W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [css3-cascade] Editorial comments

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 10 Jun 2013 16:19:27 -0700
Message-ID: <CAAWBYDCxVcJ6NnNxe8jxw4s6NiCkfumzpgEwh8stwJfsw6vwRw@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: www-style list <www-style@w3.org>
On Sat, Jun 8, 2013 at 7:57 PM, Simon Sapin <simon.sapin@exyr.org> wrote:
> When listing "The precedence of the various origins", §4.2 should link to
> §4.2.1 and §4.2.2 to define origins and '!important', respectively.

Done.

> §4.2.1. Cascading Origins should define that imported stylesheets have the
> same origin as the stylesheet that imported them.

Done.

> Thorough the document, the word "origin" (especially when preceded by
> "same") should be disambiguated by linking either to §4.2.1 when it refers
> to cascading, and some other definition (maybe the WHATWG Fetch spec?) for
> the same-origin policy.
>
> Similarly, "imported stylesheet" should link to the section defining
> '@import'.

Done.

> With inheritance, the *computed* value of the parent becomes the *specified*
> value. This requires one of two things to keep the whole thing well-defined,
> although this is probably not a problem in practice:
>
> 1. The process of resolving a specified value into a computed value (which
> is specific to every property) must be idempotent.
> 2. Or §5.2 should say that the specified value becomes the computed value
> as-is if it was inherited from a computed value.
>
> I’d prefer 2, as 1 is a burden for every other CSS spec.

We resolved some time ago on the current wording:
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=14420>.

> In §5:
>
>     Finally, the computed value is transformed to the actual value
>     based on constraints of local environment.
>
> s/computed/used/

Done.

> The first two paragraphs of §5.2. "Finding the computed value" should be a
> non-normative design principle, since the process for finding the computed
> value is normatively defined by every property. Considerations of absolute
> vs. relative value can not always be generalized (an unitless number is
> absolute in 'opacity' but relative in 'line-height') and some relative
> values are not resolved until layout as used values.
>
>
> Similarly in §5.3: the used value can differ from computed value more than
> just resolving remaining relative values. This process is specific to each
> property, and this spec should not generalize too much.

I think it's clear that this is talking in general principles.  The
actual definition clearly defines that the process is defined in each
property's definition.

~TJ
Received on Monday, 10 June 2013 23:20:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC