Add UseCounters for the use of xml:lang in SVG

Add UseCounters for the use of xml:lang in SVG

Apart from the reflect SVGElement.xmllang, this is the only place in
Blink where xml:lang has an observable effect. Count usage to help
determine what, if anything, should be done with xml:lang. Discussed in
https://code.google.com/p/chromium/issues/detail?id=341854#c7

Note that else-branch where anything other than "preserve" is handled
does not seem per spec: http://www.w3.org/TR/xml11/#sec-white-space

BUG=341854
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=189263

[philipj_slow, 2015-01-30 11:33:03]

philipj@opera.com changed reviewers:
+ ed@opera.com

[philipj_slow, 2015-01-30 11:33:04]

PTAL

[fs, 2015-01-30 12:07:16]

On 2015/01/30 11:33:04, philipj_UTC7 wrote:
> Note that else-branch where anything other than "preserve" is handled
> does not seem per spec: http://www.w3.org/TR/xml11/#sec-white-space

http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#WhiteSpace might be more
relevant to look at. The use of 'nowrap' is I believe due to rendering reasons
more than anything else though (newlines etc are explicitly striped in the
corresponding render node.)

[Erik Dahlström (inactive), 2015-01-30 12:15:06]

My gut feel is that this will generate a (too) high count due to authoring tools
outputting xml:space (most often needlessly) in content, and I'm not sure we'll
be able to tell if it's safe to remove it based just on this data. It might
still be interesting to know this for sure however, so LGTM for that part.

It would also be good to add counters for the DOM side, for SVGElement.xmlspace
and SVGElement.xmllang. Those will probably show very low usage.

Re: the "does not seem per spec" thing in the description, note that the
whitespace handling is moving away from xml:space in SVG2, see
https://svgwg.org/svg2-draft/text.html#WhiteSpace. Also, the SVG 1.x spec had
more special rules for xml:space than what's in the xml spec (and yes, people
have complained about that before). Would be interesting to know what gecko maps
xml:space to internally.

[philipj_slow, 2015-01-30 13:48:35]

The CQ bit was checked by philipj@opera.com

[commit-bot: I haz the power, 2015-01-30 13:49:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/890863003/1

[philipj_slow, 2015-01-30 15:16:58]

On 2015/01/30 12:15:06, Erik Dahlström wrote:
> My gut feel is that this will generate a (too) high count due to authoring
tools
> outputting xml:space (most often needlessly) in content, and I'm not sure
we'll
> be able to tell if it's safe to remove it based just on this data. It might
> still be interesting to know this for sure however, so LGTM for that part.

Thanks!

> It would also be good to add counters for the DOM side, for
SVGElement.xmlspace
> and SVGElement.xmllang. Those will probably show very low usage.

I'll add those now.
 
> Re: the "does not seem per spec" thing in the description, note that the
> whitespace handling is moving away from xml:space in SVG2, see
> https://svgwg.org/svg2-draft/text.html#WhiteSpace. Also, the SVG 1.x spec had
> more special rules for xml:space than what's in the xml spec (and yes, people
> have complained about that before). Would be interesting to know what gecko
maps
> xml:space to internally.

It seems like even per https://svgwg.org/svg2-draft/text.html#LegacyXMLSpace
it's wrong to treat xml:space="banana" and xml:space="default" the same, right?
Should I file a bug?

[Erik Dahlström (inactive), 2015-01-30 15:26:22]

On 2015/01/30 15:16:58, philipj_UTC7 wrote:
> On 2015/01/30 12:15:06, Erik Dahlström wrote:
> > My gut feel is that this will generate a (too) high count due to authoring
> tools
> > outputting xml:space (most often needlessly) in content, and I'm not sure
> we'll
> > be able to tell if it's safe to remove it based just on this data. It might
> > still be interesting to know this for sure however, so LGTM for that part.
> 
> Thanks!
> 
> > It would also be good to add counters for the DOM side, for
> SVGElement.xmlspace
> > and SVGElement.xmllang. Those will probably show very low usage.
> 
> I'll add those now.

Thanks.

> > Re: the "does not seem per spec" thing in the description, note that the
> > whitespace handling is moving away from xml:space in SVG2, see
> > https://svgwg.org/svg2-draft/text.html#WhiteSpace. Also, the SVG 1.x spec
had
> > more special rules for xml:space than what's in the xml spec (and yes,
people
> > have complained about that before). Would be interesting to know what gecko
> maps
> > xml:space to internally.
> 
> It seems like even per https://svgwg.org/svg2-draft/text.html#LegacyXMLSpace
> it's wrong to treat xml:space="banana" and xml:space="default" the same,
right?
> Should I file a bug?

In general the rule in svg is that when an attribute is bogus (or the
implementation doesn't grok it) it falls back to the default (aka lacuna) value
for the given attribute, in this case that would be the "default" keyword. This
wasn't clear in the SVG 1.x spec, and it looks like svg2 should clarify that.

[commit-bot: I haz the power, 2015-01-30 15:32:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-01-30 15:32:32]

Try jobs failed on following builders:
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/48512)

[philipj_slow, 2015-01-30 15:50:30]

The CQ bit was checked by philipj@opera.com

[commit-bot: I haz the power, 2015-01-30 15:51:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/890863003/1

[commit-bot: I haz the power, 2015-01-30 16:39:08]

Committed patchset #1 (id:1) as
https://src.chromium.org/viewvc/blink?view=rev&revision=189263