Re: Display Property Suggestion

On Tue, 24 Nov 1998, Håkon Wium Lie wrote:
> I admit to having lost track of the display property discussion.
> Could Ian and/or Christian summarize the current proposal(s)? If
> possible in a form suitable for inclusion in a future CSS
> specification.

On the www-style past suggestions list...
   http://www.bath.ac.uk/%7Epy8ieh/internet/wwwstyle.html
...you will find the following (but note comments following it, which
are not on the past suggestions list):

=======-------8<-------=======

Specifying Replaced Element Content

      The aims of this suggestion are:

    1. To be able to specify:

       1. several alternative uris to turn an element into
         replaced content,
       2. several alternative text/uri combinations to be
         flowed in,
       3. a text-only alternative to be flowed in,
       4. that the element's content be flowed in.
       5. that the property is inherited

    2. To be able to resize each of the items listed above
      individually.

   Discussion on www-style resulted in the following
   extended syntax for the content property:

   
 <uri> := "url(" [ <string> | attr(X) ] ")"

 <replaced> := "replaced(" <string> | attr(X) ] ")"

 <text> := [ <string> | <counter> | attr(X) | 
             open-quote | close-quote |
             no-open-quote | no-close-quote ]

 content := [ [ [ <replaced> | <text>* <uri> [ <text> | <uri> ]* ] , ]*
              [ <text> | auto ] ] | inherit

   The suggested content property syntax takes a series of
   uris to be used as replaced content and mixtures of uris
   and text which would flow as the content property defined
   in CSS2.

   Each item brought in as replaced() should be used as a
   source file for making the element into a replaced
   element.

   The UA should try to display each of the given
   possibilities in turn until it finds one that has all
   referenced uris (if any) (a) available and (b) supported.
   The keyword "auto", which is allowed as the last item in
   the comma separated series, indicates that the UA should
   display the contents of the element, if any.

   The "simplest" way of resizing each of the contents
   individually would be to allow comma separated values for
   width/height, each applying to the respective entry in
   the content property that is used. If there is no entry
   in the width/height list then "auto" would be used (going
   the other way doesn't matter, since height/width is
   decided based on content, not the other way around).

   Examples:

      IMG { content: replaced(attr(src)), attr(text); 
         width: attr(width), auto; height: attr(height), auto; }
   OBJECT { content: replaced(attr(data)), auto; }
   IFRAME { content: replaced(attr(src)), replaced(attr(longdesc)), auto; }
   #TITLE { content: replaced("welcome_and_logo.mov"),
                     replaced("welcome_and_logo.jpg"), 
                     "Welcome to " url(logo.gif) " !!",
                     "Welcome to CSS!!"; 
            width: 256px, 300px, auto; 
            height: 64px, 80px, 58px;  }

   Note, when height and width are given but there are less
   heights/widths than contents, missing values are assigned
   "auto". Note that when height/width are *not* given, then
   the cascade may give them a value anyway, and so "auto"
   might not be assumed.

   If the height and width properties are set to specific
   values (not auto), then:

    # If the content has an inherent size then the box
      should be resized and the contents should be scaled to
      fit the box. For example, images (bitmapped or
      vector).
    # If the content does not have an inherent size, for
      example an XML, MathML, or HTML document, then the
      contents act as if they were the contents of a
      block-level box, and act on the value of the overflow
      property.

   If the height and width properties are set to auto and
   the replaced content does not have an inherent size, such
   as a vector graphic, then the results are (for the
   moment) undefined by this suggestion. Also, some types of
   replaced content need scaling that preserves the aspect
   ratio - video for example, see the SMIL spec and the Note
   on SMIL and CSS.

=======-------8<-------=======

The biggest problem with the above suggestion is *what happens if
width or height is overriden by another rule?*

This is *exactly* the same problem as *what happens if color is
overriden by another rule?*, and comes under my title of "Property
Codependency" (tm), a problem for which there is no simple solution at
the moment, AFAIK.

The problem with colours is simple to show. If you use different
background colours for P and Q elements, and different colours for
plain text and the :link and :visited pseudos, say, then you have a
total of six (2*3) possible combinations of colours, which *must* all
be listed explicitly if you wish to prevent another stylesheet in the
cascade applying a background to, say, the Q element, and making the
document unreadable.

i.e., we currently have to say:

   P { color: black; background: white; }
   Q { color: black; background: yellow; }
   P A:link { color: blue; background: white; }
   P A:visited { color: navy; background: white; }
   Q A:link { color: blue; background: yellow; }
   Q A:visited { color: navy; background: yellow; }

and cannot say:

   P { color: black; background: white; }
   Q { color: black; background: yellow; }
   A:link { color: blue; }
   A:visited { color: navy; }

...since with this sheet we are faced with the possibility of another
stylesheet in the cascade applying a background to A:link, and making
the document unreadable.

When you have a stylesheet with around 10 different potential
foreground colours and 4 different background colours, like my
homepage's, then you have to explicitly specify **40** different
rules.

The current solution is simply to actually specify all 40 rules, but
as stylesheets get more complex and start applying to entire sites,
this problem will escalate.

-- 
Ian Hickson

Received on Tuesday, 24 November 1998 10:07:36 UTC