Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Intent to Implement: adding vector effects non-scaling-size, non-rotation and fixed-position to SVG

273 views
Skip to first unread message

ktecr...@gmail.com

unread,
Dec 27, 2016, 2:54:41โ€ฏAM12/27/16
to
Intent to Implement:
--------
adding vector effects non-scaling-size, non-rotation and fixed-position to SVG

Summary
--------
To offer vector effects regarding special coordinate transformations and graphic drawings as described in following Spec link,
SVG Tiny 1.2 introduced the vector-effect property. Although SVG Tiny 1.2 introduced only non-scaling stroke behavior, this version introduces a number of additional effects.

We intend now to implement non-scaling-size, non-rotation and fixed-position, as well as their combination to Gecko/SVG.

Motivation
--------
It is a point of interest in many SVG content providers to let the outline of an object keep its original size or to keep the position of an object fix, regardless of type of transforms that are applied to it. For example, in a map with a 2px wide line representing roads it is of
interest to keep the roads 2px wide even when the user zooms into the map, or introductory notes on the graphic chart in which panning is possible. Therefore, there is a high need for supporting these features in browsers.


Spec(Link to standard)
--------
https://svgwg.org/svg2-draft/coords.html#VectorEffects

Platform coverage
--------
Starting from Windows and Linux.

Bug
--------
https://bugzilla.mozilla.org/show_bug.cgi?id=1318208

Estimated or target release
--------
2017/1/30

Requesting approval to ship?
--------
No. Implementation is expected to take some time.

Tests
--------
Coming soon.

Boris Zbarsky

unread,
Dec 27, 2016, 3:19:39โ€ฏAM12/27/16
to
On 12/26/16 11:54 PM, ktecr...@gmail.com wrote:
> Spec(Link to standard)
> --------
> https://svgwg.org/svg2-draft/coords.html#VectorEffects

Is this a new SVG2 feature?

How stable is the spec? Are there any tests to test interop?

Do we have any indications that any other browser plans to implement
this? This is really most relevant for an intent to ship, but my
impression of the SVG2 new-feature work is that there is fairly limited
buy-in from implementors for most of it, and thus a high risk of no one
except us ever implementing this, at which point it wouldn't be obvious
that we want to ship this. So there's a fair risk of implementation of
such new-feature work from SVG2 being wasted time.

-Boris

L. David Baron

unread,
Dec 27, 2016, 12:27:50โ€ฏPM12/27/16
to dev-pl...@lists.mozilla.org
Does this change any invariants that we depend on in terms of how
SVG images with a viewBox respond to size changes by scaling?

Is it well defined how this interacts with all the ways in which SVG
is used, e.g., as content within an HTML document, as a standalone
file referenced via iframe or object, as a standalone file
referenced via image, when used as a background-image or
border-image, etc.?

-David

--
๐„ž L. David Baron http://dbaron.org/ ๐„‚
๐„ข Mozilla https://www.mozilla.org/ ๐„‚
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
signature.asc

ktecr...@gmail.com

unread,
Dec 28, 2016, 2:51:36โ€ฏAM12/28/16
to
> Is this a new SVG2 feature?
yes, to be more precise, it is an extension of existing "non-scaling-stroke", which is already released in Gecko.

> How stable is the spec? Are there any tests to test interop?
"non-scaling-size" and "non-rotation" spec are fix and "fix-position" spec is under review (pre-fix?). Our implementation will be adapted to latest updates. To verify interoperability, test contents are under development.

> Do we have any indications that any other browser plans to implement
> this? This is really most relevant for an intent to ship, but my
> impression of the SVG2 new-feature work is that there is fairly limited
> buy-in from implementors for most of it, and thus a high risk of no one
> except us ever implementing this, at which point it wouldn't be obvious
> that we want to ship this. So there's a fair risk of implementation of
> such new-feature work from SVG2 being wasted time.

It will be a good starting point to check out any possible issues. this is needed specially in technical drawing field. Some examples include W3C memebers like KDDI (for using in vector maps), Boeing (for use in technical designs), and it's been known request since 10 years:
https://lists.w3.org/Archives/Public/www-svg//2003Nov/0026.html

Regards
Ramin

ktecr...@gmail.com

unread,
Dec 28, 2016, 2:55:31โ€ฏAM12/28/16
to
> Does this change any invariants that we depend on in terms of how
> SVG images with a viewBox respond to size changes by scaling?

To be able to answer your question, please kindly write an example of what kind of invariant or what kind of use-case concerns you. Also please refer to following link for checking behavior of this implementation:
http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/VectorEffect_polyfill.html

thank you in advance.
Ramin

Ramin

unread,
Dec 28, 2016, 11:43:14โ€ฏAM12/28/16
to dev-pl...@lists.mozilla.org, KTEC ใƒฉใƒŸใƒณ, sa-...@kddi-tech.com, te-f...@kddi-tech.com
Intent to Implement: adding vector effects non-scaling-size,
non-rotation and fixed-position to SVG

Contact emails
--------
te-f...@kddi-tech.com, g-r...@kddi-tech.com, sa-...@kddi-tech.com

Summary
--------
To offer vector effects regarding special coordinate transformations and
graphic drawings as described in following Spec link,
SVG Tiny 1.2 introduced the vector-effect property. Although SVG Tiny
1.2 introduced only non-scaling stroke behavior, this version introduces
a number of additional effects.

We intend now to implement non-scaling-size, non-rotation and
fixed-position, as well as their combination to Gecko/SVG.

Motivation
--------
It is a point of interest in many SVG content providers to let the
outline of an object keep its original size or to keep the position of
an object fix, regardless of type of transforms that are applied to it.
For example, in a map with a 2px wide line representing roads it is of
interest to keep the roads 2px wide even when the user zooms into the
map, or introductory notes on the graphic chart in which panning is
possible. Therefore, there is a high need for supporting these features
in browsers.


Jeff Muizelaar

unread,
Dec 29, 2016, 11:25:44โ€ฏAM12/29/16
to Ramin, te-f...@kddi-tech.com, Mozilla, sa-...@kddi-tech.com
I'm concerned about the complexity this will add to the SVG implementation
as we're looking to transition to WebRender.

Can the desired effects be achieved by interleaving HTML and SVG content
today? e.g. It seems like introductory notes example could just use a
separate SVG element that had fixed positioning instead of needing to build
fixed-position into SVG.

Do other browsers intend to implement these features?

-Jeff
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

ktecr...@gmail.com

unread,
Jan 3, 2017, 7:48:01โ€ฏPM1/3/17
to
Hi Jeff
> I'm concerned about the complexity this will add to the SVG implementation
> as we're looking to transition to WebRender.
if WebRender supports currently implemented "non-scaling-stroke",
new modifications must be nothing more than recalculating CTM for those new effects.

> Can the desired effects be achieved by interleaving HTML and SVG content
> today?
my understanding is CTM translations do work well with interleaving HTML and SVG.

> e.g. It seems like introductory notes example could just use a
> separate SVG element that had fixed positioning instead of needing to build
> fixed-position into SVG.

By "introductory notes example" do you mean the example in following link?
https://svgwg.org/svg2-draft/coords.html#VectorEffects

Daniel Holbert

unread,
Jan 26, 2017, 7:44:30โ€ฏPM1/26/17
to ktecr...@gmail.com, dev-pl...@lists.mozilla.org
On 1/3/17 4:48 PM, ktecr...@gmail.com wrote:
>> e.g. It seems like introductory notes example could just use a
>> separate SVG element that had fixed positioning instead of needing to build
>> fixed-position into SVG.
>
> By "introductory notes example" do you mean the example in following link?
> https://svgwg.org/svg2-draft/coords.html#VectorEffects

I think that's what Jeff meant, yes.

(Basically, can authors already solve the problems that
"vector-effect:fixed-position" is intended to solve, by simply creating
two different <svg> elements (in an HTML context), and styling one with
"position: fixed">? Here's a simple demo with a floating fixed-position
legend, using that sort of solution:
https://jsfiddle.net/vv9gwemr/
)

Also, Jeff asked another important question -- have other browsers
expressed any intent to implement these features?

Also note that this feature is marked as "at-risk" of being dropped from
this version of the SVG2 spec:
"ISSUE 31: Values of vector-effect other than non-scaling-stroke and
none are at risk of being dropped from SVG 2 due to a lack of
implementations."
https://svgwg.org/svg2-draft/coords.html#issue31

Looks like that warning was added here:
https://github.com/w3c/svgwg/issues/186

If no other browsers are intending to implement it, then there's a
serious question of whether it's worth taking on this added code & the
increased complexity/attack-surface/bug-surface/maintenance-burden that
new features inevitably bring along, if web developers aren't going to
be able to use the feature on the web due to lack of support in other
browsers.

~Daniel

ktecr...@gmail.com

unread,
Jan 27, 2017, 12:47:55โ€ฏAM1/27/17
to
2017ๅนด1ๆœˆ27ๆ—ฅ้‡‘ๆ›œๆ—ฅ 9ๆ™‚44ๅˆ†30็ง’ UTC+9 Daniel Holbert:
> On 1/3/17 4:48 PM, ktecr...@gmail.com wrote:
> >> e.g. It seems like introductory notes example could just use a
> >> separate SVG element that had fixed positioning instead of needing to build
> >> fixed-position into SVG.
> >
> > By "introductory notes example" do you mean the example in following link?
> > https://svgwg.org/svg2-draft/coords.html#VectorEffects
>
> I think that's what Jeff meant, yes.
>
> (Basically, can authors already solve the problems that
> "vector-effect:fixed-position" is intended to solve, by simply creating
> two different <svg> elements (in an HTML context), and styling one with
> "position: fixed">? Here's a simple demo with a floating fixed-position
> legend, using that sort of solution:
> https://jsfiddle.net/vv9gwemr/
> )
That's what this implementation intends to do i.e. to have overall control
on all types of vector effects and their combinations on each individual element,
rather than having a single effect on whole svg content, as the example you mentioned.

> Also, Jeff asked another important question -- have other browsers
> expressed any intent to implement these features?
I will look to get some info of what other browsers support and if they are going
to do it or not. will update this ASAP. By the time my info is limited to:
SVG 2 user agent support
https://nikosandronikos.github.io/svg2-info/svg2-feature-support/
SVG 2 feature support
https://docs.google.com/spreadsheets/d/1kkqzcxY53h7liRYppLSSFG2sjaJ8V8TCP5rWLZK0AxA/edit

>
> Also note that this feature is marked as "at-risk" of being dropped from
> this version of the SVG2 spec:
> "ISSUE 31: Values of vector-effect other than non-scaling-stroke and
> none are at risk of being dropped from SVG 2 due to a lack of
> implementations."
> https://svgwg.org/svg2-draft/coords.html#issue31
>
> Looks like that warning was added here:
> https://github.com/w3c/svgwg/issues/186
I am agree with you on this. Implementations make sense only if spec is fix
and no risk of being dropped. Regarding this I'm in touch with SVG2 and will update ASAP.

Thanks
Ramin

long...@gmail.com

unread,
Jan 31, 2017, 3:11:21โ€ฏAM1/31/17
to
Has there been any feedback from Google, Apple or Microsoft?

We've landed stuff preffed off before and had to remove it in the end as it's just so much dead weight without any chance of being preffed on. Unless there's an intent to implement this soon from other vendors we really shouldn't put in any more effort here and we certainly shouldn't land any patches.

Robert

Jet Villegas

unread,
Jan 31, 2017, 8:35:17โ€ฏAM1/31/17
to Longson, Robert, group, mozilla.dev.platform
We had a good conversation with Ramin last week in Tokyo. The topic of
interoperability was discussed at length, and we also talked about where
Mozilla's 2017 priorities align with KDDI's.

To summarize, Mozilla is prioritizing the Web-compatibility and Performance
of the interoperable subset of the SVG feature set. That is, we will work
on features that:

A. other browsers support, and
B. authors actually use, or
C. the Firefox browser user interface requires.

Thanks,

--Jet
0 new messages