W3C home > Mailing lists > Public > www-svg@w3.org > March 2013

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

From: Liam R E Quin <liam@w3.org>
Date: Sun, 10 Mar 2013 20:42:26 -0400
To: Dirk Schulze <dschulze@adobe.com>
Cc: "www-svg@w3.org list" <www-svg@w3.org>, www-style list <www-style@w3.org>
Message-ID: <1362962546.25191.95.camel@localhost.localdomain>
On Sat, 2013-03-09 at 17:25 -0800, Dirk Schulze wrote:

> >> [1] https://dvcs.w3.org/hg/FXTF/raw-file/default/masking/index.html

Some minor editorial comments...

2. Module interactions

UAs without support for SVG must not implement the ‘mask-type’ and
‘clip-rule’ properties as well as the ‘mask’ and ‘clipPath’ elements.
(1) this should be an RFC-MUST I think (affects conformance);
(2) I don't understand it - it could mean that a user agent without
support for SVG must not implement any of the four listed properties (as
well as) or that it MAY implement EITHER mask-type and clip-rule
properties OR the mask and clipPath elements but not both (which seems
odd on the face of it).

Furthermore, the ‘mask’ and ‘clip-path’ properties must not support
references to ‘mask’ and ‘clipPath’ elements.
does this apply only to UAs that do not support SVG?

4. Definitions

bounding client rect:
typo - namespace and it's descendant elements - delete the apostrophe:

"and its descendent elements" - what about a fragment of HTML contained
inside SVG as a foreign object? The HTML element would not be in the SVG
namespace but would be a descendant of such an element.

local coordinate system:
This talks about a current local coordinate system, but this appears not
to take transformations into account, e.g. in the parent element. If
transformations and SVG viewports are to be ignored the text needs to
state that explicitly, I think.

user coordinate system:
This says, see local c.s., but that entry does not define user
coordinate system, just mentions one and states its origin (but not, for
example, which direction corresponds to positive y increments).

this definition really only works for people who know what a mask is.
Given the intro, maybe that's OK. Otherwise, it should explain that by
"painted onto the background through the mask" means that the mask isn't
actually drawn, but that pixels in the object that lie through a
transparent black part of the mask get rendered, and all other pixels
get rendered with varying transparency depending on the mask value at
that point. (assuming my explanation is correct)

clipping path:
suggest removing the parenthetic comment about anti-aliasing and
deleting 1-bit, since 1-bit masks and antialiasing have not been

5. The Mask Rendering Model

s/establishes a stacking context the same way/establishes a stacking
context in the same way/

The ‘mask’ and ‘mask-image’ properties have no effect on the geometry of
the target element's CSS boxes. 
could be taken as implying that there are some elements the geometry of
whose CSS boxes is indeed affected. Maybe what is meant is that the mask
and mask-images have no effect on the geometry of CSS boxes of any

These effects all apply after any other CSS effects such as ‘border’
I think this is saying that an element's borders are never affected by a
mask used to paint that element.

More later, I hope.


Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Received on Monday, 11 March 2013 00:42:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:41 UTC