Re: Mask and Clip behavior

2012/2/16 Erik Dahlstrom <ed@opera.com>

> On Sat, 11 Feb 2012 21:28:18 +0100, Jeremie Patonnier <
> jeremie.patonnier@gmail.com> wrote:
>
>
>>   1. Update the current SVG spec to add a note to all the relevant
>>
>>   attributes definition that do not support percentage value relative to
>> the
>>   object bounding box (gradientUnits, patternUnits, patternContentUnits,
>>   clipPathUnits, maskUnits, maskContentUnits, filterUnits or
>> primitiveUnits):
>>
>>   « Note that percentage values are not affected by the
>>   'objectBoundingBox' value and, according to the units processing rules,
>> are
>>   defined to be relative to the size of the viewport applicable to the
>> object
>>   the gradient|mask|pattern|clip|**filter|primitive is applied to. »
>>
>
> Yes, that's similar to the rule of thumb I use when dealing with these
> elements: "percentages are relative to the viewport, [0..1] (fractions) are
> relative to the boundingbox".
>
> It works in a majority of the cases, but not always. Percentages in the
> font-size attribute/property for example (relative to the parent's
> font-size).


Yes, I agree. Understanding the percentage for font-size is another
treasure hunt :)
The fact is that percentage values for font-size seam so obvious that I was
not able to find any clear definition of how font-size values express with
percentage should be compute with that objectBoundingBox thing. But I maybe
miss something.

To avoid any confusion at all, my proposal can be rephrase as such:

« Note that percentage values are not affected by the 'objectBoundingBox'
value and should be computed as if the value were 'userSpaceOnUse'. It
means that, according to the units processing rules, length values
are defined to be relative to the size of the viewport applicable to the
object the gradient|mask|pattern|clip|**filter|primitive is applied to. »


> I'm not sure if the term "applicable viewport" needs further clarification
> here, but a link from that to somewhere describing viewports might be good
> if the proposed text is accepted.
>

Are you suggesting this :
http://www.w3.org/TR/SVG/coords.html#EstablishingANewViewport
or simply what is defined here : http://www.w3.org/TR/SVG/coords.html#Units


>
>    2. I propose some changes to the upcoming SVG 2.0 to have things more
>>
>>   consistent and more author friendly:
>>
>>   1. Mark all the gradientUnits, patternUnits, patternContentUnits,
>>
>>      clipPathUnits, maskUnits, maskContentUnits, filterUnits or
>> primitiveUnits
>>      attributes deprecated. It's to many different attributes that
>> basically do
>>      the same : switching between 'userSpaceOnUse' and 'objectBoundingBox'
>>      values.
>>      2. Add two new attributes « units » and « contentUnits ». « units »
>>
>>      will be a unified attribute that will be used in replacement of
>>      gradientUnits, patternUnits, maskUnits, filterUnits and
>> primitiveUnits. «
>>      contentUnits » will be a unified attribute that will be used in
>> replacement
>>      of patternContentUnits, clipPathUnits and maskContentUnits
>>      3. The old deprecated attributes will remain with their behavior
>>
>>      unchanged but the new attributes will allow the use of percentage
>> values
>>      always relative to the object bounding box if the value of the «
>> units » or
>>      « contentUnits » is set to "objectBoundingBox" (which is, IMO,
>> what authors
>>      expect : when something is bound to the bounding box, everything
>> should be
>>      and percentage are much more readable than fraction).
>>      4. if both the old deprecated attribute and the new friendly
>>
>>      attribute are used at the same times, the new attribute will
>> override the
>>      behavior of the old one.
>>      5. if only one attribute is declared, the default value of the
>>      undeclared attribute is ignored
>>      6. if there is no attribute, both old and new attributes should have
>>
>>      the same default value which will insure backward compatibility
>> with legacy
>>      content.
>>
>
> I like the general idea of using one attribute instead of five and so on,
> but I fear that it would become even more of a mess to authors to keep
> track of - at least in a transitional period.


I don't thing so. It's the reason I only suggest to deprecate attributes
instead of removing it. For authors, they will have two options :

   1. They already know the way SVG 1.1 works and it will style work in the
   same way, so there is no need to worry. They will be able to take the time
   they want to learn the new (easier) way of doing things.
   2. They don't know the the way SVG 1.1 works. So they will learn the new
   way very easily (especially if they come form the HTML world where
   attributes names are very consistent across tags)

However, there will be a transitional time during which user-agents will
have to implement new SVG 2 features... but it's true for every new
behavior define by SVG 2 and because this proposal is an
"incremental enhancement" that do not break legacy content (nor behavior),
I really think authors will be fine with it.

There will be some mess if a popular user-agent refuse (or take a loooong
time) to implement that new feature. But it's the long story of web
standards, there is always a shift between authors expectations and
the reality of implementations :-/

So, I think the point here, is less the difficulty for author to keep track
(they will be helped by initiative such as the SVG MDN
docs<https://developer.mozilla.org/en/SVG> or
the WebED CG) than having implementors on that mailing-list agreeing on
implementing that kind of feature at the same rate.

Regards
-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>