Re: Seamless transclusion of complex replaced elements

On Feb 20, 2008, at 6:37 AM, Bert Bos wrote:

>
> On Wednesday 20 February 2008 13:09, Philip Taylor (Webmaster) wrote:
>> Brad Kemper wrote:
>>> Interesting. So this is really about auto-sizing iframes? For a
>>> moment there, I thought it might mean cacheable snippets of html
>>> text that could be inserted into the flow of a document. Something
>>> like this:
>>>
>>> <div style="content: url(htmlSnippet.asp); height:auto;" />
>>
>> This I would not like : content slipping in through
>> the back door of CSS.  Bert's proposal seemed far
>> cleaner to me.
>
> The current proposal for the 'content' property[1] in level 3 indeed
> allows the DIV in the example above to be turned into a "replaced
> element" and thus my feature request for a new height calculation
> applies to that example, too.

In the referenced working draft, the URI replaced content uses images  
as examples, and speaks of "supported formats". Does it rely on the  
MIME type to determine the format of the linked resource? Are  
snippets of html (with "text/html" MIME types) or even just plain  
text considered "supported formats"? If so, then the height should be  
whatever it would be if the HTML or text had just been part of the of  
the original document, instead of a linked resource.

After reading the bugzilla comments in Boris's link, I'm amazed that  
UAs do not consider the intrinsic height of a replaced element, when  
the CSS clearly says it should be "auto" height. For IFRAMES, this is  
clearly something that is needed, even if it breaks a few layouts,  
IMO, as there is nothing automatic about sizing it to "150px". The  
inability to set the 4 edge positions of an absolutely positioned  
IFRAME is equally baffling (and seemingly related?).

Slightly off topic, but it looks as though HTML 5 would be able to  
handle importing HTML snippets via its "embedded content" facility  
[2]. The working draft seems short on examples, but as near as I can  
tell, it would allow you to do this:

  <embed src="htmlSnippet.asp" type="text/html" />

...although I don't know what it would do with any "height" or  
"width" attributes on the EMBED element. Perhaps treat them as CSS  
"height" or "width", and subject them to the overflow values of that  
"embed" element.


[...]

> Now that I'm in a philosophical mood: how about transcluding inline
> content?
>
> The height feature I requested still assumed that a replaced  
> element is
> a rectangle. The fact that replaced elements are rectangles is one of
> the reasons that math has to become an integral part of HTML, unlike
> PNG or SVG, which are handled fine as links: formulas, unlike images,
> are not single rectangles, but can be broken over several lines.
>
> I think math is in general easier to handle if it is mixed in with the
> surrounding text, rather than linked. Formulas are often parts of a
> sentence ("if x > 0, then f(x) is even"). But assume that we want to
> transclude them anyway:
>
>     If <em src="m1.mml">x &gt; 0</em>, then
>       <em src="m2.mml">f(x)</em> is even.
>
> How do I say in CSS that the replaced element is not a simple box,  
> but a
> series of inline boxes with baselines and line break opportunities?

Well, if any old HTML snippets were allowed to be imported, via the  
EMBED element, for example, or possibly via CSS's "content", then  
this should not be a problem, as the linked and embedded HTML would  
presumably just become part of the document tree, as though it were  
written into the document from the start. Although it doesn't look  
like "embed" has fallback content, so maybe CSS's "content" property  
would be a better choice after all:

     If <em style="content: url(m1.mml);">x &gt; 0</em>, then
       <em style="content: url(m2.mml);">f(x)</em> is even.

>
> [1] http://www.w3.org/TR/2003/WD-css3-content-20030514/#content
>     (There is much in that draft that is unlikely to end up in  
> level 3,
>     but the 'content' property and its url() value have so far  
> survived
>     all discussions in the working group, so I predict that it will
>     stay.)
>
>
>
> Bert
> -- 
>   Bert Bos                                ( W 3 C ) http://www.w3.org/
>   http://www.w3.org/people/bos                               W3C/ERCIM
>   bert@w3.org                             2004 Rt des Lucioles / BP 93
>   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
>
[2] Embedded content in HTML 5: http://www.whatwg.org/specs/web-apps/ 
current-work/#the-embed

Received on Wednesday, 20 February 2008 16:58:32 UTC