Re: [css-masking] editorial changes - spec update

On Dec 16, 2013, at 11:57 PM, fantasai <fantasai.lists@inkedblade.net> wrote:

> On 12/12/2013 08:02 AM, Dirk Schulze wrote:
>> Hi,
>> 
>> I changed the specification text and think that the following suggestions were incorporated and the open issues can be closed now.
>> 
>> 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.
>> 
>> I made mask-type and <mask> top-level sections.
>> 
>> Issue 10 [1]
>> 
>>> 
>>>   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.
>> 
>> I made <clipPath> and ‘clip-rule’ top-level sections.
> 
> If I understand correctly, 'clip-rule' only applies within <clipPath>,
> and 'mask-type' only applies to <mask>. So these things should be
> grouped together, to help convey this very tight association.
> 
> I can see two ways of doing this:
> 
> 1. Give <mask> and <clipPath> individual sections, e.g.
> 
>  Clipping
>     [properties that apply clipping]
>  SVG Clip Path Sources
>     Defining a clipping path: the <clipPath> element
>     Filling the clipping path: the clip-rule property
>  Layered Masks
>     [properties that apply layered masks]
>  SVG Mask Sources
>     Defining a mask source: the <mask> element
>     Specifying mask interpretation: the mask-type property
>  Box Masks
>     [...]
> 
> 2. Put <mask> and <clipPath> both into an SVG section
> 
>  Clipping
>     [properties that apply clipping]
>  SVG Mask and Clip Path Sources
>     Defining a clipping path: the <clipPath> element
>     Filling the clipping path: the clip-rule property
>     Defining a mask source: the <mask> element
>     Specifying mask interpretation: the mask-type property
>  Layered Masks
>     [properties that apply layered masks]
>  Box Masks
>     [...]
>     Defining mask interpretation: the mask-type property

You are suggesting two different ways of organize. I would prefer the first way. The idea of Filter Effects and Masking is to harmonize SVG and CSS more. We should sort by feature not by technology.

> 
>>>   4. Layered Masks needs a new name, since at the moment we only
>>>      have one layer. :)
>> 
>> As discussed earlier in this thread, it is the intention of the editors
>> to make mask a layered model. In the current version just one layer is
>> supported. A note in the spec makes clear that this will change with
>> the next level.
> 
> Yes, but I think it's a little weird to have a title that doesn't
> reflect what it's currently titling.
> 
> How about "Positioned Masks"? It's accurate now as well as in the
> future, and reflects a fundamental difference between this type
> of mask and the box-image type of mask. Also, even once we have
> layers, the positioning features are still going to be more
> important than the layering in actual usage.

I have no strong opinion. I can change it.

> 
>>>   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.
>> 
>> Local coordinate system was indeed not used in this spec. I used the
>> SVG for most other terms mainly used by SVG. I kept the definition
>> for "user coordinate system” since the definition of SVG 1.1 is
>> extended. It is clarified how “user coordinate system” works on the
>> CSS boxing model.
> 
> It's fine to keep it if you need it, but since it's really very specific
> to the SVG bits, maybe it would be better to move the definition closer
> to where it's used? It's not a concept that a CSS-only user would need
> to understand, and it's a rather long and involved definition, so I'm
> afraid that that it's more confusing than helpful to have it up front.
> 
> (I try to keep Terminology sections at the top focused on globally-used
> concepts, where not understanding the terms would impede understanding
> of a substantial portion of the spec. Other terms I define more locally.)

The terminology section is exactly about having a common place for definitions. The definitions there are used by <mask> and <clipPath>, that is true. I would still rather keep one terminology section than having multiple sections and the reader doesn’t know which one actually defines the relevant bits.

> 
> Please add another editorial issue:
>  - Section titles should explain the purpose of each property,
>    as in http://dev.w3.org/csswg/css-backgrounds/
> Should be easy to fix, and I think would help people find what
> they're looking for if they don't already know what it's called.

This is not very common across CSS specifications. Even the 4th level of CSS Background and Border http://dev.w3.org/csswg/css-backgrounds-4/ removed the names again.

Greetings,
Dirk


> 
> ~fantasai
>

Received on Tuesday, 17 December 2013 01:34:00 UTC