Re: 'role' should be property

Hi Patrick,

I really wasn't trying to start a debate. :) But I do think this is an
interesting topic, so I'll try to answer your questions 'as I see it'.

The core of what I'm getting at is outlined in my blog post, and is
essentially that CSS defines two things--a selection mechanism that
sets properties, and definition of how properties should behave.

So, say we make all div's blue:

  div { background-color: blue; }

We've done two things; the first is to define a rule that creates a
collection of elements, and the second is to 'do something' to those
elements. As we know, this collection of elements is incredibly
flexible, and as div's are added and removed, the collection changes
automatically, and the rules are applied, or 'unapplied' as
appropriate--and that's something we could make use of in all sorts of

These two aspects of CSS--the selection mechanism and the processing
mechanism--are actually quite clearly and distinctly defined, so all I
was suggesting was that we should do some 'spec factoring', just as we
would look to factor a software library when writing code. (In my view
this is something that the W3C doesn't do anywhere near often enough,
so we generally end up with specs that are quite large, and take far
too long.)

Anyway, that's the key idea. But that doesn't mean I disagree with you
that it might be best to call it something unrelated to CSS. I see it
all a bit like the way that XPath was taken out of XSLT, and now can
be used in any other language you like--including XSLT.



On 23/05/07, Patrick H. Lauke <> wrote:
> Mark Birbeck wrote:
> > Semantics are often defined with 'rules', so applying a different set
> > of rules and ending up with different semantics is no big deal at all.
> > The mistake that is consistently made in these discussions is to
> > imagine that an HTML document is only one or two 'layers' deep, when
> > actually there can be a number of different levels of semantics.
> Could you elaborate, with an example perhaps?
> > Also, CSS is essentially two pieces; one is a mechanism that
> > dynamically sets values of properties based on rules, and the second
> > is a set of properties with specific meanings. The latter are
> > generally presentational at the moment, but there is no reason that
> > the first part--the property setting mechanism--couldn't be factored
> > out at some point in the future, to provide a generic way to set
> > properties.
> But then I'd suggest creating a new language, with the same mechanism,
> rather than hijacking CSS.
> > And there is also no reason that some non-presentational
> > properties couldn't be defined.
> Then the name Cascading Style Sheets wouldn't be descriptive of the
> actual language anymore, no?
> >> Therefore a role CSS property would violate the
> >> architecture of CSS and the goal of separating semantics and
> >> presentation, even more so than presentational HTML elements.
> >
> > You're really stretching things, here.
> Saying that CSS could also be used for things that do not concern
> presentation is stretching the original definition of "mechanism for
> adding style (e.g. fonts, colors, spacing) to Web documents", or at the
> very least stretching what "style" is (along the same way that I believe
> XBL's "binding through CSS" idea stretches it).
> P
> --
> Patrick H. Lauke
> ______________________________________________________________
> re·dux (adj.): brought back; returned. used postpositively
> [latin : re-, re- + dux, leader; see duke.]
> |
> ______________________________________________________________
> Co-lead, Web Standards Project (WaSP) Accessibility Task Force
> ______________________________________________________________
> Take it to the streets ... join the WaSP Street Team
> ______________________________________________________________

  Mark Birbeck, formsPlayer | +44 (0) 20 7689 9232 |

  standards. innovation.

Received on Wednesday, 23 May 2007 01:23:27 UTC