| 07:14 | <hsivonen> | How close is WebKit-gtk to WebKit-Mac? should I test in Midori/Epiphany or really move to my Mac Mini to test? |
| 07:18 | <SimonSapin> | hsivonen: I suppose it depends on what you’re testing |
| 07:20 | <hsivonen> | SimonSapin: DOMContentLoaded, <script defer>, readyState |
| 07:20 | <hsivonen> | all supposed to live in WebKit |
| 07:20 | <hsivonen> | itself |
| 07:20 | <hsivonen> | rather than port code |
| 07:20 | <SimonSapin> | yes, that’s my limited understanding of webkit ports |
| 07:20 | <hsivonen> | findings so far: Gecko is wrong for <script defer> per spec |
| 07:21 | <hsivonen> | Presto and Blink don't interop on when readyState changes relative to <script defer> |
| 07:23 | <hsivonen> | unsurprisingly, Safari is like Chrome, still |
| 07:24 | <hsivonen> | waiting for Windows Update to give me a fully-patched IE... |
| 07:26 | <hsivonen> | I wonder how Hixie came up with the rules for <script defer> relative to DOMContentLoaded. |
| 07:26 | <zcorpan> | hsivonen: i think presto doesn't support defer |
| 07:26 | <hsivonen> | zcorpan: ah ok |
| 07:27 | <hsivonen> | at the time, IE didn't support DOMContentLoaded |
| 07:31 | <hsivonen> | Does Chrome OS run xorg still? |
| 07:52 | <jgraham> | hsivonen: Yeah, don't worry too much about presto for anything related to script scheduling or document loading |
| 07:52 | <jgraham> | It was all scheduled for a rewrite |
| 08:06 | <hsivonen> | So it looks like it was indeed I who broke <script defer> in Gecko |
| 08:06 | <hsivonen> | and someone noticed already in 2010 |
| 08:06 | <hsivonen> | but it took until now to someone complain enough for it to actually register |
| 08:07 | <hsivonen> | makes one wonder about the utility of <script defer>, though, that this didn't become a big deal back in 2010 |
| 08:08 | <hsivonen> | hmm. I wonder if <script defer> has ever worked right in XSLT in Gecko, though |
| 08:09 | <jgraham> | OK, script defer + XSLT is pretty much the definition of niche case |
| 08:09 | <jgraham> | s/case/feature/ |
| 08:09 | <hsivonen> | Thanks to the wonders of XSLT, there's always a 3rd case after HTML and XML |
| 08:10 | <zcorpan> | can we disable defer in the xslt case? |
| 08:10 | <hsivonen> | zcorpan: it would be more work in the Trident/WebKit/Blink XSLT architecture, so probably won't fly |
| 08:11 | <zcorpan> | ah yeah |
| 08:11 | <jgraham> | I have a feeling that in presto XSLT support was implemented to not create a third case, I think the output just got fed back into the parser or something. |
| 08:11 | <jgraham> | But I really don't remember |
| 08:11 | <hsivonen> | so many things need a rewrite |
| 08:11 | <hsivonen> | Gecko's XSLT output is one of those |
| 08:11 | <hsivonen> | but first I should rewrite how XML is loaded in Gecko |
| 08:12 | <zcorpan> | yes we reparsed the output with the html parser |
| 08:12 | <hsivonen> | that project never got beyond careful planning |
| 08:12 | <Ms2ger> | We need a few clones of hsivonen, clearly |
| 08:12 | <zcorpan> | is there a reason gecko doesn't reparse? |
| 08:13 | <hsivonen> | zcorpan: Gecko does XSLT the Right Way |
| 08:13 | <zcorpan> | hsivonen: my question still stands :-P |
| 08:14 | <hsivonen> | zcorpan: sicking/peterv/Pike wrote it the Right Way? |
| 08:15 | <jgraham> | The Right Way does also seem to be The Hard To Maintain Way |
| 08:15 | <hsivonen> | yeah |
| 08:15 | <zcorpan> | yeah, so i actually meant, is there a reason not to change gecko to implement the Wrong Way like everyone else and not have a third mode to worry about? |
| 08:15 | <hsivonen> | and with scripts, the Right Way isn't actually quite right |
| 08:15 | <jgraham> | So given such a marginal feature, it seems that worse is better |
| 10:43 | <Ms2ger> | Anyone have old IEs around? |
| 10:44 | <hsivonen> | Ms2ger: I do |
| 10:45 | <Ms2ger> | Let me write you a test, then :) |
| 10:45 | <hsivonen> | Ms2ger: OK |
| 10:46 | <Ms2ger> | hsivonen, http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2259 |
| 10:49 | <hsivonen> | Ms2ger: HTMLInputElement, HTMLImageElement, HTMLImageElement |
| 10:49 | <hsivonen> | Ms2ger: in IE8 on XP |
| 10:49 | <Ms2ger> | :( |
| 10:49 | <hsivonen> | Yeah. :-( |
| 10:52 | <zcorpan> | why is that :-( ? |
| 10:53 | <zcorpan> | img needs the form element pointer? |
| 10:53 | <hsivonen> | zcorpan: right |
| 10:53 | <Ms2ger> | It seems to, at least |
| 10:54 | <hsivonen> | so why didn't WebKit devs feed their delta from the spec into the spec? |
| 10:54 | <zcorpan> | seems everyone implements that already? |
| 10:55 | <hsivonen> | zcorpan: Gecko and IE10 follow the spec and don't |
| 10:55 | <hsivonen> | or maybe I should test before I say anything |
| 10:55 | <zcorpan> | my copy of firefox gives the same result |
| 10:56 | <hsivonen> | Ms2ger: is this test case really testing what it is supposed to be testing? |
| 10:56 | <Ms2ger> | I don't know |
| 10:56 | hsivonen | boots Windows 8 |
| 10:57 | <Ms2ger> | zcorpan, Gecko does weird stuff, with <form></form><img> matching, for example |
| 10:58 | <hsivonen> | Ms2ger: same result in IE10 |
| 10:59 | <Ms2ger> | Hrm |
| 10:59 | <zcorpan> | Ms2ger: webkit and presto don't do that |
| 10:59 | <Ms2ger> | I'd hope not! |
| 10:59 | <hsivonen> | Ms2ger: maybe you should have </form> somewhere |
| 11:00 | <Ms2ger> | Gah, sounds like my IE10 is too old, then |
| 11:02 | <Ms2ger> | How about http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2260 ? |
| 11:04 | <hsivonen> | Indeed Gecko tries to support <script defer> with XSLT |
| 11:05 | <hsivonen> | Ms2ger: IE10/Windows 8: HTMLInputElement, HTMLImageElement, undefined |
| 11:05 | <Ms2ger> | Okay |
| 11:06 | <hsivonen> | Ms2ger: IE8/XP: HTMLInputElement, HTMLImageElement, script terminated with error |
| 11:07 | <Ms2ger> | Lovely |
| 11:07 | <zcorpan> | what does ie do for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2261 ? |
| 11:08 | zcorpan | bets IE6 crashes |
| 11:08 | <hsivonen> | Ms2ger: script error in IE8 |
| 11:08 | <zcorpan> | (for 2260) |
| 11:08 | <hsivonen> | Ms2ger: undefined in IE10 |
| 11:09 | <hsivonen> | oops. those were 2261 for zcorpan |
| 11:09 | <Ms2ger> | That was for zcorpan? |
| 11:11 | <zcorpan> | undefined in ie10/win7 (tested in browserstack) |
| 11:19 | <hsivonen> | does the spec intend to forbid async scripts from running after a defer script has run but before DOMContentLoaded has fired? |
| 12:18 | <zcorpan_> | why does cssom have CSSCharsetRule again? |
| 12:18 | <zcorpan_> | again as in, it was obsolete in the anne-era |
| 13:53 | <annevk> | :/ |
| 14:03 | <zcorpan_> | thanks annevk |
| 15:45 | <Ms2ger> | Nice to have someone working on cssom again |
| 15:48 | <darobin> | well, I guess I won't fix the PHP configuration on the test server today |
| 15:48 | darobin | looks for something to break very rudely |
| 16:01 | <darobin> | jgraham, Ms2ger: if I were to start writing that magic python server, where would I start looking? |
| 16:02 | <darobin> | I need something that's bare bones and doesn't handle any HTTP that I don't want it to, no magic, etc. |
| 16:02 | <darobin> | I reckon it may just be less painful than trying to set Apache+PHP up so that they work correctly |
| 16:02 | <jgraham> | darobin: Heh |
| 16:02 | <jgraham> | Well |
| 16:02 | <Ms2ger> | https://bitbucket.org/annevk/simpleserver ? |
| 16:03 | <darobin> | Ms2ger: interesting, thanks |
| 16:03 | <jgraham> | Yeah, using asyncore as the basis could work |
| 16:03 | <darobin> | I guess I need to think about how this needs to work, actually |
| 16:03 | <jgraham> | Right |
| 16:03 | <jgraham> | So, the thing is |
| 16:03 | <darobin> | because it needs to send regular files, well, regularly, and form the same origin |
| 16:04 | <jgraham> | There are kind of competing requirements |
| 16:04 | <jgraham> | For running on local test machines there is no need to service > 1 user |
| 16:04 | <jgraham> | and there is an advantage to handling statefulness in a simple way |
| 16:05 | <darobin> | ah, statefulness too |
| 16:05 | <jgraham> | For running on w3c-test.org is will be exposed to the whole internet |
| 16:05 | <darobin> | right, and we probably want to be able to run something public |
| 16:05 | <darobin> | if nothing else, it makes it easier to talk about stuff |
| 16:06 | <darobin> | glad we got rid of those people, they were annoying |
| 16:06 | <jgraham> | Most of the Google people seem to use irccloud |
| 16:07 | <jgraham> | Anyway, so in the past |
| 16:07 | <jgraham> | I got to the list of requirements |
| 16:08 | <jgraham> | Realised that they conflict |
| 16:08 | <jgraham> | and gave up |
| 16:08 | <darobin> | heh |
| 16:09 | <darobin> | I think we can get to something if we work on it based on which HTTP behaviours we need for specific cases |
| 16:09 | <darobin> | in general, we need something that can serve files correctly — that's easy |
| 16:10 | <jgraham> | Well at a high level |
| 16:10 | <darobin> | then we need specific endpoints to be configurable with specific behaviour such as setting headers, giving raw responses with specific status, being slow |
| 16:10 | <jgraham> | We need the ability for a test to send arbitary bytes over the wire |
| 16:10 | <jgraham> | With specific timing |
| 16:11 | <darobin> | so could we get away with something that just imports python and runs it if it has a given extension? |
| 16:11 | <jgraham> | But yes, there are specific things that are common cases |
| 16:11 | <darobin> | and we can prebuild some common cases |
| 16:11 | <jgraham> | Well we could do that |
| 16:11 | <jgraham> | It mgith be quite hard if the choices are "common case" or "no infrastructure" |
| 16:12 | <darobin> | if .tpy in filename: load it, give it the data and a raw socket; else: send the file |
| 16:12 | <darobin> | well |
| 16:12 | <darobin> | with that scheme we can start with zero infrastructure |
| 16:12 | <darobin> | and pieces that are common, we progressively move them into the core as available services |
| 16:13 | <jgraham> | Well sure, it might make sense to start with something very minimal |
| 16:13 | <darobin> | if we build it such that it can proxy some paths to another server, we can have a smooth transition |
| 16:13 | <darobin> | I'm guessing there's something in Python that can do proxies easily? |
| 16:16 | <darobin> | looking at the stuff out there, I find it hard to tell what's fresh and what's dead |
| 16:16 | <darobin> | I'm guessing this might be beyond my python, or at least it'll take me longer than reasonable |
| 16:16 | <darobin> | I'll sleep on it |
| 16:17 | <jgraham> | import time, random |
| 16:17 | <jgraham> | time.sleep(random.randint()) |
| 16:17 | <Ms2ger> | Would be nice to have something like ^headers^ too |
| 16:17 | <darobin> | Ms2ger: you mean just a file that sets the headers for a directory? |
| 16:18 | <Ms2ger> | For a file |
| 16:18 | <Ms2ger> | But yes |
| 16:18 | <jgraham> | Turns out that everyone always thinks that the sugar they are used to is really important :) |
| 16:18 | <Ms2ger> | Well, really important |
| 16:18 | <darobin> | Ms2ger: so foo.html.^headers^ or some such? |
| 16:18 | <Ms2ger> | I think it's a reasonably common case, and that foo.html^headers^ solves it quite simply |
| 16:18 | <Ms2ger> | darobin, right |
| 16:19 | <jgraham> | Yeah, that could be true |
| 16:19 | <darobin> | yes that makes sense |
| 16:19 | <darobin> | it's not inherently hard and it's certainly part of the stuff that I'd suggest we add as we progress |
| 16:21 | jgraham | -> afk |
| 16:22 | <darobin> | yeah, I'm off to 1) drown my attempt at configuring PHP right in beer, and 2) mull over a replacement |
| 16:22 | <Ms2ger> | 3) Implement <blink>? |
| 16:22 | <darobin> | maybe if we wait long enough then having Node as a dependency won't be an issue, and I can code it in a day, two tops :) |
| 16:29 | Hixie | is back |
| 16:29 | <annevk> | "Microsoft has been following the discussion on Futures closely both through the W3C and the discussions at TC39 (ECMAScript), and while we don't comment on plans for implementation, I can say that we are generally supportive of the idea." |
| 16:29 | <Ms2ger> | Congratulations! |
| 16:30 | <annevk> | Hixie: I'm gonna assume next is "brb, reading email" and we won't see you for another couple of weeks :p |
| 16:31 | <Ms2ger> | bholley! |
| 16:31 | bholley | knew he shouldn't have logged on IRC this morning |
| 16:31 | <bholley> | :-) |
| 16:31 | <Ms2ger> | I've been trying to catch you since Sunday or so :) |
| 16:32 | bholley | has been away from internet |
| 16:32 | Ms2ger | moves servers |
| 16:35 | <Hixie> | annevk: reading e-mail? nah, mark all as read, no? |
| 16:35 | <Hixie> | anyone send me anything important? |
| 16:36 | <Ms2ger> | Your spec for the named getter on form is bogus |
| 16:41 | <Hixie> | Ms2ger: file a bug |
| 16:41 | <Hixie> | :-) |
| 16:41 | <Hixie> | (or whatwg@ e-mail, i won't mark those as read) |
| 16:41 | <Hixie> | GPHemsley: we should probably encourage people to use their names as usernames rather than companies |
| 16:41 | <Ms2ger> | I already filed one |
| 16:42 | <Ms2ger> | More on their way |
| 16:42 | <GPHemsley> | probably |
| 16:44 | <GPHemsley> | For non-Mozillians: IE and Opera use the first occurrence of a parameter, Firefox and Chrome use the last occurrence |
| 16:44 | <GPHemsley> | no one does what the RFC says, which is to treat the whole MIME type as invalid |
| 16:59 | <Hixie> | i wonder what we should do about <meta name> |
| 16:59 | <Hixie> | on the one hand, everyone under the sun seems to invent their own value to use |
| 17:00 | <Hixie> | on the other, 99% of these values (at a guess) are never actually consumed by any software and are therefore just wasting author's time |
| 17:01 | <Ms2ger> | If it makes authors happy, can you really say that's a waste of their time? |
| 17:01 | <Hixie> | not clear that it makes them happy |
| 17:04 | <Hixie> | zcorpan: for your doc, you could name it "How HTML has evolved since 1998" |
| 17:22 | <GPHemsley> | Hixie: You mean you don't like fielding a hundred requests for accounts just to add spec-less meta extensions? |
| 17:23 | <Hixie> | no, we could solve that problem orthogonally |
| 17:23 | <Hixie> | (e.g. providing a web form) |
| 17:23 | <GPHemsley> | ah |
| 17:23 | <GPHemsley> | true |
| 17:23 | <Hixie> | we're fielding requests intentionally, as a way to see whether people actually do have so many crazy values intentionally |
| 17:24 | <Hixie> | it seems the answer is yes |
| 17:24 | <GPHemsley> | heh |
| 17:24 | <GPHemsley> | you could go the MIME type route and have multiple types of values |
| 17:24 | <GPHemsley> | those with specs, those for private use or whatever |
| 17:25 | <Hixie> | well clearly we could have more specced values and less specced values |
| 17:25 | <Hixie> | but the question is really what to do about the latter |
| 17:26 | GPHemsley | shrugs |
| 17:32 | <bradeeoh> | Hixie: ping |
| 17:34 | <Hixie> | bradee-oh: pong |
| 17:39 | <bradee-oh> | Hixie: hi - I'm crafting an email to whatwg, but as I was, I noticed the plot was thicker than I originally noticed... |
| 17:39 | <bradee-oh> | Hixie: re: pagehide events and page visibility. |
| 17:39 | <bradee-oh> | Hixie: I guess I have two issues: |
| 17:40 | <bradee-oh> | 1 - The original issue I was going to email about. "unload a document" used to go "pagehide, then unload event, then no more events" |
| 17:40 | <bradee-oh> | Now it goes "pagehide, visibilitychanged, unload, then no more events" |
| 17:41 | <bradee-oh> | Hixie: this breaks an original goal of pagehide to be a drop-in replacement for the unload event (i.e., it's the last event you'll get) |
| 17:41 | <bradee-oh> | Hixie: It also doesn't make sense in the standalone world of pagehide/pageshow. "If I get a pagehide event with persisted == true, then I expect no more events until I get pageshow" |
| 17:42 | <bradee-oh> | Hixie: but that leads to my second question... apparently the spec never allows for "pagehide with persisted set to true". I could swear that it did at one time, and WebKit certainly dispatches such events. |
| 17:42 | <Hixie> | bradee-oh: huh |
| 17:42 | <bradee-oh> | Hixie: and such an event is necessary for scripts to play with page caching. |
| 17:43 | <Hixie> | bradee-oh: i forget why we added visibilitychanged |
| 17:43 | <Hixie> | bradee-oh: does anyone implement it yet? If not, we could move it to before pagehide |
| 17:43 | <Hixie> | bradee-oh: in general, please do send the e-mail, i don't have any of this paged in and so i don't have anything useful to contribute right now :-( |
| 17:43 | <bradee-oh> | Hixie: We added it for tab visibility - background tabs, minimized windows, etc etc |
| 17:44 | <bradee-oh> | Hixie: okay - Should I put all of this in one, or start two threads? |
| 17:44 | <bradee-oh> | Hixie: I don't know about pagevis implementors yet, but I don't think we'll implement it as-is because of this holdup (https://bugs.webkit.org/show_bug.cgi?id=116769) |
| 17:45 | <Hixie> | bradee-oh: one mail is fine by me |
| 17:45 | <bradee-oh> | Hixie: okay. Thanks! |
| 17:45 | <Hixie> | (e-mails i can split easily, bugs i can't. so i prefer e-mails to have lots of issues, and bugs to have one.) |
| 17:48 | <GPHemsley> | quick poll (no cheating!): what would the charset be for a document tagged with this MIME type: |
| 17:48 | <GPHemsley> | text/xml;test=ISO-8859-2 test te"st ; charset=ISO-8859-3; testing=asd"asd; charset=ISO-8859-4 |
| 17:49 | <Hixie> | -3 probably |
| 17:49 | <GPHemsley> | Hixie: What made you come to that conclusion? |
| 17:50 | <Hixie> | [text/xml] [;] [test] = [ISO-8859-2 test te"st] [;] [charset] = [ISO-8859-3] [;] <abort> |
| 17:50 | <annevk> | isn't that a parse error theoretically? |
| 17:51 | <GPHemsley> | theoretically, but not in practice |
| 17:51 | <Hixie> | am i right? :-) |
| 17:51 | <GPHemsley> | Hixie: Depends on who you ask ;) |
| 17:51 | <Yuhong> | Hixie: on http://ln.hixie.ch/?start=1115899732&count=1, this crash was later discovered again in http://blogs.norman.com/2011/security-research/drag-and-drop-vulnerability-in-ms11-050 and turned out to be exploitable and fixed in MS11-050. |
| 17:51 | <Hixie> | GPHemsley: figures |
| 17:51 | <GPHemsley> | preliminary question, what about this: |
| 17:51 | <GPHemsley> | text/xml;charset=ISO-8859-3;charset=ISO-8859-4 |
| 17:52 | <Hixie> | Yuhong: good times |
| 17:52 | <Hixie> | GPHemsley: -3, i hope, but it depends on whether you abort early or not |
| 17:52 | <GPHemsley> | presume you are reading the entire MIME type at once (not just looking for the charset specifically) |
| 17:53 | <GPHemsley> | though you raise a good point |
| 17:53 | <Hixie> | most of the time when you want a charset you are only looking for the charset |
| 17:54 | <Hixie> | not parsing the type |
| 17:54 | <Hixie> | in my experience |
| 17:54 | <Hixie> | see also the text/html charset sniffer in the html parser |
| 17:54 | <GPHemsley> | presume you are parsing the MIME type in general, and getting the charset is only a side effect |
| 17:54 | <GPHemsley> | (these examples are only using the charset as an easily testable proxy) |
| 17:55 | <GPHemsley> | (though I suppose if there are parsers that are looking for that parameter specifically, that'd be a problem) |
| 17:55 | <jgraham> | Hixie: Hej :) I hope you enjoyed your time away from angle brackets :) |
| 17:55 | <GPHemsley> | Hixie: Do you have a link to the text/html charset sniffer for me? |
| 17:55 | <Hixie> | jgraham: it was nice :-) |
| 17:55 | <Hixie> | GPHemsley: one sec |
| 17:56 | <jgraham> | OK, that was one smilie more than I needed |
| 17:56 | <Ms2ger> | :):) |
| 17:56 | <jgraham> | Now I am worried I am turning into a lunatic |
| 17:56 | <Ms2ger> | Turning? |
| 17:56 | <Hixie> | GPHemsley: oh i guess it's just for <meta> http://www.whatwg.org/specs/web-apps/current-work/#algorithm-for-extracting-a-character-encoding-from-a-meta-element |
| 17:57 | GPHemsley | wishes people used the multipage version more often |
| 17:57 | <Hixie> | but you'll love that algorithm |
| 17:57 | <Hixie> | just keep the single page one open, then paste the url into that tab and it'll jump without reloading |
| 17:58 | <GPHemsley> | I suppose I could do that |
| 17:58 | <GPHemsley> | but anyway |
| 17:59 | <GPHemsley> | take my tests again pretending you are not just looking for charset specifically |
| 17:59 | <Hixie> | ah |
| 17:59 | <Hixie> | dunno then |
| 17:59 | <Hixie> | don't we generally ignore parameters? :-) |
| 18:01 | <GPHemsley> | gah, you're no fun :P |
| 18:01 | <Yuhong> | Tested and on IE10 it deletes the text from the original location, while on Firefox it doesn't. |
| 18:02 | <Yuhong> | On Chrome it don't work. |
| 18:02 | <GPHemsley> | Hixie: Anyway, the way things are, if you have a parameter with an unquoted value, you ignore anything that comes after the first whitespace character. |
| 18:03 | <GPHemsley> | so charset=ISO-8859-1 this is ignored;test=bla |
| 18:03 | <GPHemsley> | the question is what to do about quotation marks |
| 18:03 | <GPHemsley> | some implementations will treat the quotation mark as a quotation mark and look for its match before deciding what to ignore |
| 18:04 | <Hixie> | weird |
| 18:04 | <GPHemsley> | others will ignore all characters that aren't semicolon |
| 18:04 | <GPHemsley> | so the question is, what do I put in the algorithm? :P |
| 18:04 | <GPHemsley> | it seems to be leaning towards not matching quotes in this case |
| 18:04 | <GPHemsley> | which IE, Opera, and Safari appear to agree with |
| 18:05 | <GPHemsley> | Firefox and Chrome, on the other hand, will each up that whole chunk between the two quotation marks and ignore that |
| 18:05 | <GPHemsley> | s/each/eat/ |
| 18:05 | <GPHemsley> | meaning if you happen to have an unmatched quotation mark, the whole rest of the MIME type is ignored |
| 18:05 | <Hixie> | is there any way to test this other than charset? |
| 18:06 | <GPHemsley> | not that I'm aware of |
| 18:06 | <GPHemsley> | but I'm not aware of much :P |
| 18:06 | <GPHemsley> | what is the XML format parameter? anything visible? |
| 18:07 | <Hixie> | never heard of it |
| 18:07 | <GPHemsley> | then I have no idea |
| 18:07 | <GPHemsley> | I'm inclined to not match quotes |
| 18:07 | <GPHemsley> | but it has been suggested that tokenizing might be done before parsing |
| 18:08 | <GPHemsley> | though that would probably be in violation of the spec, as written |
| 18:08 | GPHemsley | shrugs |
| 18:09 | <Hixie> | !@#$%^&*( https://www.w3.org/Bugs/Public/show_bug.cgi?id=22106 wtf |
| 18:09 | <Hixie> | GPHemsley: if there's no way to test it, you may be trying to solve a non-problem. :-) |
| 18:15 | <GPHemsley> | Hixie: Well, yes and no |
| 18:16 | <GPHemsley> | Hixie: There are some browsers that will use the last charset value and some that will use the first |
| 18:16 | <GPHemsley> | So I think there's something in play here |
| 18:17 | <GPHemsley> | but seeing as how I would prefer the simpler solution, and a majority of browsers agree with me, I think I'll go with that |
| 18:17 | <GPHemsley> | (majority out of 5, that is) |
| 18:21 | GPHemsley | wonders if he should allow single quotes for quoted parameter values, too |
| 18:21 | <GPHemsley> | (probably not) |
| 18:34 | <GPHemsley> | ugh |
| 18:36 | <GPHemsley> | the browsers that do charset-first are also the ones that do non-quote-matching, and the same for charset-last and quote-matching |
| 18:36 | <GPHemsley> | except Safari |
| 18:37 | <GPHemsley> | because now I have to figure out whether to allow backslash to escape a semicolon in order to be ignored |
| 18:37 | <GPHemsley> | as in: |
| 18:37 | <GPHemsley> | text/xml;charset=ISO-8859-2 test te\;charset=ISO-8859-5 test; testing=asd\;asd |
| 18:38 | <GPHemsley> | allow backslash to escape in an ignorable element, and that declares no charset |
| 18:38 | <GPHemsley> | don't allow it to, and it does |
| 18:47 | <Hixie> | ok, mailbox is dealt with |
| 18:47 | <Hixie> | now lunch |
| 18:49 | <Ms2ger> | I assume "dealt with" doesn't imply "read" |
| 18:51 | <Hixie> | i read most of them |
| 18:52 | <Ms2ger> | How many were there, I wonder? |
| 18:54 | <GPHemsley> | hsivonen: You there? |
| 18:54 | <GPHemsley> | Anyone have IE handy? |
| 18:57 | <GPHemsley> | Here's a fun one: |
| 18:58 | <GPHemsley> | text/xml;test=asdf\;charset=ISO-8859-3 test;charset=ISO-8859-2 te\"st;testing=te"st;charset=ISO-8859-5 |
| 18:58 | <GPHemsley> | Four possible encodings |
| 18:58 | <GPHemsley> | (utf-8 is the default for XML) |
| 18:58 | <GPHemsley> | and at least one browser does each one |
| 19:00 | <GPHemsley> | Firefox and Chrome do the same thing, but that's because they both match quotes |
| 19:00 | <GPHemsley> | I'm curious what IE does |
| 19:01 | <GPHemsley> | (IE has so far been patterning mostly with Opera) |
| 19:03 | <Ms2ger> | Other way around, probably |
| 19:03 | <GPHemsley> | well, yeah, but from my point of view :) |
| 19:04 | <qwebirc364527> | what is the best channel to ask questions about html5 and css3? |
| 19:05 | <aklein> | Hixie: yt? I've got some questions about the 'calling scripts' algorithm, especially as it regards microtask checkpoints |
| 19:12 | <GPHemsley> | regarding that last example: Firefox and Chrome choose -5, Opera chooses -3, Safari chooses utf-8 |
| 19:12 | <GPHemsley> | so I guess no one actually chooses -2 |
| 19:12 | <GPHemsley> | unless IE does |
| 19:13 | <GPHemsley> | a UA that allowed semicolon escaping would choose -2 |
| 19:14 | <GPHemsley> | err, rather, a UA that allowed semicolon escaping AND used the first occurrence of a valid charset parameter |
| 19:14 | <GPHemsley> | (this is all very complicated) |
| 19:15 | <GPHemsley> | it's not clear what made Safari just reject everything and default to utf-8 |
| 19:16 | <GPHemsley> | oh, unless... |
| 19:17 | <GPHemsley> | perhaps Sarfari is sniffing for HTML |
| 19:18 | <GPHemsley> | which would mean it treats the whole thing as invalid |
| 19:19 | <GPHemsley> | if that's true, it makes everything else even more complicated... |
| 19:34 | <GPHemsley> | Anyone with IE, what's the encoding on this page? http://whatwg.gphemsley.org/tests/mimesniff/sniffing.php?ct=text/xml;test=asdf\;charset=ISO-8859-3%20test;charset=ISO-8859-2%20te\%22st;testing=te%22st;charset=ISO-8859-5 |
| 19:38 | <GPHemsley> | (at least Safari isn't treating it as invalid... I guess) |
| 19:57 | <GPHemsley> | Is it possible to determine the MIME type of an iframe using JavaScript? |
| 20:01 | <zcorpan> | Hixie: i think i'll not change the title again :-) |
| 20:01 | <Ms2ger> | B-b-b-b-but |
| 20:03 | <GPHemsley> | apparently only in Firefox and IE...? |
| 20:20 | <zcorpan> | GPHemsley: if everyone is doing different things, just spec the simplest sane thing you can come up with :-) |
| 20:35 | <Hixie> | aklein: here |
| 20:35 | <Hixie> | zcorpan: i figured :-) |
| 20:37 | <aklein> | Hixie: hi there. the algorithm at http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#calling-scripts looks to me like it might be "perfoming a microtask checkpoint" too often |
| 20:38 | <aklein> | Hixie: the "microtask" is meant to end only when the outermost script invocation returns |
| 20:39 | <aklein> | but my reading of that section is that causing one script to be invoked from another (say, by synchronously dispatching an event via a call to HTMLElement.focus() inside an onclick handler) causes a checkpoint to be performed in the "middle" of the click handler (and then again at the end) |
| 20:41 | <aklein> | Gecko, WebKit, and Blink all do the right thing, but I think the spec likely needs a fix (this was noticed by someone unfamiliar with microtasks trying to understand them by reading the spec) |
| 20:42 | <Hixie> | aklein: i think that was done intentionally, but let me check the history... |
| 20:43 | <Hixie> | aklein: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554 |
| 20:43 | <Hixie> | aklein: it's intentional (and it is hoped that the browsers will change accordingly) |
| 20:43 | <Hixie> | aklein: however, if the browsers won't change, then obviously we should change the spec |
| 20:44 | <aklein> | Hixie: hmm, interesting, reading... |
| 20:49 | <aklein> | Hixie: more generally, I'm interested in the problem of specs not referencing this "jump to a code-entry point" algorithm. e.g., DOM core doesn't use that algorithm when describing how events are dispatched. is that just a bug? |
| 20:50 | <aklein> | it seems like the layering is tricky, though |
| 20:50 | <aklein> | since DOM isn't supposed to refer to HTML |
| 20:51 | <Hixie> | doublec: yt? |
| 20:52 | <Hixie> | aklein: yeah i think i need to rework it to be in terms of the JS spec |
| 20:52 | <Hixie> | aklein: there's a bug on that too, hold on |
| 20:54 | <Hixie> | aklein: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242 |
| 20:56 | <aklein> | Hixie: my read of 19554: it looks you went with sicking's suggestion to do "outermost script exits" for blob url autorevoking, but left "perform microtask checkpoint" as running every time through the script-calling algorithm. and I don't see discussion about that issue on that bug. |
| 20:58 | <Hixie> | aklein: ah, maybe it was an error then. can you file a new bug? |
| 20:59 | <aklein> | Hixie: will do |
| 20:59 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851 makes no sense to me. can someone explain this? (the issue of putting .text on the abstract cue interface) |
| 20:59 | <Hixie> | aklein: thanks |
| 21:02 | <rafaelw> | Hixie: Can we abstract all uses of end-of-microtask into some kind of microtask work queue |
| 21:02 | <rafaelw> | and mutation observers, table sort, blob urls, etc... will all be microtask work queue types. |
| 21:02 | <rafaelw> | it looks like we now have at least four types of work happening without consistent semantics. |
| 21:03 | <rafaelw> | (mutation observers, table sorting, blob url revokation, custom element callbacks). |
| 21:03 | <aklein> | rafaelw: this seems to already be partially done, there's a list of "global script clean-up jobs" |
| 21:04 | <Hixie> | rafaelw: don't they all have slightly different needs? |
| 21:05 | <rafaelw> | I really hope not. |
| 21:05 | <rafaelw> | That would be unfortunate. |
| 21:05 | <rafaelw> | Adam is right, the closest thing here is the script cleanup steps. |
| 21:06 | <rafaelw> | I think maybe the global script cleanup jobs list needs a more general name: like global microtask work item |
| 21:06 | <aklein> | sicking & smaug____ might be interested in ^^^ as well |
| 21:06 | <rafaelw> | (and arun if he's nearby) |
| 21:07 | <sicking> | the way that mark miller proposed modeling it is that the "end of microtask" list is like a special task source |
| 21:07 | <sicking> | which has higher prioirty than all other task sources |
| 21:08 | <sicking> | i kind'a like that |
| 21:08 | <rafaelw> | presumably the current implementations fit that description? |
| 21:08 | <sicking> | i'm not sure that that's compatible with how mutation observers are defined right now, but I bet it could be made compatible with that |
| 21:08 | <Hixie> | i've suggested doing that |
| 21:08 | <Hixie> | but iirc there's problems with it |
| 21:08 | <sicking> | rafaelw: it's not how gecko does it |
| 21:08 | <rafaelw> | what's the semantic difference? |
| 21:09 | <sicking> | rafaelw: does mutation observers do anything differently once all mutation observers have been notified? |
| 21:09 | <sicking> | specifically, say that I have 3 observers |
| 21:09 | <sicking> | A B and C |
| 21:10 | <sicking> | if I do something that ends up wanting to notify all 3 |
| 21:10 | <GPHemsley> | zcorpan: That's the plan :) |
| 21:10 | <sicking> | and then I return to the event loop, which means that we start notifying them |
| 21:10 | <sicking> | we start with notifying A |
| 21:11 | <sicking> | and then we notify B, but B does something that wants to notify A and C |
| 21:11 | <sicking> | which one is notified after that? A or C? |
| 21:11 | <rafaelw> | C |
| 21:11 | <smaug____> | (microtask doesn't necessarily mean returning to event loop) |
| 21:11 | <rafaelw> | then A |
| 21:11 | <rafaelw> | conceptually, you can think about the delivery steps like this: |
| 21:11 | <sicking> | rafaelw: ok, so we just add to C's list, and then add to A's list which adds A to the end of the queue? |
| 21:12 | <rafaelw> | let currentRecipients be currentRecipients |
| 21:12 | <rafaelw> | clear currentRecipients |
| 21:12 | <rafaelw> | while (currentRecipients.length) |
| 21:12 | <rafaelw> | next = currentRecipients.shift(); |
| 21:12 | <rafaelw> | if (next.stillNeedsDelivery) next.deliver() |
| 21:12 | <sicking> | rafaelw: you're already describing a different model than a task source |
| 21:13 | <sicking> | rafaelw: having it be a task source would require there not being a "currentReciptients" concept |
| 21:14 | <rafaelw> | is there any advantage to the task source scheduling that you're thinking of? |
| 21:14 | <sicking> | since "currentReciptients" require going through the contents of the task source and picking out things that are specifically MO tasks |
| 21:15 | <rafaelw> | no. it wouldn't |
| 21:15 | <sicking> | rafaelw: Not sure. There might be the advantage that we can put more things in the task source while having a defined interaction and order |
| 21:15 | <sicking> | i'm not sure how we can define more things happning at "end of microtask" right now |
| 21:16 | <Hixie> | see https://www.w3.org/Bugs/Public/show_bug.cgi?id=20821 for more discussion on this btw |
| 21:17 | <rafaelw> | it seems like there are two (somewhat orthogonal issues) |
| 21:17 | <rafaelw> | a) when delivery happens |
| 21:17 | <rafaelw> | b) how delivery happens. |
| 21:17 | <sicking> | yup |
| 21:17 | <sicking> | well |
| 21:17 | <sicking> | what do you mean by the "how"? |
| 21:17 | <rafaelw> | (and I suppose) whether all clients can live with the same semantics of a single a & b. |
| 21:17 | <rafaelw> | delivery scheduling |
| 21:18 | <rafaelw> | (i.e. m.o vs task source) |
| 21:18 | <sicking> | so a == "when do we run 'end of microtask' stuff", and b == "in what order does 'end of microtask' stuff run"? |
| 21:18 | <rafaelw> | yes. |
| 21:18 | <sicking> | then yes, i agree |
| 21:18 | <smaug____> | isn't a) clear |
| 21:18 | <sicking> | i thought so |
| 21:19 | <rafaelw> | that's what i'm hoping, the current spec language is clearly wrong. |
| 21:20 | <rafaelw> | there are two problems with the current wording (wrt a) |
| 21:22 | <rafaelw> | 1) http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#calling-scripts will Perform a microtask checkpoint, when there is a running script |
| 21:23 | <rafaelw> | 2) there are multiple kinds of work which are happening here, and it seems like they should all be clients of the same mechanism. |
| 21:25 | <sicking> | rafaelw: doesn't step 5 in that algorithm only do the microtask checkpoint if it's the outermost running script? |
| 21:25 | <sicking> | oh, no |
| 21:25 | <sicking> | step 6 is what does the checkpoint |
| 21:26 | <rafaelw> | right. that's why adam was suggesting that step 5 is closest to what we need here. |
| 21:27 | <rafaelw> | although, we need think thing to also be invoked at the end of the current Task, so it makes somewhat less sense to call it (global script clean-up jobs) |
| 21:27 | <sicking> | the cleanup jobs stuff isn't even agreed upon being a workable idea. I think Google is wary so far |
| 21:27 | <sicking> | weary even |
| 21:27 | <rafaelw> | well, i think we can treat that as a separate issue. |
| 21:27 | <rafaelw> | (presumably that's about File stuff). |
| 21:28 | <sicking> | yes, definitely separate, sorry |
| 21:28 | <rafaelw> | at very least, there are m.o., custom element callbacks and table sorting. |
| 21:28 | <rafaelw> | that are all "end of microtask" |
| 21:28 | <rafaelw> | (and if their needs are different, i'm not aware of it). |
| 21:35 | <Hixie> | can anyone figure out what https://www.w3.org/Bugs/Public/show_bug.cgi?id=22049 means? |
| 21:35 | <rafaelw> | is this a reasonable way to clean this up: I'll write-up a proposal for cleaning up the language, attach it to a whatwg bug, and start cc'd folks -- and the folks i ad can make sure the right stake holders are added (that i missed)? |
| 21:35 | <sicking> | The way I'd like to define things is that there's an "end of microtask" queue of work items. These items are always added to the end of the queue and always run in queue order. Only once the queue is empty do we continue with doing whatever else we had planned to do (like calling the next event handler for example). M.o. would, when they detect that a MO gets its first entry, queue a work item at the end of the microtask queue which notifies |
| 21:35 | <sicking> | MO. When a MO gets additional entries, nothings needed to be done. |
| 21:35 | <rafaelw> | s/ad/add |
| 21:36 | <sicking> | rafaelw: that soudns good |
| 21:36 | <rafaelw> | ok, well now you've opened issue b |
| 21:36 | <rafaelw> | so let's talk about it briefly. |
| 21:36 | <sicking> | rafaelw: ah, yes, definitely |
| 21:37 | <sicking> | rafaelw: sorry, my mind has been more occupied with b |
| 21:39 | <sicking> | rafaelw: i guess it would be nice if the table sorting happened before notifying any MO. Since otherwise we'd might notify it twice rather than once. But that requires tricky knowledge about different end-of-microtask-work-items |
| 21:43 | <rafaelw> | so adam and I were just talking about this and we think it's probably ok to use a regular Task queue. |
| 21:44 | <rafaelw> | M.O. will need to schedule a single task for all observers and make sure its pending every time a new record gets enqueue to an observer |
| 21:44 | <sicking> | rafaelw: won't that cause these things to run after an event has fully run? Rather than after each event handler |
| 21:44 | <rafaelw> | sorry. have you jumped back to talking about (a)? |
| 21:44 | <sicking> | rafaelw: or do you mean "task queue that runs at the end of microtask" |
| 21:44 | <rafaelw> | yes. |
| 21:44 | <sicking> | rafaelw: ok, i'm with you |
| 21:45 | <sicking> | why do you need a single task for all observers? |
| 21:45 | <rafaelw> | the issue with scheduling for m.o is that delivery is ordered by observer *creation time*. |
| 21:45 | <rafaelw> | so each delivery cycle needs to sort the observers which are about to be delivered to. |
| 21:45 | <sicking> | oooh :( |
| 21:46 | <sicking> | why do we use observer creation time? |
| 21:46 | <rafaelw> | well, first it was a useful construct because pages can control order of delivery by creating their observers in the right sequence. |
| 21:47 | <rafaelw> | but the real reason is that ordering by *mutation* order would have risked exposing implementation details. |
| 21:47 | <rafaelw> | and being non-compat. |
| 21:47 | <rafaelw> | (or very hard to spec) |
| 21:47 | <sicking> | mm.. good point |
| 21:48 | <rafaelw> | so i think it makes sense to use a FIFO queue (avoid Task queue for clarity). |
| 21:48 | <rafaelw> | the wording for m.o. gets more complex, but i think that's ok. |
| 21:48 | <sicking> | yeah |
| 21:49 | <rafaelw> | and i think we're all agreed on the timing, but the spec is just in need to a fix-up. |
| 21:49 | <rafaelw> | any other problems you can think of? otherwise I'll go write it up and open the bug. |
| 21:50 | <sicking> | we'd have to define things like, what happens if a MO does something that both cause additional MOs needing to be called, and also cause tables to need to be re-sorted. Does those MOs get called before or after the table is sorted? |
| 21:50 | <sicking> | I.e. say that you have observers A and B created |
| 21:50 | <sicking> | and you do a mutation that requires A to fire |
| 21:51 | <sicking> | so then A fires, and it does a mutation which requires B to get fired and also mutates a table. |
| 21:51 | <sicking> | does B run before or after table is resorted? |
| 21:51 | <sicking> | and would the answer be different if the initial mutation had required both A and B to get notified? |
| 21:52 | <rafaelw> | so i have an opinion... |
| 21:53 | <sicking> | i don't think i have a strong opinion. Though it seems iffy if the answer depends on if B was originally scheduled or not |
| 21:54 | <rafaelw> | i think when m.o. runs, it *has* to deliver to all observers that are "activated" before it calls the first one. |
| 21:54 | <rafaelw> | i think the question is where it continues delivering until there are no "active" observers, or if it yields to other types of work. |
| 21:55 | <rafaelw> | s/where/whether |
| 21:56 | <sicking> | makes sense |
| 21:59 | <rafaelw> | so presumably mark wants ecma end-of-turn stuff to be enqueued to this new microtask FIFO queue? |
| 22:00 | <rafaelw> | (promises, weakrefs, Object.observe, etc...) |
| 22:01 | <rafaelw> | s/ecma/ecmascript/ |
| 22:05 | <rafaelw> | ok. i guess this horse is dead |
| 22:06 | <rafaelw> | i'll open a bug that puts a stake in the ground and we can iterate from there. |
| 22:16 | <sicking> | rafaelw: sorry, yes |
| 22:16 | <sicking> | rafaelw: say my name and my irc client will start blinking and stuff. It's really annoying but it works :) |
| 22:20 | <rafaelw> | sicking: ok. |
| 22:20 | <rafaelw> | here's the bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22185 |
| 22:20 | <rafaelw> | Please add anyone I've missed. |
| 22:21 | <rafaelw> | I'll try to write-up the proposal today or tomorrow. |
| 22:22 | <aklein> | rafaelw: thanks for writing this all down |
| 22:54 | <JonathanNeal> | So, in April http://html5doctor.com/the-hgroup-element/ mentioned they were "working on an article to help guide authors on which markup patterns they should use instead [of hgroup]" What has come of that? What would you folks recommend? |
| 22:54 | <JonathanNeal> | And related, any developments on <subline> or something similar? |
| 22:54 | <Hixie> | <hgroup> is the element to use. |
| 22:54 | <Hixie> | if you have subheadings |
| 22:55 | <Hixie> | hsivonen, MikeSmith, gsnedders: woops, sorry, just checked in a parser fix without marking it for conformance checkers and tools |
| 22:56 | <JonathanNeal> | Huh, has it been undeprecated or something, Hixie? |
| 22:58 | <Hixie> | JonathanNeal: it was never deprecated, at the whatwg |
| 22:58 | <boogyman> | JonathanNeal: why now use the appropriate h-level then use the "next sibling" CSS selector |
| 22:58 | <boogyman> | not* |
| 22:58 | <Hixie> | JonathanNeal: all that happened with <hgroup> is that the w3c is trying to assert its independence, as far as i can tell, by making dumb changes to their fork of the spec. |
| 22:58 | <Hixie> | (note: the above may be overly cynical) |
| 22:59 | <MikeSmith> | Hixie: thanksfor theheads-up |
| 22:59 | <Hixie> | MikeSmith: (specifically, for <menuitem>; without the fix you'll have an infinite loop) |
| 23:01 | <Hixie> | man, i'm totally screwing up this rtl bug |
| 23:01 | <MikeSmith> | ah yeah, I saw the bug report I think |
| 23:01 | <Hixie> | every time i fix it i make it worse |
| 23:01 | <JonathanNeal> | Is there an IRC room for bugging W3C folks about this, and figuring out what they plan to push in its stead? |
| 23:01 | <Hixie> | i18n people must think i'm a loon |
| 23:01 | <MikeSmith> | (menuitem) |
| 23:02 | <Hixie> | JonathanNeal: #htmlwg on irc.w3.org, if you care about the html spec, but i recommend living the easy life with the whatwg spec instead :-) |
| 23:03 | <Philip`> | #html-wg, I think |
| 23:03 | <JonathanNeal> | The inability to add so much as a <div> or <span> in <hgroup> was what keeps me tracking this. |
| 23:03 | <boogyman> | ^ if you're a UA implementer. If he's a consumer, then he should look at which version of the spec is being used for UA's |
| 23:03 | <JonathanNeal> | Unless I'm incorrect in that preposition? |
| 23:04 | <Hixie> | JonathanNeal: why do you need a <div> in <hgroup>? |
| 23:05 | <MikeSmith> | JonathanNeal: I don't think hgroup is ever essential. The only reason to use it is if you care about how applications the implement the outline algoritm are going to show your headings in the outline |
| 23:05 | <Hixie> | JonathanNeal: (you can have a <Span> around the <h1> or <h2> contents in <hgroup>) |
| 23:06 | <JonathanNeal> | I was always hoping an element like <hgroup> or <subline> would normalize some of the odd implementations I catch across the web. |
| 23:07 | <JonathanNeal> | Like here http://twitter.github.io/bootstrap/ they have a kind of sub heading or abstract that they place in a paragraph. |
| 23:07 | <Hixie> | that's hte idea of <hgroup>, right |
| 23:07 | <JonathanNeal> | But here http://purecss.io/ they have it in a heading. |
| 23:07 | <Hixie> | abstracts are more <header> material |
| 23:08 | <MikeSmith> | JonathanNeal: the W3C HTML spec has http://www.w3.org/html/wg/drafts/html/master/common-idioms.html#sub-head (if you've not seen it already) |
| 23:08 | <Hixie> | JonathanNeal: the bootstrap case is <header> <hgroup> <h1> Bootstrap </h1> <h2> Sleek [...] </h2> </hgroup> <p> ...download... </p> <nav> <p> ...github...examples... </p> </nav> </header> |
| 23:08 | <Hixie> | or similar |
| 23:08 | <JonathanNeal> | The Boostrap team occasionally labeling it a "byline", although it is not being used to attribute credit, it's being used as a subheading. |
| 23:10 | <JonathanNeal> | <div class="marketing">…<h1>Built with Bootstrap.</h1><p class="marketing-byline">For even more sites built with Bootstrap…</div> |
| 23:12 | <JonathanNeal> | Those are interesting recommendations, MikeSmith. |
| 23:13 | <boogyman> | JonathanNeal: secondary to this conversation, but I believe a hyphen is an illegal character to use in an id/class attribute value |
| 23:13 | <JonathanNeal> | Hixie: I see. Thanks. Yet Boostrap almost kind of avoids HTML5 elements. |
| 23:14 | <JonathanNeal> | boogyman: not sure I follow. there is no sub-head element, that's just an article describing (meh) techniques to mark up subheadings. |
| 23:14 | <Hixie> | JonathanNeal: yeah i just meant that's what it would look like if you used modern HTML |
| 23:16 | <JonathanNeal> | Maybe the paradigm shift was just really high to think of using <h1-6> for longer, even mulit-part text. |
| 23:16 | <JonathanNeal> | <h2-6> rather, within an <hgroup> |
| 23:16 | <MikeSmith> | JonathanNeal: I happen to agree with those recommendations, and disagree with Hixie. I think hgroup is a solution in search of a problem. |
| 23:17 | <Hixie> | the problem is right there: how do you mark up subheadings |
| 23:17 | <Hixie> | every w3c spec has it |
| 23:17 | <Hixie> | how is it not a real problem? |
| 23:17 | <MikeSmith> | Hixie: you can obviously mark up subheadings without <hgroup> |
| 23:17 | <tantek> | Hixie, you mean it's not <br><b><font size> ? |
| 23:17 | <tantek> | ;) |
| 23:18 | <JonathanNeal> | It's certainly a situation in the projects I've worked on, and I see differing opinions on how it should be marked up, between Twitter and Yahoo. |
| 23:18 | <MikeSmith> | everybody was marking up subheadings in whatever ways before hgroup came along |
| 23:18 | <Hixie> | MikeSmith: well sure, you can mark up paragraphs with <p>. I'm not disagreeing that there are multiple solutions, just saying that there is a problem |
| 23:18 | <MikeSmith> | UAs do nothing with hgroup |
| 23:18 | <Hixie> | MikeSmith: er, without <p> |
| 23:18 | <MikeSmith> | yeah |
| 23:19 | <MikeSmith> | I agree it'd be a bigger problem if browsers actually exposed the document outline |
| 23:19 | <Hixie> | JonathanNeal: right, the fact that there were multiple people disagreeing on how to mark it up is why we introduced <hgroup> |
| 23:19 | <Hixie> | it's similar to <section> and <aside> and so on |
| 23:19 | <JonathanNeal> | MikeSmith: some do, my iPhone has started recommending alternate views of web pages. |
| 23:20 | <JonathanNeal> | I'm sure you all know what it is better than I do, but has anyone else seen this? |
| 23:20 | <MikeSmith> | Hixie: but so far you're the one who's not wanting to have browsers provide a way to Web content to expose a document outline |
| 23:20 | <JonathanNeal> | It kind of strips the page of styling and presents you with a book view of a web page? |
| 23:20 | <MikeSmith> | JonathanNeal: have not see that |
| 23:23 | <JonathanNeal> | Yea, it's called "Reader" |
| 23:23 | <JonathanNeal> | http://photos.appleinsider.com/safari-110607-3.png |
| 23:24 | <MikeSmith> | ah yeah |
| 23:24 | <Hixie> | MikeSmith: i think the outline thing is kind of an orthogonal thing. even without the outline issue, we still need something like <aside> and <nav> and <hgroup>. |
| 23:24 | <MikeSmith> | JonathanNeal: that thing seems pretty half-assed |
| 23:25 | <boogyman> | its a "low-fi" render |
| 23:25 | <MikeSmith> | Hixie: I think there's way more of need for <aside> and <nav> then for <hgroup> but yeah I agree people certainly want something |
| 23:25 | <JonathanNeal> | MikeSmith: it's a start, and definitely the most outline-ish thing I've seen for non-developers. |
| 23:26 | <Hixie> | MikeSmith: sure, subheadings are rarer than sidebars, but that's just a question of degrees, not a question of whether there's a problem or not. |
| 23:26 | <MikeSmith> | JonathanNeal: well, it doesn't seem like an outline at all to me. And it's not clear to me that it's doing anything with <hgroup> |
| 23:26 | <MikeSmith> | Hixie: true |
| 23:28 | <JonathanNeal> | MikeSmith: I meant, it's using (atleast the elements of) the outline to create a book view of the page. |
| 23:29 | <MikeSmith> | Hixie: I guess to me it just seems like not a high enough priority to merit a new element. But then I could also say that about <article> and some others. |
| 23:30 | <JonathanNeal> | Long live <main> |
| 23:31 | <MikeSmith> | I think some people get way way to wrapped up in discussions about how to properly use the semantic elements -- <article> etc. |
| 23:31 | <MikeSmith> | splitting hairs |
| 23:32 | <MikeSmith> | talmudic |
| 23:32 | <MikeSmith> | pick your metaphor |
| 23:33 | <MikeSmith> | I think in the end Web authors should care fuck all what somebody else thinks of their markup, as long as it's accessible and i18n-friendly, etc. |
| 23:34 | <MikeSmith> | it's like looking at the source of somebody's PDF and complaining about how they used PostScript |
| 23:34 | <boogyman> | Do you agree that there's a difference between appearing accessible, and being accessible? |
| 23:35 | <MikeSmith> | boogyman: is that question a trap of some kind? |
| 23:37 | <boogyman> | that wasn't my intent. I have seen poorly authored code that is "accessible" in the sense that it had tags and wai-aria roles, but that if someone was more miopic, it's really a pos that doesn't make sense. |
| 23:38 | <MikeSmith> | I see |
| 23:39 | <MikeSmith> | boogyman: I would imagine that anybody who was taking the time to add wai-aria roles to a document would be doing it in good faith to try to actually make it accessible |
| 23:40 | <Hixie> | MikeSmith: well sure, but we have it now, so it's kind of a moot point. There's lots of elements that are even less useful. |
| 23:40 | <MikeSmith> | Hixie: no disagreement there |
| 23:40 | <Hixie> | ok :-) |
| 23:41 | <MikeSmith> | so in related news, I see http://www.apple.com/safari/features.html mentions hgroup |
| 23:41 | <MikeSmith> | "Support for article, aside, footer, header, hgroup, nav, and section elements allows developers to create advanced web designs with semantic markup." |
| 23:42 | <MikeSmith> | JonathanNeal: do you have an example of Reader doing something with hgroup? |
| 23:44 | <MikeSmith> | maybe hober knows |
| 23:44 | <boogyman> | oh, btw -- Hixie stop being a loon |
| 23:46 | <Hixie> | MikeSmith: i did a search at google and found literally over 100,000,000 pages with <hgroup> (vs about five times as many with <aside>). It's pretty widely used. |
| 23:47 | <Hixie> | (this is on a subset of the web that we use for this kind of thing internally, i don't recall the sample size but it's in the single-digit billions, iirc) |
| 23:51 | <MikeSmith> | Hixie: OK |
| 23:52 | <MikeSmith> | that suggests to me we probably don't really need <aside) either then :) |
| 23:53 | <boogyman> | 100m isn't an insignificant amount |
| 23:58 | <Hixie> | MikeSmith: well, see https://www.w3.org/Bugs/Public/show_bug.cgi?id=17812 -- from the same sample, i got about 50k pages mentioning :read-only and friends |
| 23:59 | <Hixie> | MikeSmith: i'd guess 100m here is about 1%-10%. We were forced to have the <image> hack in the HTML parser for something used on 0.2% of pages. FWIW. |
| 23:59 | <JonathanNeal> | Good ol' <image>. |
| 23:59 | <JonathanNeal> | How's <picture> doing these days? |
