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

RE: Property suggestions

From: Ian Hickson <py8ieh@bath.ac.uk>
Date: Wed, 21 Oct 1998 15:39:34 +0100 (BST)
To: braden@endoframe.com
cc: Christian Kaufhold <chka@uni-bremen.de>, www-style@w3.org
Message-ID: <Pine.GSO.4.04.9810211423510.15032-100000@amos.bath.ac.uk>
On Wed, 21 Oct 1998, Braden N. McDaniel wrote:
>> The _content_ is in the document, in the TITLE, CITE, DATETIME,
>> SUMMARY, etc, attributes.
>> But in XML, there is no way to tell the UA _which_ attributes
>> contain _what_! So what would an XML UA put in the tooltip?
> That is the principle argument in favor of continuing to develop
> HTML as an XML application: we need a lingua franca for document
> markup, and HTML might as well be it (established base thing and
> all).
Yes -- but you still have the problem of having to hard code expected

> For an arbitrary application of XML, the answer is that the viewing
> application must be aware of the "intent" of certain constructs
> expressed by the DTD.

> OR... We could a have some declarative means of expressing these
> things. I am not opposed to such a mechanism. I do think that
> tacking it onto CSS ad hoc is a bad idea.
Depends on each individual item.

How a link in it's different states (link vs visited) is drawn, is
IMHO relevant to CSS. Where the input devices are in relation to the
elements is IMHO also relevant to CSS (active, hover, focus). Ditto
tooltip and status.

> The notion of a "tooltip" is a very context-specific thing. It
> assumes the presence of a pointing device, or at least a concept of
> "focus". That's not so bad, I suppose -- the "hover" pseudo-class
> makes similar assumptions.
And "color" assumes we are using a color device. And "richness"
assumes we are using a speech synthesiser.

> But "status" is even more context-specific -- it assumes a place for
> status messages.
IMHO, actually, status is _less_ specific than tooltip. "status" also
applies to speech-based systems. Take, for instance:

[title] { play-during: url("hum.mp3") mix; status: attr(title); }

<P>The <ACRONYM title="World Wide Web Consortium">W3C</ACRONYM> was
founded in October 1994.</P>

When playing that back, the UA will play a background humming when
speaking the acronym "W3C". If the user says "Status" when that is
happening, then the UA could interrupt itself and say "World Wide Web

> I submit that that required assumption is beyond the scope of the
> currently defined media types.
Certainly in the case of "status", the required assumptions are
practically zero.

Tooltip may be harder to argue for, in which case I suggest finding
another word which is less specific to visual interactive media.

>> Would you say that CSS2's table display properties were
>> "non-essential"?
> That is not a valid comparison. Even in absence of actual support
> for the CSS2 table properties, browsers can use their own means of
> appropriately formatting a table.
Given that they don't know which element represents a
row/column/table, how can they format the table?

> There is no such analogous means for browsers to generate
> "appropriate" content.
We are not generating content.

In all examples given so far, the content has come from the document,
by use of the "attr()" CSS function.
> Which is why you need a viewing application that is aware of the
> markup language. [...] Copying content to a style sheet to achieve
> this kind of effect is just a hack.
In some cases, eg, Links, I would agree. However, status information
seems to me to be well placed in CSS.

>> For example, take the <A> element of HTML. [..] How does [the UA]
>> know what to do with the "title" attribute?
> It should do "something intelligent" with it.
It can't do anything if it doesn't know it's additional information.
At least with X-Link it knows that HREF is the target uri.

Should the UA do something intelligent with BGCOLOR="#FFFF00"? How
would it know that one is a color and the other is additional
information for a tooltip or other status reporting device?

> I think attaching these things to a page layout language is
> inappropriate.
CSS isn't limited to "Page Layout". Aural properties don't even have a
page, for instance.

> The mechanism for generating content present in CSS2 differs in a
> fundamental way from these suggestions: it is generating content
> *inside* the document, these suggestions deal with UI elements
> *outside* the document.
Is the cursor property generating content "inside" the document?

> I am far from convinced that it is a good idea to extend CSS to be a
> UI design language.
Too late. Look at IE.

> How might CSS express desirable behaviors for the LINK element?
Good question. I would have thought that would have a better place in
X-Link, though.

Another question is how would CSS decide how to render <INPUT> ?

Ian Hickson
Received on Wednesday, 21 October 1998 10:39:45 UTC

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