Re: Better Variables through Custom Properties

On Friday 2011-10-28 00:08 -0700, Tab Atkins Jr. wrote:
> On Thu, Oct 27, 2011 at 5:22 PM, L. David Baron <dbaron@dbaron.org> wrote:
> > On Wednesday 2011-10-26 11:57 -0700, Tab Atkins Jr. wrote:
> >> On Wed, Oct 26, 2011 at 11:41 AM, L. David Baron <dbaron@dbaron.org> wrote:
> >> > Do all data-* properties inherit by default, or is there any
> >> > provision for such properties that do not?  (I'm not sure if there
> >> > needs to be; I'm just trying to understand what the model you're
> >> > proposing is.)
> >>
> >> My intention is that they all inherit by default.
> >
> > OK, so my next question:  the values of data-* properties are
> > essentially streams of values (or tokens).  What needs to happen to
> > come up with a computed value for such a property (prior to
> > inheritance)?  Most importantly, do data() expressions inside that
> > stream get evaluated when finding the computed value of a data-*
> > property (and the result inherited), or are the data() expressions
> > retained through inheritance and computed at the destination?
> 
> data() expressions are evaluated (/substituted?) at computed-value
> time.  That seems necessary to get sane behavior out of normal
> properties using data() expressions.
> 
> I'm not entirely certain whether other types of values, such as 'em'
> units, should resolve or not.  I suspect it's saner to resolve
> everything that would normally be resolved at computed-value time.

I don't see how you can resolve things like 'em' units.  For
example, the following sets of declarations mean different things:

  font-size: 2em; /* multiple of parent's font size */
  width: 2em; /* multiple of element's font size */

  color: currentColor; /* parent's color */
  background-color: currentColor; /* element's color */
  counter-reset: currentColor; /* identifier */

  line-height: 100%; /* computed value is multiple of font-size */
  vertical-align: 100%; /* computed value is multiple of line-height */
  width: 100%; /* computed value is percentage */

If you wanted to resolve things like these, you'd need to break them
so that one of the above didn't work as authors would expect.

Furthermore, if you wanted to resolve them at data-* computation
time, you'd make data-* have dependencies on CSS properties, which
makes the cyclic dependency detection substantially more
complicated, since it would need to have an accurate representation
of all of the dependencies between CSS properties (see [1]).  This
cycle detection would in turn introduce compatibility problems that
would prevent the working group from introducing new property
dependencies in the future, since introducing a new CSS property
dependency could turn data-* usage that was non-cyclic into
something cyclic.

-David

[1] http://wiki.csswg.org/spec/property-dependencies

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Friday, 28 October 2011 15:51:28 UTC