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

On Wed, Feb 1, 2012 at 3:36 AM, Shane Stephens <shans@google.com> wrote:
> 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).

WebKit stores only the longhands today (except for inherit or initial,
buggy to me, which is why I sent my email).

>
> (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

(c) is what WebKit does today, it seems slightly more efficient memory
wise (you don't store the cssText of the shorthand and the shorthand
is not part of the OM).

>
> 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 think it is the sensible approach to me.

>
> 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.

What I would like to see specify is what should be in CSSOM for a
shorthand : all longhands? all longhands + the shorthand? just the
shorthand (strange)? The way each UA achieve whatever will be written
on the spec is up to us UA implementors to figure that out.

>
> 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
>>
>



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil

Received on Wednesday, 1 February 2012 10:43:44 UTC