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

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

From: Dirk Schulze <dschulze@adobe.com>
Date: Sun, 10 Mar 2013 19:36:52 -0700
To: "liam@w3.org" <liam@w3.org>
CC: "www-svg@w3.org list" <www-svg@w3.org>, www-style list <www-style@w3.org>
Message-ID: <CC210B20-36A0-4CBC-B04A-A6B9D6662019@adobe.com>
Hi Liam!

Thank you very much for your review and the valuable input as well! I changed the spec according to your input as follows [1]:

On Mar 10, 2013, at 5:42 PM, Liam R E Quin <liam@w3.org> wrote:

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

I added the "Conformance" section that was missing. This should clarify this.

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

I hope that my latest specification text changes are more clear about what a UA must not implement. Can you take another look at the specification text please?

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

Ditto.

> 
> 4. Definitions
> 
> bounding client rect:
> typo - namespace and it's descendant elements - delete the apostrophe:
> s/it's/its/

Ditto.

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

The foreignObject is a container for foreign documents. For HTML it is an HTML document which fulfills the requirements again.

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

The text has a normative reference to CSS3 Transforms, which clarifies how a local coordinate system is affected by the own transform and the transforms of the parent. The definition text for local coordinate system in CSS Masking is correct and covers the necessity for CSS Masking IMO. 

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

user coordinate system is equal to local coordinate system. The former definition is used in SVG specifications, the later in CSS specifications. The usage should be consistent within the document, but added for referenced from SVG. I will add a sentence that states this clearly.

> 
> mask:
> 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)

I look into that again.

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

Ditto.

> 
> 5. The Mask Rendering Model
> 
> s/establishes a stacking context the same way/establishes a stacking
> context in the same way/

Fixed.

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

I did s/the target/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.

I do not agree that this could be implied with the current phrasing. However, do you have a suggestion for a different phrasing?

> 
> 
> 
> More later, I hope.

That would be fantastic, thanks! :)

Greetings,
Dirk

[1] https://dvcs.w3.org/hg/FXTF/rev/59236286d848

> 
> Liam
> 
> 
> 
> -- 
> 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 02:37:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT