Re: [css-masking] Review request before going to LC

Hi Björn,

I really appreciate your review and feedback! Some comments inline.

On Mar 9, 2013, at 7:43 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Dirk Schulze wrote:
>> I would like to ask for a review of the specification before going to LC.
> 
> That should go along with a Working Draft, for instance because people
> like to reference stable documents so their comments still make sense
> when read later (for example, section numbers may change). Anyway…

Along with LC (last call) comes the LCWD (last call working draft). If you wish to reference a previous working draft, see link[1]. This is a request for an initial review before going to LCWD.

> 
>> [1] https://dvcs.w3.org/hg/FXTF/raw-file/default/masking/index.html
> 
> If this is actually meant to define the SVG <mask> element including
> APIs for it, then the title "CSS Masking" seems inadequate to me. And
> apparently <clipPath> is also there, and clipping is not masking…

CSS Masking specifies the CSS properties
* mask-image
* mask-source-type
* mask-repeat
* mask-position
* mask-clip
* mask (shorthand)
* mask-type
* mask-box-image-source
* mask-box-image-slice
* mask-box-image-width
* mask-box-image-outset
* mask-box-image-repeat
* mask-box-image (shorthand)
* clip-path
* clip

It is possible to reference an SVG <mask> element with the 'mask-image' property and
it is possible to reference an SVG <clipPath> element with the 'clip-path' property (beside other values).

To keep the specification consistent, the two elements are kept together with the properties using it. I hope this explains the "CSS" in the name.
Clipping is different operation than masking but can still be described by a 1bit mask. The specification defines the differences. As a historical background: clip-path and clip were added to the specification later.

> 
> In section 6.1 the example "url(commonmasks.xml#mask)" is misleading.
> The file name extension .xml usually maps to application/xml and sad
> as it may be, the specification for that still does not discuss frag-
> ment identifiers, so the example should not work. Use `.svg` or some
> other suitable extension.

I changed the extension to .svg for a better understanding[5].

> 
> The mask-image grammar seems to be ambiguous because <image> seems to
> include <url> these days. That needs to be discussed more explicitly,
> and closer to the grammar (explicitly say it's ambiguous, and how to
> resolve the ambiguity, probably directly below the grammar).

Yes, see the normative note beyond the value descriptions[2]. To reference the discussion for this syntax: [3][4].

> 
> The discussion of fragment identifiers in this section needs to have
> a pointer and probably an example for `image()` because otherwise it
> is not clear whether "media fragments" can be referenced considering
> fragment identifiers in url() always imply <mask /> references.

See the same note. <image> requires support for media fragments on the 'image()' function. The referenced note above defines that all fragments make the reference get treated as resource. See discussion [3][4].

> 
> There should be an example that uses something like
> 
>  mask-image: image(...), none, image(...) ...
> 
> or at least a discussion thereof, as the effect and utility of that
> does not seem obvious to me. There are a number of references in the
> document saying "Layering multiple mask images" explains that, but it
> does not really have much of an introduction into the ideas here.

There are examples on "example 2". There is no need to provide examples of all possible CSS Image values. In fact, the CSS WG asked for removing duplicates of specification text and demos from CSS3 Background and Borders.

> 
> There needs to be a discussion of what happens when a url() refers to
> more than one <mask /> element in the text defining the semantics of
> <url> or close by (that's possible using various XPointer schemes, as
> an example).

The <url> function does not allow more than one reference to resources - independent of XPointer. 

> The same probably goes for <compound-selector> values.

The <compound-selector> does indeed represent a list of resources. But it is just possible to use this value in combination with 'select()', which specifies:

""
The first matching element in tree order (as defined in [DOM]) as a result of evaluating the list of selectors is taken as the mask source.
""

> 
> There seem to be missing references to the SVG namespace, e.g. the
> reference to "select(mask:last-of-type)" seems misleading like that.

There is no need for a name spacing (svg:mask) for usage in SVG documents. The <mask> element is not in the HTML namespace and can not be added as SVG resource in HTML content directly yet. The SVG WG still decided to specify the compound selector in CSS Masking.

> 
> It wasn't immediately clear where the `select(...)` notation is defined.
> It's not defined in the proposal and none of the obvious references seem
> to define it.

It is right after the property definition like all syntax descriptions:

""
<child-selector> = select(<compound-selector>#)
""

> 
> Section 3 says "This specification follows the CSS property definition
> conventions from [CSS21]." As far as I can tell, CSS 2.1 does not de-
> fine the semantics of a post-fix `#` as used e.g. in section 6.3. That
> needs to reference a specification that defines `#` so long as it is
> used in the proposal.

Yes, the reference to CSS3 Values and Units is missing. I added the reference.

> 
> "Animatable: yes except keyword values" does not make a whole lot of
> sense for properties that only take keyword values, and seems to be
> misleading more generally because discrete animation is still animation
> and there seems to be no reason to disallow that. That might be okay if
> there a document explaining the meaning of such phrases and if that is
> linked in the property tables, but that is not currently done.

I changed animatable to no for now.

> 
> I take it SVG_MASKTYPE_LUMINANCE and SVG_MASKTYPE_ALPHA come form the
> SVG 2.0 proposal. They are likely to trigger visits from the API police
> so there should be some rationale why new numeric constants are being
> introduced.

Yes, it is a mistake to introduce them in the SVGMaskElement interface. I removed these types.

> 
> In section 9.1 there needs to be something to limit the applicability
> of the same-origin restrictions. They are only really relevant to web
> browsers and related applications with similar security concerns.

I don't see a reason to limit the restrictions here. If browsers or other applications, both should consider security of users when they deal with cross domain referencing.

> 
> In section 8.5 the "pointer events" link references the "pointer-events"
> property in SVG 1.1. That does not seem quite right to me. One problem
> is that one would have to guess whether this affects pointer events as
> the Pointer Events Working Group is defining them because they had not
> been considered when SVG 1.1 came out. I am not sure what to do there.

The 'pointer-events' property is defined by SVG 1.1 as you noted. It was adapted by CSS UI for some time but removed later again. To my knowledge there are no adaptation by other specifications. The pointer events WG has a different scope and sadly the same name as the property. This might lead to confusions but this can not be avoided.

> 
> The acknowledgements section seems to be missing.

Thanks a lot for your review again.

Greetings,
Dirk

> -- 
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[1] http://www.w3.org/TR/2012/WD-css-masking-20121115/
[2] https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-image
[3] http://lists.w3.org/Archives/Public/www-style/2012Oct/0406.html
[4] http://lists.w3.org/Archives/Public/www-style/2012Oct/0765.html
[5] https://dvcs.w3.org/hg/FXTF/rev/fd09b94a3a4d

Received on Sunday, 10 March 2013 01:26:07 UTC