On May 23, 2014 10:18 AM, "Tab Atkins Jr." <jackalm...@gmail.com> wrote: > > On Tue, May 20, 2014 at 8:41 PM, Axel Dahmen <bril...@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 >
