Re: Display Property Suggestion

I will again put a summary of the suggestion first.

Basically, Christian's idea boils down to only changing the content
property to accept the following:

   [ <uri> "," ]* 
   [ <string> | <uri> | <counter> | attr(X) | open-quote |
      close-quote | no-open-quote | no-close-quote ]*  
    | inherit

So one can list a series of uris first, separated by commas, which
should be used as the source files for making the element into a
replaced element, and which the UA should try to display each in turn
until it finds one that (a) is available and (b) it supports. If it
runs out, then it gets to the part of the content property that we all
know and love, where we can combine strings and counters and attr(ALT)
and so on. If the last part of the content property is empty, then the
contents of the element (if any) should be displayed. IOW, the
workings are the same as the "extended display" suggestion, but using
the content property instead.

Ok, now the reasoning:

On Fri, 30 Oct 1998, Christian Kaufhold wrote:
>>
>> img:before { display: inline url(attr(src)); content: attr(alt);
>>              width: auto; height: auto; }
>>
> I would suggest rather than to use "display" to set the url (image)
> to show, to use "content".
> [...]
> Also it doesn't turn "display" into a "pseudo-shorthand" property
> that takes both the display-mode, and the url to display, and which
> might therefore make problems in terms of the cascade (what happens
> when a user has set "img { display:inline!important }" ?).
Very good point.

Ok, scratch the extension to display, move it over to content.

> I think it makes more sense to say:
>    img { content: url(attr(src)), attr(alt); }
> In this way I would allow "content" to be used not only for :before
> and :after, but also for the real element (which should be empty so
> that its content is not lost), which means that the browser tries to
> read the url (one after the other), and if that fails, displays the
> rest of the content.
This means we are extending the "content" property. CSS2 says it
accepts the form "a b c" to display a+b+c, we are here suggesting it
also take the form "a,b,c", to display a, or failing that b, or
failing that c.

I like this idea, it solves all the problems at once!

> Maybe the keyword "auto" or even "element" could be used to display
> the HTML element's content in cases like
>
>   <OBJECT data="logo.mpeg" "type="application/mpeg">
>     <OBJECT data="logo.gif" type="image/gif">
>       Firm XYZ
>     </OBJECT>
>   </OBJECT>
>
> would use the stylesheet
>
>   object { content: url(attr(data)), element; }
> 
Yes, this is nice, although we don't need a keyword since we can just
say (as you did above) that an empty content is equivalent to drawing
the element's content.

This means we extended 'content' as follows:

   [ <uri> "," ]* 
   [ <string> | <uri> | <counter> | attr(X) | open-quote |
      close-quote | no-open-quote | no-close-quote ]*  
    | inherit

...thus (a) allowing a list of uris first, for the images, and comma
separated, and then failing all those we get to the final part which
accepts counters and attr()s, and so on. By subtly changing the "+" to
a "*", we allow an empty section at the end, which would display the
content of the element. Thus for object:

   object { content: url(attr(data)), ; }

and for img:

   img { content: url(attr(src)), attr(alt); }

and while I'm at it, IFRAME:

   iframe { content: url(attr(src)), url(attr(longdesc)), ; }

-- 
Ian Hickson

Received on Friday, 30 October 1998 20:01:49 UTC