Re: [css-shapes][cssom] Serializing Shape Values

On Sep 30, 2013, at 8:16 PM, Bear Travis <> wrote:

>>> The specification says "computed lengths for <basic-shape>, the image
>>> with its URI made absolute, otherwise as specified". A often used
>>> pattern is:
>>> "as specified, but with URIs made absolute".
>>> The thing that  bothers me on "computed lengths for <basic-shape>" is
>>> that it requires transforming <percentage> to <length>. This seems not
>>> to be correct at the point.
>> I agree. That sounds more like a "used value" rather than a computed
>> value.
> There was a discussion about this a couple weeks ago, the resolution being
> that the computed value of a shape with percentages maintained those
> percentages. [1] I think previous readings of that "computed lengths" has
> been "computed values of the shape args." This is probably something that
> should be verified by the spec authors.
>>> To answer your question. "as specified" for your examples means:
>>> 'rectangle(1px, 2px, 3px, 4px, 0, 0)' to 'rectangle(1px, 2px, 3px, 4px,
>>> 0px, 0px)'
>>> (but 'rectangle(1px, 2px, 3px, 4px)' to 'rectangle(1px, 2px, 3px, 4px)')
>>> 'rectangle(1px, 2px, 3px, 4px, 5px, 5px)' to 'rectangle(1px, 2px, 3px,
>>> 4px, 5px, 5px)'
>>> 'polygon(nonzero, 1px 2px)' to 'polygon(nonzero, 1px 2px)'
>>> Because that is what the user specified.
> The question I'm trying to understand here is what are the serialization
> rules for shapes? The CSSOM spec does not specify how a <shape> value is
> serialized [2], or, barring that, how a value in functional notation with
> optional arguments is serialized. My understanding is that all equivalent
> values should be serialized to the same value, and that value is what is
> returned by getPropertyValue.
> For example, the following are all equivalent shapes:
> rectangle(1px, 2px, 3px, 4px)
> rectangle(1px, 2px, 3px, 4px, 0)
> rectangle(1px, 2px, 3px, 4px, 0, 0)
> And should therefore return the same value via getPropertyValue.
> I could see either going the way of "optional parameters with a
> non-default value are dropped in the serialization" or "all parameters
> take part in the serialization".

I see what you mean. I am not sure if there is a need to specify more as saying "as specified" which already states that it should be returned as the author specified it. In this case having optional arguments or not (even if zero) makes a difference on the serialized string.


> -Bear
> [1]
> [2]

Received on Monday, 30 September 2013 18:31:47 UTC