W3C home > Mailing lists > Public > www-svg@w3.org > November 2013

RE: 'stroke' shorthand

From: David Dailey <ddailey@zoominternet.net>
Date: Thu, 14 Nov 2013 21:30:03 -0500
To: "'Dr. Olaf Hoffmann'" <Dr.O.Hoffmann@gmx.de>, <www-svg@w3.org>
Message-ID: <006a01cee1aa$97785a20$c6690e60$@net>
This all sounds accurate to me. 

Folks will be pleased to know that I deleted a whole paragraph of philosophy about the topic.*


* After all, it was well-intentioned philosophy that almost derailed the HTML5 super-express. 

-----Original Message-----
From: Dr. Olaf Hoffmann [mailto:Dr.O.Hoffmann@gmx.de] 
Sent: Thursday, November 14, 2013 6:09 AM
To: www-svg@w3.org
Subject: 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.

Received on Friday, 15 November 2013 02:30:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:47 UTC