- 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