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

2014-05-30 Thread Jarrod Overson
On Fri, May 23, 2014 at 8:10 AM, Brian Kardell bkard...@gmail.com wrote:


   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.


Does anyone have a reference for this?


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

2014-05-29 Thread Axel Dahmen

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-t...@mail.gmail.com...

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?

Digging through the bug thread, it appears you might be 

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

2014-05-29 Thread marc fawzi
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 bril...@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.


 

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

2014-05-23 Thread Tab Atkins Jr.
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?

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



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

2014-05-23 Thread Brian Kardell
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