Re: [css3-transforms] scale 0 on non-scaling strokes

Dirk Schulze:

...
> SVG 1.2 should have described this
> case but didn't and therefore is undefined at the moment. 

No, because SVG tiny 1.2 mentions no specific behaviour (what is
not really necessary), one can expect, that the stroke is rendered
in all cases - this can result in useful applications I already mentioned.

I think, it contains only the questionable rule not to render, if
the matrix list is completely zero - what is surprising as well
if you compare with the required rendering, if only the items
e or f are small numbers ;o) But maybe this is a legacy
from SVG 1.0/1.1 with no nonscaling-stroke at all.


Therefore the behaviour in SVG tiny 1.2 is defined and if current
user-agents do not render the stroke for other situations as
a matrix with a list of zeros , these are clearly bugs.

> CSS3 Transforms 
> will define it in a way that is consistent within current UAs It makes more
> sense to describe the state of the art at this point of time than defining
> something different that is clearly inconsistent with the behavior of
> current UAs. So the FX TF added a resolution to not draw content on a not
> invertible matrix.

Previous examples from HTML5 and CSS have already shown, that
it is not a clever idea, just to document bugs and funny behaviour
of current user-agents instead of writing a draft or recommendation
with meaningful behaviour ;o)
It is just awkward to make programmers look the fool by specificing
their accidental bugs or unqualified solutions as valid behaviour -
nobody is perfect and the best way to improve is to indicate and
fix such problems without much uproar.
The same applies here. If bugs are not fixed, this indicates not much
more than such problems or lack of time of the programmers - this is 
maybe understandable, because due to the huge number of bugs 
and problems, they cannot care about everything immediately.
But this is more a practical problem - maybe too many drafts
and changes in too short time - this is another argument for
good backwards compatibility and against pretty incomplete
drafts as soon as possible ;o) 
...

>
> At first I am really sorry if you got the impression that we wouldn't care
> about the thoughts authors. 

There were other funny issues, now already present in a CSS recommendation,
that resulted already in such impressions, as well as the repeated 
thought-terminating cliché that nothing in such a draft is changed, if it is
already implemented,  no matter, how this implementation result is related 
to a meaningful interpretation of a feature or not.
If such a draft becomes only a documentation of implemented things, 
why should authors care at all about such drafts, why at all
recommendations at the W3C?
If implementations already matter, the drafts come too late.
At least for me it is always more important for such texts, that they
are consistent (self- or with other related texts) and that the 
definitions describe the intended features and not the implementation
bugs ;o)


Rik Cabanier:
>> >If the element is skewed to 90deg, I agree that everything should
>> disappear.
>> >
>> This can be surprising as well, because here already the fill area is not
>> necessarily zero - isn't this conserved for skewing in general?
>>
>
>But it would be mathematically correct though.
>When you skew to 90 degrees, the shape's length becomes infinite. So: area
>divided by infinity becomes 0

Mathematically you have to determine the limes to infinite skewing/ 90 deg. 
If for all 'finite skews' the fill area is constant, it will be the same for 
infinity as well.
But of course presumable the part remaining in the viewport can
become effectively 0, but it still can have a 1D-structure as border/stroke,
that can be asumed to be present for nonscaling-stroke.
Obviously it is always possible, to define specific rules for
specific angles, for example no rendering, if angle in degrees
is divisible by 9 - but does it really help authors, really wanting
to use a combination of nonscaling-stroke and skewing?
And of course angles like 90 deg for skewing is less a problem
than transforms with non-invertable matrices (determinant 0) -
because authors should expect trouble here, if they do not
avoid such skewing angles ;o) Admittedly it is difficult to deal
with infinity numerically - therefore some more mathematical
exploration of the problem and resulting hints for implementors 
are a good idea here. At least, the problems I have already seen 
(funny dancing shapes) in current SVG implementations seem to 
be related to rounding problems or the limited internal number 
range, therefore just to move out 90 deg may not solve all practical 
implementation problems here anyway.  Infinity is a nasty thing,
not only for computers.


Olaf

Received on Sunday, 13 May 2012 16:10:39 UTC