Escaped hex serialization is not list-safe
carlosame opened this issue · comments
The current serialization for hex-escaped CSS identifiers is convenient because it mostly preserves the way that the identifier was specified, but unfortunately this has a few side effects. When an hex-escaped identifier is specified in a context where the final white space is not necessary, and then reused later in another context, this could lead to bugs.
Consider the following sequence of identifiers being used to specify font-family:
font-family: Font Awesome \\35;The last identifier does not have a trailing space because it is not needed there. However, if we retrieve the property value as a list and add a new value:
ValueList list = (ValueList) style.getPropertyCSSValue("font-family");
StyleValue value = (new ValueFactory()).parseProperty("Free");
list.add(value);
System.out.println(list.getCssText());the result would be Font Awesome \\35 Free, which unescaped is Font Awesome 5Free instead of the expected Font Awesome 5 Free.
The above example is a bit forced, but the behaviour is not compliant with the specification. The problem affects whitespace-separated value lists, including space-separated bracket lists (although I do not expect that a lot of grid lines are going to have hex-escaped names).
With the new serialization, downstream projects may need to revise their css4j-related unit tests if they involve hex-escaped identifiers. Closing.