Re: [CSS3-color] Errata

Hi Chris,

Really sorry - I thought I'd sent a reply to this whilst at the Paris F2F
but I don't think I actually did :-(.

On 08/02/2012 12:02, Chris Lilley wrote:
> This email relates to your mail
> http://lists.w3.org/Archives/Public/www-style/2011Jul/0025.html
>
> This was discussed by the CSS WG
> http://lists.w3.org/Archives/Public/www-style/2011Jul/0094.html
>
> based on that and subsequent informal discussion, I propose the
> following resolution to the three points you raise.
>
> Comment 1
>
> We don't see it as confusing (it is indeed, as you suggest, trying to
> explain the origins of the spec and says so explicitly: "The
> specification is the result of the merging of relevant parts of the
> following Recommendations and Working Drafts, and the addition of
> some new features." This is why the specifications mentioned in that
> section are non-normative).
>
> We propose to resolve your comment by explicitly stating, in section
> 1 Introduction, "This section is non-normative".

That's fine.

> Comment 2
>
> The wording "Container element" is indeed SVG terminology. The
> definitions are given in
>
> http://www.w3.org/TR/SVG/intro.html#Terminology
>
> but to summarise, in SVG elements are divided into two classes:
> graphics element (which draw stuff) and container elements (whose
> children may draw, but they themselves do not directly draw).
>
> There is no such distinction in CSS, but the critical issue is that,
> when something that has children, and the 'something' has its opacity
> property set to a non-initial value, you render that something *and
> its children* as if the opacity was 1, then change the opacity of the
> whole rendering. You do not render by propagating the opacity
> separately to all the children.
>
> This is already described in the prose, thus:
>
> "Conceptually, after the element (including its descendants) is
> rendered into an RGBA offscreen image, the opacity setting specifies
> how to blend the offscreen rendering into the current composite
> rendering."
>
> I propose to address your comment by changing
>
> "If the object is a container element"
>
> to
>
> "If the object has children" in the definition of the property value,
> and then adding, in the descriptive prose, "For SVG, 'has children'
> is equivalent to being a container element [SVG11]" where 'container
> element' links to www.w3.org/TR/SVG/intro.html#TermContainerElement
> and [SVG11] links to SVG 1.1 in the normative references.

Fine.

> Comment 3
>
> Your proposed wording isn't quite sufficient because "treated as
> though it has the index: 0" also has an effect on the painting level
> of descendents.
>
> Instead, we suggest to address your comment by changing
>
> "except that ‘auto’ is treated as ‘0’"
>
> to
>
> "except that a computed value of 'auto' behaves as if its z-index
> were zero"
>
> to make it clear that it doesn't change the computed value.

I don't think that makes much grammatical sense, but I'm happy with the
approach; it's follows the same lines as the updated suggestion that I
made in [1] in response to comments.

The heart of the issue is that it's not entirely clear what "behaves"
means!  Is it obvious that you intend that the element takes
responsibility for painting its positioned descendents (ie that
responsibility doesn't bubble up to the nearest ancestor positioned
element with integer z-index), but I wish it were more explicit that
the used value doesn't become '0'.

Here's another possibility:

  | If an element with opacity less than 1 is not positioned
  | then it is painted on the same layer, within its parent stacking
  | context, as positioned elements with stack level 0. If an element
  | with opacity less than 1 is positioned, the ‘z-index’ property
  | applies as described in [CSS21], except that if the used value
  | is 'auto' then the element behaves exactly as if it were '0'.

[Note that I prefer my first sentence over the one that's in the spec,
where a bit of a muddle occurs with "paint the layer" and "at the same
stacking order".  My sentence precisely matches what's now CSS21
terminology.]

This addresses my concern about used value, and it's implicit that a
computed value of 'auto' may still result, since that's the only way of
ending up with a used value of 'auto'.

In fact, would it not be much simpler to force the used value to '0' in
the case that the computed value is 'auto'?  There wouldn't need to be
any hand-waving at all then!


[1] http://lists.w3.org/Archives/Public/www-style/2011Jul/0116.html

Apologies again for the delay in responding.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 29 April 2012 19:35:20 UTC