See: http://comments.gmane.org/gmane.comp.web.html.general/8922

--

After reading the HTML5 specification on the seamless attribute of the iframe element, I believe the seamless attribute to be too narrowly considered.

It seems, the seamless attribute basically enables three features:

* automatic iframe height calculation
* CSS integration
* DOM integration

I see a problem in integrating the later two. So I would like to suggest the seamless attribute to become a comma separated list of above three Seamless properties to be enabled. For backward compatibility to HTML5, if the attribute value equals "seamless", all three properties should be enabled.


Here's my reason for this suggestion:

I'm using iframe elements to render micro parts of a web page, e. g. a data grid, without requiring much JavaScript ado. In the following I call these iframe micro page elements "controls".

In our web application I'm inserting arbitrary iframe controls into several web pages.

If the page's CSS would have influence on the iframe control's rendering, then it would be necessary to test each and every iframe control on each and every page where the iframe control could possibly be inserted (probably database driven), because some CSS on any particular page might have bad influence on the iframe control's content.

So I would prefer to just add an additional <link> element (the application's CSS) to the iframe control's HTML content and still be sure that there won't be any other CSS influencing the iframe control's HTML presentation.


Same for DOM integration: jQuery selectors may find elements not intended to be found if both, the page's and the iframe controls' DOM trees would be merged.

The current definition results in a testing hell, from my perspective.


So I suggest that any of the above three seamless features may be optionally applicable.

Possible seamless attribute values may be (just suggesting some names here):

    autoheight   =   sets the iframe's height to the minimum height necessary to omit a scrollbar
    cssinclude   =   have the page content's CSS being prepended to the iframe content's CSS
    dominclude   =   have the iframe content's DOM integrate with the page content's DOM
    seamless     =   "autoheight,cssinclude,dominclude"

attribute seamless = [ autoheight || cssinclude || dominclude ] | seamless

Regards,
Axel Dahmen
www.axeldahmen.de

If the use case is making a custom control, wouldn't Web Components be a better solution than <iframe seamless>?

Nice.

But Web Components are too much ado compared to IFrames. - I'm afraid there's no concept available beating a simple <iframe src="">.

An IFrame element renders asynchronously, it provides full code and visual encapsulation and can be maintained independently. Using Web Components would require plenty of JavaScript code and additional markup to acquire the same result.

And just like with the current IFrame Seamless attribute: Web Components do not keep the template's code/visuals separate from the container's code.

Web Components don't seem a feasible alternative to using IFrames with (just) automatic height calculation to me.

If Web components are too complicated compared to the (pretty complicated and subtle) <iframe seamless>, then we need to simplify Web components. Can you elaborate on what part of Web components is the issue here?

Created attachment 1473 [details]
Draft on argumenting on iframe seamless attribute augmentation

I now have created a small draft document, trying to elaborate on the benefits of using <iframe> elements compared to any other currently available alternative option, including Web Parts.

... was meant to read "Web Components".

Created attachment 1474 [details]
update on document, having the term Web Parts being replaced by Web Components

Created attachment 1475 [details]
Draft on argumenting on iframe seamless attribute augmentation

Can I ask you to send that (ideally in text form rather than PDF form) in an e-mail to public-webapps@w3.org, primarily focused on explaining why Web Components is too complicated as is compared to using <iframe>s? We should make sure we address those rough edges so that Web Components are easier for you than <iframe>s, otherwise we've failed with Web Components.

OK, here are the drawbacks of Web Components (compared to IFrames, but also in general) in details:

------------------------

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().

------------------------

Did you have a deeper look at my sample in PDF format? I've been trying to be very focussed, being brief and thorough at the same time.

Do you believe, after comparing IFrames to Web Components, you can achieve the same output (given my IFrame sample use case) using Web Components instead, *without* a single additional key stroke?


Please try to evaluate (from the given sample):

* How many more keystrokes would it require to achieve the same result using Web Components compared to the IFrame solution?

* How much more time would it require to implement the same result using Web Components compared to the IFrame solution?

* How much more time would it require to test any additional Web Component, having it been applied to, say, 10 different pages compared to the IFrame solution?

I'm not particularly familiar with Web Components, so I don't know. But the people in public-webapps@ are.

Actually, I' not aiming at condemning Web Components here.

What I'd like to achieve here is to elaborate on the IFrame seamless attribute.

Right, but what I'm saying is that for your use case, we should make sure Web Components are easier to use than <iframe>s, so that you don't need a change to iframes to do it.

OK, thank you.

I will consider forwarding this thread to the WebApps group so they can see if they want to amend the Web Components spec.

However, would you mind considering amending the seamless attribute for the existing <iframe> element? This would solve many issues without much ado.

Yes, this bug still being open means it's being considered.

Did you ever forward that thread?

Without a comparison of the way you'd like to do it (described here) to the way that one would do it with Web Components, it's hard to evaluate whether this would in fact make it simpler or not.

I sure did:

http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0515.html

It seems they've put me on a black list for this thread. At least I wasn't able to reply to the last response in the thread.

At present I assume they didn't want to further discuss on the disadvantages of using/implementing Web Components compared to iframes.

(In reply to Axel Dahmen from comment #18)
> It seems they've put me on a black list for this thread. At least I wasn't
> able to reply to the last response in the thread.
> 
> At present I assume they didn't want to further discuss on the disadvantages
> of using/implementing Web Components compared to frames.

Who are you talking about?

Nobody's blacklisted you. If you sent a message to the the public-webapps list and it didn't appear, it's likely just because you're actually not a subscriber to that list, so you message might be in a moderation queue waiting for list moderator's approval.

Anyway, I've gone ahead and added your address to the whitelist of addresses that are allowed to post to the list without moderation. So if you re-send a message on that thread now, it should get sent out to the list as expected.

Great, thanks Ian.

I'm using a newsgroup reader via GMane. So I'm usually not involved in subscribing to mailing lists.

As far as I can tell, you never actually sent any concrete information to that thread.


To make progress on this bug, I think we need a concrete comparison of the way you'd like to do it to the way that one would do it with Web Components. That is, actual source code examples of the two possible ways to do it. I can't evaluate the wisdom of this bug request without being able to compare real code samples, and I don't understand what you want to do well enough to write the code samples myself.

I understand your point.

But frankly, I'm at the end of my wisdom now. I've done everything you've requested so far. Nothing seems sufficient enough for you to just amend the attribute with a tiny enhancement which wouldn't even require new application code as the enhancement just puts existing functionality into a condition.

The Web Components specification is still an early draft. All we can discuss on for now is on a theoretical basis. How am I supposed to create sample code??

I believe, after I have now invested quite a lot effort into this bug, time has come for you to act.


Let's reiterate what is for sure as of today:

The main - and crucial - difference between iframes and Web Components is that the design of iframes naturally encapsulate code while Web Components naturally intermix page and Web Component ECMAScript and style code. Intermixing style/script, however, results in a testing hell and instability.


Frankly, I don't know what to discuss with the Web Components team. The above statement is a fact that can not be discussed or interpreted. Even the slightest bit of Web Component code affects a container page.

Using Web Components, a CSS style like "div {width: 100%}" will affect both page and Web Component content.

Using Web Components, a script like "$('div').empty();" will affect both page and Web Component content, too.

Anything that can be done to prevent such intermingling of page and web component content is already an effort that unneccessary when using iframes, because iframes naturally separate a container's content from an iframe content's content.

Using iframes encapsulates code and helps reusig code. An iframe's content will display all the same and behave all the same everywhere. No testing required.

This will never be true for Web Components.

What more is there to know?

I believe your statements regarding Web Components are inaccurate. Encapsulation is a key feature of Web Components. If the encapsulation Web Components provide isn't sufficient, then we must fix Web Components, or it just won't solve the problem it set out to solve.

I would like to try to construct a widget using an iframe and using Web Components, to see what the reality is here. Do you have an example of something less involved than a datagrid that I could start with to test this?

My main statement is not encapsulation, but effort.

As far as I can tell, Web Components result is more developing and testing effort than iframes do.

Your request for providing an example might overstrain my time schedule. I don't like to write this, but as an external lead software architect for a couple of major brands I'm rather busy and my amount of free time is quite sparse.

Yet, I'll see what I can do.

Created attachment 1520 [details]
Sample demonstrating the advantage of IFrames

OK, here's a sample, demonstrating the advantages of iframes.

The sample project contains two HTML files: The main HTML file, Container.html, and the iframe HTML file, ItemEditor.html.

Both HTML files provide their own, separate application logic.
- For obvious reasons I've omitted server side application code here. Instead, I've been using KnockOutJS to implement a basic client side application logic.

Both HTML files provide their own, separate presentation style implementation, too.
- Both inherit the project's basic stylesheet (Project.css). Yet, both add their personal, page dependant, styles. (In fact, Container.html actually doesn't add private styles to the project in this sample.)


--------------

So, here's the advantage of iframes:

Imagine, implementer #1 implements the container, having access to only the following files: "Container.html", "Project.css", "Container.css", "Container.js".

Further imagine, implementer #2 implements the item editor, having access to only the following files: "ItemEditor.html", "Project.css", "ItemEditor.css", "ItemEditor.js".

Both implementers don't know about the other's implementation. They only implement their part of the project. And they only test their share of the project.



Now, I'd like you to compare the following three items:


(1)

Create a sample replacing the iframe implementation with a Web Component implementation.

Compare the number of bytes for all the files of the Web Component version with the number of bytes of all the files of the IFrames version.

The number of bytes of my IFrames version is: 143,337 (using a decent file formatting with white space, no minimization has taken place).


(2)

Rename JavaScript object names in "Container.js" to be equal to the object names in "ItemEditor.js" in both, the Web Components version and the IFrames version.

Compare the effort that's necessary to keep both versions, the Web Components version and the IFrames version, executable.


(3)

Create a second ItemEditor (ItemEditor2.html, ItemEditor2.css, ItemEditor2.js) and add a reference to Container.html so the user will be able to add both, ItemEditor and ItemEditor2, items to the page.
(No intermixing required. Just add another <ul> and a second [add] button.)

For simplicity, don't change anything in the implementation of ItemEditor2.

Compare the effort that's necessary to keep both projects, the Web Components version and the IFrames version, executable.

BTW: I've intentionally set the iframe height to only 14.5em. Using Firefox you can see how necessary it is to amend the IFrame element according to my suggestion.

And I -again- like to stress the fact that my suggestion is fully backwards compatible to the current HTML5 specification.

I just noticed that I added jQuery and KnockOutJS to my byte count.

Unfortunately, it is not possible to amend comments. So here's my byte count without counting the length of the supporting libraries I've been using:

4,963 Bytes.

Ok so I made a version using Web Components:

   http://damowmow.com/playground/demos/components/001/

I didn't use any supporting libraries (didn't need them), and the byte count is 4833. I'm not sure how much that really tells us though. I could certainly have tried to make it smaller if that was necessary.

I don't understand your (2). Why would it cause any trouble?

Again with (3) it seems trivial to do this with Web components.

However, consider:

(4) count the number of network requests made when pressing the "add" button in the iframe version vs the component version.

I don't see why Web Components are "too much ado" here. They seem like a much cleaner fit to the problem than iframes.

Created attachment 1541 [details]
Sluggish sample demonstrating the advantage of IFrames

(In reply to Ian 'Hixie' Hickson from comment #28)
> Ok so I made a version using Web Components:
> 
>    http://damowmow.com/playground/demos/components/001/
> 
> I didn't use any supporting libraries (didn't need them), and the byte count
> is 4833. I'm not sure how much that really tells us though. I could
> certainly have tried to make it smaller if that was necessary.

Sure, but that's not the point. I could have ommitted the libraries, too (see amended example), but I wanted to give a living example working on every current browser.

The sample you've provided doesn't seem to appreciate requirements and coding standards for working in teams. Neither did you or Web Components in the sample you gave consider encapsulation. Black box programming won't work with Web Components - whereas it works using IFrames.

Here's what your sample is lacking (and what the IFrame sample isn't but by nature of the IFrame design):


(1)

Where's the stylesheet for item-editor.html? If you added it, what would a rule like "form {background-color: white;}" contained in it lead to?

(2)

Your item-editor.html code contains the following code:
    "document.registerElement('item-editor', ...);"

What if your team member created a new, second, item editor, say item-editor2.html, and what if he used the same line:
    "document.registerElement('item-editor', ...);"
... without telling you?

And what if another team member of yours, responsible for the container.html page, added that second editor to the container page by copy/pasting the container page control creation code, just amending the LINK element?

(3) Your item-editor.html code contains a global "owner" function. What if your colleague added a global function of the same name to her item-editor2.html file, but with different content?


Even now your simple sample code already contains three (if not more) breaches of encapsulation. Three situations that have to be considered and tested for. And we are but talking here about three authors fulfilling their tasks without knowing each other's code.


For IFrames ...

(1) won't be a problem, because IFrame opens its own, fully separate, render context. Nothing to test or consider here.

(2) won't be a problem, because IFrame opens its own, fully separate, render context. Nothing to test or consider here.

(3) won't be a problem, because IFrame opens its own, fully separate, render context. Nothing to test or consider here.


Web Components offer a wide gate for programming failure and and random error. IFrames don't.

So still, IFrames are the best solution for team development of larger websites featuring reusable components.

Excellent, these are the kinds of things I was asking for in comment 4. Thanks. Now we can work on making Web Components address your issues so that it'll work.

That sounds great to me! Looking forward to it!

However, in the meantime, would it be daring to ask to amend the IFrame Seamless attribute the way I described?

It'd mean quite less effort to application programmers to implement and, thus, be quicker and more reliable to use in the midterm because of the truly minor change.

> Where's the stylesheet for item-editor.html?

In item-editor.html at the top. Right now it just imports default.css since there's nothing special about the editor, but you could have a separate file if you wanted.


> If you added it, what would a rule like "form {background-color: white;}"
> contained in it lead to?

It would be scoped to the component, so it would make the form inside the item editor white, while not affecting the outer form.


> Your item-editor.html code contains the following code:
>     "document.registerElement('item-editor', ...);"
> 
> What if your team member created a new, second, item editor, say
> item-editor2.html, and what if he used the same line:
>     "document.registerElement('item-editor', ...);"
> ... without telling you?

Much like two teams that both create an ItemEditor.html file are going to conflict, two teams that both register the same element name are going to conflict. This is trivial to work around: have a wiki page for your project with first-come-first-served name registration.

But maybe the better solution is per-module element registration. Filed bug 27835 to make components have this feature.


> And what if another team member of yours, responsible for the container.html
> page, added that second editor to the container page by copy/pasting the
> container page control creation code, just amending the LINK element?

Yes, when writing code you need to make sure you don't use globals that have the same name. I mean, if you import two JS libraries that both export a global "start()" function, you're going to have the same problem. This is not unexpected. The same happens with the <iframe> model e.g. if the iframe adds an API to the parent frame, or if different components made with iframes both use external style sheets with the same names, or whatever.


> Your item-editor.html code contains a global "owner" function. What if
> your colleague added a global function of the same name to her
> item-editor2.html file, but with different content?

Yeah, that's unfortunate. We should fix that. Filed bug 27836.


> Web Components offer a wide gate for programming failure and and random
> error. IFrames don't.
> 
> So still, IFrames are the best solution for team development of larger
> websites featuring reusable components.

Right. Let's fix Web Components so that this isn't true. If Web Components aren't the best solution for what you're proposing, then they've failed. What you're proposing is the entire point of Web Components.

Yes, but with much unnecessary overhead for reaching the same result IFrames already provide.

<iframe seamless> has been removed from the implementation. Unfortunately nobody wanted to support it.

https://github.com/whatwg/html/commit/1490eba4dba5ab476f0981443a86c01acae01311