| 00:10 | <bkardell> | :x| |
| 02:12 | <bkardell> | Hixie: where you at man? |
| 02:54 | <brian_> | dglazkov: you there? |
| 03:02 | <bkardell> | ...crickets... |
| 03:05 | <bkardell> | Hixie: It definitely seems like aside from the fact that it yields two elements, this covers a lot |
| 03:05 | <bkardell> | and that two elements only has to be in legacy/script unsupported case |
| 03:05 | <bkardell> | am I way off on that? |
| 03:07 | <bkardell> | dglazkov: in theory this can provide a plan for both legacy and script not supported |
| 03:07 | <bkardell> | you can parse them, they have semantic meaning - just a wrapper |
| 03:07 | <bkardell> | if wrappers are a serious problem then the whole interwebs are borked |
| 04:26 | <Hixie> | back |
| 06:28 | <webguynow> | My attempt at Data url's, starting with <img> turned out to be a flop. |
| 06:28 | <webguynow> | Anyone have an example ? |
| 06:29 | <webguynow> | actually, There's quite a few around, so I'm not sure what I did wrong |
| 06:30 | <odinho> | http://software.hixie.ch/utilities/cgi/data/data might help a bit too. |
| 06:33 | <webguynow> | The PHP examples look pretty darn easy. |
| 06:34 | <webguynow> | I actually encoded with Java. ReadIn the file with IOUtils and encoded with the iHarder Base64 |
| 06:35 | <webguynow> | was originally trying on my work PC, with IE9 as the browser |
| 06:37 | <webguynow> | did the same thing on another machine, and still the image does not show |
| 06:37 | <odinho> | That Hixie utility has a quite needlessy big html boilerplate. |
| 06:38 | <Hixie> | which one? |
| 06:38 | <Hixie> | oh the data kitchen |
| 06:38 | <Hixie> | yeah |
| 06:38 | <Hixie> | that's old |
| 06:38 | <odinho> | Hixie: The one I pasted :-) |
| 06:38 | <odinho> | Yeah, I figured :D |
| 06:38 | <WeirdAl> | hey, I like that data kitchen |
| 06:38 | <WeirdAl> | it works, so why mess with it? |
| 06:39 | <Hixie> | hence why it still has the boilerplate :-) |
| 06:40 | <odinho> | Yeaa, it does. Although smaller boilerplate brings nicer data uri's (if you're lazy and don't change it), data:text/html;charset=utf-8,%3C!DOCTYPE%20HTML%3E%0D%0A%3Ctitle%3ETest%3C%2Ftitle%3E%0D%0A%3Cstyle%20type%3D%22text%2Fcss%22%3E%3C%2Fstyle%3E%0D%0A%3Cp%3Ehelo |
| 06:40 | <odinho> | It was merely an observation, WeirdAl, not a break the world suggestion :P |
| 06:40 | <WeirdAl> | :) |
| 09:00 | <Ms2ger> | Clearly the data URI kitchen should be renamed |
| 09:58 | <annevk> | Indeed what is up with that? |
| 09:59 | <jgraham> | ? |
| 10:02 | <annevk> | jgraham: just a late reply |
| 10:05 | <annevk> | MikeSmith: not sure when I last disrupted myself (maybe during the summer), violated an Internet Standard quite recently, and I believe AWWW means Astronaut ;-) |
| 10:37 | <hsivonen> | annevk: I hope the TAG upholds data model compatibility: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-January/038632.html |
| 10:44 | <darobin> | hsivonen: now that annevk's on the TAG he won't be able to hang out with us anymore |
| 10:44 | <darobin> | they lock up the ivory tower to make sure of that |
| 10:49 | <Ms2ger> | <object data="../images/blue.png" type="image/gif" |
| 11:01 | <annevk> | It seems wrong that a lot of component use cases are design-orientated and would require changes to the markup. |
| 11:01 | <annevk> | That is really quite backwards... |
| 11:02 | <annevk> | hsivonen: from the newly elected I doubt many care about that strongly, if that's what you mean... |
| 11:08 | <Ms2ger> | darobin, and next :) |
| 11:08 | <Ms2ger> | darobin, this one's smaller, though ;) |
| 11:08 | <darobin> | Ms2ger: :) |
| 11:09 | <darobin> | Ms2ger: some of the Mozilla tests I approved are not very good |
| 11:09 | <darobin> | they're correct, but not great as tests |
| 11:09 | <Ms2ger> | Which ones? :) |
| 11:09 | <hsivonen> | annevk: so is upholding XML stuff now completety off TAG’s list of interests? |
| 11:09 | <darobin> | I'm accepting them on the grounds that it's better to have a poor correct test that we can improve than nothing at all |
| 11:09 | <darobin> | the ol ones notably |
| 11:10 | <Ms2ger> | And better or worse than Microsoft's average oles? |
| 11:10 | <Ms2ger> | ones? |
| 11:10 | <annevk> | hsivonen: I don't know what the TAG interests are :-) |
| 11:10 | Ms2ger | looks |
| 11:10 | <darobin> | they test useful stuff like ol@reversed and all |
| 11:10 | <darobin> | but they don't indicate what the pass condition is |
| 11:10 | <darobin> | (and I wonder if they couldn't be more automated) |
| 11:10 | <Ms2ger> | Oh, those are reftests |
| 11:10 | <darobin> | ah |
| 11:10 | <darobin> | that wasn't clear |
| 11:11 | <darobin> | but anyway, we can improve them |
| 11:11 | <Ms2ger> | Indeed |
| 11:11 | <annevk> | hsivonen: I personally care about consistency, but I'm not strictly opposed to changing XML, although that seems like a farfetched idea (and when I tried I failed) |
| 11:12 | <hsivonen> | annevk: the thing is that there’s code out there even if you change the XML spec |
| 11:12 | <hsivonen> | see 5th edition |
| 11:24 | <annevk> | Is there a browser that even implements the 5th? |
| 11:32 | <hsivonen> | annevk: dunno. If you find one, please comment on https://bugzilla.mozilla.org/show_bug.cgi?id=501837 |
| 12:32 | <Ms2ger> | darobin, yt? |
| 12:35 | <darobin> | Ms2ger: back now |
| 12:36 | <Ms2ger> | I've got a couple of tests for properties of the window object |
| 12:36 | <Ms2ger> | Can I just dump those in html/browsers/the-window-object? |
| 12:36 | <Ms2ger> | None of the subdirs really make sense |
| 12:40 | <darobin> | Ms2ger: yeah, I reckon that's good enough |
| 12:41 | <darobin> | we should strive for clarity rather than for being anal, methinks :) |
| 12:41 | <Ms2ger> | And that's coming from a HTMLWG editor? |
| 12:42 | darobin | gives Ms2ger a butterfly kiss |
| 12:42 | Ms2ger | gives darobin a pat on the back |
| 12:51 | <annevk> | still waiting for http://mcc.id.au/2010/novel.html to be released |
| 12:53 | <darobin> | wah? |
| 13:02 | <bkardell> | Hixie: re: select/map discussion. My question is - do you agree that has warts too? |
| 13:09 | <bkardell> | Your slash proposal I mean? |
| 13:11 | <annevk_> | bkardell: he won't be online for at least another four or so hours |
| 13:12 | <bkardell> | You are following that... why no comment? |
| 13:12 | <bkardell> | I'd love to hear your thoughts |
| 13:12 | <bkardell> | Congrats btw! |
| 13:13 | <annevk> | Because it's not really clear to me what problem we're solving |
| 13:13 | <bkardell> | That statement alone would have been helpful imo |
| 13:13 | <annevk> | I thought it was about components at first. But a lot of the use cases that keep coming up seem presentational in nature... |
| 13:13 | <bkardell> | Because I agree |
| 13:14 | <annevk> | And addressing presentational problems with changes in HTML markup... |
| 13:14 | <annevk> | Yeah well, there's a lot of things to look at, can't be on top of all of them :-) |
| 13:15 | <bkardell> | Gotta drop.. back in a few hours |
| 13:20 | <Ms2ger> | Hrm, I thought I had commit access to html5lib |
| 13:54 | <annevk> | Ms2ger: I can arrange that... |
| 13:55 | <annevk> | Ms2ger: you need it? |
| 13:55 | <Ms2ger> | I found a test I apparently never pushed there |
| 13:55 | <Ms2ger> | So, I guess :) |
| 13:57 | <annevk> | check again |
| 14:08 | <Lachy> | annevk, I finished updating the selectors api integration into dom http://lachy.id.au/temp/dom-core.html |
| 14:08 | <Lachy> | full diff here https://github.com/lachlanhunt/dom/commit/453f2e2457202f49bd2743966a6f2f66f78a771a |
| 14:09 | <Lachy> | it's been rebased onto your latest commit, so it's should be ready to pull it in if there's no more problems with it. |
| 14:13 | <annevk> | Lachy: need-to-resolve does not seem to point anywhere |
| 14:14 | <annevk> | in 5226 |
| 14:14 | <Ms2ger> | annevk, ta |
| 14:14 | <Lachy> | oh, that definition was dropped. I must have missed the reference to it. |
| 14:14 | <annevk> | why is refNodes nullable? |
| 14:15 | <annevk> | and if it's nullable, it should default to null, but I'm not really sure that's the right approach |
| 14:18 | <Lachy> | it's nullable to handle a case where some library function calls it like find(selector, ref), without bothering to check if ref was set to anything |
| 14:19 | <annevk> | shouldn't it be Node... btw rather than sequence<Node>? |
| 14:19 | <annevk> | hmm |
| 14:19 | <Lachy> | no |
| 14:19 | <annevk> | why not? |
| 14:19 | <Lachy> | sequence<Node> allows for a NodeList to be passed for multiple reference nodes |
| 14:19 | <annevk> | sure Node... allows for that too |
| 14:19 | <annevk> | I think anyway |
| 14:20 | <Lachy> | Huh? |
| 14:20 | <Ms2ger> | Eh? |
| 14:20 | <annevk> | if you pass the argument as ...nodelist |
| 14:20 | <Ms2ger> | Oh, hmm |
| 14:20 | Lachy | checks webidl... |
| 14:21 | <annevk> | would make sense anyway |
| 14:21 | <Ms2ger> | That's probably ES6 |
| 14:21 | <annevk> | sure |
| 14:22 | <annevk> | ah yeah, ...fds won't be in IDL yet |
| 14:22 | <Lachy> | what is fds? |
| 14:23 | <Ms2ger> | annevk's canonical name for a nodelist |
| 14:23 | <Ms2ger> | Never seen var fds = document.getElementsByClassName(...? |
| 14:23 | <Lachy> | never. |
| 14:24 | <Ms2ger> | darobin, ping |
| 14:24 | <darobin> | yes? |
| 14:24 | <annevk> | Lachy: in any event, if we do nullable, it needs to be = null as well |
| 14:24 | <annevk> | Lachy: which means refNodes is always given, but might be null |
| 14:25 | <Ms2ger> | darobin, I found a file that I need to turn into a test once CSS defines reversed counters, is there any place I can dump that? :) |
| 14:25 | <annevk> | Lachy: the algorithms don't really seem to account for refNodes being null at the moment |
| 14:25 | <darobin> | Ms2ger: hmmm, is it a CSS test? |
| 14:25 | <Lachy> | annevk, that won't work. That would screw up the algorithm for determining refNodes, where null is treated as an explicit way to say there are no refNodes. |
| 14:26 | <darobin> | Ms2ger: or an <ol> test? Or yet something else? |
| 14:26 | <Ms2ger> | darobin, it's for <ol> and <ol reversed>'s numbering |
| 14:26 | <Lachy> | so that might need to be fixed |
| 14:26 | <darobin> | Ms2ger: well, if it's really ol then I'd put it with the tests for the ol element |
| 14:26 | <Ms2ger> | Alright |
| 14:26 | <darobin> | Ms2ger: but if it's CSS, talk to the CSS WG |
| 14:26 | <Ms2ger> | I try to avoid that :) |
| 14:26 | <darobin> | which I know is cruel and unusual punishment, but hey |
| 14:26 | <annevk> | Lachy: not treating undefined and null the same is kinda icky |
| 14:29 | <annevk> | Lachy: some of your exceptions are missing "" |
| 14:29 | <annevk> | Lachy: all the stuff related to parsing should also move to Selectors |
| 14:29 | <Lachy> | I know. |
| 14:29 | <Lachy> | But it hasn't been put in there yet. |
| 14:30 | <Lachy> | I can follow up with csswg to get that done, but it should at least be kept somewhere till it is |
| 14:30 | <annevk> | a lot of stuff under "Processing selectors" should be moved to that section that should eventually go away |
| 14:30 | <annevk> | I think |
| 14:30 | <annevk> | ideally we just define the thin API layer... |
| 14:31 | <annevk> | not that I'm opposed to putting it in the DOM |
| 14:31 | <darobin> | next you'll be arguing for some modularity |
| 14:31 | <annevk> | Lachy: use append rather than add |
| 14:32 | <annevk> | darobin: I usually argue for that |
| 14:32 | <annevk> | darobin: and I usually argue argainst those that suggest it without having actually explored the options |
| 14:33 | <darobin> | annevk: I know, I've sort of met you before |
| 14:33 | <darobin> | (was just teasing) |
| 14:34 | darobin | goes back to hating inter element whitespace with a vengeance |
| 14:34 | <annevk> | firstElementChild :-) |
| 14:34 | <Ms2ger> | darobin, you can also hate my pull requests instead? |
| 14:35 | <darobin> | annevk: doesn't help me here, sadly |
| 14:36 | <darobin> | Ms2ger: in a minute, let me give the full of my hatred to IEWS first |
| 14:39 | <darobin> | Ms2ger: those changes are they submissions or reviewed stuff? |
| 14:39 | <darobin> | in other words, do I need to go through each file to check them or rather is it stuff you've removed and are pushing into place |
| 14:40 | <Lachy> | annevk, if you find any more issues, post them as a comment on the diff page. I'll get to them later. And I'll see what I can do about shifting as much as I can out of here and into Selectors. |
| 14:41 | <Lachy> | [2013-01-11 15:41:32] <Lachy> annevk, if you find any more issues, post them as a comment on the diff page. I'll get to them later. And I'll see what I can do about shifting as much as I can out of here and into Selectors. |
| 14:48 | annevk | hopes Ms2ger can review a bit |
| 14:48 | <annevk> | Lachy: thanks for the work |
| 15:17 | <annevk_> | Lachy: added a bunch of comments |
| 15:17 | <Lachy> | thanks |
| 15:17 | <Ms2ger> | darobin, it's stuff from my submission dir, dunno how careful you want to review those |
| 15:18 | <Ms2ger> | I'll try to review some Selectors later |
| 15:21 | <darobin> | Ms2ger: ok, gotcha |
| 15:26 | <Ms2ger> | SimonSapin, French Spacing means exactly what you think it means, no difference between space-after-full-stop and space-everywhere-else |
| 15:27 | <annevk> | no mushrooms involved? |
| 15:27 | <SimonSapin> | Ms2ger: oh I may have missed as step in the thread |
| 15:28 | <Ms2ger> | annevk, no, mushrooms are definitely Dutch |
| 16:04 | <zewt> | i wonder if JS engines are able to optimize the "make a native function call that returns an object, and discard the result" case: it can know the object has no other references, and collect it immediately |
| 16:05 | <zewt> | (well, if the native call declares that it returns a new object) |
| 16:07 | <bkardell> | hixie: ping |
| 16:26 | <dpk> | hello |
| 16:26 | <dpk> | i think i've found a slight lingustic flaw in the HTML LS |
| 16:26 | <dpk> | http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#dates-and-times |
| 16:27 | <dpk> | refers to months and dates as referring to a "specific proleptic Gregorian date" |
| 16:28 | <dpk> | "proleptic" is used as meaning that the Gregorian calendar is used regardless of whether it was actually used at the time; ie. you don't use the Julian calendar before 1582/1752/etc |
| 16:29 | <dpk> | but what it actually means is a date that *is* before its introduction |
| 16:30 | <dpk> | you could fix this by either changing it to say "proleptic for dates before 1582", or by introducing a definition of ‘proleptic’ just for the specification that says that |
| 16:34 | <dglazkov> | good morning, Whatwg! |
| 16:37 | <gsnedders> | zewt: That'll be done as a result of inlining and dead-code elimination |
| 16:38 | <gsnedders> | Anyhow, time for me to vanish for the weekend. |
| 16:38 | Ms2ger | waves |
| 16:43 | <annevk> | dpk: best to file a bug |
| 16:44 | <dpk> | annevk: how do i do that? |
| 16:44 | <annevk> | dpk: whatwg.org/C has a form at the bottom of the screen which you can use |
| 16:45 | <annevk> | dpk: you could also email whatwg⊙wo or go directly to w3.org/Bugs/Public and file it on WHATWG / HTML |
| 16:45 | <dpk> | oh, do the W3C have a mailing list? i'll CC that, too |
| 16:46 | <dpk> | html-public, isn't it? |
| 16:46 | <Ms2ger> | Don't crosspost |
| 16:47 | <Noah> | Ms2ger: why? |
| 16:47 | <dpk> | Ms2ger: such level of integration between the two organisations which specify the same thing would be dangerous to society, i suppose |
| 16:48 | <annevk> | dpk: it's a problem because WHATWG requires subscription so you get broken threads |
| 16:48 | <dpk> | oh, i have to subscribe? –_– |
| 16:48 | <annevk> | dpk: not at all |
| 16:48 | <dpk> | wait |
| 16:48 | <dpk> | wat |
| 16:49 | <annevk> | dpk: you can file a bug instead |
| 16:49 | <annevk> | dpk: if you use the form in the spec you don't have to subscribe or give your email to anything |
| 16:49 | <dpk> | i'd like to hear back about this, though |
| 16:50 | <annevk> | then you should either make a bug account or subscribe to the mailing list |
| 16:53 | <dpk> | but… *sigh* |
| 16:53 | dpk | makes a bug account |
| 17:00 | <annevk> | jgraham: why do you only reply to part of the argument? |
| 17:00 | <annevk> | zewt did the same, it's not really helping getting anywhere |
| 17:09 | <dpk> | k, done: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20649 |
| 17:10 | <annevk> | thanks |
| 17:13 | <yroc> | annevk: A few days ago I asked what the rationale was for the leading and trailing newlines being stripped in <pre> elements... |
| 17:13 | <yroc> | annevk: You gave me the appropriate reference here: http://www.w3.org/TR/html401/appendix/notes.html#notes-line-breaks |
| 17:14 | <yroc> | annevk: But I'm trying to relate this now to the case of a <pre> with a child <code> |
| 17:15 | <annevk> | yroc: it's just a legacy quirk |
| 17:15 | <yroc> | The leading and trailing newlines of a child <code> inside a parent <pre> are *not* stripped. |
| 17:15 | <Ms2ger> | Yep, because browsers never did that |
| 17:15 | <Ms2ger> | So nobody depends on that happening |
| 17:15 | <Ms2ger> | And it's more complicated |
| 17:15 | <yroc> | annevk: Yes, I know -- the reference you gave me was good, like I said. |
| 17:16 | <yroc> | But why doesn't the line break principle in html 4.01 apply to the case of a child <code> in a parent <pre>? |
| 17:17 | <zewt> | annevk: i sure didn't do that |
| 17:17 | <annevk> | yroc: again, it's a quirk |
| 17:17 | <zewt> | if you make the same argument twice, replying to it in one place and deleting the other isn't ignoring the repeat, heh |
| 17:18 | <annevk> | I don't think that's what happened |
| 17:19 | <yroc> | annevk: So by "quirk" you mean there's no rational reason why browsers strip leading and trailing newline of <pre> but they don't strip leading and trailing newlines of a <code> child of <pre>? |
| 17:20 | <annevk> | yes |
| 17:20 | <annevk> | gotta reboot, in trouble again :/ |
| 17:20 | <Ms2ger> | Well, there is one: stripping it from children is more work |
| 17:21 | <yroc> | Ms2ger: more work for who? UA implementors? |
| 17:21 | <Ms2ger> | Yeah |
| 17:23 | <yroc> | Ms2ger: it's so funny when you rack your brain to make sense of something, assuming that there's a well thought out intention to the why, when in some cases (like this one, apparently) there isn't |
| 17:23 | <Ms2ger> | You must be new here ;) |
| 17:23 | <yroc> | How'd ya guess?! |
| 17:24 | <yroc> | New, but learning... slowly ;) |
| 17:25 | <Ms2ger> | This is an important thing to learn, then... Not a lot has been well thought through before implementation :) |
| 17:26 | <yroc> | Ms2ger: Yes, exactly. I think that's going to be my working assumption from now on until proven otherwise :) |
| 17:26 | <Ms2ger> | Good idea :) |
| 17:27 | <yroc> | Lot less head banging that way... |
| 17:38 | <annevk_> | dunno zewt, rather not introduce new objects without constructors |
| 17:38 | <annevk_> | and a constructor here could make sense |
| 17:55 | <TabAtkins> | Ms2ger: Reversed counters? You mean, counters that you have to look forward in the document to see what value they should end up on? |
| 17:55 | <Ms2ger> | I mean something to implement <ol reversed> |
| 17:55 | <Ms2ger> | So, I guess? |
| 17:56 | <TabAtkins> | I'm curious how that would even work, actually. |
| 17:57 | <TabAtkins> | You still need to establish the counter's scope at the usual starting place. |
| 17:57 | <TabAtkins> | Maybe an end parameter on counter-reset? |
| 17:57 | <Ms2ger> | Ask bz :) |
| 17:59 | <annevk_> | dglazkov: why on both <a> and <b>? |
| 17:59 | <TabAtkins> | I see how it would work in my head, actually. I was concerned temporarily about unreachable endpoints, but actually it's always fine - you just keep a running sum of the counter-increments until the scope ends, then reverse them to get your actual starting value. |
| 17:59 | <annevk_> | dglazkov: that seems different from how <a> with a child <b> would normally behave without shadow trees |
| 18:00 | <TabAtkins> | Argh, though, the syntax of coutner-* is *killer*. Space-separated lists ftl. |
| 18:03 | <annevk> | dglazkov: also note that event listeners can set the target to display:none, can remove it from the tree, etc. so offsetX / offsetY will end up weird |
| 18:03 | <annevk> | dglazkov: and what you're suggesting does not seem compatible with how they're computed today for elements that could reasonably have a shadow tree |
| 18:09 | <annevk> | dglazkov: replied on the list |
| 18:56 | <dglazkov> | annevk: me too! :) |
| 19:43 | <Hixie> | annevk: btw, whatwg.org/newbug |
| 19:44 | <Hixie> | bkardell: here now |
| 19:47 | <Hixie> | hsivonen: yt? |
| 19:52 | <bkardell> | Hixie: you agree select/map thing is not without warts/right? |
| 19:57 | <annevk_> | Hixie: cool |
| 19:58 | <Hixie> | bkardell: well it's certainly not as pretty as it would be if we could have the HMTL spec updated to have a true <geomap> element and so not need a component at all, sure |
| 19:58 | <Hixie> | bkardell: and angle brackets are kind of pain |
| 19:58 | <Hixie> | bkardell: but then i'm not a huge fan of HTML as a whole |
| 19:58 | <Hixie> | bkardell: so it's not hard for me to admit that something in HTML has warts :-) |
| 19:59 | <bkardell> | No no... not what I mean |
| 20:00 | <csuwldcat> | new Map(); // which element did that imperitive invocation just resolve to? |
| 20:00 | <bkardell> | Hixie: both plans have a number of good/bad implications... right? |
| 20:00 | <csuwldcat> | if --> <element whitelist="input, textarea"> |
| 20:00 | <csuwldcat> | then |
| 20:01 | <csuwldcat> | new Foo(); gets which one? |
| 20:02 | <bkardell> | I am just curious if we can just agree to a list to benefits and drawbacks for each one |
| 20:02 | <Hixie> | bkardell: all options have good and bad points, but i think <select/map> is the only proposal i'm aware of that has no fatal problems currently. Why, are there problems I should know of that are fatal with <select/map>? |
| 20:02 | <csuwldcat> | do we start throwing parse errors then? |
| 20:02 | <Hixie> | bkardell: i would be very happy to see such an analysis |
| 20:02 | <Hixie> | bkardell: and would be happy to review it and offer suggestions |
| 20:03 | <Hixie> | feel free to use the whatwg wiki if you want |
| 20:03 | <Hixie> | i can create you an account |
| 20:03 | <csuwldcat> | <div/foo> ERROR: invalid application of a slash-hacked attribute to a tag |
| 20:03 | <csuwldcat> | ? |
| 20:04 | <csuwldcat> | do we extend doc.createElement to understand 'div/foo'? |
| 20:04 | <Hixie> | personally i wouldn't, but that's up to dglazkov as far as i'm concerned |
| 20:04 | <csuwldcat> | I figured as much |
| 20:05 | <csuwldcat> | throw YAOAA (Yet Another One-off API Asterisk) on the pile |
| 20:06 | <bkardell> | Hixie: sure... if we want. I mean, I see a lot of drawbacks to / but only one benefit |
| 20:06 | <csuwldcat> | I feel like we're making swiss cheese, not a coherent API |
| 20:07 | <bkardell> | Hixie: i'd like someone to just list pro/con implications so we can agree wtf we are even talking abt |
| 20:07 | <csuwldcat> | ok |
| 20:07 | <csuwldcat> | ***goes to paste |
| 20:07 | <bkardell> | Dispassionately csuwldcat |
| 20:07 | <bkardell> | :) |
| 20:11 | <bkardell> | Hixie: because I think we are on too many levels talking past each other... |
| 20:13 | <csuwldcat> | https://etherpad.mozilla.org/custom-element-pro-con |
| 20:16 | <Hixie> | bkardell: http://wiki.whatwg.org/wiki/Components |
| 20:17 | <Hixie> | ok, csuwldcat did one too |
| 20:17 | Hixie | looks at csuwldcat's |
| 20:17 | <Hixie> | i disagree with most of csuwldcat's cons so far |
| 20:17 | <Hixie> | :-) |
| 20:18 | <csuwldcat> | Hixie: you can disagree all you want, those are the downstream effects |
| 20:18 | <csuwldcat> | please, add your dispute under each one |
| 20:18 | <csuwldcat> | show me how they are invalid |
| 20:18 | <csuwldcat> | Im not even half way done |
| 20:19 | <bkardell> | Sorry guys... phone and accessing irc through it :-/ |
| 20:23 | <annevk> | Can't we go back to use case discussion again? Yesterday quite a few people said they wanted decorators. Most of what web components is now is not decorators... |
| 20:24 | <dglazkov> | annevk: both decorators and custom elements are part of web components. |
| 20:24 | <annevk> | dglazkov: how do decorators work? |
| 20:24 | <annevk> | dglazkov: via CSS? |
| 20:24 | <dglazkov> | annevk: yup |
| 20:25 | <annevk> | dglazkov: where is that defined? |
| 20:25 | <dglazkov> | annevk: http://www.w3.org/TR/components-intro/#decorator-section |
| 20:25 | <annevk> | dglazkov: intro does not sound like a definition |
| 20:25 | <dglazkov> | annevk: I don't know what you mean by "quite a few people", but I am pretty sure most web devs want custom elements. |
| 20:27 | <dglazkov> | annevk: I haven't written the decorators spec yet. |
| 20:27 | <annevk> | e.g. http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases |
| 20:28 | <annevk> | a lot of those are either extending an existing form control or a decorator |
| 20:29 | <annevk> | which kinda argues for the <.../...> design I'd think |
| 20:31 | <Hixie> | yeah, people posted pages of components yesterday that showed exactly that |
| 20:31 | <dglazkov> | the biggest complaint about slash-type is that it's verbose. The best analogy I heard is having to write out base type for every instance in a normal programming language. |
| 20:31 | <Hixie> | wait, what? the slash-type thing is the least verbose it could possibly be |
| 20:31 | <Hixie> | it literally has exactly as few characters as you can use |
| 20:32 | <annevk> | dglazkov: it's not that verbose |
| 20:32 | <hober> | i still prefer <select is=map> to <select/map> |
| 20:32 | <Hixie> | you literally cannot get any less verbose without using gzip or something |
| 20:32 | <dglazkov> | Hixie <x-map> is less verbose in that regard. It has better developer egronomics. |
| 20:33 | <csuwldcat> | dglazkov: that's a #Fact |
| 20:35 | <Hixie> | dglazkov: sure but it doesn't meet the requirements so that's kind of moot |
| 20:35 | <Hixie> | dglazkov: i mean, <map> is even less verbose |
| 20:35 | <Hixie> | dglazkov: as is <> |
| 20:35 | <dglazkov> | looking through backlog and comments, the main objections from Web developers boils down to ergonomics. So.. Standards guys want slash-type, Web devs want custom tags. |
| 20:36 | <Hixie> | i don't _want_ slash-type |
| 20:36 | <Hixie> | i want something that meets the requirements |
| 20:36 | <Hixie> | foo/bar is the only one people have proposed that does |
| 20:36 | <Hixie> | i'm certainly open to other proposals |
| 20:36 | <hober> | whatever the syntax, it needs to convey two pieces of information: the element you're extending, and the component that extends it. <x-map> doesn't do that. |
| 20:37 | <Hixie> | TabAtkins: i love the "lead" vs "mislead" in http://www.w3.org/mid/CAAWBYDCQ-dmUGJpehYsjZLH9RQbc3F-VFd_um=qGBmK0ws181g⊙mgc |
| 20:37 | <Hixie> | TabAtkins: you should take that paragraph and put it in the whatwg faq somewhere :-) |
| 20:38 | <csuwldcat> | Hixie: dglazkov: verbosity is a subconcern |
| 20:39 | <csuwldcat> | the biggest lame-ness here, is that tags are noun identities with specfic protos |
| 20:39 | <csuwldcat> | tags and the HTMLElement constructors they are tied to have always had a strongly tied relationship |
| 20:39 | <Hixie> | yeah ok that etherpad thing has just devolved into namecalling, i'm out |
| 20:39 | <csuwldcat> | we are now obliterating that |
| 20:39 | <csuwldcat> | where |
| 20:39 | <csuwldcat> | ? |
| 20:40 | <TabAtkins> | Hixie: I... had no idea I was making such a great pun/parallel. |
| 20:40 | <TabAtkins> | That's wonderful. |
| 20:42 | <Hixie> | hehe |
| 20:42 | <TabAtkins> | Hixie: If you drop the requirement that "requiring parsers to read linked HTML documents is bad", then the current spec solution hits all the same points that <foo/bar> does, but better. |
| 20:42 | <csuwldcat> | TabAtkins: WORD |
| 20:43 | <Hixie> | TabAtkins: sure, if we require all UAs to implement Web Components. But we can't seriously do that. That's a huge amount of work on one of the most complicated aspects of the web platform. |
| 20:43 | <csuwldcat> | Hixie: cited some micro parser used by 4 guys in a basement in Siberia though |
| 20:43 | <Hixie> | TabAtkins: is even html5lib going to support web components natively? |
| 20:43 | <TabAtkins> | That's an incorrect assertion. |
| 20:43 | <dglazkov> | TabAtkins: I agree. I would like to understand whether 5 and 7 are actually requirements or nice-to-haves |
| 20:44 | <TabAtkins> | The parser required to understand the fallback tag semantics is a tiny tiny subset of Web Components. It's just "use your HTML parser, and look for <element> elements in the linked document." |
| 20:44 | <TabAtkins> | s/."/"./ |
| 20:44 | <csuwldcat> | Hixie: what is HTML5lib? |
| 20:44 | <TabAtkins> | Once you see the <element name="x-bar" extends="foo">, you can parse <x-bar> exactly as easily as <foo/bar>, with the same semantic fallback. |
| 20:45 | <TabAtkins> | csuwldcat: It's the de facto non-browser impl of the HTML parser. |
| 20:45 | <Hixie> | TabAtkins: i don't think that is a reasonable requirement. For example, you might not have network at that point. |
| 20:45 | <TabAtkins> | Written in Python 2/3. |
| 20:45 | <csuwldcat> | ah |
| 20:45 | <csuwldcat> | WHAT? (12:46:02 PM) Hixie: TabAtkins: i don't think that is a reasonable requirement. For example, you might not have network at that point. |
| 20:45 | <csuwldcat> | so you had a network to dl the page |
| 20:45 | <Hixie> | csuwldcat: "Hixie: cited some micro parser used by 4 guys in a basement in Siberia" is the kind of hyperbolic strawman construction that makes me not enjoy discussing this with you, fwiw. |
| 20:45 | <csuwldcat> | but not to get the linked rel? |
| 20:46 | <csuwldcat> | oh gosh, that sounds absurd |
| 20:46 | <sjmiles> | re: div/x-foo and 'verbosity is a subconcern' => not for me. From my perspective verbosity is the primary issue. |
| 20:46 | <csuwldcat> | Hixie: let me rephrase |
| 20:46 | <Hixie> | most of the studies we do of HTML consist of big zipfiles of HTML files where none of the links have been followed, for instance. |
| 20:47 | <csuwldcat> | what do you think the total usage rates of the cases you cite in relation to the lesser known parsers that are not used by any of today's modern browsers? |
| 20:47 | <TabAtkins> | sjmiles: I'm not concerned with relative verbosity either, just intent. Having to restate your inheritance structure with every instantiation seems asinine. :/ |
| 20:47 | <Hixie> | TabAtkins: fwiw, i agree with that |
| 20:47 | <sjmiles> | @tabatkins: yes, precisely ... it's a cost I have to pay over and over |
| 20:47 | <Hixie> | TabAtkins: having said that, we had some interesting cases yesterday that came up where i think this would actually help |
| 20:48 | <TabAtkins> | Hixie: Then are you just biting the bullet? \ |
| 20:48 | <csuwldcat> | TabAtkins: asinine, and asiten, and asieleven |
| 20:48 | <TabAtkins> | Hixie: Sorry, I skipped most of the discussion yesterday. |
| 20:48 | <Hixie> | TabAtkins: for instance, consider a component that wants to add an API for <h1>-<h6> |
| 20:48 | <csuwldcat> | see what I did there ;) |
| 20:48 | <Hixie> | TabAtkins: (some <h1>s to <h6>s, that is) |
| 20:48 | <Hixie> | TabAtkins: do you have to declare 6 components? |
| 20:48 | <csuwldcat> | No Hixie |
| 20:49 | <csuwldcat> | that could be a decorator |
| 20:49 | <Hixie> | not a decorator, it adds an api |
| 20:49 | <TabAtkins> | If you wanted to mimic the same hierarchy, then probably, yeah. |
| 20:49 | <csuwldcat> | h1,h2,h3,h4,h5 { decorator: url(#HixieHeadings); } |
| 20:49 | <TabAtkins> | csuwldcat: API-adding via decorator is in the long future, if ever. |
| 20:49 | <annevk> | csuwldcat: dude, he just said it wasn't a decorator |
| 20:50 | <csuwldcat> | TabAtkins: he just added that after we said it |
| 20:50 | <TabAtkins> | csuwldcat: Yes, but he said it quickly. ^_^ |
| 20:50 | <csuwldcat> | he's tacking on reqs live, this is called moving the goal post |
| 20:50 | <csuwldcat> | haha |
| 20:50 | <csuwldcat> | good point |
| 20:50 | <TabAtkins> | csuwldcat: Dude, don't be like that. This is a fast, casual medium. |
| 20:50 | <Hixie> | i didn't move the goalpost, I said it added an API in the very first line that mentioned it! |
| 20:51 | <Hixie> | jesus |
| 20:51 | <annevk> | TabAtkins: seems weird btw as h1-h6 implement the same interface |
| 20:51 | <TabAtkins> | You can't work here if you require that everyone state their entire argument and all clarifications in a single line. |
| 20:51 | <annevk> | TabAtkins: HTMLHeadingelement |
| 20:51 | <Hixie> | TabAtkins: or alternatively, every phrasing element |
| 20:51 | <TabAtkins> | annevk: <h1-6> are werid, yes. |
| 20:51 | <csuwldcat> | but hixiem you did it to present your corner case specifically geared to achieve your narrative |
| 20:51 | <Hixie> | TabAtkins: or every sectioning element (that one in particular seems quite plausible) |
| 20:51 | <csuwldcat> | how do you not see that? |
| 20:51 | <annevk> | TabAtkins: they're not the only elements with a non-unique interface |
| 20:51 | <sjmiles> | I realize I'm not getting any traction with the verbosity argument, but I expect web-devs are going to find it extremely off-putting (my team does) |
| 20:52 | <TabAtkins> | Hixie: Hm, I see. Yes, there are some plausible cases where you could want to apply the same API across several existing HTML elements. |
| 20:52 | <csuwldcat> | sjmiles: naw, they'll just rock the X |
| 20:52 | <csuwldcat> | <x/hoodwinked> |
| 20:52 | <csuwldcat> | TabAtkins: Hixie: I admit as well, the case is valid |
| 20:53 | <Hixie> | TabAtkins: what we could do is have an in-page macro mechanism, i suppose |
| 20:53 | <sjmiles> | csuwldcat: I refer to the notion that will require the extra tag semantic <div/x-whatever> |
| 20:53 | <csuwldcat> | I would contend that it is fractional and not going to be the norm |
| 20:53 | <TabAtkins> | Hixie: I don't think that overrides in general the argument against restating your base on every element, though. Perhaps argues for a way to address that case specifically. |
| 20:53 | <Hixie> | TabAtkins: so <foo/bar> is the regular syntax, but you can say <define element="bar" extends="foo" with="binding.html"> and then use <bar> |
| 20:53 | <TabAtkins> | Or pursuing something like slash-tag at the same time, as a way to manually override the extends="" attribute. |
| 20:54 | <TabAtkins> | Yeah, that's what I'm thinking. |
| 20:54 | <csuwldcat> | sjmiles: oh, but I think Hixie said the parser addition that will be required by this will add some magic that means when parsed, the name after the slash is not added as an attribute |
| 20:54 | <Hixie> | that would allow us to even drop the x- |
| 20:54 | <bkardell_> | Hixie: question - for tab too |
| 20:54 | <annevk> | that seems even better |
| 20:54 | <dglazkov> | wait wait |
| 20:54 | <TabAtkins> | Hixie: I don't really want to repeat that macro on every page, though - I'd prefer to link it in once. |
| 20:54 | <annevk> | especially if the plan is to express native elements in terms of shadow trees too |
| 20:54 | <dglazkov> | so declare elements in the doc ahead of time? |
| 20:54 | <bkardell_> | sorry guys you should have seen me trying to do this on my phone, it was something to behold |
| 20:54 | <TabAtkins> | dglazkov: Forward declarations! |
| 20:54 | <sjmiles> | look, having to put <div/x-foo> instead of just <x-foo> at a very basic level is off-putting to web devs |
| 20:54 | <dglazkov> | yeah. it has terrible developer ergonomics, too |
| 20:54 | <Hixie> | TabAtkins: well, it has to be in-page because otherwise the parser will just be utterly lost |
| 20:54 | <bkardell_> | if you do the slash thing - a LOT of tools break |
| 20:55 | <annevk> | dglazkov: like import in Python |
| 20:55 | <Hixie> | hsivonen is going to hate this |
| 20:55 | <TabAtkins> | Hixie: Without an in-band signal that it's something special, sure. |
| 20:55 | <csuwldcat> | sjmiles: not just that, it has HUGE downstream consequences |
| 20:55 | <dglazkov> | sjmiles will hate the forward decls |
| 20:55 | <csuwldcat> | with tag names, every API devs use today works |
| 20:55 | <TabAtkins> | (Like the x- prefix.) |
| 20:55 | <csuwldcat> | doc.createElement, querySelector, getElementsByTagName, el.nodeName, etc, |
| 20:55 | <Hixie> | the x- thing is _so_ ugly though |
| 20:55 | <TabAtkins> | It's reallyl not. ^_^ |
| 20:55 | <csuwldcat> | with this method, hixie is tossing all of that |
| 20:55 | <Hixie> | i mean, uglier even than the slash thing |
| 20:55 | <Hixie> | imho |
| 20:56 | <Hixie> | anyway, that's clearly subjective |
| 20:56 | <csuwldcat> | unless we patch that everywhere |
| 20:56 | <sjmiles> | at some point we discussed merely requiring '-' ... since devs will want to id their elts anyway (goog-map, yui-button) this I expect to not be alarming to web devs |
| 20:56 | <bkardell_> | hixie: amen... subjective :) |
| 20:56 | <dglazkov> | csuwldcat was right that if we have to do slash-type, most libraries will simply flow around with <x/foo> |
| 20:56 | <Hixie> | i suppose we could require a prefix, that would get around hsivonen's concerns |
| 20:56 | <csuwldcat> | dglazkov: I will, with x-tag |
| 20:56 | <bkardell_> | dgazkov: and tools will break |
| 20:56 | <bkardell_> | that is one of the things hixie wans tot avoid |
| 20:56 | <dglazkov> | bkardell_: well, that |
| 20:56 | <annevk> | bkardell_: such as? |
| 20:57 | <csuwldcat> | you can stamp a money back guarantee on that |
| 20:57 | <TabAtkins> | Hixie: <x-tag is=h1> ^_^ |
| 20:57 | <hober> | ewwwwh |
| 20:57 | <Hixie> | the other thing is what is the tag name of an extended element -- i guess y'all want it to be the component, but that means it'd be different for legacy UAs and new UAs in the <foo/bar> case |
| 20:57 | <Hixie> | TabAtkins: yeah but that fails 7 |
| 20:57 | <bkardell_> | just go to your syntax highlighters for example or all of these poste things we use online and start playing |
| 20:57 | <TabAtkins> | Where were these numbered reqs? |
| 20:57 | <Hixie> | TabAtkins: people just won't bother with the is="" |
| 20:57 | <csuwldcat> | TabAtkins: oh you are a cunning fellow Tag, nay Ninja like |
| 20:57 | <Hixie> | http://wiki.whatwg.org/wiki/Components |
| 20:57 | <dglazkov> | ... namespaces? |
| 20:57 | <TabAtkins> | Ah, kk. |
| 20:57 | <hober> | the tag name of an element that happes to be bound to a component should be the same as if it weren't bound |
| 20:57 | <TabAtkins> | <x-tag/h1> |
| 20:58 | <bkardell_> | csuwildcat and I accidentally were getting auto-completed closing tags, things that looked like errors or attributes that look like content |
| 20:58 | <TabAtkins> | In legacy browsers, tagname is x-tag, like we want, and h1 is an attribute name. |
| 20:58 | <Hixie> | TabAtkins: <h1/tag> is cleaner than <x-tag/h1> |
| 20:58 | <csuwldcat> | yeah, we also blast a ton of regexps out in the wild |
| 20:58 | <Hixie> | TabAtkins: if we're going there |
| 20:58 | <csuwldcat> | Hixie: can we give everyone your email for the support requests? |
| 20:58 | <TabAtkins> | Hixie: Marginally, yes, due tot he prefix loss, but we want to allow components to rely on their default extends (and thus be slash-less). |
| 20:58 | <csuwldcat> | I mean that's fair right? |
| 20:59 | <bkardell_> | this is what I was saying |
| 20:59 | <bkardell_> | doesn't that violate hixie's #7? |
| 20:59 | <Hixie> | do we have any idea how many components we're expecting per page? |
| 20:59 | <hober> | csuwldcat: everyone already has his email address |
| 20:59 | <Hixie> | bkardell_: not if we do the macro declaration thing |
| 20:59 | <csuwldcat> | haha hober: good point |
| 20:59 | <TabAtkins> | Often, a decent number. sjmiles can probably give a good answer. |
| 21:00 | <Hixie> | like 10? 100? |
| 21:00 | <csuwldcat> | Hixie: in our experience, it all depends on the app |
| 21:00 | <Hixie> | trying to work out if it's just out of the question to declare them ahead of time |
| 21:00 | <sjmiles> | 100s |
| 21:00 | <csuwldcat> | some it was as few as 10 |
| 21:00 | <Hixie> | ok yeah that won't work then |
| 21:00 | <Hixie> | bummer |
| 21:00 | <csuwldcat> | others, that have iterated uses, it was 100s |
| 21:00 | <Hixie> | sjmiles: in one page? |
| 21:00 | <Hixie> | man |
| 21:00 | <sjmiles> | easily |
| 21:00 | <csuwldcat> | x-responsive-img |
| 21:00 | <TabAtkins> | Hixie: I know that, just using jQuery components, I've sometimes written pages with *lots* of things. |
| 21:01 | <TabAtkins> | Counting things that were practically components, just not packaged as such, that number goes up a lot more. |
| 21:01 | <Hixie> | maybe we should just abandon HTML and just have them all use XML... (not joking) |
| 21:01 | <hober> | sjmiles: do you mean 100s of instances of a handful of components, or a handful of instances of 100s of components? |
| 21:01 | <sjmiles> | components support composition, the layering available there allows one to mitigate a complex application structure into numerous small pieces |
| 21:01 | <csuwldcat> | 100s of instances of a handful of components!!! :) |
| 21:01 | <Hixie> | i mean, if there's 100s of these things, there's no way any software is going to make head or tail of it even if they have the fallback elements |
| 21:01 | <sjmiles> | 100s of instances of a much smaller # of components |
| 21:01 | <Hixie> | oh |
| 21:01 | <Hixie> | ok |
| 21:01 | <csuwldcat> | correct |
| 21:02 | <Hixie> | how many component types per page though? |
| 21:02 | <sjmiles> | my perspective is 'web apps' to be clear |
| 21:02 | <Hixie> | sure |
| 21:02 | <csuwldcat> | so maybe 10-20 uniques |
| 21:02 | <sjmiles> | component types is more like dozens |
| 21:02 | <csuwldcat> | with a few at high iteration |
| 21:02 | <sjmiles> | for serious apps |
| 21:02 | <csuwldcat> | yeah |
| 21:02 | <Hixie> | ok that's not so bad then |
| 21:02 | <csuwldcat> | the only kind hehe |
| 21:02 | <dglazkov> | also important, in the cases where 100s of instances are present, the apps are built dynamically and more than likely HTML is only used as the UI configuration medium, not a public document. |
| 21:03 | <Hixie> | we could do something like <script type="parser macro declaration"> foo = <select/foo>; bar = <input/bar> </script> |
| 21:03 | <csuwldcat> | Hixie: in total though, over the whole of an app, across all pages/views, you could have many more |
| 21:03 | <sjmiles> | apologize if I'm repeating, but I'm concerned that rule #5 is more or less like insisting all ice-cream be served with peas on top |
| 21:03 | <dglazkov> | iow, you would load chunks of templates or fragments, and replace them as you work |
| 21:03 | <Hixie> | dglazkov: yeah, in which case you don't even need to define that many macros |
| 21:03 | <csuwldcat> | im just saying there are like 10-20 uniques per view |
| 21:03 | <sjmiles> | ulimately, the ice-cream consumers will go to incredible lengths to build pea-removal machines |
| 21:03 | <csuwldcat> | so the whole app may have 50-60 |
| 21:03 | <dglazkov> | Hixie: what I meant is that in this case requirements 5 and 7 are moot |
| 21:04 | <csuwldcat> | Hixie: think of it like jQuery plugins, some sides include like 50 js files, each a plugin |
| 21:04 | <Hixie> | dglazkov: not entirely, but yes, to a large extent i agree |
| 21:04 | <Hixie> | dglazkov: it's the markup case i'm worried about |
| 21:04 | <dglazkov> | Hixie: I understand. |
| 21:04 | <Hixie> | mostly worried about, anyway |
| 21:04 | <csuwldcat> | I will mourn the loss of doc.createElement for many moons |
| 21:04 | <Hixie> | sjmiles: sure, just like today they use <div>s only |
| 21:04 | <csuwldcat> | and all the other DOM APIs we'll either lose or have to patch |
| 21:05 | <Hixie> | sjmiles: but i don't think that's most people |
| 21:05 | <Hixie> | sjmiles: and it's widely understood to be poor style |
| 21:05 | <csuwldcat> | that is what developers will hunt us for |
| 21:05 | <dglazkov> | Hixie: these two cases are in contradiction then |
| 21:05 | <dglazkov> | I think both csuwldcat and sjmiles are mostly interested in the former and could care less about the latter |
| 21:06 | <csuwldcat> | yup |
| 21:06 | <Hixie> | the former = from script? |
| 21:06 | <csuwldcat> | the markup is low medium, all the downstream is heartbreaking |
| 21:06 | <Hixie> | if so, they sure are arguing forcefully about the latter :-) |
| 21:06 | <dglazkov> | let's call it the "apps" case vs. "document" case. |
| 21:06 | <Hixie> | i disagree with the premise that there's a difference or that apps only use scripts |
| 21:06 | <sjmiles> | this is why I wanted something optional |
| 21:06 | <csuwldcat> | Im not sure I can sell a spec that requires patching every DOM interface that works off of a tag/selector |
| 21:07 | <csuwldcat> | Boris will probably go into a fit of nerd rage |
| 21:07 | <dglazkov> | Hixie: okay let's see |
| 21:07 | <bkardell_> | are we editing a wiki with something new? |
| 21:07 | <TabAtkins> | Hixie: I've added my proposal to the wiki page. Do you agree with my writeup? |
| 21:07 | <dglazkov> | Hixie: in "apps" case, the requirements 5 and 7 are uninteresting, since the app uses markup as purely UI config serialization/deserialization medium |
| 21:07 | <bkardell_> | hixie: that was creepy fast |
| 21:08 | <dglazkov> | Hixie: in "document" case, the requirements 5 and 7 are serious, because the document's semantics are public |
| 21:08 | <sjmiles> | @dglazkov: yes, this is my belief also |
| 21:08 | <csuwldcat> | TabAtkins: dglazkov: I think a hard req for us is that you can use existing DOM APIs to query/create elements |
| 21:08 | <Hixie> | bkardell_: hm? |
| 21:08 | <sjmiles> | that's when I ask for 'optional' |
| 21:08 | <csuwldcat> | document.createElement('div/foo') |
| 21:09 | <sjmiles> | document.createElement *must* work |
| 21:09 | <csuwldcat> | querySelector('div/foo') |
| 21:09 | <bkardell_> | hixie: nm.. i just said 'can we edit the wiki' and a microsecond later you said 'i updated the wiki |
| 21:09 | <Hixie> | TabAtkins: failing any of those requirements imho is a blocker. |
| 21:09 | <csuwldcat> | sjmiles: correct |
| 21:09 | <TabAtkins> | csuwldcat: The only thing you might need to change is createElement, I think. |
| 21:09 | <TabAtkins> | bkardell_: I said that, actually. |
| 21:09 | <csuwldcat> | uhhh |
| 21:09 | <bkardell_> | oh |
| 21:09 | <bkardell_> | hahaha |
| 21:09 | <csuwldcat> | TabAtkins: what about all the others? |
| 21:10 | <TabAtkins> | csuwldcat: The tagname in any case would be the component's name. |
| 21:10 | <csuwldcat> | how do I use querySelector? |
| 21:10 | <Hixie> | TabAtkins: seems right though. It's basically the same as the earlier x-geomap proposal. |
| 21:10 | <csuwldcat> | what? how in the... |
| 21:10 | <csuwldcat> | please explain |
| 21:10 | <Hixie> | dglazkov: i disagree with the premise that apps are written entirely from script |
| 21:10 | <Hixie> | dglazkov: but that doesn't seem to affect the argument |
| 21:10 | <sjmiles> | I would say the premise is that apps are very much less interested in semantic clarity or backward UA compat |
| 21:11 | <csuwldcat> | Hixie, not entirely, but many recent ones are a panel shell with all other creation done in script |
| 21:11 | <Hixie> | bkardell_: i wrote that page today, yes |
| 21:11 | <TabAtkins> | csuwldcat: <x-foo/h1> still creates an <x-foo> element. It just changes the default extension, for the purpose of things that care about it, from whatever <element name=x-foo extends="???"> said, to h1. |
| 21:11 | <Hixie> | bkardell_: when the etherpad was started |
| 21:11 | <dglazkov> | Hixie: I disagree with this premise, too! I did not say anything about them being written entirely from script |
| 21:11 | <sjmiles> | app frequently do not work at all without the proper requirements and trying to push them into that realm is flawed |
| 21:11 | <Hixie> | dglazkov: i don't understand the point you are making then |
| 21:11 | <annevk> | TabAtkins: can't we use another prefix? E.g. "c-" meaning component? |
| 21:11 | <TabAtkins> | Hixie: As a meta-comment, I do find it troublesome to hold apps hostage to documents. I've had to fight against this in CSS land for a long time. |
| 21:12 | <TabAtkins> | annevk: I don't care what the prefix is. |
| 21:12 | <annevk> | TabAtkins: x- is so overused and for something completely different to boot |
| 21:12 | <dglazkov> | Hixie: okay. When you are writing say, an game app. |
| 21:12 | <dglazkov> | you have several screens that appear during the game |
| 21:12 | <dglazkov> | these screens are implemented as <template> instances in your doc |
| 21:12 | <bkardell_> | all... did someone comment on my observation that <select/geomap actually does break things that dont have the exact quirks of today's parsers |
| 21:12 | <dglazkov> | you instantiate them and use them as necessary |
| 21:13 | <csuwldcat> | bkardell_: please elaborate |
| 21:13 | <bkardell_> | I think it is a red-herring that it looks like that proposal meets all reqs |
| 21:13 | <dglazkov> | for anyone but the app, the markup content of these screens is completely uninteresting |
| 21:13 | <csuwldcat> | which browsers, and where? |
| 21:13 | <dglazkov> | crawlers will hate this |
| 21:13 | <dglazkov> | sorry correction |
| 21:13 | <dglazkov> | crawlers will want to ignore this content |
| 21:13 | <Hixie> | bkardell_: they're not quirks of today's browsers, today's browsers all implement the html parser spec which is pretty specific about how to parse this. |
| 21:14 | <dglazkov> | and if they don't, they will produce junk knowledge about this app as a document |
| 21:14 | <bkardell_> | hixie: I'm not sure I see the distinction |
| 21:14 | <sjmiles> | (re: wiki, my position is that <select/geomap> fails requirement 4) |
| 21:14 | <csuwldcat> | just read the wiki |
| 21:14 | <Hixie> | dglazkov: if your thesis is that we don't care about semantics for games, then i disagree |
| 21:14 | <bkardell_> | lots of tools parse html that don't |
| 21:14 | <bkardell_> | and do really well |
| 21:14 | <Hixie> | dglazkov: though i will grant you that many people will be of that opinion |
| 21:14 | <csuwldcat> | <x-geomap> doesn't even fail the reqs by your own definitions |
| 21:14 | <TabAtkins> | Hixie: Arguably, <select/geomap> fails 7, due to our repeated assertions that it's likely to become common to just extend an <x> element. |
| 21:15 | <csuwldcat> | if #7 Needs to encourage authors to put a real semantic rather than just skipping that step. |
| 21:15 | <Hixie> | TabAtkins: by the logic of that assertion, people would just use <x class=""> today, and they don't. They at worst use <div class="">, and that is widely considered poor style. |
| 21:15 | <csuwldcat> | Hixie: you might want to change this to "Needs to strictly force authors to put a real semantic rather than just skipping that step, even when it doesn't apply to their use-case" |
| 21:16 | <csuwldcat> | then I can agree, it certainly would meet #7 |
| 21:16 | <sjmiles> | the reality of web devs, IMHO, is that you can only 'encourage' people by making things that feel good ... if being semantic has tangible benefits devs will do it, if you try to force it, they will revolt |
| 21:16 | <csuwldcat> | Hixie: many devs don't know <x> would be evaluated as Unknow inline element |
| 21:16 | <csuwldcat> | if they did, they might |
| 21:16 | <TabAtkins> | Hixie: It's really not considered poor style - quite a lot of app frameworks do precisely that (ask sjmiles). There's a worrying number that also just straight-up use custom tagnames, without even a prefix to disambiguate. |
| 21:16 | <csuwldcat> | hell, most of our web devs didn't realize that |
| 21:17 | <sjmiles> | people understand the notion of semantic-goodness, but again, without a tangible benefit, the boss yelling at them to meet the deadline is massively more persuasive |
| 21:17 | <bkardell_> | I think maybe wycats_ has some experience there too :) |
| 21:18 | <sjmiles> | all wild generalizations by me are IMO :) |
| 21:18 | <sjmiles> | or, IME (in my experience) |
| 21:18 | <csuwldcat> | dglazkov: Hixie: I have strong objections to the wording of 5 & 7 |
| 21:18 | <csuwldcat> | 5 assumes there are even semantics applicable, a dubious assertion |
| 21:18 | <Hixie> | TabAtkins: it has an entry in wiktionary: http://en.wiktionary.org/wiki/divitis |
| 21:18 | <csuwldcat> | and 7 just askes that it encourges the use of fallback content |
| 21:19 | <csuwldcat> | which all would, through our extensive developer evangelism networks |
| 21:19 | <dglazkov> | this is another good point. Restriction breeds perversion. Designing something that will not be palatable to devs, even if with good intentions (see reqs 5 and 7) will just result in more craziness. |
| 21:19 | <TabAtkins> | Hixie: I'm quite aware of the dislike of the pattern in semantic circles. I'm also aware of the heavy and continuing use of it anyway within app frameworks. |
| 21:20 | <Hixie> | when you have people like zeldman and allsopp who criticise it so much they have coined a term for it, i think it's "considered poor style" |
| 21:20 | <csuwldcat> | Hixie: I can't wait for the next entry after this is released: xitis |
| 21:20 | <Hixie> | TabAtkins: sure, just like layout tables are still widely used |
| 21:20 | <sjmiles> | @dglazkov: yes, thank you for again saying what's in my head, but much more clearly :) |
| 21:20 | <Hixie> | TabAtkins: there's a difference between that and just embracing it and defining it as the best practice in the spec |
| 21:21 | <csuwldcat> | Hixie: if you relent on the link document thing, I think you'll find devs will tie in the semantics anyway |
| 21:21 | <sjmiles> | layout tables used to be necessary to get the work done, what's left now are reverberations of that |
| 21:21 | <csuwldcat> | because it actually benefits them to inherit the correct proto |
| 21:21 | <TabAtkins> | Hixie: You know it's incorrect to say that we're just rubberstamping div-itis. |
| 21:21 | <TabAtkins> | Due to the extends="" attribute. |
| 21:21 | <TabAtkins> | And my proposal for optionally allowing slash-tag as well. |
| 21:22 | <csuwldcat> | TabAtkins: but he is setting up the circular argument that you can't parse that, to the advantage of his narrative |
| 21:22 | <bkardell_> | TabAtkins: where were you when I was trying to make this argument on the bug that re-opened this? |
| 21:22 | <csuwldcat> | Hixie, I don't mean anything against you, but that is the case |
| 21:22 | <TabAtkins> | bkardell_: Ignoring the walls of text. ^_^ |
| 21:22 | <Hixie> | TabAtkins: fair enough |
| 21:23 | <TabAtkins> | Are there any other non-alphanumeric characters allowed in Name productions besides dash and underscore? |
| 21:23 | TabAtkins | is too lazy to look it up. |
| 21:23 | <csuwldcat> | TabAtkins: slash tags as optional, that's another good compromise |
| 21:23 | <csuwldcat> | good thinking! |
| 21:23 | <dglazkov> | I personally like forward defines. I would allow the browser to know which elements are going to be custom in advance. |
| 21:23 | <TabAtkins> | (Though actually, keeping the slash-tag so that the actual tagname parses equivalently in all browsers is probably a good thing.) |
| 21:23 | <bkardell_> | I worry about this slash thing brothers |
| 21:24 | <bkardell_> | have you read my points on it? |
| 21:24 | <bkardell_> | are they all invalid? |
| 21:24 | <dglazkov> | but it's untenable in real life (the case where you have multiple libraries of components, one including another, etc.) |
| 21:24 | <TabAtkins> | bkardell_: Haven't read too much, no. |
| 21:24 | <csuwldcat> | dglazkov: not only that, but how are you going to throw late parse errors? |
| 21:24 | <annevk> | I'd prefer btw if we could come up with something that's prefixless. Per that talk Hixie referenced the other day on G+ it might actually be nice if native elements could be minted. Of course, we'd have to do it in such a way that new HTML elements can still be created somehow... |
| 21:25 | <csuwldcat> | if <input/foo> is invalid, because foo cannot be attached to input, then you have to throw, but you can't do it until the linked compontents file is parsed anyway |
| 21:25 | <TabAtkins> | annevk: As far as I can tell, the only strategy that's ever worked for combining language-defined and author-defined is (1) prefixing the author-defined stuff, or (2) assuming that author-defined stuff won't happen that often anyway, and just stomping on them when you extend the language. |
| 21:25 | <csuwldcat> | beccause you don't know it is invalid yet |
| 21:26 | <csuwldcat> | annevk: in our use of the x- compontent tags, we generally have semeantic content as the payload |
| 21:26 | <annevk> | TabAtkins: I guess otherwise you'd have to tell in advance somehow this is an author-binding... |
| 21:26 | <TabAtkins> | annevk: And be okay with author-bindings stomping language-bindings when the names collide. |
| 21:26 | <annevk> | TabAtkins: right |
| 21:27 | <annevk> | Of course given HTML's silly parser it's not actually tenable |
| 21:27 | <hober> | this is, again, one of the reasons i prefer <select is=map> - there's no stomping of language-bindings and author-bindings :) |
| 21:27 | <sjmiles_> | (still here) |
| 21:27 | <bkardell_> | hober: I don't entirely hate that |
| 21:28 | <csuwldcat> | hober, other than the fact you just infered the prototype inheritance |
| 21:28 | <TabAtkins> | hober: I hate it. ^_^ |
| 21:28 | <bkardell_> | hober: the main drawback is that you have to know the root element |
| 21:28 | <csuwldcat> | and doing so will cause devs to think they can add is="map" to non-selects |
| 21:28 | <TabAtkins> | (For the reasons already stated - it looks mutable, it requires restating the inheritance in every instantiation, etc.) |
| 21:28 | <bkardell_> | personally, I like my proposal better, but.. |
| 21:28 | <csuwldcat> | even if that would cause internal compontent logic to go haywire |
| 21:29 | <TabAtkins> | I'm unsure - does the extension of a tag change the prototype chain of the newly-constructed element, or just some other information accessible to a11y stuff and such? |
| 21:29 | <csuwldcat> | it changes it |
| 21:29 | <bkardell_> | TabAtkins: the mutability thing is only bothersome until you realize that lots of things in html are like that |
| 21:29 | <sjmiles_> | the div/x-foo solution is clever, is there anyway we can default to 'div/'? I realize this poses a moral hazard, but it makes my objections go away |
| 21:29 | <csuwldcat> | emits a new proto |
| 21:29 | <bkardell_> | TabAtkins: you can't change the type of a script tag, for example |
| 21:30 | <bkardell_> | I think people could overcome it if it really gave all the rest of the benefits right |
| 21:30 | <TabAtkins> | sjmiles_: The last proposal on the wiki page now has that - it's the current spec (just <x-tag>, with <element extends=""> defining the extension) + the ability to override the extension with slash-tag: http://wiki.whatwg.org/wiki/Components |
| 21:30 | <TabAtkins> | bkardell_: They're rare, though, and those attributes that act like that are little-used, I think. |
| 21:31 | <TabAtkins> | I mean, @type isn't even a required attribute as long as you're using JS. |
| 21:31 | <bkardell_> | I've talked to several people who quickly changed their mind - that's all I'm saying |
| 21:31 | <sjmiles_> | TabAtkins: ah sorry, missed it, I'm +100 on that :) |
| 21:31 | <bkardell_> | if we dont have to - let's not |
| 21:31 | <bkardell_> | but... it's not as bad as / in my mind |
| 21:31 | <annevk> | you can change type="" of <script> and API-wise that's observable |
| 21:31 | <bkardell_> | TabAtkins: Weigh the pros and cons |
| 21:31 | <annevk> | all HTML attributes are mutable |
| 21:32 | <bkardell_> | but they don't necessarily have an effect - yeah? |
| 21:32 | <bkardell_> | couldnt that be the case here? |
| 21:32 | <annevk> | it's just that not all mutations have side effects beyond normal DOM changes, but most do |
| 21:32 | <bkardell_> | annevk: yeah - I'm not saying anything diff... I said that in the email thread I think |
| 21:33 | <bkardell_> | it has pros that / don't have |
| 21:33 | <annevk> | I saw someone suggesting <input type> was not mutable, but that certainly is, and will change the widget |
| 21:33 | <bkardell_> | really? |
| 21:33 | <TabAtkins> | bkardell_: Definitely. |
| 21:33 | <bkardell_> | I swear I just tried that yesterday |
| 21:33 | TabAtkins | regularly uses that mutability to change type=password to type=text. |
| 21:34 | <bkardell_> | hrm |
| 21:34 | <annevk> | TabAtkins: we should maybe have some kind of API on type=password |
| 21:34 | <TabAtkins> | annevk: For? |
| 21:34 | <annevk> | TabAtkins: or get UAs to implement a checkbox like think to show the password |
| 21:34 | <dglazkov> | attributes are non-starter |
| 21:34 | <TabAtkins> | annevk: Ah, interesting. |
| 21:34 | <csuwldcat> | annevk: no, it won't |
| 21:35 | <TabAtkins> | csuwldcat: What are you contradicting? |
| 21:35 | <dglazkov> | let's get everyone to agree on that. |
| 21:35 | <annevk> | TabAtkins: it's all over the place in OS UI, I'd love to have it in browsers :) |
| 21:35 | <TabAtkins> | annevk: Agreed! |
| 21:35 | <csuwldcat> | the fact you can change the attribute |
| 21:35 | <csuwldcat> | oh misread |
| 21:35 | <csuwldcat> | it was type |
| 21:35 | <TabAtkins> | annevk: Since the right side of inputs seems to be okay to place widgety things, maybe the button can just go there. |
| 21:35 | <csuwldcat> | thought it was a custom element attr |
| 21:35 | <csuwldcat> | dglazkov: agreed |
| 21:36 | <annevk> | yeah |
| 21:36 | <csuwldcat> | dglazkov: slash is going to be a nightmare to polyfill as well |
| 21:36 | <dglazkov> | hober: I highly recommend reading https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669 for a good discussion on that. Sorry it's long :) |
| 21:37 | <csuwldcat> | https://github.com/mozilla/web-components/blob/master/document.register.js |
| 21:37 | <dglazkov> | csuwldcat: I think the key here is to examine requirement 5 and determine if it really is a show-stopper. |
| 21:37 | <dglazkov> | if it is, then we go back to drawing table |
| 21:38 | <bkardell_> | so... for everyone here |
| 21:38 | <dglazkov> | if it isn't then we already have a proper solution with optional slash-type |
| 21:38 | <bkardell_> | does everyone realize that <select/map today parses with map as an attribute? |
| 21:38 | <TabAtkins> | bkardell_: Yes, it's been repeatedly explained. |
| 21:38 | <dglazkov> | ... unless TabAtkins added something new to http://wiki.whatwg.org/wiki/Components in the last secs |
| 21:38 | <dglazkov> | :) |
| 21:38 | <TabAtkins> | dglazkov: I have not. |
| 21:38 | <csuwldcat> | dglazkov: but brian's solution does that |
| 21:39 | <csuwldcat> | not at the tag level, but via fallback contents |
| 21:39 | <dglazkov> | oh. |
| 21:39 | <dglazkov> | why is it not on http://wiki.whatwg.org/wiki/Components? |
| 21:39 | <bkardell_> | TabAtkins: but the same thing without the / would not be a webcomponent |
| 21:39 | dglazkov | pokes bkardell |
| 21:39 | <csuwldcat> | dglazkov: http://paste.mootools.net/f305b18b7 |
| 21:39 | <annevk> | why doesn't extends define an interface name rather than an element name? |
| 21:40 | <annevk> | makes much more sense to extend HTMLHeadingElement than h1 or h2 |
| 21:40 | <csuwldcat> | annevk: huh? |
| 21:40 | <TabAtkins> | bkardell_: Correct, <select> by itself would not be, in that proposal. In my proposal, <x-...> indicates a component, and the slash just indicates an override extension. |
| 21:40 | <annevk> | or HTMLModElement or HTMLQuoteElement |
| 21:40 | <csuwldcat> | annevk: it could just as easily map to that |
| 21:40 | <sjmiles_> | fwiw, my notion of a default semantic type is not actually in the wiki |
| 21:41 | <TabAtkins> | annevk: Would make sense, I suppose. It does mean putting DOM stuff into HTML, which hasn't happened before. |
| 21:41 | <sjmiles_> | the last one is close, but it requires a-priori access to element tag, which is no bueno |
| 21:41 | <csuwldcat> | sjmiles_: unknowns read as spans, right dglazkov? |
| 21:41 | <TabAtkins> | csuwldcat: More or less, yeah. |
| 21:41 | <sjmiles_> | HTMLUnknownElement I suppose (is that crazy?) |
| 21:41 | <bkardell_> | sjimles_ not really |
| 21:42 | <TabAtkins> | annevk: As csuwldcat suggests, having extends="h1" just imply the actual DOM interface rather than the specific tag might work too. |
| 21:42 | <csuwldcat> | so dglazkov, if you look at that example, let's imagine my map, is a canvas map |
| 21:42 | <dglazkov> | wait wait, the last proposal http://wiki.whatwg.org/wiki/Components#Proposal:_.3Cx-geomap.3E_for_the_default_extension_.28specified_in_.3Celement.3E.29.2C_.3Cx-geomap.2Fselect.3E_to_override is not what I expected |
| 21:42 | <csuwldcat> | that blows up this whole argument |
| 21:42 | <TabAtkins> | annevk: That doesn't gain us much, though, as Hixie brings up further examples (all sectioning elements, all phrasing elements) which also make sense, and don't share a reasonable ancestor. |
| 21:42 | <dglazkov> | I thought there was one more proposal about optional fallback, where <x-map> is same as <span/x-map> |
| 21:42 | <annevk> | TabAtkins: at least it makes more sense from a JS perspective |
| 21:43 | <csuwldcat> | TabAtkins: I think that's a separate issue |
| 21:43 | <csuwldcat> | that can be solved with a repurposed is="" on the <element> def |
| 21:43 | <csuwldcat> | correct? |
| 21:44 | <csuwldcat> | so Hixie, TabAtkins, dglazkov, what happens when my MAP element is a canvas map? |
| 21:44 | <csuwldcat> | you still force me to <select/map> ??? |
| 21:44 | <hober> | dglazkov: big surprise; after reviewing that bug thread, i find i'm somewhere between Hixie & hsivonen's positions. :) |
| 21:45 | <dglazkov> | hober: I think you might be lost, then :P |
| 21:45 | <sjmiles_> | rofl |
| 21:45 | <hober> | heh |
| 21:45 | <bkardell_> | hober: where are you? |
| 21:45 | <TabAtkins> | csuwldcat: My proposal (last one in the wiki page) doesn't at all. Your <x-map> declares whatever its default native semantics are, and author can override per-instance if necessary. |
| 21:46 | <hober> | bkardell_: I prefer <select is=map> to <select/map> for several reasons, and prefer <select/map> to anything that involves not saying both "select" and "map" |
| 21:46 | <csuwldcat> | TabAtkins: I like that |
| 21:46 | <csuwldcat> | hober: but attributes are a non-starter for a laundry list of reasons |
| 21:47 | <sjmiles_> | TabAtkins: my understanding is that some of the semantic meaning is intended for web-crawlers (search engines, and so on), so access to the element definitions can't be a requirement |
| 21:47 | <dglazkov> | one is select.setAttribute("is", "fun"); |
| 21:47 | <hober> | csuwldcat: i disagree |
| 21:47 | <csuwldcat> | sjmiles_: not so, google can and does parse all sorts of stuff like that |
| 21:47 | <bkardell_> | hober: can I talk you out of select/map? |
| 21:47 | <bkardell_> | :) |
| 21:47 | <csuwldcat> | talk to Matt Cutts |
| 21:48 | <TabAtkins> | sjmiles_: That's how Hixie states the requirement. More specifically, he feels that guaranteed access to the semantics even when you can't follow links (because you're offline, you've archived the one page, etc.) is required. |
| 21:48 | <hober> | bkardell_: select/map isn't my preferred solution, so yeah, you can! :) |
| 21:48 | <bkardell_> | hober: ok |
| 21:48 | <TabAtkins> | sjmiles_: I am not as hardline. Requiring every page be self-contained seems a non-starter to me, because it means bloat in every page and more work for authors. |
| 21:48 | <csuwldcat> | bkardell_: he likes is="" |
| 21:48 | <sjmiles_> | IMO: anything that requires me as a web dev to define 'x-foo' as a select, and then say 'select' again every time they employ x-foo will make devs batshit |
| 21:48 | <bkardell_> | hober: select is=map isn't my original/preferred, but I could likve |
| 21:48 | <bkardell_> | live* |
| 21:49 | <csuwldcat> | he's one of *those* people...jk hober |
| 21:49 | <TabAtkins> | Also, many apps (what we really care about here) make no sense self-contained anyway - they often *need* the additional resources linked in to work at all. This is in contrast to documents, which can often be reasonably self-contained without great effort. |
| 21:49 | <bkardell_> | it has numerous advantages actually, only 2 downs I can see |
| 21:49 | <bkardell_> | hober: many will likely do <x is="select" |
| 21:49 | <sjmiles_> | TabAtkins: that's tricky, if we really care about 'apps', the necessity of 5 and 7 is greatly reduced IMO |
| 21:49 | <bkardell_> | I think anyway |
| 21:49 | <csuwldcat> | TabAtkins: great distinction and point, this is of primary concern to us at Mozilla |
| 21:49 | <TabAtkins> | sjmiles_: I agree! |
| 21:50 | <TabAtkins> | sjmiles_: I think that documents have little need of Components in the first place. |
| 21:50 | <csuwldcat> | we are trying to make the web a viable apps platform, and the competition is native platforms |
| 21:50 | <TabAtkins> | sjmiles_: Whether or not they end up *using* a lot of components is still up in the air, of course. |
| 21:50 | <hober> | bkardell_: i don't think many people would do that who aren't already doing <x class=map> |
| 21:50 | <csuwldcat> | if the web seems cumbersome and hard to deal with, we lose, we all lose |
| 21:50 | <TabAtkins> | sjmiles_: The hope is that the ugliness of the prefix prevents widespread use of API-free components solely to make "more semantic" names. |
| 21:50 | <bkardell_> | TabAtkins:don't have to ignore them, but lower priority, right? I agree to that |
| 21:51 | <TabAtkins> | While the terseness of the prefix doesn't put off apps that do need API-full components. |
| 21:51 | <hober> | csuwldcat: i don't think that's a universally-held position (that it's native v. web, yadda yadda) |
| 21:51 | <sjmiles_> | TabAtkins: I agree completely ... that's why I start at "terseness trumps" ... but to not completely remove 'documents' as a use case, I want something options |
| 21:51 | <sjmiles_> | optional |
| 21:51 | <csuwldcat> | hober: im in the trenches talking to all sorts of partner app companies daily bro, it is |
| 21:51 | <TabAtkins> | Thus, hopefully, the current language design means that documents use few components, and only really for app-like things, while the meaningful parts use native elements. |
| 21:52 | <TabAtkins> | And for apps, the things that *do* map decently to native semantics will often just use them anyway. |
| 21:52 | <bkardell_> | who put "The "x-" prefix is ugly." |
| 21:52 | <bkardell_> | I call bs |
| 21:52 | <csuwldcat> | Hixie: another unsung benefit: x-tabbox will light a fire under the standardistas to standardize common tags sooner |
| 21:52 | <dglazkov> | another thought: _why_ would a non "app" use web components? what would be the motivation? |
| 21:52 | <TabAtkins> | The optional slash-tag thing is actually useful there - I find that I agree with Hixie quite a bit in that if you have a component for phrasing-level elements, it'll probably apply for *all* of them. |
| 21:53 | <csuwldcat> | with the hapless marass of is="", we can go about coining useless document tags that do nothing interesting and simply carry on as usual |
| 21:53 | <TabAtkins> | Writing <x-foo/i> and <x-foo/b> instead of <x-foo-i> and <x-foo-b> (and having to double/triple/more up your <element> definitions) seems just fine. |
| 21:53 | <dglazkov> | the whole point of custom elements is to enable instantiate an object tree given markup |
| 21:53 | <TabAtkins> | And means that the sematnics are self-contained. |
| 21:53 | <dglazkov> | if you never use the object tree, what good will <x-foo> be? |
| 21:53 | <sjmiles_> | yes, I've been trying to make these distinctions for a while now: app vs document, semantic HTML vs. application HTML, machine vs human semantics, and fallback vs semantic hinting ... seems like these are all conflated in this discussion |
| 21:55 | <bkardell_> | sjmiles_: it's a hard line to draw though |
| 21:55 | <sjmiles_> | for people that see a component for x-fancy-input, there is an obvious problem that it obscures the 'input-ness' |
| 21:55 | <bkardell_> | when does the small thing become big |
| 21:55 | <hober> | dglazkov: "non-app" web pages often sprinkle widgety-things here and there; i assume we'd like such things to be built with components |
| 21:56 | <annevk> | bkardell_: it is ugly |
| 21:56 | <sjmiles_> | I would argue it's intent not size |
| 21:56 | <bkardell_> | or when does it become "red" |
| 21:56 | <csuwldcat> | can I get at least an admittance from the is="" foo/bar crowd, that the way fallback is done today in things like object could easily work here |
| 21:56 | <sjmiles_> | when I make x-report-generator, I much less concerned with losing some obvious native semantic |
| 21:56 | <TabAtkins> | hober: Yes, it's the "here and there" thing that I find important - most of the content *probably* won't be components. |
| 21:56 | <csuwldcat> | and that the only difference is that someone wants this to be forced on people from the top tag down |
| 21:56 | <hober> | TabAtkins: sure. |
| 21:56 | <bkardell_> | annevk: That's not taste? |
| 21:57 | <TabAtkins> | csuwldcat: Where you nest the fallback into the element? I don't admit that it could "easily work" here. |
| 21:57 | <dglazkov> | hober: ... and today, this is already <script> document.write ... chunk, not anything semantic |
| 21:57 | <TabAtkins> | csuwldcat: Becauset he contents of a component are part of its API. |
| 21:57 | <csuwldcat> | TabAtkins: do tell? |
| 21:57 | <bkardell_> | annevk: please pick a better word so I can understand, or we should remove it from the wiki :) |
| 21:57 | <sjmiles_> | for 'sprinkles' and highly seamantice overrides, we surely need some semantic hinting and perhaps fallback behavior |
| 21:57 | <csuwldcat> | not if we include a fallback attribute |
| 21:57 | <hober> | dglazkov: yeah, if we do this right we can improve on the status quo |
| 21:57 | <bkardell_> | annevk: need facts, not opinions |
| 21:57 | <sjmiles_> | for giant apps that never will work in ancient browser, or without JS, and so on, the semantic hinting is burdensome |
| 21:57 | <csuwldcat> | TabAtkins: dglazkov: that would specifically tell the WC code not to use it |
| 21:57 | <bkardell_> | annevk: too much of this is opinion already :) |
| 21:57 | <sjmiles_> | IMO neither use case is invalid, so we need an OPTION |
| 21:57 | <TabAtkins> | annevk: You'll have a hard time arguing that "x-" is particularly uglier than "div/". ^_^ |
| 21:58 | <dglazkov> | hober: yup. This is why we shouldn't have nasty hacks like magic attributes that never change. |
| 21:58 | <TabAtkins> | csuwldcat: Possible, sure, but ugly in its own way, imo. |
| 21:58 | <hober> | dglazkov: this is why we shouldn't have nasty hacks like sending custom element names over the wire :) |
| 21:58 | <csuwldcat> | TabAtkins: in use today |
| 21:58 | <csuwldcat> | no developer ramp time |
| 21:59 | <csuwldcat> | easy to understand and completely opt-in, maintaining the optimal interface we know is better |
| 21:59 | <TabAtkins> | csuwldcat: I don't think "fallback as child element" is in use today for component-type things. Only native elements that already have it built in. |
| 21:59 | <csuwldcat> | <object> |
| 21:59 | <hober> | dglazkov: <aside is=adsense> :) |
| 21:59 | <csuwldcat> | sure |
| 21:59 | <csuwldcat> | same-ish |
| 21:59 | <TabAtkins> | csuwldcat: Another bad part of it is expressed on the wiki, too - if you don't really need to express fallback, just what it descends from, then it's just a silly talisman. |
| 21:59 | <dglazkov> | hober: it's a nice idea. but it's an ugly hack: aside.setAttribute("is", "notAdsense"); // still adsense |
| 22:00 | <csuwldcat> | TabAtkins: correct, as it will be for the majority of use-cases |
| 22:00 | <dglazkov> | hober: custom element names, even select/map is better than that -- at least you're call things what they are |
| 22:00 | <annevk> | dglazkov: seems kinda similar to <script src> to me |
| 22:00 | <hober> | but then you totally break parity between html and xhtml |
| 22:00 | <annevk> | dglazkov: that's not too ugly |
| 22:01 | <csuwldcat> | we are letting one concern, that is still addressed via other proposals, dominate the API and the use-cases, when itself is not a majority use-case |
| 22:01 | <csuwldcat> | that is Unintuitive, Horse-Cart API Design 101 |
| 22:01 | <sjmiles_> | IMO, if HTML5 is ever going to battle native apps (particularly on mobile) we need to at least allow for streamlined syntax ... if you don't, devs will simply build something like it anyway, in Babel-Tower fashion |
| 22:01 | <csuwldcat> | Cart-Horse, rather ;) |
| 22:01 | <dglazkov> | annevk: well, it's no kinda like src. script.setAttribute("src") will still change the value |
| 22:02 | <dglazkov> | the whole element becomes numb. |
| 22:02 | <bkardell> | Annvk: script src, yes...I keep saying |
| 22:03 | <bkardell> | Gglazkov: I could live with that...easily learnable |
| 22:03 | <csuwldcat> | bkardell: but given there is only one use of script on the net today on 99.9% of sites, the argument is laced with obscurity and irrelevance |
| 22:04 | <sjmiles_> | csuwldcat: hrm? that doesn't sound right |
| 22:04 | <annevk> | dglazkov: did anyone seriously suggest changing setAttribute() semantics? doubt it |
| 22:04 | <bkardell> | Csuwldcat: disagree. |
| 22:04 | <csuwldcat> | bkardell: could you live with people adding is="" to elements that do nothing or throws errors, unless you meticulously inspect a linked document? |
| 22:04 | <sjmiles_> | most sites have 9,000 scripts for +1 buttons and ad-servers and all kinds of gunk |
| 22:04 | <hober> | annevk: indeed; i'm not suggesting that we should go anywhere near messing with setAttribute |
| 22:05 | <bkardell> | Csuwldcat: yes...if it is the best equibrium we can find |
| 22:05 | <csuwldcat> | but can we think for a second about the word equilibrium? |
| 22:05 | <bkardell_> | csuwldcat: I can conceed that hixie and annevk and all have a kind of a point there |
| 22:06 | <bkardell_> | csuwldcat: I think it is all about prioritizing the "requirements" |
| 22:06 | <csuwldcat> | bkardell: I 100% agree |
| 22:07 | <csuwldcat> | and I would like to do it according to occurrence, relevance/use-case/total use-cases |
| 22:07 | <bkardell_> | csuwldcat: I dont know for sure if I think they all are the same value, but if we weigh them out and find select is= yields the best equilbrium... I could learn to cope |
| 22:08 | <csuwldcat> | Can Hixie agree to rewrite the polyfill |
| 22:08 | <csuwldcat> | I think it would be a great exercise for him to get in touch with the pain points |
| 22:08 | <bkardell_> | csuwldcat: if you can get an honest fact pro/con of the implications then we can take up prioritization discussion |
| 22:09 | <csuwldcat> | Can anyone here just write a few of these? and them make their case? |
| 22:09 | <dglazkov> | The problem with developer ergonmics of "is" attribute become quite obvious once you have an app with 100s of components. |
| 22:09 | <csuwldcat> | I'm curious to see a show of hands as to who has A) read the full spec B) tried to polyfill is="" C) written components with it |
| 22:09 | <sjmiles_> | all 3 |
| 22:10 | <sjmiles_> | and years prior making custom component solutions |
| 22:10 | <csuwldcat> | My spidy sense is telling me that the semanticists haven't |
| 22:10 | <TabAtkins> | I suspect the raised hands are two - you, and sjmiles_. |
| 22:10 | <csuwldcat> | just got a feeling about it |
| 22:10 | <sjmiles_> | lol :) |
| 22:10 | <dglazkov> | heey, I have 3 too |
| 22:10 | <sjmiles_> | so, I see both sides |
| 22:10 | <sjmiles_> | the problem I have is the requirement to FORCE semantics |
| 22:11 | <sjmiles_> | seems to me that's really important to Hixie |
| 22:11 | <sjmiles_> | and is ultimately where we keep getting stuck |
| 22:11 | <csuwldcat> | opining from an armchair, and telling of the truth from the trenches after putting some skin in the game are two very different things |
| 22:11 | <sjmiles_> | well yes, but the 'armchair' is just actually a different set of gnarly blood-filled trenches |
| 22:11 | <sjmiles_> | don't forget :) |
| 22:11 | <csuwldcat> | sjmiles_: that is squarely the issue, yes |
| 22:12 | <csuwldcat> | forced vs elected |
| 22:12 | <csuwldcat> | neither of the competing proposals fail to address the issue, there is only the difference between forced and elected |
| 22:13 | <dglazkov> | hober: btw, <aside><x-adsense> is probably better semantically anyway. |
| 22:13 | <dglazkov> | but I digress |
| 22:13 | <csuwldcat> | sjmiles_: Im not going to lie to people in the docs we write at mozilla, we're going to be very upfront about why the majority of the time they are playing in a mud pit |
| 22:14 | <bkardell_> | I have edited the wiki - feel free to yell at me |
| 22:14 | <csuwldcat> | if we go Vader on this, someone please own it, wear the mantle |
| 22:14 | <dglazkov> | TabAtkins: I want to propose a slight alteration of your proposal |
| 22:15 | <dglazkov> | TabAtkins: not "override", but "indicate". |
| 22:15 | <sjmiles_> | csuwldcat: we're not done yet, don't go nuclear too soon |
| 22:16 | <dglazkov> | you can't override <x-qux/h1> if x-quz is an HTMLDivElement. Thus, the slash-tag becomes the optional indicator of base semantic element |
| 22:16 | <TabAtkins> | dglazkov: Same diff. You're ignoring the one specified in <element>. |
| 22:16 | <TabAtkins> | dglazkov: Oh, no, I was supposing that you *could* do exactly that. |
| 22:16 | <dglazkov> | okay. Can you add this to wikeee |
| 22:16 | <TabAtkins> | So, for example, a phrasing element component could default-extend <span>, but then you could do /b, /i, /u, whatever. |
| 22:16 | <csuwldcat> | dglazkov: good point |
| 22:16 | <TabAtkins> | /em |
| 22:17 | <dglazkov> | I just want this to be an option for specifying base semantics. |
| 22:17 | <TabAtkins> | dglazkov: What needs to be added? What I just said is exactly what the wiki indicates. ^_^ |
| 22:17 | <TabAtkins> | dglazkov: If you don't specify any base in <element>, I assume it extends <div> or somesuch. |
| 22:17 | <csuwldcat> | TabAtkins: the word override has proto smashing implications |
| 22:17 | <bkardell_> | tabatkins: but not what the wiki overrides |
| 22:17 | <csuwldcat> | he wants you to scope it tighter |
| 22:17 | <bkardell_> | :-p |
| 22:18 | <bkardell_> | indicates/overrides... see what I did there |
| 22:18 | <TabAtkins> | csuwldcat: It should indeed proto-smash. If the element you're extending shows up in your proto, then doing /em should make HTMLEmElement show up in your proto chain. |
| 22:18 | <bkardell_> | tabatkins: but only if it is more specific? |
| 22:18 | <dglazkov> | TabAtkins: what if the custom element expects a certain proto (like methods, props)? |
| 22:19 | <TabAtkins> | bkardell_: No need to care about that. (Anyway, I think the HTML*Element set are all leaf nodes.) |
| 22:19 | <TabAtkins> | dglazkov: Then you break at runtime, presumably. |
| 22:19 | <dglazkov> | TabAtkins: that seems bad? |
| 22:19 | <TabAtkins> | Don't do bad things? |
| 22:19 | <sjmiles_> | seems like you suys are into something else now |
| 22:19 | <sjmiles_> | I cant say "an input is now an img' |
| 22:19 | <sjmiles_> | why would I do that with custom elements? |
| 22:19 | <csuwldcat> | TabAtkins: can't do that |
| 22:20 | <TabAtkins> | sjmiles_: native elements don't extend each other. Components can. |
| 22:20 | <sjmiles_> | I mean, I see there are interesting possibilities there, but adding new abilities seems a bad idea at this point |
| 22:20 | <sjmiles_> | yes, even more to the point |
| 22:20 | <sjmiles_> | if I extend x-bar from x-foo, I can't then say "shove x-zot" prototype on it |
| 22:20 | <TabAtkins> | Where do you get the information about what element you're extending if not from the proto chain? |
| 22:20 | <csuwldcat> | what if the original proto and the props/methods it offered were materially relied upon in the component logic? |
| 22:20 | <TabAtkins> | sjmiles_: You certainly can. Just fiddle with __proto__. |
| 22:20 | <TabAtkins> | csuwldcat: Then it breaks. Again, don't do stupid things. |
| 22:21 | <csuwldcat> | you smash that, it literally could be a monkey wrench in the gears |
| 22:21 | <sjmiles_> | yes, it utterly breaks |
| 22:21 | <sjmiles_> | it's nonesensical |
| 22:21 | <sjmiles_> | but with proper spelling |
| 22:21 | <TabAtkins> | For the situations we've talked about (component for all headings, all phrasing elements, all sectioning elements), it doesn't break. |
| 22:21 | <csuwldcat> | TabAtkins: the funny thing is, you don't know you're "doing stupid things" |
| 22:21 | <dglazkov> | TabAtkins: that's a total foot gun |
| 22:21 | <TabAtkins> | (Because the prototypes don't actually offer much of anything.) |
| 22:21 | <sjmiles_> | yes, this is what I'm calling 'new interesting possibilities', which IMO is a mistake to add on |
| 22:21 | <csuwldcat> | sure, now let's get real about how developers will actually try to use these things |
| 22:22 | <csuwldcat> | it will be a field of landmies |
| 22:22 | <sjmiles_> | most of what I'm doing is entirely dependent on a deterministic proto chain |
| 22:22 | <csuwldcat> | mines |
| 22:22 | <TabAtkins> | In Javascript you cna already do things like constructor.call(anotherObject). |
| 22:22 | <csuwldcat> | you just traded a handknife for a footgun |
| 22:22 | <sjmiles_> | yes, but if you just randomly do that, nothing will work |
| 22:22 | <csuwldcat> | yeah |
| 22:22 | <bkardell_> | tabatkins: but you have to at least know significant details of js and dom to do it |
| 22:22 | <TabAtkins> | sjmiles_: What are you doing that depends on a constant prototype chain? |
| 22:22 | <csuwldcat> | I just relied on the input's documentURI prop |
| 22:23 | <csuwldcat> | oops, they just smashed it with /button |
| 22:23 | <bkardell_> | tabatkins: declarative is a little bigger space of people right? |
| 22:23 | <csuwldcat> | no more documentURI |
| 22:23 | <csuwldcat> | but shucks, they *looked* just like two buttons |
| 22:23 | <sjmiles_> | TabAtkins: when I inherit Bar from Foo, Bar expects to use Foo's prototypical implementation |
| 22:23 | <sjmiles_> | TabAtkins: if it's not there, Bar will not work |
| 22:23 | <csuwldcat> | devs will make phenotypical judgements on interop |
| 22:24 | <TabAtkins> | sjmiles_: Only some elements have non-trivial prototypes. The examples so-far-given where you want to be able to extend multiple elements identically all ahve trivial prototypes. |
| 22:24 | <astearns> | dglazkov: are you thinking of removing the optional indication of base semantics in <element> in favor of an optional indication in <x-component/base>? |
| 22:24 | <sjmiles_> | TabAtkins: I'm confused about this dicussion. In general, although you can call "Boat" constructor on a "Car" object, it doesn't mean it will float. :) |
| 22:24 | <csuwldcat> | to think that they are going to scan a hundred(s) lines long component definition for any use of a proto prop not to smash is a fairytale |
| 22:25 | <TabAtkins> | csuwldcat: No, I expect that authors usually won't use /foo at all. When they can do so, hopefully it's documented. |
| 22:25 | <dglazkov> | astearns: all of these are proposals here: http://wiki.whatwg.org/wiki/Components |
| 22:25 | <csuwldcat> | sjmiles_: oh I like that |
| 22:25 | <TabAtkins> | The cases being handled by the override thing are those that I think are minority in the first place, but still interesting enough to be worth addressing. |
| 22:25 | <csuwldcat> | TabAtkins: Hope and Change hasn't worked out hardly as well as advertised in the past... |
| 22:25 | <sjmiles_> | Ok, I suspect I missed some key bit here and am arguing Quixotically |
| 22:26 | <csuwldcat> | sjmiles_: no, you're right on |
| 22:26 | <csuwldcat> | __proto__ setting will infact xfer props, but they will explode if you try to use them |
| 22:26 | <csuwldcat> | thus your Car/Boat thing was apropreate |
| 22:26 | <TabAtkins> | sjmiles_: The arguments I've heard so far for per-element base indication is, say, wanting a common API on all phrasing elements (<a>, <b>, <i>, <em>, <strong>, etc.). In the current spec, you'd need to do this by defining a bunch of identical components. |
| 22:27 | <csuwldcat> | btw, I suck at spelling, ftr |
| 22:27 | <astearns> | dglazkov: right - I read into what you were saying above as option 6 *without* the default extension specified in <element> - removing the extends attribute of <element> |
| 22:27 | <TabAtkins> | My optional /foo thing lets you address this in a more natural way, by defining the component once and then saying which element it's extending per use (with a default extension still available). |
| 22:28 | <csuwldcat> | TabAtkins: will the rule of the day be defensive self-inspection code inside components? |
| 22:28 | <TabAtkins> | It seems obviously silly to do something like <x-drawing-surface/select>, though. |
| 22:28 | <TabAtkins> | csuwldcat: Why do you assume that "oh shit, the page doesn't work, maybe it's because I did something stupid by adding this extra /foo stuff" is insufficient? |
| 22:28 | <dglazkov> | astearns: no, not that :) |
| 22:28 | <csuwldcat> | <x-drawing-surface><select fallback></select></x-drawing-surface> |
| 22:28 | <TabAtkins> | (Alternately, we could define a set of pre-existing categories that you can extend from, which limits you. |
| 22:29 | <csuwldcat> | TabAtkins: I like that better |
| 22:29 | <sjmiles_> | TabAtkins: if I make 'x-sjmiles-cool' can I write <x-sjmiles-cool> in my html? that's what I want. |
| 22:29 | <dglazkov> | TabAtkins: I think the list is simply all tag names that have this prototype |
| 22:29 | <TabAtkins> | For example, saying <element name=x-foo extends=span category=phrasing> allows <x-foo/b>, but throws an error somewhere if you do <x-foo/input>. |
| 22:29 | <sjmiles_> | alternatives, options, and extensions are all fine by me |
| 22:29 | <csuwldcat> | especially if we're already throwing out the canard requirement that you have to have it operate without the linked doc |
| 22:30 | <TabAtkins> | dglazkov: Most tags are direct children of HTMLElement, though, so that's not a useful categorization scheme. |
| 22:30 | <dglazkov> | the use case where it's necessary is h1..h6 and what else? |
| 22:30 | <TabAtkins> | sjmiles_: Yes, once again, I've always been for that. My proposal is the last entry in the wiki page, like I said before. |
| 22:30 | <TabAtkins> | dglazkov: Heading elements, phrasing elements, sectioning elements, maybe others? |
| 22:30 | <csuwldcat> | dglazkov: ol, ul |
| 22:30 | <annevk> | dglazkov: quote/blockquote ins/del share the interface too |
| 22:31 | <TabAtkins> | Ah yeah, lists make sense. |
| 22:31 | <dglazkov> | aha, all these guys. |
| 22:31 | <csuwldcat> | so, just to be clear |
| 22:31 | <annevk> | dglazkov: prolly a few others |
| 22:31 | <csuwldcat> | this is a need |
| 22:31 | <sjmiles_> | TabAtkins: great, but there is not general agreement on that core point. Once there is, I can go away. :) |
| 22:31 | <csuwldcat> | but not a proto need |
| 22:31 | <dglazkov> | csuwldcat: prototype never changes, correct. |
| 22:31 | <csuwldcat> | hmm |
| 22:31 | <csuwldcat> | well that's not exactely right |
| 22:31 | <dglazkov> | at least in my head :) |
| 22:31 | <TabAtkins> | sjmiles_: You dont' have to argue with me on that point, at least. |
| 22:32 | <csuwldcat> | let's imagine for a sec that some day in the future, we add some thing that only works on a ol |
| 22:32 | <csuwldcat> | some kind of sort or something |
| 22:32 | <TabAtkins> | dglazkov: It seems weird if <x-coolspan/b> has HTMLSpanElement in its prototype, rather than HTMLBoldElement. |
| 22:32 | <csuwldcat> | and then we have the need to be strictly bound |
| 22:32 | <dglazkov> | <element extends="ol" name="x-gar">.. </element> usage: <x-gar/ul> or <x-gar/ol> |
| 22:32 | <TabAtkins> | (Actually, <b> doesn't even ahve an interface of its own.) |
| 22:33 | <csuwldcat> | dglazkov: true enough |
| 22:33 | <TabAtkins> | dglazkov: Now, how do you establish such a restriction, such that <x-gar/input> is not allowed? |
| 22:33 | <TabAtkins> | (Also, what does "not allowed" mean?) |
| 22:33 | <csuwldcat> | TabAtkins: how could you? |
| 22:34 | <TabAtkins> | csuwldcat: I don't understand the question. State it more explicitly? |
| 22:34 | <dglazkov> | look at slash-tag, and look at tag, if their base prototype is different, then throw away slash-tag |
| 22:34 | <TabAtkins> | dglazkov: Once again, that doesn't work. <ol> and <ul> have different prototypes. |
| 22:34 | <csuwldcat> | How could you other than an inferred blacklist based off the diff between an explicit whitelist? |
| 22:35 | <dglazkov> | TabAtkins: ah, then my example is wrong |
| 22:35 | <TabAtkins> | *Some* categories of elements have a nice prototype relationship. Definitely not all. |
| 22:35 | <TabAtkins> | For example, a lot of phrasing element just use HTMLElement directly - they don't even ahve their own unique interface. |
| 22:36 | <csuwldcat> | Where is the line between this whole debate and role="" (hopefully that isn't a stupid question - ducks) |
| 22:36 | <dglazkov> | <element name="x-fart"> (extends HTMLElement) usage: <x-fart/b> or any html tag that uses HTMLElement directly |
| 22:36 | <dglazkov> | <element name="x-burp" extends="HTMLHeadingElement"> usage <x-burp/h1>, <x-burp/h2>, etc. |
| 22:37 | <dglazkov> | whoa, me wrong |
| 22:37 | <TabAtkins> | dglazkov: Now you can't use <x-foo/time>? |
| 22:37 | <dglazkov> | <element name="x-burp" extends="h1"> |
| 22:37 | <TabAtkins> | (Dude, please use standard metasyntactic variables. It's annoying typing fart and burp.) |
| 22:37 | <dglazkov> | sorry :) |
| 22:38 | <csuwldcat> | TabAtkins: buzzkill! |
| 22:38 | <TabAtkins> | Note that <time> is, for most intents and purposes, a standard phrasing element. The only difference is that it additionally has a .datetime property. |
| 22:38 | <csuwldcat> | :) |
| 22:38 | <TabAtkins> | But your test (compare prototype grandparents) would fail it. |
| 22:38 | <dglazkov> | <element name="x-zoot" extends="time"> can only be <x-zoot> and <x-zoot/time> |
| 22:38 | <dglazkov> | TabAtkins: yup. |
| 22:38 | <dglazkov> | we're not decorating here. |
| 22:38 | <csuwldcat> | dglazkov: yes that makes sense |
| 22:39 | <csuwldcat> | because if we're dling the linked doc |
| 22:39 | <dglazkov> | all types are deterministic. The optional notation is only to: |
| 22:39 | <csuwldcat> | we know they are always time |
| 22:39 | <TabAtkins> | dglazkov: I'm not decorating either. I'm just saying that the difference between <b> and <time> isn't large enought to justify forever barring them from being used with the same component. |
| 22:39 | <csuwldcat> | and why would anyone masquerade one truly accurate semantic as another? |
| 22:39 | <csuwldcat> | other than the Heading case.... |
| 22:39 | <dglazkov> | a) disambiguate tags have the same prototype |
| 22:39 | <dglazkov> | b) allow painting semantics on custom tags |
| 22:40 | <TabAtkins> | dglazkov: You didn't answer my objection. |
| 22:40 | <dglazkov> | TabAtkins: because it stomps on proto and makes a foot gun. Take time element for example |
| 22:41 | <TabAtkins> | The difference between <time> and <b>, or <data> and <b>, or perhaps others, isn't large enough to justify forever barring them from using the same component API. |
| 22:41 | <dglazkov> | suppose the component only uses datetime property on some condition (hover at a certain time) |
| 22:41 | <dglazkov> | the awesome author Bob takes this component (let's call it x-roo) and sticks it on a b |
| 22:41 | <dglazkov> | <x-roo/b> |
| 22:41 | <dglazkov> | everything looks great |
| 22:41 | <dglazkov> | then Bob ships the site |
| 22:41 | <TabAtkins> | It means that I must write two identical components, the only difference being that one is defined with <element name=x-foo extends=span> and the other is <element name=x-foo-data extends=data>. |
| 22:41 | <dglazkov> | and it breaks 3 hours later |
| 22:42 | <dglazkov> | it's a foot gun |
| 22:42 | <dglazkov> | TabAtkins: sure. that's how you should do it. |
| 22:42 | <TabAtkins> | dglazkov: You're misreading me. If we're talking categories, and we care about possibly different protos, then I'm saying that *your categories are insufficient*, not *fuck categories, let people do whatever*. |
| 22:42 | <csuwldcat> | I agree with the footgun eventuality, it will happen, and there will be blood (cinema reference...nvm) |
| 22:43 | <TabAtkins> | For example, something like <element category=phrasing> could be used with /b and /time. |
| 22:43 | <dglazkov> | ohhh |
| 22:43 | <dglazkov> | I see |
| 22:43 | <dglazkov> | so the author of the component would have to build it knowingly for a category of elements |
| 22:43 | <csuwldcat> | TabAtkins: this is what I was saying earlier |
| 22:43 | <csuwldcat> | (2:35:31 PM) csuwldcat: How could you other than an inferred blacklist based off the diff between an explicit whitelist? |
| 22:44 | <csuwldcat> | category == that whitelist |
| 22:44 | <dglazkov> | TabAtkins: but if Bob the author attempts to use a component that was not built for a specific category, the browser says no. |
| 22:44 | <dglazkov> | right? |
| 22:44 | <TabAtkins> | csuwldcat: Since I had explicitly already introduced that as an option before you said that line, I was confused what you were trying to say. ^_^ |
| 22:44 | <TabAtkins> | dglazkov: What does "the browser says no" mean? |
| 22:45 | <csuwldcat> | TabAtkins: fair -nough |
| 22:45 | <dglazkov> | throw error, ignore, whatevs |
| 22:45 | <dglazkov> | TBD |
| 22:45 | <csuwldcat> | dglazkov: but what does it do in the meantime? |
| 22:45 | <csuwldcat> | and what does it do once it errors? |
| 22:46 | <csuwldcat> | disapear the element from render or just leave it with the error thrown? |
| 22:46 | <dglazkov> | since the override is secondary, I think we could just ignore it |
| 22:46 | <TabAtkins> | Ignoring the override is an acceptable answer to me. |
| 22:46 | <csuwldcat> | ok |
| 22:46 | <csuwldcat> | that makes sense |
| 22:46 | <TabAtkins> | This requires that we predefine some categories. |
| 22:46 | <dglazkov> | so if Bob does <x-zoo/input> and x-zoo has category="phrasing", it just defaults to <x-zoo> |
| 22:47 | <dglazkov> | TabAtkins: yay work! |
| 22:47 | <TabAtkins> | It also means we should consider whether this is actually worth this effort. |
| 22:47 | <sjmiles_> | TabAtkins: ^ this |
| 22:47 | <dglazkov> | TabAtkins: also, this can be done later. |
| 22:47 | <dglazkov> | TabAtkins: new feature |
| 22:47 | <csuwldcat> | TabAtkins: ^ yep +1 |
| 22:47 | <sjmiles_> | you are the heavy hitters, resolve [Bug 18669] first please |
| 22:48 | <dglazkov> | we can start with just making slash-tag an option to paint semantics |
| 22:48 | <csuwldcat> | I'd want to take a long hard look at the % of real use-cases we expect, and how much more it adds that can confuse |
| 22:48 | sjmiles_ | is stuck in a rut |
| 22:48 | <dglazkov> | sorry, sjmiles_ |
| 22:49 | <dglazkov> | look another TAG member! |
| 22:49 | <csuwldcat> | sjmiles_: Call a x-towtruck/winch...but only if the towtruck is compatible, no worries, you'll find out async after the two truck driver already arrives ;) |
| 22:49 | dglazkov | is easily distracted |
| 22:49 | <sjmiles_> | csuwldcat: TabAtkins is particularly good at making things like that actually work, so dont' take it off the table! |
| 22:50 | <dglazkov> | we have people at various stages of acceptance. This is consensus-driven, so we need have them all |
| 22:50 | <csuwldcat> | haha, ok, agreed |
| 22:50 | <csuwldcat> | wellllll |
| 22:50 | <dglazkov> | 1) Hixie I think is the closest to the finish line |
| 22:50 | <sjmiles_> | we beat some of the stakeholders into silence (but not submission) |
| 22:51 | <dglazkov> | 2) annevk is unknown |
| 22:51 | <csuwldcat> | dglazkov: is the finish line a high precipice of some sort? |
| 22:51 | <dglazkov> | 3) hober is just starting |
| 22:51 | <dglazkov> | csuwldcat: I think general understanding of the problem and seeing the spectrum of solutions |
| 22:52 | <csuwldcat> | dglazkov: do you get the sense he will agree to an optional solution wrt semantics? |
| 22:52 | <dglazkov> | 4) csuwldcat is way over finish line, far far beyond the horizon. We can only hear his screams |
| 22:52 | <csuwldcat> | I was not getting that feeling, just saying... |
| 22:52 | <csuwldcat> | haha, I've already won 7 tour de frances |
| 22:52 | <csuwldcat> | no doping either |
| 22:53 | <dglazkov> | I don't take Hixie's opinion lightly. If he has a strong opinion, there's a good reason for it. |
| 22:53 | <csuwldcat> | dglazkov: I agree it is a completely valid case/desire, never robbed him of that fact |
| 22:54 | <csuwldcat> | just how product relevant it is to the world large and the on-the-ground rate of applicable occurrence |
| 22:57 | <sjmiles_> | optional FTW |
| 22:59 | <hober> | dglazkov: you have to be careful to not end up in "consensus by exhaustion" territory |
| 23:02 | <dglazkov> | hober: I just want consensus. |
| 23:02 | <dglazkov> | exhaustion is optional. |
| 23:03 | <hober> | heh. i predict that, whether or not we manage to get consensus, exhaustion will have turned out to be mandatory :) |
| 23:09 | <dglazkov> | well, it's likely. I'll grant you that. |
| 23:56 | <dglazkov> | awesome discussion everyone, by the way |