Re: [css-cascade] Naming "value of a declaration", renaming "specified value"

On Mon, Jun 24, 2013 at 2:56 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Monday 2013-06-24 14:38 -0700, Tab Atkins Jr. wrote:
>> On Mon, Jun 24, 2013 at 2:32 PM, L. David Baron <dbaron@dbaron.org> wrote:
>> > On Monday 2013-06-24 14:16 -0700, Tab Atkins Jr. wrote:
>> >> 2. Drop the term "specified value", and slightly modify Cascade so
>> >> that "cascaded value" fills the role.  This just requires us to
>> >> slightly change the verbiage around how we handle the global keywords;
>> >> currently, the "cascaded value" may be empty or resolve to one of the
>> >> global keywords.  We'd change it so that as part of the computation of
>> >> the cascaded value, we guarantee that we fill in a value, and resolve
>> >> away the global keywords.  (Our current use of "cascaded value" in the
>> >> spec is unobservable from the outside, and we can just lean on the
>> >> term "result of the cascade" to represent the value that might be
>> >> empty or might be a global keyword.)
>> >
>> > Why do we need a term for the cascaded value with empty cases filled
>> > in?  Why not just have the term "cascaded value"?
>>
>> I'm not sure exactly how to read this question; I get at least three
>> possible meanings from it, which all have different answers.
>>
>> Can you elaborate on what you're asking?
>
> I'm asking why we need a publicly exposed term for what "specified
> value" used to mean.  In other words, it seems to be a concept that
> might be useful inside the cascade module but is unlikely to be
> useful outside of it.  In turn, that makes me think we'd be better
> off not giving it a nice easy-to-refer-to term that people are
> likely to refer to.
>
> In other words, I'm proposing not replacing the term "specified
> value" with anything that's easy to refer to, and leaving the term
> "cascaded value" as it is.

If we don't have a publicly-exposed term, then every single spec that
wants to define computed values has to handle the cases where there is
no value, or the value is a global keyword.  That's not acceptable,
since it would be boilerplate in every spec; it is treated the same
every single time.  (It's like how, today, every spec that ever refers
to inherited values has to deal with the possibility of there not
being an inherited value, because the element is the root or
something.  It's the same every time, and there are plenty of places
where we forget to address it; this should just be part of the
definition of "inherited value".)

As I stated in the first paragraph of my OP, the current term
"specified value" refers to "the value that starts the real value
computation process, before anything is altered".  This is a valuable
concept for spec readability and correctness.

~TJ

Received on Monday, 24 June 2013 22:46:47 UTC