- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sat, 16 Nov 2013 17:42:56 +0200
- To: www-svg@w3.org
Alex:
>
> > 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.
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.
Currently there is no other reason identifiable than such esoteric,
theoretical concepts, why not simply to chose another name for it?
Additionally you want to introduce another new property/attribute with the
meaning of the old property/attribute - this looks like the concept 'why
keeping it simple, if we can do it in a way, that causes incompatibilities
and trouble'.
Even more you want to define, that the meaning of the old attribute
remains, but not that of the property with the same name - causing
even more trouble and inconsistencies, difficult to explain to any author.
stroke-color just for the color, or for paint servers and 'none' as well?
Is it a proper name, if all this can be noted? Isn't it much more confusing,
to note paint-servers or 'none' as a value in something that is called
'stroke-color'? 'stroke' is a much better name for this (overloaded)
value ecosystem...
All this sounds like an intentionally very confusing concept from the point of
authors, especially because we already have a simple concept for stroke
related properties and attributes, that is backwards compatible.
Due to the requirement of SVG2 to be backwards compatible,
it is straight forward to find simply a new name for the new feature
shorthand property instead of corrupting the existing attributes/properties.
> 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
I think, the behaviour of such a shorthand should be consistent.
It is a new feature and it should not be burdened with such unneccessary
complications.
Because 'stroke' has already a well defined meaning, one only needs
a new name for this new feature.
It is pretty simple here to have both - a new property and backwards
compatibility.
There is no need for all this confusion of a redefinition of an often
used property/attribute.
From the point of a current proper SVG/CSS viewer, any 'extensions'
to the value of stroke results in an invalid value.
Therefore this does not only imply problems for the presentation
attributes, if implies problems for authors of stylesheets as well.
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;
just to ensure, that old and new viewers both get it right - this does not
really look like a simplification for authors, it is simply confusing,
that one has to set the stroke always triply with different meaning
to cover different implementations, functionalities and flavours.
> 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.
What do you expect for example for
<circle r="10" stroke="red">
<animate attributeName="stroke"
dur="12"
values="#00f; #0f0; #0ff"
additive="sum" />
</circle>
?
For a proper SVG 1.1 viewer this animates continuously the stroke property
due to the default attributeType and uses the 'red' as
underlying value for the additive animation.
A viewer with some shorthand implementation for stroke
will recognise:
a) because their is no attributeType set to XML, animate the shorthand
property automatically.
b) because continuous animation is not possible for shorthands, switch to
calcMode discrete automatically.
c) because additive animation is not possible for shorthands, ignore the
attribute.
You will get two completely different interpretations for this example -
and it is common practice not to set attributeType (and several, maybe all
implementations have bugs concerning attributeType), therefore if there is
a property at all, it must have the same meaning as the presentation
attribute.
Now - what can authors do to get it right in both kinds of viewers?
One has to introduce a switch element with a feature indication for
old and new stroke - to feed the old viewers only with the animation
above and the new one only with an animation of some new
'stroke-color'.
Taking into account, that switch elements in relation to animations
do not really work in the usual SVG viewers due to bugs and gaps,
effectively one can forget this theoretical approach with switch.
And all this just to please your aesthetics about naming?
>
> My suggestion is that the ‘stroke’ attribute in SVG2 be treated exactly
> the same as the 'stroke' attribute in 1.1
See above, this must apply for the property as well.
> , 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”/>
>
This will cause no backwards compatibility problem.
Another improvement will be to move all not simple color related things
(paint servers, and value none) to a new attribute stroke-server, that
overwrites the stroke value as well, if present.
Still one has to define, what happens, if authors still note stroke-server
related issues in stroke, maybe different from that in stroke-server with
a similar rule.
> 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.
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?
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.
> You've
> asserted that defining CSS ‘stroke’ to be a shorthand
This I never claimed:
> *IN A CSS CONTEXT*
The following applies, because stroke is often used, and introducing values,
that are backward incompatible of course creates trouble - both for old
viewers interpreting new documents and new viewers interpreting old
documents, als long as viewers do not care about version indication and
CSS has no version indication - effectively with two different definitions of
the same issue, the issue gets undefined in CSS, there are already a few
examples in CSS resulting in undefined nonsense due to backwards
incompatibilities, for example the length units desaster and the problem with
the clip property and if the related CSS 3 draft will ever become a
recommendation, for text-shadow as well.
> (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.
No, see above.
And there is a style element and a style attribute as well.
I assume, that only for a minority of SVG documents it is meaningful at
all, to use any CSS notation - 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.
> 2) The vast majority of those stylesheets use the ‘stroke’ property.
It is reasonable, that they do.
Indeed I have only one, but large project, that provides an alternative
view with an external stylesheet - it uses only stroke in the stylesheet,
but other stroke-related attributes within the content document.
If such a stylesheet is available at all, it is reasonable, that stroke is
decorated as well - or with a similar probability than fill.
> 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.
It is reasonable, that several stroke-* attributes are strongly related to
the content as already explained.
Depending on the application, I think, similar to (X)HTML the color is
much more often presentational than the width, dasharray, miterlimit etc.
There is a simply check for this, - if one removes all these presentation
attributes and all properties and it matters for the graphical presentation,
all these are important for the understanding of the content and therefore
necessary and not only decorative - therefore for a good and accessible
document, one has to note them as attributes and not (only) as properties.
This does not exclude, that one provides alternative views with
additional stylesheets resulting in another graphical presentation.
Tag soup produced automatically by some editors/programs abusing the
style attribute can be neglected for this discussion, bescause this
does not result in meaningful documents and there is no need
to care about consistency for the interpretation of tag soup, but
it matters for good and meaningful documents.
>
> I find every one of these points dubious. If you’re going to make this
> argument, I think we need to see some numbers.
No. SVG 2 has the requirement to be backwards compatible.
Because it is quite simple to introduce a new name for such a new
shorthand property, there is no need to force such unnecessary
backwards imcompatibilities.
But if you like, just I have a photogallery with maybe more than
60000 different SVG outputs and an art gallery with practically
an output of infinite number of different SVG documents
(available starting in ~2005 already, effectively due to the limitations
of the server and your viewer, of course you can get only a minor
finite subset in a finite duration...).
If we just look at this, this is already a lot just for one author.
And if you can only add a finite number from other authors to my
infinite number of own available outputs, we can simply neglect
the finite number for further discussion from a mathematical
point of view, if number counting really matters ;o)
And if we talk about numbers - currently there are approximately
zero documents and viewers following such a redefinition of stroke.
Clearly we have 'much more' documents and viewers following
the current interpretation of stroke compared to none for the
suggested change...
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.
> Does the WG have a way to
> assess breakage arguments, other than this “finger-in-the-air” back and
> forth?
They simply have an important (!) requirement for SVG 2 to be backwards
compatible.
> Does anyone have a large database of existing content that can be
> browsed headlessly to check usage patterns in the wild?
It is not wild, but if you look on my numbers above, I have a large
database just due to my documents - additionally a finite larger
number spred around in different projects - but because nobody has
access to all content, in books or without direct access over internet,
one can simply assume, that after more than 10 years of SVG
the stroke related attributes are really used in many documents,
some more, some less of course, stroke itself quite often ;o)
Taking into account the infinite number of SVG documents I now,
I can tell you, that a larger (infinite) subset of this infinite number
uses more than one stroke related presentation attribute.
A minor subset of maybe 60000 to 70000 uses stylesheets
with property notation as well.
> What’s needed is metrics.
This does not matter, because we cannot have access to all
SVG content, therefore the numbers will be always biased by
the observer and the different weights for tag soup document
versus good documents. If an author only serves daily tag
soup, we can be sure that backwards incompatibilities do not
matter much, if such an author is informed about the change
in time - we can forget about this content in practice, because
it does not survive for years anyway.
On the other hand, some content survives over years - I have
lots of documents generated already 2005 for example. If SVG
content is in payed mobile phone areas or in digital books
(EPUB for example can have SVG, you can add SVG as well as
attachment to PDFs), it will be typically hidden for your automatic
research anyway.
Such documents, that survive, have much more importance
concerning compatibility issues.
But whatever the weight is - we can assume, that proper/good
documents align with SVG 1.0/1.1 or tiny 1.2 - a change
in the future automatically means problems for those proper/good
documents, effectively kicking authors in the rear, that care about SVG.
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)
> I know the CSS WG occasionally does PhantomJS testing.
Fortunately this is not related to java-script at all ;o)
If we concentrate on what really is and not on phantoms and
esoteric aesthetics, we could have already some simple
progress in this discussion based on facts and not dubious
biased counting ;o)
> I hope
> we can all agree there’s a threshold below which some breakage is
> acceptable.
Why, if we already found a simple solution, that avoids this at all -
simply use another name than that of an already existing attribute/property.
This is not really difficult to understand and to do, just chose other
letters and the problem is completely avoided - only on letter has to differ
or has to be added (but take into account, that some people do not
like to have new names like 'Stroke' or 'STROKE' - because some have
problems with majuscules in such names ;o).
It is not difficult to chose other letters, even for a name with 3 to 6
letters there are still many never used combinations ;o)
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.
And what about my art gallery with infinite output - will you be ever
able to finish your statistics, if it provides yet another part of the
infinity on the next day? And even if you get an estimate for
'infinite areas' in the accessible internet - what does this mean
for other 'finite areas' in your research? Your average of 90% of infinite
with maybe 10% of a 10 billion subset of a finite area
(this still means 90% for all) is not necessarily a relevant average.
What if you find two infinite areas, one with an estimated value of
10% one of 90% - average undefined,
but absolute number of use cases: infinite.
What is the weight for all the 'finite areas' you did not find, is your
result significant for unknown areas?
Is it possible to give any assumption about those undiscovered areas?
Has it relevance for the weights, if one author needs 10 days to
update 1000 documents to this new behaviour, another one needs
10 minutes to update a billion documents, but 1000 authors cannot
update at all, because the do not have access to already published
works? (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').
As you can see: Finally counting is just occupational therapy
- all we really need is the current definition.
If something is compatible with this - why not.
If it is not compatible, simply look for an alternative that is compatible.
Fortunately this is quite simple here and we do not have to worry about
questionable statistics and numbers and those who counted with biase and
unpublished methods (what to count with which weight and what not at all).
>
> 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)
>
> 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.
As already mentioned, the problem mainly occurs, if the new property
is named 'stroke', because this has already a well defined meaning -
changes have influence on most SVG documents, not only those with
some kind of CSS notation.
To give only the property a new meaning and not the presentation
attribute, causes as well problems and confusion as described.
At least it requires a version indication for CSS files and that
all viewers implement version specific behaviour - questionable
if we can convince the CSS WG and implementors to do this,
even if it can be surely considered to be an important progress in general.
But it is trivial to avoid all these problems, confusions and conflicts here,
if one simply uses another name for the new feature.
This is the path of least resistance.
Olaf
Received on Saturday, 16 November 2013 15:43:27 UTC