Remove contentStyleType and contentScriptType from SVGSVGElement

Remove contentStyleType and contentScriptType from SVGSVGElement

These are marked for removal in the changes section:

http://www.w3.org/TR/SVG2/changes.html

Note that Mozilla has already removed these two.

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

[rwlbuis, 2014-04-15 18:36:04]

PTAL. Do we need an intent for this?

[pdr., 2014-04-15 18:46:09]

On 2014/04/15 18:36:04, rwlbuis wrote:
> PTAL. Do we need an intent for this?

Codechange: LGTM

Please add a link to the relevant spec discussion behind this feature being
removed (www-svg, svgwg minutes, etc).

I think we should send out a blink-dev email for this since we don't have
UseCounter data. Can you please send out an intent to deprecate and remove to
blink-dev and wait a day or so before committing?

[rwlbuis, 2014-04-15 20:06:05]

On 2014/04/15 18:46:09, pdr wrote:
> On 2014/04/15 18:36:04, rwlbuis wrote:
> > PTAL. Do we need an intent for this?
> 
> Codechange: LGTM
> 
> Please add a link to the relevant spec discussion behind this feature being
> removed (www-svg, svgwg minutes, etc).
> 
> I think we should send out a blink-dev email for this since we don't have
> UseCounter data. Can you please send out an intent to deprecate and remove to
> blink-dev and wait a day or so before committing?

That sounds like a plan :)
Update, I'll also add the similar contentScriptType removal to this CL ; the way
it was listed in the SVG2 changes section caused me to miss it :)

[Erik Dahlström (inactive), 2014-04-16 11:44:19]

https://codereview.chromium.org/233653007/diff/40001/Source/core/svg/SVGAttri...
File Source/core/svg/SVGAttributeNames.in (left):

https://codereview.chromium.org/233653007/diff/40001/Source/core/svg/SVGAttri...
Source/core/svg/SVGAttributeNames.in:37: contentStyleType
Should we also drop the other removed attributes and elements in SVG2? 

If so, that can be done separately, just wondering if we need to worry about the
html5 spec here, since there are case fixups specifically for these mixed-case
attributes/elements.

[rwlbuis, 2014-04-16 15:13:12]

On 2014/04/16 11:44:19, Erik Dahlström wrote:
>
https://codereview.chromium.org/233653007/diff/40001/Source/core/svg/SVGAttri...
> File Source/core/svg/SVGAttributeNames.in (left):
> 
>
https://codereview.chromium.org/233653007/diff/40001/Source/core/svg/SVGAttri...
> Source/core/svg/SVGAttributeNames.in:37: contentStyleType
> Should we also drop the other removed attributes and elements in SVG2? 

Yep, I think we should work towards that, ideally with UseCounter info to make
the decision even easier.

> If so, that can be done separately, just wondering if we need to worry about
the
> html5 spec here, since there are case fixups specifically for these mixed-case
> attributes/elements.

Can you explain a bit more? AFAIK the html5 parser does fixing up by simply
grabbing the svg attribute list, so it is really dynamic.

[Erik Dahlström (inactive), 2014-04-16 15:47:00]

On 2014/04/16 15:13:12, rwlbuis wrote:
> On 2014/04/16 11:44:19, Erik Dahlström wrote:
> >
>
https://codereview.chromium.org/233653007/diff/40001/Source/core/svg/SVGAttri...
> > File Source/core/svg/SVGAttributeNames.in (left):
> > 
> >
>
https://codereview.chromium.org/233653007/diff/40001/Source/core/svg/SVGAttri...
> > Source/core/svg/SVGAttributeNames.in:37: contentStyleType
> > Should we also drop the other removed attributes and elements in SVG2? 
> 
> Yep, I think we should work towards that, ideally with UseCounter info to make
> the decision even easier.

Right, what I meant was that there are a few attributes and elements that we
removed support for which still remain in the *.in files.

> > If so, that can be done separately, just wondering if we need to worry about
> the
> > html5 spec here, since there are case fixups specifically for these
mixed-case
> > attributes/elements.
> 
> Can you explain a bit more? AFAIK the html5 parser does fixing up by simply
> grabbing the svg attribute list, so it is really dynamic.

Ok, so if one were to test for proper casing would blink pass? Say have a
"contentstyletype" attribute in inline svg, will it get camelcased by the parser
on insertion in the document tree or not?

[rwlbuis, 2014-04-16 17:10:27]

On 2014/04/16 15:47:00, Erik Dahlström wrote:
> On 2014/04/16 15:13:12, rwlbuis wrote:
> > On 2014/04/16 11:44:19, Erik Dahlström wrote:
> > >
> >
>
https://codereview.chromium.org/233653007/diff/40001/Source/core/svg/SVGAttri...
> > > File Source/core/svg/SVGAttributeNames.in (left):
> > > 
> > >
> >
>
https://codereview.chromium.org/233653007/diff/40001/Source/core/svg/SVGAttri...
> > > Source/core/svg/SVGAttributeNames.in:37: contentStyleType
> > > Should we also drop the other removed attributes and elements in SVG2? 
> > 
> > Yep, I think we should work towards that, ideally with UseCounter info to
make
> > the decision even easier.
> 
> Right, what I meant was that there are a few attributes and elements that we
> removed support for which still remain in the *.in files.

You probably mean stuff like color-profile and there may be others agreed. Great
point, but indeed something for a different CL.

> > > If so, that can be done separately, just wondering if we need to worry
about
> > the
> > > html5 spec here, since there are case fixups specifically for these
> mixed-case
> > > attributes/elements.
> > 
> > Can you explain a bit more? AFAIK the html5 parser does fixing up by simply
> > grabbing the svg attribute list, so it is really dynamic.
> 
> Ok, so if one were to test for proper casing would blink pass? Say have a
> "contentstyletype" attribute in inline svg, will it get camelcased by the
parser
> on insertion in the document tree or not?

I see. Well that was the old behavior, but the new one will give that up for
these two. Do you think the html5 parser should still support it?

[pdr., 2014-04-16 21:43:43]

I think there's agreement that this is good to go, and we'll address other
attributes in a followup.

LGTM for this patch.

[rwlbuis, 2014-04-16 21:47:42]

The CQ bit was checked by rob.buis@samsung.com

[commit-bot: I haz the power, 2014-04-16 21:47:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rob.buis@samsung.com/233653007/40001

[commit-bot: I haz the power, 2014-04-16 22:54:10]

Change committed as 171813

[fs, 2014-04-17 07:31:48]

On 2014/04/16 21:43:43, pdr wrote:
> I think there's agreement that this is good to go, and we'll address other
> attributes in a followup.

FWIW, Gecko only removed the IDL attribute, so running something like:

<!DOCTYPE html>
<svg height=0><script contentscripttype></script></svg>
<script>
var scriptElm = document.querySelector('script');
var attrs = ['contentscripttype', 'contentScriptType'];
for (var i in attrs)
  document.write('<p>hasAttribute(' + attrs[i] + '): ' +
scriptElm.hasAttribute(attrs[i]) + '</p>');
</script>

will still give the "expected" result in a recent enough FF, while it'll give
the inverted result in Blink (now, with this patch). (Not that _I_ think it
matters much in this particular case, but...)

[pdr., 2014-04-30 19:12:16]

On 2014/04/17 07:31:48, fs wrote:
> On 2014/04/16 21:43:43, pdr wrote:
> > I think there's agreement that this is good to go, and we'll address other
> > attributes in a followup.
> 
> FWIW, Gecko only removed the IDL attribute, so running something like:
> 
> <!DOCTYPE html>
> <svg height=0><script contentscripttype></script></svg>
> <script>
> var scriptElm = document.querySelector('script');
> var attrs = ['contentscripttype', 'contentScriptType'];
> for (var i in attrs)
>   document.write('<p>hasAttribute(' + attrs[i] + '): ' +
> scriptElm.hasAttribute(attrs[i]) + '</p>');
> </script>
> 
> will still give the "expected" result in a recent enough FF, while it'll give
> the inverted result in Blink (now, with this patch). (Not that _I_ think it
> matters much in this particular case, but...)

Just FYI: these have now been removed from the spec:
http://html5.org/tools/web-apps-tracker?from=8591&to=8592