W3C home > Mailing lists > Public > www-style@w3.org > February 2012

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

From: Alexis Menard <alexis.menard@openbossa.org>
Date: Fri, 3 Feb 2012 15:36:45 -0300
Message-ID: <CACh0f5hCC0Fxz19dMrimbDd59aQDNg-4ToLFRD270gTwdDVn=A@mail.gmail.com>
To: Brian Manthos <brianman@microsoft.com>
Cc: www-style@w3.org
On Wed, Feb 1, 2012 at 7:48 PM, Brian Manthos <brianman@microsoft.com> wrote:
> Boris:
>> But that has nothing to do with length and item() behavior, a priori.
>> There are plenty of other cases where a property exists but is not
>> reflected in length/item (e.g all nodelists have such properties, JS
>> arrays have properties not reflected in the length, etc).
>
> I have to think about this some more.  My gut reaction is that I think it's weird to have valid .propertyName count > item() count.
>
>
> Example A (CSS 3)
>        box-shadow: 1px 2px 3px 4px red;
> Example B (CSS 7)
>        box-shadow-x: 1px;
>        box-shadow-y: 2px;
>        box-shadow-b: 3px;
>        box-shadow-s: 4px;
>        box-shadow-c: red;
>
>
> --- Brian's description:
> Available by name:
> A       boxShadow
> B       boxShadow, boxShadowX, boxShadowY, boxShadowB, boxShadowS, boxShadowC
> Available by item():
> A       boxShadow
> B       boxShadow, boxShadowX, boxShadowY, boxShadowB, boxShadowS, boxShadowC
> Length:
> A       1
> B       6 (gain 5)
>
>
> --- Boris's proposal:
> Available by name:
> A       boxShadow
> B       boxShadow, boxShadowX, boxShadowY, boxShadowB, boxShadowS, boxShadowC
> Available by item():
> A       boxShadow
> B       boxShadowX, boxShadowY, boxShadowB, boxShadowS, boxShadowC
> Length:
> A       1
> B       5 (gain 5, lose 1)

To me, a shorthand is a shortcut to set the longhands, it was made for
that, to avoid verbose CSS and also improves speed (faster parsing and
so on) and memory usage. It's *convenience*.

I don't think they should be represented in the OM, they are not real
properties of an object : the bottom-top-color, bottom-left-color, ...
are real property of my border. In a similar example, a square has
left side, a right side, a bottom side and a top side (very abstract
here) but has no such "sides" characteristic.

I don't think having a shorthand part of item() brings any benefit :
the only thing useful you can get if this entry exists is to get the
shorthand cssText but you can get it with
getPropertyValue('myshorthand').

I would say that the length of a style declaration should match with
the number of items item() could retrieve as you want to iterate in a
for loop using the length to go through all entries.

I think at any time you can query a shorthand by name and get a value
(that UA can compute from longhands) with getPropertyValue.

So to conclude I think we should set the longhands when we encounter a
shorthand and the latter only are part of the OM as they actually
represent the state of an element. Shorthands are just a *shorter* way
to express this state.

border: 1px solid red;

would "expand" to :

border-top-width: 1px;
border-right-width: 1px;
border-bottom-width: 1px;
border-left-width: 1px;
border-top-style: solid;
border-right-style: solid;
border-bottom-style: solid;
border-left-style: solid;
border-top-color: red;
border-right-color: red;
border-bottom-color: red;
border-left-color: red;

Length : 12

border-color, border-width, border-style shorthand are totally
possible to query from getPropertyValue. If the shorthand is
impossible to construct (like conflicting border declaration, e.g
border-right: 10px thin green) then the shorthand should be empty (btw
checking the code today it's what WebKit is doing). Again using the
shorthand from getPropertyValue is a convenience.

See that way if the shorthand concept didn't exist could you achieve
the same result as today? Yes, so in any case they are not critical
and does not represent the way an element is described therefore they
should not be part of its object representation.

-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
Received on Friday, 3 February 2012 18:37:14 GMT

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