CSS Progress

CSS status in trunk as of 9.19.2006

What works now

Parsing css file at compile time
Runtime performance is highly optimized
Inline stylesheets
Selectors
- element selectors
- id selectors
- attribute equals (but not attribute kind-of equals)
- descendant selectors
- compound tag[attr="val"] selectors
Rules
Specificity
- Pretty carefully implemented to the odd strange specificiation
Paradigm: "pull" styles only, not "push" styles
- $style constraints
- LzCSSStyle.getComputedStyle().getPropertyValue()
- css styles are applied on demand only, that is, by $style constraints or when the user looks up a style with the style api then sets an attribute.

LPP-2602 font formatting with $style is broken
- scheduled for a fix soon
LPP-2620 CSS: Support class#id selectors
- deferred to seaswirl
Needs investigation, probably invalid/fixed
- LPP-2575 Simplelayout and CSS styles don't interact as expected
- LPP-2633 Will it work solo-ized?
- Universal selector *

Some selectors
- .class
- sibling selectors E + F
- attribute present without regard to value E[foo]
- attribute ~=
- attribute !=
- language E:lang(c)
- pseudo-elements
- pseudo-classes
- direct descendant E > F
stylesheet src= (work in progress, LPP-2538)
stylesheet as command line argument
stylesheet as url param
style= attribute on views
"Push" styles
- Normal CSS applies styles to objects by fiat; in normal css, objects don't have to "pull" in style value.
Styleable components
.class selector
- left out on purpose
- html-specific

Need to calculate size that CSS adds to LFC
Performance
- So far diamond is satisified with performance
- LPP-2617 CSS: use ConstructorMap from LaszloInitiator to look up class name != tag name
Actually change styles at runtime
~8 separate tests can and should be gathered up into a single test file (without losing atomicity)
Write more of the formal W3C api
- 1/2 writing accessors, which is easy
- 1/2 writing runtime changes, which might be hard