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

Re: [css3-values] comparing computed values

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 17 Jul 2012 23:29:28 -0400
Message-ID: <50062D98.6080800@inkedblade.net>
To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, WWW Style <www-style@w3.org>
On 07/17/2012 12:46 PM, Kang-Hao (Kenny) Lu wrote:
>>
>> fantasai: what more do we need over "compare computed values"?
>> dbaron: some kind of statement about what a computed value is
>
> It seems that dbaron thinks the current spec is not detailed enough
> about what "computed value" is?

I still have no idea why this is unclear.

>> plinss: there's lots to define there, e.g. is 72 points == 1 inc?
>> fantasai: yes, because they get converted to absolute values
>> plinss: that should be explicit
>
> It seems that plinss thinks the spec should make this more explicit?

Every property that takes a length explicitly says that the computed
value is the "absolute length", so as dbaron notes in the line below,
it's already explicit.

>> dbaron: it is. It's more things like pairs of values
>> fantasai: we need to go and fix the computed values lines to not
>>            imply an order, if there are any left that do
>> TabAtkins: that's not a problem because they'll still compute to
>>             the same thing for comparison
>> dbaron: e.g. flex before it was a shorthand took 3 values in any
>>          order. It's computed value is the combination of the 3 values,
>>          not ??
>> TabAtkins: so I want to say just simply compare computed values,
>>             with a note that gets developers to come to us if they
>>             think something's weird
>> fantasai: yes, just a note that says these are abstract things,
>>            not strings
>> dbaron: have to be careful about computed values with optional parts.
>>          Is the presence of the optional part substantive, or can it
>>          be replaced by its default if the optional part isn't present?
>> dbaron: that text could be in values spec
>
> Was an action taken for this comment?

Yes, a note was added. (It probably belongs in css3-cascade, though,
once that's updated.)

Afaict the problem isn't with the normative prose of css3-values,
it's a problem with the Computed Value line of various properties
being poorly written, and therefore should be fixed in those places
(if any remain; there used to be some in css3-background).

>> RESOLVED: issue 15: add a note to define computed style comparisons
>>            better
>
> I don't quite care what the status keyword this issue gets, but I think
> if we want to make DoC useful, there should be a link to this discussion
> (i.e. [1]) instead of this Response mail I am replying to, which, in my
> humble opinion, doesn't have much information.

Well, you just quoted all the relevant parts, so I might just link to
your message. :)

> I am not against deferring this to the future so to speak.

As far as I know, this issue is closed and there is nothing to defer.
If that's not the case, I'll need specific examples that show what's
problematic.

Afaik, for example, the comparison of 'width' values is perfectly
well-defined. So someone would have to show me two declarations for
which it's not clear before I can figure out what needs clarifying.

If the Computed Value line of other specs are incorrect, however,
we should correct those lines in those specs, not add lengthy
explanations of what those lines should have been to the definition
of toggle().

In other words, I can't fix everything that's wrong with CSS in the
module I happen to be actively editing today just because I happen to
be actively editing it and not the module where the problem is. :/

~fantasai
Received on Wednesday, 18 July 2012 03:30:14 GMT

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