SVGLength.value setter should set the value to <number>

SVGLength.value setter should set the value to <number>

As per SVG2, SVGLength.value setter should set the
SVGLength's value to a <number> whose value is value.
https://svgwg.org/svg2-draft/types.html#__svg__SVGLength__value

This patch is supportive patch for calc() support for SVGLength.

BUG=558304
Committed: https://crrev.com/c825d655f6aaf73484f9d56e9012793f5b9668cc
Cr-Commit-Position: refs/heads/master@{#403440}

[Shanmuga Pandi, 2016-07-01 07:32:06]

Description was changed from

==========
SVGLength.setValue should set the value to <NUMBER>

As per SVG2, SVGLength.setValue should set the
SVGLength's value to a <number> whose value is value.

This patch is supportive patch for calc() support for SVGLength.

BUG=558304
==========

to

==========
SVGLength.setValue should set the value to <NUMBER>

As per SVG2, SVGLength.setValue should set the
SVGLength's value to a <number> whose value is value.
https://svgwg.org/svg2-draft/types.html#__svg__SVGLength__value

This patch is supportive patch for calc() support for SVGLength.

BUG=558304
==========

[Shanmuga Pandi, 2016-07-01 07:32:07]

shanmuga.m@samsung.com changed reviewers:
+ fs@opera.com, pdr@chromium.org, rob.buis@samsung.com

[Shanmuga Pandi, 2016-07-01 07:32:26]

PTAL!!

Thanks!

[fs, 2016-07-01 09:08:05]

While I like the simplicity of these (new) semantics, it does change our
behavior slightly compared to every other browser. So we need to tread carefully
here. It might be worth looking for the origin of the change et.c.

> "SVGLength.setValue should set..."

s/setValue/value/g since we're talking about the 'value' property on the DOM
object.

https://codereview.chromium.org/2113943003/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/svg/dom/SVGLength-setvalue-interface.html
(right):

https://codereview.chromium.org/2113943003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/svg/dom/SVGLength-setvalue-interface.html:14: },
"Tests setValue interface");
"setValue interface" => "SVGLength.value setter"

(this could also go as a <title>)

Similarly for the filename (setvalue-interface => value-setter)

https://codereview.chromium.org/2113943003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/svg/SVGLength.cpp (right):

https://codereview.chromium.org/2113943003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/svg/SVGLength.cpp:80: void
SVGLength::setValue(float value, const SVGLengthContext& context)
This method is used in a few more places besides SVGLengthTearOff, so adding a
new setValueAsNumber or so would be the more cautious approach. I think we
should be able to eliminate the other setValue uses later on.

[Shanmuga Pandi, 2016-07-01 09:41:14]

Description was changed from

==========
SVGLength.setValue should set the value to <NUMBER>

As per SVG2, SVGLength.setValue should set the
SVGLength's value to a <number> whose value is value.
https://svgwg.org/svg2-draft/types.html#__svg__SVGLength__value

This patch is supportive patch for calc() support for SVGLength.

BUG=558304
==========

to

==========
SVGLength.value setter should set the value to <NUMBER>

As per SVG2, SVGLength.value setter should set the
SVGLength's value to a <number> whose value is value.
https://svgwg.org/svg2-draft/types.html#__svg__SVGLength__value

This patch is supportive patch for calc() support for SVGLength.

BUG=558304
==========

[Shanmuga Pandi, 2016-07-01 10:27:13]

Done the changes!!!

https://codereview.chromium.org/2113943003/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/svg/dom/SVGLength-setvalue-interface.html
(right):

https://codereview.chromium.org/2113943003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/svg/dom/SVGLength-setvalue-interface.html:14: },
"Tests setValue interface");
On 2016/07/01 09:08:05, fs wrote:
> "setValue interface" => "SVGLength.value setter"
> 
> (this could also go as a <title>)
> 
> Similarly for the filename (setvalue-interface => value-setter)

Done.

https://codereview.chromium.org/2113943003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/svg/SVGLength.cpp (right):

https://codereview.chromium.org/2113943003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/svg/SVGLength.cpp:80: void
SVGLength::setValue(float value, const SVGLengthContext& context)
On 2016/07/01 09:08:05, fs wrote:
> This method is used in a few more places besides SVGLengthTearOff, so adding a
> new setValueAsNumber or so would be the more cautious approach. I think we
> should be able to eliminate the other setValue uses later on.

Done.

[fs, 2016-07-01 10:33:17]

Description was changed from

==========
SVGLength.value setter should set the value to <NUMBER>

As per SVG2, SVGLength.value setter should set the
SVGLength's value to a <number> whose value is value.
https://svgwg.org/svg2-draft/types.html#__svg__SVGLength__value

This patch is supportive patch for calc() support for SVGLength.

BUG=558304
==========

to

==========
SVGLength.value setter should set the value to <number>

As per SVG2, SVGLength.value setter should set the
SVGLength's value to a <number> whose value is value.
https://svgwg.org/svg2-draft/types.html#__svg__SVGLength__value

This patch is supportive patch for calc() support for SVGLength.

BUG=558304
==========

[Shanmuga Pandi, 2016-07-01 11:29:26]

On 2016/07/01 09:08:05, fs wrote:
> While I like the simplicity of these (new) semantics, it does change our
> behavior slightly compared to every other browser. So we need to tread
carefully
> here. It might be worth looking for the origin of the change et.c.
> 


Could you help me to trace the origin of the change ?

[fs, 2016-07-01 11:34:35]

On 2016/07/01 at 11:29:26, shanmuga.m wrote:
> On 2016/07/01 09:08:05, fs wrote:
> > While I like the simplicity of these (new) semantics, it does change our
> > behavior slightly compared to every other browser. So we need to tread
carefully
> > here. It might be worth looking for the origin of the change et.c.
> > 
> 
> 
> Could you help me to trace the origin of the change ?

The commit adding the spec text [1] referred to ACTION-3722 [2] which was filed
after a discussion on a F2F ~1.5y ago [3]. At a glance, the discussion there
doesn't seem to touch upon this in particular. Let's try it though. LGTM.

[1] https://github.com/w3c/svgwg/commit/2f9cc83a821281e88edf1dc2edc013b7b274d85b
[2] https://www.w3.org/Graphics/SVG/WG/track/actions/3722
[3] https://www.w3.org/2015/02/11-svg-minutes.html#item04

[Shanmuga Pandi, 2016-07-01 11:40:57]

The CQ bit was checked by shanmuga.m@samsung.com

[commit-bot: I haz the power, 2016-07-01 11:41:04]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-01 12:52:24]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-07-01 12:52:26]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-01 12:54:18]

Description was changed from

==========
SVGLength.value setter should set the value to <number>

As per SVG2, SVGLength.value setter should set the
SVGLength's value to a <number> whose value is value.
https://svgwg.org/svg2-draft/types.html#__svg__SVGLength__value

This patch is supportive patch for calc() support for SVGLength.

BUG=558304
==========

to

==========
SVGLength.value setter should set the value to <number>

As per SVG2, SVGLength.value setter should set the
SVGLength's value to a <number> whose value is value.
https://svgwg.org/svg2-draft/types.html#__svg__SVGLength__value

This patch is supportive patch for calc() support for SVGLength.

BUG=558304

Committed: https://crrev.com/c825d655f6aaf73484f9d56e9012793f5b9668cc
Cr-Commit-Position: refs/heads/master@{#403440}
==========

[commit-bot: I haz the power, 2016-07-01 12:54:19]

Patchset 2 (id:??) landed as
https://crrev.com/c825d655f6aaf73484f9d56e9012793f5b9668cc
Cr-Commit-Position: refs/heads/master@{#403440}