2013-01-01 [20:28:12.0000] well i didn't get to 0/0 by year-end, but I got pretty close on e-mails, and we're at about the same level in bugs as we were at the start of the year, which isn't bad given the influx [20:28:44.0000] i guess the things i was planning on doing in january are gonna need to be pushed on to april, though [13:04:19.0000] Man, having multiple globals sure causes a ton of grief... [13:06:17.0000] globals all the way down. 2013-01-02 [06:48:29.0000] I feel like Björn wrote that www-archive message for me... [07:50:27.0000] pbarth: did you merry Adam? [07:50:39.0000] marry, doh [09:10:59.0000] heycam|away: yt? [09:11:14.0000] heycam|away: can you default to a string literal in IDL? [09:14:40.0000] http://dev.w3.org/2006/webapi/WebIDL/#prod-DefaultValue says yes [11:54:23.0000] [1000, -1, -2, Infinity, -Infinity, NaN].forEach(function(x) { try { document.createElement('select').options.add(document.createElement('option'), x); } catch (e) { console.log(x + ": " + e); } }) [11:55:14.0000] FF17 throws on +/-Infinity. Chrome 23/Safari 6/IE10 throw on -2, +/-Infinity and NaN [11:57:20.0000] Based on the HTML + WebIDL specs I wouldn't expect any of them to throw. :P [12:07:54.0000] optional (HTMLElement or long)? before = null [12:08:35.0000] I don't remember stuff fully to be confident, but I think that takes either an element, or any value (which will then be coerced to long) [12:08:45.0000] so, yeah, not throwing at all I *think* might be spec-right [12:09:03.0000] /me doesn't remember the option interface well enough to know what of these options is at all sane [12:22:29.0000] jwalden: I noticed this futzing with the ES number-> IDL long conversion code. [12:23:04.0000] unsurprising :-) [12:23:37.0000] Could toss an [EnforceRange] in the spec's IDL to get throwing behavior on non-finites, but dunno why FF distinguishes NaN, and throwing on < -1 would require prose anyway. [12:23:40.0000] another fun thing to test is { valueOf: function() { return "bazinga"; } } [12:23:46.0000] er, s/return/throw/ [12:25:23.0000] I haven't tried, but I bet incrementing a counter in valueOf would give inconsistent results as well. [12:26:06.0000] undoubtedly :-) [12:33:51.0000] /me tries reading Gecko variant code to figure out what causes that behavior, spends too much time following twisty passages, gives up [12:34:18.0000] we'll adhere to webidl requirements in semi-short order, I expect [12:34:32.0000] /me doesn't know the timeline for this particular bit of code being converted, tho [12:44:36.0000] jsbell: are you sure long accepts NaN? [12:44:41.0000] jsbell: that seems kinda unlikely [12:46:38.0000] jsbell: don't mind me, I'm wrong :/ [12:48:39.0000] jwalden: btw, Ms2ger explained why that algorithm was correct after all [12:49:04.0000] jwalden: the global named properties are on some prototype object [12:49:47.0000] /me would have thought long == Int32, and ECMAScript conversions would use the ToInt32 operator [12:49:50.0000] jwalden: so using the [[GetOwnProperty]] would get there eventually [12:50:00.0000] jwalden: yeah that's correct [12:50:01.0000] if that's not the case, that's mildly surprising [12:50:27.0000] in which case NaN would become 0 for your test, jsbell [12:50:32.0000] it's ToInt32(ToNumber(V)) [12:50:48.0000] ToNumber(NaN) => NaN, ToInt32(NaN) => 0 [12:50:50.0000] http://dev.w3.org/2006/webapi/WebIDL/#es-long (with some exceptions for extended attributes) [12:50:53.0000] for better or worse [12:51:14.0000] but Infinity also becomes 0 [12:51:22.0000] and Gecko throws for that... [12:51:36.0000] Gecko [12:51:37.0000] er [12:51:52.0000] Gecko's not using webidlish code right now, so all bets are off as to what it does :-) [12:52:00.0000] at least, not for that particular interface/method/argument [12:52:04.0000] fair enough [12:52:25.0000] /me will be glad when non-webidl stuff is all dead [12:53:36.0000] yeah, then we can start fighting Web IDL [12:53:48.0000] or something like that :) [12:54:51.0000] I shouldn't be, but I'm continually amazed by how much of Gecko semantics is just "that's what the random internal method that happened to be used, did" [12:55:44.0000] it seems kinda natural for any system that grows big, to have a lot of inconsistencies [12:56:11.0000] you get that even when there's one person developing the system for an extended period of time [12:57:37.0000] I dunno, I find algorithms are just that much worse to read, usually, if they're not isomorphic to the spec steps [12:58:17.0000] which naturally leads me into writing helper methods like ToUint32 or whatever, where at least if they're wrong it's just a matter of changing guts [12:58:43.0000] rather than having to change a hundred places all converting in different ways [12:58:53.0000] meh, doesn't really matter at this point [12:59:04.0000] well that certainly makes sense :) [12:59:36.0000] I meant more what came before the standard and to some extent the standards we're developing now; that they all have their inconsistencies [12:59:58.0000] true enough [13:21:08.0000] jwalden: re: "what the random internal method... did" - and the resulting specs are such fun to implement, because you know that in some code base, somewhere, there's some trivial and probably very efficient implementation of what seems like an insanely baroque algorithm. [13:22:01.0000] in my experience, usually the internal method is also insanely baroque and inefficient :-) [13:22:23.0000] with special cases nobody's seriously thought through because some random page needed something [13:22:25.0000] Sure, kill my sense of hope... ;-) [13:22:31.0000] even redundant special cases [13:22:33.0000] heh [13:29:06.0000] jsbell: not sure what specs you're reading, but I usually aim to simplify what the implementations did [13:37:13.0000] i have no idea what that mail on www-archive means [13:38:17.0000] Hixie, "encodings suck" [13:42:13.0000] It's about BOM taking precedence over the encoding declaration and supposedly whether X-Content-Type-Options should influence that or not... And whether it's a good idea to begin with. Overall I took it as subtle critique of the Encoding Standard :-) [13:55:15.0000] sounds complicated [14:39:40.0000] Hixie: Saw "An error occurred submitting your review comment" from the HTML spec. Maybe I typed too much, maybe there's a back-end issue. [14:40:44.0000] looking... [14:40:50.0000] (did you save your comment text, perchance?) [14:41:31.0000] Hixie: it does not appear to have been cleared from the input field, so yes [14:41:37.0000] i got back a "Text Too Long" from bugzilla [14:41:42.0000] thought i worked around that though [14:42:13.0000] ah, i see [14:42:15.0000] let me fix this... [14:45:55.0000] jsbell: do you still have it up? [14:46:00.0000] jsbell: if so, try submitting again [14:46:25.0000] submittifying... [14:46:28.0000] success! [14:46:53.0000] sweet [14:48:30.0000] i really don't understand where these people are coming from who type in random things in that form [14:48:47.0000] got one just now that's just an address [14:48:49.0000] why would you do that? [14:51:16.0000] a bot reverse engineering the rules? [14:52:01.0000] doesn't look like it [14:52:11.0000] every one i've seen, they visit a few pages, then send a wacked comment [14:53:16.0000] maybe they're trying to do a search? [14:53:24.0000] and that's just what's got focus? 2013-01-03 [19:59:49.0000] hello [00:37:15.0000] thanks MikeSmith for the #microformats edit - I've been unsure about the rel-publisher value since I saw it show up. [00:43:59.0000] tantek: somebody asked about it on the www-validator list (asked why the validator doesn't support it despite it being on the wiki page) [03:52:16.0000] oh, seems some of the IETF found the URL Standard again [03:52:31.0000] too bad their comments are not really actionable [04:04:22.0000] What are they saying? [04:06:33.0000] https://twitter.com/bagder/status/286544650284699648 [04:09:21.0000] I like this one too https://twitter.com/dret/status/286625563496574977 [04:09:59.0000] Especially combined with the fact that their hero Roy has been stating that URI == URL for some time now... [04:10:34.0000] Anyway, back to creating more states for more sensible error reporting... [04:40:14.0000] If you resolve http:example.org against http://example/ should that give a parse error? [04:43:02.0000] I'm going with yes... [04:55:35.0000] Hehe. One thing they do say though, is that it would indeed be nice to have a non-normative overview over what's supported. You're doing lots of findings, and then encode them into this spec, but it's not quickly referencable. Although I fear that would be too big to use in the end anyway... [04:56:38.0000] Given that it all changes over time I don't really see how that's useful. Although you could "generate" such a thing if we completed that test suite... [04:56:59.0000] Sorry, I can see how it's useful, but also how it'd be time consuming :-) [04:58:51.0000] Yeah. [05:56:46.0000] annevk: maybe diagrams like http://dev.w3.org/csswg/css3-syntax/#token-diagrams would help explaining the syntax of URLs? [06:00:22.0000] SimonSapin: yeah, the plan is to add those at some point [06:00:43.0000] SimonSapin: though the comments were about parsing [06:38:27.0000] SimonSapin: those syntax diagrams seem incomplete btw [06:38:38.0000] annevk: how so? [06:38:43.0000] SimonSapin: e.g. for url() you can also escape the u / r / l [06:39:43.0000] indeed [06:44:51.0000] annevk: or maybe not. http://www.w3.org/TR/CSS21/syndata.html#tokenization uses "url" litteraly in the token definition, not something like {u}{r}{l} [06:44:51.0000] Green in Firefox and Opera but Chromium: data:text/html, [04:52:17.0000] are we gonna see some papayawhip action? [04:52:31.0000] http://dev.w3.org/csswg/selectors4/#idref-combinators seems to suggest so, which seems kinda poor design to me [05:25:42.0000] I don't understand http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#reprojection [05:25:59.0000] How can an insertion point be a child node of a shadow host? [05:26:25.0000]
and
is tied to another ? [05:32:39.0000] it's so weird how this spec works [05:32:58.0000] so 4.6 makes requirements, and 4.7 makes them again but in an algorithm? [05:33:06.0000] what's going on? [05:39:34.0000] I imagine what's going on is that the spec has been written by a small group of people that aren't pro spec writers, are mainly interested in one implementation, and already know how things work so don't explain it clearly [05:40:10.0000] It is the sort of thing that gets fixed when e.g. you start commenting and others start implementing [05:40:47.0000] I filed a bunch of bugs already and a couple more today, not entirely sure it's helping though... [05:41:35.0000] And my main objective here is really to understand what's going on so I can adjust DOM accordingly, but maybe I should indeed wait with that but then I worry it might be too late to change Shadow DOM at some point because "Microsoft shipped" it or some silly reason like that [05:43:31.0000] Yeah, I guess assuming that Microsoft will provide feedback before they ship something broken isn't a strategy with history on its side [05:49:38.0000] So the event situation for shadow trees... Say you have and has a then you dispatch on [05:50:20.0000] traversal path becomes b > content > shadow > a I guess [05:53:21.0000] ah, but you only hit problems if the event originates from a shadow tree [06:06:14.0000] I guess a more interesting case is with both and having a shadow tree attached so you end up with something like -> -> -> and then in 's an event is dispatched [06:07:02.0000] once the event reaches 's , the target should be I suppose and not change [08:35:21.0000] good morning, Whatwg! [08:38:01.0000] huh, annevk asked some questions and left [08:41:06.0000] dglazkov: don't worry, he usually returns after realising that the real world is even more broken than web technology [08:41:54.0000] darobin: it's not broken, it's a work in progress :) [08:50:42.0000] dglazkov: I can't wait for last call then [08:51:47.0000] darobin: we were supposed to be done on Dec 21, but stuff got delayed. [08:52:06.0000] for the real world? [08:52:13.0000] I had no idea you were part of that team, too [08:52:30.0000] darobin: we're all part of that team [08:52:55.0000] no, I just do snapshots [08:53:17.0000] working on the next fossil record [08:53:41.0000] see? part of the team [10:17:50.0000] annevk: We need *some* prefix to avoid polluting the tagname namespace. x- is the closest one to hand, and the ugliness is actually a plus. [10:18:32.0000] (It should hopefully help prevent people from just scatting and elements all over their page, since they'll instead be ugly and .) [10:22:25.0000] annevk: The bit about "insertion point is a child node of another shadow host" could be written better, and have an example, but it's referring to this: [10:22:41.0000] [10:23:06.0000] That is, the children of whatever element that shadow belongs to are reprojected as children of another component. [10:23:39.0000] We went through a *ton* of pain trying to solve that problem in a simpler matter, but as far as we can tell our current solution is the only way to allow composition without everything cooperating ahead of time. [10:23:50.0000] (And even with cooperation, the selectors necessary to style things were wonky as hell.) [10:25:05.0000] The point of it is just that, from the perspective of 's own shadow tree (and it's own element selecting things from its light children), the contains the projected nodes from the outer shadow, *not* the element of the outer shadow. It's replaced in-place. [10:28:29.0000] It's sad [10:29:50.0000] Which is sad? [10:30:32.0000] That people still think custom tagnames aren't batshit insane [10:31:03.0000] Hixie's silly is='' idea is just moving the custom tagname to an attribute. It's still fucntionally a tagname in all respects - it needs to be aroudn during initial parse, and then changing it has no effect. [10:31:20.0000] It just obfuscates things. [10:31:33.0000] If you still believe that, I'm not going to bother trying to convince you [10:32:05.0000] I haven't been around during any discussions that disputed what I just said. All I've heard is reluctance to actually use tagnames, which strikes me as insubstanial. [10:32:14.0000] If you ahve real reasons why what I said above is false, lay them on me. [10:39:38.0000] Ms2ger++ [10:39:46.0000] /me has laid the reasons down in detail in the bug [10:40:03.0000] Which bug was it again, Hixie? Just title or something for me to search for. [10:40:48.0000] has "is" and "tatribute" in the summary, i think. has "select/map" in the comments. [10:40:51.0000] attribute, even [10:49:16.0000] Hixie: Ah, right, the "everything will be divs and there will be no semantics" argument, which ignores the ability to specify the tag you're descending from declaratively (via an attribute(!) on ) and via script (via document.register). The declarative version is identically informative, and more reliable, since you can't screw up and accidentally forget to apply the attribute to an instance. [10:51:39.0000]

is the same as [10:53:21.0000] i discuss that in the bug too [10:53:50.0000] having the fallback in the binding declaration puts it in the wrong place -- you want the fallback in the page itself, for reasons i elaborate on in the bug [10:56:48.0000] Yes, I'm reading through that. I don't understand the argument. Why is the location of the fallback information important, as long as everything is declaratively knowable? [11:04:14.0000] (As far as I can tell, that point isn't adequately explained in the bug.) [11:04:34.0000] requiring that every random html processor also be enough of a web components processor to get the fallback declaration is an unacceptably (and i thought obviously) high implementation burden [11:05:06.0000] and i's a burden that is put on those implementors least likely to have the bandwidth to support it [11:05:10.0000] it's [11:05:21.0000] I assume that anything capable of actually *using* the page in any worthwhile capacity is a significant HTML processor, and thus would implement the general suite of web stuff. [11:05:43.0000] i do not think that assumption is warranted. [11:06:37.0000] for example, that increases the cost of operating a web search user agent significantly (more networking required, more processing required, etc), and that's an industry where we really don't want to be making the costs any higher than they already are [11:07:15.0000] it also means that an HTML file is no longer stand-alone in its semantics, which seems like a huge and rather disturbing step to take [11:07:30.0000] Web search that cares about the meaning of elements (the bar you're setting) already has to care about CSS to some extent, at least, or it's trivially vulnerable to cloaking. [11:07:54.0000] That's a much huger requirement than asking it to parse another document which is also HTML and look for simple associations. [11:08:29.0000] only if it's being used against arbitrary web content [11:08:40.0000] most spiders are in enterprise environments where that's not really an issue [11:09:37.0000] I'm not sure why enterprise web spiders are an industry we should care particularly much about, to the point of harming the authoring experience. [11:11:48.0000] well as discussed in the bug, i think having the fallback in the markup also improves the web author experience. [11:12:30.0000] People have made the exact opposite argument in the bug, too, and I find them much more convincing. ^_^ [11:14:00.0000] /me is with Hixie on that [11:18:56.0000] TabAtkins++ [11:19:21.0000] I am sort of intrigued by "select/map" idea though [11:20:06.0000] Basically, I find it very difficult to argue that it's more helpful for developers to have to repeat the element your component descends from for every instance. It would be like having to write a chain of superclasses for every "new" call in JS. [11:20:51.0000] TabAtkins: that is true. What if for elements that extend HTMLElement, you could just have straight custom tag? [11:21:29.0000] TabAtkins: But it is vastly more helpful for processors [11:22:04.0000] Since it degrades gracefully whereas the alternative does not [11:22:05.0000] If you forgo the "input/" prefix, you need an x- prefix. Inconsistance is bad, so you'd need to put the x- prefix on the "input/" prefixed things too, which is silly. [11:23:16.0000] jgraham: The degrading possible is very minimal. If you've never worked with apps and the sort of "components" they use, it's easy to imagine that you can just slightly extend HTML's semantics and everything will be great. In reality, most components will descend from

or whatever, not because of laziness, but because *that's the most appropriate tag, given that nothing else has the right semantics*. [11:24:07.0000] jgraham: being stuck in the ghetto is a sad compromise. If you look at what web devs are doing today to make their own "tags", you'll see that it's all gone to imperative land anyhow. [11:26:29.0000] I know what people do today. I would much rather that a custom calendar widget is or whatever than . [11:26:37.0000] for example [11:27:37.0000] (not that I really like the is= syntax) [11:28:12.0000] But the idea that
is the best match semantic in the overwhelming majority of cases is clearly wrong [11:28:53.0000] There are many cases that are like a button, or like some kind of or like a list, or like a table [11:36:25.0000] jgraham: arguably, most of those cases should be bound from CSS, imho [11:40:00.0000] Oh yes [11:40:11.0000] We've got lovely experiences with binding [11:41:10.0000] Hixie: Yeah, good luck convincing Mozilla people that's a good idea :) [11:42:55.0000] ??? [11:45:06.0000] jgraham: it seems pretty clear that e.g. the button style google uses is a CSS-level thing. [11:45:24.0000] jgraham: but Mozilla already seems to do this via CSS for their themes, so I don't see why it'd be hard to convince them? [11:46:32.0000] Because we know how terrible it sucks [11:46:41.0000] bz can tell you stories [12:04:13.0000] [12:05:57.0000] See? [12:18:11.0000] I like that Hixie at least proposes interesting alternatives [12:18:40.0000] most other detractors simply engage in navel gazing [12:23:42.0000] introduction of local semantics to HTML is simply bringing it in sync with reality. It's scary and new, but angst never seemed like a good reason for anything. [12:28:33.0000] dglazkov: "navel gazing"? Do you that that's helpful? [12:29:14.0000] jgraham: probably not :) [12:29:55.0000] jgraham: but then again, if it stirs you enough to help come up with a better idea, maybe it is? :P [12:30:14.0000] Hixie, +1 for proper RAF use in your sample code :) [13:26:46.0000] dglazkov: Well the ability to declaratively reuse an existing element name is a requirement. So I can only think of three ways of declaring which component will extend it: An attribute, a parser hack, and a binding langauge. I think all three options have already been suggested. [13:30:19.0000] What if you look at it as the requirement being to just allow web authors to build their own DOM elements? The markup part of it is just a matter of consistency. [13:33:54.0000] jgraham: The "binding language" possibility is just what Web Components currently uses (), yes? [13:38:19.0000] TabAtkins: I think a "binding" is the render-then-decorate approach that CSS takes [13:38:53.0000] which decorators part of Web Components is already covering [13:42:02.0000] dglazkov: here [13:42:20.0000] dglazkov: it's Daniel ftr [13:42:20.0000] heeey csuwldcat :) [13:42:25.0000] I was thinking of something like the approach that XBL1 takes. Which, as previously mentioned, turns out to suck (according to bz) [13:42:34.0000] just left an overly frustrated comment on the bug [13:42:44.0000] correct by questionable tone, sorry [13:42:48.0000] but* [13:43:12.0000] csuwldcat, meet jgraham and Hixie and TabAtkins and the gang [13:43:19.0000] heyo! [13:43:54.0000] this whole is=, as=, thing=, can we just make it an optional semantic addon? [13:44:05.0000] (if we were not allowing anything in the markup, my response would be "why not" and if that had a good enough answer "can we use normal js inheritance") [13:44:09.0000] it's irrelevant to a majority of use-cases [13:44:15.0000] Hi everyone. I have a semantic HTML question. I have one or more sets of video game screenshots that are being showed to the viewer to compare. Like how a particular scene looks on one game platform versus others. My first thought was that this looks a lot like tabular data. I'd have gone with that, but CSS overflow support on tables is quite spotty, so I'm looking for an alternative. [13:44:20.0000] and introduces a *ton* of gotchas [13:44:50.0000] jgraham: the answer to inheritance is already there. [13:44:53.0000] BenoitRen: would have been fine, but this situation doesn't have any appreciable semantic, so use whatever's convenient. [13:45:06.0000] csuwldcat: It seems pretty essential if we want something like graceful degredation [13:45:16.0000] sure, but optional [13:45:26.0000] and making it optional wouldn't remove the gotchas [13:45:28.0000] tags default to SPAN semantics [13:45:42.0000] Yeah, that's the problem [13:46:02.0000] [13:46:11.0000] My previous point about most components reasonably descending from
means that a large fraction (likely a large majority) of components won't have a graceful degradation story in the first place. [13:46:21.0000] TabAtkins: I don't know of anything else that's convenient, except maybe a list of lists... :/ [13:46:24.0000] See: most uses of components in the while today, which are just piles of divs and such. [13:46:27.0000] TabAtkins: correct [13:46:37.0000] s/while/wild/ [13:46:49.0000] looks prettier but doesn't have the right graceful degredation story [13:47:09.0000] BenoitRen: A list of pairs, where each pair is just some elements and maybe some wrapper elements for structure, is fine. [13:47:15.0000] TabAtkins: That's a problem that we want to fix, not a desirable feature of the solution [13:47:19.0000] the problems is="" introduces if it is used as the binding/proto mechanism are untenable [13:47:35.0000] it literally could waste millions of dev hours a year [13:47:51.0000] jgraham: I submit that it's not a fixable problem, and your hope that it is fixable comes from a naivety about the problem, due to insufficient experience with what authors are doing in that space. [13:47:57.0000] Where are these problems documented? [13:48:07.0000] the bug [13:48:17.0000] TabAtkins: That works for pairs, but the particular page I'm working on compares three screenshots. [13:48:18.0000] it just went through them for probably the 12th time [13:48:25.0000] TabAtkins: I submit that you have provided no evidence that is the case and it would be good if you could do so [13:48:30.0000] !=