| 00:04 | <aleray> | TabAtkins, sorry I'm affraid I'm a little bit stuck here |
| 00:05 | <aleray> | could you help me drafting the algorithm? |
| 00:06 | <aleray> | i'm back with http://dpaste.com/1655272/ |
| 00:09 | <TabAtkins> | Not really; I don't code against vanilla lxml if I can help it, because the API is terrible. |
| 00:09 | <aleray> | TabAtkins, what would you use instead? |
| 00:09 | <TabAtkins> | My custom DOM-like API on top of it, and tears when I have to use it directly. ^_^ |
| 00:10 | <aleray> | on top of what? lxml.etree? |
| 00:10 | <aleray> | or something else? |
| 00:12 | <TabAtkins> | What I'm suggesting is that you make your algorithm able to take a sequence of elements (like all the children of <body>), and find the subset of them that belong to a given implicit section. Use that to wrap them into a <section>, then re-run it on the children of the <section>. |
| 00:14 | <aleray> | TabAtkins, ok I give another try |
| 00:18 | <TabAtkins> | (I assume that you're running this against a relatively "flat" document, where all the headings are siblings. More complicated structures can't be automatically wrapped in <section>s, because the outline algorithm doesn't necessary correspond to a reasonable nesting structure.) |
| 00:44 | <aleray> | TabAtkins, I have this now: http://dpaste.com/1655376/ |
| 00:51 | <tantek> | Hixie, I'm back |
| 00:53 | tantek | is scrolling backwards |
| 00:59 | <tantek> | Hixie, ok I'm collecting your questions as issues with proposed answers. |
| 00:59 | <tantek> | re: there's been feature requests for tabindex scoping in HTML - URLs? |
| 01:00 | <Hixie> | well really my question is what's your roadmap. are we talking 2 weeks? 2 months? 2 years? |
| 01:01 | <tantek> | it's not a high enough priority for me to put on an explicit roadmap - hence the request for URLs to the requests |
| 01:01 | <tantek> | regardless, I'm collecting questions/ thoughts / issues here: http://wiki.csswg.org/ideas/nav-index |
| 01:02 | <Hixie> | k. what i propose to do then is spec up what html needs just so we can define the status quo, probably this week or so, and then whenever is convenient for you, if you conclude that it should all be defined in CSS instead, just let me know and we can rip it out of HTML then |
| 01:03 | <Hixie> | i don't have any real questions / thoughts / issues other than what i mentioned above -- just a matter of speccing the status quo, for now, and in the future, that issue of the scoping thing. |
| 01:03 | <Hixie> | (this only became relevant recently because i just revamped how focus is specced, so there's a lot of loose ends now that i'd like to tie up sooner rather than later) |
| 01:04 | <tantek> | Hixie we have to define the status quo of tabindex *anyway* |
| 01:04 | <tantek> | so nothing should block you from doing that |
| 01:04 | <Hixie> | well the only part of tabindex that isn't specced is the sequential navigation algorithm at this point |
| 01:04 | <tantek> | I'm happy to wait to see what you do there before doing anything further with nav-indesx |
| 01:04 | <Hixie> | which presumably is the same algorithm that would take into accound nav-index |
| 01:04 | <Hixie> | roger |
| 01:05 | <tantek> | well there's the absence of spec, and then there's the issues that have been reported |
| 01:05 | <Hixie> | are there issues other than the above? i looked at the urls you pasted but they didn't have much in the way of anything else |
| 01:05 | <Hixie> | at least, not that i saw |
| 01:08 | <tantek> | Hixie, these were enough of a pain that I gave up for now: http://wiki.csswg.org/ideas/nav-index#external-issues-to-be-incorporated |
| 01:08 | <tantek> | if you want to tackle all those, be my guest |
| 01:08 | <Hixie> | that seems to boil down to "status quo" + "scoping" |
| 01:08 | <tantek> | if you could at least drop in a few URLs to your resolutions to that wiki page that would be great. or ping me here and I'll edit the page - either way I do want to shadow this work |
| 01:09 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=24719 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=23960 are the two things on my radar (status quo and scoping respectively) |
| 01:10 | <Hixie> | not planning on doing the scoping thing soon |
| 01:10 | <Hixie> | so the only decision is "should we match the status quo" which i'm answering "yes" to. :-) |
| 01:13 | <tantek> | Hixie, that's an excellent start and scoping of work ;) |
| 01:16 | <tantek> | and thanks for the URLs, incorporated as references: http://wiki.csswg.org/ideas/nav-index#within-a-dialog-and-browsing-context |
| 01:19 | <a-ja> | Hixie: haven't looked in a while...anyone doing focus on <summary> correctly yet? |
| 01:19 | <Hixie> | define "correctly"? :-) |
| 01:19 | <a-ja> | and <summary> containing a link |
| 01:19 | <Hixie> | not sure. |
| 01:19 | <Hixie> | gotta go, though. bbl. |
| 01:21 | <aleray> | TabAtkins, I'm getting there it seems, but I'm having troubles with recursion: http://dpaste.com/1655487/ |
| 01:53 | <aleray> | TabAtkins, kind of there, seems to make the deal: http://dpaste.com/1655573/ |
| 01:53 | <aleray> | thanks a lot for helping out$ |
| 07:34 | <Ms2ger> | Anybody with a corpus want to grep for -moz-grid? |
| 08:52 | <zcorpan> | TabAtkins: why do css specs have the "default stylesheet" thing still? isn't that a waste of time given html's rendering section? |
| 10:21 | <JakeA> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html should embeded content be part of the edits page? |
| 10:25 | <zcorpan> | JakeA: i think the splits are a bit arbitrary, based on Philip`_'s size of the scrollbar thumb of each page when he implemented the splitter a few years ago, plus a few tweaks since |
| 10:26 | <JakeA> | Ahh ok, gotcha. Didn't realise it was automated like that |
| 10:48 | <Ms2ger> | karlcow, :) |
| 10:49 | <zcorpan> | JakeA: it's always possible to tweak the splits if they're suboptimal, though i'm not sure who maintains it now |
| 11:12 | <Ms2ger> | zcorpan, does anybody spec things like UIEvent.layerX? |
| 11:13 | <zcorpan> | Ms2ger: don't see it in dom3events or uievents |
| 11:13 | <zcorpan> | Ms2ger: what does it do? |
| 11:13 | <Ms2ger> | No idea, I noticed it in IDL that Servo copied from Gecko |
| 11:40 | <zcorpan> | i sense that goto fail; is the new meme |
| 11:41 | <MikeSmith> | heh |
| 12:03 | <JakeA> | The DOMContentLoaded event bubbles, anyone know why? |
| 12:19 | <zcorpan> | JakeA: probably because that's what gecko (or whoever was first) implemented |
| 12:27 | <JakeA> | zcorpan: oh yeah, it does bubble window, didn't realise that |
| 13:08 | <ondras> | so, who is the Custom Elements guru here? |
| 13:08 | <ondras> | why is there the "is" attribute for custom elements that use the "extends" clause? |
| 15:11 | <JakeA> | Been playing around with the idea of pseudo-classes to hide content that hasn't fully parsed/loaded https://docs.google.com/document/d/1qUAI7BGEAMYh6aNq3NGW2BlI6hNhg4_tKLhL_VsiRqU/edit |
| 15:11 | <JakeA> | Hoping it'll be an alternative to html imports render-blocking by default |
| 15:16 | <bblfish> | hi, I just posted a mail on keygen, if anyone has any questions on it |
| 15:16 | <Ms2ger> | "RDF 1.1 is a W3C Recommendation" |
| 15:16 | <Ms2ger> | WHAT YEAR IS IT?! |
| 15:19 | <bblfish> | well application/pkix-cert does not seem to work on Chrome for the returned X509 certificate |
| 15:23 | <MikeSmith> | bblfish: saw your message but haven't read it yet. I think you'll have a serious uphill battle trying to convince people we should use keygen for anything new |
| 15:24 | <bblfish> | keygen works very well |
| 15:24 | <MikeSmith> | ok I guess I'll just wish you luck then |
| 15:24 | <bblfish> | And Client Side Certificates can be very useful for helping us leave the space of centralised services https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html |
| 15:24 | <bblfish> | It's just not widely known how to use them to avoid CAs |
| 15:27 | <bblfish> | anyway, all that's missing in the spec is the specification of the mime type application/x-x509-user-cert since I did not find that in IANA, and that seems to be used in each browser |
| 16:33 | <jernoble|laptop> | ericc: g'morning! |
| 17:51 | <jcgregorio> | good morning dglazkov ! |
| 17:51 | <dglazkov> | good morning, Whatwg! |
| 17:51 | <dglazkov> | whoa |
| 17:51 | jcgregorio | 0/ |
| 17:54 | <Hixie> | if i do a bing search for [hixie tests adhoc html frames iframes], the first hit is: |
| 17:54 | <Hixie> | HTML Frames: absolute parent.frames['top'].location.href |
| 17:54 | <Hixie> | www.hixie.ch/tests/adhoc/html/frames/004.html |
| 17:54 | <Hixie> | pass. |
| 17:54 | <Hixie> | as far as i can tell, http://hixie.ch/tests/adhoc/html/frames/iframes/004.html doesn't contain the word "pass" |
| 17:54 | <Hixie> | so where the heck are they getting the word "pass" from??? |
| 17:56 | <jgraham> | if (site.host == "hixie.ch" && site.path.indexOf("/tests/") > -1) {site.summary = "pass"}, perhaps? |
| 17:59 | <jgraham> | Hixie: (those are different URLs FWIW) |
| 17:59 | <Hixie> | oh hey, so they are |
| 17:59 | <Hixie> | how did i miss that those urls were different |
| 18:00 | Ms2ger | gives Hixie a cup of coffee |
| 18:01 | jgraham | doesn't think that will help |
| 18:01 | <mathiasbynens> | should `element.id = null` result in `id="null"` or remove the `id` attribute? Safari removes, Chrome and Firefox set "null" as the attribute value |
| 18:01 | <jgraham> | (he will jsut give it back to you) |
| 18:02 | <mathiasbynens> | did this change recently? |
| 18:02 | <mathiasbynens> | data:text/html,<p id=x></p><script>var el = x; el.id = null; console.log(el.outerHTML)</script> |
| 18:03 | <Hixie> | mathiasbynens: looks to me like it should set it to "null". |
| 18:03 | <Hixie> | per spec, anyway |
| 18:03 | <Hixie> | null coerces to "null" in WebIDL |
| 18:03 | <Hixie> | .id is defined as reflecting |
| 18:03 | <Hixie> | and reflecting is defined as follows: On setting, set an attribute for the context object using the name of the attribute and the given value |
| 18:04 | <mathiasbynens> | thanks for confirming |
| 18:04 | mathiasbynens | files WebKit bug |
| 18:08 | <Ms2ger> | "MikeSmith: You don't need to do anything! I need to get off my ass and do something." |
| 18:14 | <MikeSmith> | haha wilhelm actually scribed that |
| 18:22 | <TabAtkins> | zcorpan: Possibly, yeah. |
| 18:27 | <MikeSmith> | TabAtkins: have you or the CSS WG overall considered putting "Don't use this" warnings on CSS TR drafts? |
| 18:27 | <TabAtkins> | Yes we have, but I haven't cared enough to overcome the inertia against making changes like that. |
| 18:28 | <MikeSmith> | I ask because I just noticed an implementor somebody in the WebDriver f2f citing TR versions of CSSOM and CSSOM View |
| 18:28 | <MikeSmith> | TabAtkins: ok |
| 18:28 | <MikeSmith> | yeah I figured that was why |
| 18:29 | <SimonSapin> | FWIW, https://github.com/mozilla/servo/wiki/Relevant-spec-links may be useful outside of Servo |
| 18:29 | <Ms2ger> | Inertia at the CSSWG? |
| 18:29 | <Ms2ger> | Who'd have thought |
| 18:29 | <SimonSapin> | Ms2ger: inertia for for making changes to anything on /TR |
| 18:29 | <TabAtkins> | It's almost like we're a mature W3C group, and filled with a decent number of people who are scared of living standards. |
| 18:30 | <MikeSmith> | SimonSapin: btw for some reason I thought you were co-editing CSSOM |
| 18:30 | <TabAtkins> | SimonSapin: Specifically, making *negative-sounding* changes to anything on /TR. |
| 18:30 | <Ms2ger> | Heh, mature |
| 18:30 | <MikeSmith> | I like how you put the implied scare quotes around the word mature there |
| 18:31 | <SimonSapin> | MikeSmith: I’m not, though I did make an edit once after zcorpan’s +1 |
| 18:31 | <TabAtkins> | "Mature" meaning "crotchety", in my case. |
| 18:33 | <MikeSmith> | SimonSapin: you editing something though I thought |
| 18:33 | <SimonSapin> | Syntax ? |
| 18:33 | <MikeSmith> | ah yeah that |
| 18:34 | <SimonSapin> | and Paged Media, though not really since I left Kozea |
| 18:35 | <MikeSmith> | OK |
| 18:35 | <Domenic_> | SimonSapin: that servo page is amazing. |
| 18:35 | <MikeSmith> | man I need HTML Imports and friends so that I can create a Fugly Warning component and easilty add it to tons of documents in TR |
| 18:36 | <jgraham> | TabAtkins: Those people are just the ones who need to see that real downstream users of CSS are having to route around the damage the WG is causing |
| 18:37 | <MikeSmith> | maybe we should just get the IP ranges for all browser vendors and just block all those from access to /TR |
| 18:37 | <TabAtkins> | jgraham: It's been stated. Some of them *cough*Bert*cough* don't care. |
| 18:37 | <jgraham> | So those people should be ignored |
| 18:37 | <TabAtkins> | MikeSmith: That would be a pretty wonderful idea. |
| 18:37 | <Ms2ger> | MikeSmith, sounds difficult for Mozilla |
| 18:37 | <TabAtkins> | jgraham: Yeah, so let's go back to the "mature W3C group" part, and how it's hard to deal with politics. |
| 18:38 | <Ms2ger> | MikeSmith, why not block access to TR for everyone except Sofia-Antipolis? |
| 18:38 | <jgraham> | Well if their response is "fuck you" it's not politics, it's childishness |
| 18:38 | <TabAtkins> | Yes. |
| 18:38 | <TabAtkins> | But hey, they're employees. |
| 18:38 | <Ms2ger> | And we're back to my scare quotes |
| 18:38 | <jgraham> | Why not just take down TR and then tell anyone who complains to get over themselves |
| 18:39 | <MikeSmith> | I added fugly to the WebDriver spec at least, just now http://www.w3.org/TR/webdriver/ |
| 18:39 | <TabAtkins> | There's the ongoing effort (that's getting close to completion, I think?) to make /TR show the ED if the editors opt into it. |
| 18:39 | <Ms2ger> | Har har har |
| 18:40 | <MikeSmith> | it's nice to have some WGs where I can just do stuff without anybody complaining |
| 18:41 | <MikeSmith> | like the WebDriver WG aka Browser Tools and Testing |
| 18:41 | <jgraham> | TabAtkins: Opt-in sounds awful. It just makes the problem inconsistent so that people don't learn there's an issue and then trip up |
| 18:41 | <MikeSmith> | because everybody in that WG is basically sane and focused on actually working on stuff |
| 18:42 | <Ms2ger> | MikeSmith, I guess it must be an "immature" group |
| 18:42 | jgraham | disputes "sane" |
| 18:42 | <TabAtkins> | On the other hand, it's a good way to sneak that shit in without people blowing up, and then once it's established, you can make it mandatory. |
| 18:42 | <Ms2ger> | jgraham, well, let's just ignore AutomatedTester :) |
| 18:43 | <TabAtkins> | Like we did with making groups public. Optional, but gradually nearly everyone become open. I think maybe all groups are open now? (Or maybe there's still a few a11y cobwebs that are closed.) |
| 18:44 | <jgraham> | Making groups open didn't really have any potential for hidden traps though |
| 18:44 | <jgraham> | Either a group was open or it was closed |
| 18:44 | <MikeSmith> | CSS WG needs a crazy staff contact who people are afraid of, afraid to cross. who just does the right thing and then goes on vacation and nobody can figure out how to unwind the stuff he did (like add a Fugly Component to all CSS WG TRs in some obfuscated way) |
| 18:45 | <MikeSmith> | hmm I have a feature request for dglazkov |
| 18:45 | <TabAtkins> | MikeSmith: Be our father figure, please? |
| 18:45 | <TabAtkins> | Or dglazkov, yeah. |
| 18:45 | <TabAtkins> | I'm too chummy to do it. |
| 18:45 | <Ms2ger> | MikeSmith, Bert? |
| 18:45 | <TabAtkins> | You forgot "does the right thing" |
| 18:46 | <MikeSmith> | no comment |
| 18:46 | <Ms2ger> | Maybe he thinks he does the right thing? |
| 18:46 | <MikeSmith> | I'm not here |
| 18:46 | <TabAtkins> | Oh, he definitely *thinks* he does. |
| 18:46 | <Ms2ger> | MikeSmith, rather I moved the conversation to #testing? |
| 18:47 | <MikeSmith> | I'm only here to get dglazkov to spec my mechanism for Secret HTML Imports for adding components to documents in such a way that when you go on vacation nobody else can figure out how to remove them |
| 18:47 | <MikeSmith> | Ms2ger: we're going through a open bug list here |
| 18:48 | <Ms2ger> | Hack into apache |
| 18:48 | <MikeSmith> | which is like listening to nails on the chalkboard |
| 18:48 | <Ms2ger> | Or better |
| 18:48 | <Ms2ger> | Install wptserve on w3.org and pass everything except TR/css-* requests to apache |
| 18:49 | <MikeSmith> | that'd be good |
| 18:49 | <MikeSmith> | good way for us to test how wptserve works under load at least |
| 18:50 | <ondras> | 14:08 < ondras> so, who is the Custom Elements guru here? |
| 18:50 | <ondras> | 14:08 < ondras> why is there the "is" attribute for custom elements that use the "extends" clause? |
| 18:51 | <jgraham> | MikeSmith: "works" |
| 18:51 | <MikeSmith> | heh |
| 18:52 | <MikeSmith> | ondras: you need to get some attention from dglazkov |
| 18:54 | <ondras> | MikeSmith: ok thanks |
| 18:54 | <ondras> | dglazkov: ? :) |
| 18:55 | <ondras> | dglazkov: why <button is="my-button"> instead of just <my-button>? is there some advantage in the former? |
| 18:56 | <Ms2ger> | Fallback |
| 18:56 | <Ms2ger> | Accessibility |
| 18:56 | <Ms2ger> | Semantics |
| 18:57 | <ondras> | I do not see any of those. :-) |
| 18:57 | <ondras> | <my-button> is also available, right? |
| 18:57 | <Ms2ger> | Maybe |
| 18:57 | <ondras> | why shall I prefer the "is" version then? |
| 18:57 | <Ms2ger> | It shouldn't be |
| 18:57 | <Ms2ger> | <Ms2ger> Fallback |
| 18:57 | <Ms2ger> | <Ms2ger> Accessibility |
| 18:57 | <Ms2ger> | <Ms2ger> Semantics |
| 18:58 | <ondras> | so if I do registerElement("my-button-1"), I can do <my-button-1>; when I registerElement("my-button-2", {extend:Button}), I am limited to <button is="my-button-2"> |
| 18:58 | <ondras> | looks highly illogical to me. |
| 19:00 | <jgraham> | ondras: Why would you want to make a button that a non-web-components UA, or an AT, treats like a plain <div> rather than like a <button>? |
| 19:01 | <ondras> | jgraham: because I find it straightforward that registerElement("x") implies <x> |
| 19:01 | <ondras> | which is true |
| 19:01 | <ondras> | in *some* cases |
| 19:02 | <ondras> | but when I pass one very special additional argument to registerElement |
| 19:02 | <ondras> | I suddenly cannot do <x> |
| 19:02 | <ondras> | from a purely API view, this looks truly strange. |
| 19:02 | <jgraham> | ondras: what do you think a UA will do with a <my-button> element? |
| 19:03 | <ondras> | jgraham: I have no idea. Shall I be interested in that? |
| 19:03 | <ondras> | my aim is to create a custom element that does some stuff |
| 19:03 | <ondras> | I am not sure what it does right now |
| 19:03 | <ondras> | but one day, someone will require some functionality |
| 19:03 | <jgraham> | ondras: Presumably your aim is to deliver some content to web users |
| 19:03 | <ondras> | preferrably. |
| 19:03 | <jgraham> | In which case it makes sense to worry about how their UA will treat your content |
| 19:03 | <ondras> | probably according to the spec? |
| 19:04 | <tobie> | tbh, I understand the background for the is="foo" notation, but my first reaction to this was WTF. |
| 19:04 | <ondras> | hmh. |
| 19:04 | <ondras> | well I probably need some time to understand the reasons |
| 19:04 | <Ms2ger> | tobie, that's my first reaction to most of the web |
| 19:04 | <ondras> | what if I want to extend my-button that already extends button? |
| 19:05 | <tobie> | heh |
| 19:05 | <jamesr__> | Hixie: the 'compound microtask' concept seems to be unnecessary |
| 19:05 | <ondras> | <button is="my-button-2"> or <my-button is="my-button-2"> ? |
| 19:05 | <jgraham> | ondras: In a UA that doesn't support web-components, what will happen if you write <my-button>? |
| 19:05 | <ondras> | jgraham: it will be treated as <div>, I guess |
| 19:05 | <tobie> | jgraham: that's implementation specific |
| 19:05 | <Ms2ger> | tobie, wat |
| 19:05 | <Hixie> | jamesr__: only in a UA that doesn't support showModalDialog(). While I'm all for that, so far we haven't proved it's possible to drop it, and other UAs have indicated that they want to support it, including in microtasks. |
| 19:06 | <Ms2ger> | tobie, you're aware we're in the standardization business here? |
| 19:06 | <jgraham> | tobie: No it isn't |
| 19:06 | <ondras> | :P |
| 19:06 | <jgraham> | ondras: Pretty much, yeah |
| 19:06 | <tobie> | old IE won't let you style the element at all, afaik |
| 19:06 | <ondras> | jgraham: the same applies to <my-calendar> that does not extend anything |
| 19:06 | <Hixie> | (more like <span>, actually) |
| 19:06 | <jamesr__> | Hixie: even in a UA that supports showModalDialog |
| 19:06 | <jgraham> | ondras: Well ideally that could extend input type=datetime |
| 19:07 | <jgraham> | Not sure if that's possible or not though |
| 19:07 | <ondras> | jgraham: there are surely cases where I do not extend. or is that not desirable at all? |
| 19:07 | <jamesr__> | a better spin-the-event-loop definition would fix it too |
| 19:07 | <ondras> | jgraham: if the non-extend variant was banished, *that* would make sense to me. |
| 19:07 | <jgraham> | ondras: If you are creating a better version of a control that has native HTML sematics it's always better to extend |
| 19:07 | <ondras> | but having and not having <x> based on whether it extends something... weird. |
| 19:07 | <Ms2ger> | That would make a lot of sense to me too |
| 19:07 | <Hixie> | jamesr__: please file a bug with a concrete proposal. i don't see any other way to do it that satisfies all the constraints, but i'm happy to consider one if one exists. |
| 19:08 | <jgraham> | It makes it much more likely that your page will work in down-rev browsers, in assistive technologies and so on |
| 19:09 | <Hixie> | always having to extend would make sense to me too, but extending <span> is kinda pointless, and that's what a lot of components would end up having to do, in practice |
| 19:09 | <tobie> | jgraham: : I'm not suggesting this is intentionally left to be impl. specific--just that older IE won't even treat is as a regular div unless you use the document.createElement('foo') trick. |
| 19:10 | <jgraham> | tobie: Isn't that quite old IE now? |
| 19:10 | <tobie> | fair enough. |
| 19:10 | <ondras> | IE8? |
| 19:11 | <ondras> | it is old |
| 19:11 | <ondras> | but still about 20% here in .cz. |
| 19:11 | <ondras> | I see that extending <span> is pointless, but the complete API divergence re. <x> vs. <stuff is="x"> is so strikingly strange |
| 19:12 | <ondras> | either the goal *is* to introduce custom elements, or it is not |
| 19:12 | <Hixie> | (is there really much divergence? i would expect the former to basically just be syntactic sugar for <span is="x">) |
| 19:12 | <ondras> | perhaps the goal is to confuse developers by introducing a puzzling api? :) |
| 19:13 | <ondras> | Hixie: *if* <my-button> was allowed (and recommended) as well |
| 19:13 | <ondras> | Hixie: so these two variants were freely interchangeable |
| 19:13 | <ondras> | and one would pick the one that fits his compatibility needs |
| 19:13 | <jgraham> | The goal was to make the right thing easy and all things possible. The API ended up making the right thing hard :( |
| 19:14 | <ondras> | to me, this looks like a clear message "do not try to make custom elements; extend instead" |
| 19:14 | <Hixie> | jgraham and ondras seem to be saying opposite things |
| 19:14 | <ondras> | (which can be also read as "the burden of backward compatibility will haunt you, the developer, forever) |
| 19:15 | <Hixie> | but i'm confused as to why there's much difference at all |
| 19:15 | <Hixie> | extending is definitely better, if there's an appropriate element |
| 19:15 | <jgraham> | Yeah. I'm not sure why you think that <x-foo> is harder than <span is="x-foo"> |
| 19:15 | <ondras> | better w.r.t. non-customelement UAs? |
| 19:16 | <Hixie> | better with respect to any UA. e.g. a web-componenents UA, when the web component files start 404ing. |
| 19:16 | <Hixie> | better w.r.t. search engines |
| 19:16 | <Hixie> | better w.r.t. downlevel clients |
| 19:16 | <Hixie> | better w.r.t. authors new to the widget library |
| 19:17 | <ondras> | okay. so when extending is better, I see no point in <x-foo> |
| 19:19 | <tobie> | irc the JS API kind of make <x-foo> the expected markup, rather than <div is=x-foo> |
| 19:19 | <Hixie> | ondras: sometimes, there's nothing appropriate to extend. |
| 19:19 | <Hixie> | ondras: e.g. what would you extend if you wanted to make a chess board container? |
| 19:20 | <TabAtkins> | <x-foo> looks way better in the markup than <div is=x-foo>, and is easier to construct in JS. Has a lot of benefits. |
| 19:20 | <Hixie> | ondras: or a chess piece? |
| 19:20 | <jgraham> | I thought it was basically that people didn't like the extra keystrokes and (probably) planned to sell out all the cases where extending is better to make their code a bit prettier |
| 19:21 | <Hixie> | yes, the real reason people are pushing non-extended elements is that they think it's prettier and they don't care about all the things i said above |
| 19:21 | <tobie> | How do selectors handle these? |
| 19:21 | <Hixie> | which is lame |
| 19:21 | <Hixie> | (but my point above is just that even if the main people pushing this have lame reasons, there are also good reasons) |
| 19:21 | <Hixie> | (so the lame reasons are moot) |
| 19:22 | <tobie> | E.g. when you do doc.querySelectorAll("x-foo"), does it also return <div is=x-foo>? |
| 19:26 | <ondras> | Hixie: for something completely new, I would expect an <element is="chess-piece"> or something |
| 19:26 | <ondras> | for the sake of consistency with <button is="my-button"> |
| 19:26 | <Hixie> | why is that better than <chess-piece> ? |
| 19:27 | <Hixie> | for consistency with <button> ? |
| 19:27 | <ondras> | Hixie: I thought you already outlined the reasons |
| 19:27 | <ondras> | 20:16 < Hixie> better w.r.t. search engines |
| 19:27 | <ondras> | 20:16 < Hixie> better w.r.t. downlevel clients |
| 19:27 | <ondras> | 20:17 < Hixie> better w.r.t. authors new to the widget library |
| 19:27 | <Hixie> | the reasons i gave don't apply here |
| 19:28 | <Hixie> | <element is="chess-piece"> and <chess-piece> are identical in all ways except syntax, as far as search engines, down-level clients, unfamiliar authors, etc, go. |
| 19:28 | <ondras> | also, how does the "extends" and "prototype" mix together? is it not sufficient to use only "prototype" ? |
| 19:28 | <ondras> | Hixie: right. but <button is="my-button"> and <my-button> are not, right? |
| 19:28 | <Hixie> | (can anyone test IE for me on http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2845 ? what does the log say?) |
| 19:28 | <Hixie> | ondras: right |
| 19:28 | <ondras> | and that puzzles me. |
| 19:29 | <ondras> | because you offer two ways of doing the same stuff (<e is="chess">, <chess>) |
| 19:29 | <ondras> | which is okay |
| 19:29 | <Hixie> | a better way to put it is <button is="zzz-zzz"> and <zzz-zzz> are different, but <zzz is="zzz-zzz"> and <zzz-zzz> are the same. |
| 19:29 | <ondras> | but you forbid one of them in a different context |
| 19:29 | <Hixie> | the difference is that the first (<button is="zzz-zzz">) has a well-understood value, plus the custom value. |
| 19:30 | <Hixie> | whereas the second has nothing well-understood. |
| 19:30 | <Hixie> | (nor the third, nor the fourth) |
| 19:31 | <ondras> | my interest, as a web developer (and teacher), is what version shall I ideally use |
| 19:31 | <Hixie> | if you are extending an existing element, is="". otherwise, not is="". |
| 19:31 | <ondras> | the recommendation of using <my-chessboard> along with <button is="my-chess-clock-button"> simply looks inconsistent |
| 19:31 | <ondras> | that's all. |
| 19:32 | <ondras> | 20:28 < ondras> also, how does the "extends" and "prototype" mix together? is it not sufficient to use only "prototype" ? |
| 19:32 | <ondras> | i.e. registerElement("my-button", {prototype:Object.create(Button.prototype)}) |
| 19:33 | <ondras> | somehow implies that I am extending the HTMLButtonElement |
| 19:33 | <ondras> | or how the hell is it called. |
| 19:36 | <tobie> | it is extending it. |
| 19:55 | <ondras> | tobie: ? |
| 19:55 | <ondras> | tobie: I am not sure I understood |
| 19:57 | <tobie> | Well, as far as I understand, registerElement("my-button", {prototype:Object.create(Button.prototype)}) makes <my-button> and <button is=my-button> strictly identical in all but old browsers. |
| 19:59 | <ondras> | tobie: right. so why use registerElement("my-button", {extends:HTMLButtonElement}) ? |
| 19:59 | <tobie> | does that exist too? |
| 20:02 | <ondras> | tobie: yes; when you extend stuff, you have to specify the "extends" clause in the registerElement descriptor. |
| 20:03 | <MikeSmith> | oh |
| 20:04 | <ondras> | which reminds me... what if the prototype/extends does not strictly match the localName of the "is" element? |
| 20:04 | <ondras> | as in |
| 20:04 | <ondras> | <button is="my-button">, registerElement("my-button", {prototype/extends: span}) |
| 20:05 | <MikeSmith> | just syntax? |
| 20:05 | <MikeSmith> | conve |
| 20:06 | <MikeSmith> | (that was in reply to earlier comment) |
| 20:07 | <tobie> | "conve" was? |
| 20:07 | <MikeSmith> | convenience |
| 20:07 | <MikeSmith> | I meant |
| 20:07 | <MikeSmith> | wifi here at Mozilla office seems not terrifically stable |
| 20:07 | <tobie> | MikeSmith: which office? |
| 20:08 | <MikeSmith> | and I'm on IRC in a persistent screen session so I drop off and some text may be buffered (or something) |
| 20:08 | <tobie> | Are you at the Testing F2F? |
| 20:08 | <MikeSmith> | tobie:yeah |
| 20:08 | <MikeSmith> | SF |
| 20:08 | <tobie> | Say hi to all these nice folks. |
| 20:08 | <MikeSmith> | the office by the Bay Bridge |
| 20:08 | <MikeSmith> | certainly will |
| 20:08 | <tobie> | ty |
| 20:09 | wilhelm | waves to tobie |
| 20:09 | <tobie> | hey |
| 20:10 | <Ms2ger> | MikeSmith, on the guest wifi? :) |
| 20:13 | <MikeSmith> | Ms2ger: yeah |
| 20:15 | <MikeSmith> | which by "guest" I guess it means it makes it de-guests you now and then so you can then enjoy the hospitality of getting re-guested anew often |
| 20:16 | <Ms2ger> | "Haven't you been on our couch for long enough now?" |
| 20:18 | <MikeSmith> | heh |
| 20:22 | <ondras> | a-ha |
| 20:22 | <ondras> | it looks like extends:"button" is the *only* way to enable <button is="my-button"> |
| 20:23 | <ondras> | otherwise I would be limited to the (not recommended) <my-button> syntax |
| 20:23 | <ondras> | although my-button inherits (prototype-wise) from HTMLButtonElement |
| 20:23 | <ondras> | http://www.polymer-project.org/platform/custom-elements.html |
| 20:43 | <MikeSmith> | ondras: oh so there is a difference |
| 20:43 | <ondras> | MikeSmith: apparently. this stuff is rather complicated, I would say. |
| 20:43 | <tobie> | Yeah. The cognitive burden is huge. But that's OK because the rest of the platform is super consistant. |
| 20:44 | <tobie> | </sarcasm> |
| 20:44 | <ondras> | .) |
| 21:01 | <smaug____> | dglazkov: yeah, I should get back to that bug, but there were other event propagation changes too, IIRC |
| 21:01 | <smaug____> | something to do with multiple shadow roots |
| 21:02 | smaug____ | tries to find that |
| 21:04 | <smaug____> | dglazkov: one problem is that I haven't see any real world case needing the current behavior |
| 21:04 | <smaug____> | perhaps I'm missing something |
| 21:05 | <smaug____> | but unless there isn't any real world case, we shouldn't complicate event propagation |
| 21:28 | <Domenic_> | I anticipate nobody using is="" because it's too ugly and inconvenient. |
| 21:29 | <Domenic_> | If possible I would make <my-button> via document.registerElement("my-button", { prototype: HTMLButtonElement.prototype }) have the same UA benefits as <button is="my-button"> via document.registerElement("my-button", { extends: "button" }) |
| 21:29 | <Domenic_> | obviously not the same UA benefits for downlevel browsers |
| 21:29 | <Domenic_> | but i think custom-element--using authors are not going to try very hard to make their stuff work there |
| 21:30 | <Domenic_> | TabAtkins: http://dev.w3.org/csswg/css-font-load-events/ 404s? |
| 21:30 | <TabAtkins> | css-font-loading |
| 21:31 | <TabAtkins> | Moved as part of the FPWD. |
| 21:32 | <Domenic_> | TabAtkins: I don't quite understand why people don't like .ready(); it seems pretty distinct from .load(). |
| 21:32 | <TabAtkins> | There's not really a need for .ready() separate from .load(). |
| 21:33 | <Domenic_> | it does give you new capabilities though, right? The ability to get notified upon loading, without actually doing the loading. |
| 21:33 | <TabAtkins> | Either you just want to check on the font, in which case you use .status, or you want to make sure it's loaded, in which case you call .load() regardless. |
| 21:33 | <Domenic_> | ok, so the idea is that getting notified upon loading without initiating loading is not a useful use case. |
| 21:33 | <TabAtkins> | I think so, yeah. |
| 21:33 | <Domenic_> | personally .load() + .loaded would make the most sense, but IIRC you can "re-load" or something so a property doesn't work... |
| 21:34 | <TabAtkins> | Nah, can't reload. |
| 21:34 | <MikeSmith> | wilhelm: are you using the Guest wifi in the f2f? |
| 21:34 | <Domenic_> | oh, then why is .ready() currently a property? |
| 21:34 | <wilhelm> | MikeSmith: Yes. |
| 21:34 | <TabAtkins> | Domenic_: ?_? |
| 21:34 | <Domenic_> | TabAtkins: err sorry, currently a method I meant |
| 21:35 | <wilhelm> | MikeSmith: "Mozilla Guest". |
| 21:35 | <TabAtkins> | Because that's usually how it works? |
| 21:36 | <Domenic_> | TabAtkins: I dunno, [citation needed]? maybe in jQuery, but they never use properties for anything. Getter or data property makes most sense to me. |
| 21:36 | <Domenic_> | Sigh, we need data properties. |
| 21:36 | <TabAtkins> | data properties? |
| 21:36 | <Domenic_> | non-accessors in WebIDL |
| 21:37 | <TabAtkins> | Still not understanding. |
| 21:37 | <MikeSmith> | wilhelm: yeah I get dropped pretty often for some reason |
| 21:37 | <Domenic_> | I am going off the rails, sorry. But: I am saying that IMO the most reasonable thing for .loaded would be as a data property. Whereas WebIDL would force it to be a getter. |
| 21:37 | <TabAtkins> | Still dont' know what "data property" means, so I cant' comment. |
| 21:38 | <Domenic_> | defineProperty(FontFaceSet.prototype, { value: readyPromise }) vs. defineProperty(FontFaceSet.prototype, { get() { return readyPromise; } }) |
| 21:38 | <Domenic_> | err |
| 21:38 | <Domenic_> | you wouldn't put it on the prototype. nevermind, ignore me. |
| 21:39 | <TabAtkins> | Okay. ^_^ |