- From: Dirk Schulze <dschulze@adobe.com>
- Date: Tue, 17 Dec 2013 01:44:32 +0000
- To: fantasai <fantasai.lists@inkedblade.net>
- CC: www-style list <www-style@w3.org>
On Dec 17, 2013, at 2:33 AM, Dirk Schulze <dschulze@adobe.com> wrote: > > On Dec 16, 2013, at 11:57 PM, fantasai <fantasai.lists@inkedblade.net> wrote: > >> On 12/12/2013 08:02 AM, Dirk Schulze wrote: >>> Hi, >>> >>> I changed the specification text and think that the following suggestions were incorporated and the open issues can be closed now. >>> >>> On Dec 11, 2013, at 11:46 AM, fantasai <fantasai.lists@inkedblade.net> wrote: >>> >>>> 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. >>> >>> I made mask-type and <mask> top-level sections. >>> >>> Issue 10 [1] >>> >>>> >>>> 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. >>> >>> I made <clipPath> and ‘clip-rule’ top-level sections. >> >> If I understand correctly, 'clip-rule' only applies within <clipPath>, >> and 'mask-type' only applies to <mask>. So these things should be >> grouped together, to help convey this very tight association. >> >> I can see two ways of doing this: >> >> 1. Give <mask> and <clipPath> individual sections, e.g. >> >> Clipping >> [properties that apply clipping] >> SVG Clip Path Sources >> Defining a clipping path: the <clipPath> element >> Filling the clipping path: the clip-rule property >> Layered Masks >> [properties that apply layered masks] >> SVG Mask Sources >> Defining a mask source: the <mask> element >> Specifying mask interpretation: the mask-type property >> Box Masks >> [...] >> >> 2. Put <mask> and <clipPath> both into an SVG section >> >> Clipping >> [properties that apply clipping] >> SVG Mask and Clip Path Sources >> Defining a clipping path: the <clipPath> element >> Filling the clipping path: the clip-rule property >> Defining a mask source: the <mask> element >> Specifying mask interpretation: the mask-type property >> Layered Masks >> [properties that apply layered masks] >> Box Masks >> [...] >> Defining mask interpretation: the mask-type property > > You are suggesting two different ways of organize. I would prefer the first way. The idea of Filter Effects and Masking is to harmonize SVG and CSS more. We should sort by feature not by technology. And it is changed to the first hierarchy model. > >> >>>> 4. Layered Masks needs a new name, since at the moment we only >>>> have one layer. :) >>> >>> As discussed earlier in this thread, it is the intention of the editors >>> to make mask a layered model. In the current version just one layer is >>> supported. A note in the spec makes clear that this will change with >>> the next level. >> >> Yes, but I think it's a little weird to have a title that doesn't >> reflect what it's currently titling. >> >> How about "Positioned Masks"? It's accurate now as well as in the >> future, and reflects a fundamental difference between this type >> of mask and the box-image type of mask. Also, even once we have >> layers, the positioning features are still going to be more >> important than the layering in actual usage. > > I have no strong opinion. I can change it. I changed it to “Positioned Masking" > >> >>>> 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. >>> >>> Local coordinate system was indeed not used in this spec. I used the >>> SVG for most other terms mainly used by SVG. I kept the definition >>> for "user coordinate system” since the definition of SVG 1.1 is >>> extended. It is clarified how “user coordinate system” works on the >>> CSS boxing model. >> >> It's fine to keep it if you need it, but since it's really very specific >> to the SVG bits, maybe it would be better to move the definition closer >> to where it's used? It's not a concept that a CSS-only user would need >> to understand, and it's a rather long and involved definition, so I'm >> afraid that that it's more confusing than helpful to have it up front. >> >> (I try to keep Terminology sections at the top focused on globally-used >> concepts, where not understanding the terms would impede understanding >> of a substantial portion of the spec. Other terms I define more locally.) > > The terminology section is exactly about having a common place for definitions. The definitions there are used by <mask> and <clipPath>, that is true. I would still rather keep one terminology section than having multiple sections and the reader doesn’t know which one actually defines the relevant bits. > >> >> Please add another editorial issue: >> - Section titles should explain the purpose of each property, >> as in http://dev.w3.org/csswg/css-backgrounds/ >> Should be easy to fix, and I think would help people find what >> they're looking for if they don't already know what it's called. > > This is not very common across CSS specifications. Even the 4th level of CSS Background and Border http://dev.w3.org/csswg/css-backgrounds-4/ removed the names again. > > Greetings, > Dirk > Greetings, Dirk > >> >> ~fantasai >> > >
Received on Tuesday, 17 December 2013 01:45:02 UTC