Discussion:
[paint] Publishing FPWD of Fill and Stroke Module
(too old to reply)
fantasai
2017-03-15 23:31:55 UTC
Permalink
Raw Message
Tab and I just wrapped up the last remaining edits from the Sydney F2F last year
https://lists.w3.org/Archives/Public/www-style/2016Mar/0358.html
where we were asked to merge the spec with heycam's Strokes module. (Most of the
edits went in last August, but we dropped the ball on wrapping them up and asking
for publication, sorry.)

The draft is here:
https://drafts.fxtf.org/paint/
We think it is ready for FPWD.

Note that there are a lot of issues:
https://drafts.fxtf.org/paint/#issues-index
This is okay. The point of FPWD is to say "we've got a a good rough draft of the
module and are ready to ask for broader input", not "this is ready for implementation".
(But we should probably discuss them all at some point, too.)

If this is a topic that interests you, please have a look at the draft and let us know if
* there is anything we forgot to add to the spec
* there is a particular issue you absolutely want to resolve before FPWD
* there are other issues that aren't noted in the spec or in github
* you're OK with FPWD

(We would also love it if anyone wants to send us a list of "Here are my preferred
answers to all the open questions in the spec" as there are rather a lot.)

Also, I'm proposing to mark this as Level 3 (post-SVG2) and Tab wants to mark it
as Level 1 (first level after modularization), so we'll have to get a resolution
on that, too. >:]

~fantasai and TJ
Amelia Bellamy-Royds
2017-03-16 17:12:57 UTC
Permalink
Raw Message
Thanks to you both,

I'll try to do a careful review & response to spec issues at some point,
but there is one issue that should at least be added to the spec before
FPWD:

The initial value of fill-color isn't backwards compatible. It needs to be
"black" to be compatible with the initial value of SVG fill. But then that
isn't backwards-compatible with regular CSS text rendering (which uses
color).

Options:

- give fill-color an `auto` value which equates to `black` for SVG
elements and to `currentColor` elsewhere.

- add a separate text-rendering-mode property that determines whether to
use basic text rendering (currentColor fill, stroke ignored) vs fill+stroke
paint (and use the user stylesheet to switch mode for <svg> then switch it
back for <foreignObject>).


In the discussion on the proposed "font-presentation" property (
https://github.com/w3c/csswg-drafts/issues/352#issuecomment-285129212) I
suggested that this switch could be integrated into a property that also
switched on or off multi-color fonts.

(The current draft of "font-presentation" that Myles compiled is much
narrower, however, and only applies to characters that take unicode emoji
variant selectors:
https://drafts.csswg.org/css-fonts-4/#font-presentation-desc)
Post by fantasai
Tab and I just wrapped up the last remaining edits from the Sydney F2F last year
https://lists.w3.org/Archives/Public/www-style/2016Mar/0358.html
where we were asked to merge the spec with heycam's Strokes module. (Most of the
edits went in last August, but we dropped the ball on wrapping them up and asking
for publication, sorry.)
https://drafts.fxtf.org/paint/
We think it is ready for FPWD.
https://drafts.fxtf.org/paint/#issues-index
This is okay. The point of FPWD is to say "we've got a a good rough draft of the
module and are ready to ask for broader input", not "this is ready for implementation".
(But we should probably discuss them all at some point, too.)
If this is a topic that interests you, please have a look at the draft and let us know if
* there is anything we forgot to add to the spec
* there is a particular issue you absolutely want to resolve before FPWD
* there are other issues that aren't noted in the spec or in github
* you're OK with FPWD
(We would also love it if anyone wants to send us a list of "Here are my preferred
answers to all the open questions in the spec" as there are rather a lot.)
Also, I'm proposing to mark this as Level 3 (post-SVG2) and Tab wants to mark it
as Level 1 (first level after modularization), so we'll have to get a resolution
on that, too. >:]
~fantasai and TJ
Tab Atkins Jr.
2017-03-16 17:47:01 UTC
Permalink
Raw Message
On Thu, Mar 16, 2017 at 10:12 AM, Amelia Bellamy-Royds
Post by Amelia Bellamy-Royds
The initial value of fill-color isn't backwards compatible. It needs to be
"black" to be compatible with the initial value of SVG fill. But then that
isn't backwards-compatible with regular CSS text rendering (which uses
color).
give fill-color an `auto` value which equates to `black` for SVG elements
and to `currentColor` elsewhere.
add a separate text-rendering-mode property that determines whether to use
basic text rendering (currentColor fill, stroke ignored) vs fill+stroke
paint (and use the user stylesheet to switch mode for <svg> then switch it
back for <foreignObject>).
We went for a third option (which we were planning to do, but forgot
to put in the spec): set fill-color to black for root svg elements in
the UA stylesheet.

~TJ and fantasai
Amelia Bellamy-Royds
2017-03-16 18:09:30 UTC
Permalink
Raw Message
I'm not sure that would be web-compatible. It breaks any case where `fill`
is set with the expectation that it would inherit into inline SVG. Unless
you really meant only "svg:root" elements, in which case all my original
concerns still apply to inline SVG.

Either way, I'd still recommend adding an issue to the spec, to look into
the compat issues.

And of course, for any version that requires new user-agent stylesheet
rules, we'll need a section of the spec for that. (I assume this is the
part you were "planning to do"!)

~ABR
Post by Tab Atkins Jr.
On Thu, Mar 16, 2017 at 10:12 AM, Amelia Bellamy-Royds
Post by Amelia Bellamy-Royds
The initial value of fill-color isn't backwards compatible. It needs to
be
Post by Amelia Bellamy-Royds
"black" to be compatible with the initial value of SVG fill. But then
that
Post by Amelia Bellamy-Royds
isn't backwards-compatible with regular CSS text rendering (which uses
color).
give fill-color an `auto` value which equates to `black` for SVG elements
and to `currentColor` elsewhere.
add a separate text-rendering-mode property that determines whether to
use
Post by Amelia Bellamy-Royds
basic text rendering (currentColor fill, stroke ignored) vs fill+stroke
paint (and use the user stylesheet to switch mode for <svg> then switch
it
Post by Amelia Bellamy-Royds
back for <foreignObject>).
We went for a third option (which we were planning to do, but forgot
to put in the spec): set fill-color to black for root svg elements in
the UA stylesheet.
~TJ and fantasai
Tab Atkins Jr.
2017-03-16 21:38:02 UTC
Permalink
Raw Message
On Thu, Mar 16, 2017 at 11:09 AM, Amelia Bellamy-Royds
Post by Amelia Bellamy-Royds
I'm not sure that would be web-compatible. It breaks any case where `fill`
is set with the expectation that it would inherit into inline SVG.
Yes, if it was set somewhere in HTML with the expectation that it
inherits into inline SVG. Hopefully rare-to-nonexistent; if not, we
can pursue a more complicated solution.
Post by Amelia Bellamy-Royds
Unless
you really meant only "svg:root" elements, in which case all my original
concerns still apply to inline SVG.
Either way, I'd still recommend adding an issue to the spec, to look into
the compat issues.
And of course, for any version that requires new user-agent stylesheet
rules, we'll need a section of the spec for that. (I assume this is the
part you were "planning to do"!)
Yeah, we've done it now - you can check the spec. ^_^

~TJ
Paul LeBeau
2017-03-17 13:47:35 UTC
Permalink
Raw Message
I had a comment on stroke-dash-justify. There are options to stretch or
compress the dash pattern to fit. Wouldn't it also be desirable to have an
option that stretched or compresses depending on which was closest? For
example, equivalent to the "round" option of border-image-repeat?

Also would it make sense to match the border-image-repeat names where
appropriate? For example, the keyword "space" is basically equivalent to
"gaps".

Paul
Post by Tab Atkins Jr.
On Thu, Mar 16, 2017 at 11:09 AM, Amelia Bellamy-Royds
Post by Amelia Bellamy-Royds
I'm not sure that would be web-compatible. It breaks any case where
`fill`
Post by Amelia Bellamy-Royds
is set with the expectation that it would inherit into inline SVG.
Yes, if it was set somewhere in HTML with the expectation that it
inherits into inline SVG. Hopefully rare-to-nonexistent; if not, we
can pursue a more complicated solution.
Post by Amelia Bellamy-Royds
Unless
you really meant only "svg:root" elements, in which case all my original
concerns still apply to inline SVG.
Either way, I'd still recommend adding an issue to the spec, to look into
the compat issues.
And of course, for any version that requires new user-agent stylesheet
rules, we'll need a section of the spec for that. (I assume this is the
part you were "planning to do"!)
Yeah, we've done it now - you can check the spec. ^_^
~TJ
fantasai
2017-03-22 23:12:18 UTC
Permalink
Raw Message
I had a comment on stroke-dash-justify. There are options to stretch or compress the dash pattern to fit. Wouldn't it also be
desirable to have an option that stretched or compresses depending on which was closest? For example, equivalent to the
"round" option of border-image-repeat?
Leaving out the stretch/compress keywords would have that effect.
Also would it make sense to match the border-image-repeat names where appropriate? For example, the keyword "space" is
basically equivalent to "gaps".
Not a bad idea, but there isn't an equivalent to the other values, really.
What keywords would you use for 'dashes' or 'gaps dashes'?

~fantasai
Dirk Schulze
2017-06-02 14:46:53 UTC
Permalink
Raw Message
Hi fantasai,

I wonder if the SVG specific paint properties should go in into the first draft. I am not sure if there is interest from browser vendors to still implement them.

Also, I wonder how https://svgwg.org/specs/strokes/ is aligning with the the Fill and Stroke Module. Should it get the 2nd level? Should it get integrated into the editors draft of Fill and Stroke?

Adobe Illustrator is able to mix fill and strokes. This would not be possible with this draft and I wonder how this could be supported in the future if we allow layered fills and stroke as specified.

Greetings,
Dirk

On 16. Mar 2017, at 00:31, fantasai <***@inkedblade.net<mailto:***@inkedblade.net>> wrote:

Tab and I just wrapped up the last remaining edits from the Sydney F2F last year
https://lists.w3.org/Archives/Public/www-style/2016Mar/0358.html
where we were asked to merge the spec with heycam's Strokes module. (Most of the
edits went in last August, but we dropped the ball on wrapping them up and asking
for publication, sorry.)

The draft is here:
https://drafts.fxtf.org/paint/
We think it is ready for FPWD.

Note that there are a lot of issues:
https://drafts.fxtf.org/paint/#issues-index
This is okay. The point of FPWD is to say "we've got a a good rough draft of the
module and are ready to ask for broader input", not "this is ready for implementation".
(But we should probably discuss them all at some point, too.)

If this is a topic that interests you, please have a look at the draft and let us know if
* there is anything we forgot to add to the spec
* there is a particular issue you absolutely want to resolve before FPWD
* there are other issues that aren't noted in the spec or in github
* you're OK with FPWD

(We would also love it if anyone wants to send us a list of "Here are my preferred
answers to all the open questions in the spec" as there are rather a lot.)

Also, I'm proposing to mark this as Level 3 (post-SVG2) and Tab wants to mark it
as Level 1 (first level after modularization), so we'll have to get a resolution
on that, too. >:]

~fantasai and TJ
Amelia Bellamy-Royds
2017-06-02 16:02:48 UTC
Permalink
Raw Message
I think the Fill and Stroke module has incorporated all the text from the
SVG Strokes module (with additional changes), so SVG Strokes as a separate
spec is effectively discontinued. It should probably be replaced by a note
pointing to the new spec.

As the spec gets more advanced, we can probably discuss deferring some
features to a Level 4, based on implementer interest. I don't see a
purpose in doing that pre-emptively. If we remove the features now, we're
definitely not going to get implementer interest.
Post by Dirk Schulze
Adobe Illustrator is able to mix fill and strokes. This would not be
possible with this draft and I wonder how this could be supported in the
future if we allow layered fills and stroke as specified.
Can you explain what you mean? If you mean "mix" as in "mix-blend-mode",
I've got an issue for that here & I think it's just waiting on someone
drafting up the text & filing a pull request:
https://github.com/w3c/fxtf-drafts/issues/134

If you mean "mix" as in mix up the paint-order (fill 1, stroke 1, fill 2,
stroke 2), that's something I've discussed previously in SVG WG but without
getting a final proposal. It would need to be implemented as an extension
of `paint-order`, since browsers already support `paint-order`. You could
start the debate by filing an issue that describes what is possible in
Illustrator.
Dirk Schulze
2017-06-02 16:16:48 UTC
Permalink
Raw Message
On 2. Jun 2017, at 18:02, Amelia Bellamy-Royds <***@gmail.com<mailto:***@gmail.com>> wrote:

I think the Fill and Stroke module has incorporated all the text from the SVG Strokes module (with additional changes), so SVG Strokes as a separate spec is effectively discontinued. It should probably be replaced by a note pointing to the new spec.


Some property names changed. Missed that!

As the spec gets more advanced, we can probably discuss deferring some features to a Level 4, based on implementer interest. I don't see a purpose in doing that pre-emptively. If we remove the features now, we're definitely not going to get implementer interest.


You are right. Not a requirement to move/remove it now but questionable if there shouldn’t be interest in it still.

Greetings,
Dirk


On 2 June 2017 at 08:46, Dirk Schulze <***@adobe.com<mailto:***@adobe.com>> wrote:
Adobe Illustrator is able to mix fill and strokes. This would not be possible with this draft and I wonder how this could be supported in the future if we allow layered fills and stroke as specified.

Can you explain what you mean? If you mean "mix" as in "mix-blend-mode", I've got an issue for that here & I think it's just waiting on someone drafting up the text & filing a pull request:
https://github.com/w3c/fxtf-drafts/issues/134<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Ffxtf-drafts%2Fissues%2F134&data=02%7C01%7C%7C2ebd9953f29345ed1de308d4a9d0d16b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636320161726283318&sdata=%2BM8ovLYjLNEF7FcZXMsTz%2FkBJ5i%2FooCbpWwKQtYmrOE%3D&reserved=0>

If you mean "mix" as in mix up the paint-order (fill 1, stroke 1, fill 2, stroke 2), that's something I've discussed previously in SVG WG but without getting a final proposal. It would need to be implemented as an extension of `paint-order`, since browsers already support `paint-order`. You could start the debate by filing an issue that describes what is possible in Illustrator.
Loading...