Re: Porting fill/stroke (and -opacity variants) to plain CSS

Hi,

I would like to summarize the thread and continue the discussion about ‘fill’ and ’stroke’ on text.

The suggestion is to allow ‘fill’ and ‘stroke’ not only on all graphical SVG elements, but also text in general (HTML and other markup languages).

1) State of the art

Text in HTML and all non-SVG markup languages
* uses the ‘color’ property to style text. The initial value depends on the UA.

SVG graphics elements (including text)
* use the ‘fill’ property to paint
* use the ’stroke’ property for styling the outline of graphics
* ‘fill’ has an initial value of ‘black’
* ’stroke’ has an initial value of ’none’
* beside ‘stroke’ there are other properties like ’stroke-width’ and ’stroke-dasharray’. ’stroke’ is not a shorthand yet.

2) The idea
* ‘color’ needs to continue to be the primary way of styling text (everywhere but SVG) 
* ‘fill’ will override ‘color’ when set.
* ‘fill’ gets a new value ‘auto’ which is
    * ‘black’ by default for all SVG elements (including text).
    * ’none’ by default for text with the exception of SVG text (problem see next point; therefore it can’t be ‘currentColor')
* ‘color’ must not style SVG elements including SVG text (fill: none would still color SVG graphics/text if we don’t do it - incompatible to SVG 1.1)
* ’stroke’ must get a shorthand for dash array and stroke-width (?)

3) Next steps
* ‘fill’ and ’stroke’ continue to be maintained by the SVG WG and ‘auto’ is added as value and initial value for ‘fill'. CSS Text decoration adds ‘fill’ and ’stroke’ as styling options for text but must exclude ‘color’ as direct style option for SVG Text and defines what ‘auto’ means for text (probably ’none’).

4) Further discussions (PLEASE NEW THREAD)
* What is the “boundary” of floating text for SVG paint servers? Suggestion: Still the boundary of the block level element. Line styling could be done by setting width/height or x2/y2 on gradients or patterns.

Please send your comments on the proposal.

Greetings,
Dirk

On Jan 25, 2013, at 2:11 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Jan 24, 2013 at 4:59 AM, Chris Lilley <chris@w3.org> wrote:
>> Wednesday, January 23, 2013, 8:15:41 PM, you wrote:
>>> Heya SVGWG, in today's CSSWG call fantasai suggested, to solve another
>>> issue, porting SVG's fill and stroke properties to plain CSS, with
>>> them applying only to text.
>> 
>> Sounds  reasonable to have them apply to text. They should not need to
>> be 'ported'.
> 
> By that I meant that their definitions have to be made compatible with
> the inline layout model, which may be slightly different in detail to
> what SVG does with text.
> 
>>> We'll look to existing SVG application of fill/stroke to <text>, and
>>> WebKit's use of their proprietary text-stroke and text-fill
>>> properties, to inform how they work.  We'll probably define them in
>>> the Text Decoration module.
>> 
>>> Any issues you anticipate with that?
>> 
>> So   this   would   not   be  the  same  properties,  but  differently
>> named/differently   acting  lookalikes?  Which  would  mean  that  SVG
>> implementations  would  then need to deal with both sets of properties
>> and their combinations, on SVG text?
> 
> No, I said nothing of the sort, and the rest of the thread makes that
> even clearer.  I mean precisely what I actually said, which is
> allowing SVG's 'fill' and 'stroke' properties to apply to text in
> CSS's inline layout model.  I'm definitely not proposing any
> backwards-incompatible changes; at most, we might request some
> extensions to the properties (or new properties in the namespace) to
> handle cases that come up. For example, when filling/stroking a
> paragraph with an image, is the image laid out across all the text in
> a big line, and then broken, like backgrounds are? Or is laid out into
> the bounding space of the post-layout lineboxes? Should this be
> controllable?
> 
> ~TJ
>

Received on Tuesday, 12 November 2013 16:42:06 UTC