Re: [Bug 25376] - Web Components won't integrate without much testing

On May 23, 2014 10:18 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
> On Tue, May 20, 2014 at 8:41 PM, Axel Dahmen <brille1@hotmail.com> wrote:
> > I got redirected here from a HTML5 discussion on an <IFrame>'s SEAMLESS
> > attribute:
> >
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25376
> >
> > Ian Hickson suggested to publish my findings here so the Web Components
team
> > may consider to re-evaluate the draft and probably amending the spec.
>
> Could you post your findings here?

Replying to the points from the bug, quoted by Tab below ...



>
> Digging through the bug thread, it appears you might be talking about
this:
>
> > Web Components require a plethora of additional browser features and
behaviours.
> >
Natively though, that seems a good thing to me..

> > Web Components require loads of additional HTML, CSS and client script
code for displaying content.
> >
How? CSS seems the same either way, html could actually be significantly
lessened and script is dependent on what you actually want to do.  If it's
just "a fragment" js for a single fragment element would potentially serve
many and you can describe declaratively a lot.


> > Web Components install complex concepts (e.g. <decorators>) by
introducing unique, complex, opaque behaviours, abandoning the pure nature
of presentation.

> >
Decorators were dropped last i checked, but many of the new features create
a lightweight alternative to iframes and, again, give us, new powers to
create.


> > Web Components require special script event handling, so existing
script code cannot be reused.

Depends, but possibly.  Can you provide a specific that works better with
iframes in this regard.

> > Web Components require special CSS handling, so existing CSS cannot be
reused.
> >
Same comment as above..



> > Web Components unnecessarily introduce a new clumsy “custom”, or
“undefined” element, leaving the path of presentation. Custom Elements
could as easy be achieved using CSS classes, and querySelector() in ECMA
Script.
> >
Definitely not, because as you say, we add new mechanisms to treat Custom
Elements (note title casing) as first class things with a known lifecycle,
larger meaning etc.  you could visually and interactively achieve similar
results from a user perspective potentially, and nothing prevents you going
forward from maintaining this mentality for your use.  What that approach
doesn't give you is a universal means to declaratively share these with
scores of users who don't have to understand all that and for the community
to participate easily in finding out what actually works for us instead of
spending years in a committee to debate about things only to find out that,
after all, it doesn't.



> > The W3C DOM MutationObserver specification already provides
functionality equivalent to
insertedCallback()/readyCallback()/removeCallback().
>
MutationObservers, I believe, are neutral spec-wise on the point of when
they fire in terms of parsing (I think), but regardless of the spec, at
least Mozilla does not fire them during parse.  That turns out to be a
pretty big deal actually.  Ideally, though, we should be connecting APIs
and layering them atop one another so just because this is possible with
another API does not make it a bad thing.



> Is this correct?  Is this the full list of comments you wish to make?
>
> ~TJ
>