Re: 'stroke' shorthand

Alex write:
> What about adding ‘stroke-color’ to both SVG and CSS, and changing
“stroke” to a shorthand across the board?

And breakage could be additionally mitigated if SVG2 renderers didn't
honour the reset behaviour if the document version="1.1".


On 15 November 2013 10:49, <alex@bellandwhistle.net> wrote:

> 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
>
>