| 00:00 | <TabAtkins> | Largely *because* you're the last one to the party. Also because you're Hixie. |
| 00:00 | <Hixie> | uh huh :-| |
| 00:00 | <rafaelw> | What criticism do you expect? |
| 00:01 | <Hixie> | rafaelw: that we are "unilaterally ruining the web" and "making the beautiful world that is xml" be all "ruined" and so forth |
| 00:02 | <rafaelw> | oh....that.... |
| 00:02 | <rafaelw> | ;-) |
| 00:02 | <zewt> | ruining xml |
| 00:03 | <rafaelw> | I think that maintaining the XHTML/HTML equivalence was a good thing, |
| 00:03 | <zewt> | is that like emptying a bag of dirt into a port-a-potty |
| 00:03 | <rafaelw> | but to be honest, I kind of feel like I'm happy letting the XML folks decide for themselves. |
| 00:04 | <rafaelw> | You can XHTML/HTML equivalence or not change the XML parser. Not both. |
| 00:04 | <Hixie> | yup |
| 00:04 | <rafaelw> | The thing that isn't reasonable is claiming that HTML parsing should never be able to express anything that the XML parser can't understand -- if you're uninterested in changing the XML parsing. |
| 00:06 | <Hixie> | yeah, no need to convince me |
| 00:06 | <Hixie> | :-) |
| 00:06 | <Hixie> | i'm the first one to suggest divergent parsing and so forth |
| 00:06 | rafaelw | gets down off the soap box. |
| 01:23 | <zewt> | hearing "WebVTT depending on TTML", loading TTML spec, hoping it's just a *really* bad joke |
| 01:52 | <nessy> | zewt: that's definitely a misunderstanding! |
| 01:53 | <zewt> | from the number of posts talking about using TTML for chapters in webvtt, i sure wonder how it could be :) |
| 02:43 | <nessy> | zewt: there's a difference between WebVTT and the TextTrackAPI |
| 02:43 | <nessy> | but I'm sure that thread is confusing to some |
| 02:46 | <nessy> | I'm gonna let go for now - I'm obviously not making my point well enough :-) |
| 04:00 | <MikeSmith> | rafaelw, Hixie : regarding the XML partisans potentially making a fuss about the parsing and XSLT/XPath changes: Do we expect that tools other than browsers are going to need to do any special processing of <template>? Or that we'd even want them to? |
| 04:03 | <Hixie> | MikeSmith: dunno |
| 04:03 | <MikeSmith> | ok |
| 04:04 | <Hixie> | MikeSmith: i would imagine that xslt would want to have the same result whether done on a dom tree parsed by a browser or offline |
| 04:05 | <MikeSmith> | Hixie: even if the purpose of the xslt is to generate something that's then going to be sent over the wire to Web clients? |
| 04:05 | <Hixie> | i guess it's possible that you never want to use the same xslt on a browser and on a server if you're using <template>, independent of the different parse behaviour |
| 04:07 | <MikeSmith> | but wait is the spec actually defining any change in XSLT behavior anyway? |
| 04:07 | <Hixie> | xml behaviour |
| 04:07 | <MikeSmith> | it says, "XSLT processing should to treat template contents as descendants of the template element when contained in XHTML input of an XSLT transform and place the descendants of a template element into template contents in XSLT output." |
| 04:07 | <Hixie> | oh, interesting |
| 04:07 | <Hixie> | ok so the difference would be with other technologies like xslt that aren't xslt |
| 04:08 | <MikeSmith> | of course XPath handling is different though |
| 04:08 | <Hixie> | just so we're clear, i personally am not particularly worried one way or the other :-) |
| 04:10 | <MikeSmith> | heh :) |
| 04:10 | <MikeSmith> | yeah, I figured |
| 04:12 | a-ja | decides not to hold his breath waiting for two interoperable implementations |
| 04:37 | <MikeSmith> | manu-db: it would really help if the definitions of shared terminology in the RDFa spec were unambiguous. Or even if they were defined at all. |
| 04:38 | <MikeSmith> | re: http://www.w3.org/TR/rdfa-syntax/#A-prefix |
| 04:39 | <MikeSmith> | the spec doesn't define what a "white space separated list" is |
| 04:53 | <MikeSmith> | OK now I find http://www.w3.org/TR/rdfa-syntax/#white_space |
| 04:54 | <MikeSmith> | "When attributes accept a white space separated list of tokens, an RDFa Processor must ignore any leading or trailing white space." |
| 04:55 | <MikeSmith> | I'm not actually implementing a conforming RDFa Processor (nor need to to) but OK |
| 05:04 | <Hixie> | how the hell does the AAA ever trigger foster parenting in step 10 |
| 05:06 | <Hixie> | oh, duh |
| 05:06 | <Hixie> | nevermind |
| 06:57 | <zcorpan_> | hmm. didn't the spec used to have "escaped text spans" for things like <title>& <!-- & --></title>? |
| 06:59 | <zcorpan_> | i guess it was dropped as part of the script parsing rewrite |
| 07:04 | <zcorpan_> | so we accidentally killed a quirk that turned out to not be necessary for compat |
| 07:04 | <zcorpan_> | (quirk as in weird behavior, not related to the modes) |
| 08:18 | jgraham | note to self: quote Hixie on "one clear algorithm" later :) |
| 08:51 | <annevk> | http://what-if.xkcd.com/51/ what about the squirrel suit?!! |
| 08:58 | <jgraham> | Isn't a squirrel suit a type of wingsuit? I'm not sure that literally dressing as a squirrel would help nearly as much… |
| 09:01 | <annevk> | Oh it is. Disappointing. |
| 09:44 | <tobie> | ^ :D |
| 09:57 | <zcorpan_> | annevk: do you recall why MediaList has a stringifier? |
| 09:57 | <annevk> | zcorpan_: I think I had some idea of .media returning a MediaList |
| 09:58 | <zcorpan_> | annevk: which .media? |
| 09:58 | <annevk> | zcorpan_: all of them :) |
| 09:58 | <zcorpan_> | <link>.media? |
| 09:59 | <annevk> | Yeah, back then <a> too, but that's gone it seems |
| 09:59 | <annevk> | Note that I'm no longer sure if that's actually realistic |
| 09:59 | <annevk> | Or a good idea really, MediaList is not a great API |
| 10:00 | <zcorpan_> | maybe i can use [PutForwards=mediaText] on StyleSheet.media at least |
| 10:01 | <zcorpan_> | similar to .style |
| 10:01 | <zcorpan_> | i'm not sure it's a good idea to make <link>.media return MediaList since a <link> doesn't necessarily have a style sheet to begin with |
| 10:02 | <zcorpan_> | but changing media="" should probably update mediaText |
| 10:02 | <annevk> | Well, .media always holds media queries |
| 10:02 | <zcorpan_> | true |
| 10:03 | <annevk> | Oh, MediaList has a constructor now? |
| 10:03 | <zcorpan_> | not any more |
| 10:04 | <annevk> | I guess MediaList is conceptually a Set, but probably an ordered Set in practice... |
| 10:04 | <annevk> | Because of serialization. It would've been nice if we had invented all those primitives before all these adhoc APIs. |
| 10:05 | <zcorpan_> | would've been nice if document.write wasn't invented :-P |
| 10:05 | <annevk> | Hey, shut up and give me a pony |
| 10:05 | <zcorpan_> | on it |
| 10:06 | <zcorpan_> | hey look, CSSImportRule already has [PutForwards=mediaText] |
| 10:09 | <zcorpan_> | i wonder what elementFromPoint should do if the root element has pointer-events:none |
| 10:17 | <zcorpan_> | i also wonder what elementsFromPoint should do in a case like this http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2365 |
| 10:23 | <annevk> | Hint: define hit testing |
| 10:43 | <annevk> | Hmm... So Fetch not being able to just deal with a Document object is somewhat annoying... |
| 10:43 | <annevk> | (It cannot have a document object association if we assume the eventual architecture is that Fetch is a distinct thread.) |
| 10:45 | <annevk> | But e.g. for CSP having a load group would make a lot of sense. The load group holds the policy and enforces it for each fetch that gets queued in it. |
| 11:23 | <annevk> | zcorpan_: could you maybe update my email address at the top of the CSSOM spec? |
| 11:23 | <annevk> | zcorpan_: people still try to contact me through my former @opera.com address so the less it's out there the better |
| 11:23 | <zcorpan_> | annevk: sure |
| 11:24 | <zcorpan_> | annevk: should i change the opera affiliation? |
| 12:24 | <annevk> | zcorpan_: I guess |
| 12:25 | <zcorpan_> | annevk: i left it saying opera since you worked for opera when you stopped editing |
| 12:25 | <annevk> | zcorpan_: fair enough |
| 12:40 | <zcorpan_> | Ms2ger: can you add me to the anolis project so i can close bugs? |
| 12:41 | zcorpan_ | looks at https://bitbucket.org/site/master/issue/4084/close-resolve-issues-using-comment-of-a |
| 12:56 | <Ms2ger> | zcorpan_, I will as soon as I can log in :) |
| 13:00 | <zcorpan_> | TabAtkins: what's the status on http://lists.w3.org/Archives/Public/www-style/2013Jun/0038.html ? is there a bug or something i can follow? |
| 13:17 | <manu-db> | MikeSmith: are you referring to the 'prefix' thing? Yeah, I noticed that when I went looking for the whitespace allowance for the contents of prefix. It's unfortunate that the discussion didn't happen two weeks ago. We could've done something to fix it in the PER for RDFa Core 1.1 (which goes out today) |
| 13:17 | <manu-db> | MikeSmith: We can put it in the errata so that the next rev will pick it up. |
| 13:22 | <annevk> | Anolis should move to GH... |
| 13:23 | <Ms2ger> | No thanks |
| 13:46 | <MikeSmith> | manu-db: ok, thanks -- yeah, I'll try to write up some proposed text |
| 13:48 | <manu-db> | MikeSmith: ok, thx, much appreciated - gotta prep for a call in 12 minutes, let me know if you have something you want me to look at and I can check it out after the call. |
| 13:49 | <MikeSmith> | ok |
| 13:54 | <annevk> | Hmm, did http://labs.ft.com/2013/01/seamless-iframes-not-quite-seamless/ ever come up on a mailing list? |
| 13:59 | <MikeSmith> | "Netscape Navigator 4 supported a src attribute on DIV tags which pretty much solved all of these problems..." |
| 14:00 | <Ms2ger> | If only we'd all implemented <layer>... |
| 14:11 | <annevk> | <ilayer> is where it's at I hear |
| 14:12 | <annevk> | I need to get out of this hole of writing specs that are important but nobody really cares about |
| 14:15 | <Ms2ger> | We care |
| 14:15 | <Ms2ger> | Abstractly |
| 14:18 | <jgraham> | I think what Ms2ger means is "we care about the abstracts" |
| 14:18 | <jgraham> | Because who has time to actually read whole specs these days? |
| 14:19 | <nessy1> | annevk: look at it as a niche rather than a hole ;-) |
| 14:20 | <annevk> | jgraham: heh |
| 14:21 | <annevk> | nessy1: yeah, that prolly came of worse than I meant it, but it would be nice to work on stuff that has more collaboration without having to ask people to partake |
| 14:22 | <Ms2ger> | annevk, you could go and work on webrtc ;) |
| 14:23 | <annevk> | I'm getting the impression it's IETF-zoned. |
| 14:23 | <jgraham> | It is at least true that people get very excited about it |
| 14:24 | <SimonSapin> | annevk: AFAIU the network/protocols part is in IETF, the browser/APIs part in W3C |
| 14:25 | <annevk> | SimonSapin: did you check who's involved W3C-side? |
| 14:26 | <SimonSapin> | annevk: no, just heard Adam Roach talk about it in Taipei |
| 14:26 | <SimonSapin> | https://intranet.mozilla.org/images/7/7d/Intro-to-IETF.pdf |
| 14:27 | <Ms2ger> | Boo, intranet |
| 14:30 | <SimonSapin> | sorry :/ |
| 14:30 | <Ms2ger> | Want to poke whoever put it there? :) |
| 14:30 | <Ms2ger> | Or tell me who it was, so I can shout |
| 14:31 | <SimonSapin> | Ms2ger: Adam Roach, abr on IRC |
| 14:31 | <SimonSapin> | "Standardization and Mozilla: IETF" |
| 14:36 | <SimonSapin> | pinged about making our work week slides public |
| 14:37 | <Ms2ger> | Ta |
| 14:41 | <MikeSmith> | https://github.com/philipwalton/html-inspector is nice |
| 15:17 | <Ms2ger> | https://dl.dropboxusercontent.com/u/53717247/Intro-to-IETF.pdf in case people are interested |
| 15:30 | <zewt> | "Your search - python backtrace - did not match any documents." go home google you are drunk |
| 15:45 | <dglazkov> | good morning, Whatwg! |
| 15:45 | <MikeSmith> | Ms2ger: thanks |
| 15:46 | <Ms2ger> | Np |
| 15:58 | zcorpan | sent an email about lazyload="" |
| 17:08 | <annevk> | Ms2ger++ |
| 17:08 | annevk | encourages SimonSapin to share more links that ought to be public |
| 17:09 | <Ms2ger> | https://lists.w3.org/Archives/Member/w3c-css-wg/? |
| 17:09 | <SimonSapin> | annevk: I talked to Jet, he agrees that work week talks should be public |
| 17:10 | <SimonSapin> | Ms2ger: we don’t have much there, but yeah |
| 17:11 | <Ms2ger> | I'm afraid dbaron wouldn't approve if I made that public :) |
| 17:41 | <rillian> | annevk: your webvtt validator could give a better error message for '00:01.500 -> 00:02.300' |
| 17:41 | <annevk> | Is this where I say, "patches welcome"? |
| 17:42 | <rillian> | I'm sure that's one of the dialog choices in the menu |
| 17:42 | <annevk> | "Line 4, column 1: Timestamp must start with a character in the range 0-9." is kinda poor indeed |
| 17:52 | <rillian> | annevk: quite |
| 18:17 | <annevk> | rillian: so it seems like you found an actual bug somewhere |
| 18:17 | <annevk> | rillian: code suggests it should alert "No valid timestamp separator found." so something is amiss :/ |
| 18:22 | <rillian> | bug! |
| 18:23 | <annevk> | rillian: ooh, so what happens is that because the line does not contain "-->" it becomes an ID |
| 18:24 | <annevk> | rillian: because that's how WebVTT handles IDs... |
| 18:24 | <annevk> | rillian: so I'm not sure there's anything I can do here really |
| 18:24 | <annevk> | rillian: you'll get a much more sensible message for "ID\n00:11.000 -> 00:13.000" |
| 18:30 | <rillian> | annevk: maybe change the error to 'couldn't find valid timestamps'? |
| 18:30 | rillian | is out for a bit |
| 18:39 | <annevk> | might give it another look tomorrow |
| 18:41 | <jgraham> | SimonSapin: You are supposed to thinkn in terms of "does this need to be private", not "does this need to be public" :p |
| 20:53 | <Hixie_> | i'm actually doing deep enough work on the html parser that i'm swapping in my parser knowledge again |
| 20:53 | <Hixie_> | yikes |
| 20:54 | <Ms2ger> | Yikes indeed |
| 20:55 | <Hixie_> | http://html5.org/tools/web-apps-tracker?from=7997&to=7999 |
| 21:22 | <Ms2ger> | I have to say I'm quite fascinated that TC39 apparently decided to add Number.parseInt, which does the same thing as parseInt |
| 21:46 | <Hixie_> | rafaelw: yt? |
| 21:46 | <rafaelw> | hixie: here |
| 21:49 | <Hixie_> | rafaelw: can you walk me through the foster parenting case for template? |
| 21:49 | <rafaelw> | sure. |
| 21:49 | <Hixie_> | rafaelw: what would happen that you don't want to have happen if that line wasn't there? |
| 21:50 | <rafaelw> | you can't have any content lifted out of the template. |
| 21:50 | <rafaelw> | that's the main thing. |
| 21:50 | <Hixie_> | what's an example of input that would trigger that? |
| 21:51 | <rafaelw> | Trying swap of all this back in. |
| 21:51 | <rafaelw> | I think, for example, <template><tr>Foo |
| 21:51 | <rafaelw> | would have attempted to lift the Foo outside the template. |
| 21:53 | <Hixie_> | oh right, i keep forgetting <template> applies in cases like that |
| 21:53 | <Hixie_> | ok, thanks |
| 21:53 | <rafaelw> | ;-) |
| 21:55 | <Hixie_> | rafaelw: in the "or a table element immediately below it" case, isn't that the same as normal foster parenting? |
| 21:55 | <Hixie_> | ( https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#foster-parent-addition ) |
| 21:59 | <rafaelw> | no. i'm trying to remember why. |
| 21:59 | <rafaelw> | i know there's an html5lib case that covers it. |
| 21:59 | <rafaelw> | (brain is slow today) |
| 22:00 | <Hixie_> | i can't figure out a way in which it's different... "The foster parent element is the parent element of the last table element in the stack of open elements, if there is a table element and it has such a parent element" |
| 22:00 | <Hixie_> | if the element before <table> is <template>, that's what it would be, no? |
| 22:01 | <Hixie_> | oh except that it wouldn't be the parent... |
| 22:01 | <Hixie_> | maybe that's it |
| 22:01 | <Hixie_> | it's to handle the case where it would be the parent, except for template's logic |
| 22:03 | <zcorpan> | Hixie_: is this correct? |
| 22:03 | <zcorpan> | Elements in other namespaces whose interface is not defined by |
| 22:03 | <zcorpan> | + that namespace's specification must use the interface <code>Element</code>.</p> |
| 22:04 | <rafaelw> | Yes. That's it. |
| 22:04 | <rafaelw> | I think. |
| 22:04 | <rafaelw> | You can't lift the node and make it a child of the template element. |
| 22:05 | <zcorpan> | Hixie_: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2369 foobar is SVGElement in presto/blink/gecko |
| 22:05 | <Hixie_> | zcorpan: interesting |
| 22:05 | <Hixie_> | zcorpan: can you file a bug? |
| 22:05 | <zcorpan> | sure |
| 22:05 | <Hixie_> | zcorpan: that hasn't changed, fwiw |
| 22:05 | <Hixie_> | but i'm glad the recent changes brought it to light :-) |
| 22:05 | <Hixie_> | thanks |
| 22:06 | <zcorpan> | i wish web-apps-tracker had a bug filer |
| 22:14 | <zcorpan> | <script async> shouldn't block the load event per spec, right? |
| 22:16 | <rafaelw> | hixie: I can't remember exactly. |
| 22:16 | <rafaelw> | If you want I can build with that line removed from blink and see which html5lib test fails. |
| 22:16 | <zcorpan> | hmm... "Fetching an external script must delay the load event of the element's document until the task that is queued by the networking task source once the resource has been fetched (defined above) has been run." |
| 22:17 | <Hixie_> | rafaelw: if it's trivial to do so, sure, more data is always good. but otherwise don't worry, i'm confident that the cases above are sufficient for my understanding of this. |
| 22:24 | <Hixie_> | rafaelw: actually, i take what i said back. i think the spec already handles the case of <template><table>x, since it'd put the x before the <table> in the template contents. |
| 22:25 | <Hixie_> | rafaelw: so yeah, i'd love to see what breaks if you remove the code equivalent of "or a table element immediately below it" |
| 22:26 | <rafaelw> | ok. |
| 22:27 | <Hixie_> | in fact, as written, i think the spec is wrong. it makes <template><table>x actualy put the "x" text node in the template, not the template contents. |
| 22:27 | <Hixie_> | i assume the intent is that the "x" end up _before_ the <table> in the template contents? |
| 22:53 | <gsnedders> | Gah! Moving this into spec means I lose my excuse to not bother implementing it in html5lib! |
| 22:53 | <Hixie_> | looks like it's actually not that hard to implement. i'm doing most of the hard work (other than designing this all in the first place, that is!), which is to work out how it integrates with foster parenting in an explicit fashion. |
| 22:57 | <annevk> | Starship Troopers is basically awesome |
| 22:57 | <rafaelw> | hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21430 |
| 22:59 | <Hixie_> | rafaelw: so i get the second part of that bug, where <template><tr><div> should parse into a DOM with one empty <template>, whose tempalte contents are <><div/><tr/></> (where <>..</> is a doc frag) |
| 22:59 | <Hixie_> | rafaelw: but what's wrong with the first part, where the foster parent element is the document fragment? |
| 23:00 | <Hixie_> | rafaelw: isn't that exactly what we want? |
| 23:01 | <Hixie_> | btw i'm doing what you said in comment 1 (make it into one algorithm) |
| 23:02 | <Hixie_> | oh, i see, the spec says "if it's not an element..." |
| 23:02 | <Hixie_> | well we should just remove that, no? |
| 23:02 | <Hixie_> | i wonder why we refuse to foster parent if it's not an element... |
| 23:04 | <rafaelw> | yeah. |
| 23:05 | <rafaelw> | i think that's what anne was suggesting in the bug. |
| 23:05 | <rafaelw> | i think maybe i got this wrong. |
| 23:05 | <rafaelw> | the test in html5lib that fails is: <template><template><table>Foo |
| 23:05 | <rafaelw> | the failure is that (without the additional rule), the foo comes before the table, rather than after. |
| 23:05 | <Hixie_> | what do you end up doing in the two cases? |
| 23:05 | <Hixie_> | ah |
| 23:06 | <Hixie_> | why is that a failure? |
| 23:06 | <Hixie_> | surely you want it to come before |
| 23:06 | <Hixie_> | (i say "surely" like this makes any sense, hah) |
| 23:06 | <Hixie_> | i mean, for consistency with non-template markup |
| 23:09 | <rafaelw> | I am serious... And stop calling me "Shurly". |
| 23:10 | <Hixie_> | (in other news, modulo this discussion, so far i've integrated 7.1 to 7.5. and my patches so far are hundreds of lines long. :-|) |
| 23:10 | <Hixie_> | (amazing how much you can do with just a few lines of monkeypatching spec prose :-) ) |
| 23:10 | <rafaelw> | http://www.youtube.com/watch?v=0A5t5_O8hdA |
| 23:10 | <Hixie_> | airplane? |
| 23:10 | <rafaelw> | yup. |
| 23:11 | <rafaelw> | classic. |
| 23:11 | <Hixie_> | indeed |
| 23:11 | <rafaelw> | anyhow. |
| 23:11 | <rafaelw> | back to html parsing hurting land. |
| 23:11 | <Hixie_> | btw feel free to tell me darobin already figured this out if i'm asking you stuff he already asked you :-) |
| 23:11 | <rafaelw> | I can't honestly remember why that needed to come after. |
| 23:11 | <rafaelw> | seems wrong now. |
| 23:11 | <rafaelw> | nope. he didn't ask any of this stuff. |
| 23:12 | <Hixie_> | k |
| 23:12 | <Hixie_> | any objection to me making foster parented stuff come out above the <table> in the <template>? |
| 23:13 | <Hixie_> | bummer, next section is 'Additions to "reset the insertion mode appropriately"', that sounds painful |
| 23:14 | <rafaelw> | can we leave it as is for now |
| 23:14 | <rafaelw> | and open a bug. |
| 23:14 | <rafaelw> | i just tested FF nightly, but found another bug in their impl. |
| 23:14 | <rafaelw> | (was curious what they implemented). |
| 23:15 | <rafaelw> | Ok. FF also implemented what we did |
| 23:16 | <rafaelw> | (text node comes after table). |
| 23:16 | <rafaelw> | I think we should open a bug and see what everyone thinks. |
| 23:16 | <rafaelw> | It may be there was a good reason for this and I'm not remembering right now. |
| 23:18 | <rafaelw> | sorry. i think i imagined the bug in FF impl. Looks right. |
| 23:20 | <Hixie_> | sure. can you file the bug? (not sure where it should get filed exactly. if it's a whatwg spec bug, i just fix it!) |
| 23:21 | <Hixie_> | so the case i have to hack in the spec is if you have a table whose parent is the template contents doc frag, it should be appended, not inserted above the table, right? |
| 23:26 | <Hixie_> | in particular, the issue here is that it means <template><table>2<td>1</table></template> and <template><div><table>1<td>2</table></div></template> act differently |
| 23:28 | <gsnedders> | Hixie_: effort("not that hard") > effort("delaying") |
| 23:29 | <Hixie_> | believe me, i understand |
| 23:29 | <Hixie_> | i delayed this as long as i could too :-P |
| 23:29 | <gsnedders> | I don't want to swap the parser back into my head. Thankfully almost everything on the 1.0 to-do list doesn't really involve the parser. :P |
| 23:30 | <Hixie_> | again, i know _exactly_ how you feel :-P |
| 23:30 | <gsnedders> | Really what I don't want to do is fix up the (placeholder) error messages around the AAA. |
| 23:30 | <gsnedders> | Useful parse error messages for the AAA, ergh. |
| 23:31 | <gsnedders> | And I expect you know _exactly_ how AAA hell feels, too. :P |
| 23:34 | <Hixie_> | i just tweaked the AAA yesterday |
| 23:34 | <Hixie_> | i need say no more, i'm sure |
| 23:35 | <gsnedders> | Hixie_: Hate you. Hate you forever. >_> |
| 23:37 | <Hixie_> | :-) |
| 23:37 | <Hixie_> | i actually tweaked it by making it slightly simpler, factoring out the foster parenting logic |
| 23:38 | <Hixie_> | (should be an editorial change) |
| 23:38 | <gsnedders> | Oh, provided it's editorial it's fine. I can ignore it. :P |
| 23:38 | <gsnedders> | (even if it means impl strategy diverges) |
| 23:38 | <gsnedders> | Will resync when a normative change happens. |
| 23:39 | <Hixie_> | rafaelw: (see comments above the discussion between gsnedders and i) |
| 23:39 | <gsnedders> | (Please don't make one, so I never have to.) |
| 23:39 | <Hixie_> | gsnedders: very next commit will be a huge normative change to the parser. |
| 23:40 | <gsnedders> | Hixie_: The template one? |
| 23:40 | <Hixie_> | yeah |
| 23:40 | <gsnedders> | Thus my complaint about "not that hard" being more than "delaying" :P |
| 23:40 | <Hixie_> | man, <template> really supports templates in <colgroup> amd <frameset>? |
| 23:40 | <Hixie_> | ok... |
| 23:41 | <gsnedders> | Ewwwwwwwwwwwwwwwwwwwwwwwwwwwwwww |
| 23:41 | <gsnedders> | (Maybe a few more "w"s were needed?) |
| 23:42 | <rafaelw> | Hixie: what I'm asking is if we can file a bug to *ask* if the template spec behavior *is* bug. |
| 23:42 | <rafaelw> | I think it may be, but I'd like to not assume right now that it is. |
| 23:42 | <Hixie_> | rafaelw: right |
| 23:43 | <Hixie_> | rafaelw: that's what i said :-) |
| 23:43 | <Hixie_> | no? |
| 23:43 | <rafaelw> | ok. so file a whatwg bug and cc the moz folks? |
| 23:44 | <Hixie_> | if you file a whatwg bug, then the person you're asking is me, and i know what i'd say, hence my question of how we file a bug :-) |
| 23:44 | <rafaelw> | how about if you *not* just resolve it in the case because we actually want other opinions? |
| 23:45 | <rafaelw> | alternatively, if you prefer me to file a w3c bug, i'm happy to do that. |
| 23:45 | Hixie_ | follows the "spec editors make decisions" philosophy, not the "consensus" philosophy |
| 23:45 | <Hixie_> | and in this case, you're the editor :-) |
| 23:45 | <rafaelw> | They why did you ask me? |
| 23:45 | <Hixie_> | you and tony, anyway |
| 23:46 | <rafaelw> | s/They/then |
| 23:46 | <Hixie_> | cos you're the editor :-) |
| 23:46 | <gsnedders> | rafaelw: So he could ignore you knowing your opinion. |
| 23:46 | <rafaelw> | ah. |
| 23:46 | <gsnedders> | Sorry, I'll go away again. |
| 23:46 | <Hixie_> | anyway i'm happy to spec whichever; right now i've specced what the template spec said and left a marker in the spec |
| 23:46 | <rafaelw> | ok. |
| 23:46 | <Hixie_> | saying that this is likely a bug |
| 23:47 | <rafaelw> | ok. filing a w3c bug. |
| 23:47 | <Hixie_> | cool |
| 23:47 | <Hixie_> | thanks |
| 23:50 | <Hixie_> | rafaelw: where should <body><template><body></body><!----> put the comment? |
| 23:50 | <gsnedders> | So running `git blame` on the spec may have been a bad idea… :) |
| 23:51 | <gsnedders> | Oh, actually, while you're around Hixie_: should there be trees that can *only* be created with parse errors (or through scripting, obv.)? |
| 23:52 | <Hixie_> | gsnedders: if you need blames for the html spec, see http://www.whatwg.org/specs/web-apps/current-work/blames-list.cgi |
| 23:52 | <Hixie_> | gsnedders: how do you mean? |
| 23:53 | <Hixie_> | rafaelw: similar question with <button><template><button>; should the template have a button in it? |
| 23:53 | <rafaelw> | Hold on. |
| 23:53 | <rafaelw> | I got it wrong. |
| 23:54 | <rafaelw> | That extra language is *so that* the text node comes before the table. |
| 23:54 | <gsnedders> | Hixie_: I can't recall the exact example, but I came across some tree that could only be produced by the parser with inputs that caused a parse error. |
| 23:54 | <rafaelw> | https://code.google.com/p/html5lib/source/browse/testdata/tree-construction/template.dat#1140 |
| 23:54 | <rafaelw> | hixie: sorry. i slept poorly last night and i'm juggling to many things at once. |
| 23:55 | <Hixie_> | rafaelw: ah ok, cool, thanks makes more sense. so it's basically just working around the thing in the old spec that said to act weird if the parent was non-null but not an element (i.e., a doc or doc fragment) |
| 23:55 | <rafaelw> | yes |
| 23:55 | <Hixie_> | ok. |
| 23:55 | <gsnedders> | Hixie_: If that makes any more sense? |
| 23:55 | <Hixie_> | rafaelw: i'm gonna stop working on this now and resume tomorrow. hopefully we'll both be better rested :-) |
| 23:55 | <rafaelw> | Yeah. I was gonna sk. |
| 23:55 | <rafaelw> | ask |
| 23:55 | <rafaelw> | THanks =-0 |
| 23:55 | <rafaelw> | ;-) |
| 23:56 | <rafaelw> | I think I'll be more help with a good nights sleep. |
| 23:56 | <Hixie_> | i'm clearly a masochist because this merge is starting to actually be fun |
| 23:56 | <Hixie_> | i haven't done work on the parser this deep since before the foreign content stuff |
| 23:57 | <Hixie_> | and the foreign content stuff suffered from my not being deep enough in it, i think |