Re: 'stroke' shorthand

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

Tell the HTML5 WG about those ideas, their target is more to pave the
cowpaths, which do not even exist in previous recommendations ;o)

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

I never tried without - still one has to know, what a property means,
for what it is applicable, inheritance etc and I think, there are some
examples in the past of CSS, where the intuition of implementors and
authors did not fit to the recommendation ...
Additionally one has to find out, it there are different definitions in
different versions of CSS - in such a case it is better for an author 
to avoid such a property completely or not to rely on a specific 
behaviour, if used nevertheless.

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

Because the current HTML5 draft has no namespace mechanism, its
extensibility will be very limited. Better for authors not to start with 
this at all, better to use SVG in XHTML, what is anyway already available
for a longer time. SVG in HTML will not work in older user-agents anyway.

For example in the photo gallery I already mentioned I reference only
output in another format - XHTML+CSS for longer text and larger navigation
lists and SVG(+CSS) or alternatively XHTML+CSS for areas with only
minor text parts, but with all the photos. Old user-agents are identified
by sniffing, they get an XHTML only alternative as default, in doubt for
old netscape or MSIE served as HTML - as for the others styles
the user can switch and test what works.
This avoids typical problems.
But once a user choses a style, the same stylesheet document is
used for the XHTML output and the SVG output.

>
> “stroke” isn’t yet a property in regular CSS. 

Of course, currently it is defined in SVG, but if used as property,
it is noted in a stylesheet - I do not know about the history - was
SVG 1.0 with these properties developed without the knowledge
or acceptance of the CSS WG?

> Most HTML authors who 
> don’t write SVG have probably never touched it. 

For (X)HTML+CSS it is currently without any relevance, because
there are no shapes to stroke or fill, but there are boxes with
background and border, outline etc.

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

There were already discussions about the question, whether it is
useful at all to allow to stroke glyphs in SVG (I think, for tiny viewers
it is not required, not sure, which version). SVG fonts, that allow
even more styling and shaping of glyphs, is not widely implemented, 
therefore pretty surprising, that something like this appears to be relevant
enough to create such prefixed properties - bored developers?
They could implement something, that is already a recommendation ;o)


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

There is no problem, if one choses text-stroke-*, if this really matters.
Other reasonable alternative names could be strike-*, streak-*, coat-*, 
line-* ...
No need to have 'stroke' as a name for such an application in CSS,
that seems not to be very closely related to stroke property of SVG,
having already a discussion to exclude stroke for text shapes in SVG 
for better readability. 

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

It is mainly a question, no objection.
However because paint servers like gradients or pattern are not a color,
the naming is questionable, especially following your idea above, that 
the naming should be somehow related to the meaning to avoid, that
authors have to study always the recommendations.

Because already the current stroke values are complex and for example
difficult for animation, _this_ would be a good reason to change something,
for example splitting this into two properties.

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

Sure, but why to have two names for the same thing?
And if another definition for stroke appears, stroke is not well defined 
anymore. Therefore it is clever not to note somewhere a deviating
definition for stroke, whatever the meaning of 'stroke-color' might be.

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

Well, starting with viewers for SVG 1.0 and over the years a few for
SVG 1.1, some others for SVG tiny 1.2, overall the progress in implementations
is slow.
For example due to my systematic tests, Opera 10 is still the viewer with the
highest probability to get a corrent presentation of a random SVG document 
right. The quality decreases slowly up to version 12, the final Opera/Presto.
For Gecko/Firefox after some promising efforts in the first years of SVG 
support now we can see almost stagnation on a level clearly below Opera
10. For a viewer like Batik/Squiggle already for a longer time there was
no update. webKit viewers had problems with either decoding or they
indicated that they need a plugin to present SVG on my Debian-Linux,
therefore finally not something relevant for testing or daily use ;o)
(sister Konqueror KHTML+KSVG or something like this is still more 
predictable than such forks - it really displays something).
MSIE seems to have some stagnation as well, if available at all.

To resume, there is currently not much progress in SVG implementations.
If one tries to extrapolate this, there is not much need to care about
new versions of viewers for a few years. It may take even longer until
one reaches the level of Opera 10 again - if at all, we will see ;o)

> Do you seriously believe that people will be using Inkscape 
> 0.4, Illustrator CS6, and FF25 in 20 years?

It is questionable, that new versions will differ a lot concerning
proper interpretation of stroke related issues and many other
issues as well - and hopefully not in a backwards incompatible way.
Else there will be an even bigger decrease of quality and more
need to keep the older viewers.
It cannot be excluded, that there are more regressions than
progress as well - in such cases it is pretty useful to keep older,
better versions - for example for some aspects Firefox
version 4 to 8 is a clearly better choice than the current version of
Firefox, for some other aspects not - there are both several
regressions and bug fixes.

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

Indeed, back in 2005 I was more optimistic, but in the average
currently stagnation seems to dominate the different versions of user agents.
As in the past 10 years, better to keep a larger collection of viewers to
see the differences in presentation. 
For some old SVG files, unfortunately 'designed' including the bugs of
the adobe SVG plugin, one even has to use this one - what is not really
bad for proper files as well compared with several current viewers.
I'm surprised over years, that no one fixes the bugs in those old SVG files,
because the typical display today is a correct error message about the
bugs - maybe the authors still assume, that the adobe SVG plugin needs
to be used ;o)

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

Due to additive sum, this might result in yet another presentation.
One has to use a switch with a feature string to offer the first
alternative to older viewers and the second to those with some
interpretation of stroke-color and such a new stroke, else a new
viewer animates both and one gets another surprise.
And as already mentioned, switch together with animation elements
does not work with several current implementations, causing even
more trouble.
Authors, who want to solve this, need to apply user-agent sniffing,
serving different files to new and old viewers - or they provide different
versions of the document to select manually.

>
> But SMIL’s usefulness in the web space is pretty sad at the moment. 

You mean the timesheets - yes, unfortunately there seem to be not
much attempts to implement this.

But within SVG some subset of declarative animation in SVG is already ok
for today, there are more viewers doing this than a few years ago.

> IE refuses to implement it

I do not consider this an SVG viewer - is this still often in use? ;o)

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

I do not know, what rAF animations are - presumable I have never seen one, 
but the subset of declarative animation in SVG implemented in several viewers 
correctly is already quite useful - fortunately. When I started, this was 
much more problematic.
Now often one can assume, that the audience can see what was intended
without forcing them to install other, more advanced programs.
The main problem for authors is to know, what the subset is, they can use -
this problem never changed within all the years, only the subset got slightly
larger in the average and stabilises now on some incomplete level due
to the implementation stagnation.


> Anyone attempting to write cross 
> platform animation for the web using SMIL is currently *doing it wrong*.

Not sure, if timesheets or the original SMIL approach is really used.
What survived is the derivative in SVG, that differs already from the
original SMIL (especially for such values as fill and stroke).

For SVG one should always provide a text alternative, if it matters for
content.
Declarative animation in SVG seems to be the most advanced
'standard' method today, if this is relevant for content, there are not
really alternatives, that are both recommendations and somehow 
implemented in often used user-agents.

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

I was excited about this years ago. - Looking on my statistics, not sure,
if it still evolves after Opera stopped to develop this Presto engine. 

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

I provided several other problematic use cases already.
And if people will really start to use EPUB 3 the situation will get
more problematic - more static digital books with SVG content,
that gets soon out of control of authors.

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

There is no indication for this in the SVG definition.
What 'real world' do you talking about?
One can and one does note this in any order.
But as we already mentioned, there is not much content at all
with external stylesheets and a meaningful usage of properties
at all. Is there really much more than my ~74000 (I took a look at
the current state of content) samples?
For attributes this is used in any order, and because this
inherits, presentation attributes applicable for more than
one element are noted in the root svg element or on a g element.
On demand scour cleans up stupid usage of style attributes 
and if desired, I think, it moves applicable presentation attributes 
in g elements to decrease file size.

> That's what insulates existing content from most breakage 
> if 'stroke' gets redefined as a CSS shorthand.

No, the mentioned inheritance is yet another scenario, where
you get in big trouble with such a redefinition.
The stroke attributes (and properties) applicable for an element
are not necessarily noted at this element, and even in 
stylesheets this is not necessarily always selected with a
fragment identifier selector.

With some more days to think about it, maybe even more
problematic constructs come up to result in nonsense, if
the interpretation of current stroke is changed.


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

Hmm - but width is no shorthand that resets for example the src and alt of
the img as well - in both cases it gives information about the same issue
and does not change something else, not related.

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

Not sure, that they will get it all - for example up to now there was only one
major try to get 'all' of my art gallery - and this silly robot failed and 
gave up after some time ;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. 

I provided other examples as well...

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

My example was only intended to show, that such counting is problematic.
I you do not find my examples, your statistical relevance can be questionable,
if I have many files protected against robots for example or somehow 
frustrated for robots.
If you only have my examples (indeed I know maybe a few thousands
of other SVGs from other authors as well, but this is much less than
the number of my files) - this results in some bias as well, because this
gets dominated by my style of notations.
If you get a huge amount of inkscape files (not cleaned up manually or
with scour), you will get a bias resulting from bad practice of inkscape
developers, abusing the style attribute for everything.
Potentially the number of automatically generated SVGs by my
scripts in my art gallery is bigger than the manual output of inkscape.
How to compare this - I have hundreds of different scripts, but there are 
only a few inkscape versions. Therefore if we only count SVG document
generators, still my art gallery wins by just counting - and none of my
scripts abuses the stroke attribute or something similar ...

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

No, indeed they decided not to collect arbitrarypublished web content
currently.
Only a few blogs might be of some cultural relevance - but of course, 
they cannot exactly know, which ;o) This is different from NSA and other
big brothers - those might collect all they can get - and even if not 
published at all ;o)
But I'm curious about the moment, they start some collector for the web 
and this tries to harvest such a project like my art gallery, they get new
content everytime their harvester wants some - and indeed they do not 
have to collect unique copies at all ;o)

But they started to collect digital books in the format EPUB (that
can contain SVG as well).

> Formats evolve, sometimes for the better. The archivists 
> will find a way. 

They are not necessarily allowed giving access to manipulated content
to others without the permission of the author (german: Urheberrecht) - 
the author only has to send them the file/media/book (with no DRM/encryption)
after publication.
Because you can read the media in the library and they are not allowed
to manipulate that content, what you will get is what the author once
published.

...
>
> SVG Drawing apps and js libraries don’t generate SVG “tag soup” in any
> sense of term. They generate (relatively) strict XML. 

Technically it will be in general ok, but there is another type of tag soup -
if the markup/notation does not fit to the content.
This typically applies, if they put none decorative parts of the document
into the style attribute, indicating it as decorative.
But if you remove all style attributes, the presentation will be in most cases
not meaningful.
Those programs do not understand what they do or what the intentions of
an author are, therefore they produce files, that need to be cleaned up
before publications to be meaningful.
I have seen several of these unchanged outputs for example at 
wikimedia commons - the unfortunate amount is a reputational damage
of the SVG format.

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

No, one has to explore, that such a change has no awkward effect:
a) interpretation of old files by new viewers should not differ from the 
intentions of the author (assuming that this is aligned to an older 
recommendation)
b) there should be a way, that authors can write in an easy way new documents, 
that are still presentable with old and new viewers, if they decide to only 
use a subset of elements, attributes, properties of the new recommendation, 
but already defined in an older recommendation.

But as the discussed examples show, a redefinition of stroke has such
awkward effects, presumably we did not even get all of them.
Therefore chose another name for a new feature - maybe a completely
new name, if this does not apply to SVG at all as mentioned above,
if you need such shorthand naming consistency within CSS definitions.

> I submit that no file authored by a drawing 
> application or a js library 

How to know, which you don't know and which are not considered for everyones
use, but producing files as well. 

> 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.
>
With no incompatible change, you can be sure, that this applies as well for 
all the scripts and programs you don't know about - and additionally for all 
handcoded files ;o)

And if one observes the handling of bugs and gaps of viewers, every
idea to redefine such an often used feature as stroke with currently more
or less acceptable implementations might create major headaches 
and heart attacks to millions of authors, if they get informed about it ;o)

Olaf

Received on Wednesday, 20 November 2013 18:24:30 UTC