Re: [strokes] CSS fill/stroke spec + questions

On Fri, Jan 29, 2016 at 6:07 AM, Tavmjong Bah <tav.w3c@gmail.com> wrote:
> On Mon, 2016-01-25 at 15:32 -0800, Tab Atkins Jr. wrote:
>> Per an FXTF meeting some time ago
>> <https://lists.w3.org/Archives/Public/www-style/2013Jun/0678.html>,
>> fantasai and I have been drafting fill/stroke as applied to text in
>> CSS, and with the extensions needed to handle multiline text,
>> hierarchical elements, and multi-layer (background-like) paints.
>
>
> I've added CSS Strokes as a topic for the joint CSS/SVG meeting. Here
> are some quick comments:
>
>
> stroke-align:
>
>   This property, although highly desired and simple in principle, turns
> out to be quite difficult to define and implement. It has been moved
> out of the SVG 2 specification into a "strokes" module (along with
> 'stroke-dashcorner' and 'stroke-dashadjust'). For some of the problems,
> see:
>
>   https://svgwg.org/specs/strokes/#SpecifyingStrokeAlignment
>   http://tavmjong.free.fr/blog/?p=1257

Thanks for that!

>   It would also be nice to be able to give a numerical value to
> partially offset a stroke.

Yeah, we saw that in one of the proposals.  We weren't sure what the
value range should be - 100% to -100%, default 0?  Or 0% to 100%,
default 50%?

>   You might consider adding the 'paint-order' property as this solves
> the common problem of distorted looking glyphs when stroke is above
> fill.

And the fill is opaque (which is common, of course).  I'm fine with this.

> stroke-linejoin:
>
>   There are two additional values added in SVG 2:
>
>     'miter-clip' (with a much nicer fallback behavior than 'miter').
>     'arcs' (much more appealing join for curved paths).

We're aware of that, but only integrated it into the Perfect-World
Syntax section. Check it out, we think it's a bit better.

stroke-corner-shape: bevel | round | [ arc | miter ] [ bevel | round ]?

That is, arc and miter can have a "limit shape" specified.  If
omitted, it's the "clip" that it currently does.  Otherwise, it's
bevel or round.

So, "bevel", "round", or "miter" would have the current behavior
SVG1.1 behavior.  "miter bevel" would give the better behavior of
"miter-clip".  We can make "arc" either default to the better
behavior, or be consistent and default to the uglier clipping
behavior, and require "arc bevel" for the attractive one.

We added "round" as a limit shape because it just seems to make sense?
 Same behavior as bevel.

> stroke-miterlimit:
>
>   With the 'miter-clip' and 'arcs' line joins, a '<number>' value makes
> more sense than an '<angle>' value. Computed value should be a number.

Yeah, this was our conclusion too after some discussion.  The problem
is that the SVG spec goes straight into "hey here's a trig formula",
rather than opening with an informative example of what the value
means and tucking the formula into an out-of-the-way note at the end.
I literally didn't understand what the number actually meant until we
wrote our spec and dug into it. ^_^

>
> stroke-dasharray:
>
>   Yes, percentages are stupid when referenced to the diagonal of the
> containing block. Values in SVG can be lengths, percentages, or
> numbers. Numbers are in user-units.

I'm annoyed at SVG's legacy insistence on only having two "units"
(numbers and %s), and having globalish flags to determine how to
interpret those units in a given instance. >_<

In CSS we can just have lots of units.  Is there a way out here?  If
we absolutely can't, shrug, that's life.

> Relative to stroke-width may seem
> at first be an obvious choice but if stacking stroked path above each
> other (with different widths to build complicated paths) then having it
> in user-units makes sense.

I mean, you just wouldn't use %s there.  What's the issue?

>   Interesting, the SVG spec does say "The ‘pathLength’ attribute on a
> ‘path’ element affects ‘stroke-dasharray’: each dash and gap length is
> interpreted relative to the author's path length as specified by
> ‘pathLength’." What this actually means, I don't know... but it would
> be quite handy to have percentages defined relative to path length (but
> probably not very useful for stroking text).
>
> stroke-dashoffset:
>
>   Same comments as for 'stroke-dasharray'.

...oh jeez, I see the issue.  The spec is wrong/contradictory!  For
both dasharray and dashoffset, it claims that % is relative to the
scaled diagonal, but it's *actually* relative to the pathLength, which
is obviously completely different!  That's why the "self-drawing SVG"
thing works - you create a 100% dash and a 100% gap, then animate
dashoffset from -100% to 0%.

Having the % be relative to the path length is more reasonable.  I'll
fix our spec.  I'll let you fix SVG. ^_^

~TJ

Received on Wednesday, 10 February 2016 00:38:10 UTC