#whatwg on 2010-01-11

00:21	<Hixie>	something's leaking in apache on my server
00:23	<Hixie>	Lachy: fixed
00:25	<Philip`>	Must be the cats
00:25	<Dashiva>	cat apache
00:36	<Lachy>	Hixie, thanks
00:37	<Lachy>	I just upgraded the wordpress installation
00:37	Lachy	makes a note to check for mediawiki upgrade later
00:46	<ttepasse>	Hm. Why isn't there a isProtocolHandlerRegistered() to registerProtocolHandler()?
00:48	<Hixie>	because we don't want to expose whether the user deleted the registration or not
00:48	<Hixie>	just call register...() againt
00:48	<Hixie>	again, even
00:49	<ttepasse>	Ah.
04:04	<sirdarckcat>	hello, I have a question regarding the CSS3 spec
04:04	<sirdarckcat>	why the "Malformed statements"
04:05	<sirdarckcat>	from
04:05	<sirdarckcat>	http://www.w3.org/TR/CSS2/syndata.html#parsing-errors
04:05	<sirdarckcat>	was removed on
04:05	<sirdarckcat>	http://www.w3.org/TR/css3-syntax/#error-handling
04:05	<sirdarckcat>	how should a parser behave if it finds a selector that can't be parsed?
04:07	<AryehGregor>	Drop it and the following block, I believe.
04:07	<AryehGregor>	Easy to test.
04:07	<sirdarckcat>	hmm, yes, that's how browsers behave.. my meaning is
04:07	<sirdarckcat>	if there was a particular reason to remove it from the spec
04:07	<AryehGregor>	Dunno.
04:08	<aho>	halt and catch fire if it's IE :>
04:08	<AryehGregor>	You could ask www-style.
04:08	<sirdarckcat>	mailing list or channel?
04:08	<sirdarckcat>	oh
04:08	<sirdarckcat>	mailing list
04:08	<sirdarckcat>	haha
04:08	<AryehGregor>	There's a #css here, but I don't think the spec editors hang out there regularly. I believe there's a W3C IRC network too. But I meant the list.
04:08	<sirdarckcat>	yes hehe
04:09	<sirdarckcat>	oh well, I was just trying to see if there was some point I was missing
04:09	<sirdarckcat>	I'll ask them
04:09	<sirdarckcat>	thanks
04:09	<AryehGregor>	I didn't even look at the spec, TBH.
04:09	<AryehGregor>	Just be sure it wasn't just moved someplace else or anything.
04:10	<sirdarckcat>	yeah, I'm trying to see the tokenization section, and the selector := any+ seems to imply that almost anything is acceptable
04:10	<sirdarckcat>	but stuff like
04:10	<sirdarckcat>	^= and $= selectors are not declared in that syntax
04:11	<sirdarckcat>	but its normal, since the document states that the SELECT chapter should be merged
04:11	<sirdarckcat>	anyway, I still find it difficult to find a specific about what to do
04:11	Hixie	tries to work out what document.clear() is
04:13	<Hixie>	sirdarckcat: look at the dates of those documents - the CSS2 one is from sept 2009, the CSS3 one is from Aug 2003.
04:13	<aho>	back to the future :v
05:06	<Hixie>	anyone know what the term "activation object" in ES3 became in ES5?
05:24	<sirdarckcat>	@Hixie, oh you are right
05:24	<sirdarckcat>	thanks
06:50	<Hixie>	hole kittens, i actually got below 90 bugs finally
06:50	<Hixie>	i thought that was like some sort of unbreakable barrier there for a while
10:46	<payman>	gsnedders: ping
10:53	<Hixie>	MikeSmith: cvs locked again
10:53	<MikeSmith>	dammit
10:54	<MikeSmith>	Hixie: working on it now
10:55	<MikeSmith>	at least I know now that that it's not my author-view automation that's causing the problem
10:56	<MikeSmith>	Hixie: how long has it been hanging?
10:57	<MikeSmith>	systeam tells me the lock has an up-to-this-minute timestamp on it
10:57	<MikeSmith>	and that the PIDs are changing as we speak
10:57	<MikeSmith>	so something is running normally
10:57	<Hixie>	MikeSmith: about 3 minutes
10:57	<MikeSmith>	I mean it's not a stale lock at least
10:58	<Hixie>	:-)
10:58	<MikeSmith>	OK
10:58	<MikeSmith>	please give it another few minutes
10:58	<Hixie>	actually 14 minutes so far
10:58	<Hixie>	but sure
10:58	<MikeSmith>	oh
10:58	<Hixie>	not like i have any choice :-P
10:59	<Hixie>	10:51 UTC is when i first got a lock message
10:59	<Hixie>	haven't checked anything into the /spec/ directory since
10:59	<Hixie>	i should say, i haven't succeeded at checking anything into there since
10:59	<Hixie>	(i have tried)
11:00	<MikeSmith>	OK
11:00	<Hixie>	for the record, this microdata split is dumb
11:00	<Hixie>	it makes the <link> and <meta> sections silly
11:01	<Hixie>	and makes all the global stuff - index, lists of attributes, etc - wrong also
11:01	<Hixie>	and the postmsg thing makes the Window object IDL silly
11:01	<Hixie>	sigh
11:01	<Hixie>	i hate these splits
11:03	<MikeSmith>	Hixie: locks seem to be clearing and then coming back again very quickly
11:03	<MikeSmith>	something must be looping
11:03	<Hixie>	well it ain't me, i'm not checking anything in right now
11:06	<Hixie>	MikeSmith: i just discovered that some of the examples in the spec are invalid HTML4, so I'm having to comment them out of the w3c version of the spec
11:08	<MikeSmith>	Hixie: I think the answer to that should be that they don't assert that they're valid HTML4
11:08	<Hixie>	these were examples where there was first the source, then the example literally in the spec so you could see what it looked like
11:08	<Hixie>	i just removed the second part and left the source
11:09	<Hixie>	e.g. search for "gross margin table"
11:09	<Hixie>	that <table> uses the HTML5-suggested "<tfoot>-comes-last" markup style
11:10	<Hixie>	so i left the markup but hid the actual table
11:10	<MikeSmith>	ah tfoot
11:10	<MikeSmith>	I would rather we just got rid of tfoot
11:10	<Hixie>	there are other examples, like <p> in <caption>, and so on
11:10	<MikeSmith>	I see
11:11	<Hixie>	i expect the number will increase as i add examples
11:13	<MikeSmith>	you could solve this problem most easily by just removing all the examples
11:15	<Hixie>	:-P
11:17	jgraham	prefers invoking the wrath of the gods on whoever thinks that HTML5 shouldn't be writen in HTML5
11:17	jgraham	notes that he believes this to be a purely psychological terror
11:18	<Hixie>	every HTML4 draft was published using HTML4
11:19	<webben>	It's a good practice for languages that want backwards compatibility to demonstrate that in the spec! :)
11:20	<Lachy>	Hixie, who has requested that the spec be written in HTML4?
11:21	<Hixie>	w3c pubteam
11:21	<Lachy>	wtf? Just tell them no.
11:21	<Hixie>	hahahahaha
11:21	<Hixie>	good luck with that
11:22	<Hixie>	please feel free to be my spokesperson the next time we publish
11:22	<Hixie>	i'm done arguing with w3c over stupid things like that
11:22	<jgraham>	You could try "It is reducing the quaility of the spec" although I'm not convinced that argument holds much weight
11:22	<Lachy>	Just explain that due to the examples in the spec illustrating HTML5, the spec itself cannot be valid HTML4
11:23	<Hixie>	i've tried every argument under the sun already
11:23	<Hixie>	it's no longer my concern
11:23	Lachy	suggests splitting out the examples into their own spec.
11:23	Lachy	runs
11:24	<jgraham>	Lachy: Don't someone will probably take you seriously
11:24	<Hixie>	the canonical version of the spec is on the whatwg.org site, the w3c can take as long as they like to get over their problems and get with the programme
11:25	Dashiva	waves to MLW
11:26	<Philip`>	Is he still going?
11:26	<Dashiva>	I'll bet you a <details> Hixie's latest line will be on it
11:30	<jgraham>	It seems (s)he is. I'd forgoten all about it to be honest
11:32	<Hixie>	http://www.w3.org/Bugs/Public/show_bug.cgi?id=8628 - are we sure that the term "boolean attribute" is the cause of this?
11:32	<Hixie>	i've seen people use =false long before html5 came along.
11:32	<Hixie>	"flag attribute" is kinda hokey
11:32	<hsivonen>	Hixie: =false seems to show up with new HTML5 attributes
11:33	<hsivonen>	Hixie: I don't remember seeing <input checked=false> too often, but I don't have scientific data
11:33	<Hixie>	yeah, but that's just because authors have a hard time understanding the whole concept of boolean attributes, not because they're called that
11:33	<Hixie>	and because the new attributes are often used without testing
11:34	<Hixie>	changing a term that is used that often in the spec is very disruptive and usually results in all kinds of mistakes that takes weeks to fix
11:34	<Hixie>	so unless we have a really really good replacement term, i'm skeptical
11:35	<webben>	Hixie: I agree the attributes are confusing no matter what; I think "boolean attributes" is perhaps more confusing than "flag attributes" because people see "boolean" and think they know what that means.
11:36	<Hixie>	i'm not buying the asserted causality chain here
11:36	<Hixie>	and "flag attributes" is just terrible as a term
11:36	<Philip`>	Do normal people actually know what "boolean" means?
11:36	<Hixie>	(also i use the term "flag" all over the place)
11:36	<Philip`>	(i.e. people who aren't programmers or mathematicians)
11:37	<Hixie>	Philip`: yeah that's one reason i don't really buy it
11:37	<hsivonen>	enough people who write HTML by hand know enough about programming to know what a boolean is
11:38	<webben>	hsivonen: Exactly.
11:38	<jgraham>	I don't really like flag attributes
11:38	<jgraham>	It makes me think of the things that wave in the wind
11:38	<jgraham>	(but I also don't like boolean attributes because it does seem confusing)
11:39	<Philip`>	Call it a there-or-not attribute
11:39	<webben>	I think "boolean" confuses anybody with any experience of programming, on top of the attributes being confusing to everyone to begin with.
11:39	gsnedders	finds the spec looks nothing like what he remembered
11:39	<gsnedders>	Hixie: I guess you really want xdoc xref soon
11:40	<Philip`>	I thought he really wanted it years ago
11:40	<gsnedders>	Well, yeah
11:40	<Hixie>	gsnedders: websockets is blocked on not having cross-doc xrefs
11:40	<Hixie>	(microsoft want them before we publish any further)
11:40	<gsnedders>	Hixie: I expect there will be something usable by the end of the month.
11:40	<Hixie>	sweeeeeeet
11:40	<Hixie>	how does it work?
11:41	<Hixie>	what input do i give it?
11:41	<gsnedders>	Basically the same as you give PMS now. I don't know how jgraham will want to deal with being given loads of files all at once, though.
11:41	<Lachy>	Hixie, why does the W3C multi-page spec still contain microdata? http://dev.w3.org/html5/spec/#auto-toc-5
11:41	<Hixie>	gsnedders: how do you work out what the URLs should be then?
11:41	<Hixie>	Lachy: mike stopped regenning it i think, not sure
11:42	<Lachy>	ok
11:42	<gsnedders>	Hixie: Oh, and it's quicker to generate all the WHATWG specs (excluding complete) than generating the "HTML" document alone with Anolis 1.
11:42	<gsnedders>	Hixie: You tell it the URLs.
11:42	<Dashiva>	"Valueless attributes"
11:43	<MikeSmith>	Lachy, Hixie - I turned of the script that generates the multi-page version
11:43	<Hixie>	gsnedders: currently i only regen the changed ones
11:43	<MikeSmith>	the full version should be up to date
11:43	<MikeSmith>	one-page version
11:43	<gsnedders>	http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?content-type=text/html still contains everything?
11:43	<Hixie>	no
11:43	<Lachy>	dammit, you're right about the microdata split making the spec silly. Section 6.1 Content models in the separate Microdata spec makes it more difficult to know the conformance requirements for the elements it changes :-(
11:44	<gsnedders>	Hixie: You could get it to do that, but that will get complex when multiple files change and you need to get the right set of files.
11:44	<Hixie>	gsnedders: going forward are you saying i should just group the specs into the w3c ones, the whatwg ones, and complete, and have the cross-references work? i'm confused.
11:45	<gsnedders>	There are two ways to deal with xref: either you pass all the source files at once, or you pass some of them and URLs for other files to load xref from.
11:45	<gsnedders>	(but in that case it can't add ids to the,)
11:45	<gsnedders>	*them
11:45	<Hixie>	hm so basically i could just generate each one, upload them, then generate them all again, upload that, and keep repeating until it converges? :-)
11:45	<Dashiva>	Sounds like bibtex
11:46	<gsnedders>	You _could_.
11:46	<Philip`>	Is it guaranteed to converge?
11:47	<gsnedders>	I can't think of any way in which it wouldn't.
11:47	<Hixie>	gsnedders: can i give it a URL to load references from but give it a _different_ URL to actually use in the spec it outputs?
11:47	<gsnedders>	No
11:47	<Hixie>	gsnedders: because then i wouldn't have to upload the drafts to the w3c
11:47	<Dashiva>	With all the talk of modularization and monoliths, this sounds like it would be a lot easier if the spec splitter was integrated with the cross referencer
11:48	<Hixie>	to do the converging
11:48	<gsnedders>	Hixie: Wouldn't it be easier to just generate all the W3C specs at once, with some magic to deal with not regenning unchanged documents?
11:49	<Hixie>	Dashiva: and we could merge that with the html-to-ietf-draft convertor, too! :-)
11:49	<Philip`>	Seems like a similar problem to the linker for compiled programming languages, where you want to process a lot of source files individually and then fix up all the crossreferences later
11:49	<Hixie>	Philip`: it's actually the opposite, since i start with one source file :-)
11:50	<Philip`>	except in this case the linker (Anolis) is doing a lot of the compilation too
11:50	<Hixie>	gsnedders: there are ten w3c drafts right now
11:51	<Hixie>	gsnedders: it sounds like i can deal with what you're describing
11:51	<Dashiva>	Hixie: Did you see adactio's comments about /html5 and /specs/ earlier?
11:51	<Hixie>	Dashiva: no? where? here?
11:51	<Dashiva>	Yeah
11:51	<Dashiva>	Basically, /html5 no longer links to HTML5 (rather WHATWG HTML) and /specs/ is woefully incomplete and out of date
11:52	Philip`	wouldn't want /html5 to redirect to HTML5, since all the links he's posted to /html5#foo would suddenly change to the single-page version that crashes people's browsers
11:52	<Hixie>	i updated /specs/ recently
11:52	<Hixie>	is it better now?
11:52	<MikeSmith>	Hixie: I will let you know as soon as i get clue about the lockng problem
11:53	<Hixie>	/html5 is supposed to redirect to the whatwg html page
11:53	<Dashiva>	It doesn't look changed to me: http://www.whatwg.org/specs/
11:54	<Dashiva>	E.g. it doesn't mention WA 1.0
11:54	<Hixie>	oh, should it?
11:54	<Hixie>	i guess it could
11:54	<adactio>	I think it's pretty ridiculous that the URL /html5 doesn't redirect to the HTML5 spec. Use /html to direct to HTML and /html5 to redirect to HTML5. I think it's pretty devious that all the links out there pointing to /html5 no longer point to the HTML5 spec.
11:55	<Hixie>	it is the HTML5 spec
11:55	<Hixie>	well, it's really the HTML6 spec
11:55	<Hixie>	or whatever you want to call it
11:55	<Hixie>	it's the spec that matters, anyway
11:55	<hsivonen>	Hixie: not having "HTML5" as the name of "the spec that matters" is a problem
11:55	<Hixie>	that's why it says "including html5"
11:56	<Dashiva>	Hixie: I don't have a strong opinion, but the page should at least be as informative as the FAQ entry.
11:56	<hsivonen>	(as far as communicating with people who don't follow #whatwg goes)
11:56	<Hixie>	Dashiva: well i don't want to have that information there twice... i guess i can just point to the FAQ entry?
11:56	<Dashiva>	hsivonen: Having HTML5 as the name would make people even angrier
11:58	<adactio>	Well, I'll just start pointing people to the W3C URLs because they seem to more trustworthy i.e. they aren't likely to suddenly change from one day to the next.
11:58	Philip`	isn't convinced the process problems can be solved simply by selecting good names
11:58	hsivonen	tries to understand how the different i5 or i7-branded CPUs might compare for compiling Firefox
11:58	<Hixie>	adactio: i'm not really sure i understand what it is that is changing in the whatwg one
11:58	<Dashiva>	How about calling it HTML.next instead of WHATWG HTML :)
11:58	<Hixie>	adactio: the w3c one is changing all the time -- e.g. they just took out microdata and the 2d context for no good reason
11:59	<hsivonen>	Hixie: in fairness, you took out the 2d context
11:59	<adactio>	Hixie: but at least the URL for HTML5 still points to a specification for HTML5.
11:59	<hsivonen>	Hixie: there was no chair decision for that
11:59	<Dashiva>	Not like it wasn't obvious what the chair decision would have been
11:59	<Hixie>	adactio: what do you call "html5"?
12:00	<Hixie>	hsivonen: there's nobody in the htmlwg asking for it to be kept in the spec except me and a handful of #whatwg regulars, as far as i can tell.
12:00	<adactio>	Hixie: the part of WHAT WG HTML in parentheses "(including HTML5)"
12:00	<hsivonen>	Hixie: OK
12:01	<Hixie>	adactio: so you think everything in the HTML spec on the WHATWG site except the <device> element is HTML5?
12:01	<adactio>	Hixie: Anybody coming to /html5 expecting to see a spec called HTML5 and instead discovering a spec called "HTML (including HTML5)" will want to know "Well, which bit is HTML5 because that's what I'm interested in"
12:01	hsivonen	thinks adactio is right
12:01	<adactio>	Hixie: the point is: I don't know anymore what HTML5 is.
12:01	<Hixie>	adactio: why would anyone care about HTML5, as opposed to what the latest HTML spec is? HTML5 is the last generation now.
12:02	<hsivonen>	Hixie: because HTML5 has all the hype
12:02	<adactio>	Hixie: because people like me are out there tell front end developers/designers: "you should really check out HTML5—it's got great stuff". They then go looking for something called HTML5.
12:03	<Hixie>	well i can't call the whatwg spec "html5" without making the even more confusing step of having the specs describe the term "html5" as being different sets of technology.
12:03	<gsnedders>	Hixie: Because people want to claim to support "HTML5", because it is hard to support something that has changed in the time from layout-engine freeze to shipping
12:03	<adactio>	Hixie: now, should I instead be evangelising "HTML (including HTML5) because that's going to get very tiring to say/write/
12:03	<Hixie>	adactio: i would evangelise individual features, not buzzwords
12:04	<adactio>	Hixie: then, as I said, the safest thing for me to do is to point to W3C urls rather than WHATWG urls.
12:04	<Hixie>	adactio: why is that safer?
12:04	<hsivonen>	Hixie: I suggest making /html5/ and /current-work/ point to something that corresponds to "HTML5"
12:04	<hsivonen>	or at least /html5/
12:04	<adactio>	What hsivonen said.
12:04	<Hixie>	i don't understand why we would want to hide <device> from people
12:04	<Hixie>	or is that not what you're asking for
12:05	<Hixie>	i don't really understand what you're asking for
12:05	<Lachy>	adactio, it doesn't matter. The whole point of it is to try and move away from versioned specs. The features that people can use depends solely on what is supported in implementations, not whether something happened to make the feature freeze cut off in the W3C process.
12:05	<Philip`>	Maybe "HTML (including HTML5)" should be deleted, and "HTML5" considered the 'main' HTML spec for now (and the same between W3C and WHATWG), and the new features split into separate specs (the "Devices for HTML" spec etc)
12:05	<hsivonen>	Hixie: does <device> have implementor buy-in?
12:05	<Philip`>	since that avoids the confusion of having multiple versions of HTML being promoted simultaneously
12:05	<Hixie>	hsivonen: it has as much implementor interest at this stage as <video> did when we added that
12:05	<adactio>	Point /html to the "everything" spec (HTML including HTML5 and Device). Point /html5 to the subset that is HTML5. (as for what's in that subset: I don't know anymore—you tell me)
12:06	<Hixie>	adactio: do you think what is labeled "html5" should include any or all of .localStorage, web workers, websockets, geolocation, eventsource, or <device>, and if so, which ones?
12:06	<csarven>	Is readonly implied for <input type="hidden" ?
12:07	<Lachy>	adactio, other than the backwards W3C process, can you clearly explain why you think the distinction between HTML5 and the additional stuff is important?
12:07	<hsivonen>	Lachy: "5" is important when "5" has PR value
12:07	<Lachy>	hsivonen, that's not what I'm asking
12:07	<hsivonen>	Lachy: for better or worse, we have a number in the buzzword
12:08	<Hixie>	adactio: also add microdata, the canvas 2d graphics context, and elements like <progress> and <details> to that list, so i can better understand what you think is in html5 and what you think is out
12:08	<Lachy>	my question is regarding the distinction between the features that are officially in HTML5, and the features that are additional extras.
12:09	Philip`	guesses the HTML5 spec should have links to other "HTML5" technologies like geolocation too, to help users
12:09	<adactio>	Lachy: actually, no, I can't answer that, at least not easily. I just know that it smells bad to overload a spec with everything. I absolutely agree that 5 is a buzzword but it's got to mean something: a subset of "everything including the kitchen sink"
12:09	<Dashiva>	WHATWG HTML is a subset already, though
12:09	<Hixie>	"everything including the kitchen sink" is http://www.whatwg.org/specs/web-apps/current-work/complete.html
12:09	<Dashiva>	It's just a slightly larger subset
12:09	<Hixie>	(actual kitchen sink in the abstract)
12:10	<hsivonen>	HTML5-the-buzzword pretty much covers everything that isn't covered by CSS3-the-buzzword...
12:10	<Hixie>	http://www.whatwg.org/specs/web-apps/current-work/ excludes web storage, web workers, wob sockets, server sent events
12:11	<adactio>	Look: the current spec (located at /html5) has the title "HTML (including HTML5)". It's completely reasonable for someone to ask "Oh, which part of this spec is HTML5?". As for what that subset is, you tell me!
12:11	<Lachy>	adactio, so, in other words, your sole reason for this line of argument is purley an instinctive reaction to what you consider to be unexpected?
12:11	<adactio>	Least surprise.
12:11	<Hixie>	the w3c html5 spec excludes microdata, <device>, 2d context, postMessage, MessageChannel, web storage, web workers, wob sockets, server sent events
12:11	<hsivonen>	Lachy: adactio's question is perfectly reasonable considering the title
12:11	<adactio>	Lachy: yeah, right now the principle of least surprise is being violated by having /html5 redirect to a spec called HTML.
12:12	<Hixie>	adactio: ok, HTML5 is everything in the spec labeled "WHATWG HTML (including HTML5)", we just can't call it that because the w3c would lynch me.
12:13	<hsivonen>	"SVG is part of the HTML 5 family of technologies."
12:13	<adactio>	Hixie: so you know it really should just be called HTML5 ...but that would cause political problems.
12:13	<Hixie>	csarven: (no, it just doesn't apply because you can't edit it, it's not interactive)
12:13	<Hixie>	adactio: yes
12:13	<Hixie>	adactio: well, it really should just be called HTML, and we should move away from versioning
12:13	<Hixie>	adactio: but it can be called HTML5 for now if that buzzword hasn't had its day yet
12:14	<Hixie>	adactio: except it can't, because then the w3c and the whatwg would be disagreeing about what is in "html5"
12:14	<Hixie>	adactio: and that would be even worse
12:14	<adactio>	Hixie: I'm in favour of not confusing authors/developers even if it's at the expense of political harmony between organisations.
12:14	<Hixie>	you wouldn't have to bear the brunt of the disharmony
12:14	<Dashiva>	adactio: But it would confuse authors in a different way, since they'd see two HTML5 with different contents in the media
12:14	<Lachy>	call it HTML5++
12:15	<Lachy>	or HTML++
12:15	<adactio>	Hixie: then it sounds like I definitely should be pointing to W3C urls as being canonical.
12:15	Philip`	wonders where political harmony comes in the priority of constituencies
12:15	<Hixie>	adactio: the W3C URLs are missing microdata, <device>, 2d context, postMessage, MessageChannel, web storage, web workers, wob sockets, and server sent events, is that what you want?
12:15	<Dashiva>	Philip`: The bureaucracy is always highest priority
12:15	<Philip`>	Wob sockets sound fun
12:15	<adactio>	Hixie: I think so, yes.
12:16	<Hixie>	(assuming by "the W3C URLs" you mean http://dev.w3.org/html5/spec/Overview.html)
12:16	<Hixie>	adactio: then go ahead :-)
12:16	<Hixie>	adactio: personally i think that's a pretty feeble "html5" :-)
12:16	<adactio>	We need some kind of name for the subset of HTML (i.e. HTML not including device, web storage, etc.). For historical reasons, the word HTML5 seems to be the best label for that subset.
12:17	<Hixie>	there are two subsets
12:17	<Hixie>	there's the subset that is only missing web storage, web workers, web sockets, and server sent events
12:17	<Hixie>	that's what i would call "HTML"
12:17	<Hixie>	then there's a further subset that's also missing microdata, <device>, 2d context, postMessage, and MessageChannel
12:17	<Hixie>	which the w3c currently calls "HTML5"
12:18	<Hixie>	but then a few weeks ago they had all but <device> in there and they called _that_ HTML5
12:18	<Dashiva>	We have always been at war with Eurasia
12:19	<Lachy>	adactio, this table illustrates what's included in each version of the spec http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F
12:19	<adactio>	So it sounds like you need a new term to describe HTML5+device+microdata. Overloading the existing terms (HTML and HTML5) is not going to clarify anything.
12:19	<Hixie>	adactio: personally i'm interested more in making the web better than in making best use of buzzwords, so having <device> in HTML (and in the spec that I want people to review) is more important than calling it HTML5 to me
12:20	<Lachy>	IMHO, the complete Web Applications 1.0 spec is all that you should be concerned about. The rest is just a result of buraucracy
12:20	<Hixie>	adactio: microdata is part of HTML, whatever number it has on the end of it
12:20	<Philip`>	The web won't be made better if users don't understand what features exist and can't find where they're documented
12:20	<Philip`>	so the naming seems like an integral part of the betterment
12:20	<adactio>	Hixie: but clarity is important in getting authors to adopt this technology (and according to the priority of constituencies, they are important).
12:21	<adactio>	What Philp said.
12:21	<Hixie>	adactio: authors have been adopting thus stuff far faster than i'd like, so far
12:21	<Hixie>	adactio: it's actually caused problems already
12:21	<Hixie>	so i don't think that's a problem currently
12:22	<Dashiva>	adactio: What if /html5 pointed to a copy that had only half of HTML5. Would that be okay?
12:22	<adactio>	Hixie: well, if the Orwellian naming conventions are an attempt to stop authors using this stuff, I think it will succeed.
12:22	<Dashiva>	Authors don't read specs, they read diveintohtml5
12:22	<adactio>	Dashiva: I don't even know what you mean when you say HTML5 ...which is really at the heart of the problem.
12:22	<Hixie>	Orwellian? the names are intended to be accurate.
12:22	<Dashiva>	I don't think we can stop them from using things unless we get rid of markp :P
12:22	<Hixie>	let's not start exaggerating here.
12:22	<adactio>	Hixie: I apologise.
12:23	<adactio>	Hixie: but there's a certain "moving of the goalposts" feel going on.
12:23	<Dashiva>	adactio: The heart of the problem, yes. Because at the w3c, what is HTML5 changes from day to day
12:23	<Philip`>	Dashiva: What'll happen if he wants to cover <device> in that book?
12:23	<Dashiva>	If enough people dislike it, suddenly a feature doesn't exist anymore
12:23	<Hixie>	adactio: well yeah, it's been 6 years since we've been working on HTML5, we _are_ moving the goalposts. Last year we got to Last Call on what is HTML "5", and now we're moving towards a versionless development model.
12:24	<Philip`>	You can't sell a book called "Dive into HTML" because nobody will realise it's new and not ten years old
12:24	<Hixie>	Philip`: you just call it the 2010 edition
12:24	<Dashiva>	Release four pamphlets called "Dive into HTML 1-4" and then go for "Dive into HTML 5"
12:24	<Hixie>	hah
12:25	<adactio>	Hixie: I appreciate that and I have no problem with it (I think it's a good move). But you must see that having a url with "5" in it (/html5) pointing to the ongoing versionless spec isn't helpful.
12:25	<csarven>	Sure, "Dive into HTMl 5 Last call" sounds great
12:25	<Philip`>	I'd imagine some people are still writing/updating books in 2010 that only cover HTML4/XHTML1
12:25	<Philip`>	so that doesn't help a reader know what technologies are covered in it
12:25	<Hixie>	adactio: i can't see what else we would point to
12:25	<Lachy>	Hixie, what would it take for you to reintegrate 2dcontext, postMessage and MessageChannel back into HTML5, given that they weren't taken out by a formal group decision anyway, so we can at least partially reduce the differences between WHATWG HTML and HTML5?
12:25	<Dashiva>	Lachy: Get a WG decision on it
12:26	<Philip`>	(and they'll only judge the book by its front cover, not by the bit on the back that lists all the features it talks about)
12:26	<adactio>	"Dive into what's known as 'HTML (including HTML5)' at the WHAT WG and HTML5 at the W3C" — catchy!
12:26	<Hixie>	Lachy: object to the bugs where i did that and raise an issue
12:26	<Hixie>	Lachy: but i doubt they would pass, that's why i made the changes
12:26	<Hixie>	Lachy: the reasons that were applied to microdata apply equally to those
12:26	<Hixie>	adactio: it only has "(including HTML5)" in the name to address the concen you raised of people wondering if this was the right spec
12:27	<Hixie>	adactio: maybe the answer is to not bothe including that parenthetical
12:27	<Lachy>	the reasons that applied to microdata were bogus anyway
12:27	<Dashiva>	That doesn't really matter as long as the system considers it valid
12:27	<Hixie>	Lachy: doesn't matter if they're bogus or not, apparently
12:28	<Lachy>	the real reason people wanted microdata out was just becaue some people would prefer that we didn't work on it at all, as clearly illustrated by the FPWD objections and calls to move it to a new mailing list
12:28	<Hixie>	Lachy: obviously
12:29	<Dashiva>	If you ask me, we might as well get WG decisions on all these sections sooner rather than later
12:29	<Dashiva>	Might be able to free up some bandwidth on public-html
12:29	<adactio>	I'm seeing the start of a disturbing precedent here. When anyone* files a bug about any feature of HTML5 (the W3C spec), it gets removed from that spec but remains in the WHAT WG spec. At that point, what's the point of having mailing lists or any attempt at discussion. (*usually Shelley)
12:29	<Hixie>	i guess if we get the chairs to decide on lots of splits, the w3c spec will be such a mess that adactio won't want to point to it anymore, and he'll go back to pointing to the whatwg one :-)
12:30	<Dashiva>	Well, they might decide in a dozen different ways
12:30	<Dashiva>	But as long as the decisions are made, that's one thing less to waste time on
12:31	<Hixie>	adactio: the whatwg mailing list is still a useful way of getting input from a broad range of people and a useful way of contributing to the spec.
12:31	<Hixie>	adactio: can't speak about the w3c lists, but then i've mostly given up on them at this point.
12:31	<Dashiva>	Oh look, MLW is at it
12:31	<Dashiva>	Darn, old content
12:32	<adactio>	I'm perfectly fine with the spec called HTML5 (as hosted by the W3C) being a subset of the spec called HTML (as hosted by the WHAT WG) but two is plenty: let's try not to splinter it any further than that.
12:32	<Hixie>	it's already splintered further than that at the w3c
12:32	<Hixie>	the htmlwg already has four specs
12:33	<Dashiva>	Does that include RDFa?
12:33	<Hixie>	html5, microdata, 2dcontext, and postMessage/MessageChannel
12:33	<Hixie>	rdfa is going into its own group
12:33	<csarven>	So, I have a question; when authors, developers want to look up the spec for how x supposed to work, where do you think they will head to? HTML(WHATWG) or HTML5(W3C) ?
12:33	<Dashiva>	... then why did we publish a FPWD in the first place?
12:34	<Hixie>	csarven: probably whichever google takes them to for their query
12:34	<csarven>	This is going to be a mess
12:34	<Hixie>	it's already a mess
12:34	<Dashiva>	csarven: They probably won't go to a spec at all
12:35	<Hixie>	csarven: if they've tried using both before, they'll probably end up reusing the whatwg one, since it's got more of the content in one place
12:35	<Hixie>	rather than being split into four pieces
12:38	<Hixie>	adactio: how about if i rename the WHATWG HTML spec to "HTML5 (including next generation additions still in development)" or something?
12:39	<adactio>	Hixie: I think that would make life much, much better for curious authors/developers/designers looking to find out more about this thing they keep hearing about. Yes!
12:39	<Dashiva>	HTML5++ doesn't seem so bad in comparison
12:39	<hsivonen>	Dashiva: C++ is horrible compared to C
12:39	<adactio>	Hixie: Although I appreciate that this is just postponing the issue of moving to a numberless nomenclature.
12:40	<Dashiva>	hsivonen: But compared to C (including next generation additions still in development)?
12:41	<Lachy>	Hixie, it might be useful to clearly enumerate the additional sections included in HTML5++. The abstract currently only mentions the device element, and probably wouldn't hurt to list 2d context, postMessage and MessageChannel.
12:42	<Hixie>	oh i guess yeah, i should list that those things are included
12:42	<Hixie>	i didn't think of that
12:42	<Dashiva>	And it might useful to mention which were at some point in HTML5, and which were never
12:42	<Lachy>	Or maybe mark the headdings of those sections in some way, or at least their TOC entires, in some way that makes it obvious that they're added extras
12:42	<adactio>	Hixie: I definitely think it would be clearer to label the spec "HTML5 (plus x, y, z)" rather than "HTML (including HTML5)".
12:43	<Hixie>	ok, let me poke around and see what i can do
12:43	jgraham	thinks he agrees with adactio's original position i.e. the whatwg should call HTML5 the set of things that htmlwg is working on currently and "HTML" the mainline of HTML development
12:43	<adactio>	Hixie: Thank you. Much appreciated.
12:49	<hsivonen>	hmm. I wonder if I care enough about "boolean attributes" to escalate the bug to the Decision Process
12:50	<Hixie>	if you care that much, reopen the bug with a better name
12:50	<Hixie>	i did kind of like the earlier suggestion of "valueless attribute"
12:50	<csarven>	Isn't the value implied?
12:51	<hsivonen>	"valueless" isn't technically correct
12:51	<hsivonen>	"presence attributes" would be
12:51	<Hixie>	the name is indeed not technically correct
12:51	<Hixie>	i considered "presence attribute" but nobody would understand that
12:51	<hsivonen>	but "presence attributes" is weirder than "flag attributes"
12:51	<Hixie>	"valueless" has the advantage of discouraging people from giving values
12:52	<csarven>	(just playing here) Was 'null attributes' mentioned? Not that great but..
12:54	<Dashiva>	It has a value, but the content of the value has no importance
12:54	<csarven>	How strict should validation be? What if it said, if this attribute has a value, UAs can ignore it
12:55	<csarven>	s/can/should
12:56	<Philip`>	Seems weird to say <input checked="checked"> is a valid valueless attribute
12:58	<Huvet>	I think the trickiest problem here is to explain why autobuffer="false" means that the element _will_ autobuffer... it's hard to explain without going balobas with technical terms
13:01	<jgraham>	We could call them Descartes attributes on the basis that if they exist they are
13:01	<Huvet>	:)
13:03	<Philip`>	What terms do existing books and tutorials etc use to refer to those attributes?
13:03	<Huvet>	I think I like to call them valueless still... it could be argued that checked="checked" is just a longer form of "checked"
13:04	<Philip`>	It's a form of "checked" which has a value
13:04	<Philip`>	so it's clearly not valueless :-p
13:04	<hsivonen>	it's still a flag, though
13:04	<Philip`>	Also "valueless attribute" sounds like "pointless worthless attribute" to me
13:05	<Hixie>	oh that's a good term too
13:06	Hixie	ducks
13:07	<Hixie>	adactio: http://www.whatwg.org/specs/web-apps/current-work/#is-this-html5?
13:07	<Hixie>	adactio: does that work?
13:07	<Huvet>	<attribute>checked</attribute>=<value>"checked"</value> <- valueless makes sense! :)
13:08	<Dashiva>	"set attribute"
13:08	<Dashiva>	As oppose to map attribute :D
13:08	<Dashiva>	+d
13:08	<Philip`>	Hixie: "only even been" - should be "ever"?
13:08	<Hixie>	fixed thanks
13:10	<Philip`>	"Features that are part of HTML5 (and this specification) but that have been published as separate specifications in the past (or indeed currently, at the W3C):" - why doesn't that list include e.g. Web Forms 2, which was published separately in the past?
13:10	<Hixie>	i just changed that sentence to the present tense
13:10	<Hixie>	but i guess i should list wf2, yeah
13:11	<Lachy>	Hixie, why is the content of /current-work/ different from /current-work/multipage/ now?
13:11	<Hixie>	/multipage/ only updates when i check in the cahnges
13:11	<Lachy>	ah, ok
13:13	<Hixie>	adactio, Philip`: ok, regenned with the changes
13:16	Hixie	checks in the changes
13:16	<Hixie>	ok it's nearly 5:30am, long past anything I should consider my bed time
13:17	<gsnedders>	But you do consider it your bed time anywa.
13:19	<Philip`>	It's only a "should", he's allowed to violate it
13:19	<jgraham>	Does this coult as a good justification?
13:19	<jgraham>	*count
13:27	<Hixie>	nn
13:27	<webben>	night Hixie
13:33	<Lachy>	othermaciej, since you were the one who convinced me that we should try adding queryScopedSelector, do you have anything to add to the current discussion about whether or not we should keep it?
13:33	<othermaciej>	Lachy: I'm slogging my way through public-html right now - will look at that thread next
13:34	<Lachy>	JohnResig, I'd also like to hear from you on the issue, if you've got time, and I'm still interested to hear the alternative proposals you once told me you had.
13:34	<Lachy>	othermaciej, ok.
13:37	<TabAtkins>	What list is this discussion on?
13:37	<gsnedders>	I'd guess webapps
13:38	<Lachy>	yeah, public-webapps
13:39	<Lachy>	see the recent selectors api 2 thread
13:39	<TabAtkins>	Subscribed and checking archives now.
13:40	<Lachy>	http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/thread.html#msg62
13:58	<othermaciej>	TabAtkins: are you going to have time to write a counter-proposal for the dt/dd issue?
13:58	<TabAtkins>	Yeah, but I thought Lachy was already writing something up for it. When you need it by?
13:58	<othermaciej>	if I don't see one by tomorrow, I'll sign up for doing it myself (or just actually write one)
13:58	<TabAtkins>	Ok.
13:59	<othermaciej>	the deadline is the 16th IIRC but I don't want to wait until the last minute if I have to do it myself
13:59	<othermaciej>	Lachy doing it is fine
13:59	<othermaciej>	just wanna make sure it gets done
14:03	<Lachy>	I put it on the whatwg wiki, hoping some others might contribute to the proposals they liked
14:03	<Lachy>	http://wiki.whatwg.org/wiki/Change_Proposal:_figure_and_details
14:04	<Lachy>	also, if you guys could review the rationale against dt/dd, that would be useful
14:04	<othermaciej>	Lachy: ah, sweet
14:05	<Lachy>	TabAtkins, you might like to do proposal 6, for the <p summary> idea
14:05	<TabAtkins>	Will do.
14:05	<Lachy>	othermaciej, I'm guessing you can do fcaption/dlabel
14:06	<othermaciej>	Lachy: that looks like a good template, very useful
14:06	<othermaciej>	it seems like all that's needed to turn this into actual Change Proposals is:
14:06	<othermaciej>	1) Pick one of the proposals.
14:06	<othermaciej>	2) Update the Summary to reflect it accurately.
14:07	<othermaciej>	3) Update Rationale to explain why it is better than other proposed changes for this (e.g. why better than <fltcap>, why better than the others here).
14:07	<othermaciej>	4) Flesh out proposal details.
14:07	<othermaciej>	5) Write Impact.
14:07	<othermaciej>	6) Post somewhere in W3C space.
14:07	<othermaciej>	I will do those steps for fcaption/dlabel
14:08	<othermaciej>	I would prefer not to be first but in any case I intend to do it by tomorrow night.
14:08	<othermaciej>	Lachy: would you prefer to be listed as co-author or not?
14:08	<Lachy>	I figured once we get the proposal details written for a few of them (not necessarily all of them), then we can submit them each as individual change proposals, but they can each share the rationale against dt/dd, and provide their own rationale in favour of the particular proposal
14:09	<othermaciej>	Lachy: ok, I'll fill in those bits in the wiki first
14:14	<adactio>	Lachy: I think that's a very good change proposal document but I think it would be better as two documents: one for figure and one for details. I know that these documents would be almost identical in their rationale but crucially, the change proposals would be more specific to the particular element.
14:15	<adactio>	For example, Proposal 4 is really two different proposals.
14:15	<othermaciej>	Lachy: I'm not sure I follow the Legacy Cruft point
14:16	<othermaciej>	Lachy: are you saying that the workaround <div> will persist past its point of usefulness?
14:17	<othermaciej>	Lachy: on "Default Styles", I assume UA stylesheets will eventually give "figure > dt" and such separate style rules, but I guess it matters for the intermediate period
14:17	<othermaciej>	Lachy: I can make edits to clarify these points myself if you prefer
14:21	<Lachy>	yeah, that's what I meant about the extra <div>. I wasn't sure if that was a particularly strong argument, but I left it in there anyway
14:21	<Lachy>	you can go ahead and make whatever changes you like
14:54	<TabAtkins>	All right, proposal six is filled in. Lachy, do you need any of the others in particular filled in?
14:54	<othermaciej>	I think folks should fill in whichever ones they personally believe in
14:55	<TabAtkins>	Sure, but I believe in a few of them.
14:55	<othermaciej>	TabAtkins: you filled in a rationale for Proposal 6 relative to other proposals, but I don't see a fleshed out "Proposal Details"
14:56	<Lachy>	TabAtkins, feel free to fill in details for any that you like
14:56	<othermaciej>	TabAtkins: i.e. the details of what exactly should change in the spec
14:56	<TabAtkins>	Ah, indeed.
14:56	<othermaciej>	TabAtkins: I intend to do #3 and I'll have subsections marked "Summary", "Additional Rationale", "Details" and "Impact"
15:05	<TabAtkins>	k done
15:25	<othermaciej>	Lachy: it might be a couple of hours til I can read and comment on the webapps thread
15:27	<othermaciej>	Lachy: I made a few edits to your Rationale
15:27	<othermaciej>	Lachy: I'd like to add one more Rationale point if it is ok with you
15:27	<othermaciej>	specifically, aesthetics
15:27	<othermaciej>	actually, let me go ahead and add it, and you tell me if you hate it
15:29	<Lachy>	othermaciej, sure
15:30	<Lachy>	I sort of touched on the aesthetics issues in the Unwanted Elements section
15:31	<Lachy>	where I said it was unappealing to authors. But it might be worth making it clearer
15:32	<Lachy>	TabAtkins, you seem to have omitted any details about how or where the caption attribute is defined and which elements it can be used on
15:33	<othermaciej>	Lachy: done
15:33	<othermaciej>	feel free to edit that bit
15:33	<TabAtkins>	Which elements = all.
15:33	<othermaciej>	I also added a dt to "Unnecessary Elements"
15:34	<othermaciej>	TabAtkins: you have to describe the actual spec changes - would it be described next to "id" or next to "hidden" (those are in different sections)? how would the content model of affected elements change? what happens if you use @caption in a disallowed context?
15:34	<othermaciej>	TabAtkins: look at the level of detail in Shelley's Change Proposal
15:34	<TabAtkins>	Ah, got it. Adding that now.
15:35	<Lachy>	othermaciej, the unnecessary elements section was giving an example of where there is no caption.
15:35	<TabAtkins>	Actually, I'm looking at the level of detail in time's definition of pubdate, since that's pretty much exactly what I want.
15:35	<Lachy>	maybe the prose could be updated to reflect the addition of dt to the example though
15:35	<othermaciej>	Lachy: oh, sorry, I'll revert
15:35	<othermaciej>	I missed that
15:37	<Lachy>	it doesn't matter. I don't mind if you revert the example, or just change the preceding line introducing it
15:37	<othermaciej>	I reverted the example
15:37	<othermaciej>	I thought it was a mistake, I don't have an opinion on which way works better
15:40	<Huvet>	I think I found another html5lib bug. I get maximum recursion depth, and when I make a testcase I get this: "<object </body></html>"
15:40	<Huvet>	someone forgot to close an object starting tag
15:40	<Huvet>	I'll file a bug
15:46	<Huvet>	http://code.google.com/p/html5lib/issues/detail?id=132
15:46	<othermaciej>	TabAtkins: looking at what you have so far - you still need to describe where and how the caption attribute as a global attribute will be defined, and when it is valid to use
15:47	<gsnedders>	Huvet: Does the traceback make it look like it's in an infinite loop?
15:47	<Huvet>	yes, I cut off 500 lines or so in the traceback
15:47	<Huvet>	"<cut 500+ lines of exceptions> "
15:47	<TabAtkins>	I've done that now, you may have viewed the page slightly too early.
15:48	<gsnedders>	Huvet: So it's just the same few over and over again? OK.
15:48	<gsnedders>	Huvet: There will be some extreme cases where a conforming document could cause a stack depth error, but that wouldn't loop between a few states
15:49	<Huvet>	this is just line 1279 and line 460, back and forth
15:49	<othermaciej>	TabAtkins: what about changes to the details element?
15:50	<othermaciej>	TabAtkins: per your suggestion it seems like caption is valid even on elements that are not in a <figure> or <details>
15:50	<othermaciej>	is that really your intent?
15:50	<TabAtkins>	This doesn't affect the <details> element - I don't think it's appropriate there. I'm fine with <dt>/<dd> for <details>, or any of the new-element suggestions.
15:50	<TabAtkins>	Hrm, no. I worded it wrongly there.
15:50	<TabAtkins>	Should be invalid, not ignored.
15:50	<othermaciej>	TabAtkins: then you should update your summary to say your change is to make this change for figure but leave details as-is
15:51	<TabAtkins>	Ok.
15:51	<TabAtkins>	Not quite familiar with the spec conventions - does anything else need to be said about an invalid attribute? Is it implied that it should have no effect?
15:52	<Huvet>	gsnedders: http://pastebin.com/m2ab28d90
15:52	<Huvet>	that's the full one
15:53	<othermaciej>	TabAtkins: "invalid" and "no effect" are orthogonal - you'd have to say both if you mean both
15:53	<TabAtkins>	kk
15:53	<othermaciej>	the spec normally says "MUST NOT" rather than "invalid" but people will get what you mean
15:53	<gsnedders>	Right, yeah. Great.
15:54	<gsnedders>	Huvet: Probably quite easy to fix though
15:54	<othermaciej>	(e.g. "The caption attribute MUST NOT be applied to elements that are not a child of a figure or details element."
15:54	<othermaciej>	TabAtkins: is it ok to have more than one child in a figure with @caption on it?
15:55	<othermaciej>	TabAtkins: is it ok for the caption to be in the middle instead of first or last?
15:56	<TabAtkins>	"If multiple children of a figure element have the content attribute set, it is invalid on all such elements beyond the first, and has no effect." <-- new text
15:56	<othermaciej>	(current spec doesn't allow multiple captions or caption in the middle)
15:56	<TabAtkins>	Yes, you can put the @caption attribute anywhere within the <figure>'s content.
16:05	<TabAtkins>	I... I think my 404 page just got spammed.
16:15	<othermaciej>	TabAtkins, Lachy: I wrote the Summary and Additional Rationale for Proposal 3
16:20	<Lachy>	othermaciej, "The body parts of these elements would not have any additional markup." doesn't really make sense.
16:20	<othermaciej>	Lachy: yeah that is poorly worded
16:20	<Lachy>	I assume you're not trying to imply that they're empty elements. Maybe you want to say that they can contain phrasing content
16:21	<othermaciej>	what I mean is that there's no replacement for <dd>, you just put the actual contents right in
16:21	<Lachy>	oh, right. I totally misunderstood what you were trying to say
16:24	<Lachy>	othermaciej, wiki links are done using the syntax like this: [http://example.com/ Link Text], rather than <a> elements
16:26	<othermaciej>	Lachy: I can do that - annoying that both ways work
16:26	<Lachy>	it doesn't appear to work when I look at the page.
16:26	<Lachy>	it's showing up literally as: "it seems to refer to <a href="http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8">captions overlayed on top of the image</a> ..."
16:29	<Lachy>	that's quite a well written rationale.
16:31	<othermaciej>	all right, hang on
16:32	<Lachy>	TabAtkins, "All HTML elements may have the caption content attribute set" is directly contradicted by "The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."
16:32	<TabAtkins>	No it's not. All elements may have it set. However, they must be in that particular context.
16:33	<Lachy>	there are elemnets like <html>, <body>, etc. would never be allowed to have it, cause they can't be children of figure
16:33	<TabAtkins>	Ah, got you.
16:33	<othermaciej>	Lachy: addressed both those comments
16:34	<Lachy>	you probably want to say it can be on any element in the Flow Content category
16:34	<TabAtkins>	Thanks, I was just about to ask if I should say something about flow content elements.
16:37	<Lachy>	othermaciej, it still doesn't quite read correctly, becuase the subject from the previous sentence is the fcaption and dlabel elements, rather than figure and details. It might be better to say:
16:37	<Lachy>	"The content portions of the figure and details elements would not have any special markup, it would be nested directly inside them."
16:37	<Lachy>	hmm, still doesn't quite work
16:39	<Lachy>	maybe "The content portions of the figure and details elements would not have any specialised markup; any other flow content may be used"
16:39	<Lachy>	othermaciej, btw, I'm considering raising an objection to the 2d canvas api split. But I haven't had time to review the changes that were made and what impact it has had
16:40	<othermaciej>	Lachy: it would be within your rights to escalate it then, if you decide to object
16:40	<Lachy>	I recall there were good arguments against doing so back when the issue was heavily discussed on the list
16:40	<Lachy>	I will have to look those up later
16:42	<Lachy>	othermaciej, what would be an acceptable process for getting microdata reinstated? I assume I would have to wait for new information, such as new implementations and evidence of adoption by developers to reopen the issue
16:43	<daedb>	TabAtkins: If caption can be on any flow content element, wouldn't <figure><img><style scoped caption></style></figure> be valid? That would be kinda weird :)
16:43	<othermaciej>	Lachy: the Working Group Decision gave specific examples of what kinds of new information might be a sound basis for re-raising the issue
16:43	<Lachy>	oh, ok. I don't recall seeing anything mentioned about that. I'll take another look
16:45	<TabAtkins>	daedb: Weird, yes. Worth worrying about? I dunno.
16:45	<TabAtkins>	I don't know if there is a categorization that captures "every element that you use to present content of some sort".
16:50	<daedb>	oh, video is flow content... I could have images in figures with video captions :D
16:50	<Lachy>	TabAtkins, that's a problem with your proposal you will have to sort out
16:50	<Lachy>	it's one of the reasons I don't particularly like it
16:50	<TabAtkins>	deadb: Yes, yes you can.
16:50	<othermaciej>	Lachy: oh man, I'd been ignoring that thread in the hopes that there wasn't anything relevant (re queryScopedSelector)
16:50	<jgraham>	othermaciej: (fwiw I would object to the canvas api split if it weren't for the WHATWG copy of the spec. However assuming logic is applied consistently there microdata decision sets precedent for everything that is not in HTML4 to be split out of HTML5, so I would be surprised if such an objection were not futile)
16:50	<Lachy>	since there's no clear, inuitive subset of elements that it makes sense on
16:51	<jgraham>	s/there/the/
16:51	<TabAtkins>	Lachy: There is a clear, intuitive subset. That subset just isn't currently labelled in HTML.
16:51	<othermaciej>	jgraham: I don't think the microdata decision "sets precedent for everything that is not in HTML4 to be split out of HTML5"
16:52	<othermaciej>	jgraham: I do think there are some valid arguments for splitting the canvas API, and even Hixie has agreed at various points in time that it was good in principle to do so, though he didn't have time
16:52	<othermaciej>	now, apparently, he has time
16:53	<jgraham>	othermaciej: If "limited success in the marketplace" is a sufficient reason for splitting, it follows that anything new could be split
16:54	<jgraham>	othermaciej: e.g. I would expect the same argument to hold if someone asked for <video> to be split
16:55	<othermaciej>	jgraham: the Working Group Decision only said that all of those arguments are effective in combination (in particular with the "don't pick winners" argument) and really only as they apply to the facts of Microdata
16:56	<othermaciej>	jgraham: also, <video> clearly has a lot more traction than Microdata at present - it has multiple client-side implementations and sites (including some prominent sites like daringfireball.net and youtube.com) using it in production or as a future technology demo
16:56	<othermaciej>	jgraham: do you really sincerely think that <video> and Microdata have equivalent levels of adoption? (let alone of potentially competing alternatives)
16:57	<TabAtkins>	Heh, <video> definitely has an extremely popular and well-entrenched alternative - Flash embedded video.
16:58	<jgraham>	othermaciej: If <video> disappeared tommorrow, hardly anyone would notice. Almost no-one is using <video> on a day-to-day basis.
16:58	<jgraham>	(I note in passing that the critria of reusability in other specifications would also apply equally well to <video>)
16:58	<jgraham>	(perhaps better)
17:07	<cardona507>	I'm pretty sure that if <video> disappeared tomorrow people would know - there seems to be quite a buzz for <audio> & <video>
17:08	<othermaciej>	jgraham: people have had whole conferences about how to use <video>
17:09	<othermaciej>	TabAtkins: I think a proprietary competing technology is not quite the same thing as a competing standard
17:09	<TabAtkins>	A valid critique.
17:09	<othermaciej>	it arguably is the W3C's place to pick a winner between standards-based and proprietary solutions
17:09	<cardona507>	when I mention HTML5 in html/css class <audio> & <video> often get the most and easiest "wow"
17:10	<othermaciej>	that being said,
17:10	<AryehGregor>	Almost no users would notice, web developers would notice.
17:10	<AryehGregor>	If video died.
17:11	<othermaciej>	I think the point is moot if no one actually asks for <video> to be removed
17:11	<AryehGregor>	It's clear that a lot of the opposition to Microdata was because it had a standards-based competitor that some people liked more.
17:11	<AryehGregor>	That doesn't apply to any (?) other new feature in HTML5.
17:11	<AryehGregor>	Although, some people also feel really strongly about how big specs should be, too.
17:11	AryehGregor	shrugs
17:14	<jgraham>	If that was the reason for the decision it would have been nice if it was just stated. Then it would be clear that it didn't apply to other things
17:16	<AryehGregor>	It was mentioned in some fashion, wasn't it?
17:16	<foolip>	well, at least it was obvious that it was the actual reason to all involved
17:17	<jgraham>	AryehGregor: It was mentioend in the discusion but not actually given as the reason
17:18	<jgraham>	s/the/a/
17:31	<othermaciej>	jgraham: "Many of the objections balance out. But, in some areas, keeping Microdata would draw stronger objections than splitting it. The objections based on maturity, market success, and reusability in other languages are stronger than their respective counterpoints. In light of these other arguments, the objections to picking a winner in this case are stronger than the objections to not doing so. The objections to picking either RDF
17:31	<othermaciej>	Microdata as a winner were stronger, on the whole, than the objections to letting them compete on an equal footing."
17:32	<othermaciej>	jgraham: the "pick a winner" argument is clearly stated in the Short Summary and given a lot of prominence both there and in the longer discussion
17:34	<Dashiva>	But it wasn't picking. RDFa didn't want to be in HTML5 at all.
17:35	<Lachy>	othermaciej, the problem I have with that statement is that splitting it out does not really let them compete on an equal footing. Instead, it forces the Microdata proponents to adapt to a new way of developing the spec that they're not particularly comfortable with
17:35	<othermaciej>	Dashiva: you could debate whether the reasoning provided by commentors was valid, but what we're discussing now is whether it "sets precedent for everything that is not in HTML4 to be split out of HTML5, so I would be surprised if such an objection were not futile)"
17:35	<othermaciej>	which I think is not the case
17:36	<jgraham>	othermaciej: Fair enough. To me the list of three arguments is the essence of the summary
17:36	<Lachy>	That would have been my argument against the split, but since I was on holidays at the time the poll was called and didn't really have time, I missed out on contributing
17:38	<othermaciej>	jgraham: the chairs intended it somewhat the other way around, so apologies if the summary gave the wrong impression
17:38	<othermaciej>	jgraham: I think if you read the detailed reasoning, I think it is more clear
17:40	<othermaciej>	anyway, I don't really want to revisit this issue to death (better to move on), but I did want to note that it does not mean every other proposed split or removal is an automatic winner
17:40	<jgraham>	So given an arbitary part of the spec to which one can apply all three arguments with the same level of conviction as with microdata, it would not necessarilly be split out if someone requested that unless there was another W3C spec in the same space?
17:40	<Dashiva>	othermaciej: So you're saying that a contentious (if not outright invalid) argument was the real decider
17:40	<AryehGregor>	It's good you didn't say that, because if you did then someone would have proposed splitting <span> to its own spec.
17:41	<othermaciej>	Dashiva: really it was the combination of all four facors with the real decider
17:41	<AryehGregor>	Come on, people, this is politics, let's just drop it and move on to something else, hopefully non-editorial.
17:41	<othermaciej>	s/with/which was/
17:41	<AryehGregor>	Although it looks like we still have lots more editorial stuff to argue about.
17:41	<Dashiva>	AryehGregor: I'm not sure if you've noticed, Shelley has filed close to a dozen new issues already
17:41	<Dashiva>	This isn't going away any time soon
17:42	<AryehGregor>	Yes, Shelley is why we still have lots more editorial stuff to argue about.
17:42	<othermaciej>	jgraham: if someone could show that all the arguments applied equally to some other section, that would likely be precedent for a split
17:42	<othermaciej>	jgraham: likewise that the balance did not fall the other way on any other arguments
17:42	<Dashiva>	Besides, doesn't SMIL pretty much fill RDFa's role when it comes to <video> and choosing a winner? :)
17:42	<AryehGregor>	I think it's become pretty clear that making a WG where any random person from the Internet can trigger lengthy bureaucratic processes over anything they disagree with is a bad idea.
17:43	<AryehGregor>	Normally WGs (including W3C WGs and the WHATWG) are made up of a small number of people, mostly paid by interested organizations, which typically have a direct interest in progressing the spec.
17:43	<AryehGregor>	And anyone else can comment, but can be ignored out of hand if the actual members disagree.
17:43	<othermaciej>	if Shelley overuses the process then I expect the Chairs will take some action to keep it from turning into a DOS attack
17:43	AryehGregor	can't wait.
17:43	<Dashiva>	So you're saying she isn't overusing it yet?
17:44	<AryehGregor>	Dashiva, don't you remember what Hixie said? The chairs can't decide anything except on Tuesdays. :)
17:44	<Dashiva>	Yeah, yeah
17:44	<Dashiva>	It's a shame othermaciej has to be the messenger here
17:45	<othermaciej>	she's got 9 issues open out of the total 35 by my count
17:45	<othermaciej>	wait, 11
17:45	<othermaciej>	but ISSUE-76 should be closed
17:45	<AryehGregor>	Impressive.
17:46	<Dashiva>	And she opened, what, 7 of them the last two days?
17:46	<othermaciej>	10/34 is a somewhat suspiciously high number
17:47	<othermaciej>	I am looking for two more pieces of information before I decide whether it is a problem:
17:47	<AryehGregor>	What is it if you count all issues, not just open ones?
17:47	<othermaciej>	1) will she end up pursuing all of these as Change Proposals? (doesn't cost the group much time if the issue gets closed without prejudice)
17:48	<Dashiva>	AryehGregor: Less than 20%, by my estimate
17:48	<othermaciej>	2) what proportion of these issues end up being things that anyone but Shelley agrees with? (if any of them really represent the WG view, then it's not a waste of tiem)
17:48	<othermaciej>	3) how many other issues will we get out of the recent batch of bug closures?
17:48	<othermaciej>	we have 4 sitting there with TrackerRequest
17:48	<TabAtkins>	There are 90-something issues, and most of them came about before Shelly went on her issue-spree, so most of them won't be hers.
17:48	<othermaciej>	and probably more that people have not looked yet
17:49	<othermaciej>	I believe there are 98 total and at least 12 are hers
17:50	<othermaciej>	for example if someone makes a Change Proposal and there is clearly not significant support for it, the chairs can just put forth a CfC to reject it instead of a call for counter-proposals
17:51	<othermaciej>	not saying we will actually do that in any particular case but people should consider that before filing potentially frivolous issues
17:51	<webben>	What was the reason every Change Proposal has counter-proposals again?
17:52	<webben>	Why can't you just have a Change Proposal and solicit objections?
17:52	<TabAtkins>	Mostly, to group the objections together.
17:52	<Dashiva>	That's basically what a counter-proposal is
17:52	<othermaciej>	originally our intent was just to do it for old issues where there is no prior rationale from the editor
17:52	<Dashiva>	"Proposal: Change nothing. Rational: ..."
17:52	<othermaciej>	but I think it works better than just collecting objections by email
17:52	<Dashiva>	*Rationale
17:52	<webben>	Dashiva: Yeah, but with microdata you had a counter-proposal, a proposal and then a load of objections to both on top.
17:52	<othermaciej>	what is the right wiki syntax for a bulleted list?
17:53	<Dashiva>	*
17:53	<Dashiva>	No empty lines between items
17:54	<webben>	Dashiva: Since the chairs needed to read all the objections anyway, I don't see the point.
17:54	<othermaciej>	my problem was leading spaces
17:54	<othermaciej>	fixt
17:55	<othermaciej>	webben: reading both Change Proposals plus the poll responses was way less work than reading every single mailing list response would have been
17:55	<webben>	othermaciej: But was it less work than reading a Change Proposal + poll responses would have been?
17:56	<othermaciej>	webben: it helped focus the key arguments
17:57	<webben>	Fair enough.
17:57	<othermaciej>	webben: we tried to look at the poll responses by how they related to one proposal or the other's rationale
17:57	<webben>	If it works, it works :)
20:33	<cardona507>	Firefox 3.6 release candidate out with support for the HTML5 File API - nice
20:35	<cardona507>	ohhh - it looks like there are all kinds of goodies in Firefox 3.6 :)
20:38	<miketaylr>	i think <input type=file multiple> as well
20:52	<AryehGregor>	"Heck, even my cat has her own domain name."
21:09	<TabAtkins>	Hrm. This is an interesting border-radius bug. Never seen it before.
21:12	<TabAtkins>	Ah, never mind. It's a repainting issue.
21:16	<othermaciej>	I'm so persuaded by my rationale for Proposl 3 that I'm not sure I can bring myself to write any others
21:16	<TabAtkins>	Haha.
21:17	<othermaciej>	(the only other one I might do at this point is Proposal 4, but I don't know if I will)
21:17	<othermaciej>	and I still have to write the remaining bits of Proposal 3
21:18	<TabAtkins>	I have to say that Proposal 4 is my favorite.
21:18	<TabAtkins>	Dang, I mean 3.
21:18	<TabAtkins>	Followed by 6, then 2 and 4 equally.
21:18	<jgraham>	pointer?
21:18	<othermaciej>	ah, I was gonna say
21:18	<othermaciej>	jgraham: http://wiki.whatwg.org/wiki/Change_Proposal:_figure_and_details
21:19	<Lachy>	we should just go ahead and call the spec "HTML Microdata", since we're basically trying to move away from versioning. Leif's seems like hte easiest objection ever to get withdrawn
21:19	<othermaciej>	TabAtkins: 4 is the hardest to write, because it requires parser changes
21:19	<TabAtkins>	As opposed to 1?
21:19	<othermaciej>	the parser changes for 1 are already in the spec
21:19	<TabAtkins>	Ah, right. Commented out.
21:19	<TabAtkins>	I don't wanna write 4, then.
21:20	<othermaciej>	oh really? I thought it still had the parsing change for <legend> still in
21:20	<TabAtkins>	Eh, maybe. Hopefully so, actually.
21:20	<othermaciej>	I will consider writing 4 if it seems likely to be anyone's favorite
21:20	<othermaciej>	but describing changes to the parsing algorithm in detail is not my idea of a fun time
21:21	<TabAtkins>	And I don't understand the parsing algorithm sufficiently well to write it at all.
21:21	<Lachy>	I think we should give up on proposal 4. If the caption element could be salvaged in any way, we would have done it when the parsing algorithm was written. I find it highly unlikely that any proposal for it would work in practice
21:21	<Lachy>	also, we'd be stuck with the legacy for many years to come
21:22	<TabAtkins>	We should drop 1 in that case as well. It has equivalent problems, it's just easier to write a change proposal for.
21:22	<Lachy>	yeah, the problems with 1 were the whole reason we got where we are today. I don't think it will go over well with the community
21:23	<Lachy>	though, IMHO, legend is the second best alternative to introducing a new element
21:24	<Lachy>	at this stage, now that I've read the rationale behind it, I think 3 sounds the most promising. The names aren't ideal, but they're not overly bad
21:24	<jgraham>	Did I already mention that I find fcaption and dlabel mysterious names
21:24	<TabAtkins>	The parallel to the naming of <table>'s sub-elements is nice, at least.
21:25	<jgraham>	figcaption (like optgroup) would be better for the figure one imho
21:25	<TabAtkins>	jgraham: Are they any more mysterious than thead, if you discount your existing familiarity?
21:26	<jgraham>	TabAtkins: It is hard to discount my existing familiarity
21:26	<TabAtkins>	True. Rationally, then, are they any more mysterious?
21:26	<jgraham>	But <thead>, <tbody>, etc. are basically never used whereas <figcaption> would be used for every single <figure>
21:27	<TabAtkins>	<tr> and <td> are used on every table, though.
21:27	<TabAtkins>	Though their commonality may be sufficient justication by itself for their short names.
21:27	<TabAtkins>	Simply from a bandwidth pov.
21:27	<TabAtkins>	(network and finger-based)
21:28	<jgraham>	But that is OK because both parts are abbreviated and the structure is such that you want short names more than you want readability
21:29	<TabAtkins>	Is <figcaption> sufficiently better than <figurecaption> to justify the shortening? Is the parallel to <optgroup> strong enough to justify it?
21:29	<jgraham>	<figcaption> feels a lot shorter and using fig. as an abbreviation of figure is rather common
21:29	<TabAtkins>	True.
21:30	<TabAtkins>	Is there any parallel name for <dlable> that feels natural?
21:30	<TabAtkins>	s/dlable/dlabel/
21:31	<jgraham>	Maybe <summary> but it is not quite right and doesn't capture the labelness if that is how we expect it to be used
21:31	<TabAtkins>	Yeah, that sounds odd to me.
21:32	<jgraham>	(It is not clear to me if people will do things like <details><dlabel>[lots of contnet here]</dlabel>[more content here]</details>
21:32	<TabAtkins>	The clickability parallel with form labels is nice enough that I want to keep "label" in it.
21:32	<jgraham>	(The other possible pattern is <details>label<expansion></expansion></details>
21:32	<jgraham>	)
21:33	<TabAtkins>	<content>?
21:33	<TabAtkins>	That makes it too easy to do <details>foo<content>bar</content>baz</details>. Of course, that might still be good...
21:33	<jgraham>	No, we might want that as a parallel to <header> et. al. one day
21:33	<TabAtkins>	But I think that most commonly it's the label that will be styled specially, so it's best to make that have the wrapper.
21:34	<jgraham>	I think it is also common to want the expansion to have a special style e.g. some extra margin
21:35	<othermaciej>	jgraham: I wouldn't have a problem with tweaking the proposal to <figcaption> or <figurecaption> instead of <fcaption> if that is truly more popular, and if there is a good similar change for <label>
21:35	<othermaciej>	er, good similar change for <details>
21:35	<TabAtkins>	jgraham: Agreed, and that's why I'm still honestly fine with <dt>/<dd> for details.
21:36	<othermaciej>	but I do think names for specialized child elements often have either no prefix or an abbreviated prefix and rarely have a full-word prefix
21:36	<jgraham>	My feat with <dlabel> is just that; people will write <label> by mistake when they mean <dlabel>
21:36	<jgraham>	*fear
21:36	<othermaciej>	well I'd just propose <label> if I thought it would fly :-)
21:36	<othermaciej>	but the fact that using <label> will result in none of your content showing up should be a good enough signal to limit that error
21:36	<TabAtkins>	Well, <label> doesn't have parsing problems. You'll just be prevented from embedding form controls in the details label until browsers know to treat it differently.
21:37	<daedb>	<figurecaption> is too long imo. I'd prefer <fcaption> over <figcaption> for length reasons too, but I could live with both.
21:37	<jgraham>	Embedding form controls in the details label seems like it is a valid use case though
21:38	<TabAtkins>	I agree, but it's a less drastic problem than parsing issues.
21:38	<othermaciej>	in particular you are much less likely to want a form control inside the <details> label than in a figure caption
21:39	<othermaciej>	the way it is used on Mac OS X, it pretty much never contains controls
21:39	<daedb>	Really? I expect form controls in <details> to be quite common.
21:39	<jgraham>	Yes but Web developers on't have to conform with the apple HIG :)
21:40	<othermaciej>	daedb: in <details>, yes, in the label part, no
21:40	<Lachy>	the name <content> is out anyway, since it clashes with XBL, and it was already considered and rejected when we were discussing the idea of introducing a content wrapper for section elements
21:40	<jgraham>	(I can imagine something where you have a list of checkboxes, each of which is a details control that allows you to set more advanced options for that item. Not great UI perhaps but the sort of thing that seems plausible)
21:40	<Dashiva>	othermaciej: Were you smiling to yourself when you wrote "touch base" in that email? :)
21:41	<TabAtkins>	Heh, I was just typing up that precisely, jgraham.
21:41	<othermaciej>	Dashiva: why would I be?
21:41	<othermaciej>	jgraham: I guess that is plausible
21:41	<daedb>	othermaciej: oh, I was just thinking in general, not just for the label... oops :)
21:42	<othermaciej>	so is anyone here a big fan of 1, 2, 4 or 5?
21:42	<Dashiva>	To me it's too cliche to consider seriously
21:42	<TabAtkins>	I'm sort of a2 fan, but that's all.
21:42	<othermaciej>	also, would it be a good thing to mention this wiki page on the HTML WG, in case any other WG participants would like to fill in the details for any of those?
21:42	<daedb>	I like the shortness of <c> in 2.
21:42	<othermaciej>	or otherwise share our rationale
21:43	<Lachy>	<label> was rejected for use within <figure> since it clashes with form control labels. Perhaps the fact that it needs to be first in <details> would be enough to make the distincition.
21:43	<TabAtkins>	yeah, i think so, othermaciej
21:43	<jgraham>	othermaciej: No, I would happily throw them all out :)
21:44	<othermaciej>	Lachy: it also seemed to me that using form controls legitimately in the figure caption might be more likely, but I'm not as sure now
21:44	<daedb>	I like 2 and 3 the most, then 6... don't care about the rest.
21:44	<othermaciej>	jgraham: do you like the way the spec is now best?
21:44	<othermaciej>	so far no one seems willing to write the UnChante Proposal for this issue
21:44	<Lachy>	I think 4 and 5 should be dropped
21:44	<jgraham>	othermaciej: No, I like 3
21:45	<jgraham>	But with slightly different names
21:45	<jgraham>	(I wasn't clear by "all" I meant "all the ones you listed")
21:45	<othermaciej>	Lachy: would it be ok to post a link to this page on public-html? Maybe someone there will want to champion one of those
21:45	<Lachy>	My order of prefence for the others is: 2 and 3, followed by 1, followed by 6.
21:45	<Lachy>	sure, it's a public wiki. Go ahread.
21:45	<Lachy>	*ahead
21:46	<Lachy>	othermaciej, what's the "UnChante Proposal"?
21:47	<othermaciej>	I meant to say UnChange
21:47	<Lachy>	oh
21:47	<othermaciej>	i.e. in favor of the status quo
21:47	<Lachy>	yeah, the status quo can't really be defended
21:47	<TabAtkins>	I wanna write UnChange for <details>. Leaving it as <dt>/<dd> is still my personal favorite.
21:47	<Dashiva>	So now HTML Microdata vs HTML5 Microdata is also a matter of picking winners... joy
21:48	<TabAtkins>	Just because I'll virtually always be styling both the label and the content, and it's the only one with a pair of elements.
21:48	<Lachy>	in that case, we should split proposal 3 into two. One for figure and one for details
21:48	<othermaciej>	proposal 3 could have a variant with elements for both the body and contents
21:48	<TabAtkins>	I'd be happy with that.
21:49	<othermaciej>	how would you style the body and exclude the label under proposal 3?
21:49	<TabAtkins>	<figbody> and <dbody>!
21:49	<othermaciej>	I'm not sure figbody/fbody is as useful as dbody
21:49	<jgraham>	I was about to say <dhead> and <dbody>. I thought Lachy would like that :)
21:49	<Lachy>	or, maybe it's not necessary to split 3, if the poll clearly separates the questions for figure and details. (just make it clear that a vote for proposal 3 for one of them doesn't imply a vote for the other too
21:50	<TabAtkins>	You kidding? I'll often be wanting some padding on my figbody, but not on my figcaption.
21:50	<daedb>	I don't want a <figbody>, it's unnecessary wrapping.
21:50	<othermaciej>	you could have a rule for details > :not(dlabel) { .. }
21:50	<othermaciej>	agreed that is a bit mysterious
21:50	<Lachy>	if you want to style the content, then we don't need a specialised element. Use <div>, possibly with a class
21:50	<TabAtkins>	Doesn't work with padding, unless you are very careful with your selectors and break up the padding rule.
21:50	<daedb>	If I want an extra styling hook I'll just throw in a <div> or something.
21:51	<TabAtkins>	Bah. I just feel bad putting in extra divs.
21:51	<othermaciej>	Lachy: I am hoping that with some discussion, we might be able to get down to a clear crowd favorite and settle this without a poll
21:51	<Lachy>	there's no semantic we really need to convey with it
21:51	<othermaciej>	TabAtkins: oh, I see, you want to style the body as a unit
21:51	<Lachy>	TabAtkins, btw, I still object to dt/dd for details for the compatibility hacks required for it
21:51	<othermaciej>	TabAtkins: you could always add a div with a unique class
21:52	<othermaciej>	TabAtkins: since the element is only needed as a styling hook, and not for semantics or the UA's use
21:52	<TabAtkins>	Then again, if I go suggest in a while the idea Hixie and I were discussing, I could just write ::wrap(dlabel+*), and get a pseudoelement wrapping everything below the dlabel.
21:52	<Lachy>	oh, that's a nice idea
21:53	<Lachy>	would it wrap all groups of consecutive elements that match the selector?
21:53	<TabAtkins>	(The idea is that you could specify one or two selectors, detailing the first and after-the-last element.)
21:53	<daedb>	::wrap(dlabel~*)?
21:54	<TabAtkins>	So, frex, to get a section pseudo (when using implicit sectioning), ::wrap(h1,h1) would do it. Similarly ::wrap(h2,:matches(h1,h2)) for the lower ones. Though that should probably be a built-in pseudo anyway.
21:56	<Lachy>	TabAtkins, that wouldn't quite work if you described it properly, since the second h1 would be wrapped by the pseudo-section, where as you likely want the wrap to stop before it
21:56	<TabAtkins>	No, the second selector picks the after-the-end element.
21:56	<Lachy>	also, you'd end up with weird overlapping wraps
21:56	<TabAtkins>	So it would, indeed, stop just before the next h1.
21:56	<Lachy>	oh. I misunderstand what you meant by after-the-end
21:56	<TabAtkins>	Np. I'll be more precise when I actually suggest it.
21:57	<Lachy>	I though you meant the wrap would begin at the start element and then continue until the end element, inclusive
21:57	<TabAtkins>	That's what I thought at first, but it's overly hard to specify the end properly in a lot of common cases.
21:58	<TabAtkins>	While with this, you can either specify after-the-end, or if you have an easy way to refer to the last element that should be in the group, just give "elem + *" as the second selector.
21:59	<TabAtkins>	And, obviously, specifying only one selector like I did for the dlabel bit means that it should envelop all following siblings of the selected element.
22:01	<TabAtkins>	There's just some oddities with being able to specify overlapping ::wrap()s that I need to resolve, probably in whatever way we decide to resolve overlapping ::text()s.
22:02	<othermaciej>	I added Proposal 7
22:02	<othermaciej>	(variant of 3 that adds special elements for the body parts)
22:03	<TabAtkins>	I changed it to specify optional on both of them.
22:05	<othermaciej>	TabAtkins: works4me
22:05	<Lachy>	haha, I just noticed that in the current WebApps WG charter, selectors api is scheduled to reach rec in the year 20089. http://www.w3.org/2008/webapps/charter/#deliverables
22:05	<othermaciej>	TabAtkins: after all, <tbody> is optional
22:05	<TabAtkins>	Haha.
22:05	<Lachy>	somehow, I don't think the internet will still be around in 18,000 yeras
22:05	<othermaciej>	Lachy: you slacker!
22:05	<TabAtkins>	othermaciej: Exactly.
22:05	<Dashiva>	Lachy: Oh ye of little faith
22:30	<Hixie>	othermaciej: i believe at the time the 2d split was first suggested, i didn't have anything like my current spec gen infrastructure
22:30	<Hixie>	it is in fact relatively easy for me to carve specific chapters out now
22:31	<Hixie>	(though it is harder than ever to make invasive splits)
22:32	<othermaciej>	Hixie: that is good
22:32	<othermaciej>	Hixie: I reopened http://www.w3.org/Bugs/Public/show_bug.cgi?id=7386 , see what you think of my reasoning
22:35	<Philip`>	If a new editor was found for one of the split-out sections, how would that work with the current spec gen infrastructure?
22:36	<Philip`>	Would it be necessary for them to extract it into a separate source document, or would they edit the same source document in SVN, or something?
22:38	<Hixie>	we'd just do what we did with xhr
22:52	<Lachy>	Hixie, with the 2d context split, it seems this requirement is no longer present in either W3C HTML5 or the 2D context specs: 'This specification only defines one context, with the name "2d". If getContext() is called with that exact string for its contextId argument, then the UA must return a reference to an object implementing CanvasRenderingContext2D.'
22:53	<Hixie>	it's still there, just in different words
22:53	<Lachy>	ok
22:53	<Lachy>	oh, I see. It's repeated here "When the getContext() method of a canvas element is invoked with 2d as the argument, a CanvasRenderingContext2D object is returned."
22:54	<Lachy>	making that first one redundant, since the latter is present in all copies
22:54	<Lachy>	it would be less confusing if the differences between the split specs and the full specs were kept to a minimum
22:55	<Hixie>	the latter isn't a conformance requirement
22:55	<Hixie>	and yes, the changes are kept to a minimum
22:55	<Lachy>	oh, then I can't see where the equivalent conformance requirement is
22:56	<Lachy>	but the latter does come from the Conformance Requirements section
22:56	<Hixie>	paragraphs 2 and 3 of http://dev.w3.org/html5/2dcontext/Overview.html#conformance-requirements
22:56	<Lachy>	that's what I quoted
22:56	<Hixie>	no
22:56	<Hixie>	you quoted the whatwg version
22:56	<Hixie>	which says "is"
22:56	<Hixie>	the w3c version says "must be"
22:56	<Hixie>	like i said, i'm keeping the changes to a minimum :-)
22:57	<Lachy>	ah. I didn't notice the difference in the 2 sentences
22:58	<Lachy>	then I take that back. Please keep the differences to a maximum to avoid further confusions like that caused by such subtle differences :-)
22:58	<Hixie>	hah
23:09	<AryehGregor>	TabAtkins, your selector would tend to misnest. I don't see any way you could sensibly define things like padding in general if you have <table><th><h1>...</h1>...</table><p>...<h1>...</h1> and you try to wrap everything between the h1's.
23:09	<AryehGregor>	Also, foo + * won't work if foo is the last child of its parent.
23:09	<TabAtkins>	I'm confused by your first statement, Aryeh.
23:09	<TabAtkins>	And yes it will - at most, it will wrap to the end of its parent.
23:10	<TabAtkins>	Oh, wait, now I see what you mean.
23:10	<AryehGregor>	TabAtkins, take my HTML snippet. What does ::wrap(h1, h1) { padding: 1em } do? What box gets the padding? Your ::wrap includes some children of one block, then a sibling of that block.
23:10	<TabAtkins>	Nah, it explicitly doesn't jump between generation boundaries. (I didn't state that before, but it's part of the proposal in my head.)
23:11	<AryehGregor>	So in this case it would do nothing.
23:11	<AryehGregor>	Because we have <th><h1>...</h1></th>.
23:11	<AryehGregor>	It would just select the h1.
23:11	<TabAtkins>	Yes, it would wrap the <h1> only there.
23:11	<AryehGregor>	And foo + * just won't match anything if foo has no next sibling, as a normal selector.
23:12	<AryehGregor>	I assume ::wrap(squozzle, fooble) wraps nothing if there's no fooble element in the document.
23:12	<TabAtkins>	But if you had <h1>foo</h1><table><th><h1>bar</h1></table><h1>baz</h1>, it would generate two wrapping pseudos at the top level, and one inside the th
23:12	<AryehGregor>	That sounds unexpected.
23:12	<TabAtkins>	The foo+* where foo has no next sibling works as expected - if the second selector is missing or matches nothing, it just wraps to the end of the first selector's parent box.
23:12	AryehGregor	has thought about this problem a bit for MediaWiki, from the perspective of auto-adding divs around sections, but it's pretty hairy if there's any nesting
23:12	<AryehGregor>	Ah, I see.
23:12	<TabAtkins>	And yes, ::wrap(sqozzle, fooble) wouldn't do anything.
23:13	<TabAtkins>	The first selector has to match something for it to work at all.
23:13	<AryehGregor>	Wait, wouldn't ::wrap(squozzle, fooble) wrap around each squozzle element and all its subsequent siblings, if there's no fooble element?
23:13	<TabAtkins>	Yes.
23:13	<AryehGregor>	I think I get it now, then.
23:13	<TabAtkins>	kk
23:13	<AryehGregor>	It will break horribly if you have any kind of nesting, but oh well.
23:14	<TabAtkins>	It won't break. It just won't generate pseudos like you expect.
23:15	<TabAtkins>	The main problem is this: <b>foo</b> <i>bar</i> <b>baz</b> <i>qux</i>, ::wrap(b,b) {} ::wrap(i,i) {}
23:15	<TabAtkins>	That'll attempt to create overlapping wrapping pseudos, which is no good.
23:15	<AryehGregor>	That's a much bigger problem, yes.
23:15	<TabAtkins>	But I believe that we can resolve this with whatever we decide is appropriate for the same situation in the ::text() pseudo.
23:15	<AryehGregor>	I got the impression ::text() wasn't going anywhere.
23:16	<TabAtkins>	Nah, I'll be revisiting it in a bit. I'm pretty attached to the functionality.
23:16	<TabAtkins>	And the two authors of the group (me and Brad) both feel very strongly about it, so as long as we can get the implementors to grudgingly accept it, we should be golden.
23:16	<TabAtkins>	That just involves resolving all the ambiguities, and ensuring that it's not too expensive to match.
23:17	<TabAtkins>	"just"
23:19	<AryehGregor>	I think the point that it ties together style and content too tightly is pretty compelling.
23:19	<TabAtkins>	I think the argument that simple page transformations are unreasonably useful is pretty compelling. ^_^
23:20	<TabAtkins>	::text does indeed tie to content pretty tightly, but the current solution, where you wrap the content in <span>s according to the styling you want, is just as bad, it's just putting the problem in the HTML rather than the CSS.
23:20	<TabAtkins>	::wrap wouldn't be as tightly tied, since at least it just selects on the same things as normal CSS.
23:23	<TabAtkins>	The fact is, there simply isn't a generic declarative solution for complex prettifying of arbitrary content short of AI, and I think we're still pretty far from "page-style: make-it-pretty;".
23:23	<TabAtkins>	So style is fated to intertwine with content at least somewhat in some situations, just as behavior twines with content and style in js.
23:24	<TabAtkins>	Heh, page-visual-template: url(foo.pdf);
23:28	<Lachy>	TabAtkins, what's this page-visual-template property?
23:28	<TabAtkins>	A pretend property implemented by AI, which takes a pdf and styles the page accordingly.
23:28	<Lachy>	oh.
23:29	<cardona507>	interesting
23:29	<Lachy>	I think what you're looking for is: html { content: url(design.png); }
23:30	<TabAtkins>	Nah, that's clearly not good for user interaction.
23:31	<Lachy>	fine then. binding: url(layout.xbl);
23:31	<TabAtkins>	But then I can't just hand it a file created by Advertising!
23:31	<TabAtkins>	Those people definitely won't know how to create xbl.
23:31	<Lachy>	oh, you poor lazy web developer ;-P
23:31	<TabAtkins>	Nope, I need an AI which will look at the page, match it with my content, and automagically do everything for me.
23:32	<cardona507>	heh
23:32	<TabAtkins>	But it needs to be a secret so I can still charge for 8 hours of work.
23:36	<AryehGregor>	That's always the tricky part.
23:36	<AryehGregor>	On the other hand, if we have AI like that, maybe we can all retire and have robots do everything for us.
23:36	<TabAtkins>	Sounds good to me.
23:37	TabAtkins	is waiting for scarcity economics to die.
23:38	<Lachy>	TabAtkins, what's scarcity economics?
23:38	<TabAtkins>	Economics founded on scarcity. Essentially, nearly all of economics before the digital age.
23:38	<TabAtkins>	Anything where there is a limited quantity of product, such that you have to limit it.
23:39	<Lachy>	scarcity of phyical products is just reality. But, yeah, for digital, I agree, artificial scarcity is harmful
23:39	<TabAtkins>	When you have essentially infinite product (or similarly, when duplicating a product is essentially free), everyone benefits.
23:39	<cardona507>	free - chris anderson
23:39	<Lachy>	huh?
23:39	<TabAtkins>	Eh. With matter printers we'd reduce physical scarcity to whatever raw materials the printer needed.
23:39	<Lachy>	who is Chris Anderson?
23:40	<AryehGregor>	Universal constructors!
23:40	<AryehGregor>	Nanorobots!
23:40	<Lachy>	TabAtkins, you mean the Star Trek Replicators?
23:40	<TabAtkins>	Sure, whatever mechanic ended up being used for them.
23:40	<TabAtkins>	Lachy: Basically yeah.
23:40	<cardona507>	lachy http://www.youtube.com/watch?v=rPJuoziJaE4
23:41	<cardona507>	lachy - the editor in chief of wired - and the author of "the long tail" & "free"
23:44	<Lachy>	I hate watching long videos on YouTube. Is that video downloadable from elsewhere?
23:44	<Lachy>	actually, I'll use miro to get it from YT
23:45	<othermaciej>	I finished fleshing out proposal 3
23:46	<othermaciej>	if anyone would like to review, comments would be appreciated
23:46	<othermaciej>	I guess everything I wrote about equally applies to 3b
23:46	<othermaciej>	and almost all of it applies to 7
23:47	<othermaciej>	though you would have to strike "Does Not Introduce Redundant Elements for the Content" and justify "Adds Helpful Optional Elements for the Content"
23:50	<Lachy>	othermaciej, should the content model of details say "preceded or followed by a dlabel element?" Shouldn't it be preceded only?
23:51	<othermaciej>	Lachy: let me check what the spec says now
23:51	<TabAtkins>	othermaciej: You have to escape all your html - there's one spot where a tag is clearly missing.
23:51	<Lachy>	it says one dt followed by dd
23:51	<Lachy>	so the label must come first
23:51	<TabAtkins>	second paragraph of Impact.
23:51	<othermaciej>	Lachy: and it requires both?
23:51	<othermaciej>	Lachy: I will fix to match
23:52	<TabAtkins>	nm, I just fixed it.
23:52	<Lachy>	yes, both are required
23:52	<Lachy>	it wouldn't make sense to have a details without a label
23:52	<Lachy>	and even less sense to have no content
23:53	<Lachy>	hmm, unless it were just used as a placeholder in the page
23:53	<othermaciej>	fixed
23:54	<Lachy>	oh, sorry. the current spec does make dt optional
23:54	<othermaciej>	optional but has to be first?
23:54	<othermaciej>	I guess I should look myself
23:54	<Lachy>	yes
23:56	<othermaciej>	ok really fixed
23:56	<othermaciej>	does folks like the suggested names in 3b better? (figcaption and dsummary instead of fcaption and dlabel)
23:56	<TabAtkins>	Hmm, dsummary. Yeah, I like it.
23:57	<Lachy>	I keep mistyping dlabel as dlable today.
23:57	<othermaciej>	The <details> spec text does call the caption-like thing "the summary"
23:57	<AryehGregor>	"label" makes more to sense to me, offhand.
23:57	<othermaciej>	heck, it could just be <summary> since that is presently unused
23:57	<AryehGregor>	Oh, that would be a slam dunk IMO.
23:57	<TabAtkins>	Sounds even better.
23:57	<Lachy>	though, I have been mistyping a lot today. Don't know why. maybe I'm just tired.
23:58	<hober>	But then you start to see <article><summary>...
23:58	<Lachy>	I once suggested using <summary>, but I can't remember what the objections were at the time
23:58	<hober>	<article><dsummary> is much more obviously wrong, in the same way as <html><tbody>
23:59	<Lachy>	but I do think label is more appropriate here, given its effectively a control label