- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 11 Dec 2013 02:46:31 -0800
- To: "www-style@w3.org" <www-style@w3.org>
[Sorry for the late response. I haven't felt like working lately.] Non-editorial: 1. I'm wondering if the naming of the properties should follow the pattern mask-x shorthand with mask-x-* longhands for layered masks; mask-y shorthand with mask-y-* longhands for box-image masks; mask-type not prefixed by x or y since it's not part of either set; x and y as, preferably, a single word since this would best reflect the relationships among the properties. 2. Would like to see 'mask-box-image' shortened to 'mask-box' (or some other short alternative) as was mentioned in this thread: http://lists.w3.org/Archives/Public/www-style/2013Jun/0599.html http://lists.w3.org/Archives/Public/www-style/2013Jun/0634.html because it's imho unnecessarily long. 3. In the definition of 'no-clip'... # The painted content is not restricted (not clipped). # The mask painting area is set to the bounding client rect. I don't think this is what we want. Various effects are drawn outside the bounding client rect, for example box-shadows, border-images with outset, and content that overflows the box. If the intent is that the painted content is not clipped, then this definition is wrong. 4. The reference boxes for masking and clipping seem to be dramatically different. Afaict, masking uses the boxes as defined for backgrounds and borders. But clipping uses the "bounding client rect". Consider a box that has been split across three columns of a multi-col element on one page and into the first column on a second page. If I use an elliptical mask stretched to 100%, then the clipped perimeter will be an ellipse stretched across the height of the reconstructed box, and split across the fragments. But if I use an elliptical clip-path stretched to 100% this will not be the case. If the element stretched just across the first 3 columns, then the elliptical clip-path would stretch across the rectangle containing the 3 columns. Across pages, I don't even know what would result... Using the same shape for a mask and for a clip-path should result in the same effect. 5. clip-path should not be defining the origin and percentage basis of <basic-shape>s directly, but define what the "reference box" is. http://www.w3.org/TR/2013/WD-css-shapes-1-20131203/#reference-box 6. # If the URI reference is not valid [...], no clipping is applied. Please clarify whether a stacking context is still created or whether the behavior is equivalent to specifying 'none'. 7. clip-rule is not defined. At all. There's some syntax, an explanation of how the two values differ, and an example, but no definition of what the property actually *does*. 8. Does 'mask-source-type' apply to 'mask-box-image-source'? It's not clear from the spec. (See editorial issue #8, of which this seems to be a symptom.) If it doesn't: 8.A.1 Having its name match mask-x-type per issue #1 would help clarify that relationship. 8.A.2 This raises the issue of whether we need a mask-y-type. If it does: 8.B.1 I should be pulled out into the same section as the 'mask' shorthand, since they both apply to both types of masking. 8.B.2 Also, in this case, I'd like to reraise the question of whether mask-source-type and mask-type should be merged. I think it would be less confusing if there was just one property and its value at the point of application overrode its value at the point of source definition, the same way the 'width' property does. Editorial: 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. 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. 3. Since 'mask' now is a shorthand for both layered masks and box-image masks, it shouldn't be under the layered masks section. 4. Layered Masks needs a new name, since at the moment we only have one layer. :) 5. Would recommend shifting clipping above masking, since I'm *guessing* we'd prefer people to clip if they can, then mask if it's too complicated for clipping, not Mask All the Things. 6. Intro still needs work. Structure should probably be - What is masking and clipping, and why do we care? Focus first on their similarities, but also explain their differences so we know which one we're interested in for which applications. - How to clip things with CSS - More on Masking: - More technical detail on masking, if needed - How to mask things with CSS: what is CSS masking able to do, and what features do I use to do 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. 8. The use of 'mask source' and 'mask image' in the spec is confusing. There need to be separate concepts for the mask introduced by the background-inspired mask properties and by the border-image-inspired mask properties. Once these concepts are named, defined, and used consistently, we can have a clearer model for understanding CSS masking. 9. The definition of 'clipping path' in the Terminology section is more confusing than helpful. Just <dfn> the first instance of the term in the Clipping Paths section. Similarly, I don't find the definition of 'mask source' here to be helpful, and would remove it from Terminology. 10. # The usage of mask-box-image corresponds to the border-image property # of CSS Background and Borders [CSS3BG]. Except that the image is used as a mask rather than rendered on top of the background, right? :) You should say that up front. 11. # Later versions of this specification may define new properties # to enable fine-grained control over the interactions between # hit testing and clipping. This specification or whatever one ends up defining pointer-events, I presume? Trivialities ------------ 1. "are applied; these effects" -> use a period, start new sentence 2. "any other CSS effects such as border"... I think "CSS effects" here is rather undefined. Can we be clearer what makes something part of this class of effects? 3. Lastly, there's a stray apostrophe after the Value line in mask-source-type's propdef table. :) ~fantasai
Received on Wednesday, 11 December 2013 10:47:00 UTC