| 00:25 | <zewt_> | dear google: stop returning 4 results and then going "results for similar searches" with no way to get more real non-irrelevant results |
| 00:50 | <TabAtkins> | zcorpan: Regarding http://lists.w3.org/Archives/Public/www-style/2013Jun/0038.html, no bug yet. I haven't done it yet, but expect to get to several UseCounter things this week. |
| 00:54 | <TabAtkins> | SimonSapin: Except for the occasional thread where we mess up, the css private list is solely for things like dinner plans and f2f details. We discuss nothing of importance there, but some of the things we *do* discuss are mildly sensitive, and are best done privately. |
| 05:55 | <UserC479> | hi there - i need help - trying to figure out how to get background image and body content one color |
| 09:14 | <Ms2ger> | zcorpan, you should have access now |
| 09:14 | <zcorpan> | Ms2ger: thanks |
| 09:21 | <MikeSmith> | jgraham: it'd be nice to have a message bot on #whatwg too |
| 09:32 | <Ms2ger> | zcorpan, how do you feel like adding a test for https://bitbucket.org/ms2ger/anolis/pull-request/11/enable-usage-of-instead-of-for-xrefs-also/diff too? :) |
| 09:34 | <zcorpan> | Ms2ger: (╯°□°)╯︵ ┻━┻ |
| 09:35 | <Ms2ger> | That seems unhappy :) |
| 09:36 | <zcorpan> | i'll add a test |
| 09:36 | <Ms2ger> | Thanks :) |
| 09:48 | <Ms2ger> | Is there anything else I promised someone here to do this week? |
| 10:18 | <zcorpan> | annevk: can you update web-apps-tracker please? |
| 10:19 | <annevk> | zcorpan: we're just gonna 404 web-workers-tracker? |
| 10:20 | <zcorpan> | annevk: yeah, why not? |
| 10:20 | <annevk> | seems it ought to be 410 |
| 10:21 | <zcorpan> | fair enough |
| 10:22 | <annevk> | you also forgot to update the .htaccess |
| 10:22 | <annevk> | do you want me to do that? |
| 10:24 | <annevk> | i'm gonna do that |
| 10:28 | <annevk> | I wonder why I couldn't do that online |
| 10:31 | <annevk> | hmm scp * doesn't copy .htaccess |
| 10:59 | <annevk> | Ms2ger: I think you promised to do AttrExodus this week |
| 10:59 | <Ms2ger> | Ha |
| 11:04 | <annevk> | zcorpan: btw, I synced the whole thing now |
| 11:04 | <zcorpan> | annevk: thanks! |
| 11:11 | <annevk> | Asked Domenic_ about a better NodeList for find/findAll: https://gist.github.com/domenic/5864658 |
| 11:11 | <annevk> | Not entirely sure why it uses const, but the logic looks reasonable. |
| 11:25 | <annevk> | zcorpan: "url += location.protocol+'//'+location.host+location.pathname+location.search;" why not just echo location? Want to avoid the fragment? |
| 11:30 | <zcorpan> | annevk: yeah |
| 12:06 | <zcorpan> | Ms2ger: i wrote a test but i get this error: |
| 12:06 | <zcorpan> | self.buildReferences(ElementTree, **kwargs) |
| 12:06 | <zcorpan> | TypeError: buildReferences() takes at least 3 arguments (2 given) |
| 12:06 | <zcorpan> | from xspecxref.py |
| 12:08 | <Ms2ger> | Hmm |
| 12:08 | <Ms2ger> | Try adding "allow_duplicate_dfns": false in the options? |
| 12:09 | <zcorpan> | TypeError: buildReferences() takes at least 3 arguments (3 given) |
| 12:11 | <Ms2ger> | Oh, wait |
| 12:11 | Ms2ger | blames annevk |
| 12:12 | <Ms2ger> | How about if you change... |
| 12:12 | <Ms2ger> | - def buildReferences(self, ElementTree, xref, allow_duplicate_dfns=False, **kwargs): |
| 12:12 | <Ms2ger> | + def buildReferences(self, ElementTree, xref="data/", allow_duplicate_dfns=False, **kwargs): |
| 12:12 | <Ms2ger> | Or without the slash |
| 12:15 | <zcorpan> | then i get SyntaxError: Specification not found: foobar. i guess i should have "xref":"xref" in options? |
| 12:15 | <Ms2ger> | Yeah |
| 12:17 | <zcorpan> | tests/xref even |
| 12:17 | <zcorpan> | ok now it seems to work |
| 12:25 | <zcorpan> | thanks. pushed |
| 12:34 | <annevk> | Ms2ger: I don't even |
| 12:49 | <zcorpan> | TabAtkins: ok cssom toc is now non-ugly |
| 13:44 | <annevk> | Hmm, http:@/example.com/ ends up as http:///example.com/ which ends up as http://example.com/ |
| 13:47 | <MikeSmith> | annevk: is that bad? |
| 13:48 | <annevk> | MikeSmith: it would be nice if parsing URLs was idempotent |
| 13:48 | <MikeSmith> | ah |
| 13:49 | <annevk> | MikeSmith: maybe that's not quite the right term, but parse(serialize(parse(x))) is ideally equal to parse(x) |
| 13:50 | <hober> | that's the right term |
| 13:50 | <Hixie_> | mornin' all |
| 13:51 | <annevk> | hober: Hixie_: early much? :) |
| 13:53 | <Hixie_> | yes. |
| 13:57 | <annevk> | hober: yeah so ap suggested this |
| 13:58 | <annevk> | hober: it seems we'd have to forbid empty host names to make that actually work out |
| 13:59 | <annevk> | aaah |
| 13:59 | <annevk> | that's what he implemented |
| 14:04 | <hober> | annevk: re: early, yeah, got an early morning appt |
| 14:16 | <Hixie_> | i think my least favourite people who aren't actually evil are people who complain about things in vague terms but refuse to give specifics because they "know" that the complaints won't be fixed |
| 14:17 | <Ms2ger> | Me? |
| 14:18 | <Ms2ger> | I guess I'm actually evil |
| 14:18 | <Hixie_> | no, you file tons of specific bugs |
| 14:18 | <Hixie_> | i mean like http://www.reddit.com/r/web_design/comments/1gtxtz/i_need_clarification_on_article_and_section/caqed9q |
| 14:20 | <zcorpan> | Hixie_: i commented on https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 - let me know if you need something more or if i'm being unclear |
| 14:21 | <annevk> | "Even the writing ability is lower in this document compared to previous HTML versions." what does this mean? |
| 14:21 | <zcorpan> | annevk: idempotent should be a requirement |
| 14:22 | <annevk> | Heh, what did Chris Wilson do? |
| 14:22 | <annevk> | zcorpan: is this just a "makes sense" remark or is this coming from somewhere? |
| 14:23 | <Hixie_> | zcorpan: cool, thanks |
| 14:24 | <annevk> | zcorpan: Hixie_: HTML should probably define <?xml-stylesheet?> in total, so it can also define when to do XSLT |
| 14:24 | <annevk> | XSLT \o/ |
| 14:25 | <SimonSapin> | Can HTML even do XSLT? |
| 14:25 | <Hixie_> | i don't understand xslt, and nobody else seems to care enough to tell me what it should say, so i'm not doing xslt stuff. |
| 14:25 | <zcorpan> | annevk: not being idempotent can lead to bugs like http://labs.spotify.com/2013/06/18/creative-usernames/ |
| 14:25 | <MikeSmith> | annevk: yeah about URL parsing, I understood what you meant. Maybe plain-old "round-trippable" is a better term |
| 14:25 | <Hixie_> | annevk: see bug 18460 |
| 14:25 | <annevk> | SimonSapin: I meant HTML as in the HTML Standard |
| 14:26 | <Hixie_> | annevk: and bug 17976 |
| 14:26 | <annevk> | SimonSapin: I think our XSLT APIs might allow for non-XML DOMs to be used though, haven't played with that |
| 14:26 | <annevk> | Hixie_: yeah I'm aware, I don't care enough really to fix that up, if it was up to me we'd nuke <?xml-stylesheet?> |
| 14:26 | <Hixie_> | ditto |
| 14:28 | <zcorpan> | Hixie_: i've made CSSOM only know about CSS as the supported styling language, btw |
| 14:28 | <annevk> | zcorpan: heh, that's pretty much why I'm looking into this (different exploit of course) |
| 14:29 | <annevk> | zcorpan: Hixie_: I think embracing CSS / JavaScript makes sense as we'd have to rethink a whole lot of things anyway when it comes to introducing something new |
| 14:30 | <annevk> | zcorpan: Hixie_: also, for most other features our extensibility story is almost never that we anticipate something new but that we leave ways for new things to be introduced later |
| 14:30 | <Ms2ger> | Hixie_, if you want to know about xslt, you just need to ask hsivonen :) |
| 14:30 | <annevk> | zcorpan: Hixie_: seems kinda weird that for CSS and JavaScript we explicitly call out some theoretical non-CSS and non-JavaScript thingies |
| 14:30 | <zcorpan> | annevk: yeah. the features have intertwingled with css and js specifics anyway already |
| 14:31 | <zcorpan> | so the theory is just an illusion |
| 14:31 | <annevk> | right |
| 14:52 | <Hixie_> | Ms2ger: pretty sure he's cc'ed on those bugs |
| 14:53 | <Hixie_> | zcorpan: vbscript and dart have both been implemented in browsers, so it's not that much an illusion. it's just that we're not doing a good job of it. |
| 14:53 | <Hixie_> | (and i agree that we shouldn't...) |
| 14:56 | <zcorpan> | Hixie_: dart has a separate API for the DOM, right? |
| 14:57 | <Hixie_> | probably |
| 15:02 | <annevk> | rillian: http://quuz.org/webvtt/ has that error message you wanted now |
| 15:03 | <annevk> | rillian: see https://github.com/annevk/webvtt/commit/89316fa128668bd953be9db162dd9751a990f4d7 for the change if you're interested |
| 15:41 | <Hixie_> | rafaelw: ping |
| 15:50 | <SteveF> | question: does the browser update the value if you do a setfocus on an element whose tabindex value is set to -1? or does it just return the tabindex value for the element as set in the element attribute set? and where is this specced? |
| 15:51 | <annevk> | SteveF: as an editor of HTML5.1... |
| 15:52 | <SteveF> | annevk: I don't expect to know everything and thats HTML 5.1 to you ;-) |
| 15:52 | <annevk> | SteveF: you correct spelling of such things is quite rich, but fair enough |
| 15:52 | <SteveF> | annevk: and am happy to show my ignorance in order to get a helpful answer |
| 15:52 | <annevk> | correcting, even |
| 15:53 | <SteveF> | annevk: tongue in cheek is the term i would use, so do you know i just wanted to bait me? |
| 15:54 | <annevk> | SteveF: it's not entirely clear what your question means, but I do know the answer can be found in HTML |
| 15:54 | <SteveF> | or just |
| 15:54 | <SteveF> | OK so will look some more |
| 15:55 | <annevk> | SteveF: e.g. whether you're talking about the DOM property or the content attribute |
| 15:55 | <annevk> | SteveF: and what "value" refers to |
| 15:58 | <SteveF> | annevk: I am talking about the HTMLElement interface property. Not the content attribute |
| 15:58 | <SteveF> | interface HTMLElement : Element { |
| 15:58 | <SteveF> | // metadata attributes |
| 15:58 | <SteveF> | attribute DOMString title; |
| 15:58 | <SteveF> | attribute DOMString lang; |
| 15:58 | <SteveF> | attribute boolean translate; |
| 15:58 | <SteveF> | attribute DOMString dir; |
| 15:58 | <SteveF> | readonly attribute DOMStringMap dataset; |
| 15:58 | <SteveF> | // user interaction |
| 15:58 | <SteveF> | attribute boolean hidden; |
| 15:58 | <SteveF> | void click(); |
| 15:58 | <SteveF> | attribute long tabIndex; |
| 15:58 | <SteveF> | annevk: btw asking for a friend |
| 15:59 | <annevk> | "The tabIndex IDL attribute must reflect the value of the tabindex content attribute. Its default value is 0 for elements that are focusable and −1 for elements that are not focusable." |
| 16:00 | <SteveF> | annevk: thanks |
| 16:05 | <Hixie_> | annevk: you don't honestly expect w3c editors to have read the spec they're editing, do you? |
| 16:06 | <annevk> | I was going to say "I don't even" but I think I reached my quota for that |
| 16:07 | annevk | defers to the topic |
| 16:07 | <Hixie_> | (one would imagine that "reading the spec" would be a prerequisite for being assigned as editor or chair, but...) |
| 16:18 | <Hixie_> | darobin: since rafaelw's not around, maybe you can help. do you have any idea why rafael and tony added the "in html scope" thing? Isn't it equivalent to just asking if the element is in the stack at all? |
| 16:18 | <Hixie_> | darobin: (or for that matter, do you have any info on the questions i was asking yesterday, like, "<body><template><body></body><!---->; where does the comment go?") |
| 16:19 | <annevk> | Hixie_: are you considering nested <template> elements? |
| 16:20 | <annevk> | (I haven't read the <template> spec in detail, just thinking some of it might be related to that) |
| 16:21 | <Hixie_> | yes |
| 16:21 | <Hixie_> | i don't think nested templates do anything special in these cases |
| 16:21 | <Hixie_> | but i could be wrong, certainly |
| 16:26 | <annevk> | Hixie_: reading it, it does seem like all it means is if there's a <template> on the stack |
| 16:27 | <Hixie_> | it can't just be that, surely. otherwise why woudl rafael and tony and darobin all write it the way they did instead of the simpler way. |
| 16:28 | <annevk> | Hmm, how does that stack concept work? Don't <template> elements have their own stack? |
| 16:29 | <Hixie_> | of open elements? |
| 16:29 | <Hixie_> | there's just one of those |
| 16:30 | <Hixie_> | i'm really confused by 7.7 |
| 16:30 | <Hixie_> | why do they only add "template" to the table scope list |
| 16:30 | <Hixie_> | surely it should be in all the scope lists? |
| 16:33 | annevk | is lost |
| 16:33 | annevk | goes back to hacking his URL parser |
| 16:33 | <Hixie_> | eh |
| 16:33 | <Hixie_> | heh even |
| 16:34 | <Hixie_> | next question. why does <template> not reset the frameset-ok flag? |
| 16:35 | Hixie_ | also wonders why they went with "template contents" instead of "in template" for the insertion mode, given the style of all the other modes |
| 16:43 | <annevk> | Hixie_: consistency does not seem high on the list for most people; e.g. CSP decided to use URI throughout contrary to most of the platform |
| 16:45 | <rafaelw> | hixie: here now. |
| 16:47 | <rafaelw> | yes. that is the idea. |
| 16:47 | <rafaelw> | i'd be fine saying it a different way. |
| 16:49 | <Hixie_> | rafaelw is here! woot |
| 16:49 | <Hixie_> | rafaelw: ok, let me go back to my list of questions. i hope you slept well. :-) |
| 16:50 | <Hixie_> | rafaelw: given <button><template><button>, should the template have a button in it? |
| 16:52 | <Hixie_> | (currently chrome says yes, firefox says no) |
| 16:52 | <Hixie_> | (as far as i can tell, the spec says no) |
| 16:53 | <Hixie_> | (but it seems like yes is the better answer? from my naive perspective, anyway...) |
| 16:53 | <Hixie_> | basically this boils down to "should 'template' be added to the various lists of "in foo scope" elements, in addition to just the "in table scope" one that is specified currently" |
| 17:02 | <Hixie_> | (i guess we don't have to add it to the select scope list, i can't see a way in which that would affect parsing) |
| 17:05 | <rafaelw> | yes. slept better. |
| 17:05 | <rafaelw> | thanks. |
| 17:05 | <rafaelw> | good question. i don't think this came up previously. |
| 17:05 | <rafaelw> | looking |
| 17:08 | <dglazkov> | good morning, Whatwg! |
| 17:08 | <Hixie_> | rafaelw: similar question would be how to parse <body><template><body></body><!--x--> |
| 17:09 | <Hixie_> | rafaelw: in firefox and the spec, the comment ends up outside the template. in chrome, it goes inside the tempalte |
| 17:09 | <Hixie_> | (in neither case does a second <body> get created, obviously) |
| 17:10 | <rafaelw> | Ok. So WebKit/blink added template as a new element in the set of scope markers. |
| 17:10 | <Hixie_> | (nor do attributes on the second get propagated) |
| 17:10 | <rafaelw> | I know this was intentional. |
| 17:10 | <Hixie_> | seems like the right thing to do |
| 17:10 | <rafaelw> | That explains the button example. |
| 17:11 | <rafaelw> | I know the spec adds template as a "special" element. |
| 17:11 | <rafaelw> | (which means it gets a cute hat) |
| 17:12 | <Hixie_> | it also explains the comment example, i think |
| 17:13 | <Hixie_> | the scope thing, i mean |
| 17:13 | <Hixie_> | not the hat :-) |
| 17:15 | <MikeSmith> | Hixie_: btw not to break your train of thought, but in <p><style scoped>/* first */</style><style scoped>/* second */</style> is the second <style> instance valid or should it be reported as an error? |
| 17:15 | <rafaelw> | I think maybe the spec needs to add template as a (general) scope marker. |
| 17:15 | <Hixie_> | MikeSmith: off the top of my head, should be valid, i think. is the spec unclear? |
| 17:15 | <Hixie_> | rafaelw: k |
| 17:16 | <annevk> | you cannot have <body> inside <template>? that's kinda sad |
| 17:16 | <rafaelw> | you can't have <body><head> or <frameset> inside a template. |
| 17:16 | <rafaelw> | allowing this would have made the parser changes WAY more invasive. |
| 17:16 | <MikeSmith> | Hixie_: I'll make it valid in the validator for now but it's not clear to me from the spec, so I'll file a bug |
| 17:16 | <Hixie_> | yeah |
| 17:17 | <Hixie_> | MikeSmith: cool, thanks man |
| 17:17 | <Hixie_> | rafaelw: so next question |
| 17:17 | <Hixie_> | annevk: what's the use case? |
| 17:17 | <Hixie_> | rafaelw: <table><tr><td><select><template></template><caption>A</table> vs <table><tr><td><select><xxxxxxxx></xxxxxxxx><caption>A</table> |
| 17:17 | <Hixie_> | rafaelw: is the difference intentional? |
| 17:18 | <annevk> | Hixie_: creating generic template for some <iframe>s |
| 17:18 | <Hixie_> | rafaelw: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2374 |
| 17:18 | <Hixie_> | annevk: just do the template for the contents of the <body> and dump it into the body |
| 17:18 | <Hixie_> | annevk: no need to explicitly list the body in the template |
| 17:19 | <Hixie_> | annevk: unless you mean you want to template the whole thing, <head>, <title>, and all? |
| 17:19 | <rillian> | annevk: thanks! |
| 17:19 | <rafaelw> | (working) |
| 17:19 | <annevk> | Hixie_: you might want to modify some attributes on <body> too, but sure |
| 17:20 | <annevk> | Hixie_: just seems annoying to have exceptions given how generic it otherwise is |
| 17:21 | <Hixie_> | annevk: no disagreement there |
| 17:21 | <Hixie_> | annevk: seems like if you're going to template the whole document, though, you might as well... just use a document |
| 17:21 | <annevk> | badum tish |
| 17:22 | <TabAtkins> | Hixie_: One use-case I saw was a code editor, which will put the code into an <iframe> afterwards. |
| 17:22 | <TabAtkins> | And it wants its contents to be used literally, like a <textarea>. |
| 17:23 | <Hixie_> | can you elaborate on how <template> fits in here? |
| 17:24 | <TabAtkins> | Well, I was thinking that a <template> could be wrapped around the contents to "protect" it. |
| 17:24 | <TabAtkins> | But then, <xmp> can be used just as well for this case. |
| 17:25 | <Hixie_> | or <textarea> :-) |
| 17:25 | <annevk> | except <xmp> is non-standard |
| 17:27 | <rafaelw> | Hixie: does it make sense to you why the later case doesn't ignore the <caption>A |
| 17:27 | <rafaelw> | ? |
| 17:28 | <rafaelw> | Clearly Chrome doesn't, but I'm not getting why yet |
| 17:28 | <rafaelw> | Seems like you stay in InSelect mode and keep ignoring tokens. |
| 17:28 | <rafaelw> | What am I mising. |
| 17:28 | <rafaelw> | ? |
| 17:28 | <Hixie_> | rafaelw: yeah, it's because the reset algorithm resets to 'in select' instead of 'in select in table' which is what it was in before |
| 17:28 | <Hixie_> | it's easily fixed by making the reset algorithm detect that case |
| 17:29 | <Hixie_> | (i think... haven't checked what that would entail yet) |
| 17:29 | <Hixie_> | (i hope it would just entail checking the stack for a <td> or <th>) |
| 17:29 | <Hixie_> | (or <caption>) |
| 17:29 | <rafaelw> | Ah. |
| 17:29 | <rafaelw> | I see. Thank you. |
| 17:29 | <Hixie_> | (or any table node, maybe?) |
| 17:29 | <rafaelw> | <sigh> |
| 17:29 | <rafaelw> | Well, the reset would need to do more work in this case. |
| 17:30 | <Hixie_> | yeah, but only in the case that it currently detects a "select" |
| 17:30 | <Hixie_> | so it's not a hot path |
| 17:30 | <rafaelw> | If it finds a <select> it would need to look further up to see if the select is in a table. |
| 17:30 | <Hixie_> | yeah |
| 17:30 | <rafaelw> | No. |
| 17:30 | <rafaelw> | Good catch. |
| 17:30 | <Hixie_> | so, i should fix that one? |
| 17:31 | <rafaelw> | so aside from just popping a <template>, how else can reset get called with <select> as the bottom element? |
| 17:32 | <Hixie_> | the only way it could before <template> was innerHTML, i think |
| 17:32 | <Hixie_> | (incidentally, i think i'm gonna remove all the "(fragment case)" annotations, they're becoming really convoluted to maintain and not that useful as far as i can tell) |
| 17:33 | <rafaelw> | no complaint. |
| 17:34 | <rafaelw> | i only see three places that reset: </template> (generally), </table> (when InTable), and </select> (when InSelect) |
| 17:34 | <rafaelw> | don't think the later two can have a <template> as the bottom element afterwards. |
| 17:34 | <rafaelw> | Seems safe. |
| 17:34 | <rafaelw> | I'll open a w3c bug |
| 17:34 | <bholley> | Hixie_: curious about https://www.w3.org/Bugs/Public/show_bug.cgi?id=22102#c6 when you get the chance. Let me know if there's some better way to get questions like that in your queue |
| 17:35 | <TabAtkins> | annevk: <xmp> is perfectly well-standardized. It's just hidden away. ^_^ |
| 17:35 | <annevk> | okay... |
| 17:36 | <bholley> | Hixie_: FWIW, I think it would be awesome to get NEEDINFO up and running on the WHATWG bugzilla. It's majorly helpful on BMO |
| 17:36 | <rafaelw> | Hixie: So does reset insertion mode need to just look at the previous element to see if it's a table cell element? |
| 17:37 | <Hixie_> | rafaelw: not just previous, it needs to check if there's a table-related element in scope, i think. for some definition of scope. |
| 17:37 | <Hixie_> | rafaelw: i haven't worked otu exactly what it should be yet. |
| 17:38 | <Hixie_> | bholley: best way is just to reopen the bug, if you want me to look at it :-) looking now... |
| 17:38 | <bholley> | Hixie_: ok - wasn't sure if that was kosher :-) |
| 17:38 | <Hixie_> | bholley: hm, yeah, dunno why i thought window.document was accessible per spec. |
| 17:38 | <Hixie_> | bholley: oh definitely feel free to reopen bugs |
| 17:38 | <Hixie_> | bholley: not a problem |
| 17:38 | <bholley> | Hixie_: ok, cool |
| 17:38 | <Hixie_> | bholley: especially from you! |
| 17:38 | <bholley> | :-) |
| 17:38 | <bholley> | Hixie_: also curious about comment 7 |
| 17:38 | <Hixie_> | bholley: Storage is accessible cross-domain when you change document.domain |
| 17:39 | <Hixie_> | bholley: it's the one thing that gets neutered when you change d.d |
| 17:39 | <bholley> | Hixie_: why that and only that? |
| 17:39 | <bholley> | Hixie_: (Gecko neuters everything) |
| 17:40 | <Hixie_> | bholley: well, other things don't get neutered because they never did (gecko is a lone pioneer in changing that, currently) |
| 17:40 | <bholley> | Hixie_: (Presto too, but that's kind of moot these days) |
| 17:40 | <rafaelw> | How does the <select> rule for InBody get reached if the insertion mode is InTable, InTableBody etc... |
| 17:40 | <Hixie_> | bholley: but Storage has to be neutered because otherwise it breaks the ability to do locking or some such |
| 17:40 | <Hixie_> | rafaelw: the "any other" rule falls through to in body |
| 17:40 | <bholley> | Hixie_: locking? |
| 17:41 | <Hixie_> | bholley: storage mutex |
| 17:41 | <Hixie_> | bholley: on a per-origin basis |
| 17:41 | <Hixie_> | not that anyone actually implements that |
| 17:41 | <Hixie_> | but the spec tries to keep it possible |
| 17:43 | <Hixie_> | rafaelw: the next question, assuming you agree we should fix the reset algorithm for that rare edge case of 'in select', is more editorial, i hope. the spec uses "template element in html scope" -- does that just mean the same as "has a template element in the stack of open elements"? |
| 17:43 | <bholley> | Hixie_: Ah, I see. It would be helpful to mention that in the spec at http://www.whatwg.org/specs/web-apps/current-work/#security-localStorage - I'll file a bug |
| 17:43 | <Hixie_> | bholley: thanks |
| 17:44 | <bholley> | Hixie_: np |
| 17:44 | <rafaelw> | hixie: yes |
| 17:44 | <rafaelw> | so presumably the point of the in select in table mode is to allow tables to close when there is a select inside which fails to close itself? |
| 17:46 | <Hixie_> | rafaelw: yeah |
| 17:46 | <Hixie_> | rafaelw: (welcome to legacy web parsing) |
| 17:46 | <rafaelw> | :-( |
| 17:47 | <Hixie_> | rafaelw: oh another question, when you see <template> you don't reset the frameset-ok flag. is that intentional? i don't remember how that flag works exactly... |
| 17:48 | <Hixie_> | i guess it must be, or you couldn't have a template in <head> and then use <frameset> |
| 17:49 | <rafaelw> | Filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22482 |
| 17:51 | <Hixie_> | cool |
| 17:51 | <Hixie_> | k, the only other thing i had on my list so far is a small comment on the way the ownerDocument requirement is phrased |
| 17:51 | <Hixie_> | right now it only actually sets ownerDocument to the template doc for nodes that are children of the <template> |
| 17:52 | <Hixie_> | so e.g. <template><div><img src='...'> would create the <div> in the template doc, but it doesn't say what the <img> would be created in |
| 17:52 | <Hixie_> | i assume that's just an oversight? |
| 17:54 | <rafaelw> | hixie: frameset-ok. |
| 17:54 | <Hixie_> | man, i really did a poor job of putting the start tag / end tag cases in the spec in any sort of sane order |
| 17:57 | <TabAtkins> | I'd always wondered what order you based that on. |
| 17:57 | <rafaelw> | I'm pretty sure setting frameset-ok inside template would allow <frameset> |
| 17:58 | <rafaelw> | which we don't want. |
| 17:58 | <Hixie_> | rafaelw: it's set by default, and right now you don't unset it |
| 17:58 | <rafaelw> | i'm now trying to convince myself that the parser *can't* currently end up inside <template> with frameset-ok set to 'ok' |
| 17:58 | <Hixie_> | rafaelw: if you unset it, you'd prevent <head><template></template><frameset> from working |
| 17:59 | <Hixie_> | rafaelw: currently you do indeed support <head><template><frameset>; i haven't checked to see what that implies. |
| 18:00 | <Hixie_> | (not sure why it doesn't get parsed in firefox) |
| 18:00 | <Hixie_> | (or chrome) |
| 18:00 | <Hixie_> | oh, i see |
| 18:01 | <rafaelw> | nope. that throws away the <frameset>. |
| 18:01 | <Hixie_> | <frameset> only gets parsed after head and in body |
| 18:01 | <Hixie_> | and in body only if you've already seen a <body> but are still frameset-ok |
| 18:02 | <Hixie_> | yeah i haven't studied this closely enough yet to have educated things to say about it |
| 18:02 | <Hixie_> | i'll add it to my list |
| 18:09 | <rafaelw> | I see |
| 18:09 | <rafaelw> | . |
| 18:09 | <rafaelw> | We don't need to unset it because the test for in body on <frameset> fails if a template is open. |
| 18:09 | <rafaelw> | If the second element on the stack of open elements is not a body element, or, if the stack of open elements has only one node on it, then ignore the token. (fragment case) |
| 18:09 | <rafaelw> | == false |
| 18:10 | <rafaelw> | this is the case for <head><template><frameset> |
| 18:13 | <rafaelw> | Also opened: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22484 |
| 18:17 | <Hixie_> | cool |
| 18:20 | <Hixie_> | so here's an interesting case: <!DOCTYPE html>�<template></template><frameset></frameset> |
| 18:20 | <Hixie_> | the U+0000 null character pushes us into <body> mode, but doesn't reset the frameset-ok flag |
| 18:20 | <Hixie_> | we then parse the <template>, then get to the <frameset>, and we're still frameset-ok |
| 18:20 | <Hixie_> | so we nuke the entire <body>, <template> and all, and replace it with a <frameset>. |
| 18:21 | <Hixie_> | you'd get the same result with <!DOCTYPE html>�<!-- --><frameset></frameset> |
| 18:21 | <Hixie_> | or <!DOCTYPE html>�<link><frameset></frameset> |
| 18:21 | <Hixie_> | so it's probably ok to keep it with <template> |
| 18:25 | <Hixie_> | rafaelw: what's the change that's intended to the "A start tag whose tag name is "frameset"" part of "in body"? is it just changing the parenthetical? |
| 18:26 | <rafaelw> | yes. |
| 18:26 | <rafaelw> | before, this could only happen in the fragment case. |
| 18:26 | <rafaelw> | now it's template case as well. |
| 18:28 | <Hixie_> | k |
| 18:50 | <Yuhong> | IE10 finally supports Mutation Observers: http://msdn.microsoft.com/en-us/library/ie/dn265034(v=vs.85).aspx |
| 18:50 | <Yuhong> | *IE11 |
| 18:51 | <Yuhong> | But with two releases of IE only supporting Mutation Events, I wonder if they can ever be removed from the platform. |
| 19:26 | <smaug____> | dglazkov: curious, what does "registration context." actually mean |
| 19:26 | <smaug____> | the window of a document may change |
| 19:38 | <gsnedders> | What tree should <p><table></p> give per spec? |
| 19:40 | <dglazkov> | smaug____: when? tell me more. |
| 19:41 | <smaug____> | dglazkov: I filed a bug |
| 19:41 | <smaug____> | dglazkov: but document.open |
| 19:41 | <dglazkov> | smaug____: great! |
| 19:42 | <smaug____> | http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-document-open step 15 |
| 19:42 | <dglazkov> | aha |
| 19:50 | <smaug____> | dglazkov: webkit at least used to have buggy document.open, so blink may have too |
| 19:51 | <dglazkov> | smaug____: right, we don't create new Window, or Document for that matter |
| 19:51 | <smaug____> | document.open obviously doesn't create a new document ;) |
| 19:52 | <dglazkov> | smaug____: sorry, right |
| 19:52 | <smaug____> | (well, it does, if it forwards open call to window, but that is not the case we're talking here) |
| 19:52 | <Hixie_> | not sure if this is relevant here, but note that a Window's Document can change too |
| 19:52 | <dglazkov> | intuitively, if I call document.open, I should probably blow away the custom element registry |
| 19:52 | <Hixie_> | specifically, if you open an iframe then navigate it, the Document changes from the about:blank one to a new one, but the Window remains. |
| 19:53 | <dglazkov> | Hixie_: that part's okay. |
| 19:53 | <Hixie_> | ok just checking |
| 19:53 | <dglazkov> | it's the other way around that I haven't thought through |
| 19:53 | <dglazkov> | smaug____: thanks for checking on me :) |
| 19:56 | <Hixie_> | rafaelw: why does the in body EOF token handler defer to the template contents EOF handler? |
| 19:56 | <Hixie_> | rafaelw: does it do something in particular that you're looking to trigger? |
| 19:58 | <gsnedders> | So <p><table><p> is the only case in which you can get a p element as a child of a p element from the parser. Lovely. Seems a bit horrible. |
| 19:58 | <Hixie_> | gsnedders: only in quirks mode right? |
| 19:58 | <gsnedders> | Yes. |
| 19:58 | <Hixie_> | and that's why quirks mode is non-conforming. |
| 19:58 | <gsnedders> | I may have just caused myself and abarth a panic through not realizing that. :) |
| 19:59 | <Hixie_> | no panicking abarth |
| 19:59 | <abarth> | :) |
| 19:59 | <Hixie_> | panicking security researchers can have adverse effects |
| 20:00 | gsnedders | is now imagining abarth as having a big red STOP EVERYTHING button next to him :) |
| 20:00 | <abarth> | SHUT DOWN EVERYTHING |
| 20:02 | <Hixie_> | i don't understand the EOF handling in the <template> spec |
| 20:03 | <Hixie_> | it looks like <template>.innerHTML = '' never stops parsing, for instance. |
| 20:03 | <gsnedders> | Hixie_: So html5lib has 49 tests that don't roundtrip (take tree, serialize, parse, compare tree). I wonder if this is worthwhile trying to reduce. If we ignore html5lib's serializer's brokenness with <plaintext>, it takes it down to 36. Things like <p><table><p> having no obvious serialization when presented with the tree (XML: <p><p/><table/></p>). |
| 20:04 | <abarth> | data:text/html,<template id="foo"><script>alert("no template support")</script></template><script>document.getElementById("foo").innerHTML = "";alert(1)</script> |
| 20:04 | <abarth> | seems to termiante |
| 20:04 | <Hixie_> | if there are any that are conforming inputs, that's definitely a problem |
| 20:04 | <abarth> | maybe the spec doesn't match the impl? |
| 20:05 | <Hixie_> | abarth: well by "doesn't stop parsing" i mean the behaviour is undefined. You run out of tokens, but never get to invoke the "stop parsing" steps. |
| 20:06 | <Hixie_> | gsnedders: as a general rule there's lots of things that parse into a state that can't be represented in conforming content |
| 20:07 | <Hixie_> | gsnedders: and the serialisation only tries to form conforming content |
| 20:07 | <Hixie_> | gsnedders: e.g. anything involving the form pointer would fail to round-trip correctly (i doubt html5lib would even catch that case) |
| 20:07 | <Hixie_> | gsnedders: but i'm happy to examine the cases if you want to talk about any in particular |
| 20:07 | <Hixie_> | especially now that i've the parser swapped in |
| 20:09 | <gsnedders> | BTW, can you remember what the "CDATA" category was renamed to? |
| 20:09 | <gsnedders> | escapable raw text elements, actually |
| 20:09 | <Hixie_> | yeah, sounds right |
| 20:09 | gsnedders | realizes he could just look what elements are in that group and compare :P |
| 20:09 | <Hixie_> | that's in syntax, not in parsing |
| 20:10 | <Hixie_> | parser still uses cdata |
| 20:10 | <rafaelw> | hixie: yes, all the potentially nested <template>s need to unwind. |
| 20:10 | <Hixie_> | rafaelw: why? |
| 20:10 | <gsnedders> | Hixie_: Parser doesn't have CDATA, just RCDATA |
| 20:10 | <Hixie_> | rafaelw: or rather, what does that do that just popping all the nodes like the "stop parsing" rules say to do doesn't do? |
| 20:10 | <Hixie_> | gsnedders: oh, right |
| 20:10 | <Hixie_> | gsnedders: cdata is raw text, rcdata is escapable raw text. or something. |
| 20:11 | <rafaelw> | let me see what it breaks =-) |
| 20:11 | <Hixie_> | rafaelw: i don't see anything that acts outside the parser in the </template> handling... |
| 20:11 | <Hixie_> | quite possible i'm missing something though |
| 20:12 | <gsnedders> | Hixie_: Right, so CDATA became RCDATA, and RCDATA became RAWTEXT it would appear. |
| 20:12 | <rafaelw> | I know there was a reason. We had a lengthy discussion about it. |
| 20:12 | <rafaelw> | Actually, let me try to find the bug |
| 20:12 | <gsnedders> | html5lib ought rename them before I get even more confused :) |
| 20:12 | <Hixie_> | gsnedders: that doesn't sound right |
| 20:13 | <gsnedders> | html5lib has cdata: title, textarea; rcdata: style, script, xmp, iframe, noembed, noframes, noscript |
| 20:13 | <rafaelw> | hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20924 |
| 20:14 | <Hixie_> | aah, after-head |
| 20:14 | <Hixie_> | ok |
| 20:14 | <rafaelw> | basically, it's possible to hit EOF in body (in head) |
| 20:16 | <Hixie_> | yeah, this makes sense |
| 20:20 | <gsnedders> | Hixie_: Given I've forgotten the conclusion here, do we want nested a elements being created by the parser? |
| 20:21 | <gsnedders> | (non-conforming case) |
| 20:23 | <Hixie_> | gsnedders: in what case? |
| 20:23 | <Hixie_> | gsnedders: we definitely can end up with it if there's enough scoping going on, i would guess |
| 20:23 | <Hixie_> | gsnedders: maybe e.g. <a><table><tr><td><a> or some such |
| 20:23 | <Hixie_> | or <a><button><a>, i dunno off-hand what scoping "a" start tags check |
| 20:23 | <gsnedders> | Hixie_: Yeah, that sort of case |
| 20:23 | <Hixie_> | pretty sure that yes |
| 20:42 | <Hixie_> | i wonder why "in table"'s EOF rule doesn't defer to in body |
| 20:42 | <Hixie_> | it's basically the same thing... |
| 21:16 | <Hixie_> | i wonder why we support <template><frame><frameset> but not <template><frameset><frame> |
| 21:22 | <Hixie_> | this has to be an error |
| 21:23 | <Hixie_> | if i'm reading this right, the spec says <template><frame><frameset></frameset><frameset></frameset> ignores the end tags. |
| 21:36 | <zcorpan> | gsnedders: CDATA didn't become RCDATA. CDATA just became RAWTEXT. and RCDATA was always RCDATA |
| 21:36 | <zcorpan> | gsnedders: and the writing section renamed RCDATA to escapable text elements |
| 21:37 | <zcorpan> | s//raw/ |
| 21:38 | <zcorpan> | gsnedders: looks like html5lib has cdata and rcdata backwards re http://krijnhoetmer.nl/irc-logs/whatwg/20130626#l-1058 |
| 21:41 | <Hixie_> | i think you mean "s//raw/dwim" :-P |
| 21:42 | <gsnedders> | zcorpan: Weird. |
| 21:46 | <Hixie_> | hmm... i wonder why link, script, style, meta, and template are treated differently than base, basefont, bgsound, noframes, and title in <template> |
| 21:46 | <Hixie_> | maybe that's a web component thing... |
| 22:02 | <zcorpan> | Hixie_: those flags are on by default in irc :-) |
| 22:12 | <gsnedders> | html5lib-tests needs people to actually review stuff if it's actually going to be review-then-commit |
| 22:21 | <jgraham> | gsnedders: Sure. Encourage other people to become reviewers on that repo. But I might have time tomorrow (although I have said that about a number of other things) |
| 22:22 | <jgraham> | gsnedders: Oh, wait, it's not even in critic |
| 22:22 | <jgraham> | OK, first I should fix that, then you should encourage other people to become reviewers for it |
| 22:23 | <jgraham> | But tomorrow |
| 22:24 | <gsnedders> | jgraham: You've agreed to fix that before :P |
| 22:24 | <jgraham> | Or "today, after I sleep", if you don't speak en-GB-x-Hixie |
| 22:24 | <jgraham> | gsnedders: Well, maybe |
| 22:24 | <jgraham> | It is tedious to fix at the moment because it needs manual setup |
| 22:24 | <jgraham> | Still not going to do it before the morning though |
| 22:25 | <gsnedders> | Okay, so html5lib would now fail a lot of the tokenizer tests if it were up to date with the submodule. |