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

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 Thursday, 24 January 2013 18:12:28 UTC