| 00:03 | <zewt> | things that are less than confidence-inspiring: http://joker.com has a login form on the front non-https page |
| 00:07 | <tantek> | it's not supposed to be funny? |
| 01:24 | <MikeSmith> | hober: the IRC server was upgraded a few days agod |
| 01:25 | <MikeSmith> | to ngIRCd |
| 01:26 | <MikeSmith> | if you're see flakiness, please report it so the systems team can investigate |
| 01:28 | <a-ja> | it's all the new users....bailing from Messenger :) |
| 01:28 | <MikeSmith> | hober: oh I think what you're seeing might not have anything to do with the IRC server upgrade at all but instead this: "Connectivity problems due to a bad link between MIT and Level3" |
| 01:29 | <MikeSmith> | that connectivity problem has been going on for several days now |
| 01:29 | <MikeSmith> | a-ja: :-) |
| 01:30 | <a-ja> | MikeSmith: just heard that on CNN and haven't read about it yet....wassup? |
| 01:31 | <MikeSmith> | a-ja: I don't know the details at all. Just know it's been at least 2-3 days now going one |
| 01:36 | <abarth> | Hixie: in WebKit, window.document isn't visible across origins |
| 01:37 | <Hixie> | abarth: well, it is, but in those cases it's ok |
| 01:38 | <abarth> | in which cases is it visible across origins? |
| 01:38 | <a-ja> | MikeSmith: ahh...forcing em on to skype instead |
| 01:39 | <Hixie> | abarth: take a same-domain iframe's document, then set your own document.domain. |
| 01:39 | <Hixie> | the document you took is now cross-origin, but you can still access it |
| 01:39 | <abarth> | oh, I wasn't covering document.domain |
| 01:39 | <abarth> | document.domain is dumb |
| 01:39 | <abarth> | and isn't interoperable |
| 01:40 | <abarth> | there's nothing special about document in that regard |
| 01:40 | <MikeSmith> | a-ja: ah you mean Microsoft has shut down Messenger? |
| 01:40 | <abarth> | the same is true for any other property of window |
| 01:40 | <abarth> | or any other property of anything for that mater |
| 01:40 | <abarth> | matter |
| 01:40 | <a-ja> | MikeSmith: in March |
| 01:40 | <abarth> | (except the ones I listed in my email) |
| 01:42 | <JonathanNeal> | Great article Bruce Lawson, if you're out there. http://html5doctor.com/interview-with-ian-hickson-html-editor/ |
| 01:42 | <Hixie> | abarth: yup |
| 01:42 | <JonathanNeal> | Hixie: you were good too :) |
| 01:43 | <Hixie> | heh |
| 01:44 | <a-ja> | why do we trust that guy again? heh |
| 01:45 | <a-ja> | good interview |
| 01:45 | <JonathanNeal> | It was a really great article. Hixie, if the web doesn't work out for us, I will read your column in the printed press. |
| 01:45 | <Hixie> | heh |
| 01:45 | <Hixie> | journalist was one of the things i wanted to be as a kid |
| 01:46 | <Hixie> | (spec writer wasn't. i became a spec writer long before it was what i wanted to be.) |
| 01:46 | <JonathanNeal> | Now you're good at both. Thanks for sharing that content. |
| 02:02 | <MikeSmith> | they should run an article where Hixie is the one who interviews somebody and asks the questions |
| 02:02 | <MikeSmith> | Hixie interviews abarth |
| 02:02 | <MikeSmith> | or bz |
| 02:04 | <a-ja> | or a11y folks |
| 02:07 | <MikeSmith> | speaking of abarth I see WebKit will be moving HTML parsing of the main thread to speed up parsing on mobile |
| 02:07 | <MikeSmith> | http://lists.webkit.org/pipermail/webkit-dev/2013-January/023271.html |
| 02:10 | <abarth> | yes |
| 02:10 | <abarth> | although we're going to start with a slightly different approach that used in mozilla |
| 02:11 | <abarth> | (just moving the tokenizer, not the whole thing) |
| 02:15 | <MikeSmith> | abarth: you working on the implementation again this time too, or just Eric? |
| 02:54 | <MikeSmith> | Hixie: in case you're curious, XSLT WG published a "XSLT and XQuery Serialization 3.0" that defines XHTML and HTML output methods, normatively referencing the HTML spec |
| 02:54 | <MikeSmith> | well, the HTML5 spec |
| 02:54 | <MikeSmith> | though also the HTML4 spec |
| 02:55 | <MikeSmith> | and not matching the definition for space characters in the HTML spec |
| 04:33 | <abarth> | MikeSmith: yes, eric, tonyg, and myself |
| 04:45 | <MikeSmith> | abarth: ah ok |
| 05:23 | <zewt> | i forget how impossible wikipedia is to read without a style to hide the endless gross mass of superscripts |
| 08:02 | <hsivonen> | Hixie: that we now have exceptionally good interop for HTML parsing is not a permission to start breaking that interop! |
| 09:35 | <krijn_> | Are there any WebVTT implementations out there already? |
| 09:53 | <krijn_> | http://ie.microsoft.com/testdrive/Graphics/VideoCaptions/ - IE10, Chrome en Safari, check! |
| 10:31 | <MikeSmith> | https://code.google.com/p/web-page-replay/ is interesting |
| 10:32 | <MikeSmith> | "Record web pages using a local DNS and local HTTP/HTTPS servers which act as proxies and record performance metrics in addition to the actual resources." |
| 10:32 | <MikeSmith> | "Play back recorded pages again with simulated performance characteristics." |
| 10:33 | <MikeSmith> | call-flow diagrams https://code.google.com/p/web-page-replay/wiki/ArchitecturalOverview |
| 11:10 | <Stevef> | krijn_: http://www.w3.org/community/texttracks/2012/08/23/webvtt-support-in-browsers/ may be helpful |
| 11:10 | <krijn_> | Jep, just found that, thanks |
| 11:16 | <SimonSapin> | gsnedders: great news for html5lib on Python 3. It looks like two separate code bases, do you expect to release two tarballs? |
| 11:20 | <SimonSapin> | gsnedders: or maybe a single tarball with a single setup.py that picks between src2 and src3? |
| 12:18 | <Ms2ger> | gsnedders, btw, from __future__ import unicode_literals is nice |
| 12:46 | Ms2ger | never realized how true wordpress's "Some HTML is ok" was |
| 12:47 | <annevk> | I wonder though |
| 12:47 | <annevk> | Impostor, glitch in the matrix, potential comeback? |
| 12:49 | <hsivonen> | I was quite surprised to see someone claiming to be Mark Pilgrim post |
| 12:51 | <MikeSmith> | post where? |
| 12:54 | <Ms2ger> | MikeSmith, Hixie's interview |
| 12:55 | <Ms2ger> | http://html5doctor.com/interview-with-ian-hickson-html-editor/ |
| 12:56 | <MikeSmith> | ah ok |
| 12:58 | <Ms2ger> | What was the chatter about a secret testing meeting about, btw? |
| 12:58 | <darobin_> | it's not secret, it just hasn't been announced.... |
| 13:00 | <Ms2ger> | Go on... :) |
| 13:00 | <darobin> | Ms2ger: from what I gather 29/01, West Coast somewhere |
| 13:00 | <darobin> | that's *all* I know :) |
| 13:00 | <SimonSapin> | Mark Pilgrim’s post if dated 2007 |
| 13:01 | <SimonSapin> | is* dated |
| 13:01 | <Ms2ger> | January 8, 2013 at 5:05 pm # |
| 13:01 | <Ms2ger> | Can someone point me to where \s in JS regices is defined? |
| 13:01 | <SimonSapin> | ah, I was looking at http://blog.whatwg.org/the-longdesc-lottery linked from the interview |
| 13:04 | <hasather> | Ms2ger: http://www.ecma-international.org/ecma-262/5.1/#sec-15.10.2.12 |
| 13:05 | <Ms2ger> | hasather, thanks |
| 13:09 | <Ms2ger> | What does [0-9]{4,} mean? |
| 13:12 | <darobin> | Ms2ger: four or more digits |
| 13:12 | <darobin> | hi romainhuet__ :) |
| 13:13 | <Ms2ger> | darobin, good :) |
| 13:14 | <darobin> | I wonder if TC39 can be convinced to improve JS regexes |
| 13:16 | <annevk> | they are improving them |
| 13:16 | <darobin> | ah, good to know |
| 13:16 | <darobin> | annevk: you have a pointer? |
| 13:20 | <annevk> | darobin: hmm, at least for the i18n work there's talk about it |
| 13:20 | <darobin> | ah yes, I've heard mentions of making \w i18n friendly and that sort of stuff |
| 13:20 | Ms2ger | cries |
| 13:21 | <darobin> | but I'd like things like lookbehinds and such that are a weird omission now |
| 13:23 | <annevk> | \w as well? |
| 13:23 | <annevk> | oh well |
| 13:24 | <annevk> | JavaScript is weird |
| 13:24 | <annevk> | can't find where I read this :/ |
| 13:28 | <annevk> | I wish I was in the same timezone as dglazkov for a while |
| 13:28 | <Ms2ger> | Sounds like you should find an employer in the Bay Area ;) |
| 13:29 | <annevk> | Who says I haven't? :p |
| 13:29 | <Ms2ger> | Problem solved, then :) |
| 13:31 | <annevk> | So given my email from last night, I realize that https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#events-that-are-always-stopped does not make sense. |
| 13:32 | <annevk> | That is, what about the capture phase? |
| 13:33 | <annevk> | dglazkov calls it "refactoring" but I've the feeling what we lack here is a coherent design :/ |
| 13:33 | <annevk> | Maybe I should just ignore the shadow DOM for now and focus on the HTML spec? |
| 13:38 | <annevk> | Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20633 for some of the issues |
| 13:42 | <darobin> | it is customary when designing something around the shadow DOM to come up with a broken design of some kind |
| 13:42 | <darobin> | dglazkov is nothing if not traditional |
| 13:43 | <annevk> | A broken design is okay, but an unexplained design is not. |
| 13:43 | <annevk> | At least not for my purposes... |
| 13:50 | <hsivonen> | annevk: do you have an opinion on <x-map> vs. <select is=map> vs. <select/map> ? |
| 13:50 | <annevk> | hsivonen: they all suck |
| 13:50 | <hsivonen> | yeah |
| 13:52 | <annevk> | <x-map> would make it hard to make custom components out of <td> and such, <select is=map> is kinda weird, <select/map> I suppose is the least weird and the best parser-wise (although it would require changes to the parser) |
| 13:52 | <Ms2ger> | Don't tell that to hsivo... Oh |
| 13:52 | <annevk> | heh |
| 13:53 | <annevk> | Not necessarily best parser-wise as least changes to the parser, but most flexibility for web developers... |
| 13:54 | <annevk> | Well, <select is=map> does that too |
| 13:54 | <darobin> | but it's verbose |
| 13:55 | <Ms2ger> | Won't anybody thnk f te chrcters? |
| 13:56 | <annevk> | Can't avoid verbose while caring about parser compatibility I think... Unless maybe we parse <x-...> similar to <script>? |
| 13:58 | <hsivonen> | I think I care more about infoset compat for server-side munging than about parser compat |
| 13:59 | <hsivonen> | so stuff that would involve non-NCName local names in server-side systems are not OK from my POV |
| 14:00 | <hsivonen> | that is, if you can't use server-side XSLT to augment a doc that says <select/map>, then we shouldn't have <select/map> |
| 14:01 | <annevk> | Isn't it unfair to consider those systems immutable? Just imagine what that would do to CSS, CSS is designed around parser changes... |
| 14:03 | <hsivonen> | annevk: I was talking about data model |
| 14:04 | <hsivonen> | annevk: that's my point: revising the data model in all server-side systems is a big deal |
| 14:04 | <hsivonen> | annevk: even if parsers and serializers are off-the-shelf in principle |
| 14:04 | <annevk> | Ah yeah, dunno what the localName would be for select/map |
| 14:04 | <hsivonen> | annevk: CSS didn't assume a stable data model to begin with |
| 14:05 | <annevk> | (Which is painful for CSSOM designers...) |
| 14:05 | <hsivonen> | <template> breaks the data model on the client |
| 14:05 | <hsivonen> | but on the server you can pretend it doesn't |
| 14:05 | <hsivonen> | not so with select/map as a local name |
| 14:06 | <hsivonen> | unless you want some Uhhhhhh notation |
| 14:06 | <Ms2ger> | <select/map></select/map>? |
| 14:07 | <hsivonen> | that reads almost as badly as <title/foo/ |
| 14:07 | <hsivonen> | the SGML <title/foo/ that is |
| 14:07 | <annevk> | I do anticipate allowing <x-...> will make a even bigger mess of the web as that will be sprinkled all over the place... |
| 14:08 | <hsivonen> | annevk: well, <x-...> can be deployed even if browser devs say “no”… |
| 14:08 | <annevk> | At that point the last bit about shared semantics in HTML is thrown overboard and you really need a browser-like engine to understand what's going on. |
| 14:08 | <annevk> | hsivonen: yeah, and they have of course to some extent. |
| 14:09 | <annevk> | hsivonen: just when you sanction that and let it pass through validation, libraries will use it, developers will use them throughout their site, and reusable HTML is lost to the world. |
| 14:10 | <annevk> | (just thinking out loud) |
| 14:10 | <annevk> | (not necessarily loud :-)) |
| 14:11 | <hsivonen> | I’m in general pretty unhappy that right after we reached interop with IE10 shipping people come up with multiple parser change ideas from <template> to void <menuitem> to <select/map> |
| 14:12 | <annevk> | I'm with Hixie though. The whole point of interoperable parsing is that it makes it easier to make specific changes. |
| 14:13 | <annevk> | That's why we document features of the past and reimplement features of the past. To make it easier to tweak them. |
| 14:17 | <hsivonen> | In the interview, Hixie answered someone that stuff is going to stick if it is in 2 browsers |
| 14:17 | <hsivonen> | I guess that doesn't apply to e.g. <command> parsing/serialization |
| 14:17 | <hsivonen> | so “all bets are off”? |
| 14:18 | <hsivonen> | (or Hixie should have said “in 2 browsers and used in content”) |
| 14:19 | <annevk> | I think that's what he meant |
| 14:20 | <Ms2ger> | Well, I guess it applies in the sense that you shouldn't bet on it being changeable |
| 14:21 | <annevk> | Everyone had some variant of <basefont> too, yet we managed to remove most of it |
| 14:21 | <annevk> | In the case of <Basefont> the parser weirdness is still there though I believe |
| 14:22 | <hsivonen> | annevk: yes, <basefont> and <bgsound> are in the parser as void |
| 14:22 | <hsivonen> | annevk: and it would not be a win to make the parser unaware of them |
| 14:23 | <annevk> | hsivonen: agreed, I meant that we removed HTMLBaseFontElement at some point |
| 14:23 | <annevk> | hsivonen: even though it had two implementations |
| 14:23 | <hsivonen> | IE and Opera? |
| 14:24 | <Ms2ger> | Probably us, actually |
| 14:25 | <annevk> | Gecko at least. |
| 14:25 | <Ms2ger> | https://bugzilla.mozilla.org/show_bug.cgi?id=518110 |
| 14:26 | <annevk> | I wonder if later on nsIDOMHTMLHeadElement.profile was removed now binary compat is no longer necessary? |
| 14:27 | <Ms2ger> | Yeah, I believe so |
| 14:27 | <annevk> | k |
| 14:28 | <annevk> | man |
| 14:28 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=3875#c77 |
| 14:29 | <Ms2ger> | "It's not standards compliant, it's deprecated. We are not required to implement deprecated features" |
| 14:29 | <annevk> | "As font, they liked to have something that presented better to students, Comic Sans MS" "I discover the BASEFONT tag at W3schools" "it works in IE, but not in Mozilla" "I was forced to throw Mozilla from the PC and work just with IE" |
| 14:29 | <annevk> | 10/10 would read again |
| 14:30 | <Ms2ger> | And there's more |
| 14:39 | <annevk> | I hope that not exposing Node's cross-origin catches on |
| 14:40 | <annevk> | (disregarding document.domain for now) |
| 14:52 | <hsivonen> | what’s the correct term for the thing that Rails used to use the snowman for? |
| 14:53 | <hsivonen> | it’s not “UTF-8 canary”, but it’s a similar term |
| 14:53 | <hsivonen> | what is it? |
| 14:53 | <hsivonen> | my memory fails me |
| 14:53 | <hsivonen> | it’s “UTF-8 (noun)” |
| 14:53 | <hsivonen> | but which noun |
| 14:54 | <MikeSmith> | not talisman? |
| 14:55 | <hsivonen> | MikeSmith: no. it has a function |
| 14:55 | <hsivonen> | oh well. I’ll try to write my way around my lack of proper terminology |
| 14:55 | <hsivonen> | two functions even |
| 14:56 | <annevk> | utf-8 parameter? |
| 14:56 | <annevk> | http://stackoverflow.com/questions/4104474/rails-3-utf-8-query-string-showing-up-in-url |
| 14:56 | <annevk> | utf8* |
| 14:58 | <annevk> | hsivonen: https://github.com/rails/rails/commit/c6160898c83107ba63017ad2a8b3878733267136 |
| 15:02 | <hsivonen> | annevk: I saw the patch by wycats_. Too bad the commit message didn’t have the term I was looking for. |
| 15:02 | <hsivonen> | annevk: I also tried to find it on wycats_'s blog and on StackOverflow |
| 15:02 | <hsivonen> | no success |
| 15:02 | <hsivonen> | I’m very sure I am not imagining things and there is a term for that thing |
| 15:02 | <annevk> | from what I can find about the parameter there's not really a name, but maybe someone coined one? |
| 15:03 | <annevk> | something it's called utf8 enforcer param |
| 15:03 | <annevk> | somewhere* |
| 15:04 | <annevk> | not many hits for that though |
| 15:07 | <hsivonen> | FWIW, the context was https://bugzilla.mozilla.org/show_bug.cgi?id=234628#c63 |
| 15:17 | <annevk> | Less encoding menu ++ |
| 15:19 | <romainhuet> | darobin: Hey! Just noticed your message I was away :) |
| 15:19 | Ms2ger | waves at darobin |
| 15:20 | <darobin> | :) |
| 15:21 | <Ms2ger> | darobin, also, ugh. |
| 15:23 | <jgraham> | darobin: So, what's the difference between secret and unannounced? :) |
| 15:25 | <darobin> | hsivonen: I thought it was UTF8 Canary |
| 15:25 | <darobin> | jgraham: secret is properly planned but kept to a gang; unannounced is not even planned out |
| 15:26 | <darobin> | jgraham: note though it's not a really technical meeting, it's about getting commitments from companies to provide resources for testing |
| 15:27 | <jgraham> | Also, I think one lesson from web components is that you shouldn't overconstrain things like identifiers just because you don't have a use case today |
| 15:27 | <jgraham> | Lots of possible solutions fail because they require non NCName tags/attributes |
| 15:28 | <annevk_> | NCName is a disaster |
| 15:29 | <hsivonen> | darobin: ok. maybe canary was the noun I was looking for after all |
| 15:32 | <annevk> | dglazkov: XBL2 misses quite a few lessons from HTML not only because it's a XML vocab :-) |
| 15:32 | <darobin> | hsivonen: actually common usage seems to be "unicode canary" |
| 15:49 | <annevk> | whoa Chrome already ships with some kind of <template> support? |
| 15:50 | <Ms2ger> | Chrome shipping something half-baked? They wouldn't! |
| 15:50 | <annevk> | false alarm it seems |
| 16:40 | <gsnedders> | Ms2ger: from __future__ import unicode_literals and b"" helps iff we drop support for earlier than 2.6, which I dunno about. |
| 16:40 | <gsnedders> | SimonSapin: I dunno, I may well just make it so setup.py uses awkwardduet (a continuation of 3to2) to build the src2. |
| 16:41 | <SimonSapin> | gsnedders: something like distribute’s use_2to3? |
| 16:41 | <gsnedders> | SimonSapin: Exactly. |
| 16:42 | <gsnedders> | Just, like, use_3to2 :) |
| 16:42 | <gsnedders> | But it can't use the actual original 3to2, because we cause that to throw an exception. |
| 16:43 | <SimonSapin> | I didn’t know distribute had use_3to2 built-in like it has use_2to3 |
| 16:43 | <gsnedders> | SimonSapin: I've got no strong opinion on what to do, for distribution. What I will probably do is remove the py2 code from hg. |
| 16:43 | <gsnedders> | To stop people thinking it has any development significance, beyond it working. |
| 16:44 | <jgraham> | gsnedders: Things older than 2.6 are already broken I think |
| 16:44 | <jgraham> | I wontfixed some bugs already |
| 16:44 | <SimonSapin> | however it’s done, It’s desirable that "pip install html5lib" just works on all supported python versions |
| 16:44 | <gsnedders> | SimonSapin: Agreed. |
| 16:44 | <SimonSapin> | it’s one of the reason I made cairocffi to replace py2cairo/pycairo |
| 16:44 | <dglazkov> | annevk: Hixie actually HTML-ized XBL2 in the last large edit |
| 16:45 | <dglazkov> | good morning, Whatwg! |
| 16:45 | <gsnedders> | If we drop everything but 2.6/2.7 then I may well just try and get a single codebase running. |
| 16:46 | <SimonSapin> | single code base with 2.6+ is very doable |
| 16:47 | <SimonSapin> | I even prefer a custom compat.py module to using six |
| 17:01 | <gsnedders> | SimonSapin: tbh, it's embarrassingly rare that I actually deal with anything like packaging nowadays, thus my lack of a clue :P |
| 17:03 | <SimonSapin> | gsnedders: I could give a hand if you want |
| 17:04 | <gsnedders> | I guess my biggest problem is just not knowing what a good idea is for Py2/Py3 duality. |
| 17:06 | <SimonSapin> | b'' and __future__.unicode_literals go a long way to make this easier |
| 17:07 | <SimonSapin> | __future__.division is nice too. (integer division is still available as //) |
| 17:07 | <gsnedders> | Last I knew we were still unofficially officially supporting older Python versions, thus not using that approach. Though 2to3 was badly needed just to sort out the mess there was before of str/unicode comparisons and coercions. |
| 17:09 | <SimonSapin> | https://github.com/mitsuhiko/python-modernize looks nice (one-shot conversion to a single code base) but I haven’t tried it. |
| 17:10 | <gsnedders> | tbh, it may well be pretty much possible just adding from __future__ import unicode_literals |
| 17:10 | GPHemsley | grumbles something about trailing slashes in URLs |
| 17:10 | <SimonSapin> | GPHemsley: what about it? |
| 17:11 | <GPHemsley> | SimonSapin: Just arguing about whether about URLs (particularly bare domains) should have a trailing slash. Also arguing about whether it's worth arguing about. |
| 17:12 | <SimonSapin> | tastes and colors … |
| 17:13 | GPHemsley | grumbles some more |
| 17:14 | <Ms2ger> | non est disputandum? |
| 18:07 | <JonathanNeal> | Hello |
| 18:36 | <JonathanNeal> | When using a <link> element with rel=alternate, is the type required? This fellow says the DIHTML5 chapter is off by saying it is required https://github.com/diveintomark/diveintohtml5/issues/21 |
| 18:37 | <tantek> | huh, he had me until the citation of w3schools |
| 18:38 | <JonathanNeal> | I ignored that reference in my reply. I know it's a red flag. As far as his argument goes, it doesn't really change it. He was just trying to give it weight. |
| 18:39 | <TabAtkins> | JonathanNeal: It seems like Mark is referring to literally rel="alternate", not rel="stylesheet alternate". |
| 18:39 | <tantek> | right, that's the problem. someone thinking that referencing w3schools adds weight is bad sign. |
| 18:40 | <tantek> | also the argument is a bit pedantic and also his suggested text ruins the flow / readability of Mark's text for a very minor point. |
| 18:40 | <TabAtkins> | I'm not sure if <link rel="alternate" type="text/css"> is supported anywhere. |
| 18:40 | <JonathanNeal> | Unless we subtly believe that anything on whatwg that also happens to be in w3schools is probably wrong in both, and that w3schools is, in essence, nothing more than a parody-style bug reporter. |
| 18:40 | <tantek> | TabAtkins, yeah. |
| 18:40 | <TabAtkins> | If it is supported anywhere, I'd believe that type="text/css" might be required to have it process as CSS. |
| 18:41 | <tantek> | so the confusion is that "optional" does not mean "has no effect" |
| 18:41 | <tantek> | the issue reporter is confusing the two |
| 18:42 | <tantek> | yes, "type" is optional, but like many optional features, if you want the desired EFFECT, then using it is REQUIRED |
| 18:42 | <JonathanNeal> | I see. |
| 18:42 | <tantek> | I think Mark's text is short, simple, and fine as is. Adding longer text as suggested just adds to the "glaze" factor and will likely result in LESS comprehension, not more. |
| 18:42 | <tantek> | I would would "won't fix" this. |
| 18:43 | <tantek> | *wordstutter* |
| 18:48 | <JonathanNeal> | Thanks |
| 18:49 | <JonathanNeal> | Thanks a lot, tantek. I would like to have most of these issues addressed or resolved before I begin making the responsive changes. My goal is to have the book more like this https://a248.e.akamai.net/camo.github.com/3d702d436ffc01ec0c533ab0e8b0afd06524257b/687474703a2f2f692e696d6775722e636f6d2f73504d437a2e706e67 |
| 18:49 | <JonathanNeal> | I mean this https://a248.e.akamai.net/camo.github.com/6264b96dce00bb1d2a7b557567a5237213a1544e/687474703a2f2f692e696d6775722e636f6d2f58336838592e706e67 |
| 18:50 | <tantek> | ooh nice! |
| 20:08 | <Hixie> | hsivonen: nobody's talking about breaking interop, just evolving the platform |
| 20:09 | <Hixie> | hsivonen: <command> parsing isn't a feature, <command> is a feature. <command> has never been implemented. |
| 20:26 | <Hixie> | GPHemsley: did you do the eR-eF guy? |
| 20:37 | <GPHemsley> | Hixie: Done now. |
| 20:40 | <Hixie> | oh, thanks. didn't mean to ask you to do it, was just wanting to make sure i didn't give him a second account by mistake :-) |
| 21:04 | <jgraham> | Hixie: Well of course you do break interop if browsers parse <command>foo</command> differently. Particularly if you start getting usage of <command> |
| 21:05 | <Hixie> | why would we get usage of <command>? |
| 21:07 | <jgraham> | Well I guess for a feature that's being removed and never got used the case is weaker |
| 21:09 | <Hixie> | i would be jumping up and down faster than and higher than hsivonen if someone was suggesting turning <img> into a non-void element or some such |
| 21:10 | <tantek> | it is irrelevant if browsers do parse <command>foo</command> differently, if no one publishes any real world pages with <command> that depend on those differences, if even publishes any real world pages with <command> at all that is. |
| 21:11 | <tantek> | if even *anyone* publishes... |
| 21:13 | <jgraham> | Hixie: But it is also problematic to introduce void elements |
| 21:14 | <jgraham> | In general being conservative around the parser is reasonable |
| 21:14 | <tantek> | that I'd agree with |
| 21:14 | <tantek> | on both points |
| 21:15 | <jgraham> | And the burden of proof that changes are compatible is firmly with the people proposing the changes |
| 21:15 | <tantek> | though I'd say "risky" rather than problematic WRT introducing new void elements |
| 21:15 | <tantek> | it's only problematic if there are existing real world pages that happened to be depending on non-void usage of such elements |
| 21:16 | <tantek> | jgraham - I'm not sure the burden is so cut and dry |
| 21:16 | <tantek> | I think we can make bayesian/probabilistic arguments both ways |
| 21:16 | <jgraham> | tantek: I fell like if you want to change the parser you should get some data and show that your change won't break any pages |
| 21:17 | <jgraham> | There are a few sources of such data and people have successfully used them in the past |
| 21:18 | <tantek> | having to prove that every new element won't break the web is too unnecessarily high a bar for our desire to continue evolving the web |
| 21:19 | <tantek> | that being said, as you pointed out, we should be conservative around changes to the parser |
| 21:19 | <jgraham> | Not every new element |
| 21:19 | <tantek> | new void elements are an interesting subset of both of those |
| 21:19 | <jgraham> | Just ones that need parser changes |
| 21:19 | <tantek> | not all parser changes are the same level of "riskiness" |
| 21:21 | <jgraham> | Well obviously. Like Hixie said, changing <img> parsing is an obvious non starter. On the other hand (even) hsivonen believes that it's OK to change the parser for <main> given the risk/benefit (I wonder if someone looked for existing use of <main>...) |
| 21:21 | <tantek> | (people did look for existing uses of <main> - I believe stevefaulkner in particular, with his open crawl corpus) |
| 21:22 | <tantek> | Webdevdata.org |
| 21:22 | <tantek> | now if there was a nice web UI to query that data ... |
| 21:24 | <WeirdAl> | !seen Ms2ger |
| 21:26 | <jgraham> | WeirdAl: Good luck with that |
| 21:26 | <WeirdAl> | I'm looking for some *simple* testcases for DOMParser/XMLSerializer |
| 21:27 | <WeirdAl> | http://domparsing.spec.whatwg.org/ |
| 21:27 | <WeirdAl> | in particular character encodings |
| 21:29 | <jgraham> | You want simple tests for character encodings? You realise that's an oxymoron, right? |
| 21:29 | <annevk> | dglazkov: I wouldn't classify that edit as a major change |
| 21:29 | <jgraham> | But I don't recall any DOMParser tests |
| 21:29 | <WeirdAl> | jgraham: partially, yes :) |
| 21:29 | <jgraham> | Maybe annevk does |
| 21:29 | <annevk> | dglazkov: it was just rewording a few things to get implementor interest, not a fresh look |
| 21:29 | <annevk> | WeirdAl: jgraham, sorry |
| 21:29 | <WeirdAl> | (back in about 15 minutes) |
| 21:29 | <dglazkov> | annevk: okay |
| 21:29 | <jgraham> | Dammit I was trying to pass the buck :) |
| 21:30 | <annevk> | dglazkov: I'd appreciate an answer to the offsetX/offsetY question |
| 21:30 | <annevk> | dglazkov: trying to figure out how to best refactor dispatch |
| 21:30 | <annevk> | dglazkov: but maybe for now I should leave shadow DOM out of the picture? |
| 21:32 | <dglazkov> | annevk: been terribly busy in the last few days, will start answering emails at earnest tomorrow morning (PST) |
| 21:33 | <annevk> | dglazkov: okay, guess I can work on Encoding work instead |
| 21:33 | <dglazkov> | annevk: thank you for your patience. you are very important to us. please continue to hold and the next representative will be with you shortly |
| 21:35 | <annevk> | uhuh :) |
| 21:48 | <WeirdAl> | jgraham: well, the alternative is that I write tests... and people tell me that they're wrong :p |
| 22:03 | <jgraham> | WeirdAl: Maybe if you write correct tests they won't do that? ;) |
| 22:04 | <WeirdAl> | heh, I write tests in Jasmine |
| 22:04 | <WeirdAl> | so even if it's correct, it's "wrong" |
| 22:10 | <jgraham> | Well yes, if you write tests in the wrong format it's not that helpful |
| 22:12 | <jgraham> | Where "wrong" in this case just means "not widely used in the standards community" |
| 22:13 | <csuwldcat> | Hixie: Brian Kardell has the best solution I've seen so far |
| 22:13 | <csuwldcat> | did you see the bug? |
| 22:13 | <Hixie> | jgraham: given the massive upside of <menuitem> and the comparatively trivial upside of <main>, I don't really understand hsivonen's position on this |
| 22:14 | <Hixie> | csuwldcat: looking now |
| 22:15 | <csuwldcat> | dglazkov: read the last two comments on the is/tag bug |
| 22:15 | <csuwldcat> | I like the simplicity of it |
| 22:15 | <jgraham> | "could skip tokenization" - I don't see how that will work |
| 22:16 | <csuwldcat> | jgraham: if you marked it as your 'fallback' it could do that, why not? |
| 22:16 | <csuwldcat> | I mean DOM inflation, whatever |
| 22:16 | <jgraham> | csuwldcat: How do you skip tokenising something? |
| 22:16 | <csuwldcat> | jgraham: basically, it could ignore them |
| 22:16 | <gsnedders> | csuwldcat: How do you know where to resume tokenizing? |
| 22:17 | <jgraham> | Yes, gsnedders was clearer |
| 22:17 | <csuwldcat> | perhaps im not using the right word, can we just fix on the meaning? |
| 22:17 | <jgraham> | You could at best stop treebuilding |
| 22:17 | <csuwldcat> | you don't need the elements if their parent is marked fallback |
| 22:17 | <csuwldcat> | sure, the rotator splint, that thing |
| 22:17 | <csuwldcat> | :) |
| 22:17 | <jgraham> | csuwldcat: It's hard to know what the meaning is if you say something that means something different |
| 22:17 | <csuwldcat> | sorry |
| 22:17 | <csuwldcat> | didn't mean to |
| 22:18 | <jgraham> | Well it's OK , I understand now |
| 22:18 | <jgraham> | I still don't understand why that's considered a good thing |
| 22:18 | <jgraham> | it just seems to introduce gratuitous differences in the DOM |
| 22:19 | <csuwldcat> | not really, it's not all that different than if a Template is applied and the child content doesn't match a <content select=""> selector |
| 22:19 | <csuwldcat> | it is not rendered |
| 22:19 | <csuwldcat> | same sort of thing |
| 22:20 | <csuwldcat> | except you wouldn't ever need to even create the DOM elements in the first place |
| 22:20 | <jgraham> | Well <template> has already caused all sorts of controversy because of the weird-ass way it interacts with the DOM |
| 22:20 | <csuwldcat> | haha |
| 22:20 | <jgraham> | But in that case there was a compelling reason |
| 22:20 | <csuwldcat> | oh this is a barrel of monkeys isn't it |
| 22:21 | <csuwldcat> | fallback allows the developer to not worry about it messing with normal component operation if it is not needed |
| 22:21 | <csuwldcat> | think of alt="" |
| 22:21 | <jgraham> | Well |
| 22:21 | <csuwldcat> | I don't need to query and loop all img elements turning off the alt display when it isn't needed |
| 22:21 | <csuwldcat> | the browser does that |
| 22:22 | <csuwldcat> | the fallback attr would be a flag to tell it to do the same, where similarly unneeded |
| 22:22 | <jgraham> | It seems pretty dubious to me to start adding attributes that affect treebuilding |
| 22:23 | <jgraham> | And it means that you can't show the fallback if there is some fatal problem with the component |
| 22:23 | <csuwldcat> | lol, so naturally you would be opposed to attributes being used to massively affect treebuilding in the realm of compone... oh, wait ;) |
| 22:23 | <jgraham> | I don't know if you can *have* fatal problems with components |
| 22:23 | <bkardell> | Ok... can we consider first without fallback attr |
| 22:24 | <csuwldcat> | jgraham: fatal problems? |
| 22:24 | <jgraham> | Right, so ignoring the @fallback thing, this is roughly the same solution we have for <canvas> |
| 22:24 | <jgraham> | Which sucks |
| 22:24 | <csuwldcat> | it works though |
| 22:24 | <jgraham> | But it is at least a recognised pattern on the platform |
| 22:24 | <bkardell> | It is the same as a lot of things |
| 22:24 | <csuwldcat> | and I'd hate to impose known suckage on the 90% case, to satisfy the hand-wavey fractional cases |
| 22:25 | <jgraham> | I am still dubious of your 90% claims |
| 22:25 | <jgraham> | But anyway |
| 22:25 | <bkardell> | Yes, that is my point...hixie/etc seem ok with them... |
| 22:25 | <csuwldcat> | jgraham: me too, but a majority for sure |
| 22:25 | <dglazkov> | sorry guys, doing the webkit gardening thing, need to watch the tree |
| 22:25 | <csuwldcat> | I have experience in our own component building |
| 22:25 | <csuwldcat> | we have actual man-on-the-ground info and usage on that |
| 22:25 | <csuwldcat> | these are not made-up claims |
| 22:26 | <jgraham> | By "fatal problems", I meant a situation where the component fails to init |
| 22:26 | <jgraham> | For example if I write <x-foo><select fallback>[...] and there isn't any component corresponding to x-foo |
| 22:27 | <jgraham> | I want the select to display |
| 22:27 | <csuwldcat> | well, I wouldn't want component authors to have lame code in every component that sniffed if fallback content was needed and had to manually special case blowing it out |
| 22:27 | <jgraham> | But with @fallback it wouldn't even be in the DOM |
| 22:27 | <csuwldcat> | that was the reason for the suggestion |
| 22:27 | <csuwldcat> | sure, and that's why I was thinking it would be helpful for devs |
| 22:28 | <bkardell> | Ok, so I mentioned this earlier on that thread |
| 22:28 | <csuwldcat> | because they wouldn't have to worry about erasing the unused stuff |
| 22:28 | <jgraham> | Huh? Why would it helpful to not display the fallback in the case of an error? |
| 22:28 | <csuwldcat> | in the words of an obviously cool dude: (2:28:15 PM) jgraham: But with @fallback it wouldn't even be in the DOM |
| 22:28 | <csuwldcat> | precisely my motivation! :) |
| 22:28 | <jgraham> | Right, I see what you are trying to achieve |
| 22:29 | <csuwldcat> | jgraham: error is different |
| 22:29 | <jgraham> | But I think that's the wrong way to do it |
| 22:29 | <csuwldcat> | keep it somewhere, sure |
| 22:29 | <csuwldcat> | this is for you browser-backend folks to figure out |
| 22:29 | <jgraham> | Well there isn't really any "somewhere" |
| 22:29 | <csuwldcat> | im just saying, it would be nice for a dev not to worry about it |
| 22:29 | <csuwldcat> | as with alt="" |
| 22:29 | <csuwldcat> | jgraham: Templates have a non-rendered "somewhere" |
| 22:30 | <csuwldcat> | so, there, somewhere like it |
| 22:30 | <csuwldcat> | you know what I mean |
| 22:30 | <csuwldcat> | so does <object> |
| 22:30 | <jgraham> | The non-rendered somewhere of templates makes kittens weep |
| 22:30 | <bkardell> | I think we all agree on the concepts though? Impl details aside? |
| 22:30 | <bkardell> | Lol |
| 22:31 | <jgraham> | Well |
| 22:31 | <csuwldcat> | I'd rather have kittens weaping than the majority of developers crying because the interface is obtuse and lame |
| 22:31 | <csuwldcat> | weeping* |
| 22:31 | <csuwldcat> | I support kitten sadness, if you will |
| 22:32 | <jgraham> | Conceptually <x-foo> with fallback is ugly and doesn't really encourage good fallback. But I think I can live with it. Of course I reserve the right to change my mind when Hixie and hsivonen point out all the flaws in this approach :) |
| 22:32 | <csuwldcat> | jgraham: the known litany of flaws in the attribute routes are far worse than anything they've presented |
| 22:33 | <csuwldcat> | it's like choosing a footgun because a handknife scares you |
| 22:33 | <Hixie> | bkardell: the key is that with <foo/bar> you can't not give <foo>. If you're saying that <x-bar><foo> would fail to bind if the <foo> was present, and would turn into a single element in the DOM, then ok |
| 22:33 | <Hixie> | bkardell: but that seems like it'd require even more crazy parsing magic than <foo/bar>. |
| 22:33 | <Hixie> | er, if the <foo> was _not_ present |
| 22:33 | <Hixie> | sorry |
| 22:34 | <csuwldcat> | Hixie: but you're hoisting this imposition on all cases when it is not going to be the majority case |
| 22:34 | <csuwldcat> | that's the problem |
| 22:35 | <csuwldcat> | Hixie: also, developers can just use the semantic elements as their component guts |
| 22:35 | <csuwldcat> | Hixie: this API will largely be an advanced dev API, at least short/medium term |
| 22:35 | <csuwldcat> | we will have the opportunity to best-practice-ize the hell out of it |
| 22:36 | <csuwldcat> | and to make you a happy Hixie, I will bust my ass over here at mozilla to make sure all of our docs, references, and components do this well |
| 22:36 | <Hixie> | i feel like you are not taking into account what i have been saying |
| 22:36 | <csuwldcat> | I will shout it from the rooftops, scout's honor |
| 22:37 | <Hixie> | it doesn't matter what you or i say, documentation has minimal impact on what authors do |
| 22:37 | <csuwldcat> | Hixie: correct |
| 22:37 | <csuwldcat> | thus: <x/x-map> |
| 22:37 | <csuwldcat> | boom |
| 22:37 | <Hixie> | i've already responded to that |
| 22:38 | <Hixie> | if you're just going to ignore what i'm saying, there's not much point in discussion |
| 22:38 | <csuwldcat> | where did you respond to it |
| 22:38 | <csuwldcat> | I'm scanning the bug now |
| 22:38 | <csuwldcat> | and I feel similarly |
| 22:38 | <Hixie> | in IRC, yesterday |
| 22:39 | <csuwldcat> | I feel you are paying little to no attention to the #Fact, that the interface and implementation using attributes is fraught with peril |
| 22:39 | <csuwldcat> | and degrades all sorts of other things |
| 22:39 | <Hixie> | i'm not suggesting using attributes... |
| 22:39 | <csuwldcat> | sure you are |
| 22:39 | <Hixie> | authors aren't going to use <x/foo> any more than they'll use <x class="foo"> today -- it looks ugly, validators will complain, etc |
| 22:39 | <Hixie> | i'm really not |
| 22:39 | <csuwldcat> | <select/x-map> == <select x-map> |
| 22:39 | <Hixie> | no |
| 22:40 | <Hixie> | <select/map> == <select>, bound to "map" component |
| 22:40 | <Hixie> | no attributes |
| 22:40 | <csuwldcat> | How do I pollyfill that in a sane way Hixie? |
| 22:41 | <sjmiles> | my concern is that the actual % of components that have sensical fallback semantics is too small to justify any of this hoop jumping |
| 22:41 | <csuwldcat> | if you answer: "you dont" that is an immediate loss of 3423523452352345 points |
| 22:41 | <csuwldcat> | sjmiles: and that's the word! |
| 22:41 | <csuwldcat> | preach it! |
| 22:41 | <Hixie> | we shouldn't optimise for shims, shims are for a few years, the web is for decades |
| 22:42 | <csuwldcat> | hahaha |
| 22:42 | <csuwldcat> | yeah, and so is the lame interface we hoist upon them |
| 22:42 | <Hixie> | yeah ok laugh at me, that will convince me |
| 22:42 | <csuwldcat> | my thouhts exactely |
| 22:42 | <csuwldcat> | im not laughing at you buddy, you are a smart guy |
| 22:42 | <csuwldcat> | and a web icon |
| 22:42 | <csuwldcat> | I was laughing at the irony |
| 22:42 | <Hixie> | if you're not willing to have a serious conversation then i've got bigger fish to fry |
| 22:42 | <csuwldcat> | the very reason you dislike it |
| 22:43 | <csuwldcat> | is the same reason I dislike attr/slash etc |
| 22:43 | <csuwldcat> | sorry, I wasn't laughing at you |
| 22:43 | <csuwldcat> | as I said |
| 22:43 | <Hixie> | i've made multiple attempts at proposing alternative syntaxes that try to take into account the concerns that you have and the concerns i have |
| 22:43 | <csuwldcat> | we just use the same reason, from two different angles |
| 22:44 | <Hixie> | if you're not ok with any of them, it's your turn to try to make proposals that address my concerns and yours |
| 22:44 | <csuwldcat> | we did, but at a point we run up against the realm of total possibility |
| 22:44 | <csuwldcat> | are there other wholey different options possible? |
| 22:45 | <sjmiles> | some of us place a really high premium on simple syntax |
| 22:45 | <sjmiles> | and less so on fallback and machine-semantics |
| 22:45 | <csuwldcat> | sjmiles: where "some of use" == the majority of users/use-cases |
| 22:45 | <Hixie> | sjmiles: right, hence my proposing something that is literally the shortest it could be while still addressing the fallback issue |
| 22:46 | <Hixie> | csuwldcat: without data documenting what the use cases are, repeatedly saying "what i want is the majority case" is unconvincing |
| 22:46 | <csuwldcat> | but you introduce all sorts of other things |
| 22:46 | <csuwldcat> | like the unswitchable case |
| 22:46 | <csuwldcat> | that still is an issue |
| 22:46 | <Hixie> | unswitchable case? |
| 22:46 | <sjmiles> | yes, but as I keep saying, the cost (even if it's the most minimal) is too high for me vs the ROI |
| 22:46 | <csuwldcat> | <input/x-foo> may not be able to be applied to <button/x-foo> |
| 22:46 | <sjmiles> | ^ this |
| 22:47 | <csuwldcat> | I may touch a proto prop in the code def of x-foo that does not exist on <button> |
| 22:47 | <csuwldcat> | even if the phenotypical render of the two would have devs believe it would be logical |
| 22:47 | <sjmiles> | if <input/x-foo> was optional, then I would have no complaints |
| 22:47 | <csuwldcat> | that is a full-stop, unexpected bustage case |
| 22:48 | <csuwldcat> | yep |
| 22:48 | <csuwldcat> | me too |
| 22:48 | <Hixie> | if you write <input/foo>, and "foo" is defined to only apply to / only extend <button>, then obviously it shouldn't bind |
| 22:48 | <csuwldcat> | optional means I agree with anything, as long as there is the option to make a truly custom tag |
| 22:48 | <Hixie> | i answered that yesterday too |
| 22:48 | <Hixie> | sjmiles: it being optional is the one thing i think is a dealbreaker |
| 22:48 | <csuwldcat> | but Hixie, brotha man, where would you specify that? |
| 22:49 | <sjmiles> | then you make 90% of my components div/x-foo |
| 22:49 | <csuwldcat> | in the...component definition? |
| 22:49 | <csuwldcat> | which isn't in the page... |
| 22:49 | <csuwldcat> | which is behind a link asset.... |
| 22:49 | <csuwldcat> | which brings us to square 1 |
| 22:49 | <Hixie> | sjmiles: <div/foo>, not <div/x-foo>. And maybe, I don't know what your componetns are. Is there documentation somewhere that talks about what the likely use cases are? Because 90% of the ones I've seen are extending existing elements, not <div>. |
| 22:49 | <Hixie> | csuwldcat: eh? |
| 22:50 | <Hixie> | csuwldcat: you're not making sense man |
| 22:50 | <csuwldcat> | Hixie: "foo" is defined to only apply to / only extend <button |
| 22:50 | <csuwldcat> | where |
| 22:50 | <csuwldcat> | defined where |
| 22:50 | <Hixie> | csuwldcat: in the definition of "foo" |
| 22:50 | <sjmiles> | we've made extensive component systems using non-web based components |
| 22:50 | <csuwldcat> | which isn't in the page! |
| 22:50 | <Hixie> | csuwldcat: so? |
| 22:50 | <sjmiles> | so, this is just me, I can't say 'for the web' |
| 22:50 | <csuwldcat> | so the dev has to find the link tag |
| 22:50 | <csuwldcat> | hunt through 50 defintions |
| 22:50 | <Hixie> | csuwldcat: why does the dev have to do anything |
| 22:51 | <csuwldcat> | and scout for a whitelist? |
| 22:51 | <csuwldcat> | these are untenable ergonomics |
| 22:51 | <Hixie> | why does the dev have to do this? |
| 22:51 | <csuwldcat> | Hixie: no, that is not really the case |
| 22:51 | <Hixie> | what are you saying "no" to |
| 22:51 | <csuwldcat> | this is why I wanted to talk in person with the rest of the folks |
| 22:51 | <Hixie> | i've only said "why" for the past like 5 lines |
| 22:51 | <sjmiles> | examples from similar technology: http://enyojs.com/gallery/ |
| 22:52 | <Hixie> | csuwldcat: i don't see why we'd be any more able to have a conversation in person than on IRC |
| 22:52 | <csuwldcat> | why, because if they make the assumptions the platform infers currently, they are often going to be sadly mistaken |
| 22:52 | <sjmiles> | fwiw, often these things are 'decorators' that wrap around semantic elements, rather than replace them |
| 22:52 | <Hixie> | csuwldcat: what assumptions |
| 22:52 | <Hixie> | csuwldcat: i'm at a complete loss as to what you're talking about here |
| 22:52 | <csuwldcat> | sjmiles: wow, I didn't even think of that |
| 22:52 | <csuwldcat> | great point |
| 22:53 | <csuwldcat> | Hixie: this is why IRC can be frustrating |
| 22:53 | <Hixie> | csuwldcat: it works better if you use complete sentences :-) |
| 22:53 | <csuwldcat> | I think sjmiles knows exactely what im talking about |
| 22:53 | <Hixie> | csuwldcat: and don't use rhetorical questions |
| 22:53 | <csuwldcat> | if we force a whitelist |
| 22:53 | <csuwldcat> | <element whitelist="input"> |
| 22:54 | <Hixie> | components have a whitelist already, no? they say what they're extending. |
| 22:54 | <csuwldcat> | then that forces a dev hunt |
| 22:54 | <csuwldcat> | no |
| 22:54 | <csuwldcat> | they don't |
| 22:54 | <Hixie> | seriously, dude, rebind your "enter" key to your "space" key and put everything from one sentence on one line |
| 22:54 | <csuwldcat> | can we stop being pedantic about my writing style and focus? |
| 22:55 | <Hixie> | your writing style is making this conversation impossible to follow for me |
| 22:55 | <csuwldcat> | there is currently no whitelist |
| 22:55 | <csuwldcat> | extend declares proto inheritance |
| 22:55 | <Hixie> | components as defined say what they extend, right? |
| 22:55 | <csuwldcat> | it is a 1:1 |
| 22:55 | <Hixie> | ok, great |
| 22:55 | <Hixie> | so that's what you apply the binding to |
| 22:56 | <Hixie> | if you have a component that allows you to enter a bug for a section header, and it extends an <h3>, then you say <h3/bugformheading3> |
| 22:56 | <Hixie> | (though it would be simpler if you could have one component that you could apply to all of h1-h6) |
| 22:56 | <csuwldcat> | you can't mix proto extension and tag application together |
| 22:57 | <dfreedm> | what if you wanted a component to extend another component? |
| 22:57 | <csuwldcat> | they are not the same and have internal code reliance impact |
| 22:57 | <Hixie> | csuwldcat: can you elaborate on why not? |
| 22:57 | <csuwldcat> | the proto is different |
| 22:57 | <csuwldcat> | your example of all Hs is myopic |
| 22:57 | <dfreedm> | say, foo extends h1, and bar extends foo |
| 22:57 | <Hixie> | the proto of what is different from the proto of what? |
| 22:57 | <sjmiles> | you guys are talking about how to make it work, but my concern is still that the syntax is a non starter |
| 22:57 | <dfreedm> | would devs have to know to write a <h1/foo/bar> ? |
| 22:58 | <Hixie> | dfreedm: no, just <h1/bar>, at least in my proposal |
| 22:58 | <csuwldcat> | sjmiles: well sure, but what Hixie is saying, is that no matter how bad the interface would be, the optimal fringe case solution should trump |
| 22:58 | <Hixie> | dfreedm: the key is to have both the component name and the "real semantic" in the markup |
| 22:58 | <Hixie> | csuwldcat: see, that kind of strawman reinterpretation and trivialisation of my comments makes me not at all interested in talking with you |
| 22:59 | <csuwldcat> | is it not true? |
| 22:59 | <Hixie> | csuwldcat: because it makes me feel like you're not taking my concerns seriously |
| 22:59 | <csuwldcat> | I am |
| 22:59 | <csuwldcat> | im just weighing them against the majority of use-cases |
| 22:59 | <Hixie> | i do not think the interface is bad, and i do not think my concern (that we keep conveying semantics) is a "fringe case" |
| 22:59 | <csuwldcat> | I don't think it rises to a level that warrents complicating the ergonomics |
| 22:59 | <Hixie> | you keep referring to this "majority of use cases". are the use cases documented somewhere? |
| 22:59 | <sjmiles> | this is one crucial disagreement |
| 22:59 | <csuwldcat> | warrants* |
| 23:00 | <sjmiles> | I posted a link to a page of 'components', did you see those? |
| 23:00 | <Hixie> | (thank you for writing full sentences btw, it's making it much easier to follow) |
| 23:00 | <csuwldcat> | https://github.com/mozilla/x-tag-elements |
| 23:00 | <csuwldcat> | half of those elements don't extend semantic ones |
| 23:00 | <csuwldcat> | Hixie: do be mindful of what sjmiles mentioned about decorators |
| 23:01 | <csuwldcat> | if your "compontent" is that close to a native element |
| 23:01 | <csuwldcat> | you are likely writing a decorator |
| 23:01 | <Hixie> | sjmiles: yeah, i looked at those. Those of that list that seemed applicable to the Web seemed mostly to be extensions of <input> or <select>. |
| 23:01 | <csuwldcat> | which acts precisely the way you want |
| 23:01 | <sjmiles> | I don't understand 'applicable to the web' |
| 23:01 | <sjmiles> | all those components are in use in applications that use web technology, is this the problem? |
| 23:02 | <sjmiles> | the classic 'page vs app' debate? |
| 23:02 | <csuwldcat> | Hixie: that's the thing with our two stances, I would contend that sjmiles, I, and the majority who have voiced opinion on the issue are focused on the "applicable to the web" cases |
| 23:03 | <csuwldcat> | aka, the way and cases this API will be used en mass |
| 23:03 | <csuwldcat> | Is that not of primary importance? |
| 23:03 | <Hixie> | sjmiles: oh i misunderstood the keyboard one, thought it was for extending the OS on-screen keyboard. YEah, they mostly seem to apply. They mostly are extensions of existing elements, like <iframe>, <input>, <Select>, <applet>, etc. |
| 23:04 | <csuwldcat> | Hixie: I really think the decorators thing is the seperation point |
| 23:04 | <csuwldcat> | I love the idea that they can bridge this gap |
| 23:04 | <Hixie> | most of them on https://github.com/mozilla/x-tag-elements also extend existing elemeents |
| 23:04 | <csuwldcat> | sjmiles: thank you for bringing that up |
| 23:04 | <Hixie> | this all seems to suggest that "the majority of use-cases" do not extend <div> |
| 23:04 | <Hixie> | they extend existing elements |
| 23:05 | <Hixie> | which is _exactly_ what i thought would be the case and why i am worried about people not giving the full semantics in the page. |
| 23:05 | <csuwldcat> | dragbox, alert, dialog, flipbox, indexed scroller, map, mediaquery, modal, panel, shiftbox, slidebox, template - all do not |
| 23:06 | <csuwldcat> | Hixie: the ones that do, would be decorators |
| 23:06 | <csuwldcat> | We just don't have the polyfill for that yet |
| 23:06 | <csuwldcat> | so they are in there |
| 23:06 | <Hixie> | dragbox is a <select> or <menu> extension (not entirely clear to me). |
| 23:06 | <csuwldcat> | an example would be autocomplete, that would be a decorator |
| 23:07 | <Hixie> | alert-popup is a <dialog> extension |
| 23:07 | <Hixie> | dialog-toast is a <dialog> extension |
| 23:07 | <csuwldcat> | no, dragbox is a container that when applied creates an automatically draggable relationship between its children and drop areas, and other dragboxes |
| 23:07 | <csuwldcat> | sure, they would be decorators |
| 23:08 | <Hixie> | <flipbox> is either a CSS binding (what you call a decorator?) that applies to everything, or probably more likely a <section> extension |
| 23:08 | <Hixie> | index-scroller seems to be nothing currently, so can't tell |
| 23:08 | <csuwldcat> | but some of those have proto methods |
| 23:08 | <csuwldcat> | which point to custom elements |
| 23:09 | <csuwldcat> | so that's is not true for most of the ones I listed |
| 23:09 | <csuwldcat> | flipbox could be, slidebox would not be |
| 23:09 | <csuwldcat> | because that needs a template, proto props, and extended methods |
| 23:09 | <Hixie> | not clear what map is; if it's just to show a map, it's probably an <img> extension; if it's a country picker, a <select> extension. If it's an interactive map app like Google Maps, then you might have your first <div> extender (but maybe <article> would be better). |
| 23:10 | <csuwldcat> | it shows a Leaflet interactive map |
| 23:10 | <csuwldcat> | not an img |
| 23:10 | <Hixie> | anyway, this clearly doesn't demonstrate that <div> is what the majority will be derived from |
| 23:10 | <csuwldcat> | and not a country picker, just a map that can be used for any purpose |
| 23:10 | <Hixie> | so, let's put that to rest, please |
| 23:11 | <csuwldcat> | that is not accurate, and I don't agree |
| 23:11 | <Hixie> | ! |
| 23:11 | <Hixie> | we just went through a bunch of them! |
| 23:11 | <csuwldcat> | most of those need proto extension |
| 23:11 | <Hixie> | what does that mean? |
| 23:12 | <Hixie> | that they define an externally visible API? |
| 23:12 | <csuwldcat> | they need to extend the type and provide new functions/accessors |
| 23:12 | <csuwldcat> | correct, one that goes beyond attributes |
| 23:12 | <Hixie> | what does that have to do with whether they are equivalent to an <input> or a <div>? |
| 23:12 | <csuwldcat> | it is the delineation between a decorator and a custom element |
| 23:14 | <csuwldcat> | I just ran out of time for today, but the API interface choice here is going to be a plague to developers for a long time, ergonomics trump, and <x-map><select fallback><option>US</option></select></x-map> is a good solution |
| 23:14 | <csuwldcat> | you'are map could be svg or canvas |
| 23:15 | <csuwldcat> | just because you believe a developer should take on a tag, doesn't mean their use-case is so narrowly defined |
| 23:15 | <csuwldcat> | your* |
| 23:16 | <Hixie> | i don't see why decorators are relevant here |
| 23:16 | <csuwldcat> | Hixie: a intense discussion, but necessary, thank you for having it |
| 23:16 | <csuwldcat> | an intense* |
| 23:21 | <sjmiles> | is there a difference between "semantically equivalent to image" and "has image API such that an image elements is a suitable fallback"? |
| 23:22 | <sjmiles> | I see hixie's point that many of those components could be conceptually similar to input/img/etc., but does that from an API standpoint, that e.g., map IS an img? |
| 23:25 | <sjmiles> | Right, Sgt. Major. Marching up and down the square! |
| 23:32 | <Hixie> | sjmiles: my concern is for the case of the UA that doesn't implement components |
| 23:32 | <Hixie> | sjmiles: and for those, the UA needs to know what element to treat the component element as |
| 23:38 | <bkardell> | Sorry catching up |
| 23:39 | <bkardell> | Wait ... hixie, you keep saying "not select/x-map" but your who point was that legacy read that as attr |
| 23:39 | <bkardell> | Now you are advocating willynilly attributes in the global space? |
| 23:39 | <bkardell> | What am I missing? |
| 23:40 | <Hixie> | not just legacy, any UA that doesn't implement web components |
| 23:40 | <sjmiles> | hixie: it's not clear to me that, e.g., getting a IMG is better than getting an HTMLUnknownElement (or a span) ... I understand the usefulness for semantic evaluation (this thing is image-like), but less so for fallback |
| 23:40 | <Hixie> | the parser would be changed so that <foo/bar> wouldn't treat "bar" as an attribute. |
| 23:41 | <dglazkov> | I think there's a distinction between any UA that doesn't implement Web components and any UA that doesn't run JS. The former is not an issue. The latter is. |
| 23:41 | <Hixie> | sjmiles: in the case of the map, i agree, img wouldn't be particularly useful for fallback. Nothing really would be. |
| 23:41 | <Hixie> | dglazkov: the former is an issue too |
| 23:41 | dglazkov | throws a line into the crowd and runs away |
| 23:42 | <bkardell> | Right but you can't change legacy |
| 23:42 | <bkardell> | Why is the former not an issue? |
| 23:42 | <sjmiles> | hixie: to me, that's the '90% of components don't map to semantics properly' argument that you said I couldn't make anymore :) |
| 23:42 | <Hixie> | sure, but that's not a big deal. Who cares if a few pages get some attributes in legacy UAs on random elements. |
| 23:42 | <bkardell> | Input/type |
| 23:42 | <Hixie> | sjmiles: hm? |
| 23:43 | <bkardell> | You would effectively reserve every valid attr of the base tag instead of just saying x-?? |
| 23:43 | <bkardell> | Hixie...shame |
| 23:44 | <sjmiles> | sorry, I have been suggesting that 'most' components would be based on DIV, and I thought you said that argument was debunked |
| 23:45 | <sjmiles> | the distinction I'm making is that although many of those components map neatly to existing components conceptually, in terms of actual fallback functionality the payoff is drastically less |
| 23:45 | <Hixie> | bkardell: no, i'm saying don't use attributes at all |
| 23:45 | <sjmiles> | sorry "existing components" was supposed to be "existing semantics" |
| 23:46 | <bkardell> | In legacy it _is_ an attr |
| 23:46 | <bkardell> | Isn't that why you suggested in the first? We tried it, it is |
| 23:46 | <Hixie> | sjmiles: for some, fallback for users in legacy UAs is indeed a lost cause, yes. That's not the primary concern. Just like <div> and CSS could just be used exclusively and you'd still have a usable page for users. The problem in both cases is that the page is meaningless for other tools, like search engines, accessibility tools, data mining tools, etc. |
| 23:46 | <Hixie> | bkardell: i don't understand the relevance of legacy parsers here. |
| 23:47 | <bkardell> | Doesn't it defeat the whole pupose if we jump hoops to make legacy work only to kill it |
| 23:47 | <bkardell> | I am gonna have to go read that thread again |
| 23:48 | <nimbu> | OMG |
| 23:48 | <Hixie> | bkardell: as i just said to sjmiles, it's not just about legacy. But even if it was, I don't understand the problem here? |
| 23:48 | <nimbu> | AHEM w3cmemes creator |
| 23:48 | <nimbu> | there is one waiting to be created on today's news |
| 23:48 | <Hixie> | bkardell: how does this kill something? |
| 23:48 | <sjmiles> | hixie: well, this is the distinction I was asking about in the lull ... the difference between 'machine semantics' and 'fallback' |
| 23:49 | <sjmiles> | that's why I wanted to consider some kind of 'machine semantic hint' |
| 23:49 | <sjmiles> | but ultimately that falls in the category of 'make it optional' |
| 23:50 | <bkardell> | Ok... today select/map is parsed as select map |
| 23:51 | <Hixie> | sure but today browsers don't do web components either, so... |
| 23:51 | <Hixie> | that's kind of a non-issue |
| 23:51 | <bkardell> | Anything that is not legacy is by definition new |
| 23:51 | <zewt> | (well, no) |
| 23:52 | <bkardell> | So what part of the new is problematic with the fallback approach I suggested |
| 23:52 | <bkardell> | Did I miss it? |
| 23:52 | <Hixie> | the <foo><bar> thing? |
| 23:52 | <Hixie> | well it's two elements, and it doesn't fail if you don't give the <bar> |
| 23:53 | <Hixie> | so it kinda misses the whole point of keeping semantics |
| 23:53 | <Hixie> | i gotta go, meeting. bbl |
| 23:54 | <bkardell> | I will be leaving, if someone wants to post up to the bug where this leaves off it would be helpful imo |
| 23:54 | <bkardell> | Esp if someone can explain what hixie just said right there :) |