[css-masking] editorial changes (was: Re: [css-masking] Comments)

Hi,

On Dec 11, 2013, at 11:46 AM, fantasai <fantasai.lists@inkedblade.net> wrote:

>   1. I'd like to see mask-type and the <mask> element given their
>      own top-level section. They're defining a mask source, not
>      a mask application, as the rest of the properties are.

That sounds reasonable. Although, <mask> is very depending on mask-image. (The only property that can reference it.)

> 
>   2. Similarly, I'd like to see <clipPath> and 'clip-rule', which
>      (afaict) define a clip "source" given a separate top-level
>      section from 'clip' and 'clip-path', which define a clip path's
>      application.

Same applies to clip-path and <clipPath> as for mask-image and <mask>. I do not object to either change but am also not in favor for transforming it.

> 
>   3. Since 'mask' now is a shorthand for both layered masks and
>      box-image masks, it shouldn't be under the layered masks
>      section.

The main task is still to be a shorthand for all mask-image based properties. To reset the max-box-image properties as well is just a secondary function.

> 
>   4. Layered Masks needs a new name, since at the moment we only
>      have one layer. :)

This is just for this level. The note on the ‘mask’ property states[1]:

“”
Note: A future level of this specification will allow different mask layers for various additional masking operations like composited mask layers masking and serial layer masking.
“”

While I am still open for the previous requests, I do insist to keep layered mask. Even a single mask layer is still a layer.

> 
>   5. Would recommend shifting clipping above masking, since I'm
>      *guessing* we'd prefer people to clip if they can, then mask
>      if it's too complicated for clipping, not Mask All the Things.

On the one hand, yes. Clipping is easier and faster to implement. From talking with designers, they prefer masking more. However, I doubt that any order in the spec will influence the behavior of authors. I do not care which comes first.

> 
>   6. Intro still needs work. Structure should probably be
>        - What is masking and clipping, and why do we care?
>          Focus first on their similarities, but also explain their
>          differences so we know which one we're interested in for which
>          applications.

This is part of the intro currently. Basically clip-path defines a visual region while masking looks at the alpha channel of a given mask to determine how much you see the masked object. This is what the spec says currently.

>        - How to clip things with CSS

Do you have specific suggestions?

>        - More on Masking:
>            - More technical detail on masking, if needed

What do you think is missing?

>            - How to mask things with CSS: what is CSS masking able to
>              do, and what features do I use to do it?

The specification gives an overview. I think we can agree that a complete tutorial would not in the scope of an introduction. I am very open to specific suggestions to improve this section but also don’t see that something is missing. (Which could of course be a side effect of editing the spec.)

> 
>   7. The terms local coordinate system, user coordinate system, and
>      object bounding box units are only used in the definition of
>      <mask>. They should be relegated to that section (or merely
>      referenced from SVG), not defined up front. The top terminology
>      section should be for definitions and concepts used throughout
>      the spec, that someone would need to know to understand random
>      sections they jump to once through the introductory sections.

It indeed seems that "local coordinate system" is not used in the spec. It is though on other specs. I can remove the term.

> 
>   8. The use of 'mask source' and 'mask image' in the spec is confusing.
>      There need to be separate concepts for the mask introduced by the
>      background-inspired mask properties and by the border-image-inspired
>      mask properties. Once these concepts are named, defined, and
>      used consistently, we can have a clearer model for understanding
>      CSS masking.
> 
>   9. The definition of 'clipping path' in the Terminology section is
>      more confusing than helpful. Just <dfn> the first instance of
>      the term in the Clipping Paths section.

I’ll do.

> 
>      Similarly, I don't find the definition of 'mask source' here to
>      be helpful, and would remove it from Terminology.

Ok.

> 
>  10. # The usage of mask-box-image corresponds to the border-image property
>      # of CSS Background and Borders [CSS3BG].
> 
>      Except that the image is used as a mask rather than rendered on
>      top of the background, right? :) You should say that up front.

True. It could be stated explicitly.

> 
>  11. # Later versions of this specification may define new properties
>      # to enable fine-grained control over the interactions between
>      # hit testing and clipping.
> 
>      This specification or whatever one ends up defining pointer-events,
>      I presume?

This is from SVG. The idea is that an author can specify if and how clip-path contributes to hit testing. This is not possible at the moment. It could be defined by the 'pointer-event’ property or by a new property.

I can remove this sentence since it is not in the scope of the CSS WG at the moment.

> 
> Trivialities
> ------------
> 
>   1. "are applied; these effects" -> use a period, start new sentence
> 
>   2. "any other CSS effects such as border"... I think "CSS effects"
>      here is rather undefined. Can we be clearer what makes something
>      part of this class of effects?

We could say "graphical effect” but we do not have a definition for properties affecting the visual output of an element (which is basically the case by all properties directly or indirectly).

> 
>   3. Lastly, there's a stray apostrophe after the Value line in
>      mask-source-type's propdef table. :)

Yes, this is fixed in the ED version.

Thanks a lot for your review. I am happy to discuss open questions further.

Greetings,
Dirk

[1] http://dev.w3.org/fxtf/masking/#propdef-mask

Received on Wednesday, 11 December 2013 16:40:56 UTC