W3C home > Mailing lists > Public > www-style@w3.org > November 1998

Re: Display Property Suggestion

From: Ian Hickson <py8ieh@bath.ac.uk>
Date: Sun, 1 Nov 1998 15:41:53 +0000 (GMT)
To: Christian Kaufhold <chka@uni-bremen.de>
cc: www-style@w3.org
Message-ID: <Pine.GSO.4.04.9811011510540.3637-100000@midge.bath.ac.uk>
On Sat, 31 Oct 1998, Christian Kaufhold wrote:
> For replaced elements (not :before and :after), <counter> and quotes are
> not allowed - I don't think it makes sense. So it looks like this:
That`s a bit of an arbitary limitation. Why should "attr()" be allowed but
not "quote"?! How would you quote the attribute?

And why make a distinction between the values allowed for :before and
normal elements?

Don`t forget that we have no way of knowing what future XML lanuage will
be like, and authors may well choose to write <QUOTE text="The quote"/>
which requires `content` to accept quotes to display content (note, I
disagree with this use, but there is no reason why we should limit

>    [ [ <string> | <uri> | attr(X) ]* ,]*
>      [ <string> | attr(X) ]*
>      | inherit
> This way, you
> a) have to provide an alternative without an uri, so that something
> reasonable is always displayed,
Actually, what you quote would allow a completely blank value (you
probably meant to use "+" not "*" on the second line).

However, this is actually a _bad_ thing. There are some decorative images
that *must not* have alternative text, sicne it makes no sense to litter
the text browser with irrelevant descriptions of stars and bullets or
whatever. Corner graphics, for example.

> b) the first uris can also be combined with text.
How do you render replaced content with text?!

The whole point of replaced content is that it`s unrelated to the outside
document, as it were, being merely a box as far as the renderer is
concerned. If you have attached text, you then have to define how it is
rendered, and the only sensible way I see is the way that `content` is
*currently* rendered, that is, *not* as replaced content.

Originally I was going to suggest allowing text as well as <uri>, in
fact, but I could not see any logical way of rendering it.

Another problem is that the whole point of having multiple values is that
if one cannot be drawn then you fall onto the next one, until you get to
the last value in the `content` list, which is text-based (or a mixture
of text and uri). If you allow text first, as your suggestion does, then
it allows for the content value " attr(alt), uri(xyz) ", which would be
pointless (the uri would *never* be shown) while still being valid.

>> 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.
> I would still suggest to use some keyword, because I think a list that
> ends with a comma is ugly, and this syntax might easily lead to
> mistakes.
Fair enough.

In that case I suggest

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

...so we only allow uris first, which results in the element becoming a
replaced element with that uri, trying each one in turn until a supported
one is found, and failing that the content property works as it does now,
except if the "auto" keyword is used, which indicates that the content of
the property as specified by the document should be used.

 * { content: auto; }
 IMG { content: uri(attr(src)), attr(alt); }
 Q:before { content: open-quote; }
 Q:after { content: close-quote; }
 OBJECT { content: uri(attr(data)), auto; }
 IFRAME { content: uri(attr(src)), uri(attr(longdesc)), auto; }

Ian Hickson
Received on Sunday, 1 November 1998 10:41:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:48 UTC