Re: [css3-values] RE: CSSStyleDeclaration#length and shorthands.

Coming in a bit late here, I thought maybe I could try to summarize the issues:

(1) What happens when shorthand properties are parsed out of a style
and converted to the browser's internal representation?

There seems to be consensus of implementations that only longhand
property values are stored internally. Some browsers also store the
original cssText. I'd be interested to know if these browsers maintain
a per-longhand-value mapping back to the shorthand value that was used
to set the longhand value (if any).

(2) How should the browser's internal representation be displayed to
Javascript via the OM in terms of which items should be set?

There again seems to be a consensus of implementations that the
internal representation should be mapped directly onto the OM - i.e.
any values which are set internally should be displayed in the OM. Of
course, there isn't clear consensus about what that internal
representation should be, so actual results differ.

There are a few proposals for alternative behaviours:
(a) mirroring the input css text exactly. Glenn points out there is
some support for this in the specifications, however I think the
quoted sections are ambiguous at best.
(b) providing both the longhand and author-set shorthand values.
(c) reconstructing all possible (for some value of possible) shorthand
values and providing these along with the longhand values.

I would personally prefer to avoid (a) as it elides information from
the OM that has already been computed by the browser - i.e. what the
values of the various longhand properties are for a given style rule.

(3) How should the browser's internal representation be displayed to
Javascript via the OM in terms of what cssText should be?

There are three different approaches currently in use:
(a) retain the input cssText
(b) report only longhand values through cssText
(c) regenerate shorthand values from the internal representation

I think this result should match the output of (2), but obviously this
won't work if both shorthand and their accompanying longhand values
are reported in the items list.

(4) What does this mean for inherit and initial when applied to
shorthand properties?

This thread seems to be settling on expanding the shorthand properties
and storing inherit or initial against each impacted longhand property
internally. This is consistent with all of (1), (2) and (3).

I'd also like to introduce a further question: Which of these things
should be specified (and therefore made consistent) inside the CSSOM
spec? I think it would be difficult to specify what internal
representation CSS engines should use, but I do think we can and
should try to ensure that the same css text (if conformant with the
specification) has the same CSSOM representation in all browsers.

Cheers,
    -Shane

On Tue, Jan 31, 2012 at 8:49 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 1/31/12 11:40 PM, Glenn Adams wrote:
>>
>> Three UAs retain the original cssText, excepting Safari which translates
>> to the longhand properties only.
>
>
> Your test doesn't show that, actually.  What it _does_ show is that at least
> three UAs try to produce shorthands in cssText.
>
> I know for a fact that Gecko does NOT retain the original cssText here.  It
> stores longhands internally, and tries to produce the shortest text
> representation it can for cssText.
>
> The only way to tell what UAs are really doing here is to try multiple
> different values of the original cssText and see what happens to it.  In
> addition to the shorthand you tried, you should also try "border-top-width:
> 2px; border-right-width: 4px; border-bottom-width: 2px; border-left-width:
> 4px" (which won't change the output in gecko and WebKit; not sure about the
> others), and perhaps things like "border-width: 3px 4px;
> border-bottom-width: 2px; border-top-width: 2px" and so forth....
>
>
>> Three UAs also report 4 items, including those that return only one
>> shorthand property in cssText.
>
>
> The only reason Gecko reports more than 4 is that our implementation of
> border-start and border-end involves a few extra longhand properties dealing
> with border widths, and the border-width shorthand sets those additional
> longhand properties.
>
>
>> There are clearly some interoperability requirements here that need to
>> be resolved in both CSSOM and in the UAs.
>
>
> Yep.
>
> -Boris
>

Received on Wednesday, 1 February 2012 06:37:07 UTC