Re: Generated content via URI

Bert Bos <bert@w3.org> wrote:

>I think people referred to document formats that were originally made 
>for printing, and thus do not provide fallbacks for network errors or 
>for different devices. Such documents may require a certain element 
>(e.g., <danger/>) to print a symbol (e.g., a warning triangle), which 
>can be emulated with CSS through 'content', except that CSS doesn't 
>guarantee that the symbol will actually be rendered. Thus, while 
>waiting for the fallback control of CSS3, it falls to the UA to handle 
>error cases.

I'd prefer a real world case reference, the above throws up too many
questions.

Afaics you are describing a situation where marked up content is
replaced by CSS generated content. Under CSS2.1 this is not possible
other than by faking it by introducing another element, for example:

danger span{display:none}
danger:after{content:url(danger.png)}

<danger><span>/!\</span></danger>

The above construct could result in nothing being printed if the image
is not available, but this is the consequence of using hacks that
attempt to do something that isn't properly possible with CSS2.1. I
don't understand why the CSS2.1 spec should cater to such flawed hacks
when doing so introduces a new problem that negatively affects proper
CSS usage.

>It's not that the WG thinks it is *appropriate* to put different 
>semantics in the style than in the document, but simply that the WG 
>thinks there is no way to make it impossible, without also making 
>correct usage impossible.

Having brushed up on the CSS3 generated content proposal I now realise
that CSS textual fall back content is a companion to the "inhibit" value
for the content property. It is the replacing of content which this
value enables that I have difficulty with. The only usage I can imagine
is inappropriate usage.

>with 
>the generalization of 'content' in CSS3 you can provide images that 
>replace text without affecting the accessibility of the document

Such a construct belongs in the markup, not in a styling language.
If the position is taken that the <object> element has failed in
practice then use of an <img> element with alt content is a better
choice than doing it with CSS.

Using "CSS image replacement" techniques for images that are not
strictly decorative has always been an ugly hack. Extending CSS to
further such practices would be a regrettable development.

>and so 
>that you can show different images for different window sizes.

This is fundamentally not a problem for CSS to solve. Furthermore I
don't believe that if CSS were to provide such a feature that it would
see real world usage. The complexities of authoring a single markup
document with different size images and then coding the CSS to deliver
these different size images to different viewport sizes are such that
authoring separate versions is easier, and this also has the advantage
that other content can be tailored to meet the different requirements of
such environments.

Authoring content that works well on for example mobile phones and
desktop computers requires not just different size images, but different
content in general, plus a different in-viewport UI.

-- 
Spartanicus

Received on Tuesday, 17 April 2007 19:49:05 UTC