Re: 'stroke' shorthand

On 2013-11-16 07:42, Dr. Olaf Hoffmann wrote:

> You really want to introduce a new CSS property with the same name
> as an old SVG property/attribute? ;o)
> And for what? Just to please your aesthetic feelings about the usual 
> CSS
> naming of shorthands - this is only a theoretical concept that competes 
> here
> with existing, well defined content.

Developer aesthetics are important. This is not an “esoteric” notion in 
any sense of the word. Clean, elegant APIs prosper over those that are 
crooked and hard to remember.  The usage history of JS libraries shows 
this to be true, and SVG's lack of any real competition shouldn't be an 
excuse to forget this. Part of the utility of CSS is that you don’t need 
a reference manual to write it.

“stroke-shorthand” isn’t just another ugly duckling, it’s a stumbling 
block that every beginning author will trip on, again and again again, 
for the infinitely foreseeable future. I think that future stumbling, 
(by people who are perhaps just being born now) needs to be accounted 
for as “resistance”. That’s why I think it’s worth investing some time 
exploring alternatives, and exploring their real world consequences. The 
potential of SVG within HTML is much vaster than what it can accomplish 
within its current garden of namespaced, legacy content.

“stroke” isn’t yet a property in regular CSS. Most HTML authors who 
don’t write SVG have probably never touched it. There are proprietary 
stroke properties in webkit:

    -webkit-text-stroke-width: 1px;
    -webkit-text-stroke-color: black;
    -webkit-text-stroke: 1px black; //currently implemented as a 
shorthand, note the naming/syntax

but porting ‘stroke’ in any fashion to regular CSS is something new, and 
IMHO should be approached with consideration for *both* existing CSS 
conventions and backwards-compatibility with existing content.

We agree that backwards-compatibility is hugely important. I’m hoping we 
could also agree that there’s a threshold beneath which a minuscule 
amount of breakage is tolerable in order to achieve a tight alignment 
with CSS, specifically the convention of using the first particle of the 
property name group as the shorthand. The is how background-*, border-*, 
outline-* et al all work.

> stroke-color just for the color, or for paint servers and 'none' as 
> well?

I don’t understand your objection. “stroke-color” should behave exactly 
the same as stroke, including paint servers, without exception. There is 
no inconsistency.

> Because 'stroke' has already a well defined meaning, one only needs
> a new name for this new feature.

All of that well-defined-ness can be easily mapped to 'stroke-color'.

> A typical notation after such an awkward change for the next
> 10 or 20 years:
> stroke: url(#MyStroke), red icc-color(MyRedColour, 1);
> stroke-color: url(#MyStroke), red icc-color(MyRedColour, 1);
> stroke-opacity:1;
> stroke-width:1;
> stroke-miterlimit: 1;
> stroke-dasharray: 1;
> stroke-dashoffset:1;
> stroke-linecap:round;
> stroke-linejoin:round;
> stroke: url(#MyStroke), red icc-color(MyRedColour, 1) 1 1 1 1 1 round 
> round;

20 years?! I think you’re vastly overestimating the lifespan of existing 
1.1 viewers. Do you seriously believe that people will be using Inkscape 
0.4, Illustrator CS6, and FF25 in 20 years? They might well be using one 
of those pieces of software, but not that version. I actually can’t tell 
if you’re kidding here about the timeline. On the other hand, I think 
it’s plausible, even likely that tens of millions of people will still 
be writing CSS in 20 years. In truth, the longer-term we think of, the 
more attractive a slight re-mapping of “stroke” appears.

> What do you expect for example for
> <circle r="10" stroke="red">
> <animate attributeName="stroke"
>                  dur="12"
>                  values="#00f; #0f0; #0ff"
>                  additive="sum" />
> </circle>

You’re absolutely right, Olaf, there would be a breakage there. An 
author wanting maximum compatibility in the interim would have to write:

<circle r="10" stroke="red" stroke-color="red">
<animate attributeName="stroke"
                   dur="12"
                   values="#00f; #0f0; #0ff"
                   additive="sum" />
<animate attributeName="stroke-color"
                   dur="12"
                   values="#00f; #0f0; #0ff"
                   additive="sum" />
</circle>

But SMIL’s usefulness in the web space is pretty sad at the moment. IE 
refuses to implement it, and the webkit/blink implementations are still 
locked to the 40kHz timer, which means the requestAnimationFrame timer 
will basically always outperform it. In browsers, SMIL animations look 
like garbage next to rAF animations. Anyone attempting to write cross 
platform animation for the web using SMIL is currently *doing it wrong*. 
I am excited to see these situations evolve, but that’s the state of the 
art at the moment, and so we’re really talking about a future tense 
here. My workaround is verbose, I would agree, but you're talking about 
a single use case here, working in what is currently at this moment a 
highly non-performant "red flag, wrong way to go" authoring pattern.

>> Yes, but obviously, order does matter for the CSS cascade.
> No, currently not.
> For stylesheets as well, it does not matter if you write
> stroke-width:10; stroke:red
> or
> stroke:red; stroke-width:10
> why to change this?

Yes it does matter. That's the point. In the real world, the 'stroke' 
CSS property generally gets stated before other stroke-* properties in 
the cascade. That's what insulates existing content from most breakage 
if 'stroke' gets redefined as a CSS shorthand.

> If you have a presentation attribute of the same name with such a
> shorthand functionality, you have to define, what it means as well -
> and as explained above, it must have the same meaning than the
> property.

No, that's not strictly true. There can be slightly different handling. 
Across HTML/CSS there are examples where identically-named attributes 
and properties accept different values. Dimension attributes on img, 
iframe, embed, object, video are the obvious case:

<img width=“auto”> // No, no keywords.
<img width=“100%”> // No, no percentages.
<img width=“100”> // Yes, Positive integers only, interpreted as CSS 
pixels

<img style=“width:auto;”> // Yes.
<img style=“width:100%;”> // Yes.
<img style=“width:100px”> // Yes, and requires units.

SVG could do the same thing with ‘stroke’, treating the *attribute* as 
an alias for stroke-color, and treating the CSS *property* as a CSS 
shorthand. They don't have to be uniformly identical in every 
particular. The 'stroke' attribute would accept the same values it 
accepts now.

> I assume, that only for a minority of SVG documents it is meaningful at
> all, to use any CSS notation -

We agree here.

for example the style attribute should be
> depreciated in SVG 2, because it is widely abused for nonsense
> in several SVG editors. One always has to fix this either by hand
> or with something like scour before publication, to get some meaningful
> content.

A separate topic.

> As you can see, number counting is always biased by the point
> of view and how to count and does not really help to get it right.

Obviously it would take NSA-scale servers to characterize existing SVG 
content in its entirety. Any partial sampling method will have a certain 
built-in biases. I was curious if there are any agreed-upon methods for 
this, but it sounds like there aren’t. Too bad. :(

> Stupid biased number counting typically creates misleading results
> and wrong conclusions.
> I think, we have already seen, that such biased number counting can
> be quite misleading, if we look at some HTML5 efforts based on 
> statistics ;o)
> If the counters had mainly access to tag soup, it wasn't a surprise, 
> that they
> mainly found tag soup ;o)

Sure. But either real-world usage patterns matter, or they don’t. You 
can’t have it both ways. You can’t cry wolf about massive widespread 
breakage and then offer a single example involving SMIL. You can’t 
appeal to empirical statistical evidence and then not offer any. You 
can’t accuse me of statistical bias and then offer your own personal 
library of files as the database to do testing from. :)

> And even if you find, that something breaks maybe only 10% of the
> documents you found, this does not neccessarily mean, that it does
> not cause problems for other parts, you did not find.
  (for example in germany there is a law that a national library
> has to collect all published books and several other media considered
> to be of cultural relevance - an author cannot change SVG content in
> those collected media anymore, you cannot update, you need to
> publish a completely new media, if you need to change something -
> once they have it, all versions are conserved for 'eternity').

You’re right, the National Library of Germany will never be able to look 
at all those awesome blogs hausfraus wrote ten years ago using the 
<blink> tag. :) Formats evolve, sometimes for the better. The archivists 
will find a way. I think we're talking about a change of similar 
magnitude here, for significantly better semantics and consistency.

>> 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"/>
> 
> This looks more like an example, why one should depreciate
> the stroke element in SVG 2 as well - the stroke-miterlimit:10
> and stroke-linecap:round for a rect already indicates,
> that the program does not understand, what it does -
> authors of good documents will have a lot of work to clean
> up the output of such programs before publication ;o)

This makes no sense to me. I see the "conflict", but it's not an 
authoring error, strictly speaking.

SVG Drawing apps and js libraries don’t generate SVG “tag soup” in any 
sense of term. They generate (relatively) strict XML. A professor could 
probably refine it, but the comparison to the chaos of HTML authoring is 
none. Obviously, what matters for considering compatibility is how 
‘stroke’ is currently used in stylesheets, and in what context, not 
simply that it is used. I submit that no file authored by a drawing 
application or a js library that I know of would be broken by this 
change, and it would save several million small headaches going forward 
for the years to come.

Cheers,
Alex

Received on Monday, 18 November 2013 21:16:06 UTC