[Webkit-unassigned] [Bug 261656] [SVG2] Allow leading and trailing whitespace in svg attributes using <integer>, <angle>, <number>, <length> and <percentage>

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=261656

Karl Dubost <karlcow at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |karlcow at apple.com

--- Comment #1 from Karl Dubost <karlcow at apple.com> ---
The test:

data:text/html,<svg id="testcontainer"><defs><marker></marker><stop></stop><filter><feTurbulence></feTurbulence></filter></defs></svg>


document.getElementsByTagName('stop')[0].setAttribute('offset', '-47a')


Then they try to 
document.getElementsByTagName('stop')[0].getAttribute('offset')

which returns '-47a' in all browsers.

Where it differs is when requesting:
document.getElementsByTagName('stop')[0].offset.baseVal 

it returns 

-47 in Safari 
0   in Firefox
0   in Chrome

It seems Safari is normalizing the value by ignoring the trailing garbage.
While the others are saying bad values let's reset it.

In fact
document.getElementsByTagName('stop')[0].offset returns on Safari.

{animVal: -47, baseVal: -47}


https://svgwg.org/svg2-draft/pservers.html#GradientStopAttributes
the initial value is indeed 0.
The values

<number>
A number usually ranging from 0 to 1.
<percentage>
A percentage usually ranging from 0% to 100%.


I don't remember where are the processing rules for the invalid values in CSS. 

But baseVal and animVal are defined in
https://svgwg.org/svg2-draft/types.html#__svg__SVGAnimatedString__baseVal

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230920/3e1cf317/attachment.htm>