- From: Brian Manthos <brianman@microsoft.com>
- Date: Fri, 3 Feb 2012 21:31:44 +0000
- To: 'Alexis Menard' <alexis.menard@openbossa.org>
- CC: "www-style@w3.org" <www-style@w3.org>
Alexis:
> I don't think having a shorthand part of item() brings any benefit :
Sure it does. Keeping (constructible) shorthands accessible by item() index means that you're talking about 1 collection with predictable behavior.
Having access-by-index and access-by-name supporting different sets is a weird collection model, IMO.
Alexis:
> I think at any time you can query a shorthand by name and get a value
> (that UA can compute from longhands) with getPropertyValue.
Only constructible ones. Shorthand-unfriendly disjoint state prevents that in some cases, as previously shown.
Alexis:
> 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.
I don't see how this speaks to the example you quoted.
When something becomes a shorthand in the future, it's a compatibility breaking change.
Example HTML:
<div style="box-shadow: 1px 2px 3px 4px red;"/>
function TestForBoxShadow()
{
var d = document.getElementsByTagName("div")[0];
var s = d.style;
for (var i = 0; i < style.length; i++)
{
if (style.item(i) == "box-shadow"))
{
return true;
}
}
return false;
}
In CSS3, this returns true.
In CSS7 when box-shadow is a shorthand, it would return false with the only-longhands item() proposal.
As such, this would either be compatibility breaking in CSS7 *or* it couldn't be done to avoid that.
Both results are failure modes, IMO.
Received on Friday, 3 February 2012 21:32:24 UTC