In theory much of the hard coded style mapping logic that provides navigator or html behaviors can be replaced with attribute selector style rules.

Don't get too excited about doing this. First, this only works for simple boolean attributes, not the general case. ie: you can't turn <font face="foo"> into font[face] { font-family: attr(face); } because in CSS the attribute function in only legal for the content property. (and you dont want to do: font[size=1] {font-size: xx-small} font[size=2] { font-size: x-small} ... can you say rule explosion?) Secondly, speed is king. HTML attribute mapping code is MUCH faster than CSS attribute selectors. It uses atom based attribute access paths (blazing) where CSS must use nsString based APIs (many string compares). Also, there's a fast GetContentStyleRule() call to determine the attribute mapping function versus a full on CSS rule cascade and selector match... Also, the more rules we dump into ua.css the slower style resolution gets. This is mostly migigated by several hashing functions, but more is still more...

The other problem is that the weights in the style cascading are wrong. The order of the cascade (from least important to most is): ua.css user presentational HTML author author-!important user-!important so you would need a way of stepping above the user stylesheet.

See bug 2942.

I did some work recently that accomplished 99% of what I wanted here, so I'm closing the bugs. If other cases show up then we can file bugs on them and fix them then.

Kipp: Could you please mark this as verified fixed as this is more code oriented. Thanks