W3C home > Mailing lists > Public > www-style@w3.org > August 2011

[CSSOM] some feedback on serialization

From: Brian Manthos <brianman@microsoft.com>
Date: Fri, 19 Aug 2011 02:20:43 +0000
To: "Anne van Kesteren (annevk@opera.com)" <annevk@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D17124CED@TK5EX14MBXC264.redmond.corp.microsoft.com>
As requested...

http://dev.w3.org/csswg/cssom/

3.1
#To serialize a URL means to create a string represented by "url(",
#followed by the string escaped value of the given string, followed by ")".

There is much variety among implementations, mostly involving adding wrapping double-quotes or single-quotes.  Is this spec intending to make normative that such wrapping must not be present?


6.5.1 - IDL attribute / CSS property table
Needs updating for CSS3.

New properties that come to mind quickly:
- background-clip
- background-origin
- background-size
- border-image
- border-radius (and individual corners)
- box-shadow
- opacity


6.6.2
# Where multiple CSS component values can appear in any order
# without changing the meaning of the value (typically represented
# by a double bar || in the value syntax), use the order as given in
# the syntax.

Many (all?) CSS3 modules appear to be paying no attention to this expectation at all.  As this specification becomes normative, that twist needs to be disseminated clearly and broadly so that all active specification will take it into account when deciding on the grammar and syntax ordering.


6.6.2
# If this would remove all the values, then include the first allowed value.

Much like the previous spec snippet, this one needs to be broadly known and accounted for.

Fortunately, my original example case has been fixed:
http://www.w3.org/TR/css3-background/

# background: [ <bg-layer> , ]* <final-bg-layer>
# <bg-layer> = <bg-image> || <bg-position> [ / <bg-size> ]? || <repeat-style> || <attachment> || <box>{1,2}
# <final-bg-layer> = <bg-image> || <bg-position> [ / <bg-size> ]? || <repeat-style> || <attachment> || <box>{1,2} || <'background-color'>

Example:
input - background: none, none;
output - background: none, none;

My recollection is that in an earlier version of the B&B spec the proper output would have been:
output - background: none, transparent;


6.6.2
#  <color>
Strongly recommend that (when the blank is filled in) the specification is clear whether or not rgba and hsla functional syntax should treat the parameters as comma separated lists.  More specifically, the spec should be crisp about whether each comma should be followed by a space (for readability) or not (for brevity).


6.6.2
# <angle>
# The number of degrees serialized as per <number> followed by the literal string "deg".
# <length>
# A length of zero is represented by the literal string "0px".
# <time>
# The time in seconds serialized as per <number> followed by the literal string "s".

I think this is a bad idea.

If the input has units, then the original units should be retained in the serialized output.
If the input does not have units, then there should be no units in the serialized output.


6.6.2
# <shape>
# The string "rect(", followed by the result of serializing the serialized CSS
# component values belonging to <shape> as list, followed by ")" (U+0029).
Much like my comment about <color> above, a decision should be made whether the parameters should be treated as a comma separated list or not.  The current phrasing "list" could mean space-separated, comma-seperated, or something else (commas without spaces?).


6.6.2.1
# Before		After
# background: none	background: rgba(0, 0, 0, 0)
This example is incorrect in one way and (IMO) undesirable in another.

It's incorrect because <bg-image> is the first entry in the <final-bg-layer> (as well as in the <bg-layer>) grammar.

It's undesirable, IMO, because the initial value (keyword 'transparent') is not being preserved.


6.6.2.1
# Before		After
# azimuth: behind  left	azimuth: 220deg
# azimuth: leftwards	leftwards
Undesirable, IMO, as per the <angle> commentary above about preserving the authored value.

Further, the leftwards example shows that some keyword syntaxes are preserved while others are not.  This inconsistency is also undesirable.


6.6.2.1
# Before		After
# content: url('h)i') '\[\]'	content: url("h)i") "[]"
This doesn't match the 3.1 serialization rules because (a) the wrapping double-quotes should be omitted and (b) the special characters should be escaped.


6.6.2.1
# Before			After
# color: rgb(18, 52, 86)		color: #123456
# color: rgba(000001, 0, 0, 1)	color: #000000
Once again preserving the authored value is strongly preferred, IMO.

Also, rgba should serialize as hash-prefixed six-digit hex when the alpha channel happens to be 1 but something else when the alpha channel is not 1?  AT best it's confusing.
Received on Friday, 19 August 2011 02:21:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:43 GMT