Re: CSS-Tranformation mechanism and modularizing CSS

Almost all concerns I read, have the same problem with the content
property. f.e.:

   IMG[src="x"]:hover {
       @attributes {
           src: "y";
       }
   }
   IMG[src="y"]:hover {
       @attributes {
           src: "x";
       }
   }

has currently the same problem with:

   IMG["x"]:hover {
       content: "y";
   }
   IMG["y"]:hover {
       content: "x";
   }

and this:

> I'd also point out that you're setting the src attribute based on a state
> here - what happens if someone comes in through script and explicitly sets
> the src to something else while you're in that state?  What happens, then,
> when you move the cursor away?  There is a considerable amount of
> specification work that would need to be worked on here, with a model for
> how attributes set through your proposed stylesheet extensions interact
with
> those set in the document and the access through the DOM.

This should also be wondered about the content property.

If somebody has problems concerning changing attributes, that does not
apply to the content property, please send them.

Sjoerd Visscher

----- Original Message -----
From: Ian Hickson <py8ieh@bath.ac.uk>
To: Sjoerd Visscher <sjoerd@heeten.nl>
Cc: www-style <www-style@w3.org>
Sent: Tuesday, October 05, 1999 12:31 AM
Subject: Re: CSS-Tranformation mechanism and modularizing CSS


> On Mon, 4 Oct 1999, Sjoerd Visscher wrote:
>
> > I _know_ that STTS can do all this, but STTS is not going to be
> > implemented in the big browsers. CSS3 on the other hand IS, so it's
> > just waiting until the functionality of STTS is incorporated in
> > CSS3.
>
> So why not just push for STTS to a CSS3 module?
>
>
> > Considering the relatively low amount of extra coding to implement
> > such powerful things as:
> >
> > IMG[src2]:hover {
> >     @attributes {
> >         src: attr(src2);
> >     }
> > }
> >
> > (I can't help it, I really *LOVE* this example)
>
> But, what does that _do_? How does one know that the 'src' attribute
> creates a replaced element?
>
> You are going to need CSS such as:
>
>    IMG { content: replaced(attr(src)); }
>
> ...anyway, so why not just have:
>
>    IMG { content: replaced(attr(src)); }
>    IMG:hover { content: replaced(attr(src2)); }
>
> ...? It is much simpler, cleaner, and requires less coding for the
> implementor than what you suggest. (The replaced() syntax is part of a
> proposal which was thrashed out on the list and made a while back, see
> the www-style past suggestions list.)
>
> Also, it doesn't change the document tree from under the feet of the
> style system. Imagine if you had something like this:
>
>    IMG[src="x"]:hover {
>        @attributes {
>            src: "y";
>        }
>    }
>    IMG[src="y"]:hover {
>        @attributes {
>            src: "x";
>        }
>    }
>
> YAARG!
>
> Unless, of course, you are defining a _transformation_ language, which
> applies before the document is styled. But if that is what you are
> suggesting, then this basically _is_ STTS! (Or XSL with CSS syntax.)
>
>
> > Moreover: consider the way BECSS will be implemented. If an event is
> > fired, the implementation has to check in the CSS-properties if
> > there is a handler defined, and else look in the document tree.
>
> No, it won't. The document tree will only contain the event attributes
> for HTML elements -- just like HTML currently contains <font>.
>
> You seem to be arguing something equivalent to saying "why bother with
> 'color' and 'font' when we could just insert <font> elements using a
> transformation language?". Well, inline events and style are B.A.D.
> (The why of this has been covered already, I won't go over it again.)
>
> In the New World, XML documents are not likely to have style and
> events inline. Events should be taken out of line, such as into a
> BECSS sheet.
>
> --
> Ian Hickson
> "I take a Professor Bullett approach to my answers. There's a high
> probability that they may be right."
>   -- Dr Snow; Mechanics Lecturer at Bath University; 1999-03-04
>

Received on Tuesday, 5 October 1999 07:11:08 UTC