Re: 'stroke' shorthand

Tab Atkins Jr.:

...
>
> Dirk's code is obviously useless, but the resetting functionality
> itself is very useful.  (Not to say it's always what you want, of
> course.)  Imagine the "stroke" shorthand was in a different style
> block from the group of longhands, written by a separate author.  The
> person writing the "stroke: green;" is expecting to get a "default"
> stroke, just green-colored.  If it didn't reset, then a bunch of other
> properties would bleed through and mess up the styling.
>
> ~TJ

If we assume the typical behaviour of current viewers to ignore
version indications in documents - and we have additionally in
mind that CSS documents have no version indication at all,
a redefinition of stroke will cause problems for almost all (good)
SVG 1.1 documents.
Therefore I think, it might be useful to have such a feature with a
new name, but not by corrupting the meaning of an old feature
like the stroke property.

For example in several of my SVG documents, that use stroke-dasharray
such a pattern is strongly related to the curve it is applied to -
it is calculated relative to this curve, therefore the stroke-dasharray
is noted as presentation attribute to indicate, that is is content and
no decoration. But often for example the color of the stroke may
change decoratively. If one provides an alternative view of such
SVG 1.1 documents with an external stylesheet, this will 
typically contain only the stroke property to be changed.
Because the  stroke-dasharray is content and strongly related
to the curve, it would corrupt the meaning of the document to
reset this with the set of stroke in the stylesheet.
And if new viewers would do this by ignoring, that the stylesheet
is applied to an SVG 1.1 document, the presentation of such 
existing documents is simply corrupted.
Another related issue - if the stroke-dasharray presentation
attribute is animated and a viewer resets the value, because
in a stylesheet just the stroke property is set, there will be no
visible effect of the animation anymore - never intented by
an author of an SVG 1.1 document.

With (X)HTML+CSS the line between content and decoration
is more obvious than for SVG (+CSS). What works pretty well
for (X)HTML+CSS will often not work for SVG (+CSS) in the same
and meaningful way.
Typically for SVG documents, the presentation attributes
matter for content - for (X)HTML there is typically no need for
presentation attributes at all.
Usually I think most authors will not provide an alternative
view of an SVG document at all.
Therefore the most relevant part about properties is, that
they work pretty well as presentation attributes, stylesheets
are more a nice and beautiful addition for a few advanced authors.

If you remove all presentation attributes from a good SVG document, 
for most documents you will not understand their meaning by the graphical 
presentation anymore - this indicated, that for graphical content the
presentation  attributes are a very important part of the content.
Therefore to introduce a backwards incompatible change of the 
meaning of a property breaks content, not just decoration.

Therefore, if such a shorthand notation has use cases, it
needs a new name to protect current viewers from breaking existing 
content with the implementation of such a new feature,
if they do not take into account a version specific behaviour 
for such an else incompatible changed feature.

Olaf

Received on Thursday, 14 November 2013 11:09:58 UTC