Package io.sf.carte.doc.style.css.nsac


package io.sf.carte.doc.style.css.nsac
NSAC: a non-standard revision to W3C's SAC api.

NSAC 2

NSAC 1.0 was intended to be an easy upgrade path for SAC users, and it preserved most of SAC. That 1.0 API was not convenient for modern CSS, however, so NSAC 2 was written as a better replacement.

The SAC jar file is no longer necessary, as NSAC 2 contains all the required classes and interfaces.

Selector Serialization

Implementations of the selector interfaces are not required to provide a toString() serialization, although the reference implementation (the doc.style.css.parser package) does. It is not recommended to use it for serialization, however, as it may not reflect namespace changes made after the parsing took place (i.e. changing the namespace prefix). The rule serialization in the Object Model implementation of css4j does account for that, and it does not use the selector's toString().

If you combine NSAC with your own Object Model code, you may want to follow the same approach and serialize the selectors yourself.

Parser Flags

To let the parser be configurable, two methods were added to the Parser interface:

void setFlag(Flag)

void unsetFlag(Flag)

where Flag is a flag from an enumeration:

  • STARHACK. 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 in plain SAC parsers it was producing 'unexpected character' errors 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.
  • IEVALUES accepts values with some IE hacks like IE expressions (progid included), and also values ending with \9 and \0. The non-standard values produce LexicalType.COMPAT_IDENT values as a result.
  • IEPRIO accepts values with the !ie priority hack, and again produces LexicalType.COMPAT_IDENT values.
  • IEPRIOCHAR accepts values with the !important! priority hack, and instead produces LexicalType.COMPAT_PRIO values.

LexicalUnit Extensions

Some of the above Internet Explorer compatibility flags require the use of two pseudo-values that do not follow standard CSS syntax:

  • COMPAT_IDENT values are produced only when the IEVALUES and IEPRIO flags are used, and contain ident-like values.
  • COMPAT_PRIO values are produced by the IEPRIOCHAR flag, representing values that its compatible browser interprets as being of !important priority.

Caution is advised when using these compatibility pseudo-values, as they may conflict with syntax-conformant values.

This software includes material derived from SAC (https://www.w3.org/TR/SAC/). Copyright © 1999,2000 W3C® (MIT, INRIA, Keio).