| 00:00 | <Hixie> | or if there should even be a detectable difference |
| 00:00 | <heycam> | I think we do! |
| 00:00 | <Hixie> | since the only difference is the type |
| 00:00 | <heycam> | it surely can't require much prose to make it work |
| 00:00 | <annevk> | wasn't that type mostly useful for developers? |
| 00:01 | <annevk> | I mean it doesn't actually affect implementations as it's a callback |
| 00:01 | heycam | doesn't know |
| 00:01 | <Hixie> | yeah in JS for onerror anything will match either type, i think |
| 00:01 | <annevk> | I'd just treat all those as one and define the superset behavior |
| 00:02 | <annevk> | for the HTMLCollection vs HTMLPropertiesCollection case I'm less sure, since that would affect me |
| 00:02 | <Hixie> | anyway i don't really care what solution we pick, just need to know what to write :-) |
| 00:02 | <annevk> | :-) |
| 00:02 | <annevk> | Hixie: see above for a sketch for onblur |
| 00:02 | <heycam> | if you want me to look at HTMLCollection and propose wording for you both, I can do that |
| 00:03 | <annevk> | Hixie: just make the element check part of the attribute definition and don't let it depend on IDL |
| 00:03 | <Hixie> | as far as i can tell, onblur is defined already. |
| 00:03 | <Hixie> | there's only one attribute. |
| 00:04 | <Hixie> | onerror is the unclear one as far as those go. |
| 00:04 | <annevk> | but onblur has implementation requirements in different places |
| 00:05 | <annevk> | even if there's only one attribute, the prose suggests they're different |
| 00:05 | <Hixie> | *shrug* |
| 00:05 | <annevk> | well that's kinda relevant one you start applying one attribute at another location |
| 00:05 | <annevk> | I'd think |
| 00:06 | <Hixie> | there's only one onblur, so if it's defined to work on one <body> element, i don't see why it wouldn't work anywhere. |
| 00:11 | <annevk> | Hixie: I guess you're saying that although the attribute is defined separately for all elements and the <body> element in particular, that's kind of an implicit if check in the attribute's implementation? |
| 00:11 | <Hixie> | right |
| 00:12 | <annevk> | Hixie: I guess I can buy that. It seems onerror is also one type now in the spec? |
| 00:14 | <annevk> | Which would leave HTMLPropertiesCollection which heycam is going to fix? :-) |
| 00:14 | <heycam> | I'll take a look at it later today and post in the bug with proposed wording |
| 00:16 | <annevk> | nn |
| 00:17 | <Hixie> | onerror is of two types |
| 00:17 | <Hixie> | but we can change that i guess |
| 03:53 | <Yuhong> | "btw, has anyone tested if IE10 has an “IE9 XML” mode in addition to an “IE10 XML” mode?" |
| 03:53 | <Yuhong> | Yes it does: http://msdn.microsoft.com/en-us/library/hh834788(v=vs.85).aspx |
| 05:52 | <karlcow> | do web notifications allow for bells? |
| 07:23 | <Hixie> | i like how http://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm has two contradictory paragraphs defining what is normative and what is not |
| 07:24 | <Hixie> | (paragraps 1 and 3 of the conf section) |
| 08:52 | <hsivonen> | https://twitter.com/g16n/status/288326241755484160 |
| 09:27 | <darobin> | "And it doesn't mean you are addressing the same way the @brucel @brucel"? |
| 09:29 | darobin | wonders how much of the web breaks if we just dropped Accept-Language entirely |
| 10:39 | <annevk> | Using x- for web components is so silly. Why hasn't that been named differently yet? x- means experimental and on top of that the IETF is over the x- experiment itself... |
| 10:43 | <Ms2ger> | I gave up trying to drill that into their heads |
| 10:58 | <jgraham> | But it's ugly and breaks functionality! What's not to like? |
| 11:00 | <Ms2ger> | Your face :) |
| 11:01 | <jgraham> | Well, I think we can all agree on that |
| 11:04 | darobin | smooches jgraham's face |
| 11:05 | Ms2ger | whacks darkcypher_bit |
| 11:05 | Ms2ger | whacks darobin |
| 11:05 | <Ms2ger> | darkcypher_bit, nvm |
| 11:05 | <darobin> | tee hee |
| 11:05 | darobin | smooches Ms2ger too |
| 11:05 | <Ms2ger> | Nooo |
| 11:05 | <Ms2ger> | Do work instead! |
| 11:06 | <karlcow> | pwet! |
| 11:07 | <Ms2ger> | Hi Karl |
| 11:07 | <karlcow> | ☺ hullo |
| 11:08 | <darobin> | Ms2ger: I find it difficult to focus on working with your sexiness hanging around like that |
| 11:08 | Ms2ger | covers his body |
| 11:37 | <annevk> | Does anyone know how Shadow DOM works at an implementation level? |
| 11:38 | <odinho> | Let's hope they do, else the one in webkit would be in very bad shape. |
| 11:42 | <annevk> | The terminology usage in the Shadow DOM spec is so sloppy :/ |
| 12:51 | <annevk> | so given |
| 12:52 | <annevk> | <a href=x>test</a> <b id=x>test</b> <style> a /href/ b { background:papayawhip } </style> |
| 12:52 | <annevk> | are we gonna see some papayawhip action? |
| 12:52 | <annevk> | http://dev.w3.org/csswg/selectors4/#idref-combinators seems to suggest so, which seems kinda poor design to me |
| 13:25 | <annevk> | I don't understand http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#reprojection |
| 13:25 | <annevk> | How can an insertion point be a child node of a shadow host? |
| 13:26 | <annevk> | <shadow><div><content/></div></shadow> and <div> is tied to another <shadow>? |
| 13:32 | <annevk> | it's so weird how this spec works |
| 13:32 | <annevk> | so 4.6 makes requirements, and 4.7 makes them again but in an algorithm? |
| 13:33 | <annevk> | what's going on? |
| 13:39 | <jgraham> | 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 |
| 13:40 | <jgraham> | It is the sort of thing that gets fixed when e.g. you start commenting and others start implementing |
| 13:40 | <annevk> | I filed a bunch of bugs already and a couple more today, not entirely sure it's helping though... |
| 13:41 | <annevk> | 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 |
| 13:43 | <jgraham> | Yeah, I guess assuming that Microsoft will provide feedback before they ship something broken isn't a strategy with history on its side |
| 13:49 | <annevk> | So the event situation for shadow trees... Say you have <a><b> and <a> has a <shadow><content match=b> then you dispatch on <b> |
| 13:50 | <annevk> | traversal path becomes b > content > shadow > a I guess |
| 13:53 | <annevk> | ah, but you only hit problems if the event originates from a shadow tree |
| 14:06 | <annevk> | I guess a more interesting case is <a><b> with both <a> and <b> having a shadow tree attached so you end up with something like <a> -> <shadow> -> <b> -> <shadow> and then in <b>'s <shadow> an event is dispatched |
| 14:07 | <annevk> | once the event reaches <a>'s <shadow>, the target should be <b> I suppose and not change |
| 16:35 | <dglazkov> | good morning, Whatwg! |
| 16:38 | <dglazkov> | huh, annevk asked some questions and left |
| 16:41 | <darobin> | dglazkov: don't worry, he usually returns after realising that the real world is even more broken than web technology |
| 16:41 | <dglazkov> | darobin: it's not broken, it's a work in progress :) |
| 16:50 | <darobin> | dglazkov: I can't wait for last call then |
| 16:51 | <dglazkov> | darobin: we were supposed to be done on Dec 21, but stuff got delayed. |
| 16:52 | <darobin> | for the real world? |
| 16:52 | <darobin> | I had no idea you were part of that team, too |
| 16:52 | <dglazkov> | darobin: we're all part of that team |
| 16:52 | <darobin> | no, I just do snapshots |
| 16:53 | <darobin> | working on the next fossil record |
| 16:53 | <dglazkov> | see? part of the team |
| 18:17 | <TabAtkins> | 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. |
| 18:18 | <TabAtkins> | (It should hopefully help prevent people from just scatting <para> and <list> elements all over their page, since they'll instead be ugly <x-para> and <x-list>.) |
| 18:22 | <TabAtkins> | 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: |
| 18:22 | <TabAtkins> | <shadow><x-foo><content></x-foo></shadow> |
| 18:23 | <TabAtkins> | That is, the children of whatever element that shadow belongs to are reprojected as children of another component. |
| 18:23 | <TabAtkins> | 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. |
| 18:23 | <TabAtkins> | (And even with cooperation, the selectors necessary to style things were wonky as hell.) |
| 18:25 | <TabAtkins> | The point of it is just that, from the perspective of <x-foo>'s own shadow tree (and it's own <content> element selecting things from its light children), the <x-foo> contains the projected nodes from the outer shadow, *not* the <content> element of the outer shadow. It's replaced in-place. |
| 18:28 | <Ms2ger> | It's sad |
| 18:29 | <TabAtkins> | Which is sad? |
| 18:30 | <Ms2ger> | That people still think custom tagnames aren't batshit insane |
| 18:31 | <TabAtkins> | 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. |
| 18:31 | <TabAtkins> | It just obfuscates things. |
| 18:31 | <Ms2ger> | If you still believe that, I'm not going to bother trying to convince you |
| 18:32 | <TabAtkins> | 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. |
| 18:32 | <TabAtkins> | If you ahve real reasons why what I said above is false, lay them on me. |
| 18:39 | <Hixie> | Ms2ger++ |
| 18:39 | Hixie | has laid the reasons down in detail in the bug |
| 18:40 | <TabAtkins> | Which bug was it again, Hixie? Just title or something for me to search for. |
| 18:40 | <Hixie> | has "is" and "tatribute" in the summary, i think. has "select/map" in the comments. |
| 18:40 | <Hixie> | attribute, even |
| 18:49 | <TabAtkins> | 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 <element>) 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. |
| 18:51 | <TabAtkins> | <p is=foo> is the same as <element name=x-foo extends=p> |
| 18:53 | <Hixie> | i discuss that in the bug too |
| 18:53 | <Hixie> | 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 |
| 18:56 | <TabAtkins> | 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? |
| 19:04 | <TabAtkins> | (As far as I can tell, that point isn't adequately explained in the bug.) |
| 19:04 | <Hixie> | 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 |
| 19:05 | <Hixie> | and i's a burden that is put on those implementors least likely to have the bandwidth to support it |
| 19:05 | <Hixie> | it's |
| 19:05 | <TabAtkins> | 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. |
| 19:05 | <Hixie> | i do not think that assumption is warranted. |
| 19:06 | <Hixie> | 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 |
| 19:07 | <Hixie> | 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 |
| 19:07 | <TabAtkins> | 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. |
| 19:07 | <TabAtkins> | That's a much huger requirement than asking it to parse another document which is also HTML and look for simple associations. |
| 19:08 | <Hixie> | only if it's being used against arbitrary web content |
| 19:08 | <Hixie> | most spiders are in enterprise environments where that's not really an issue |
| 19:09 | <TabAtkins> | 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. |
| 19:11 | <Hixie> | well as discussed in the bug, i think having the fallback in the markup also improves the web author experience. |
| 19:12 | <TabAtkins> | People have made the exact opposite argument in the bug, too, and I find them much more convincing. ^_^ |
| 19:14 | JibberJim | is with Hixie on that |
| 19:18 | <dglazkov> | TabAtkins++ |
| 19:19 | <dglazkov> | I am sort of intrigued by "select/map" idea though |
| 19:20 | <TabAtkins> | 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. |
| 19:20 | <dglazkov> | TabAtkins: that is true. What if for elements that extend HTMLElement, you could just have straight custom tag? |
| 19:21 | <jgraham> | TabAtkins: But it is vastly more helpful for processors |
| 19:22 | <jgraham> | Since it degrades gracefully whereas the alternative does not |
| 19:22 | <TabAtkins> | 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. |
| 19:23 | <TabAtkins> | 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 <div> or whatever, not because of laziness, but because *that's the most appropriate tag, given that nothing else has the right semantics*. |
| 19:24 | <dglazkov> | 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. |
| 19:26 | <jgraham> | I know what people do today. I would much rather that a custom calendar widget is <input type=calendar is=my-calendar> or whatever than <x-my-calendar>. |
| 19:26 | <jgraham> | for example |
| 19:27 | <jgraham> | (not that I really like the is= syntax) |
| 19:28 | <jgraham> | But the idea that <div> is the best match semantic in the overwhelming majority of cases is clearly wrong |
| 19:28 | <jgraham> | There are many cases that are like a button, or like some kind of <input> or like a list, or like a table |
| 19:36 | <Hixie> | jgraham: arguably, most of those cases should be bound from CSS, imho |
| 19:40 | <Ms2ger> | Oh yes |
| 19:40 | <Ms2ger> | We've got lovely experiences with binding |
| 19:41 | <jgraham> | Hixie: Yeah, good luck convincing Mozilla people that's a good idea :) |
| 19:42 | <a-ja> | <input type=calendar data-is=my-calendar> ??? |
| 19:45 | <Hixie> | jgraham: it seems pretty clear that e.g. the button style google uses is a CSS-level thing. |
| 19:45 | <Hixie> | 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? |
| 19:46 | <Ms2ger> | Because we know how terrible it sucks |
| 19:46 | <Ms2ger> | bz can tell you stories |
| 20:04 | <dglazkov> | <input type=redundant is=redundant class=redundant class=redundant> |
| 20:05 | <Ms2ger> | See? |
| 20:18 | <dglazkov> | I like that Hixie at least proposes interesting alternatives |
| 20:18 | <dglazkov> | most other detractors simply engage in navel gazing |
| 20:23 | <dglazkov> | 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. |
| 20:28 | <jgraham> | dglazkov: "navel gazing"? Do you that that's helpful? |
| 20:29 | <dglazkov> | jgraham: probably not :) |
| 20:29 | <dglazkov> | jgraham: but then again, if it stirs you enough to help come up with a better idea, maybe it is? :P |
| 20:30 | <jamesr> | Hixie, +1 for proper RAF use in your sample code :) |
| 21:26 | <jgraham> | 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. |
| 21:30 | <dglazkov> | 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. |
| 21:33 | <TabAtkins> | jgraham: The "binding language" possibility is just what Web Components currently uses (<element extends>), yes? |
| 21:38 | <dglazkov> | TabAtkins: I think a "binding" is the render-then-decorate approach that CSS takes |
| 21:38 | <dglazkov> | which decorators part of Web Components is already covering |
| 21:42 | <csuwldcat> | dglazkov: here |
| 21:42 | <csuwldcat> | dglazkov: it's Daniel ftr |
| 21:42 | <dglazkov> | heeey csuwldcat :) |
| 21:42 | <jgraham> | I was thinking of something like the approach that XBL1 takes. Which, as previously mentioned, turns out to suck (according to bz) |
| 21:42 | <csuwldcat> | just left an overly frustrated comment on the bug |
| 21:42 | <csuwldcat> | correct by questionable tone, sorry |
| 21:42 | <csuwldcat> | but* |
| 21:43 | <dglazkov> | csuwldcat, meet jgraham and Hixie and TabAtkins and the gang |
| 21:43 | <csuwldcat> | heyo! |
| 21:43 | <csuwldcat> | this whole is=, as=, thing=, can we just make it an optional semantic addon? |
| 21:44 | <jgraham> | (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") |
| 21:44 | <csuwldcat> | it's irrelevant to a majority of use-cases |
| 21:44 | <BenoitRen> | 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. |
| 21:44 | <csuwldcat> | and introduces a *ton* of gotchas |
| 21:44 | <dglazkov> | jgraham: the answer to inheritance is already there. |
| 21:44 | <TabAtkins> | BenoitRen: <table> would have been fine, but this situation doesn't have any appreciable semantic, so use whatever's convenient. |
| 21:45 | <jgraham> | csuwldcat: It seems pretty essential if we want something like graceful degredation |
| 21:45 | <csuwldcat> | sure, but optional |
| 21:45 | <jgraham> | and making it optional wouldn't remove the gotchas |
| 21:45 | <csuwldcat> | tags default to SPAN semantics |
| 21:45 | <jgraham> | Yeah, that's the problem |
| 21:46 | <csuwldcat> | <element extends="table"> |
| 21:46 | <TabAtkins> | My previous point about most components reasonably descending from <div> means that a large fraction (likely a large majority) of components won't have a graceful degradation story in the first place. |
| 21:46 | <BenoitRen> | TabAtkins: I don't know of anything else that's convenient, except maybe a list of lists... :/ |
| 21:46 | <TabAtkins> | See: most uses of components in the while today, which are just piles of divs and such. |
| 21:46 | <csuwldcat> | TabAtkins: correct |
| 21:46 | <TabAtkins> | s/while/wild/ |
| 21:46 | <jgraham> | <element extends=table> looks prettier but doesn't have the right graceful degredation story |
| 21:47 | <TabAtkins> | BenoitRen: A list of pairs, where each pair is just some <img> elements and maybe some wrapper elements for structure, is fine. |
| 21:47 | <jgraham> | TabAtkins: That's a problem that we want to fix, not a desirable feature of the solution |
| 21:47 | <csuwldcat> | the problems is="" introduces if it is used as the binding/proto mechanism are untenable |
| 21:47 | <csuwldcat> | it literally could waste millions of dev hours a year |
| 21:47 | <TabAtkins> | 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. |
| 21:47 | <jgraham> | Where are these problems documented? |
| 21:48 | <csuwldcat> | the bug |
| 21:48 | <BenoitRen> | TabAtkins: That works for pairs, but the particular page I'm working on compares three screenshots. |
| 21:48 | <csuwldcat> | it just went through them for probably the 12th time |
| 21:48 | <jgraham> | TabAtkins: I submit that you have provided no evidence that is the case and it would be good if you could do so |
| 21:48 | <csuwldcat> | <input type="button" is="foo" /> != <button is="foo"> |
| 21:48 | <TabAtkins> | BenoitRen: Then mark up three of them. Don't overthink it. |
| 21:48 | <csuwldcat> | one could/will cause explosions |
| 21:49 | <csuwldcat> | but devs will *never* think about the reason why |
| 21:49 | <jgraham> | csuwldcat: Let me reread the bug |
| 21:49 | <BenoitRen> | TabAtkins: Like <dl><dt><img></dt><dd><img></dd><dd><img></dd></dl>? |
| 21:49 | <csuwldcat> | you cannot have an element defintion that materially relies on an element proto and expect it to interop when slapped on random other elements |
| 21:50 | <BenoitRen> | TabAtkins: I'm overthinking it because I'd like to do it right, even if a little bit. :) |
| 21:52 | <csuwldcat> | it's not just a preference, is="" is nearly a technical/API non-starter |
| 21:53 | <csuwldcat> | it has real consequences that are significant and error-prone |
| 21:53 | <csuwldcat> | I could care less about introducing a descriptor attribute |
| 21:53 | <csuwldcat> | knock yourself out |
| 21:54 | <jgraham> | That sounds like complaining that if you create an object that inherits from class A and try to use methods of class B it will fail. Well yes, but that doesn't seem to be something that people have difficulty understanding. |
| 22:00 | <csuwldcat> | jgraham: you used a imperitive construction to make the case for declaritive interop difficulty |
| 22:00 | <csuwldcat> | ? |
| 22:02 | <csuwldcat> | the point is, you're not constructing an concrete class, is="" is packed with inference, by nature |
| 22:15 | <gsnedders> | jgraham: Um, etree_lxml hasn't been tested in ages. |
| 22:16 | <gsnedders> | So lxml support has all kinds of weird bugs. :( |
| 22:27 | <BenoitRen> | TabAtkins: I went with a bunch of <ul class="comparison">. Thanks for the assistance! :) |
| 22:33 | BenoitRen | is out |
| 22:33 | <BenoitRen> | Laters. |
| 22:34 | <Hixie> | csuwldcat: Web Components is the optional add-on, not the semantics. |
| 22:43 | <dglazkov> | Hixie: I wonder if the gist of the whole argument is on whether we should allow authors to introduce local semantics. |
| 22:51 | <Hixie> | dglazkov: "semantics" is what the author and reader agree the semantics are. On the Web, that means something that the browser vendor and page author both agree is defined in a specification. It is basically impossible for an author to unilaterally introduce new semantics. |
| 22:51 | <Hixie> | dglazkov: i do agree that that is probably where the disagreements begin, though |
| 22:54 | <dglazkov> | Hixie: why does it need to be impossible? |
| 22:58 | <Hixie> | it doesn't _need_ to be impossible |
| 22:59 | <Hixie> | it just is |
| 22:59 | <Hixie> | if fred decides he wants a new semantic, he isn't going to be able to unilaterally write a spec for it and convince all the browser vendors to adopt it |
| 22:59 | <Hixie> | heck i write the spec for HTML as my fulltime job and i can barely do it |
| 23:00 | <dglazkov> | if fred could come up with a new set of tags to describe some concepts in his web applications, he should be able to do it. |
| 23:00 | <Hixie> | that's not new semantics |
| 23:01 | <dglazkov> | oh? |
| 23:01 | <Hixie> | <Hixie> dglazkov: "semantics" is what the author and reader agree the semantics are |
| 23:01 | <Hixie> | i.e. the spec. |
| 23:01 | <dglazkov> | they mean something to fred and all other authors of this web app |
| 23:02 | <Hixie> | that's fantastic. still not semantics though. |
| 23:02 | <dglazkov> | that's just one type of semantics. The public semantics. |
| 23:02 | <Hixie> | it's not public if it's just the authors of the page |
| 23:02 | <dglazkov> | what fred has is local semantics |
| 23:03 | <Hixie> | ok fine, we can define that as "local semantics" |
| 23:03 | <Hixie> | local semantics is worthless. |
| 23:03 | <Hixie> | (on the large scale) |
| 23:03 | <Hixie> | (which is what matters) |
| 23:05 | <dglazkov> | interestingly, the value of local semantics is not zero on the large scale. If fred writes a successful library that's used by many authors, his set of tags may be used by unnamed editor of HTML spec to turn them into public semantics. |
| 23:06 | <Hixie> | there is marginal incremental value, sure, but it's not of relevance to this discussion |
| 23:06 | <Hixie> | specifically, "local semantics" doesn't address any of the problems that we need semantics for, namely, fallback in legacy UAs, fallback in non-web-component-aware UAs, ability for new authors to understand what's going on, ability for UAs to determine page meaning without fetching other resources, etc. |
| 23:06 | <Hixie> | all the things discussed in the bug. |
| 23:07 | <Hixie> | it's the same reason we have em, strong, cite, a, dfn, q, small, s, abbr, data, time, code, var, samp, sub, sup, ruby, etc, rather than just letting authors make up their own elements and use CSS to style them. |
| 23:08 | <Hixie> | the same reason people use HTML rather than just XML+script+css |
| 23:09 | <dglazkov> | well, fred that we're talking about is already using json+script+css, precisely because HTML wouldn't let him have local semantics. |
| 23:14 | <Hixie> | dglazkov: i've nothing against adding local semantics hooked to real semantics |
| 23:15 | <dglazkov> | The problems you mentioned are real, though I can't exactly measure their real impact. |
| 23:16 | <dglazkov> | Hixie: that is a ghetto approach, which is why I am not super in love with it. I am intrigued by the idea, though. |
| 23:16 | <Hixie> | what do you mean by "ghetto" in this context? |
| 23:17 | <dglazkov> | "here's a playground for your kind (the web dev), let the browser do their thing and don't bother us" |
| 23:18 | <Hixie> | ah. then i disagree. |
| 23:18 | <dglazkov> | I think it's a fair question (that I've been asked many times): why can't a web developer build their own tag that behaves just like the built-in one? the ghetto makes it clear where the real folks live, and where the toy people should play. |
| 23:18 | <Hixie> | it's not toy people |
| 23:18 | <Hixie> | it's extensions. |
| 23:18 | <Hixie> | extensions are qualitatively different than built-in features. |
| 23:19 | <dglazkov> | extensions is just a nice word for ghetto |
| 23:19 | <dglazkov> | built-in should be abolished as a concept eventually |
| 23:19 | <Hixie> | i completely disagree with that |
| 23:19 | <dglazkov> | everything is just custom elements that UA happened to provide |
| 23:20 | <dglazkov> | Hixie: I know :) |
| 23:21 | <Hixie> | these are the same arguments we had when xml came to be |
| 23:21 | <Hixie> | people were pushing the idea that people would be able to make up their own language |
| 23:21 | <dglazkov> | the idea to make up their own language, as a self-goal, is crazy and stupid. |
| 23:22 | <Hixie> | how is that different than "everything is just custom elements"? |
| 23:24 | <dglazkov> | because with the latter, the goal is to make the entire surface of Web platform inherently consistent and hackable. If some crazy nut decides to go invent their language with it, I am not going to stop them. |
| 23:24 | <Hixie> | TabAtkins: do i have to put anything about :user-error in the html spec? and if so, what? |
| 23:24 | <dglazkov> | Hixie: he's not at desk |
| 23:25 | <Hixie> | dglazkov: i think the goal of "make the entire surface of Web platform inherently consistent and hackable" is as misguided as the goal behind Perl6 of making the language itself mutable |
| 23:25 | <Hixie> | having concrete things that don't change is _good_, it's what makes the language approachable and usable |
| 23:25 | <Hixie> | you find someone else's work, you can tell how it works |
| 23:25 | <Hixie> | because it uses the same language you know |
| 23:26 | <Hixie> | if people can just mutate anything at will, it becomes nigh on impossible to maintain other people's work |
| 23:26 | <dglazkov> | it's a requirement for any platform to be usable. Unlike what it is now |
| 23:26 | <dglazkov> | Hixie: you're taking this to the deep end |
| 23:26 | <Hixie> | i disagree that it's a reqirement for the platform to be usable |
| 23:26 | <Hixie> | first, i don't know of any platform that actually does this and is widely used. |
| 23:27 | <Hixie> | second, the web is clearly usable, since it's used. |
| 23:27 | <Hixie> | it's the world's most used platform. |
| 23:27 | <Hixie> | sure, it can be made easier and more powerful |
| 23:27 | <Hixie> | but i don't see any reason to believe that making its core pillars mutable is a step towards that |
| 23:27 | <Hixie> | rather than a step awauy |
| 23:27 | <Hixie> | away |
| 23:28 | <dglazkov> | Hixie: I know :) I wonder if it's because you need some experience building and maintaining a good-sized web app. Then you'll see what I am talking about. Most web devs today spend most of their time fighting the platform, not working with it |
| 23:29 | <dglazkov> | making core pillars mutable sounds a bit different from what I am talking about |
| 23:31 | <dglazkov> | the web is definitely clearly usable. But it sucks as an application platform. And there's a lot of folks (including me) who think it shouldn't. |
| 23:31 | <Hixie> | i do write web apps, dunno how big they have to be to count as "good-sized", but my most recent mostly complete one is thousands of lines of JS, thousands of lines of HTML, and thousands of lines of server-side code. |
| 23:32 | <zewt> | it sure doesn't suck as an application platform (which isn't to say it doesn't have tons of room for improvement) |
| 23:32 | <Hixie> | there are certainly things in the platform that suck and are hard to deal with |
| 23:33 | <Hixie> | but i don't think being able to invent your own language is a solution to any of them |
| 23:33 | <zewt> | for many things i prefer it for application development over native development (especially when there's any gui involved), so i can only say it sucks in that respect to an equal or lesser degree than alternatives |
| 23:33 | <dglazkov> | again, you're trying to misrepresent what I am trying to say |
| 23:33 | <Hixie> | i'm not trying to |
| 23:33 | <zewt> | (that's a pretty accusatory thing to say) |
| 23:33 | <dglazkov> | inventing own language is not the goal |
| 23:33 | <Hixie> | if i am doing so it is because i don't understand what you are saying. |
| 23:33 | <dglazkov> | Hixie: then it's accidental |
| 23:33 | <Hixie> | which seems quite likely since i think what you're saying makes no sense :-) |
| 23:34 | <Hixie> | (wc says said app is about 20,000 lines of html, js, perl, and freepascal) |
| 23:34 | <zewt> | is http://krijnhoetmer.nl/irc-logs/whatwg/ down? |
| 23:34 | <Hixie> | (fwiw) |
| 23:34 | <zewt> | (looking for context) |
| 23:34 | <dglazkov> | Hixie: that's a lot of lines |
| 23:34 | <Hixie> | (though it has no shims to make things work in down-level clients, which i wouldn't be surprised to see double it) |
| 23:35 | <Hixie> | it's not that many lines, but it's relatively dense code |
| 23:36 | <dglazkov> | what component approach did you take, if it's not a secret? |
| 23:37 | <Hixie> | two approaches, mostly |
| 23:37 | <Hixie> | well, three |
| 23:37 | <csuwldcat> | whoa, just read the last few minutes - helllllo hyperbole! |
| 23:38 | <Hixie> | one was "add things i need to the HTML spec and wait for them to be implemented", but obviously that doesn't scale and i wouldn't say i really used that :-) |
| 23:38 | <Hixie> | the main one was i used canvas (it's a visual game); i used a lot of what i learnt from this project in the speccing of addHitRegion(), fwiw. |
| 23:38 | <Hixie> | and the third is that i am waiting for web components to enable me to extend <input> to provide a better UI for what I want; in the meantime I'm using the closest matching <input> type. |
| 23:39 | <csuwldcat> | Hixie: for some perspective, not a *single* web developer at mozilla that has used/discussed/explored custom elements has thought is="" _is_ was a good idea |
| 23:40 | <Hixie> | csuwldcat: i don't think it's a great idea either. |
| 23:40 | <csuwldcat> | why can't is/as just be optional |
| 23:40 | <csuwldcat> | ? |
| 23:41 | <csuwldcat> | why burden and obfiscate the interface with such inference? Especially when the inference is singly to serve a tangential need? |
| 23:41 | <Hixie> | almost nobody would use it if it was optional, since most people don't undersand why semantics matter |
| 23:41 | <Hixie> | same reason people used to use <font> all the time |
| 23:41 | <csuwldcat> | <x is="foo"> |
| 23:42 | <csuwldcat> | nothing forces they to comply |
| 23:42 | <Hixie> | indeed. nothing stops people from just using xml and css today. |
| 23:43 | <Hixie> | but by saying things are required, and making the language ergonomics encourage particular behaviours, we can increase the chances. |
| 23:43 | <a-ja> | or div & span with data- |
| 23:44 | <Hixie> | indeed |
| 23:44 | <Hixie> | and some people do indeed just use <div>s |
| 23:44 | <Hixie> | and it's sad when they do |
| 23:44 | <Hixie> | but at least the language encourages them not to |
| 23:44 | <csuwldcat> | Hixie, so you're afraid of the circumstance where a developer creates a custom element - that semantically kin to an existing element - and explicitly not using extends="input", for instance? |
| 23:44 | <Hixie> | e.g. it's easier to use <nav> than <div class="nav"> |
| 23:45 | <csuwldcat> | what is the barrier to entry for extends="" *once* vs is="" 1000 times repeditively? |
| 23:45 | <Hixie> | csuwldcat: that is a fear, yes. more specifically, i'm worried people won't make it clear in the markup itself that it is an input. |
| 23:45 | <csuwldcat> | what is the need? |
| 23:45 | <Hixie> | so first, notice i am not suggestion we use is="" |
| 23:45 | <Hixie> | and haven't for a long time |
| 23:45 | <Hixie> | and please read the relevant bug where i discuss the reasons for all this |
| 23:45 | <csuwldcat> | UA just parses the <element extends="input" name="x-foo"> |
| 23:45 | <Hixie> | UA has to download the file that contains the <element> first |
| 23:45 | <Hixie> | that's one of the problems |
| 23:46 | <csuwldcat> | you have a chicken egg here |
| 23:46 | <csuwldcat> | how will it know to use is? |
| 23:46 | <Hixie> | ? |
| 23:46 | <csuwldcat> | is=""? |
| 23:46 | <Hixie> | antecedant error |
| 23:46 | <csuwldcat> | bc you code it to know this? |
| 23:46 | <csuwldcat> | the parser |
| 23:46 | <csuwldcat> | if it takes code to recognize is |
| 23:46 | <Hixie> | antecedent even |
| 23:46 | <Hixie> | i don't know what you're asking, sorry |
| 23:46 | <csuwldcat> | does it not take code to pull link |
| 23:46 | <csuwldcat> | either way you need to add something, no? |
| 23:47 | <csuwldcat> | either is="" recognition |
| 23:47 | <csuwldcat> | or extends="" recognition |
| 23:47 | <csuwldcat> | the same ends can be achieved, no? |
| 23:47 | <Hixie> | i really have no idea what you're talking about right now. can i beg you to start over with a complete sentence that doesn't require prior context in this conversation? :-) |
| 23:48 | <csuwldcat> | ok, in the element defintion <element name="x-tag-completer" extends="input"> |
| 23:48 | <csuwldcat> | you declare your kin, what you are most like, or want to be |
| 23:48 | <csuwldcat> | obviously the browser would need to be coded to recognize this |
| 23:49 | <csuwldcat> | similarly it would need additional code to recognize is="" |
| 23:49 | <csuwldcat> | it seems to me, the single difference here, is that you are unhappy with not forcing the choice of an existing native element to inherit from |
| 23:49 | <csuwldcat> | am I wrong? |
| 23:50 | <Hixie> | my problem is that a UA that doesn't know anything about Web Components, when it sees <x-tag-completer>, has no idea what this is |
| 23:50 | <Hixie> | such a UA needs to see that as an <input> |
| 23:50 | <csuwldcat> | does it not have the same effect as a HTMLSpanElement in UA land? |
| 23:51 | <Hixie> | so e.g. <input/tag-completer>, which parses as <input> in legacy UAs, and as an <input> element implementing the "tag-completer" component in Web Component-aware UAs. |
| 23:51 | <Hixie> | yes, that's the problem, <x-tag-completer> is like <foo> or <span>, not like <input> which is what it should be like if a tag-competer is some sort of input widget. |
| 23:51 | <Hixie> | when you get a reference to the element, it should implement HTMLInputElement in both new and old UAs |
| 23:51 | <Hixie> | when you are a search engine you should be able to tell that it's a form control without knowing about web components |
| 23:52 | <csuwldcat> | Hixie: I know the crawlers execute js and grab linked docs |
| 23:52 | <Hixie> | when you only have the HTML file and not the web components, your data analysis tool should be able to know it's a form control and not, say, a section |
| 23:53 | <csuwldcat> | so that isn't the blocker it is being made out to be |
| 23:53 | <csuwldcat> | if you have the page, it will have the link |
| 23:53 | <csuwldcat> | and custom element internal elements will be native mostly |
| 23:53 | <Hixie> | requiring that tiny spiders implement web components just to be able to tell that it's an input is imho putting the burden on the wrong side of the balance. |
| 23:54 | <csuwldcat> | Let me admit something, you are in part right |
| 23:54 | <csuwldcat> | not forcing people through a fail-prone attribute may result in less is="" users |
| 23:54 | <csuwldcat> | I'll openly admit that |
| 23:55 | <csuwldcat> | However |
| 23:55 | <Hixie> | let me repeat that i am not proposing is="" |
| 23:55 | <csuwldcat> | input/foo? |
| 23:55 | <Hixie> | that's my latest proposal, yes |
| 23:55 | <csuwldcat> | how about <x/foo>.... |
| 23:55 | <Hixie> | the "input" part is the part i care about |
| 23:55 | <csuwldcat> | see what I did there ;) |
| 23:55 | <Hixie> | if you do <x/foo> the validator can say "look dude, that's not HTML" |
| 23:56 | <Hixie> | which is enough to push a lot of people towards doing it right |
| 23:56 | <csuwldcat> | x-foo or x/foo, brevedy and felt need will win |
| 23:56 | <csuwldcat> | how do you reconcile the very real probability that the vast majority of custom elements have no equivalent? |
| 23:57 | <Hixie> | i don't think that's true, to start with |
| 23:57 | <csuwldcat> | thus rendering the exercise a monotonous, annoyance |
| 23:57 | <Hixie> | but do we have any data on that? |
| 23:57 | <csuwldcat> | I'd be willing to bet |
| 23:57 | <Hixie> | i'd love to see what kinds of components people are trying to write |
| 23:58 | <csuwldcat> | our tags at Mozilla |
| 23:58 | <Hixie> | if we had data showing this one way or the other it would significantly influence my opinions |
| 23:58 | <csuwldcat> | how do you classify a x-growbox? |
| 23:58 | <csuwldcat> | howabout a slidebox |
| 23:58 | <Hixie> | what's a "growbox"? or "slidebox"? |
| 23:58 | <csuwldcat> | flipbox? |
| 23:58 | <csuwldcat> | map? |
| 23:58 | <Hixie> | map as in map of the world, pick a country? that's a <select>. |
| 23:58 | <zewt> | please don't assume that everyone here is an expert in gecko internals :) |
| 23:58 | <csuwldcat> | growbox autoanimates height to match new injected elements |
| 23:58 | <Hixie> | that's CSS. |
| 23:58 | <csuwldcat> | basically, height: auto; transitioning |
| 23:59 | <Hixie> | shouldn't be a component at all. at least, not one in the markup. |
| 23:59 | <csuwldcat> | nope |
| 23:59 | <csuwldcat> | can't do that without this |
| 23:59 | <csuwldcat> | another annoyance we took care of |
| 23:59 | <Hixie> | then fix css to make it possible. |
| 23:59 | <csuwldcat> | haha |
| 23:59 | <csuwldcat> | On it :) |
| 23:59 | <Hixie> | things that are presenation-specific have no business being a markup-level component. they should either be in css, or css+webcomponents, but not in the html markup. |
| 23:59 | <csuwldcat> | Hixie: this is a copout "shouldn't be a component at all. at least, not one in the markup." |
| 23:59 | <Hixie> | presentation-specific |