RE: Why aren't styled language repsonsible for pseudo-classes?

Excellent points, Orion. If I might just add a comment or two:

> It would make sense to me that the underlying languages that 
> are being styled specify the pseudoclasses they allow. Having 
> CSS specify them seems to limit the number of pseudoclasses 
> artificially and complicate the CSS system for all styled documents.

I could not agree more! XForms requires a few pseudo-classes, yet they are
still not available in any full recommendation.


> Personally, I would have liked it if CSS didn't specify 
> selectors either so it could work with non-tree based 
> languages. It seems like a restriction based on it's  tight 
> coupling with HTML, the only real language it was meant to style.

Actually the basic architecture of CSS is not so bad -- it distinguishes
between the addressing and processing models, and keeps things suitably
abstract that you could replace the addressing model and retain the
processing model. I wrote on similar themes in a blog a few months ago:

  It would seem pretty straightforward to me to take the first step of
  breaking the CSS processing and addressing mechanisms away from the
  actual properties themselves. If the selection mechanism was distinct
  from the styling properties it would be both easy and manageable to
  allow different groups to produce different sets of these properties
  for their different specifications. [1]

In other words, we have multiple selection languages (at least CSS selectors
and XPath, for now), we have one processing model, and then we have many,
many, small specifications that specify the properties. Using mechanisms
similar to the way that the DOM is extended (getFeature(), etc.) we could
easily tell what features a DOM supports.

The root problem is that people are still thinking of 'traditional' browsers
being these big monsters that 'know' everything. However, the browser of the
future will have a very different architecture. A 'XAML browser', for
example, will be very different, allowing authors to bind objects at
run-time to the language, and extending the language allows you to add new
objects.  Our own browser, Sidewinder, takes a similar approach, but uses
standard languages to do it -- we've focused on the 'framework', managing
the relationship between XHTML and plug-ins for XForms, SVG and MathML, all
from different vendors. The Mozilla guys have also taken the 'plug-in'
approach quite seriously, and FireFox supports XForms via this method.

Whether these new architectures are 'right' or not, only time will tell. But
one thing I can say is that with the current interest in 'compound
documents' and building browsers that use a plug-in architecture, the
current CSS approach is extremely outdated.


> Moving on though, if the underlying language provide the 
> pseudoclasses, then CSS could purge itself of it's few and 
> let each language do the work for it. It already has to 
> communicate with the language. This way any language can 
> implement certain funtionality and get pseudoclass support.

Exactly! For example, with XForms, it's the XForms processor that must set
the values of read-only, enabled, and so on, based on complex conditions in
the model (using XPath). So, as you rightly point out, why bother defining
those things in CSS? It just makes the whole standards process more
difficult:

  As it happens, [...]. I'm not really saying that this gatekeeper role
  is desired by the CSS group -- after all, they need to be superhuman
  to keep up with the demand for new features in such a diverse range of
  disciplines, from speech, to vector graphics, mathematical mark-up,
  and of course forms. But desired or not, this gatekeeper role is a
  direct consequence of the unnecessarily over-centralised nature of the
  CSS standard

(Sorry for quoting myself twice!)


> I'm also leaning towards pseudo-elements being done this way, 
> but I'm not there yet.

You're instincts are right...they would definitely come out. For example, in
XForms we need a pseudo-element for the rows in a xf:repeat. And yet, as
with the pseudo-classes, this is still not available in a formal 'full'
recommendation.

Regards,

Mark

[1]
http://internet-apps.blogspot.com/2005/04/css-xforms-dependency-engine-and.h
tml

Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Tuesday, 5 July 2005 10:35:38 UTC