The first version of the NSAC api (see
https://groups.google.com/d/msg/css4j-devel/_HDhplPEvic/JDITUjYrAQAJ) allowed to extend
W3C's SAC to be able to handle level 4 selectors and level 3 values. However, for the API to be of general usefulness the
Parser interface has to be extended. This post describes the parser extensions that have been added to NSAC (and its reference implementation) in the current
core CSS4J Git tree.
Parser Flags
To let the parser be configurable, two methods were added to the Parser interface:
where Flag is an enumeration that currently only contains the STARHACK flag.
When STARHACK is set, the parser will handle asterisk-prefixed property names as accepted names. This hack (that targets old IE browsers) is ubiquitous in present-day websites, and until now it was producing 'unexpected character' errors in SAC/NSAC because the property names are not valid according to the specification. However, these declarations weren't real mistakes and the style authors wanted them to be there. That meant that for some use cases, the API wasn't really useful.
Now in CSS4J's object model implementation, when a style sheet is created from a factory that is in LENIENT mode the STARHACK is automatically enabled, allowing it to handle those sheets.
Rule Parsing
The original SAC api includes this method:
void parseRule(InputSource)
The method can be used to parse individual rules, like those supplied to the CSSOM's
CSSStyleSheet insertRule method:
int insertRule(String, int)
However, when a rule that contains a namespace prefix is parsed, the style sheet may contain the appropriate CSSNamespaceRule for that prefix, but the newly-created Parser is not going to know about it. To be able to handle that case, NSAC adds the following method to the Parser interface:
void parseRule(InputSource, NamespaceMap)
where NamespaceMap is a simple sub-interface that just gives the namespace URI associated to a prefix:
String getNamespaceURI(String)
As always, comments/feedback are encouraged.