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

Excuse my unsolicited comment here, being new to the webapps mailing list,
but here is my two cents feedback as a web developer...

I think the idea behind Web Components is good regardless of the flaws on
the spec. The idea is to create a standard built into the browser that will
allow library--and framework--free, mass distribution of reusable
components. Today, we can build components, without half broken stuff like
iframes, using JS/CSS isolation patterns. So the issue IMO is not about
doing something we couldn't do already, but standardizing the way things
are done so that we can have the ability to build and share components
without dependency on a certain library (e.g. jQuery) or framework (e.g.
Angular)

Marc





On Thu, May 29, 2014 at 4:05 AM, Axel Dahmen <brille1@hotmail.com> wrote:

> Yes, Tab, your below summary is correct.
>
> First, let me (again) stress the fact that my intention is NOT to give a
> critical judgment on Web Components.
>
> Many ways lead to Rome. Web Components is one way of implementing discrete
> components into a web page. And the HTML IFRAME element is just another. I
> wouldn't want to keep anyone from walking his way as long as I'm left to go
> mine.
>
> My sole intention (still) is to have the SEAMLESS attribute of the HTML
> IFRAME element amended for the given reasons. So I'm examining Web
> Components from this single perspective here. I'm not targeting on
> improving Web Components; I'm also not targeting to discuss Web Components
> when used in XML here, just HTML. So my wording here will not be a
> constructive one but one comparing advantages/disadvantages of one approach
> compared to the other within this constrained environment.
>
> So now here's an elaboration to my list:
>
>
> ========================
>
>  Web Components require a plethora of additional browser features and
>> behaviours. <
>>
>
> Everything Web Components promise to provide already exists (e. g. by
> using HTML IFRAME elements). So any effort put into developing or using Web
> Components is a wasted amount of time because it'd just recreate existing
> features while bloating browser engine code, making the engine more
> sluggish and error prone.
>
> Moreover, Web Components put a hard load on client engines, requiring them
> to support a whole bunch of features flawlessly, making it a hell for
> programmers to test their websites against different browsers. Whereas HTML
> IFRAME elements just display arbitrarily simple HTML pages served by a
> single web server. Any server code displaying static data can be assumed to
> display the data correctly on all browsers when successfully tested once.
>
>
> ========================
>
>  Web Components require loads of additional HTML, CSS and client script
>> code for displaying content. <
>>
>
> Let's start with Shadow DOM: The whole one hundred thousand ++ text
> character specification adds a heavy burden to the client's script engine.
> - And its implementation is completely unnecessary while using HTML IFRAME
> elements or anything else than Web Components.
>
> Custom Elements: It's unnecessary to have Custom Elements (please note the
> explicit capitalization here) to declaratively define complex components if
> you need ECMA script to get them to life. Just create an ECMA script class
> doing all the work to decorate dedicated elements and you're done. Custom
> Elements just add redundancy.
>
> CSS: I'm just going to name a few additional CSS constructs here: @host,
> :scope, ::distributed -- While IFRAME content can reuse a website's CSS,
> Web Components require their discrete CSS. IFRAME content can be displayed
> as a web page on their own, Web Components can't. End of Story.
>
>
> ========================
>
>  Web Components install complex concepts (e.g. <decorators>) by
>> introducing unique, complex, opaque behaviours, abandoning the pure nature
>> of presentation. <
>>
>
> As I've read on one of the replies I've received, decorators are
> deprecated by now, so I won't further elaborate on them. Still, Shadow DOM
> remains being an unnecessary and complex design, compared to using HTML
> IFRAME elements.
>
>
> ========================
>
>  Web Components require special script event handling, so existing script
>> code cannot be reused. <
>>
>
> Decorators, Custom Elements and Shadow DOM require additional events for
> them to function properly. HTML IFRAME elements just use the existing
> events - if there is any event required at all to display their content. No
> further ado or implementation required when using HTML IFRAME elements.
>
>
> ========================
>
>  Web Components require special CSS handling, so existing CSS cannot be
>> reused. <
>>
>
> Please refer to my above elaboration on CSS for details.
>
>
> ========================
>
>  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. <
>>
>
> Please refer to my above elaboration on Custom Elements for details.
>
>
> ========================
>
>  The W3C DOM MutationObserver specification already provides functionality
>> equivalent to insertedCallback()/readyCallback()/removeCallback(). <
>>
>
> Please refer to the W3C DOM MutationObserver specification for details.
>
>
>
> Cheers,
> Axel Dahmen
>
>
> ------------------
> "Tab Atkins Jr."  schrieb im Newsbeitrag news:CAAWBYDCV6MRC2xx9xiupEAGV7-
> R1dxaE7YQWsnWG5LgB1-t2hw@mail.gmail.com...
>
>
> 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?
>
> Digging through the bug thread, it appears you might be talking about this:
>
>  Web Components require a plethora of additional browser features and
>> behaviours.
>>
>> Web Components require loads of additional HTML, CSS and client script
>> code for displaying content.
>>
>> Web Components install complex concepts (e.g. <decorators>) by
>> introducing unique, complex, opaque behaviours, abandoning the pure nature
>> of presentation.
>>
>> Web Components require special script event handling, so existing script
>> code cannot be reused.
>>
>> Web Components require special CSS handling, so existing CSS cannot be
>> reused.
>>
>> 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.
>>
>> The W3C DOM MutationObserver specification already provides functionality
>> equivalent to insertedCallback()/readyCallback()/removeCallback().
>>
>
> Is this correct?  Is this the full list of comments you wish to make?
>
> ~TJ
>
>
>
>