W3C home > Mailing lists > Public > www-style@w3.org > September 2011

RE: [css3-regions] iframe as content source

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Thu, 8 Sep 2011 02:03:08 +0000
To: David Hyatt <hyatt@apple.com>
CC: Vincent Hardy <vhardy@adobe.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E5398569284121233A8@TK5EX14MBXC213.redmond.corp.microsoft.com>
Actually the "iframe flow" behavior is anti-transclusion, and it is closer to what happens to formatted content when you put it into a chain of boxes in a DTP system:


*         Content styling is not affected by parent styles (other than intentional override via region styling)

*         Scripts in content are contained to content document (security options may vary, but script is contained unless it intentionally reaches outside)

Building up complex documents via Ajax is actually much close to transclusion as it creates a single document from pieces that may be completely unrelated initially. And model of isolated flow is closer to the concept of "template" or "master document", where layout of magazine page and article content are done by different people and have no reason to share style sheets...

BTW, one example of use of isolated flow (essentially same as regions with iframes) is print preview in IE [1]. It works that way since last century, and it would be much harder to do the same if the source document had to be merged with the print preview template...

I agree that the current definition (the special behavior simply triggered by using iframe as a source) is not ideal. I've just opened an issue at wiki [2] to get it resolved formally.

Alex

[1] http://msdn.microsoft.com/en-us/library/aa969430(VS.85).aspx
[2] http://wiki.csswg.org/spec/css3-regions?&#issue-19special-behavior-of-iframe-flow

From: David Hyatt [mailto:hyatt@apple.com]
Sent: Wednesday, September 07, 2011 5:58 PM
To: Alex Mogilevsky
Cc: Vincent Hardy; www-style@w3.org
Subject: Re: [css3-regions] iframe as content source

It just seems like transclusion is a problem that isn't tied to regions. I don't get why you're latching on to "flow" as a way to implement transclusion. The two are separate features. I think if you want to do transclusion as a feature, you should make a new CSS module and spec it there. Overloading it into regions, though, doesn't make any sense to me.

dave
(hyatt@apple.com<mailto:hyatt@apple.com>)

On Sep 7, 2011, at 3:45 PM, Alex Mogilevsky wrote:


I don't mind if this is made optional until we see stable implementations and use patterns, but I will very much insist in keeping it in some form. We consider it important for content model that separates content and template, and we will have an implementation. The feature needs to be defined, unless we believe it is fundamentally wrong to have it.
From: www-style-request@w3.org<mailto:www-style-request@w3.org> [mailto:www-style-request@w3.org]<mailto:[mailto:www-style-request@w3.org]> On Behalf Of David Hyatt
Sent: Wednesday, September 07, 2011 1:34 PM
To: Alex Mogilevsky
Cc: Vincent Hardy; www-style@w3.org<mailto:www-style@w3.org>
Subject: Re: [css3-regions] iframe as content source

I would strongly prefer this feature be cut from the draft. I think it's going to be extremely complicated to implement, and I don't think the use cases are compelling enough when compared with the cost of implementation.

dave
(hyatt@apple.com<mailto:hyatt@apple.com>)

On Jul 14, 2011, at 10:34 PM, Alex Mogilevsky wrote:



There is an action on me to add detail to behavior of iframe element when used as a named flow source (http://dev.w3.org/csswg/css3-regions/#flow2)

Here is prose I'd like to put there:
If 'flow<http://dev.w3.org/csswg/css3-regions/#flow2>' property is specified on an iframe, object or embed element the 'display' property is computed to 'none' and the referenced document within the element is used as the named flow. In the case of the object element if fallback occurs and the fallback element has a referenced document then that document is used as the named flow, otherwise the fallback element itself is added to the named flow.
<ins>Any properties set on the iframe/object/embed elements (including margin, border, padding, background) have no effect. This redirection of content does not change representation of the elements in document tree, just as for any other source of named flow; in this case iframe still provides security checks for script in content (and sandbox if required), events and CSS cascading work the same way as in a documents hosted in regular iframes.
Region styling applies to content coming from iframe/object/embed sources exactly the same way as to any other flow content.</ins>
New issue (perhaps this belongs to wiki, not inline with spec):

Issue 5

Having a special case for treatment of iframe box model may be seen as inconsistency in definition of named flows. Also, it may be desirable to add an iframe or object to a named flow as a replaced element (which would require a wrapping element with this definition). This difference in behavior may be acceptable, or it could be addressed by providing an option to use content of an element in named flow vs. using the whole element.

For example, there could be two 'flow-into' properties:

1)    <iframe style="flow-into:flow1"> --  add iframe to flow as a replaced element
2)    <iframe style="flow-content-into:flow1"> --  add content of the iframe to flow

Alternatively, there can be a separate property to specify what to add to flow, with the same effect:

1)    <iframe style="flow-into:flow1; flow-source-type:element"> --  add iframe to flow as a replaced element
2)    <iframe style="flow-into:flow1; flow-source-type:content"> --  add content of the iframe to flow

Note that adding element vs. content option would add interesting possibilities, such as a choice of adding the whole table to flow vs. contributing table's rows into a merged table.
Received on Thursday, 8 September 2011 02:04:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:44 GMT