RE: Custom elements contentious bits
From: Brian Kardell [mailto:bkard...@gmail.com]
> I'd really like to understand where things really are with async/sync/almost
> sync - does anyone have more notes or would they be willing to provide more
> exlpanation? I've read the linked contentious bit and I'm still not sure
> that I understand.
The question is essentially about at what time the custom element callbacks are
being called. There are three possible times:
1. Synchronously, i.e. from within the middle of the DOM Standard's relevant
algorithms/from within browser C++ code, we call out to JavaScript. There is
then no queuing.
2. "Nanotask" timing, i.e. right before exiting C++ code and returning back to
JS, we call out to queued JS.
3. Microtask timing, i.e. we put the callbacks on the standard microtask queue,
letting any JS run to completion before running the microtasks.
The difference between 1 and 2 is very subtle and shows up only rarely, in
complicated algorithms like cloning or editing. 3 is what you would more
traditionally think of as "async".
> I can say, for whatever it is worth, that given some significant time now
> (we're a few years in) with web component polyfills at this point I do see
> more clearly the desire for sync. It's unintuitive at some level in a world
> where we (including me) tend to really want to make things async but if I am
> being completely honest, I've found an increasing number of times where this
> is a actually little nightmarish to deal with and I feel almost like perhaps
> this might be something of a "least worst" choice. Perhaps there's some
> really good ideas that I just haven't thought of/stumbled across yet but I
> can tell you that for sure a whole lot of frameworks and even apps have their
> own lifecycles in which they reason about things and the async nature makes
> this very hard in those cases.
I'm not really sure what you're talking about here. Is it something besides
Chrome's web components, perhaps some unrelated framework or polyfill? Chrome's
web components have always used (2), which is not really async in any
meaningful sense.
> Shadow DOM will definitely help address a whole lot of my cases because it'll
> hide one end of things, but I can definitely see cases where even that
> doesn't help if I need to actually coordinate. I don't know if it is really
> something to panic about but I feel like it's worth bringing up while there
> are discussions going on. The declarative nature and the seeming agreement
> to adopt web-component _looking_ tags even in situations where they are not
> exactly web components makes it easy enough to have mutually agreeing
> "enough" implementations of things. For example, I currently have a few
> custom elements for which I have both a "native" definition and an angular
> directive so that designers I know who write HTML and CSS can learn a
> slightly improved vocabulary, say what they mean and quickly get a page setup
> while app engineers can then simply make sure they wire up the right
> implementation for the final product. This wasn't my first choice: I tried
> going purely native but problems like the one described above created way too
> much contention, more code, pitfalls and performance issues. In the end it
> was much simpler to have two for now and reap a significant portion of the
> benefit if not the whole thing.
This is a bit off-topic but...
As you point out, the main benefit of custom elements is not that you can use
custom tag names in your markup---that is easily accomplished today. The
benefits are being able to use the DOM API on the resulting tree
(document.querySelector("my-custom-el").myCustomMethod()) and, most
importantly, lifecycle callbacks. If you want lifecycle callbacks with a
third-party framework, you must let that framework control your page lifecycle.
The things Angular does to ensure this are horrendous, e.g. monkeypatching
every DOM method so that it can know when certain lifecycle events happen.
Letting the browser simply call out to author-supplied callbacks when it's
already doing work is going to be much nicer.
> Anywho... I'm really curious to understand where this stands atm or where
> various companies disagree if they do.
Since nobody is proposing 3, where we stand now is that there seems to be a
disagreement between 1 and 2. I don't really understand the advantages of 1
over 2, but I do believe Apple still prefers 1. It would be great to hear more.
Re: Custom elements contentious bits
On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola <d...@domenic.me> wrote: > A bit ago Jan put together an initial draft of the "contentious bits" for > custom elements, in preparation for our January F2F. Today I went through and > expanded on the issues he put together, with the result at > https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits. > It morphed into a kind of agenda for the meeting, containing "Previously > contentious bits", "Contentious bits", "Other things to work out", and "Other > issues worth mentioning". > > It would be lovely if other vendors could take a look, and fill in anything > they think is missing, or correct any inaccuracies. So my impression is that Apple is still in favor of synchronous construction. Talking to developers from Ember.js they care about that too (to the extent they even think this problem is worthwhile solving). The "upgrade" problem is a more general problem we also have with service workers and such. There's some kind of boostrapping thing that might warrant a more general solution. Would be great to have some cards on the table. And with respect to that, Mozilla is interested in shipping Shadow DOM. We continue to have concerns with regards to lack of integration with the HTML Standard, but hope those will get resolved. Custom elements is less of a priority for us at this point, so we're not sure what to make of this meeting if things are still up in the air. -- https://annevankesteren.nl/
Re: Custom elements contentious bits
On Thu, Dec 10, 2015 at 3:23 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola <d...@domenic.me> wrote: > > A bit ago Jan put together an initial draft of the "contentious bits" > for custom elements, in preparation for our January F2F. Today I went > through and expanded on the issues he put together, with the result at > https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits. > It morphed into a kind of agenda for the meeting, containing "Previously > contentious bits", "Contentious bits", "Other things to work out", and > "Other issues worth mentioning". > > > > It would be lovely if other vendors could take a look, and fill in > anything they think is missing, or correct any inaccuracies. > > So my impression is that Apple is still in favor of synchronous > construction. Talking to developers from Ember.js they care about that > too (to the extent they even think this problem is worthwhile > solving). The "upgrade" problem is a more general problem we also have > with service workers and such. There's some kind of boostrapping thing > that might warrant a more general solution. > > Would be great to have some cards on the table. > > And with respect to that, Mozilla is interested in shipping Shadow > DOM. We continue to have concerns with regards to lack of integration > with the HTML Standard, but hope those will get resolved. Custom > elements is less of a priority for us at this point, so we're not sure > what to make of this meeting if things are still up in the air. > > > -- > https://annevankesteren.nl/ > > I'd really like to understand where things really are with async/sync/almost sync - does anyone have more notes or would they be willing to provide more exlpanation? I've read the linked contentious bit and I'm still not sure that I understand. I can say, for whatever it is worth, that given some significant time now (we're a few years in) with web component polyfills at this point I do see more clearly the desire for sync. It's unintuitive at some level in a world where we (including me) tend to really want to make things async but if I am being completely honest, I've found an increasing number of times where this is a actually little nightmarish to deal with and I feel almost like perhaps this might be something of a "least worst" choice. Perhaps there's some really good ideas that I just haven't thought of/stumbled across yet but I can tell you that for sure a whole lot of frameworks and even apps have their own lifecycles in which they reason about things and the async nature makes this very hard in those cases. Shadow DOM will definitely help address a whole lot of my cases because it'll hide one end of things, but I can definitely see cases where even that doesn't help if I need to actually coordinate. I don't know if it is really something to panic about but I feel like it's worth bringing up while there are discussions going on. The declarative nature and the seeming agreement to adopt web-component _looking_ tags even in situations where they are not exactly web components makes it easy enough to have mutually agreeing "enough" implementations of things. For example, I currently have a few custom elements for which I have both a "native" definition and an angular directive so that designers I know who write HTML and CSS can learn a slightly improved vocabulary, say what they mean and quickly get a page setup while app engineers can then simply make sure they wire up the right implementation for the final product. This wasn't my first choice: I tried going purely native but problems like the one described above created way too much contention, more code, pitfalls and performance issues. In the end it was much simpler to have two for now and reap a significant portion of the benefit if not the whole thing. Anywho... I'm really curious to understand where this stands atm or where various companies disagree if they do. -- Brian Kardell :: @briankardell
Re: Custom elements contentious bits
Domenic, Closed shadow DOM and its impact on test automation and auditing is also a very important issue. --Dylan On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola <d...@domenic.me> wrote: > Hi all, > > A bit ago Jan put together an initial draft of the "contentious bits" for > custom elements, in preparation for our January F2F. Today I went through > and expanded on the issues he put together, with the result at > https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits. > It morphed into a kind of agenda for the meeting, containing "Previously > contentious bits", "Contentious bits", "Other things to work out", and > "Other issues worth mentioning". > > It would be lovely if other vendors could take a look, and fill in > anything they think is missing, or correct any inaccuracies. > > Over all I'm pretty optimistic that we've narrowed this down to a small > set of issues and will be able to make progress at the F2F. > > -- Download FireEyes Free: http://getfireeyes.com/ Life is ten percent what happens to you and ninety percent how you respond to it. - Lou Holtz
