RE: Property suggestions

> -----Original Message-----
> From: Ian Hickson [mailto:py8ieh@bath.ac.uk]
> Sent: Tuesday, October 20, 1998 3:18 PM
> To: braden@endoframe.com
> Cc: Christian Kaufhold; www-style@w3.org
> Subject: RE: Property suggestions
>
>
> On Tue, 20 Oct 1998, Braden N. McDaniel wrote:
> >> I would not use "tooltip" (to present a tooltip over the element)
> >> as a pseudo-element, as it has been suggested, but create it as a
> >> new property. I also suggest a property "status" whose content is
> >> displayed in the status line of the browser, and which takes
> >> exactly the same values.
> > The problem I have with these kinds of things is that they operate
> > *outside* the context of the page formatting and layout.
> With all due respect, Braden, you've missed the point. ;-)
>
> 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).

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.

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. But
"status" is even more context-specific--it assumes a place for status
messages. I submit that that required assumption is beyond the scope of the
currently defined media types.

> *That* is what the "tooltip" and "status" properties would be useful
> for. Sure, they can be _abused_ -- but so can CSS2 generated content
> and CSS1's display:none. (How? You can use it to spam search engines
> without affecting your page's layout).
>
> > Thus, I don't think they're appropriate additions to a page layout
> > language. The larger problem is that you're using style sheets for
> > *content*. The content belongs in the document. We started down this
> > slippery slope with generated content in CSS2; it is a very
> > easily-abused feature. Generated content should only be used for
> > content that has a superficial role and is non-essential.
> 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. There is no such analogous means for browsers to
generate "appropriate" content.

> > What you describe would be more appropriate as attributes on
> > elements in the markup itself. I'd suggest you bring this up as an
> > idea for HTML 5.
>
> It's already _in_ HTML and XML, as you point out: for example, the
> TITLE attribute.

No, that's a TITLE attribute. Browsers just use it as tooltip text.

> The problem is in getting the content out of the
> document and into the right interface elements, in this case the
> tooltip.

Which is why you need a viewing application that is aware of the markup
language. It is not sufficient for it just to be familiar with the parent
metalanguage. Copying content to a style sheet to achieve this kind of
effect is just a hack.

> For example, take the <A> element of HTML (but assume we are talking
> about XML!). Presumably the UA knows that it is a link because of the
> X-Link spec, and knows that the HREF attribute is the target uri.
> However, how does it know what to do with the "title" attribute?

It should do "something intelligent" with it. A tooltip is one option. I'd
suggest that what you're really looking for is an XML-aware UI design
language.

> What
> about the "type" attribute?

Again, "something intelligent." I would agree that, in this case, that is
probably an inadequate specification. IMO, at least, there is a stark
ambiguity between the purpose of this attribute and that of the MIME type
information sent by the server.

> This is what these properties would aim to
> solve.

Okay, but I think attaching these things to a page layout language is
inappropriate.

> Take the examples:
> >> * { tooltip:attr(title) }
> This is the current behaviour of IE4.
>
> >> a[href] { status:"Link to " attr(href) }
> This is similar to the behaviour of IE4 too, but allows for site by
> site customization (pretty much a requirement with XML, as discussed
> above).
>
> >> blockquote,q[cite] { status:"Quotation from " attr(cite) }
> A distinct improvement on IE4, and one which with this property we
> would not have to worry about MS not implementing.

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. I am far from convinced that it is a good idea to extend CSS to be
a UI design language. Perhaps I could be swayed by a broader proposal which
addresses more of the diverse ways a UI could be extended to complement
particular features of a document. I don't mean that just as a challenge...
I'm sitting here trying to convince myself. I'll share my food for thought:
How might CSS express desirable behaviors for the LINK element?

Braden

<http://www.endoframe.com>

Received on Wednesday, 21 October 1998 00:33:46 UTC