Re: 'stroke' shorthand

On 2013-11-14 03:09, Dr. Olaf Hoffmann wrote:
  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.

To summarize Olaf’s point as I understand it: Authors who want to change 
the color of a dashed line created in SVG using CSS might declare 
“stroke: green” and inadvertently wipe out a stroke-dasharray effect. 
Even if the author redeclares a matching stroke-dasharray in CSS, this 
would wipe out any existing animations on the dasharray. This is a 
genuine compatibility problem. There ought to be a simple way to change 
a stroke’s color in CSS without changing anything else.

On the other hand, I really don’t like the idea of ‘stroke-shorthand’ as 
a CSS property. It feels contorted, and wildly inconsistent with 
existing CSS shorthand patterns. It works, but there’s something just 
really ugly about it.

I also agree with Tab about the usefulness of shorthands as reset. This 
should be seen as a positive feature, one that CSS authors are 
accustomed to expect. There should be no exceptions made to this rule.

In retrospect, it would have made the most sense in the beginning to 
have named the “stroke” attribute  “stroke-color” instead. It’s more 
descriptive, more consistent with the CSS “background” and “border” 
property naming conventions, and it frees up the ‘stroke’ term for a 
shorthand. If that had been the case from the beginning, we wouldn’t be 
having this discussion now.

Of course, things didn’t happen that way. But isn’t there a way to get 
there from here? What about adding ‘stroke-color’ to both SVG and CSS, 
and changing “stroke” to a shorthand across the board? This is somewhat 
draconian, I realize, and probably off of the table for procedural 
reasons, but it might be functionally better than the alternatives. 
Going forward, legacy SVG ‘stroke’ attributes that only supply a color 
would be treated as a shorthand, and would still work with most 
legacy-content, which in my experience supplies “stroke” values before 
“stroke-width”, “stroke-miterlimit”, et al. I virtually never see those 
properties specified in the opposite order. There would be occasional 
breakage, of course, but achieving a strong, highly consistent alignment 
with CSS might be worth that price. And those breakages would be very 
easy to fix. This solution would also completely avoid the problem Olaf 
describes.

FWIW I would rather see a few ancient pages break than watch a mongrel 
like “stroke-shorthand’ find its way into the spec, or create a set of 
CSS properties with no independent way to exclusively target a stroke’s 
color. At some point the concern with legacy content has to give.

Cheers,
Alex

Received on Thursday, 14 November 2013 21:49:55 UTC