# [01:00] <AryehGregor> annevk, what does "What did you do? You tried to pass the comment system with an invalid comment! (Or you used an entity that cannot be used. Sorry about that, PHP is a mess.)" mean? I have a comment I want to post but it won't let me.

# [01:15] <gsnedders> Well, the email to internals for PHP 5 bugs wasn't sent for a while because it had over 1000 things in it, and that broke the script!

# [01:15] <AryehGregor> gsnedders, did you know, for instance, that if a __get is nested at any depth inside another __get, even for a totally different class (IIRC), it silently returns null without even raising a notice?

# [01:15] <gsnedders> Most of the bugs I've reported in the past couple of years aren't bogus.

# [01:23] <Philip`> I'm interpreting "accreted" as meaning the same as "evolved", and languages like Python and Java accreted with the guidance of some language design principles and a desire for self-consistency

# [06:00] <MikeSmithX> Hixie: it turns out the problem is not my script, but some problem on the cvs server.. I'm trying to figure it out now, but not clear to me how locking is handled in this cvs server instance

# [09:39] <Hixie> feel free to slide in some easter eggs btw -- a great many of the examples in the spec have secret messages or are referencing memes, or shows or books i like, or my friends, or whatever :-)

# [11:02] <hsivonen> cardona507: I don't know about the relative technical merits of Vorbis and AAC. However, no one is collecting royalties for Vorbis.

# [11:02] <othermaciej> I think all the MP3 US patents expire on 2012 except for non-essential ones on optional ways to improve encoding quality

# [11:02] <tametick> cardona507: actually i only need to use the audio api for sound effects (that need to play fast with as little latency as possible), i guess i could use that wav/ogg solution for that and just use plain old <embed> for background music, since latency is a lot less important for it

# [12:49] <othermaciej> Hixie: this one has an implied spec change based on a faulty premise in addition to the question

# [12:49] <othermaciej> i.e. it says there is a contradiction which actually there is not

# [12:50] <othermaciej> so I'd handle this one on that basis (in addition to answering the question)

# [12:51] <othermaciej> if a bug really just asked a question without any report of a problem or request for a change (even implied), then I would consider that INVALID, same as garbage text or a completely off-topic comment

# [12:51] <othermaciej> or maybe NEEDSINFO if it seemed like the person was getting at something but failed to express themselves

# [15:35] <hsivonen> I'm concerned that if something goes wrong with my account and I lose access, I'm paying Google nothing and I'm one among millions, so that Google doesn't have enough of a reason to care and I have no recourse

# [15:40] <Lachy> hsivonen, if you don't like self-hosting, are there any problems with the Zimbra accounts they host for you?

# [15:40] <hsivonen> annevk: only if quota there is large enough and Webmail there doesn't suck

# [15:40] <Philip`> hsivonen: Since you're one among millions, a problem will either affect lots of people and therefore be important to fix quickly, or it will affect one person and there's a million-to-one chance it won't be you

# [15:52] <hsivonen> Philip`: I don't trust Microsoft's commitment to open specs enough to use their hosted services. I don't want to find that one day IMAP has been replaced by Exchange protocols and Webmail by Silverlightmail

# [15:52] <Lachy> Microsoft have already tried to replace IMAP with their own protocols

# [15:53] <Lachy> and they've largely succeeded, given how pervasive Exchange is in the enterprise market, and why Outlook is the most popular client because there isn't much else that's compatible with it

# [15:53] <jgraham> s/tried to/succeeded in/ for the purposes of many large intranets

# [15:53] <Lachy> though Apple Mail is now I think they've licensed it

# [19:09] <Lachy> I don't think TimBL could really overrule a WG decision if it had been decided to keep it, regardless of Tim's or the TAG's position on the issue

# [19:09] <AryehGregor> Doesn't the W3C procedure say that the Director needs to personally approve specs for them to progress?

# [19:10] <Philip`> TabAtkins: Yahoo's is fairly close to RDFa, if I remember correctly

# [19:10] <Lachy> that's basically to confirm that proper W3C procedures have been followed during it's development, rather than having the director say whether or not he agrees with everything in the spec

# [19:13] <TabAtkins> Well, yeah. Microformats generally map *directly* to a Microdata vocabulary in an extremely obvious way, nearly to the point of just being able to search/replace the current class-based syntax with a Microdata-based one.

# [19:13] <Lachy> but, you're right, there are bigger fights coming up that are more important than this

# [19:13] <AryehGregor> But I'm in an awkward position as a web developer, with one well-established spec that a W3C Recommendation and everyone's heard of, and a better spec that's not in any W3C spec anymore, as soon as it's removed from the HTML5 draft.

# [19:13] <AryehGregor> Also, CC license metadata is currently only de facto standard in RDFa, IIRC.

# [19:13] <Lachy> the next step for this issue is just to take Microdata to FPWD

# [19:14] <AryehGregor> I assume that will probably happen, given the enthusiasm from the RDFa camp about equal footings and all.

# [19:14] <AryehGregor> Does anyone know someone at the CC who they could convince to have an official microdata vocabulary for CC licenses and encourage people to use that instead of RDFa?

# [19:15] <AryehGregor> We now have a few major parties that are consuming some form of RDFa, none for microdata that I see.

# [19:24] <Philip`> Plain text was good enough for typewriter users, it should be good enough for us

# [19:24] <Lachy> my only regret in this issue is that I never got around to debunking the claim about how splitting it would somehow level the playing field, but that's just cause I went on holidays just before the poll was announced

# [21:59] <Philip`> In the canvas accessibility discussion, it just means the DOM subtree of the <canvas> element (which doesn't get rendered in graphical browsers), as far as I'm aware

# [21:59] <jgraham> in the <canvas> case they just mean "desendants of the canvas element" as I understand it

# [21:59] <TabAtkins> cardona507: The benefit is that it allows you to do transformations that don't actually make sense from a content perspective, but are necessary for styling. Like, say, wrapping a box in multiple <div>s so that you can style each one.

# [22:00] <TabAtkins> The fact that your styling happens to be easier to apply when you have a structure like <div><div><div><div>foo</div></div></div></div> shouldn't have any effect on your actual content, which just uses <div>foo</div>.

# [22:01] <othermaciej> jgraham: most of the individual criteria were not enough to decide the matter by themselves, and it's not clear if any other part of the spec is precisely in the somewhat unusual position that Microdata is in

# [22:02] <TabAtkins> What precisely *is* the unusual position Microdata is in?

# [22:02] <othermaciej> jgraham: plus, we're not going to rule on splitting anything that no one actually objects to

# [22:04] <Lachy> the right way to deal with that is, since Hixie won't introduce new elements, is to drop both figure and details from the spec and reintroduce them with <legend> in the future when the parsing issues are resolved with it.

# [22:05] <Lachy> ok, someone should write down what I just said as a change proposal

# [22:05] <othermaciej> as far as I am aware, that is not an ordinary term of art for the caption for a figure, let alone the label of a disclosure control

# [22:05] <othermaciej> I am considering writing Change Proposals for one or more of the following:

# [22:05] <othermaciej> 1) Use <caption> for <figure> and <label> for <details>, with a slight tweak to parsing so that <caption> inside <figure> does not break tables

# [22:06] <Lachy> that would be nice if you think the legacy issues with <caption> aren't insurmountable

# [22:06] <othermaciej> 2) Introduce new elements <fcaption> and <dlabel> because it's totally a standard design pattern for HTML elements with compound structure to have specialized helper elements that exist only for purposes of their structure

# [22:07] <Lachy> I like <c> as an element name, which I've suggested before

# [22:07] <othermaciej> despite Hixie's distaste for the idea, we have tbody, thead, tfoot, tr, td and caption which are (currently) only used for tables, li only for lists, dt/dd previously only for dl, param only for object

# [22:07] <TabAtkins> The issues with <caption> only arise when you put a <figure> inside of a <table> anyway. If you can avoid that you're golden.

# [22:08] <othermaciej> TabAtkins: and parsing can be changed in the future to make it not a problem in the long run, so I think it's better than <legend>, since both are fixable and in the short term <caption> only affects <figure> in <table>

# [22:08] <othermaciej> 3) Suggest using <h1> (or some other <hn> element) for figure captions and the label of <details>

# [22:08] <Lachy> TabAtkins, given how many legacy pages there are using layout tables around the whole page, I don't think it's unrealistic for a <figure> to end up being added to an old template like that

# [22:08] <jgraham> I think my general opinion is that a) parsing issues should not be underestimated and b) adding more elements is not a problem

# [22:08] <TabAtkins> Then they just wait for parsing changes before doing so, Lachy.

# [22:09] <othermaciej> I asked Hixie what the problem with <h1> would be and he said it might interfere with the content model of <figure>

# [22:09] <Lachy> I don't like the idea of reusing heading elements, since a caption is not a heading. It's a very different concept, and I think the default styling of h1 will make it very unappealing to authors

# [22:09] <jgraham> If we can't do something that can be deployed in legacy browsers we should wait for the next version of HTML

# [22:09] <othermaciej> my reaction is that this is not a problem for <details>, and in the case of <figure> in the unusual case where you need headers inside the figure content, you can wrap it in a <div> or <section>

# [22:10] <TabAtkins> If the parsing changes are required to use it at *all*, like <legend>, it's a problem. If they are more minor, it's less of a problem.

# [22:10] <jgraham> "Needed to use it in a table based layout" is a serious problem

# [22:10] <othermaciej> I think <details><label> can be deployed in legacy browsers with essentially no problem, and <figure><caption> with problems only for figures in tables, but making it usable everywhere else

# [22:10] <Lachy> also, reusing h1 to h6 for this will make stylesheets overly complicated, since authors wanting to apply styles to headings will have to do some magic with their CSS to undo the styles for figure>h1

# [22:11] <othermaciej> jgraham: I agree with you in general that adding new elements is not a problem; Hixie seems to be almost alone in very strongly opposing new elements

# [22:12] <jgraham> (the reason I think that deploying things that cannot work in the legacy is bad is that authours read a bunch of tutorials saying "well you can't actually use this because of legacy concerns" and then ten years later when the legacy concerns are gone, people still cargo-cult whatever workaround was developed in the inierim)

# [22:12] <othermaciej> cardona507: it expires at the end of this year, but will hopefully be renewed

# [22:18] <Lachy> othermaciej, I think we should merge the change proposals to introduce a new element together into one, and just list the possible alternatives. Then when people make their case for/against the change proposals, they can state the name preference

# [22:18] <jgraham> Philip`: The problem as I understand it is that we would have to adopt the proposal wholesale. So we would need the name at least temporarily

# [22:28] <Lachy> I think dt/dd sort of works for details, but the compat problems are annoying for authors to have to deal with, especially since the workaround isn't all that intuitive, at least without understanding how IE's crazy parsing works

# [22:28] <daedb> I prefer a new element (though I dislike the ftlcap name) for <figure> instead of dt/dd just because dt/dd feels like unnecessary wrapping most of the time.

# [22:30] <Lachy> I suppose the rationale against using dt/dd would be the same for virtually all change proposals, so we should have that clearly documented once, and then let the rest of the change proposals just argue which alternative is best

# [22:30] <othermaciej> that's it, we should name the new element <bikeshed>

# [22:31] <Philip`> Why give this element such special status, compared to all the other bikesheds we have?

# [22:31] <jgraham> (because it seems odd to spell out <figure> and spell out caption> but have a random f hanging around)

# [22:31] <othermaciej> sure, everyone making their own rationale might not be the best use of time, I think it would be ok to cite another Change Proposal's rationale wholesale and the new rationale just explains why this proposal seems best

# [23:13] <AryehGregor> How about we use <rubric> for the new elements, define it to work the same as <caption>, <legend>, and <label> in the appropriate contexts, and eventually make all of the latter nonconforming?