| 09:29 | <annevk_> | http://sockpuppet.org/blog/2015/01/15/against-dnssec/ "The Internet loses nothing if it declares a TKO on DNSSEC and starts fresh. There are better DNS security proposals circulating already. They tend to start at the browser and work their way back to the roots. Support those proposals, and keep DNSSEC code off your servers." |
| 09:29 | <annevk> | However, if you tell that to the IETF they'll puke at the word browser and stop listening... |
| 10:37 | <MikeSmit1> | annevk: so we just replace the word "browser" with the word "user" there |
| 10:37 | <MikeSmit1> | And it's still the same point |
| 10:40 | <annevk> | MikeSmit1: I would be surprised if they give up on DNSSEC anytime soon |
| 10:40 | <annevk> | MikeSmit1: though with both IDNA and DNS management IETF hasn't really shined |
| 10:41 | <annevk> | MikeSmit1: or IPv6... |
| 10:42 | <annevk> | HTTP/2 is the only thing I can think of that's quite exciting |
| 11:03 | <gsnedders> | annevk: wait, what should IETF have done wrt IPv6 and IPv4 address space exhaustion? |
| 11:04 | <annevk> | It's not a matter of what, it's that the rollout isn't going very well |
| 11:05 | <gsnedders> | Well, yes. But how could the IETF have shined? I don't see anything they could've done to make that go quicker? |
| 11:06 | <annevk> | I forgot the specifics, but from what I remember there's various parts that could've been done better |
| 11:08 | <gsnedders> | Most of what's hurt the rollout for most of the time is it's taken a long while to get hardware support for IPv6 in routers, and then the consumer routers where the problem is now is simply cost-cutting to the extreme by ISPs… |
| 11:09 | <gsnedders> | Yes, IPv6 could be better in some ways. But I don't think it'd have had an appreciable difference in the rollout. |
| 11:26 | <MikeSmit1> | https://mobile.twitter.com/sideshowbarker/status/520358150583508992 |
| 11:26 | <MikeSmit1> | http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ |
| 11:27 | <MikeSmit1> | but yeah we really do need IPV6 |
| 11:27 | <MikeSmit1> | so it's a shame |
| 11:29 | <MikeSmit1> | "We have seen Windows machines with more than 300 IPv6 addresses — which, recall, means that every 150 seconds they will be transmitting 30 multicast packets per second which have to be flooded through the network." |
| 11:30 | <MikeSmith> | IPv6 "privacy" addresses |
| 11:34 | <MikeSmith> | annevk: anyway about your earlier comment, we really should just all start using some code word for "browsers", like "user-facing web clients" |
| 11:35 | <MikeSmith> | or Facing-to User Clients |
| 11:35 | <MikeSmith> | FUCs |
| 11:36 | <MikeSmith> | in discussions with IETFers |
| 11:38 | <MikeSmith> | seriously the biggest thing that distinguishes browsers from the myriad of other kinds of web clients that the IETFers always like to drag into every discussion is that browsers are user-facing, and used by billions of real people |
| 11:41 | <gsnedders> | I'M A PERSON NOT A MACHINE. |
| 11:42 | <MikeSmith> | (the myriads of other kinds of web clients that supposedly exist, according to them, and that the rest of us need to consider even though they almost never give concrete examples) |
| 11:57 | <jgraham> | Is there some common name for the combination (method, url)? |
| 11:58 | <jgraham> | When describing a HTTP API |
| 12:02 | <gsnedders> | I've seen request-line used occasionally for that, but nothing else. |
| 12:03 | jgraham | considers going with "endpoint" |
| 12:03 | <annevk> | MikeSmith: yeah, that's one of the articles |
| 12:04 | <annevk> | MikeSmith: thanks |
| 12:04 | <annevk> | jgraham: endpoint is the URL |
| 12:06 | <zcorpan> | jgraham: methurl |
| 12:10 | <jgraham> | annevk: citation needed |
| 12:14 | <annevk> | jgraham: just search? E.g. http://camel.apache.org/endpoint.html |
| 12:14 | <jgraham> | I did search and found WSDL which was a) incomprehensible and b) somewhat suggestive that it didn't mean that |
| 12:54 | hemanth | talking about ES6 generators http://youtu.be/ZrgEZykBHVo :0) |
| 13:08 | <hemanth> | annevk, caitp, Domenic_ seeking your comments on http://youtu.be/ZrgEZykBHVo thanks :o) |
| 13:09 | <annevk> | jgraham: I've always read HTTP API endpoint as URL, but might just be me |
| 13:25 | <gsnedders> | I agree with annevk about endpoint, fwiw. |
| 13:48 | <annevk> | Domenic_: so the question for ARIA is really whether elements should have access to a private ARIA API to set an initial role (and aria-* attributes?) |
| 13:49 | <annevk> | Domenic_: enabling something like that probably makes sense, I don't think we want to allow overriding e.g. <hr> (unless you create an actual subclass, once we figure out how that should work) |
| 14:32 | <annevk> | tobie: can't +1 that email enough |
| 14:35 | <tobie> | annevk: wish your +1s would drive change; Unfortunately not holding my breath. |
| 14:40 | <scott_gonzalez> | Are dialogs supposed to have forced overflow containment? |
| 14:40 | <scott_gonzalez> | http://jsbin.com/pofemovupo/1/ |
| 14:42 | <scott_gonzalez> | I didn't see anything in the spec about this and dev tools don't show any styles being applied by the user agent stylesheet that should cause this, as far as I can tell. |
| 14:42 | <scott_gonzalez> | I'm testing in Chrome, since I believe that's the only browser that supports <dialog> right now. |
| 14:44 | <annevk> | tobie: yeah... |
| 14:46 | <tobie> | :( |
| 14:46 | <annevk> | scott_gonzalez: did you study the rendering section? |
| 14:47 | <scott_gonzalez> | I didn't see anything about this relating to dialogs. |
| 14:47 | <annevk> | scott_gonzalez: there's default styling there for dialog elements |
| 14:47 | <annevk> | scott_gonzalez: dialog elements also create a top layer, which is explained in https://fullscreen.spec.whatwg.org/#top-layer |
| 14:47 | <scott_gonzalez> | Yeah, I see that, but I don't see anything that would contain the content. |
| 14:48 | <annevk> | Chrome may have bugs in that though, they have for Fullscreen and since they use the same mechanism... |
| 14:48 | <scott_gonzalez> | That's why I'm trying to find out if this is expected behavior. |
| 14:49 | <scott_gonzalez> | This surprised us (the jQuery UI team) when tooltips were applied to a native dialog. |
| 14:50 | <Domenic_> | annevk: : largely yes. States/properties need to change over time. In Chrome at least role is set at inserted-into-document time. |
| 14:50 | <annevk> | scott_gonzalez: okay, so what do you mean by overflow containment? What I'm seeing looks okay |
| 14:50 | <annevk> | scott_gonzalez: note that a top layer has this for position: "If its position property computes to fixed, its containing block is the viewport, and the initial containing block otherwise." |
| 14:50 | <Domenic_> | annevk: we'd also need to expand ARIA's vocabulary a decent bit. |
| 14:51 | <scott_gonzalez> | annevk: Refresh that page. I added a native tooltip to the custom tooltip. |
| 14:51 | <annevk> | Domenic_: makes sense, I don't really understand why ARIA is not a straight mapping of the available APIs but is instead described on some RDF-like thingie |
| 14:51 | <scott_gonzalez> | annevk: Notice how the native tooltip isn't contrained by the bounding box of the dialog. |
| 14:51 | <scott_gonzalez> | annevk: I was expecting the same from the custom tooltip since it's absolutely positioned. |
| 14:52 | <Domenic_> | annevk: I presume platform independence, although I don't know the history. |
| 14:52 | <annevk> | scott_gonzalez: isn't shrink-wrapping normal when you position something absolute that has no width? |
| 14:52 | <annevk> | scott_gonzalez: you'd need to add something like width:intrinsic, no? |
| 14:53 | <Domenic_> | annevk: it would be a good approach to look at what the intersection of accessibility APIs looks like though across platforms. Programmatic APIs instead of markup, that is. |
| 14:53 | <annevk> | Domenic_: well that bit makes sense, but there's a lot of voodoo going on |
| 14:53 | <annevk> | Domenic_: I think Steve might have done that already, or someone at least |
| 14:54 | <annevk> | Domenic_: there's an ARIA to accessibility layer mapping document somewhere |
| 14:54 | <scott_gonzalez> | annevk: The question is why is the dialog used to determine where the content wraps? |
| 14:54 | <scott_gonzalez> | annevk: `width: intrinsic` on #tooltip doesn't help. |
| 14:54 | <annevk> | scott_gonzalez: see top layer |
| 14:55 | <annevk> | scott_gonzalez: I explained that above |
| 14:55 | <annevk> | scott_gonzalez: perhaps Chrome does not support that, but if I set a width of 400px on #tooltip it works |
| 14:56 | <scott_gonzalez> | Sure, but that's not how native tooltips work. |
| 14:57 | <annevk> | scott_gonzalez: apparently there's new keywords but they're not supported: dev.w3.org/csswg/css-sizing-3/#width-height-keywords |
| 14:57 | <annevk> | scott_gonzalez: sure, but native tooltips are not implemented through absolute positioning either... |
| 14:58 | <scott_gonzalez> | annevk: Ok, let me state this another way. The top layer handling of dialogs has broken the behavior of jQuery UI tooltips. |
| 14:58 | <scott_gonzalez> | annevk: It sounds like you're saying right now there's no way to fix that. |
| 15:03 | <annevk> | scott_gonzalez: I recommend posting to either www-style or whatwg or both and asking |
| 15:03 | <scott_gonzalez> | annevk: Ok. Thanks. |
| 15:03 | <annevk> | scott_gonzalez: I'm not an expert on <dialog>, I just know how to read specs :-) |
| 15:05 | annevk | wonders where hemanth went |
| 15:54 | <Domenic_> | annevk: so I was thinking about the ARIA/overriding <hr> stuff a bit, and it reminded me one reason why callbacks are copied in on definition time |
| 15:55 | <Domenic_> | which is that e.g. if you overrode HTMLHRElement.prototype.attachedCallback, in theory that would give you an (almost-sync) callback every time a HR element is inserted into the DOM |
| 15:55 | <Domenic_> | or worse, just HTMLElement.prototype.attachedCallback |
| 15:55 | <Domenic_> | The "copying" idea is similar to saying "at start-up time, the browser grabs the value of HTMLHRElement.prototype.attachedCallback, and saves it, and calls the saved value when it inserts <hr>s" |
| 15:56 | <Domenic_> | similar to "at start up time, the browser grabs the value of window.Number, and saves it, and calls the saved value when it converts values to numbers" |
| 15:56 | <Domenic_> | The punch line being, I think a similar thing could work for ARIA callbacks (and focus, see recent conversations at https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit ) |
| 15:57 | <annevk> | Domenic_: how does that help custom elements though? |
| 15:57 | <annevk> | Domenic_: oh, we'd still expose some API to custom elements for having non-overrideable roles? |
| 15:58 | <Domenic_> | So you could let custom elements define e.g. implicitAriaLabel() and strongAriaRole() or implicitAriaRole() just like they define attachedCallback() |
| 15:58 | <Domenic_> | And you'd put those same methods on HTMLHRElement |
| 15:58 | <Domenic_> | but you'd have no problem saying "if you override HTMLHRElement.prototype.strongAriaRole(), we're going to ignore it." |
| 15:58 | <Domenic_> | same as if you change MyCustomEl.prototype.attachedCallback after registration time, we ignore it |
| 15:59 | <Domenic_> | They stick around on the prototype because they're still relatively useful (for subclasses to call, or in other scenarios) but the original value is saved away |
| 16:02 | <Domenic_> | It's similar to saying, "HTMLHRElement.prototype.align is a getter that returns `this.getAttribute("align")`, but it makes sure to use the saved value of HTMLElement.prototype.getAttribute instead of just calling it directly." |
| 16:02 | <Domenic_> | I should write all this up |
| 16:13 | <caitp> | hemanth: re the promise talk, have you watched jafar husain's talks on it? he's pretty good at conveying the message of es6/7/etc control patterns |
| 16:14 | <annevk> | Domenic_: yes I see now |
| 16:14 | <annevk> | Domenic_: could they not just be data properties in that case? |
| 16:14 | <annevk> | Domenic_: a role is just a string after all |
| 16:16 | <annevk> | Domenic_: also, did you see all the email? I think we should at least explore "Jonas" a bit more before we go with "Dmitry" |
| 16:17 | <Ms2ger> | Planning your dates, huh |
| 16:18 | <annevk> | We named the Upgrade alternatives after those who came up with them, see the wiki |
| 16:24 | <Domenic_> | annevk: role changes, e.g. <a> vs. <a href> |
| 16:25 | <annevk> | c |
| 16:25 | <Domenic_> | annevk: yeah saw the email. Willing to explore Jonas, certainly. |
| 16:25 | <SteveF_> | annevk: Domenic: HTML Accessibility API Mappings 1.1 http://rawgit.com/w3c/aria/master/html-aam/html-aam.html may be helpful |
| 16:26 | <Domenic_> | SteveF_: yeah, I'm also curious about what the actual a11y *APIs* look like on various platforms, not just the strings involved... |
| 16:27 | <annevk> | Domenic_: 4.3.2 has that, no? |
| 16:27 | <SteveF_> | Domenic: http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#dfn-accessibility-api links to acc apis |
| 16:27 | <annevk> | Domenic_: oh you mean how the roles get conveyed? |
| 16:27 | <Domenic_> | SteveF_: perfect, never found that section before |
| 16:27 | <Domenic_> | annevk: yeah I mean the actual OS function calls I am curious about |
| 16:28 | <Hixie> | scott_gonzalez: the default styles for <details> are intentionally pretty minimal |
| 16:28 | <Hixie> | scott_gonzalez: but if there's something dumb that we overlooked we can definitely add more |
| 16:28 | <Hixie> | scott_gonzalez: mail whatwg@ or file a bug (whatwg.org/newbug) or something |
| 16:28 | <Domenic_> | For example http://msdn.microsoft.com/en-us/library/ms697291%28v=vs.85%29.aspx is interesting |
| 16:35 | <annevk> | Domenic_: also, for element-constructors, I was thinking of creating a pull request to add an SVG example |
| 16:35 | <annevk> | Domenic_: people asked about it on Twitter, makes sense to cover it |
| 16:36 | <annevk> | Domenic_: but yeah, main thing I wanted to ask is how we could best evaluate the different Upgrade strategies to get everyone on the same page so we can move on with Apple on board |
| 17:21 | <Domenic_> | annevk: yeah, would be good to do SVG as well, I agree. Should probably end up parallel to HTMLElement but I might be missing some stuff. |
| 17:22 | <Domenic_> | annevk: the biggest issue with "Jonas" I see is it doesn't cover upgrades. Which I think are important because async modules. You end up needing a second story for upgrades. |
| 17:23 | <Domenic_> | annevk: quoting from his post, "While parsing, when you hit a custom element (with a constructor)" the point of the upgrade case is when you don't have a constructor when parsing, but a few seconds later you do |
| 17:24 | <annevk> | Domenic_: the question is whether upgrades need to be coupled |
| 17:24 | <Domenic_> | say more? |
| 17:25 | <annevk> | Domenic_: we could ship almost-synchronous now and have the upgrade bit be polyfilled until something like "HTML modules" emerges |
| 17:26 | <annevk> | Domenic_: which might very well emerge based on experimenting with JS modules, the loader API, and all the other new goodness over there |
| 17:26 | <Domenic_> | so you are saying that almost-synchronous is really almost-synchronous + dummy-replacement? |
| 17:26 | <annevk> | Domenic_: or e.g. you async load your JS module and a blob of HTML |
| 17:26 | <annevk> | Domenic_: then once the JS module is ready you parse the blob of HTML |
| 17:27 | <Domenic_> | Yes, if you don't want to write your HTML in .html files, upgrading is not needed, I agree. |
| 17:27 | <annevk> | Domenic_: I'm saying it's almost-synchronous + something in v2 |
| 17:27 | <Domenic_> | It feels like we should have all the information now to nail down what "something" is |
| 17:28 | <annevk> | Domenic_: I think wycats is correct that :unresolved is a poor mans fallback |
| 17:28 | <annevk> | Domenic_: and that typically you want to include a rather large set of custom elements (name it a module...) |
| 17:29 | <annevk> | Domenic_: and that while that module is loading you want fallback covering it all |
| 17:29 | <Domenic_> | That all makes sense. I think we should nail that down though if we want to go that route, instead of saying "we'll figure it out later" |
| 17:31 | <Domenic_> | I also think it could be layered on top of Dmitry just as well as it could be layered on top of Jonas though. The benefit of Jonas being that you write `constructor(...args) { super(...args); /* code here */ }` instead of `[Element.create]() { /* code here */ }` is not too compelling to me. (But apparently is mandatory for rniwa?) |
| 17:31 | <annevk> | Domenic_: it seems hard to nail down ahead of time, with loader not being done and modules not having landed |
| 17:31 | <Domenic_> | We know roughly how loaders work and if there are specific features we need from them we can demand them |
| 17:32 | <Domenic_> | Better to co-evolve than wait until it's nailed down and find out it doesn't solve our use case |
| 17:32 | <annevk> | that is fair |
| 17:33 | <Domenic_> | Layering on top of Dmitry instead of on top of Jonas has the benefit that Dmitry gives a no-thinking-required solution for out of the box work. I agree that something along the lines of wycats's solution is going to be nicer for more complex apps though. Unsure what the split is, e.g. could be anywhere from 80/20 to 20/80. |
| 17:34 | <annevk> | That seems worth figuring out. I guess I'm going to ask rniwa on list to clarify that only Jonas works for Apple |
| 17:34 | <Domenic_> | I do want to be cautious of saying that just because Chrome/Polymer works with something simple-ish (similar to, but worse than, Dmitry) that it is OK for the majority of apps. That isn't proven in my mind. |
| 17:35 | <annevk> | If you ask Facebook they'll just say no :-( |
| 17:35 | <Domenic_> | Right, that's good feedback to keep in mind |
| 17:35 | <Domenic_> | Their concerns IIRC are more around the global namespacing (which wycats' proposal also seems to contain a hint of solving) |
| 17:35 | <annevk> | I emailed a bit with React and talked with some folks at Mozilla that are into it; they have very different ideas |
| 17:35 | <wycats> | Yes confirm :) |
| 17:35 | <wycats> | Interesting |
| 17:35 | <Domenic_> | But then again their model is so different (immutable state etc.) that I'm not sure they're even in the room. |
| 17:36 | <annevk> | Right, the only use they see for custom elements is for if you want to do things between frameworks |
| 17:36 | <annevk> | If you're exclusively React it's not needed |
| 17:36 | <Domenic_> | I am curious if people write things in .html files when using React. |
| 17:36 | <wycats> | My thinking is largely around how granularly "unrendered" loading UI should be |
| 17:37 | <wycats> | Per-element seems OK for google +1 buttons and bad for apps |
| 17:37 | <wycats> | Domenic_: they do not |
| 17:37 | <annevk> | Domenic_: I believe you write the tree as JS plus constraints which then generates a DOM for view |
| 17:37 | <wycats> | They are strongly opposed to the concept of separate HTML |
| 17:38 | <Domenic_> | brb, somehow freenode is confused and I can't get rid of this underscore. |
| 17:38 | <wycats> | Ember's view is actually interesting here: we treat HTML as a DSL for building DOM but are very careful to obey HTML's semantics |
| 17:38 | <wycats> | So we parse the HTML on the server and use createElement and friends |
| 17:39 | <Domenic> | (that was easier to fix than I thought it would be. Goodbye underscore.) |
| 17:39 | <wycats> | Which means that the way we want to deal with custom elements is actually not even in the parser |
| 17:39 | <wycats> | We want createElement to work (which it does of course) |
| 17:39 | <wycats> | Our goal is to be largely indistinguishable from what the browser would do |
| 17:39 | <wycats> | We're a bit of an implementation in that respect |
| 17:40 | <Domenic> | Similar to react though in that people don't write in .html files |
| 17:40 | <Domenic> | Honestly I don't like writing in .html files myself |
| 17:40 | <Domenic> | But it seems important to support |
| 17:41 | <wycats> | https://github.com/tildeio/simple-html-tokenizer |
| 17:41 | <annevk> | Domenic: XHTML 2.0! |
| 17:41 | <wycats> | Domenic: it's a little different than react |
| 17:42 | <Domenic> | wycats: definitely different but in terms of whether it needs upgrading or not, neither do |
| 17:42 | <wycats> | We have separate template files that are supposed to be "as if" HTML |
| 17:42 | <wycats> | yes 100% |
| 17:42 | <wycats> | Domenic: we've been talking a lot about adding {{import}} to top-level templates in Ember |
| 17:42 | <wycats> | That's where I got the idea |
| 17:43 | <wycats> | There's also a lot of desire for scoped imported elements |
| 17:43 | <wycats> | (You mentioned it above) |
| 17:44 | <wycats> | So one question is: if the use cases for bare .HTML are things like Facebook like buttons, maybe it's OK to do pure DOM replacement there |
| 17:44 | <wycats> | And not worry too much about brain transplants |
| 17:44 | <wycats> | But if you're scoped inside of some container, you are saved from both DOM replacement and brain transplants |
| 17:45 | <wycats> | (iow apps shouldn't mind the extra scoping... they pretty much already need it anyway) |
| 17:46 | <Domenic> | I think the use cases for bare .html are much bigger than that |
| 17:46 | <Domenic> | they're for less-ambitious apps that want to use non-native components, given that the components built in to HTML are very limited |
| 17:47 | <Domenic> | <tabset>, <google-map>, etc. are all useful even on "brochure" sites |
| 17:48 | <wycats> | But surely they can wrap in some element |
| 17:48 | <wycats> | I see the situation as somewhat analogous to modules in es6 |
| 17:48 | <Domenic> | Yes, the ywrap in <html> |
| 17:49 | <wycats> | There's a bit more verbosity but it makes everything far more predictable |
| 17:49 | <Domenic> | But they want their site to load and then <google-map> to load later. |
| 17:49 | <wycats> | Domenic: we could add an async global attr for custom elements? |
| 17:50 | <wycats> | async is wrong |
| 17:50 | <wycats> | Since everything is non-blocking |
| 17:51 | <Domenic> | wycats: the problem is all of this "just works" with Dmitry. Why make it more complicated for people building sites like that, if the only benefit is writing `constructor(...args) { super(...args); /* code here */ }` instead of `[Element.create]() { /* code here */ }` |
| 17:51 | <annevk> | Domenic: what does instanceof do with the Dmitry design? |
| 17:51 | <Domenic> | annevk: works great, no tricks needed. Since the constructor you pass in is the real constructor. |
| 17:52 | <annevk> | Domenic: even for markup-created elements? |
| 17:52 | <Domenic> | annevk: yep, because __proto__-munging in that case |
| 17:52 | <annevk> | Domenic: wait what? We keep __proto__ munging? |
| 17:52 | <wycats> | Domenic: the problem with brain transplants is beyond ^^ |
| 17:52 | <Domenic> | same reason instanceof works in Chrome today, except today you have to do `instanceof ReturnedC` instad of `instanceof PassInC` |
| 17:52 | <annevk> | Domenic: I did not realize that :-( |
| 17:53 | <wycats> | I think it's a common case you want a loading spinner not a bunch of elements "popping in" |
| 17:53 | <Domenic> | annevk: yes, you are essentially emulating the ES [[Construct]] algorithm which itself does proto-munging |
| 17:53 | <annevk> | eww |
| 17:53 | <wycats> | It's not so bad ;) |
| 17:54 | <wycats> | Domenic: I guess I just think "popping in" UIs are amateur hour |
| 17:54 | <wycats> | And I don't think the unknown element pseudo does enough to mitigatr |
| 17:54 | <wycats> | You know what I mean? |
| 17:54 | <Domenic> | I mean, it's worked for Angular for years |
| 17:54 | <wycats> | Nah |
| 17:54 | <wycats> | They have ng-cloak |
| 17:55 | <dglazkov> | if you don't use the HTML parser (that is, use it only as a bootstrapping device), you don't need upgrades -- this is true, btw. |
| 17:55 | <wycats> | Which is semi sort of analogous to what I'm talking about |
| 17:55 | <Domenic> | I see the desire for a better solution, but I think we still want it to work out of hte box |
| 17:55 | <Domenic> | Yeah, ng-cloak is just a worse version of :unresolved |
| 17:55 | <Domenic> | it is one you have to manually insert |
| 17:55 | <wycats> | Except it can be applied at a coarser grain |
| 17:55 | <dglazkov> | and "UI popping in" is orthogonal to the upgrades. |
| 17:56 | <wycats> | It's orthogonal to upgrades but not orthogonal to the loading story |
| 17:56 | <wycats> | Which is key here |
| 17:56 | <Domenic> | dglazkov: how so exactly orthogonal to the upgrades? What I think of by "UI popping in" is the upgrade from <google-map> = HTMLElement to full-fledge <google-map> |
| 17:56 | <wycats> | Domenic: I think it's only orthogonal in a narrow sense |
| 17:56 | <dglazkov> | the upgrades are really about consistency of how you deal with avoiding to block HTML parser and yielding |
| 17:57 | <Domenic> | Hmm I think of upgrades as answering the question "I wrote <google-map> in my .html file but it took 2 seconds on a slow mobile network to load google-map.js" |
| 17:57 | <wycats> | that's pretty related to "popping in" |
| 17:57 | <wycats> | yes |
| 17:57 | <wycats> | I agree |
| 17:58 | <wycats> | Domenic: I think the issue is that for things like <google-map> you definite want async + "pop in" |
| 17:58 | <Domenic> | I guess maybe dglazkov |
| 17:58 | <wycats> | and if you're careful, you'll use CSS to give it the right size so it doesn't affect layout |
| 17:58 | <wycats> | but in apps, where you have 20-30 or even more custom elements |
| 17:58 | <wycats> | you really don't want to have to fine-tune ::unresolved per element |
| 17:58 | <Domenic> | 's point is that there are two upgrade scenarios: one where google-map.js is already loaded, and you want to worry about not blocking the HTML parser to run user code, and one where google-map.js will be loaded in the future. |
| 17:58 | <wycats> | you just want to show a spinner, and wait for the elements to load |
| 17:59 | <wycats> | yes, I think the former is legitimate but may be easy to mitigate |
| 17:59 | <Domenic> | "easy", but yes |
| 17:59 | <wycats> | iow, it may be possible to avoid leaking the internals |
| 17:59 | <wycats> | I meant to say "easy" |
| 17:59 | <wycats> | in quotes :P |
| 17:59 | <wycats> | I see that as an important, but less critical aspect of this problem |
| 18:00 | <wycats> | I understand why it's important to work out, but I think the "correct answer" will be driven by the other half of the problem |
| 18:00 | <dglazkov> | the reason I view these as orthogonal, because this is something you need to solve with our without custom elements or upgrades |
| 18:00 | <Domenic> | +1 |
| 18:00 | <Domenic> | this is really a general problem of UI management |
| 18:00 | <Domenic> | it is unclear why it should be coupled to custom elements |
| 18:00 | <wycats> | Domenic: so an analogy is |
| 18:00 | <Domenic> | as opposed to e.g. custom elements giving you a hook, just like any other library |
| 18:00 | <Domenic> | maybe :unresolved is not a good enough hook |
| 18:01 | <wycats> | before ES6 modules, globals were just totally imperative |
| 18:01 | <wycats> | and you just ran code |
| 18:01 | <Domenic> | but you probably want a framework for displaying "loading" vs. "ready" content that goes waaaay beyond custom elements |
| 18:01 | <wycats> | and had to externally manage the order that things were loaded in |
| 18:01 | <wycats> | you could make it work |
| 18:01 | <wycats> | but it was very clunky and not quite right |
| 18:01 | <wycats> | ES6 modules let you say "this code DEPENDS on this other code" |
| 18:01 | <wycats> | "so please go get the other code before you bother trying to execute me" |
| 18:01 | <wycats> | and it's a huge ergonomic improvement to the programming model |
| 18:02 | <wycats> | even though in theory it was possible to fudge before (using, for example, AMD) |
| 18:02 | <wycats> | I'm saying roughly an equivalent problem exists here |
| 18:02 | <wycats> | and as in ES6 modules, it's a little more annoying if you're dealing with tiny amounts of code |
| 18:02 | <wycats> | but much less annoying if you're dealing with an "app" |
| 18:03 | <Domenic> | This kind of ties back to Hixie's declarative dependency stuff IMO |
| 18:04 | <wycats> | Domenic: I agree 100% |
| 18:04 | <Domenic> | You want a general mechanism of delaying showing some part of the UI until a variety of promises fulfill |
| 18:04 | <wycats> | yes |
| 18:04 | <wycats> | I think you want to keep it entirely inert, though |
| 18:04 | <Domenic> | that sounds better, yes |
| 18:04 | <Domenic> | But in general IMO as long as the relevant custom elements stuff exposes the relevant promise then it can tie into this more general framework |
| 18:04 | <wycats> | I don't necessarily agree with Hixie's precise proposal, but I agree that at a high-level he's on to something |
| 18:04 | <wycats> | Domenic: not necessarily if you want them to be inert |
| 18:05 | <Domenic> | So maybe the takeaway here is that you want some kind of promise-returning `document.whenElementRegistered("my-tag")` |
| 18:05 | <wycats> | interesting |
| 18:05 | <Domenic> | Then maybe later high-level markup syntax like <blahblah inert-until-registered="my-tag my-other-tag"> |
| 18:05 | <wycats> | yes |
| 18:05 | <wycats> | I think that sounds like a good stab |
| 18:06 | <wycats> | (I like both attr-based deps and inner-tag based deps because trying to cram multiple imports into an attribute could be crazy) |
| 18:06 | <wycats> | (but that's a surface detail) |
| 18:06 | <Domenic> | sure yeah |
| 18:06 | <wycats> | Domenic: I think Hixie is onto something about this not being just about custom elements |
| 18:06 | <Domenic> | dglazkov was the one who drove that home for me ten minutes ago :) |
| 18:06 | <wycats> | I think linking it in to ES6 modules is the way to go (I think you've mentioned this in the past) |
| 18:07 | <wycats> | so you're importing a Module that maybe exports a default tag or multiple named tags |
| 18:07 | <wycats> | something like that |
| 18:08 | <Domenic> | yeah that would be nice |
| 18:08 | <Domenic> | builds on potentially scoped registrations |
| 18:08 | <wycats> | c |
| 18:10 | <wycats> | so I think our options for upgrade are: |
| 18:10 | <wycats> | 1) decide to run constructors synchronously |
| 18:10 | <wycats> | 2) run constructors asynchronously, but not observably so |
| 18:10 | <wycats> | 3) brain transplant |
| 18:10 | <wycats> | 4) DOM replacement |
| 18:11 | <Domenic> | 1) is not an option for upgrade |
| 18:11 | <Domenic> | it is something you could do if you combined with 4) |
| 18:11 | <wycats> | 5) only update the prototype (this doesn't feel like a real option) |
| 18:11 | <wycats> | well... |
| 18:11 | <Domenic> | 1) is basically saying "no upgrades" |
| 18:11 | <wycats> | I'm saying you could decide you don't need upgrade at all if you have the element |
| 18:11 | <wycats> | yes |
| 18:12 | <Domenic> | bbl lunch |
| 18:12 | <wycats> | bbl company offsite :) |
| 18:36 | <annevk> | tobie: the whole silo setup also doesn't work the moment you start doing the thing where you let one app talk to the SW of another app |
| 18:37 | <annevk> | tobie: because in a world of silos, only the app itself will ever have a SW |
| 18:37 | <tobie> | the whole silo setup just doesn't work |
| 18:37 | <annevk> | tobie: it's just fundamentally broken |
| 18:37 | <annevk> | right :-) |
| 18:37 | <tobie> | yes |
| 18:38 | <annevk> | this is what we get letting old man like mounir__ be in charge of stuff |
| 18:38 | <Ms2ger> | Could be worse |
| 18:38 | <Ms2ger> | Could've been marcosc :) |
| 18:40 | <mounir> | annevk: who is that mounir__ guy? |
| 18:41 | <annevk> | mounir: wouldn't you want to know? :p |
| 19:10 | <annevk> | Domenic: wycats: sounds great, hopefully we can flush this out and make it work |
| 19:10 | <wycats> | annevk: I'm excited |
| 19:11 | <annevk> | Domenic: I continue to be excited by the element constructor project too, I guess I still need to wait a bit with specifying the thing :-) |
| 19:11 | <wycats> | we're pretty close with subclassing |
| 19:12 | <Domenic> | annevk: :D it is pretty close I think. Also once ES6 classes ship in V8 I will prototype it in jsdom. |
| 19:24 | <dglazkov> | just to un-mumble something I said earlier: upgrades are a performance primitive when you have non-blocking script and parser that yields. |
| 19:25 | <dglazkov> | with upgrades, the non-blocking script could execute during a yield, register elements, and keep on going. The chunk of html that was parsed previously will upgrade, and the chunk that hasn't yet parsed will start queueing callbacks. |
| 19:26 | <dglazkov> | without upgrades, you as a developer are highly incentivized to reduce the amount of html after your non-blocking script, because you need to wait until the doc parsed completely until you can sensibly run the script. |
| 19:39 | <wycats> | dglazkov: have you seen my (very syntactically strawman) POV? |
| 19:39 | <wycats> | my POV is largely about making it possible to increase the granularity of upgrade |
| 19:39 | <wycats> | so you're not upgrading individual elements, but rather chunks of markup |
| 19:42 | <dglazkov> | I am open to concrete proposals. It took a while to shake all the kinks out of mine, so I apologize for being weary. It's a human thing. |
| 20:24 | <annevk> | dglazkov: I really appreciate how positive you are actually |
| 20:38 | <jsbell> | ms2ger: Do I need to do anything more with https://critic.hoppipolla.co.uk/r/3723 at the moment, or is it just waiting for reviewers to have cycles? |
| 20:39 | <annevk> | jsbell: yeah, sorry |
| 20:39 | <Ms2ger> | jsbell, yeah, just needs review |
| 20:39 | <Ms2ger> | jsbell, please badger us :) |
| 20:39 | <annevk> | jsbell: you could address the issues I suppose, but mostly it needs more eyes |
| 20:39 | <Ms2ger> | annevk, no open issues :) |
| 20:39 | <annevk> | ooh |
| 20:40 | <jsbell> | :) Just didn't want it to be blocked on me hitting a button or something |
| 20:40 | <annevk> | Ms2ger: remind me Monday and I'll just do it, custom elements is making good progress :-) |
| 20:40 | <Ms2ger> | annevk, will try :) |
| 20:42 | Ms2ger | just reviewed a -7+7 fixup from last July :/ |