W3C home > Mailing lists > Public > www-style@w3.org > August 2005

Re: [CSS2.1] Replaced elements

From: Staffan Mhln <staffan.mahlen@comhem.se>
Date: Wed, 10 Aug 2005 18:28:27 +0200
To: www-style@w3.org
Message-ID: <42FA474B.6855.268DB0@localhost>

> [mailto:www-style-request@w3.org] On Behalf Of L. David Baron
> Sent: den 12 juli 2005 23:39
> To: Staffan Mhln
> Subject: Re: [CSS2.1] Replaced elements
> On Wednesday 2005-06-15 18:24 +0200, Staffan Mhln wrote:


> > Whats the reason for choosing the approach that the CSS renderer needs 
> > to be aware of a ratio rather than that the embedded media needs to be 
> > made aware of the CSS constraints? 


> I'm not sure what it is you're saying here, nor are others in 
> the working group.  Are you saying that the algorithm is 
> fine, but it should be defined in the other specs (e.g., SVG) 
> rather than the CSS spec?

No i'm not sure that the algorithm is good enough. Yes i believe that other
recs (including SVG) need to define this themselves, or at least may need to 
(CSS will always override in this type of case and simple media types wont 
need any special handling, intrinsic width/height is usually fine). I think SVG 
already defines some of this in section 7.2. CSS should define how it
acts when embedded into itself, eg <img src="ex.html" />.

> That seems like a bad idea to me since it's relatively easy 
> to define and harder to define an API through which other 
> specs can define it.
> If you still think the spec needs changing, could you 
> clarify, preferably with examples?

Sure, sorry about being unclear. I may well be reading to much into the
ratio feature. Here are some examples:

>From about a month ago on this list an example in XHTML2:

    <section role="navigation" src="nav.xhtml" 
srctype="application/xhtml+xml" />
    <section role="banner" src="banner.xhtml" 
srctype="application/xhtml+xml" />
    <section role="main" src="main.xhtml" srctype="application/xhtml+xml" />

A simple SVG example that might be difficult to solve with ratio:

<object data="some_svg.svg" type="image/svg+xml" />
(some_svg: <svg width="100%" height="100%">...)

Shrink-wrap calculations can be a problem, and min/max width/height
should work:

    <object data="some_data" style="max-width: 400px; max-height 200px;" />

SVG also has some features that seems to me like they are poorly suited for
the ratio thing.
(<svg width="200px" height="500px" preserveAspectRatio="none">)

And there are of course other media-types to consider.
<object type="text/plain" data="the_script.js" />

Finally, when it might be useful to consider other purposes than 
replaced elements:
background-image: url(some_svg.svg)
list-style-image: url(some_svg.svg)
content: url(the_script.js)

I am trying to say that essentially you cannot create enough
parameters from embedded objects to the CSS context to handle complex
media like SVG with their specific features. The IMHO most reasonable
way of handling this is that the CSS level provides it's info to the
underlying object, which then decides its size, and then the CSS 
level re-checks that the chosen dimensions are within its
constraints. The data the CSS level would expose to an object is
probably something like the applicable of the below:

'width' of <object>
'height' of <object>
'min-width' of <object>
'max-width' of <object>
'min-height' of <object>
'max-height' of <object>
used width, or if not known, 'width' of containing block
'height' of containing block

Such a solution also allows using different fallback dimensions for
different media (which at least some UAs seem to do today, but this may
depend on the element used to include the resource as well and seems
difficult to analyse, only iframes seem to be as simple as the 300px fallback). 


>  This whole business would 
> be quite difficult to define; it could be considered for 
> CSS3, but I think it's out of scope for CSS2.1 considering 
> that it's a new feature and there are no current implementations.

Ok, so what cases does ratio solve and are there current implementations?

Received on Wednesday, 10 August 2005 16:28:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:20 UTC