| 05:35 | <hsivonen> | Tabatkins: your hypothetical <sandbox> would get similar objections from me as <template> |
| 06:31 | <Hixie> | hsivonen: how do you feel about the hypothetical <template srcdoc="">? |
| 06:38 | <hsivonen> | Hixie: I think it would be mostly inconvenient compared to letting the nodes be in the tree but it wouldn't have the DOM Consistency problems if it parsed consistently regardless of the XMLness of the host doc |
| 06:39 | <hsivonen> | Hixie: I'm not actually advocating it as a solution, because it would be syntactically inconvenient to author |
| 06:39 | <Hixie> | do you really think it's plausible to put the dom nodes in the dom inline and then change the zillions of things that need to be neutered? it seems really intractable to me |
| 06:39 | <Hixie> | (i'm not a big fan of the attribute solution either) |
| 06:39 | <Hixie> | (but i don't understand your objection to the inline thing) |
| 06:41 | <hsivonen> | Hixie: one possibility is that <template> is the wrong thing to want in the first place and we should instead focus on making it easy to write document fragments inline inside .js files |
| 06:42 | <Hixie> | those seem like orthogonal concerns |
| 06:42 | <hsivonen> | Hixie: I do think it's tractable to make inline nodes as static as nodes in an XSLT program |
| 06:42 | <Hixie> | but i'm definitely 100% behind solving the latter problem |
| 06:42 | <Hixie> | i have no idea if nodes in an XSLT program are static |
| 06:43 | <Hixie> | i wish we could just drop XSLT |
| 06:43 | <hsivonen> | Hixie: they aren't quite orthogonal to the extent <template> doesn't do anything in declaratively on its own |
| 06:43 | <Hixie> | it's so ill-defined |
| 06:43 | <Hixie> | (and used almost but not quite rarely enough to be dropped, grr) |
| 06:43 | <hsivonen> | Hixie: if <template> exists only to provide scripts a fragment to clone, the fragment might as well be put in the script |
| 06:43 | <Hixie> | my understanding is that <template>'s main purpose is for web components, is that wrong? |
| 06:44 | <hsivonen> | Hixie: if that's the main purpose, I've missed some big-picture memo |
| 06:44 | <Hixie> | i wasn't aware scripts would do much with them, i kinda assumed it would be mostly declarative like the repetition model |
| 06:44 | <Hixie> | anyway i agree that html-in-script is something more interesting to solve |
| 06:45 | <Hixie> | can you get anyone at mozilla to implement http://hixie.ch/specs/e4h/strawman ? :-) |
| 06:45 | <hsivonen> | Hixie: unlikely |
| 06:45 | <Hixie> | :-( |
| 06:45 | <hsivonen> | Hixie: Conway's Law: it would belong to a different team |
| 06:47 | <hsivonen> | Hixie: anyway, my DOM Consistency concern would be less defensible if the proponents of <template>-as-a-wormhole-to-another-world were ready to introduce the same model to XML parsing and face the wrath of XML people |
| 06:48 | <hsivonen> | Hixie: if there are reasons not to do that with XML parsing, consider those same reasons raised as reasons not to do it in HTML parsing |
| 06:48 | <hsivonen> | (I'm behind in my W3C mailing list reading, so I'm not sure if the position on XML parsing has been reversed by now) |
| 06:49 | <hsivonen> | Hixie: that said, I'm uneasy about the wormhole model even if it applied to both XML and HTML |
| 06:50 | <Hixie> | the reason not to do it with xml parsing is "the xml spec doesn't say to do it" |
| 06:50 | <Hixie> | and... conway's law, we don't control the xml spec :-) |
| 06:50 | <Hixie> | (i don't think they really care about xml) |
| 06:51 | <Hixie> | (can't say i blame them) |
| 06:51 | <hsivonen> | well, XML is in the same department as XSLT: not a priority but can't be dropped |
| 06:51 | <Hixie> | yeah |
| 06:51 | <Hixie> | but doesn't have to be supported well either |
| 06:51 | <hsivonen> | rewriting Gecko's XML loading code paths is on my list of things to do |
| 06:52 | <hsivonen> | so XML is still planned to get engineering time |
| 06:52 | <hsivonen> | I even feel surprisingly motivated to do it |
| 06:52 | <Hixie> | mozilla uses xml more than other browsers |
| 06:53 | <hsivonen> | Hixie: oh the Mozilla-special parts are not planned to get overhauled |
| 06:53 | <Hixie> | loading xml has an impact on firefox load time |
| 06:53 | <Hixie> | it doesn't have an impact on other browsers |
| 06:54 | <hsivonen> | it would be so much nicer not to have to worry about RDF and XUL |
| 06:54 | <hsivonen> | or XSLT |
| 06:54 | <hsivonen> | those are the 3 special cases |
| 06:54 | <hsivonen> | within the XML universe that is |
| 07:04 | <abarth> | hsivonen: i'm not sure why XML should be allowed to constrain the development of HTML |
| 07:05 | <annevk> | hsivonen: sounds more like the Gecko XML universe :) |
| 07:05 | <abarth> | if you want to use feature A that isn't supported in XML, then don't use XML. |
| 07:07 | <hsivonen> | abarth: well, at some point someone will use <template> in XML and then we'll be in a place where everyone loses if one browser vendor tries to be nice and support that case |
| 07:08 | <annevk> | wouldn't that be prevented by a test case? |
| 07:08 | <annevk> | and the note in the spec "Does not work in XML" |
| 07:08 | <hsivonen> | we have been in a situation where we had DOM inconsistency |
| 07:08 | <hsivonen> | the situation was bad |
| 07:08 | <hsivonen> | and we worked hard to get DOM Consistency |
| 07:09 | <annevk> | I always thought of that whole concept more as sharing the same DOM model |
| 07:09 | <annevk> | not as the same mapping-to-the-DOM model |
| 07:09 | <hsivonen> | annevk: well, they aren't going to share the same DOM model if one supports wormholes and one doesn't. |
| 07:10 | <annevk> | like using the same namespace, having the DOM behave the same in both environments (more or less) |
| 07:10 | <abarth> | hsivonen: one supports entity references and the other doesn't :) |
| 07:11 | <hsivonen> | abarth: different level of abstraction |
| 07:11 | <annevk> | hsivonen: I don't really see DOM consistency as a requirement that the effects the markup one of them can create in the DOM, the other has to too |
| 07:11 | <abarth> | anyway, there's no reason a DOM generated from XML can't support wormholes |
| 07:11 | <annevk> | hsivonen: e.g. XML can create namespaced nodes |
| 07:11 | <abarth> | isn't that just a property on the HTMLTempalteElement? |
| 07:11 | <annevk> | hsivonen: and now HTML would be able to create template trees |
| 07:11 | <annevk> | hsivonen: doesn't seem like a huge deal to me |
| 07:12 | <annevk> | abarth: no it's also how the contents are parsed and put on the fragment that attribute returns |
| 07:12 | <annevk> | put in* |
| 07:12 | <hsivonen> | annevk: I think making the DOM not be a syntax tree and turning it into an application-specific tree is a huge deal |
| 07:13 | abarth | is confused |
| 07:13 | <abarth> | doesn't shadow DOM do that? |
| 07:13 | <abarth> | I'm clearly missing something here |
| 07:13 | <annevk> | abarth: the idea is that <template>something</template> turns into <template/> in the DOM with an associated fragment that contains something |
| 07:14 | <hsivonen> | abarth: does the shadow DOM have a serialization? |
| 07:14 | <abarth> | I feel like you're conflating two things |
| 07:14 | <abarth> | 1) there's a DOM, independent of serialization |
| 07:14 | <abarth> | that's shared between HTML and XML |
| 07:15 | <abarth> | 2) there are HTML and XML serializations |
| 07:15 | <abarth> | <template> is not supported in the XML serilaization |
| 07:15 | <abarth> | that's it |
| 07:15 | <hsivonen> | abarth: but the DOM isn't just any tree. It's a tree designed to represent the syntax of tags-and-text markup |
| 07:15 | <abarth> | none of that has changed |
| 07:15 | <annevk> | well it kind of has |
| 07:16 | <annevk> | because the contents of <template> are elsewhere |
| 07:16 | <abarth> | not any more that <style><div>hi</div></style> changed it |
| 07:16 | <hsivonen> | abarth: so saying that the correspondence between tags-and-text and the DOM nodes is now different is a huge departure from what the DOM was designed to be |
| 07:16 | <abarth> | s/that/than/ |
| 07:16 | <abarth> | so? |
| 07:16 | <annevk> | abarth: I think it's more; that's still in the DOM |
| 07:16 | <abarth> | having script in web page was a huge departure too |
| 07:16 | <abarth> | and it has turned out to be a good thing |
| 07:17 | <abarth> | well, don't put it in the DOM |
| 07:17 | <abarth> | put it in an HTMLTemplateElement propertly |
| 07:17 | <abarth> | like a shadow DOM |
| 07:18 | <abarth> | your argument has now shifted to not make reference to XML |
| 07:18 | <abarth> | which, IMHO, is a more interested conversation |
| 07:18 | <abarth> | s/interested/interesting/ |
| 07:18 | abarth | can't type |
| 07:19 | <hsivonen> | abarth: no, XML is a useful aid for making my argument, because the correspondence between tags-and-text and DOM nodes is even more straight-forward in XML |
| 07:19 | <abarth> | the XML issue is off-point |
| 07:19 | <abarth> | it's more interesting to discuss whether this is a good or bad thing for HTML |
| 07:19 | <abarth> | irrespective of the existence of XML |
| 07:20 | <abarth> | for most intents and purposes, XML doesn't exist |
| 07:20 | <annevk> | it sounds like hsivonen's point is that you can serialize the DOM without element-specific knowledge, but that is already not true for HTML |
| 07:21 | <Hixie> | hober: yt? |
| 07:22 | <hsivonen> | at the most basic, my argument is that 1) DOM isn't an app-specific API first; it's a direct representation of tags-and-text syntax. 2) That essential nature of the DOM shouldn't be changed lightly, because changing fundamentals has unforeseen consequences. 3) Stuff that has unforeseen consequences shouldn't be done in gung-ho "let's just implement this feature [in Chrome]" manner |
| 07:22 | <Hixie> | 1) is clearly false IMHO, since all the HTML elements have dedicated interfaces into the DOM |
| 07:22 | <abarth> | (3) seems prematurely argumentative |
| 07:23 | <abarth> | I'm not aware of that happening with <template> |
| 07:23 | <Hixie> | in fact, it was first an application-specific API (new Image(), new Option(), etc) onto which a generic model was then layered |
| 07:23 | <Hixie> | retroactively |
| 07:23 | <hsivonen> | so I'm not trying to argue what specific bad effects this might have, because my fear is that changing fundamentals will have consequences I don't see now |
| 07:23 | <annevk> | but you also don't see the potential good effects |
| 07:23 | <Hixie> | and clearly nobody is doing 3) since if this was gung-ho, it'd be in the spec already instead of people trying to convince you :-) |
| 07:24 | <hsivonen> | annevk: true |
| 07:25 | <hsivonen> | Hixie: well, just brushing off XML to the side instead of having a design that integrates will all existing parts of the platform seems gung-ho to me |
| 07:26 | <hsivonen> | (it's so weird to be the person who seems to care the most about XML) |
| 07:26 | <annevk> | might be worth studying http://msdn.microsoft.com/en-us/library/windows/desktop/ms766512(v=vs.85).aspx |
| 07:26 | <Hixie> | (on an unrelated note: i think i'm going to put little "fingerprint" icons in the spec in the places that leak fingerprintable data. If anyone has an icon to contribute, or a list of places that should get the icon, please let me know, e.g. by filing a bug or sending me an e-mail.) |
| 07:26 | <annevk> | but I cannot find much information about success/failure |
| 07:27 | <Hixie> | hsivonen: i'm all for solutions that work in XML too. I just haven't seen one. I don't think we should sacrifice the web's progress on the altar of XML -- if we can't find a solution, we have to move on, imho. |
| 07:27 | <hsivonen> | annevk: yeah, data islands are precedent. and failed precedent |
| 07:29 | <hsivonen> | Hixie: about #1, even though elements have convenience properties and methods, the tree structure corresponds to tags-and-text rather than application-specific considerations |
| 07:29 | <abarth> | it doesn't though |
| 07:30 | <annevk> | hsivonen: failed because unappealing or because lack of adoption by other vendors? |
| 07:30 | <abarth> | or rather it only does if you know some special rules for some of the tags |
| 07:30 | <annevk> | hsivonen: successful enough for https://developer.mozilla.org/en/Using_XML_Data_Islands_in_Mozilla it seems |
| 07:30 | <hsivonen> | annevk: unappealing to other vendors ;-) |
| 07:30 | <Hixie> | hsivonen: the tree structure was not first |
| 07:31 | <hsivonen> | Hixie: the current crop of implementations is no longer based on the model that existed before the tree structure |
| 07:31 | <Hixie> | hsivonen: the tree structure was layered on top of the app-specific API years later. |
| 07:31 | <Hixie> | hsivonen: that doesn't seem relevant to the question of what it is |
| 07:31 | <hsivonen> | Hixie: rather, it was layered under |
| 07:32 | <Hixie> | i'm not arguing that the tree structure isn't important, just that it's not some core concept that should be considered holy |
| 07:33 | <Hixie> | the dom _is_ an application specific api, was from the start, and we haven't made it any less so (q.v. srcdoc="") |
| 07:33 | <abarth> | hsivonen: how would you feel if we allowed XL in <script> ? |
| 07:34 | <hsivonen> | XL? |
| 07:34 | <abarth> | it just so happens that the syntax of JavaScript doesn't look like tags-and-text |
| 07:34 | <abarth> | http://en.wikipedia.org/wiki/XL_(XML_programming_language) |
| 07:34 | <abarth> | but there isn't any reason why we shouldn't be able to use a scripting language |
| 07:34 | <abarth> | whose syntax is tags-and-text |
| 07:34 | <abarth> | then the <script> tag would do the same thing that's bothering you about the <template> tag |
| 07:34 | <annevk> | the HTML spec already caters to that possibility |
| 07:34 | <Hixie> | abarth: xforms actions is the language i usually reference in this context |
| 07:35 | <abarth> | ok, there are lots of them |
| 07:35 | <abarth> | XL was the first one I found :) |
| 07:35 | <Hixie> | :-) |
| 07:35 | <Hixie> | CSS even _has_ a tree structure _in the DOM_ |
| 07:36 | <hsivonen> | abarth: I think supporting that sort of language in <script> would be a can of worms |
| 07:36 | <hsivonen> | abarth: I'm aware that WHATWG HTML allowes (allowed?) it, but fortunately, no one really supports a languages like like |
| 07:36 | <abarth> | what if we replaced the < brackets with { |
| 07:36 | <hsivonen> | abarth: it would make it less of a can of worms from the DOM perspective |
| 07:37 | <abarth> | it's unclear to me why < has a special status in the syntax of scripting languages |
| 07:37 | <hsivonen> | abarth: because < is special in the wrapper |
| 07:37 | <abarth> | i mean, JavaScript uses < |
| 07:37 | <hsivonen> | abarth: but this is theoretical. I disapprove of non-JS <script> language in general, including Dart and VBScript |
| 07:37 | <abarth> | it just doesn't look like tags |
| 07:38 | <abarth> | IMHO, that's short sighted |
| 07:38 | <hsivonen> | abarth: < in inline JS is a Polyglotness problem |
| 07:38 | <Hixie> | abarth: i think for this line of argumentation CSS is the better path, because it is already parsed into an exposed OM |
| 07:38 | <abarth> | yes, hence not supporting <template> in XML |
| 07:38 | <abarth> | so, not allowed in polyglot |
| 07:38 | <abarth> | ok, consider CSS |
| 07:38 | <abarth> | but using < rather than { |
| 07:39 | <hsivonen> | abarth: you are basically trying to argue that since we already have cans of worms, it's OK to open some more |
| 07:39 | <abarth> | my argument is that your argument from purity ignores that we're already impure |
| 07:39 | <Hixie> | we don't just have a can of worms, dude. We're swimming in a swamp of worms. |
| 07:40 | <hsivonen> | Hixie: I had them in plural already :-) |
| 07:40 | <abarth> | the correspondence between DOM and tags-and-text isn't as tight as you make it sound |
| 07:40 | <hsivonen> | abarth: from impl point of view, <script> is the most special of elements |
| 07:40 | <hsivonen> | abarth: I accept it as legacy, but I don't view it as a role model for introducing anything else |
| 07:40 | <Hixie> | i dunno about _that_ |
| 07:40 | <Hixie> | <script> is bad, granted. |
| 07:40 | <abarth> | DOCTYPE has got to be more special |
| 07:40 | <abarth> | :) |
| 07:40 | <Hixie> | but <table> parsing is crazy |
| 07:41 | <Hixie> | <iframe> is buts |
| 07:41 | <Hixie> | nuts even |
| 07:41 | <Hixie> | <object> is a land of its own |
| 07:41 | <Hixie> | <frameset>... |
| 07:41 | <Hixie> | not to mention the magic that is nested <a> parsing! |
| 07:41 | <Hixie> | ok i'll stop now |
| 07:42 | <hsivonen> | Hixie: none of those can do the kind of things to the parser state as <script> |
| 07:42 | <Hixie> | <script> is only crazy because of document.write() |
| 07:42 | <Hixie> | which by the way is why i neutered that for svg, which you keep arguing we should bring back! :-P |
| 07:43 | <hsivonen> | Hixie: on the XML side, it can suspend the parser as a nod to document.write even though document.write doesn't work |
| 07:43 | abarth | needs to go to sleep soon |
| 07:43 | <Hixie> | i don't recall what we did in xml mode |
| 07:43 | <Hixie> | i don't really care about xml |
| 07:51 | <Hixie> | hsivonen: i don't see anything in the spec that does the document.write() thing in xml, am i missing something? |
| 07:54 | <hsivonen> | non-async/defer script block the xml parser to show a predictable DOM state to scripts |
| 07:54 | <hsivonen> | maybe it's not specced anywhere |
| 07:54 | <Hixie> | <Script src=""> blocks the parser's modifications of the DOM, sure |
| 07:54 | <Hixie> | that's got nothing to do with document.write() |
| 07:55 | <hsivonen> | nothing? |
| 07:55 | <Hixie> | that's just the scripts being synchronously loaded |
| 07:55 | <Hixie> | the same would occur if document.write() didn't exist at all |
| 07:55 | <hsivonen> | I don't believe it would |
| 07:56 | <Hixie> | ok |
| 07:56 | <Hixie> | either way |
| 07:56 | <Hixie> | i did not have document.write() in mind when speccing that |
| 07:56 | <Hixie> | and it has nothing to do with document.write() in the spec |
| 07:56 | <Hixie> | it's just sync external script loading |
| 07:56 | <Hixie> | and it's hardly "crazy" |
| 07:56 | <Hixie> | compared to things like <object>'s processing model |
| 07:57 | <hsivonen> | object is very light in craziness from the parser impl POV |
| 07:58 | <Hixie> | oh for parsing, sure |
| 07:58 | <Hixie> | parsing in general is very light in craziness from the big picture point of view :-) |
| 07:58 | <Hixie> | XML parsing |
| 07:58 | <hsivonen> | script has the worst parsing complications |
| 07:59 | <Hixie> | in XML parsing, it has the only complications |
| 07:59 | <Hixie> | well, i guess </video> and </object> technically have some minor complications |
| 07:59 | <Hixie> | but that's about it, in xml |
| 08:00 | <hsivonen> | and <svg> |
| 08:00 | <Hixie> | oh because of their event nonsense? |
| 08:00 | <hsivonen> | right |
| 08:00 | <Hixie> | yeah i haven't been affected by that so it doesn't come to mind :-) |
| 08:02 | <Hixie> | anyway. i think the original point stands: if there's a solution that works for XML, I'm sure people would be happy to hear about it, but so far none have been put forward, and it doesn't seem sensible to block progress on that. And when you forget about XML, it really doesn't seem like the proposal is unreasonable; it reuses existing logic. |
| 08:06 | <Hixie> | ok, HD canvas is done, modulo all the bugs i just introduced that hober and zcorpan will point out |
| 08:06 | <Hixie> | next up is removeHitRegion(), i guess |
| 08:06 | <Hixie> | tomorrow |
| 08:13 | <annevk> | how do URLs in <template> descendant elements resolve? |
| 08:13 | <annevk> | I guess base URLs would have to work |
| 08:14 | <annevk> | we could just modify XML really |
| 08:14 | <annevk> | introduce <xml:template> or something odd like that |
| 08:22 | <annevk> | http://what-if.xkcd.com/3/ is awesome |
| 10:32 | <annevk> | Is there any circumstance where you do not have a base URL? |
| 10:33 | <annevk> | (other than the address bar) |
| 10:36 | <hsivonen> | <xml:foo> is never the right solution |
| 10:37 | <hsivonen> | for evidence, see xml:lang, xml:id and <xml:include> |
| 10:38 | <annevk> | hsivonen: yeah after I mentioned that I wondered whether I should correct it to html:template |
| 10:38 | <annevk> | hsivonen: or just let it be warnocked |
| 10:45 | <MikeSmith> | http://www.w3.org/community/xmlhypermedia/ created |
| 10:45 | <MikeSmith> | by the xml:href guy |
| 10:48 | <MikeSmith> | interesting list of technologies on this "Anatomy of a Web Developer" T-shirt http://rlv.zcache.com/anatomy_of_a_web_developer_brain_driven_by_mysql_tshirt-p235273746211126463b7wq7_400.jpg |
| 10:55 | hsivonen | didn't know there was *the* xml:href guy |
| 11:06 | <hsivonen> | so not only have I semi-accidentally come into contact with browsing context code, I have even more accidentally came into contact with B/F cache code :-( :-( |
| 11:07 | <hsivonen> | let's see if Hixie has conceptualized the B/F cache better than the Gecko code that introduced it... |
| 11:11 | <hsivonen> | I wonder if Gecko ever puts non-"complete" docs in the B/F cache in the first place... |
| 11:11 | <hsivonen> | smaug____: do you happen to know? |
| 11:12 | <smaug____> | it shouldn't |
| 11:12 | <hsivonen> | smaug____: ok. thanks |
| 11:21 | <MikeSmith> | hsivonen: btw it would be nice to try to fix the the parser bug that causes double-quoted charset parameter values to be reported as errors in the validator |
| 11:22 | <MikeSmith> | I can't remember where the source of that is but I vaguely recall being in the chardet code maybe |
| 11:23 | <hsivonen> | MikeSmith: does the spec not treat those as errors? |
| 11:23 | <MikeSmith> | no, not as far as I know |
| 11:23 | <hsivonen> | interesting |
| 11:24 | <MikeSmith> | I don't know that the HTML spec says anything about the syntax for the header case |
| 11:24 | <MikeSmith> | anyway, the mime-type RFCs allow it |
| 11:24 | <hsivonen> | oh this is about header parsing rather than processing the value after header parsing? |
| 11:24 | <MikeSmith> | though only for double quotes, not for single once |
| 11:25 | <MikeSmith> | yeah |
| 11:25 | <MikeSmith> | one common place where it gets reported is for the built-in Web server that ships with mercurial |
| 11:25 | <MikeSmith> | hgweb |
| 11:26 | <hsivonen> | ok |
| 11:36 | <MikeSmith> | hsivonen: related mercurial bug I filed: http://bz.selenic.com/show_bug.cgi?id=3531 |
| 13:18 | <odinho> | Ms2ger: Problem is ofc that they're really so damn verbose. Should be a way to say "I want to see the important stuff". So then it's possible to fix that first... |
| 13:18 | <odinho> | Ms2ger: (the idlharness that is) |
| 13:18 | <Ms2ger> | Well, all of idlharness is obscure edge cases, really :) |
| 13:20 | <odinho> | Nope, checking that properties exist, is readonly, returning expected objects back that behave as described. That stuff is useful for doing a quick skeleton of code to further refine and build on. :] |
| 13:20 | <odinho> | Well, depends on obsucrity level ofc, but not that obscure :P |
| 13:23 | <Ms2ger> | Easy; you just import the IDL file and let the bindings code do its wo... Oh |
| 13:24 | <odinho> | ... |
| 13:24 | Ms2ger | curses Gecko's manual bindings |
| 13:26 | <odinho> | Hmm? Thought Gecko had a binding system? |
| 13:26 | <Ms2ger> | About 5 |
| 13:35 | <Ms2ger> | And the hand-written parts don't look nice... |
| 13:52 | <annevk> | why does http://trac.webkit.org/browser/trunk/Source/WebCore/platform/KURL.cpp#L74 not list ports for ws: and wss:? |
| 13:52 | <annevk> | they're the same as for http? |
| 13:57 | <annevk> | indeed they are |
| 15:03 | <MikeSmith> | hsivonen: so I find the cause of the parser not handling double-quotes in the Content-Type header charset parameter is not in chardet but in the validator util code |
| 15:03 | <MikeSmith> | https://bitbucket.org/validator/util/src/de960161c5f1/src/nu/validator/xml/ContentTypeParser.java#cl-37 |
| 15:03 | <MikeSmith> | private static final Pattern CHARSET = Pattern.compile("^\\s*charset\\s*=\\s*(\\S+)\\s*$"); |
| 15:04 | <MikeSmith> | should be: |
| 15:04 | <MikeSmith> | private static final Pattern CHARSET = Pattern.compile("^\\s*charset\\s*=\\s*\"(\\S+)\"\\s*$"); |
| 15:04 | <MikeSmith> | instead I guess |
| 15:04 | <MikeSmith> | hmm are the spaces allowed there? |
| 15:05 | MikeSmith | goes back to read whatever RFC it is |
| 15:05 | <gsnedders> | Yes, they are. |
| 15:05 | <zewt> | heh, nothing is quite as horrid as double-escaped regexes in languages without a regex syntax |
| 15:06 | <Ms2ger> | perl comes close |
| 15:06 | <zewt> | it always does |
| 15:08 | <MikeSmith> | gsnedders: oh yeah? |
| 15:08 | <zewt> | who was it that objected to just "img.src = blob", again? was it just MS? |
| 15:09 | <zewt> | (because they seemed to object to anything that wasn't their own broken oneTimeOnly thing) |
| 15:10 | <Ms2ger> | I think that img.src = non-string is silly |
| 15:11 | <MikeSmith> | from productions in RFC 2616 at least I can't see that the spaces are allowed |
| 15:11 | <MikeSmith> | gsnedders: ↑ |
| 15:11 | <MikeSmith> | I guess I must be missing something |
| 15:14 | <annevk> | zewt: it was sicking |
| 15:14 | <annevk> | zewt: primarily because of the CSS thing, which I don't think people will use |
| 15:14 | <zewt> | i'm personally on the fence (for whatever that's worth, not being a sicking myself) |
| 15:15 | <zewt> | having to add new entry points for every single api seems a lot bigger than changing the existing ones |
| 15:15 | <zewt> | but it is nicer |
| 15:17 | <zewt> | one thing that makes me nervous about it is that it makes it "optional" for APIs |
| 15:17 | <zewt> | some apis will inevitably go "why would you want to do that?" and not add the entry point, instead of it being a universal feature |
| 15:20 | <annevk> | that just requires a bit of hammering |
| 15:21 | <annevk> | but we can go with what we have now |
| 15:21 | <MikeSmith> | hsivonen: and would be better to be using a real parser there instead of regexp :) I'll file a TODO bug for it |
| 15:22 | <zewt> | annevk: well, modulo https://www.w3.org/Bugs/Public/show_bug.cgi?id=16790#c13 |
| 15:26 | <zewt> | calling a black-box script that does a document.write("<script...") and having blob URLs in the caller be revoked would be bad |
| 15:47 | <dglazkov> | good morning, Whatwg! |
| 15:51 | <jwalden> | morning, dglazkov |
| 16:38 | <gsnedders> | MikeSmith: Implicit white space is what you're missing. |
| 16:39 | <gsnedders> | jwalden: So, we now outnumber these accessor property people. Mwhaha! :) |
| 16:39 | <jwalden> | :-) |
| 16:39 | <jwalden> | I landed the __proto__ patch about an hour ago, we'll see how it goes |
| 18:14 | <annevk> | hmm authority is annoying to parse |
| 18:14 | <annevk> | [bits[:bits]@]bits[:bits] is the grammar or some such |
| 18:15 | <annevk> | but then wildly more complicated |
| 18:50 | <Philip`> | Hmm, I got a "DMCA Removal Notice - Link Removal Request" about "an unauthorised link to our clients web site" on http://philip.html5.org/data/doctypes.html |
| 18:51 | <Philip`> | annevk: Since you're hosting it and would presumably have to deal with any problems if they're serious: Should I care? |
| 18:53 | <zewt> | Philip`: it's it a felony to send bogus DMCA requests or something? heh |
| 18:53 | <Philip`> | zewt: I guess that only applies to actual take-down notices, not to emails which happen to mention "DMCA" in their subject line |
| 18:54 | <zewt> | "something something DMCA - do whatever I tell you to" |
| 18:54 | <zewt> | Philip`: DMCA Removal Notice - buy me a pizza |
| 18:54 | <Philip`> | This one says "If the links are not removed as soon as possible then we may have to take further action such as requesting a DMCA take-down notice or reporting the links to Google" |
| 18:55 | <Philip`> | (I'd have thought Google was already aware of all my links, since that's what their business is based on...) |
| 18:55 | <zewt> | "you're going to tell a search engine about my webpage? please do!" |
| 19:01 | <Ms2ger> | Oh, look |
| 19:01 | <Ms2ger> | First action as a CSSOM editor: "Hey, do you *really* want me to *define* things?" |
| 19:20 | <MikeSmith> | gsnedders: I don't think I'm missing implicit white space as far the the RFCs go |
| 19:20 | <MikeSmith> | there's nothing implicit about it in RFC 2616 |
| 19:21 | <MikeSmith> | rather it's just simply not allowed |
| 19:21 | <MikeSmith> | if browser engines allow it, then that should be specified somewhere |
| 19:29 | <annevk> | Ms2ger: oh, something is fixed? |
| 19:30 | <Ms2ger> | Dunno |
| 19:30 | <annevk> | Philip`: sounds like you can just ignore it |
| 19:33 | <karlcow> | Philip`: just ignore. |
| 19:57 | <Hixie> | hober: your quick review of the HD stuff would be nice, to make sure i'm not barking up the wrong tree |
| 19:57 | <Hixie> | MikeSmith: ping |
| 20:02 | <annevk> | am I reading it correctly that IRIs don't allow non-BMP characters? |
| 20:03 | <annevk> | http://tools.ietf.org/html/rfc3987#page-8 |
| 20:03 | <annevk> | oh well, not that it matters what that spec says |
| 20:04 | <zewt> | an established tradition with rfcs |
| 20:15 | <annevk> | for URL parsing it's actually easier if the internal URL object stores path segments and the filename |
| 20:16 | <annevk> | so when you resolve "../" against something else, you just copy the path segments from the base URL (along with everything else, but not the filename and such) and just pop the topmost one |
| 20:16 | <annevk> | (after you tokenize "../" per path tokenization rules of course) |
| 20:17 | <annevk> | (and only if these are hierarchical schemes) |
| 20:18 | <annevk> | and then .pathname is just the concat of path segments with / followed by / followed by filename |
| 20:19 | <Tabatkins> | Philip`: There's no such thing as an unauthorized link. You can ignore that. |
| 20:28 | <karlcow> | annevk: what is the filename? |
| 20:29 | <annevk> | karlcow: remainder except for query/fragment |
| 20:29 | <karlcow> | http://example.org/path/foo/morefoo?blah |
| 20:29 | <annevk> | morefoo |
| 20:30 | <annevk> | path segments would be an array of path and foo |
| 20:30 | <karlcow> | In which context it is a filename? |
| 20:30 | <annevk> | query would be blah |
| 20:30 | <annevk> | it's just a term |
| 20:31 | karlcow | scratches his head |
| 20:32 | <annevk> | yeah, the URL related terms are not too great |
| 20:33 | <annevk> | but we are kind of stuck with them given the API |
| 20:33 | <karlcow> | the path is "/path/foo/morefoo" |
| 20:33 | <annevk> | though I'm somewhat hesitant to call fragment hash instead |
| 20:33 | <annevk> | and query search... |
| 20:36 | <Hixie> | it's often tempting in writing these specs to just call everything "opaque term #391" and so forth |
| 20:36 | <Tabatkins> | But then you need a registry... |
| 20:36 | <Hixie> | just to shortcircuit the confusion and bikeshed bickering that inevitably results |
| 20:37 | <Hixie> | Tabatkins: "html spec opaque term #391" |
| 20:37 | <Tabatkins> | Ah, distributed extensibility. |
| 20:38 | <annevk> | Hixie: shortcircuit the confusion with terms like that? interesting universe |
| 20:39 | <Hixie> | yeah the problem is it introduces a whole different confusion |
| 20:39 | <Hixie> | where everyone has no idea what anything means |
| 20:39 | <Hixie> | but seriously, people sometimes get so hung up on the terms and ignore their definitions, it drives me crazy |
| 20:39 | <annevk> | uhuh |
| 20:39 | <Hixie> | e.g. the "cookie-free document" thing recently, which was very clearly defined as meaning "document that cannot get cookies", not "document that has no cookies" |
| 20:39 | <Hixie> | yet people wrote code assuming it meant the latter! |
| 20:40 | <Hixie> | (i changed that to "cookie-averse documents") |
| 20:40 | <Tabatkins> | omg |
| 20:40 | <Hixie> | and the definition was like two sentences from where the offending requirement was |
| 20:40 | <Tabatkins> | I... want to refuse to believe that people would write code based solely on the name of a feature, rather than reading any of the actual spec. |
| 20:40 | <Hixie> | i wish |
| 20:41 | <Hixie> | anyway, that kind of thing is what makes me want to use really opaque terms so that there's no way to implement it without truly understanding it |
| 20:41 | <Hixie> | obviously a non-starter in practice |
| 20:42 | <Hixie> | ok, i've added removeHitRegion() for microsoft |
| 20:42 | <Hixie> | that's apple and microsoft dealt with |
| 20:43 | <Hixie> | opera wants data: in web works, mozilla wants... what was it, someone had a suggestion earlier |
| 20:43 | <Hixie> | inputmode, i think |
| 20:43 | <Hixie> | that's gonna require research |
| 20:44 | karlcow | now wonders what are the APIs in different std libs for programming languages. |
| 20:48 | <karlcow> | * for URIs |
| 21:54 | <Hixie> | ok... data: workers done |
| 21:55 | <Hixie> | that leaves autocompletetype for chrome and inputmode for mozilla |
| 21:56 | <annevk> | Hixie: how did you handle same-origin that redirects to a data: URL? |
| 21:57 | <smaug____> | really really odd, pages for mobile browsers seem to use event.srcElement reasonable often |
| 21:57 | <smaug____> | I wonder why |
| 21:57 | <smaug____> | srcElement is IEism |
| 21:57 | <smaug____> | not webkitism |
| 21:58 | <Hixie> | annevk: bummer. redirects. |
| 21:58 | Hixie | reopens the editor |
| 21:58 | <annevk> | I thought it was an easy fix for XHR too and then decided to pun on it when I realized redirects |
| 21:59 | <Hixie> | annevk: oh it's already dealt with. As soon as you have a redirect to a different origin, the fetch aborts. |
| 22:00 | <Hixie> | annevk: the way i specced it, it's only data: URLs given in the actual argument that are special-cases |
| 22:00 | <Hixie> | special-cased |
| 22:00 | <annevk> | I guess that's okay |
| 22:00 | <annevk> | the redirect case is kind of weird |
| 22:13 | <hober> | If you're an implementor and object to the changes described in http://www.w3.org/wiki/User:Mtanalin/legend-placement#Details it would be nice if you said so in the wbs poll on the matter before friday: https://www.w3.org/2002/09/wbs/40318/issue-200-objection-poll/ |
| 22:15 | <Tabatkins> | Oh jesus. |
| 22:18 | <hober> | Tabatkins: exactly. |
| 22:32 | <Hixie> | adding some screenshots to http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control |
| 22:32 | <Hixie> | hober: why does it matter? surely if the wg just makes the spec say something dumb, it'll just be ignored |
| 22:35 | <hober> | Hixie: all things being equal, it'd be nice if the wg took its charter requirement to actively pursue convergence. |
| 22:35 | <hober> | s/took/took seriously/ |
| 22:36 | <Hixie> | hober: that's up to the chairs |
| 22:37 | <Hixie> | hober: and the editors |
| 22:37 | <hober> | indeed, and they base their decisions on, among other things, the wbs survey results. having voices of reason in the survey results helps improve the outcome |
| 22:41 | <Hixie> | hober: if they took their charter requirement to actively pursue convergence seriously, they wouldn't base their decisions on surveys |
| 22:43 | tantek | scrolls up |
| 22:43 | <tantek> | nicely written objection TabAtkins |
| 22:44 | <tantek> | I'm not sure I could really add anything substantial to that |
| 22:44 | <tantek> | my big objection is that there is insufficient benefit shown to offset the cost of adding a new <ilegend> element - in fact, quite the opposite, it looks like language pollution. |
| 22:45 | <Tabatkins> | tantek: Simply adding that Mozilla objects for the same reason would be useful. |
| 22:45 | <tantek> | however, that's not really a new objection compared to what you wrote, so I'm not going to bother adding a "me too" answer since the chairs say they don't look at # of votes etc. but rather just the strength of arguments. |
| 22:45 | <Tabatkins> | While votes themselves aren't counted, weight of impl opinion is. |
| 22:45 | <tantek> | it shouldn't be an (un)popularity contest |
| 22:45 | <Tabatkins> | It should absolutely include popularity among implementors. |
| 22:45 | <Tabatkins> | Given that they're the ones implementing the features. ^_^ |
| 22:45 | <Hixie> | it shouldn't be a contest at all |
| 22:45 | <tantek> | I'd rather see the chairs make a good rational decision based on your objection alone. I think that will show that strength of argument matters more than specific parties objecting. |
| 22:46 | <karlcow> | plus I would rather prefer having an element called <iamlegend> or even better <thelastmanonearth> |
| 22:46 | <Hixie> | the objections have long been discussed, if the chairs wanted to make rational decisions they could have done so months ago (when i did) |
| 22:46 | <Tabatkins> | Past experience suggests the chairs don't make good rational decisions on these things. |
| 22:46 | <Hixie> | (not to mention that in this case the problems are self-evident) |
| 22:46 | <tantek> | Tabatkins - my experience has been contrary - e.g. decisions on Issue 183, Issue 184. Have been quite rational. |
| 22:47 | Hixie | gave up hope on the chairs when they decided on a proposal that was literally self-contradictory |
| 22:47 | <Tabatkins> | I'm willing to believe they're not consistently irrational. ^_^ |
| 22:47 | <tantek> | Hixie, baby/bathwater. No one is perfect. |
| 22:48 | <Hixie> | this isn't about lacking perfection |
| 22:48 | <tantek> | Anyway, I think the chairs will also be increasingly biased *against* new elements in an effort to get closure on the HTML5 feature set. |
| 22:48 | <Hixie> | it was clear in their decision that they didn't even know what they were deciding on -- the thing they pointed to had two different proposals, both internally inconsistent, and they hadn't even noticed |
| 22:48 | <Hixie> | and they continued to insist for something like 6 months, even after every single problem was discussed to death, that their decision was right |
| 22:48 | <tantek> | Hixie, not everyone is as good at spotting deep internal inconsistencies as you are :P |
| 22:49 | <Hixie> | this isn't "deep internal inconsistencies" |
| 22:49 | <Hixie> | this proposal wasn't even consistent at a shallow level |
| 22:49 | tantek | isn't even sure which issue/proposal(s) we're talking about, but suspects it has something to do with accessibility. |
| 22:49 | <Hixie> | some canvas thing last year |
| 22:56 | <tantek> | quick question for those of you that went to TPAC2012 and are considering going to TPAC2013: |
| 22:57 | <gavinc> | ... isn't TPAC2012 in October? |
| 22:57 | <Tabatkins> | Very end of Oct/beginning of Nov. |
| 22:57 | <tantek> | make that went to TPAC2011 and are considering going to TPAC2012 :) |
| 22:57 | <Tabatkins> | Oh, got it. |
| 22:57 | Tabatkins | missed the implication of the question. ^_^ |
| 22:57 | <tantek> | Did you get value out of the TPAC2011 pre-scheduled morning sessions (before the BarCamp-style sessions), or not? (e.g. lots, some value, none, negative, walked out) And if you did get value, any suggestions for "global" topics for TPAC2012? |
| 22:58 | <tantek> | (that's the question, before was just setup) |
| 22:58 | <tantek> | (totally unscientific poll) |
| 22:58 | <Tabatkins> | I don't remember what they were, so... apparently not. |
| 22:58 | <Tabatkins> | I think fantasai and I skipped them to work on the slides for out later session. |
| 22:58 | <othermaciej> | do you mean on the tech plenary day? |
| 22:59 | <tantek> | othermaciej yes |
| 22:59 | <tantek> | Tabatkins I' |
| 22:59 | <tantek> | I'll take that as "none" for you and fantasai then |
| 22:59 | gavinc | got no value what so ever as the WGs he's part of didn't go to TPAC last year, and are going this year but now the TPAC is in Europe and can't get funding and there is no remote on the TPAC site this year :( I am a sad panda |
| 23:00 | <Tabatkins> | More of an "abstain", but close enough to be "none". |
| 23:00 | <Tabatkins> | gavinc: I'll take you in my baggage. |
| 23:01 | <tantek> | more of a "decided to not go" than "abstain" which if anything is a vote against based on pre-evaluation. |
| 23:02 | <smaug____> | uh, almost forgot tpac... more traveling this year |
| 23:02 | <hober> | IIRC the unconference part of the day was worthwhile |
| 23:02 | <hober> | but I don't remember the non-unconference part. |
| 23:02 | <Tabatkins> | tantek: Yeah, but we had things to do, and also the weather was *gorgeous* outside. |
| 23:02 | <Hixie> | i got a lot of OpenTTD done that week |
| 23:02 | <tantek> | hober - I'll take "don't remember" as a "none" |
| 23:03 | <Hixie> | other than that, pretty much every meeting i was in that i thought was productive (not many to start with) ended up being a no-op because the decisions made there were reversed or abandoned within a month or two |
| 23:03 | <Hixie> | so i'd have to go with "negative" |
| 23:03 | <Tabatkins> | Hixie: He's not polling about WG meetings. |
| 23:03 | <Hixie> | i didn't go to any wg meetings |
| 23:03 | <Tabatkins> | Oh, ok then. |
| 23:04 | <Hixie> | those i _knew_ are a waste of time :-) |
| 23:05 | <tantek> | Hixie - I thought I saw you in the HTMLWG meeting - or was I hallucinating that? |
| 23:05 | <Hixie> | oh yeah there was that tv-related thing |
| 23:05 | <Hixie> | forgot that that was a wg meeting |
| 23:05 | <tantek> | I have a vague memory of time element discussions that were fairly productive |
| 23:06 | <tantek> | but some of that was also in informal lobby conversations as well |
| 23:06 | <Hixie> | the time element discussions were productive in that you and i spent 5 minutes at lunch time and that resulted in the whatwg spec being updated to the right thing, and the htmlwg still hasn't figured out the resolution to that topic. |
| 23:06 | <tantek> | either way - it was good to see you at TPAC even if for only a day or two. |
| 23:06 | <Hixie> | last year i was thinking of doing a "whatwg team building day" on the wednesday |
| 23:06 | <Hixie> | but the w3c and hsivonen convinced me not to |
| 23:06 | <tantek> | Hixie - htmlwg has resolved on both issue 183 and 184 AFAIK, and consistent with the whatwg spec changes/resolutions. |
| 23:07 | <Tabatkins> | Dammit, I wanted to do that. |
| 23:07 | <tantek> | (those are the time/data issues) |
| 23:07 | <Hixie> | tempted to try again in 2013 (assuming 2012 is in europe) |
| 23:07 | <tantek> | what would be a whatwg team building day? like go rock climbing somewhere together? |
| 23:07 | <Hixie> | tantek: i thought there were still some oustanding, but ok, i can't claim to have looked closely |
| 23:07 | <Hixie> | my idea was to rent a bunch of buses and take everyone down to the exploratorium |
| 23:08 | <tantek> | Hixie, there were, but there's been progress today on both issues. |
| 23:08 | <Hixie> | and do some sort of puzzle hunt there |
| 23:08 | <Hixie> | "progress" |
| 23:08 | <Hixie> | c.f. the whatwg spec resolved this last year |
| 23:08 | <tantek> | "progress" meaning actual HTMLWG decisions and issue closures. |
| 23:08 | <Hixie> | pardon me for having stopped caring entirely :-) |
| 23:08 | <Hixie> | (about the htmlwg) |
| 23:09 | <tantek> | Hixie, I realize the delay in changes/decisions in comparison. I decided to in good faith attempt to pursue the issue resolution path in HTMLWG. |
| 23:10 | <Hixie> | anyway, yeah, if the tpac is back in the bay area some time i'll look into doing some sort of proper team-building day again |
| 23:10 | <tantek> | I expect so in 2013 |
| 23:10 | <Hixie> | right |
| 23:11 | <hober> | sounds fun |
| 23:11 | <tantek> | BTW I think they're constructing a new Exploratorium on the bay (forgot which Pier #) and moving everything. |
| 23:11 | <Hixie> | oh neat! |
| 23:11 | <tantek> | not sure if that will be done or not by 2013 TPAC |
| 23:12 | <tantek> | http://www.exploratorium.edu/piers/ |
| 23:12 | <Hixie> | they say "in 2013" |
| 23:12 | <tantek> | Pier 15 apparently |
| 23:12 | <Hixie> | spring 2013! |
| 23:12 | <Hixie> | dude that's awesome |
| 23:12 | <Hixie> | we should definitely do that |
| 23:12 | <Hixie> | anyway, that's like 18 months away |
| 23:13 | <Hixie> | afk, bbiab |
| 23:14 | <tantek> | couldn't find a timeline, but yeah spring 2013 sounds good. also this is cool: http://www.exploratorium.edu/piers/creatingcampus.php?show=inside |
