| 00:29 | <zcorpan> | Philip`: is element-href-absolute the resolved url? does it take <base href> into account? |
| 00:39 | <Philip`> | zcorpan: It's just href resolved against element-uri |
| 00:39 | <Philip`> | and element-uri is just the page that was downloaded |
| 00:40 | <Philip`> | so it ignores <base> entirely |
| 00:40 | <zcorpan> | ok |
| 02:25 | <drhodes> | does anyone know if websockets will allow peer2peer connections? |
| 02:30 | <drhodes> | ok, well found this: http://stackoverflow.com/questions/1032006/will-html5-allow-web-apps-to-make-peer-to-peer-http-connections if by chance anyone is also curious. |
| 03:42 | <Hixie> | drhodes: the short answer is "not in this version" |
| 03:43 | <Hixie> | drhodes: however, it's definitely something that's come up in the past, and i wouldn't be surprised to see it come up again in the future |
| 03:43 | <Hixie> | drhodes: in particular, if the current exploration of the video conferencing space goes anywhere, i wouldn't at all be surprised to see something for peer-to-peer streaming |
| 03:56 | <drhodes> | ok, thanks Hixie. |
| 06:58 | <boblet> | hey all. Has any browser fully supported HTML4.01 yet? What about CSS2.1—still only IE8? |
| 07:01 | <boblet> | s/supported/implemented/ |
| 07:01 | <hsivonen> | boblet: I'm pretty sure a browser that can browse the Web can't fully implement HTML 4.01 |
| 07:02 | <boblet> | hsivonen: heh |
| 07:02 | <hsivonen> | boblet: and for CSS 2.1 there isn't a sufficient test suite yet to be able to tell |
| 07:02 | <JoePeck> | I heard people were going to skip "4" and go straight to "5" like ECMAScript =P |
| 07:02 | <hsivonen> | (I am nt suggesting that there'd be a sufficient test suite for HTML 4.01) |
| 07:03 | <boblet> | hsivonen: ohrly? I thought the test suite was pretty complete now after MS’s contributions. interesting |
| 07:03 | <boblet> | JoePeck: ++ |
| 07:03 | <zcorpan> | JoePeck: you mean css5? |
| 07:04 | <hsivonen> | boblet: as I understand it, the MS test suite test features statically in isolation--not feature interactions or dynamic changes |
| 07:04 | <boblet> | hsivonen: aah. thanks for the explanation |
| 07:04 | <JoePeck> | I'm too tired to joke =), g'nite guys ;) |
| 07:06 | <zcorpan> | http://jhop.me/ie8-bugs suggests ie8 doesn't have a perfect css2.1 impl |
| 07:10 | <zcorpan> | (not surprisingly many bugs seem to be about feature interactions and dynamic changes) |
| 07:11 | <zcorpan> | though a surprising (to me) number of bugs are marked as regressions since ie7 |
| 07:11 | <zcorpan> | maybe regressions are easier to find |
| 07:12 | <hsivonen> | hmm. otoh, maybe html 4.01 has so few MUSTs that apply to UAs that there are impls of all mandatory requirements |
| 07:13 | <zcorpan> | hsivonen: browsers assume a default encoding, which is a violation of html4 must |
| 07:14 | <hsivonen> | ok. that settles it then |
| 07:18 | <zcorpan> | html4 also has a must requirement about parsing media="" which is incompatible with css3-mq |
| 07:19 | <zcorpan> | and "user agents must always make the content |
| 07:19 | <zcorpan> | of the TITLE element available to users (including TITLE elements that |
| 07:19 | <zcorpan> | occur in frames)" |
| 07:20 | <zcorpan> | and that q has quotes |
| 07:21 | <zcorpan> | and some rendering requirements about the soft hyphen |
| 07:24 | <zcorpan> | i guess i could count the remaining testable requirements on my other hand's fingers, but it's too boring |
| 07:34 | <zcorpan> | MikeSmith: yo |
| 07:35 | <hsivonen> | MikeSmith: I re deployed V.nu yesterday |
| 07:37 | <MikeSmith> | hsivonen: cool |
| 07:37 | <MikeSmith> | zcorpan: hey |
| 07:37 | <zcorpan> | MikeSmith: i don't see any xml-stylesheet support in qa-dev from testing it |
| 07:37 | <MikeSmith> | zcorpan: hmm, OK |
| 07:38 | <MikeSmith> | I must have muffed something up |
| 07:38 | <MikeSmith> | I'll take a look later |
| 07:38 | <MikeSmith> | zcorpan: I plan to work on the xml-stylesheet checker this weekend |
| 07:38 | <zcorpan> | cool |
| 07:39 | <MikeSmith> | hopefully will have something fairly complete by Monday |
| 07:39 | <MikeSmith> | ready for testing |
| 07:39 | <zcorpan> | ok |
| 07:45 | <zcorpan> | MikeSmith: what does the internally generated document look like? |
| 07:46 | <MikeSmith> | zcorpan: what internally generated document? |
| 07:46 | <MikeSmith> | oh |
| 07:46 | <MikeSmith> | it looks like this: |
| 07:46 | <MikeSmith> | <xml-stylesheet href=""> |
| 07:46 | <MikeSmith> | etc. |
| 07:46 | <MikeSmith> | <xml-stylesheet href=""/> |
| 07:46 | <MikeSmith> | actually |
| 07:47 | <MikeSmith> | it's just a single element |
| 07:47 | <zcorpan> | ok |
| 07:47 | <MikeSmith> | exactly the same as the PI, just with < and /> instead of <? and ?> |
| 07:48 | <MikeSmith> | uses XOM to parse that and then examine the attributes |
| 07:49 | <MikeSmith> | dunno if XOM is the best choice or if there's some better way of doing it |
| 07:49 | <MikeSmith> | but this way seems to work OK |
| 07:50 | <zcorpan> | i wonder if there's a way to break out of the element but still end up with a well-formed document |
| 07:50 | <zcorpan> | considering that > is allowed in pi content |
| 07:50 | <MikeSmith> | hmm, dunno |
| 07:50 | <zcorpan> | it would be possible with xml5's short end tag |
| 07:52 | <hsivonen> | MikeSmith: are you using code from the HTML5 tokenizer? |
| 07:52 | <MikeSmith> | hsivonen: no, using standard XOM directly |
| 07:53 | <MikeSmith> | zcorpan: that does remind me about one downside of doing it the way I am, which is that if the pseudo-element/document is not well-formed, all it really does right now is report it as "The syntax of the xml-stylesheet PI is incorrect." |
| 07:53 | <MikeSmith> | e.g., for a case like <?xml-stylesheet href="<"?> |
| 07:53 | <MikeSmith> | it doesn't really tell the user where the error is |
| 07:53 | <zcorpan> | yeah |
| 07:54 | <MikeSmith> | I could have it get the message from the exception that XOM throws |
| 07:54 | <MikeSmith> | but the problem with that is XOM messages use the word "attribute" |
| 07:54 | <zcorpan> | but that message would be confusing for <?xml-stylesheet >?> |
| 07:54 | <hsivonen> | MikeSmith: I don't see how XOM would be applicable |
| 07:55 | <MikeSmith> | hsivonen: for creating a document based on taking <?xml-stylesheet href=""?> and turning it into <xml-stylesheet href=""/> |
| 07:56 | <hsivonen> | oh |
| 07:57 | <MikeSmith> | I'm using a Builder the creating an Element then using getAttribute() |
| 07:57 | <zcorpan> | MikeSmith: what happens for namespace declarations? |
| 07:57 | <hsivonen> | MikeSmith: involving a tree model here seems over-complicated to me |
| 07:59 | <zcorpan> | i think you need a namespace-unaware xml parser |
| 07:59 | <MikeSmith> | hsivonen: if you have another way that'd work better, I can implement it that way |
| 08:00 | <hsivonen> | I'd take the data from the PI in a SAX handler and run it through a state machine that implements the pseudo-attribute syntax |
| 08:01 | <hsivonen> | and I'd create the state macine by copying and pasting from the HTML5 tokenizer |
| 08:01 | <MikeSmith> | hsivonen: OK |
| 08:01 | <zcorpan> | at least Char checking is already done by the xml parser |
| 08:02 | <MikeSmith> | hsivonen: OK, I can make that change this weekend |
| 08:02 | <MikeSmith> | zcorpan: Char checking? |
| 08:02 | <MikeSmith> | oh |
| 08:02 | <zcorpan> | (but not LegalChar for NCRs) |
| 08:03 | <MikeSmith> | zcorpan: you mean the Char checking is done before we get to the xml-stylesheet PI checking |
| 08:03 | <zcorpan> | yes |
| 08:03 | <MikeSmith> | zcorpan: why do we need a namespace-unaware parser? |
| 08:04 | <MikeSmith> | if somebody has <?xml-stylesheet xlink:href="foo"?> or whatever, that's just an invalid attribute name, right? |
| 08:04 | <zcorpan> | MikeSmith: because otherwise <?xml-stylesheet href='' xmlns:xml='http://www.w3.org/XML/1998/namespace'?><x/>; would probably pass |
| 08:04 | <MikeSmith> | oh, I see |
| 08:05 | <MikeSmith> | hmm, yeah |
| 08:05 | <zcorpan> | but if you implement your own tokenizer, that won't be a problem |
| 08:05 | <MikeSmith> | right |
| 08:06 | <MikeSmith> | so Henri's suggestion is definitely not just a better way of doing it, but basically the right way |
| 08:07 | <MikeSmith> | there are probably other bad side effects of turning into a element |
| 08:07 | <MikeSmith> | anyway, I have to step out for a bit |
| 08:07 | <MikeSmith> | back later |
| 08:08 | <zcorpan> | hsivonen: how would you validate the pseudo-attributes? |
| 08:10 | <zcorpan> | with custom code, or with a schema? |
| 08:11 | <hsivonen> | zcorpan: I was thinking custom code |
| 08:11 | <zcorpan> | ok |
| 08:19 | hsivonen | wonders how "as well as non-browser environments that make use of Web technologies" got into the Web Apps WG charter |
| 08:19 | <zcorpan> | widgets? |
| 08:20 | <hsivonen> | maybe |
| 08:21 | <hsivonen> | too bad the bit is there. not having it there would make it easy to form a charter-based argument for why it's not worthwhile use of resources for the group to facilitate non-browser reuse of XHR |
| 08:22 | <hsivonen> | fwiw, I think such reuse is fine |
| 08:22 | <hsivonen> | but the group shouldn't use its finite resources to facilitate it |
| 08:23 | <hsivonen> | it should be the reusers' problem |
| 08:26 | <hsivonen> | (conceptually, I prefer Web apps pinned to HTML5 app cache over widgets) |
| 12:00 | <hsivonen> | sent comments |
| 12:00 | <hsivonen> | the e-book part is particularly odd |
| 14:57 | <annevk> | oh yes |
| 14:57 | <annevk> | win win win |
| 14:57 | <annevk> | I successfully merged XHR1 and XHR2 into a single document |
| 14:57 | <annevk> | now all I need to do is update the script with new file names and I can start editing again |
| 18:01 | <Hixie> | so i guess we have to wait til wednesday now for the chairs to come to a decision? |
| 20:24 | <hsivonen> | " <oedipus> could set up a google code group for the shadow DOM for CANVAS and use development of shadow DOM as a follow-up activity to the RWAB XG" |
| 20:25 | <hsivonen> | what does the rich web app backplane have to do with canvas subtree? |
| 20:29 | <miketaylr> | back |
| 22:59 | <TabAtkins> | Argh I am once again stymied by <dl>'s inconsiderate lack of <di>. |
| 22:59 | <TabAtkins> | Hixie: Will it do me any good to throw a request for <di> at you? I can provide use-cases, all styling-related. |
| 23:00 | <Hixie> | can you make a convincing argument that the bug shouldn't be fixed in css rather than html? :-) |
| 23:00 | <TabAtkins> | …probably not. |
| 23:03 | <TabAtkins> | Damn your logic! |
| 23:11 | <othermaciej> | I wonder if anyone is going to propose an alternative to shelley's figure/dialog/dt/dd thing |
| 23:12 | <TabAtkins> | I have it on my calendar. |
| 23:12 | <othermaciej> | I can understand her aesthetic distaste for using <dt> and <dd> inside <figure>, but I can't say <fltcap> is much better |
| 23:12 | <othermaciej> | I'm considering making a proposal to use <label> instead |
| 23:12 | <TabAtkins> | Despite <label>'s problems with embedded form elements? |
| 23:12 | <othermaciej> | I can't say I love the status quo enough to ersonally advocate that |
| 23:13 | <TabAtkins> | I won't be advocating the status quo either - I find the use of <dt>/<dd> to personally be ugly. |
| 23:13 | <othermaciej> | yes, despite <label>'s potential problems for some use cases in current browsers |
| 23:13 | <othermaciej> | I guess I would probably have to suggest how future browsers could finesse the issue |
| 23:14 | <othermaciej> | I could go even more crazy and propose <label> for <details> and <caption> for <figure>, which is semantically the best match, but would require a parsing change for <figure> and could render it unusable in tables in the short term |
| 23:14 | <othermaciej> | er, a parsing change for <caption> |
| 23:14 | <othermaciej> | I also wonder if there is a technical reason none of the <hn> elements would not do |
| 23:15 | <TabAtkins> | One nice advantage of using <label> is that it suggests the possibility of putting the <label> outside of the <details> and linking it with an idref. |
| 23:15 | <TabAtkins> | Though perhaps that's bad for accessibility of the markup? |
| 23:16 | <TabAtkins> | I suggested using an <h1> for it on the list some time ago. |
| 23:16 | <othermaciej> | I think a label where the details pop up somewhere else is actually useful in some cases |
| 23:16 | <Hixie> | <label> makes it impossible to have form controls in a template-like page with a <figure>, so i think it's a non-starter |
| 23:17 | <Hixie> | <h1> would interfere with the <figure> content model |
| 23:17 | <TabAtkins> | What's the use-case for putting form controls in a figure caption? I can't recall one right now. |
| 23:17 | <Dashiva> | Editing, e.g. a checkbox in each figure for inclusion or exclusion of some sort |
| 23:17 | <othermaciej> | <label> would only have to create problems like that in the short term, which is still IMO better than <legend> was but to be fair is more objectively problematic than <dt>/<dd> |
| 23:18 | <othermaciej> | TabAtkins: Hot or Not |
| 23:18 | <Hixie> | <figure><legend><label>Caption: <input type=text></label></legend> ... </figure> |
| 23:20 | <TabAtkins> | I see thee template use, then. The hot-or-not use is weird, though. We don't really want the form being outside of the page outline, do we? |
| 23:21 | <Hixie> | ? |
| 23:21 | <TabAtkins> | <figure> is an outline root, right? |
| 23:21 | TabAtkins | may be misremembering. |
| 23:24 | <othermaciej> | <figure><dd><img src="random-photo-12345.jpg"></dd><dt><label><input type="radio" name="hotornot" value="hot">Hot</label> or <label><input type="radio" name="hotornot" value="not">Not</label></dt></figure> |
| 23:24 | <othermaciej> | using current syntax |
| 23:24 | <othermaciej> | makes sense to me |
| 23:25 | <othermaciej> | I don't understand how the document outline would be relevant to whether those controls are part of the caption - certainly feels to me like they are |
| 23:26 | <othermaciej> | the way I would work around this if <figure>'s caption were <label> is to only let form controls inside a <figure> caption bind to a label through explicit <label for> or aria-labeledby and not implicitly via containment |
| 23:26 | <othermaciej> | that would make this use case for <figure> non-viable until all browsers update |
| 23:28 | <Hixie> | i really think we should avoid making the platform that quirky |
| 23:28 | <Hixie> | it's bad enough when we add quirks accidentally |
| 23:29 | <Hixie> | no need to make it worse :-) |
| 23:33 | <othermaciej> | it's true, that would be an odd quirk |
| 23:33 | <othermaciej> | and <label> is not a good enough match for <figure> to be worth fighting for |
| 23:33 | <TabAtkins> | That would be way too strange. It would confuse me. |
| 23:33 | <othermaciej> | <caption> would be the best match |
| 23:33 | <TabAtkins> | Let's all go back to <caption>. |
| 23:33 | <TabAtkins> | Yus. |
| 23:33 | <othermaciej> | but the short-term cost of being unusable in tables might be too high |
| 23:33 | <TabAtkins> | Man, who puts figures in tables? |
| 23:34 | <othermaciej> | presumably that is what Flickr would do if they used <figure> |
| 23:35 | <Hixie> | we couldn't use <caption> at all -- you couldn't nest a figure in a <caption> if we used <caption> |
| 23:35 | <Hixie> | if we reuse elements, only <dt>/<dd> and <legend> make any sense, i believe |
| 23:35 | <Hixie> | if we make a new element, well, we'd be adding to HTML's quite ridiculous set of "heading"-like elements |
| 23:36 | <Hixie> | we're at 18 already iirc |
| 23:36 | <Hixie> | surely it's time to draw the line :-) |
| 23:36 | <TabAtkins> | Twitter's use of <table> doesn't even make *sense*. They're a fixed-width site. They can handle this in other ways. |
| 23:36 | <Hixie> | this far, no farther! |
| 23:36 | <TabAtkins> | s/Twitter/flickr/ |
| 23:37 | <daedb> | Let's draw the line at 20, just in case we eventually need one more... also, even numbers are better ^^ |
| 23:37 | <TabAtkins> | Why can't we nest <caption><figure><caption>? |
| 23:38 | <Hixie> | TabAtkins: <caption> would close the parent <caption> |
| 23:38 | <TabAtkins> | Damn legacy parsing constraints! |
| 23:38 | <TabAtkins> | I suppose that's a necessity for some reason. |
| 23:42 | TabAtkins | needs to write all this down. |
| 23:43 | TabAtkins | …since he did offer to do that whole "Why Features Exist" thing. |
| 23:44 | <othermaciej> | Hixie: I don't see why using <caption> would prevent you from nesting a <figure> in a <caption>, but I also don't see a use case for doing so |
| 23:45 | <TabAtkins> | He said why while you were gone. Legacy parsing constraint, apparently. |
| 23:45 | <Hixie> | <caption> has to imply </caption> |
| 23:46 | <Hixie> | and as to why you'd have one in a table caption, putting <details> in a <caption> is one of the proposed ways of addressing the complex table accessibility issue |
| 23:46 | <TabAtkins> | Is that necessary if the <caption> is nested inside a <figure>, though? We *don't* have any legacy constraints surrounding people putting <figure> in table captions. |
| 23:46 | <othermaciej> | Hixie: does <caption> have to imply </caption> inside <figure> |
| 23:46 | <othermaciej> | ? |
| 23:46 | TabAtkins | doens't know if that complicates parsing or what. |
| 23:46 | <othermaciej> | I don't see how that could be a legacy constraint |
| 23:47 | <Hixie> | othermaciej: i really don't think adding a new parsing mode just to handle <figure> is the right balance to strike :-) |
| 23:47 | <othermaciej> | Hixie: I think <label> would be better for <details> than <caption> and I think control nesting is not likely to be an issue there |
| 23:48 | <TabAtkins> | It's not really an issue because the entirety of a details caption has to be active already. |
| 23:49 | <TabAtkins> | The *idea* of nesting form controls in a <details> caption is about as troublesome as nesting <a> inside of <a>, or <label> inside of <label> currently. |
| 23:49 | <Hixie> | othermaciej: i think <legend> would be orders of magnitude better than either of those |
| 23:50 | <Hixie> | TabAtkins: why? it's quite common |
| 23:50 | <TabAtkins> | I've never done so on either, and it strikes me as crazy-talk. |
| 23:50 | <othermaciej> | <legend> is broken for all uses in current browsers, as opposed to just in tables, so I can't see how it's worse than <caption> other than the fact that you have already written the spec for the needed parser chnges |
| 23:50 | <othermaciej> | er, can't see how it's better than <caption> |
| 23:51 | <Hixie> | the <legend> parsing changes are a simplification. The <caption> parser changes are so much extra complexity they actually require at least one more parse mode. |
| 23:51 | <TabAtkins> | Firefox *can't* nest <label>s inside of <label>s. |
| 23:51 | <TabAtkins> | (possibly other's can't too) |
| 23:52 | <Hixie> | anyway, bbiab, gotta go to work |
| 23:52 | <othermaciej> | I think either possible change would be the about same amount of code change to WebKit's existing parser, regardless of whether it is a simplification or addition in the spec |
| 23:52 | <othermaciej> | gotta pay attention to meeting |
| 23:52 | <othermaciej> | back later |