- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sat, 4 Feb 2012 02:16:51 -0800
- To: Glenn Adams <glenn@skynav.com>
- Cc: Alexis Menard <alexis.menard@openbossa.org>, Brian Manthos <brianman@microsoft.com>, www-style@w3.org
On Fri, Feb 3, 2012 at 1:27 PM, Glenn Adams <glenn@skynav.com> wrote: > On Fri, Feb 3, 2012 at 11:36 AM, Alexis Menard <alexis.menard@openbossa.org> > wrote: >> 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. > > > if we allow longhand properties to be queried or set using their shorthand > form via getPropertyValue/setValue, then shorthands probably should be > enumerated by item(); > > there is also the issue of what happens when a current longhand is > re-designated in the future as a shorthand, and then subdivided into a new > set of longhands Glenn and Brian have this right. Properties that are currently longhands *will* become shorthands in the future. This has already happened, and it will continue to happen, as we provide more options for certain properties. Ideally, we can spec things in a web-compatible way so that all shorthands act similarly to longhands (modulo the fact that they'll sometimes not exist because the longhands were set in a way that can't be represented in the shorthand). At worst, legacy shorthands will have a crazy behavior, but we should establish a behavior going forward for all new shorthands that is compatible with the longhand->shorthand transition. ~TJ
Received on Saturday, 4 February 2012 10:17:48 UTC