W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > April 2017

Re: [fxtf-drafts] [geometry] DOMMatrix should not depend on the CSS parser

From: Philip Jägenstedt via GitHub <sysbot+gh@w3.org>
Date: Tue, 25 Apr 2017 11:14:21 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-296997884-1493118860-sysbot+gh@w3.org>
As [reported](https://groups.google.com/a/chromium.org/d/msg/blink-dev/cAiTOdSGyes/gL4XXaGMBgAJ) by @chrishtr on blink-dev, he added separate use counters for [setMatrixValue](https://www.chromestatus.com/metrics/feature/timeline/popularity/1912) and the [string constructor](https://www.chromestatus.com/metrics/feature/timeline/popularity/1913). They haven't reached the stable channel yet, but getting rid of the constructor does not look promising.

A related Chromium issue is https://bugs.chromium.org/p/chromium/issues/detail?id=703908

Since the string-parsing is already shipping for WebKitCSSMatrix or DOMMatrix in all engines, I propose to leave that intact and just limit it to the main thread. Concretely:
* Add [Exposed=Window] to setMatrixValue
* Let the DOMString constructor throw TypeError in workers (using prose)

(The idea is to behave as if the string constructor didn't exist, even though it does. If the third `sequence<unrestricted double> numberSequence)` variant wasn't there, I'd instead suggest behaving like the no-argument constructor.)

-- 
GitHub Notification of comment by foolip
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/122#issuecomment-296997884 using your GitHub account
Received on Tuesday, 25 April 2017 11:14:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 November 2018 00:45:57 UTC