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

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

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

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


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


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.


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

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


Tav



> Currently this lives in the Text Decoration 4 ED
> <https://drafts.csswg.org/css-text-decor-4/>.  Is this appropriate,
> or
> should it live somewhere else less directly text-centric?
> 
> We're also unsure exactly how much of fill/stroke to define in this
> spec.  Should we take over the entire model, copying text from SVG,
> or
> should we only define the syntax, and the rendering parts that are
> relevant to CSS, letting SVG define the rendering parts important to
> it?
> 
> ~TJ
>

Received on Friday, 29 January 2016 14:07:43 UTC