W3C home > Mailing lists > Public > www-style@w3.org > February 2008

RE: Seamless transclusion of complex replaced elements

From: Justin Rogers <justrog@microsoft.com>
Date: Wed, 20 Feb 2008 07:01:21 -0800
To: Bert Bos <bert@w3.org>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <00BD06E707F60B4F9D6A3E75C712209D49F11A38AE@NA-EXMSG-C104.redmond.corp.microsoft.com>

I apologize in advance if I'm reading too much into the use of auto-sizing, but...

Any specification should be very careful when giving the IFRAME element or any element that renders variable and cross domain content the ability to auto-size based on the content itself. If you do this I can now predict based on the final size of the element the contents of the page in the element. You could call this a minor cross domain hole, but information disclosure like this is becoming the new mechanism for targeting users with convincing phishing attacks.

Justin Rogers [MSFT]

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Bert Bos
Sent: Wednesday, February 20, 2008 6:38 AM
To: www-style@w3.org
Subject: Re: Seamless transclusion of complex replaced elements


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.

I didn't target IFRAME elements in particular. They are an old-fashioned
way of transcluding content and haven't been part of HTML since HTML4.
But if replaced elements in general can have a flexible height, then so
should IFRAMEs.

Of course, inserting content via the style sheet is a feature that is
easily abused. The rule of thumb is still that the document should be
fully understandable without its style sheet. But it's not CSS's task
to make dangerous things impossible; its task is to make useful things
possible (and try to make the statistically most useful things easy).



[Slightly unrelated:]

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?


[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
Received on Wednesday, 20 February 2008 15:01:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:01 GMT