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