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

* 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...

>[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...

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.

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).

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.

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 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 same probably goes for <compound-selector> values.

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

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.

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.

"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 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.

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.

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 acknowledgements section seems to be missing.
-- 
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/

Received on Saturday, 9 March 2013 15:43:57 UTC