- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Oct 2018 20:04:35 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `What is the unit type after setting an SVGAngle or SVGLength's value`, and agreed to the following: * ``RESOLUTION: When setting `value` on an SVGLength or SVGAngle, the current unit type is preserved if the object has a defined conversion factor from the unit type to user units / implicit degrees.`` <details><summary>The full IRC log of that discussion</summary> <krit> topic: What is the unit type after setting an SVGAngle or SVGLength's value<br> <krit> GitHub: https://github.com/w3c/svgwg/issues/478<br> <krit> AmeliaBR: Robert filed it couple of months ago and we forgot about it.<br> <krit> AmeliaBR: it is a case where browsers do not match the spec and we should decide if we change the spec.<br> <krit> krit: are browsers interoperable?<br> <krit> AmeliaBR: mostly. Chrome, Safari, Firefox seems consistent, Edge is a bit different but doesn't match the spec either.<br> <krit> krit: is there a proposal in the issue?<br> <krit> AmeliaBR: I've written up one in a comment<br> <krit> AmeliaBR: The setter algorithm for angle or length object needs to convoluted to match the actual behavior<br> <krit> AmeliaBR: based on current behaviours I'd recommend changing the spec text.<br> <krit> AmeliaBR: question is about the value properties. One can access the length in the unit they are specified in or the units directly.<br> <krit> AmeliaBR: what happens when you set the angle value in implicit degrees. Should that set units as well to the used unit? Or should it do a backwards conversion to use the original units?<br> <krit> AmeliaBR: spec says to unset the unit, browsers preserve.<br> <krit> AmeliaBR: Set a value in ems and you set it to 24, browsers would use Unser units in converted with the previous units... for 24 it would be 2ems<br> <krit> AmeliaBR: for angles: should it treat the angle unites?<br> <krit> AmeliaBR: all implementations do the backwards translation to the original units<br> <krit> chris: seems reasonable<br> <krit> AmeliaBR: there could be issues with fonts and ems<br> <krit> AmeliaBR: anther is the UNKNOWN type<br> <krit> AmeliaBR: especially with calc() function we have to define what happens.<br> <krit> chris: we shouldn't<br> <krit> AmeliaBR: we define it for attributes which we treat as unknown unit but we can not translate it back<br> <krit> AmeliaBR: that is the exception where we should reset the current unit<br> <krit> AmeliaBR: that is what Robert showed in his tests.<br> <krit> chris: just don't want to redefine calc() and rather suggest to use CSS. but this is ok<br> <krit> AmeliaBR: we do allow full cSS grammar in presentation attributes and need to handle it in SVG DOM<br> <krit> AmeliaBR: at this point we should look at actual browser behavior in these edge cases and look at consistency and decide based on the results.<br> <krit> krit: thought there were tests. So we still need more tests for edge cases?<br> <krit> AmeliaBR: yes, need more testing.<br> <AmeliaBR> Proposed resolution: When setting `value` on an SVGLength or SVGAngle, the current unit type is preserved if the object has a defined conversion factor from the unit type to user units / implicit degrees.<br> <krit> RESOLUTION: When setting `value` on an SVGLength or SVGAngle, the current unit type is preserved if the object has a defined conversion factor from the unit type to user units / implicit degrees.<br> <krit> krit: could you ask Robert if he could help with edge case testing?<br> <krit> AmeliaBR: I can ping hom<br> <krit> s/hom/him/<br> <krit> AmeliaBR: I'll assign myself<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/478#issuecomment-426043975 using your GitHub account
Received on Monday, 1 October 2018 20:04:37 UTC