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

To go back to Tab's original question: where should this content be spec'd?

For SVG, these aren't "text-decoration" properties.  These are some of the
most fundamental style properties for all of SVG. Furthermore, as suggested
by Brad Kemper, there may be future interest in extending these approaches
(stroke-like dashing control) to borders in the CSS box model.

The SVG WG has already published (a draft of) a dedicated module on Stroke
geometry, including dashing, linejoins and stroke alignment.  Although not
all of the stroke geometry options would apply to text, I think it makes
sense to continue with that spec, possibly moving it to the FX task force
umbrella.

This Stroke Geometry module (or an advanced level version of it) might then
integrate new border-dashing options that would use the same underlying
rendering calculations.  It would also be a good place to implement a new
syntax for stroke dashes as a percent of the path length or path segment
length, which everyone agrees is a "nice to have" but is not a simple
addition in a backwards-compatible manner.

A matching Paint module (under FX) could become the universal definition
for the `fill` and `stroke` shorthand properties and their constituent
longhand properties, as well as some closely related properties such as
`paint-order`.

As I mentioned at the F2F, I very much prefer the shorthand/longhand
breakdown of multilayer paint presented in this spec, compared to the
longhand-only syntax currently in the SVG 2 spec for fill and stroke.  It
would be wonderful if this can be properly spec'd in time for SVG 2
publication.

I assume, from an implementation perspective, it would be ideal if the spec
for CSS painted text is ready to implement at the same time as SVG wrapping
text, and multilayer paint for both.  That way the rendering code can be
harmonized once and used everywhere.

But that's a *very* short time scale (2-3 months), so probably not
feasible. However, we should at least have a clear strategy for how the
different specs will interact and depend on each other.

A few final thoughts:

1) Both syntaxes (SVG 2 and the long-hands in the new draft spec) are
missing a way to define the reference box for SVG paint servers. This is
something that needs to be clarified in coordination with other FX specs
(mask/clip-path and filter) to provide clear but flexible interpretation of
how to adapt the SVG objectBoundingBox / userSpaceOnUse units in a manner
consistent across all properties and content types.

2) Simply activating the `fill` and `stroke` properties on non-SVG text may
have unintended complications.  Because these properties inherit to child
SVG content there may be a zombie code issue, breaking existing content
that sets these values on HTML elements that contain SVG icons.  The
@supports rule and most simple feature detection methods are useless when
certain properties are recognized as valid but may or may not have an
effect on a given element.

Furthermore, Many implementations use advanced rendering methods (such as
sub-pixel aliasing) for solid color text that isn't available for complex
painted text.  It would probably be useful for performance if there was a
single property that switched on or off the new feature. Something like

text-paint-mode: color | paint ;

(or just `paint-mode`, to match `paint-order`, and it could apply to SVG
shapes as well, with an effect similar to `fill: currentColor` when
switched)

where `color` is normal CSS-styled text, use color property, and `paint` is
SVG text, use fill and stroke properties. This would also circumvent the
issue with a default fill-color: currentColor not working for SVG backwards
compatibility. The default fill-color would be black (to match SVG), but
the default (text-)paint-mode for non-SVG text would be `color`.  With this
mode, the rendering implementation could safely ignore changes to the
fill-* and stroke-* properties.  And of course, authors could test support
for the paint-mode property in an @supports block.


~ABR

On 25 January 2016 at 16:32, Tab Atkins Jr. <jackalmage@gmail.com> 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.
>
> 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
>
>