Re: 'stroke' shorthand

On 2013-11-15 03:36, Dr. Olaf Hoffmann wrote:

> If you have stroke-linecap="round' for paths of zero length, the
> result will be invisible, if this is removed by styling.
> If you have spiked curves with specific requirements for
> stroke-miterlimit, the result will be nonsense, if this is
> removed by styling.

This is all summarized in your (and also my example). Understood and 
agreed that there are multiple stroke-* attributes. I did read your 
original post :)

> And if different stroke presentation attributes are noted, because the
> order is not important for attributes, one has to define for SVG 2,
> what applies, if someone notes
> <path d="M0 0 100 0" stroke-width="10" stroke="red" 
> stroke-linecap="round" />

It might be best to define CSS ‘stroke’ as a shorthand, but leave the 
presentation attribute ‘stroke’ as a longhand (essentially an alias for 
stroke-color), and mark ‘stroke’ as deprecated. So the width and linecap 
in your example would be retained in all versions. Alternatively, the 
interpretion of the presentation attribute ‘stroke’ as a shorthand could 
be conditional upon a 2.0 document version, as Paul suggested. My 
overall sense is that shorthands are very useful specifically in a CSS 
context, with most major bugs finally resolved, but a real source of 
parsing, inheritance, and override issues in other contexts, getting the 
author lots of compatibility issues for very little convenience. I agree 
that attempting SMIL animation of a shorthand is in practice likely to 
always work out miserably for everyone on all sides: the WG, 
implementers, and authors.

My suggestion is that the ‘stroke’ attribute in SVG2 be treated exactly 
the same as the 'stroke' attribute in 1.1, except that ‘stroke-color’ 
attribute, when supplied, will always override the ‘stroke’ attribute so 
that:

     <path stroke=“red” stroke-color=“green”/>

will be stroked green. This is an edge case though, to deal with sloppy 
authoring. More commonly authors could desiring maximum compatibility 
would write:

     <path stroke=“green” stroke-color=“green”/>

if they wanted compatibility with 1.1 viewers, which will ignore 
“stroke-color”. Given the current pace of the browser release cycle, I 
think it's possible to overestimate breakage in a web context.

> As mentioned above, the order is not relevant, therefore I never cared
> about this - especially for the large amount of hand-coded documents
> or those done by author scripts (PHP for example), there will be no
> specific order.

Yes, but obviously, order does matter for the CSS cascade. You've 
asserted that defining CSS ‘stroke’ to be a shorthand *IN A CSS CONTEXT* 
(which is the point Dirk was originally raising) would break “most” (!) 
existing content. For this assertion to be true, it would have to be 
true that:

1) The vast majority of existing SVG content uses external stylesheets.
2) The vast majority of those stylesheets use the ‘stroke’ property.
3) The vast majority of the referenced content has stroke-*  
presentation attributes that would be reset by defining CSS ‘stroke’ to 
a shorthand, and those presentation attributes are not restated later as 
in the applied stylesheet as CSS properties that fully preserve the 
desired appearance, including any animations.

I find every one of these points dubious. If you’re going to make this 
argument, I think we need to see some numbers. Does the WG have a way to 
assess breakage arguments, other than this “finger-in-the-air” back and 
forth? Does anyone have a large database of existing content that can be 
browsed headlessly to check usage patterns in the wild? What’s needed is 
metrics. I know the CSS WG occasionally does PhantomJS testing. I hope 
we can all agree there’s a threshold below which some breakage is 
acceptable.

As Rik pointed out, CSS stylesheets generated by Illustrator always puts 
the stroke first in stylesheets. Re-pasting his example:

<style type="text/css">
.st{fill:#00FF00;stroke:#000000;stroke-width:4;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:12;}
</style>
<rect x="246" y="59" class="st" width="374" height="266"/>

Similarly, script-generated content (e.g. D3 and Raphael) basically 
doesn’t use CSS (with a very few unrelated exceptions). So there’s no 
breakage issue there. For my part, I've never authored a single file 
that would be broken by this change.

Cheers,
Alex

Received on Friday, 15 November 2013 18:56:44 UTC