Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Gijs Kruitbosch]

On 12/04/2018 00:00, da...@openweb.io wrote:

On Tuesday, 10 April 2018 00:57:43 UTC-7, Gijs Kruitbosch  wrote:

On 10/04/2018 03:07, Cameron McCormack wrote:

On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote:

Do we have a heuristic for when to /not/ include something from HTML in SVG?


If it doesn't make two features which already exist in both HTML and SVG more 
consistent, then I wouldn't include it.


More or less, these additions to SVG just strike me as having solid
potential risk (for both spec-interaction and implementation bugs) and
negligible upside. Do we have people asking for this?


I don't know of people asking for this, but I would hope that we could share the 
implementations of these properties between HTMLAnchorElement and SVGAElement.  The 
closer the two  elements are in behavior, and the more we can share 
implementation between them, the lower the risk for bugs between the two.  (Ignoring 
the general risk of bugs from touching code at all..)


I don't know about the C++ side of things here in terms of shared
implementation, but *behavior* is already different as per spec. And we
(frontend folks who have to make sure things like context menus deal
with arbitrary web content) regularly forget that, and then end up being
bitten by it. Most annoyingly, for SVG  the `.href` property is an
SVGAnimatedString object with `baseVal` and `animVal` properties, not a
string like it is in HTML.

I assume that the same thing applies to the properties this is adding,
which means this is on the one hand more consistency with HTML (same
properties) and on the other hand, less (different values anyway).

~ Gijs


Hi, I work on MS Edge and I'm helping drive these changes.

The idea here is quite the opposite. We're trying to make the same concepts in 
SVG share the same specified behavior as HTML. For example in SVG today these 
say to return an SVGAnimatedString. With this change they return a DOMString 
(except relist which returns a DOMTokenList object) and thus match the HTML 
definition. The defined behavior will be in HTML as Anne mentions.. We've 
already made a similar change for SVGElement, where focus() et al were defined 
in the SVG spec with a note that they behave the same as HTML. Now they're 
defined in a HTMLOrSVGElement mixin in HTML and the definition is removed from 
the SVG spec. This one was an easy change as the behavior was already aligned.


Your point about href is a good one. That is one we can't redefine as DOMString 
due to already being implemented and having usage on the web. We're trying to 
avoid future cases like this by aligning behavior/specs. There may be some ways 
we can align href while keeping legacy behavior so things don't break, but 
don't have a concrete proposal for this yet.


Hi,

Thanks for the clarification! I'm glad that HTML/SVG alignment is being 
worked on.


Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[david]

On Tuesday, 10 April 2018 00:57:43 UTC-7, Gijs Kruitbosch  wrote:
> On 10/04/2018 03:07, Cameron McCormack wrote:
> > On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote:
> >> Do we have a heuristic for when to /not/ include something from HTML in 
> >> SVG?
> > 
> > If it doesn't make two features which already exist in both HTML and SVG 
> > more consistent, then I wouldn't include it.
> > 
> >> More or less, these additions to SVG just strike me as having solid
> >> potential risk (for both spec-interaction and implementation bugs) and
> >> negligible upside. Do we have people asking for this?
> > 
> > I don't know of people asking for this, but I would hope that we could 
> > share the implementations of these properties between HTMLAnchorElement and 
> > SVGAElement.  The closer the two  elements are in behavior, and the more 
> > we can share implementation between them, the lower the risk for bugs 
> > between the two.  (Ignoring the general risk of bugs from touching code at 
> > all.)
> 
> I don't know about the C++ side of things here in terms of shared 
> implementation, but *behavior* is already different as per spec. And we 
> (frontend folks who have to make sure things like context menus deal 
> with arbitrary web content) regularly forget that, and then end up being 
> bitten by it. Most annoyingly, for SVG  the `.href` property is an 
> SVGAnimatedString object with `baseVal` and `animVal` properties, not a 
> string like it is in HTML.
> 
> I assume that the same thing applies to the properties this is adding, 
> which means this is on the one hand more consistency with HTML (same 
> properties) and on the other hand, less (different values anyway).
> 
> ~ Gijs

Hi, I work on MS Edge and I'm helping drive these changes. 

The idea here is quite the opposite. We're trying to make the same concepts in 
SVG share the same specified behavior as HTML. For example in SVG today these 
say to return an SVGAnimatedString. With this change they return a DOMString 
(except relist which returns a DOMTokenList object) and thus match the HTML 
definition. The defined behavior will be in HTML as Anne mentions. We've 
already made a similar change for SVGElement, where focus() et al were defined 
in the SVG spec with a note that they behave the same as HTML. Now they're 
defined in a HTMLOrSVGElement mixin in HTML and the definition is removed from 
the SVG spec. This one was an easy change as the behavior was already aligned.


Your point about href is a good one. That is one we can't redefine as DOMString 
due to already being implemented and having usage on the web. We're trying to 
avoid future cases like this by aligning behavior/specs. There may be some ways 
we can align href while keeping legacy behavior so things don't break, but 
don't have a concrete proposal for this yet.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Boris Zbarsky]

On 4/10/18 4:03 AM, Gijs Kruitbosch wrote:
I looked at the patch briefly, and I'm a bit confused about the state of 



The DOM bit is exposed, but we don't actually send pings.

Yes, this sucks in terms of detecting whether ping is supported...

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Jet Villegas]

I like that our link handling is getting shared but would really love a fix
for this bug in SVG  rendering:
https://bugzilla.mozilla.org/show_bug.cgi?id=1366494

Robert: do you have time to fix that one while you're in there?

Thanks!

--Jet


On Tue, Apr 10, 2018 at 1:09 AM, Gijs Kruitbosch 
wrote:

> On 10/04/2018 09:03, Gijs Kruitbosch wrote:
>
>> On 09/04/2018 22:11, longs...@gmail.com wrote:
>>
>>> Summary: HTML anchor elements have ping, rel, referrerPolicy, relList,
>>> hreflang, type and text properties. SVG anchor elements should support
>>> these properties too according to the SVG 2 specification and
>>> https://github.com/w3c/svgwg/issues/315.
>>>
>>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1451823
>>>
>>
>> I looked at the patch briefly, and I'm a bit confused about the state of
>>  . Specifically, my understanding is that we don't currently ship
>> it - it's behind a pref and it's off by default (
>> https://searchfox.org/mozilla-central/source/modules/libpref
>> /init/all.js#303 ). However, we have support in the codebase. But it
>> looks to me like the patch on the bug doesn't really check this pref
>> (unsure if we expose .ping for HTML if the pref is off) and doesn't
>> alter the implementation. At a minimum, it looks to me like this check:
>>
>> https://searchfox.org/mozilla-central/source/docshell/base/n
>> sPingListener.cpp#255-259
>>
>> would need updating to actually support .ping "properly" for SVG.
>>
>
> Sorry for the repetitive post, but I neglected to actually make the point
> I was trying to make. I can't really tell what the intent is from the
> patch, but I would be hesitant to say that this "implements and ships"
> 'ping' without any qualifications (in, say, release notes), because in
> effect the pref will still be off and presumably this means pings won't get
> sent (neither for HTML nor SVG links).
>
>
> ~ Gijs
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Gijs Kruitbosch]

On 10/04/2018 09:03, Gijs Kruitbosch wrote:

On 09/04/2018 22:11, longs...@gmail.com wrote:
Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, 
hreflang, type and text properties. SVG anchor elements should support 
these properties too according to the SVG 2 specification and 
https://github.com/w3c/svgwg/issues/315.


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


I looked at the patch briefly, and I'm a bit confused about the state of 
 . Specifically, my understanding is that we don't currently 
ship it - it's behind a pref and it's off by default ( 
https://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#303 
). However, we have support in the codebase. But it looks to me like the 
patch on the bug doesn't really check this pref (unsure if we expose 
.ping for HTML if the pref is off) and doesn't alter the 
implementation. At a minimum, it looks to me like this check:


https://searchfox.org/mozilla-central/source/docshell/base/nsPingListener.cpp#255-259 



would need updating to actually support .ping "properly" for SVG.


Sorry for the repetitive post, but I neglected to actually make the 
point I was trying to make. I can't really tell what the intent is from 
the patch, but I would be hesitant to say that this "implements and 
ships" 'ping' without any qualifications (in, say, release notes), 
because in effect the pref will still be off and presumably this means 
pings won't get sent (neither for HTML nor SVG links).


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Gijs Kruitbosch]

On 09/04/2018 22:11, longs...@gmail.com wrote:

Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, 
hreflang, type and text properties. SVG anchor elements should support these 
properties too according to the SVG 2 specification and 
https://github.com/w3c/svgwg/issues/315.

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


I looked at the patch briefly, and I'm a bit confused about the state of 
 . Specifically, my understanding is that we don't currently 
ship it - it's behind a pref and it's off by default ( 
https://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#303 
). However, we have support in the codebase. But it looks to me like the 
patch on the bug doesn't really check this pref (unsure if we expose 
.ping for HTML if the pref is off) and doesn't alter the 
implementation. At a minimum, it looks to me like this check:


https://searchfox.org/mozilla-central/source/docshell/base/nsPingListener.cpp#255-259

would need updating to actually support .ping "properly" for SVG.

~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Gijs Kruitbosch]

On 10/04/2018 03:07, Cameron McCormack wrote:

On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote:

Do we have a heuristic for when to /not/ include something from HTML in SVG?


If it doesn't make two features which already exist in both HTML and SVG more 
consistent, then I wouldn't include it.


More or less, these additions to SVG just strike me as having solid
potential risk (for both spec-interaction and implementation bugs) and
negligible upside. Do we have people asking for this?


I don't know of people asking for this, but I would hope that we could share the 
implementations of these properties between HTMLAnchorElement and SVGAElement.  The 
closer the two  elements are in behavior, and the more we can share 
implementation between them, the lower the risk for bugs between the two.  (Ignoring 
the general risk of bugs from touching code at all.)


I don't know about the C++ side of things here in terms of shared 
implementation, but *behavior* is already different as per spec. And we 
(frontend folks who have to make sure things like context menus deal 
with arbitrary web content) regularly forget that, and then end up being 
bitten by it. Most annoyingly, for SVG  the `.href` property is an 
SVGAnimatedString object with `baseVal` and `animVal` properties, not a 
string like it is in HTML.


I assume that the same thing applies to the properties this is adding, 
which means this is on the one hand more consistency with HTML (same 
properties) and on the other hand, less (different values anyway).


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Anne van Kesteren]

On Tue, Apr 10, 2018 at 3:58 AM, Jeff Gilbert  wrote:
> Do we have a heuristic for when to /not/ include something from HTML in SVG?
>
> More or less, these additions to SVG just strike me as having solid
> potential risk (for both spec-interaction and implementation bugs) and
> negligible upside. Do we have people asking for this?

Microsoft and the SVG WG seem to be driving this somewhat. I think
there's mostly upsides to having HTML and SVG share more code as it
means ongoing maintenance will be more shared as well. It seems it
might also lead to some simplification on the SVG side (e.g., a
further change being considered is to make target a simple string
rather than an animated string).

OP did not mention this, but the idea is that pretty much everything
would end up being defined in HTML:
https://github.com/whatwg/html/issues/3591.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Cameron McCormack]

On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote:
> Do we have a heuristic for when to /not/ include something from HTML in SVG?

If it doesn't make two features which already exist in both HTML and SVG more 
consistent, then I wouldn't include it.

> More or less, these additions to SVG just strike me as having solid
> potential risk (for both spec-interaction and implementation bugs) and
> negligible upside. Do we have people asking for this?

I don't know of people asking for this, but I would hope that we could share 
the implementations of these properties between HTMLAnchorElement and 
SVGAElement.  The closer the two  elements are in behavior, and the more we 
can share implementation between them, the lower the risk for bugs between the 
two.  (Ignoring the general risk of bugs from touching code at all.)

> Are there privacy concerns from embedding pings (et al) in images? I
> suppose we better have been handling CORS requests from within SVGs
> properly already, so it should Just Work?

SVG as images don't have scripting and can't be interacted with to activate 
links, so I don't think it's a concern there.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Jeff Gilbert]

Do we have a heuristic for when to /not/ include something from HTML in SVG?

More or less, these additions to SVG just strike me as having solid
potential risk (for both spec-interaction and implementation bugs) and
negligible upside. Do we have people asking for this?

Are there privacy concerns from embedding pings (et al) in images? I
suppose we better have been handling CORS requests from within SVGs
properly already, so it should Just Work?

On Mon, Apr 9, 2018 at 6:26 PM, Cameron McCormack  wrote:
> On Tue, Apr 10, 2018, at 7:56 AM, Jeff Gilbert wrote:
>> Can we not put more things into SVG? Making SVG more complicated seems
>> like it should be an anti-goal for the web platform.
>
> I think we should align the features and behavior of HTML  and SVG .
>
>   
>   something
>  
>
>   
>
> I don't see why the two DOM objects for the HTML  and SVG  should 
> behave substantially differently.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Cameron McCormack]

On Tue, Apr 10, 2018, at 7:56 AM, Jeff Gilbert wrote:
> Can we not put more things into SVG? Making SVG more complicated seems
> like it should be an anti-goal for the web platform.

I think we should align the features and behavior of HTML  and SVG .

  
  something
 
   
  

I don't see why the two DOM objects for the HTML  and SVG  should behave 
substantially differently.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Jeff Gilbert]

Can we not put more things into SVG? Making SVG more complicated seems
like it should be an anti-goal for the web platform.

On Mon, Apr 9, 2018 at 2:11 PM,   wrote:
> Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, 
> hreflang, type and text properties. SVG anchor elements should support these 
> properties too according to the SVG 2 specification and 
> https://github.com/w3c/svgwg/issues/315.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1451823
>
> Platform coverage: All
> Target release: Firefox 61
> Preference behind which this will be implemented: None
> Is this feature enabled by default in sandboxed iframes: Yes, enabled 
> everywhere
> DevTools bug: None
> Do other browser engines implement this? Microsoft are working on an 
> implementation for Edge. They have created web platform tests for this.
> web-platform-tests: https://github.com/w3c/web-platform-tests/pull/10275
> Secure contexts: n/a
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[longsonr]

Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, 
hreflang, type and text properties. SVG anchor elements should support these 
properties too according to the SVG 2 specification and 
https://github.com/w3c/svgwg/issues/315.

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

Platform coverage: All
Target release: Firefox 61
Preference behind which this will be implemented: None
Is this feature enabled by default in sandboxed iframes: Yes, enabled everywhere
DevTools bug: None
Do other browser engines implement this? Microsoft are working on an 
implementation for Edge. They have created web platform tests for this.
web-platform-tests: https://github.com/w3c/web-platform-tests/pull/10275
Secure contexts: n/a 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform