Re: Custom elements contentious bits

On Thu, Dec 10, 2015 at 3:23 PM, Anne van Kesteren <annevk@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