Re: 'stroke' shorthand

Alex:

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

If you have a map, where the width of the stroke for example indicates
approximately the width of a street or river, this is content as well, that
is not to be changed, if color is changed in an alternative view.
If you have samples, where the stroke has to be the same width
as the diameter of a circle moving along the path, the 
presentation will be simply nonsense as well, if the content relevant
width is removed by styling.
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.

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

SVG 1.1 has no presentation attributes for shorthands, to avoid that
one has to define what this means, if used together with normal notation
in single attribute.

If you try to do a SMIL animation of such a shorthand property,
it will be always discrete, not continuous due to its complex, non numerical
structure.

> Even if the author redeclares a matching stroke-dasharray in CSS, this
> would wipe out any existing animations on the dasharray. 

This applies only, if one animates the presentation attribute, not the
property or 'auto', however if it matters for content, one might want to
do this.

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

Indeed, it is ugly, but thats life ;o)
We cannot go back in time to change history (at least there is currently
no method to do this and no indication, that we ever can do this
for our past).

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

Note, that such a property has to be in the SVG 1.1 list to have an
effect. This means, proper SVG 1.1 viewers have to ignore all
properties not explictly noted in the SVG 1.1 recommendation.
Because all current SVG documents are either SVG 1.0, SVG 1.1 or
SVG tiny 1.2 (no CSS styling required at all), such a property has
no effect for all current documents per definition, 
even if implemented later for SVG 2 documents.
This applies for something ugly as 'stroke-shorthand' as well,
but because this will not appear for SVG 1.x documents, this
results in no problem.

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

Authors just have to take into account, that older viewers will ignore this,
therefore in their stylesheet they have to note:
stroke: red;
stroke-color: red;
anyway to ensure, that older viewers do the right job.
And to ensure, that new viewers do the right job as well,
of course they always have to repeat all the other stroke related
properties again in the stylesheet, because the stroke required for
old viewers will remove all of them for new viewers ;o)
This means, if any of the stroke properties is relevant for content,
their value will be specific for a specific document and one can
forget about the idea, to apply one stylesheet to more than one
content file - and this was one of the big adavantage of CSS ;o)

This is even more ugly and uncomfortable than just a name 'stroke-shorthand'.

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

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.
And if noted as presentation attributes (what should apply
for all good SVG documents as the initial presentation), the order
is not relevant as well even for SVG 2.

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

No - it corrupts both SVG and some core use cases of CSS stylesheets
as mentioned above.
And of course it exposes, that the usual suspects of viewers will
doing it wrong by ignoring version indications in documents ;o)

If such an incompatible change is done for SVG 2, my suggestion
for authors to avoid problems is to forget about stylesheets and
property notations at all and to forget about providing alternative
views for SVG documents.


> And those breakages would be very 
> easy to fix. 

No - there is no authority to do this - you do not have access to any
published file and typically no right to modify it.
Even if you want to do this, you can't or you are not allowed to do it.

> This solution would also completely avoid the problem Olaf 
> describes.

No, it introduces the problem, I described ;o)

Olaf

Received on Friday, 15 November 2013 11:37:19 UTC