I agree that we shouldn't make Math.ceil the default code path. What does the change look like? Could it be post-processed onto the JS output when somebody needs it? I didn't think Opera was one of our target browsers.
-Alex On 8/20/17, 1:23 AM, "Harbs" <harbs.li...@gmail.com> wrote: >I discovered a bug in Blink (Chrome and Opera).[1] > >The workaround for this is to set the width and height of svg elements to >round numbers (using Math.ceil seems to generally be a good way of doing >this). I have implemented the workaround in my app and it works well. I’m >debating on whether this is something that should go in framework code. > >Reasons to add it: >1. It will make SVG components display correctly in all browsers. >2. Client developers do not need to be aware of this issue. > >Reasons not to: >1. It’s a bug which I believe will only present itself in cases where >there is transforms applied to the elements. >2. It’s hopefully a temporary problem until it’s fixed in Blink. >3. It’s “just in case” code that’s only needed for Chrome and Opera and >is only needed for certain types of svg hierarchies. >4. It’s relatively easy to work around in client code. >5. I’m pretty sure that elements which have a scale transformation will >display incorrectly if the width and height values are rounded. > >To me, reason number 5 is a pretty compelling reason to NOT fix this in >the framework. I do think we should document this bug with the workaround >somewhere though. > >Thoughts? > >Harbs > >[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.c >hromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D757196&data=02%7C01%7C >%7C6de72659db7c4afeeb1f08d4e7a4b5ea%7Cfa7b1b5a7b34438794aed2c178decee1%7C0 >%7C0%7C636388141989832483&sdata=9eYrcJ4kvQITIot%2BibogmJhiPaV%2FBsVt1KCM1t >5fO%2BU%3D&reserved=0
