Intent to Ship: Geometry Interfaces

[xlai]

Contact emails

jinho...@samsung.com, caba...@adobe.com, dsch...@chromium.org, esprehn@chromium.org,

chri...@chromium.org, p...@chromium.org

Spec

https://drafts.fxtf.org/geometry/

Summary

The specification provides basic geometric interfaces to represent points, rectangles,

quadrilaterals and transformation matrices that can be used by other modules or specifications.

We will ship following interfaces:

 - DOMMatrix and DOMMatrixReadOnly

 - DOMRect and DOMRectReadOnly

 - DOMQuad

 - DOMPoint and DOMPointReadOnly

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/V_bJNtOg0oM/lECG9SikFwEJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

http://test.csswg.org/suites/geometry-1_dev/nightly-unstable/html/toc.htm

More conformance tests will be followed up.

Debuggability

You can enable the geometry interfaces by passing "--enable-blink-features=GeometryInterfaces" to Chrome and try the constructors and functions of these interfaces.

Interoperability and Compatibility Risk

The specification has been proposed in 2013 and some browsers have shipped the interfaces since 2014, so generally the risk is low.

As the specification has undergone several changes (https://drafts.fxtf.org/geometry/#changes) since 2014, other browsers have not picked up the new constructors for

several ReadOnly interfaces yet; but such a non-interoperability will be short-termed as other browsers match the latest specification in the future.

Edge: No signals

Firefox: Shipped

Safari: Shipped

Web developers: Positive

OWP launch tracking bug

http://crbug.com/388780

Entry on the feature dashboard

http://www.chromestatus.com/features/6015941766807552

[Jinho Bang]

non-owner lgtm :)

[Simon Pieters]

> <http://www.google.com/url?q=http%3A%2F%2Ftest.csswg.org%2Fsuites%2Fgeometry-1_dev%2Fnightly-unstable%2Fhtml%2Ftoc.htm&sa=D&sntz=1&usg=AFQjCNG63D9QQogkqdVgArk4M2Y0zcLnJA>

>
> More conformance tests will be followed up.
>
> Debuggability
>
> You can enable the geometry interfaces by passing
> "--enable-blink-features=GeometryInterfaces"
> to Chrome and try the constructors and functions of these interfaces.
>
> Interoperability and Compatibility Risk
>
> The specification has been proposed in 2013 and some browsers have
> shipped
> the interfaces since 2014, so generally the risk is low.
>
> As the specification has undergone several changes
> (https://drafts.fxtf.org/
> geometry/#changes) since 2014, other browsers have not picked up the new
> constructors for
>
> several ReadOnly interfaces yet; but such a non-interoperability will be
> short-termed as other browsers match the latest specification in the
> future.

Could you file issues for the browsers that have shipped and don't match
the current specification, informing them about this Intent to Ship, so as
to minimize the time for this non-interop?

> Edge: No signals
>
> Firefox: Shipped
>
> Safari: Shipped
>
> Web developers: Positive
>
> OWP launch tracking bug
>
> http://crbug.com/388780
>
> Entry on the feature dashboard <http://www.chromestatus.com/>
>

> http://www.chromestatus.com/features/6015941766807552
>


--
Simon Pieters
Opera Software

[xlai]

Yup, I've filed issues https://bugzilla.mozilla.org/show_bug.cgi?id=1346399 and https://bugs.webkit.org/show_bug.cgi?id=169482 to request an update of geometry interfaces to the latest spec. 

Moreover, I also realized that Safari has shown public support for Geometry interfaces but they actually haven't shipped them yet. Only Firefox has shipped the interfaces.

[Boris Zbarsky]

On 3/10/17 5:00 PM, xlai wrote:
> Yup, I've filed
> issues https://bugzilla.mozilla.org/show_bug.cgi?id=1346399
> and https://bugs.webkit.org/show_bug.cgi?id=169482 to request an update
> of geometry interfaces to the latest spec.

So we have a possible problem here.

The interfaces as defined in the spec today do not match the interfaces
as defined in the spec at the point when Firefox shipped it. Not only
that, but the differences are not easily detectable.

Specifically, the behavior of rotate/rotateSelf was totally changed
without an easy way to detect it without actually trying to rotate a
matrix.

The behavior of scale/scaleSelf was also changed, but at least in a
detectable way (.length has changed).

Anyway, to the extent that sites are using DOMMatrix (as opposed to
WebkitCSSMatrix), it looks like there is risk of Chrome suddenly
supporting it with different semantics causing site breakage....

-Boris

[Boris Zbarsky]

On 3/10/17 5:16 PM, Boris Zbarsky wrote:
> Specifically, the behavior of rotate/rotateSelf was totally changed
> without an easy way to detect it without actually trying to rotate a
> matrix.

I guess all the args became optional, so the .length changed here too.
So the real question is how likely sites are to be checking .length.

-Boris

[Rik Cabanier]

It's probably very unlikely as few sites are using the API  since it only shipped in Firefox.,

[Simon Pieters]

On Mon, 13 Mar 2017 02:55:27 +0100, Rik Cabanier <caba...@gmail.com>
wrote:

I think it is unreasonable to make such assumptions. For example, it would
be quite possible to develop and use widely a polyfill (that matches the
Gecko implementation), which uses the native implementation if available.
That would then break in Chromium if they use rotate(angle, originX,
originY) semantics instead of rotate(rotX, rotY, rotZ).

However I searched for usage of DOMMatrix and didn't find much; see
https://bugzilla.mozilla.org/show_bug.cgi?id=1346399#c3

[Boris Zbarsky]

On 3/12/17 9:55 PM, Rik Cabanier wrote:
> It's probably very unlikely as few sites are using the API since it
> only shipped in Firefox.,

The problem would be sites that detect whether the "standard" API is
available and use if it so, falling back to WebKitCSSMatrix otherwise.

-Boris

[Rik Cabanier]

On Mon, Mar 13, 2017 at 3:06 AM, Simon Pieters <sim...@opera.com> wrote:

On Mon, 13 Mar 2017 02:55:27 +0100, Rik Cabanier <caba...@gmail.com> wrote:

On Fri, Mar 10, 2017 at 2:30 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 3/10/17 5:16 PM, Boris Zbarsky wrote:

Specifically, the behavior of rotate/rotateSelf was totally changed
without an easy way to detect it without actually trying to rotate a
matrix.

I guess all the args became optional, so the .length changed here too. So
the real question is how likely sites are to be checking .length.

It's probably very unlikely as few sites are using the API  since it only
shipped in Firefox.,

I think it is unreasonable to make such assumptions. For example, it would be quite possible to develop and use widely a polyfill (that matches the Gecko implementation), which uses the native implementation if available. That would then break in Chromium if they use rotate(angle, originX, originY) semantics instead of rotate(rotX, rotY, rotZ).

Boris' question was about ".length"

DOMMatrix was supposed to be a perfect alias of WebkitCSSMatrix so having a different rotate function would be breaking code.

[Rik Cabanier]

How likely is it that a polyfill for DOMMatrix would do this?

It sounds that worst case, older polyfills would switch to WebKitCSSMatrix even though DOMMatrix is available.

[Justin Novosad]

Currently, about 5% of pages visited with Chrome are using WebKitCSSMatrix. It's not clear how much (if any) of the uses are polyfills that would otherwise use DOMMatrix.  Does Mozilla have usage stats for DOMMatrix?

[Boris Zbarsky]

On 3/13/17 6:06 AM, Simon Pieters wrote:
> However I searched for usage of DOMMatrix and didn't find much; see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1346399#c3

Thank you for doing that. This does suggest that the change might be
safe to make.

-Boris

[Boris Zbarsky]

On 3/13/17 10:32 AM, Rik Cabanier wrote:
> How likely is it that a polyfill for DOMMatrix would do this?

I don't know, though Simon's data suggests not very.

-Boris

[Boris Zbarsky]

On 3/13/17 11:04 AM, Justin Novosad wrote:
> Does Mozilla have usage stats for DOMMatrix?

We do not, sorry.

-Boris

[Jochen Eisinger]

As you've already discovered, the performance of these interfaces is not as you'd expect, both in terms of memory usage and runtime. I think we might be able to recover some of the lost performance in bindings, however, I don't think we'll be able to recover all of it.

I see the argument that those interfaces are nicer to use - maybe it's worth the trade-off.

Note however that we already have matrices and similar concepts in the platform for WebGL which uses typed arrays for this purpose, so we'll run the risk of confusing developers here.

Anyways, from a process point of view, you've taken the necessary steps, and Firefox already ships it, so lgtm1

[Dimitri Glazkov]

LGTM2

[Jinho Bang]

As I know, gogag2@ is working on making existing WebKitCSSMatrix as an alias of DOMMatrix.

 - https://codereview.chromium.org/2709763004/

There are a little bit differences between WebKitCSSMatrix and DOMMatrix.

I think we should discuss/fix the differences before shipping this feature.

gogag2@, Could you share your investigation?

[gog...@gmail.com]

2017년 3월 18일 토요일 오전 1시 27분 3초 UTC+9, Jinho Bang 님의 말:

Yeah, I’m working on making WebKitCSSMatrix as an alias of DOMMatrix.

 - Related crbug: https://bugs.chromium.org/p/chromium/issues/detail?id=581955

 - WIP CL: https://codereview.chromium.org/2709763004/

I’ll share my investigation as follows:

When calling WebKitCSSMatrix.multiply with no parameter, the result matrix will be null.

But DOMMatrix.multiply with no parameter will multiply identity matrix.

/**

 * In case of WebKitCSSMatrix

 */

var cssMatrix1 = new WebKitCSSMatrix(…);

var cssMatrix2 = cssMatrix1.multiply();

assert cssMatrix2 == null;

/**

 * In case of DOMMatrix

 */

var domMatrix1 = new DOMMatrix(…);

var domMatrix2 = domMatrix1.multiply();

assert domMatrix1 == domMatrix2;

If the WebKitCSSMatrix is not invertible, throws NotSupportedError.

But DOMMatrix sets all attributes to NaN.

/**

 * In case of WebKitCSSMatrix

 */

var cssMatrix1 = new WebKitCSSMatrix(…);

var cssMatrix2 = cssMatrix1.inverse(); // Throws NotSupportedError

/**

 * In case of DOMMatrix

 */

var domMatrix1 = new WebKitCSSMatrix(…);

var domMatrix2 = domMatrix1.inverse(); // Set all attributes to NaN.

assert domMatrix2.m11 == NaN

assert domMatrix2.m12 == NaN

assert domMatrix2.m13 == NaN

…

WebKitCSSMatrix(undefined) throws no exception.

But DOMMatrix(undefined) throws SyntaxError.

/**

 * In case of WebKitCSSMatrix

 */

new WebKitCSSMatrix(undefined); // No exception

/**

 * In case of DOMMatrix

 */

new DOMMatrix(undefined); // Throws SyntaxError 

[Boris Zbarsky]

On 3/17/17 12:56 PM, gog...@gmail.com wrote:
> WebKitCSSMatrix(undefined) throws no exception.
>
> But DOMMatrix(undefined) throws SyntaxError.

This seems like a spec bug in DOMMatrix to me, coming from its arguable
misuse of overloads.

It could be addressed in the spec simply by replacing this:

Constructor,
Constructor(DOMString transformList),

with:

Constructor(optional DOMString transformList)

and defining the "not passed" behavior to create an identity matrix.

Of course the spec could also move entirely away from overloads to a
single optional union-typed argument.

-Boris

[Rik Cabanier]

On Fri, Mar 17, 2017 at 10:03 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 3/17/17 12:56 PM, gog...@gmail.com wrote:

WebKitCSSMatrix(undefined) throws no exception.

But DOMMatrix(undefined) throws SyntaxError.

This seems like a spec bug in DOMMatrix to me, coming from its arguable misuse of overloads.

I agree that's a spec bug. It was likely missed because there was no spec for WebKitCSSMatrix

 

It could be addressed in the spec simply by replacing this:

 Constructor,
 Constructor(DOMString transformList),

with:

 Constructor(optional DOMString transformList)

and defining the "not passed" behavior to create an identity matrix.

Of course the spec could also move entirely away from overloads to a single optional union-typed argument.

Can that be done later, or will that move have other subtle side effects? 

[Boris Zbarsky]

On 3/17/17 1:14 PM, Rik Cabanier wrote:
> Can that be done later, or will that move have other subtle side effects?

Moving from an overload set where all overloads have one argument, with
one of them possibly optional, to a single overload with a single
possibly optional union should not have caller-observable effects. If
it does, that's a bug in the webidl spec which we should fix forthwith.

I'm not aware of such bugs at the present time, though they have existed
in the past (e.g. <https://github.com/heycam/webidl/issues/123>).

-Boris

[Elliott Sprehn]

I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.

[Rik Cabanier]

On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.

One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.

CSS supports the transform syntax, so DOMMatrix has to support it as well.

[Simon Pieters]

On Fri, 17 Mar 2017 17:56:47 +0100, <gog...@gmail.com> wrote:

>
>
> 2017년 3월 18일 토요일 오전 1시 27분 3초 UTC+9, Jinho Bang 님의 말:
>>

> Yeah, I’m working on making WebKitCSSMatrix as an alias of DOMMatrix.

>
> - Related crbug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=581955
>
> - WIP CL: https://codereview.chromium.org/2709763004/
>
>
> I’ll share my investigation as follows:

Could you please report each of these at
https://github.com/w3c/fxtf-drafts/issues/new?title=[geometry]%20

Thanks!

> WebKitCSSMatrix(undefined) throws no exception.
>
> But DOMMatrix(undefined) throws SyntaxError.
>
>

> /**
>
> * In case of WebKitCSSMatrix
>
> */
>
> new WebKitCSSMatrix(undefined); // No exception
>
>
> /**
>
> * In case of DOMMatrix
>
> */
> new DOMMatrix(undefined); // Throws SyntaxError

[Elliott Sprehn]

On Sat, Mar 18, 2017 at 10:57 AM, Rik Cabanier <caba...@gmail.com> wrote:

On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.

One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.

CSS supports the transform syntax, so DOMMatrix has to support it as well.

That's not how Typed OM works. It represents transforms as an operation list:

https://drafts.css-houdini.org/css-typed-om-1/#transformvalue-objects

To parse to a transform list you'd use this API:

https://drafts.css-houdini.org/css-typed-om-1/#dom-cssstylevalue-parse

The only reason to support parsing of transform lists for CSSMatrix except for possibly backwards compatibility with WebKitCSSMatrix.

I'd prefer we didn't though and kept the parsing as a layer on top of these low level math types.

[Rik Cabanier]

On Mon, Mar 20, 2017 at 12:57 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Sat, Mar 18, 2017 at 10:57 AM, Rik Cabanier <caba...@gmail.com> wrote:

On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.

One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.

CSS supports the transform syntax, so DOMMatrix has to support it as well.

That's not how Typed OM works. It represents transforms as an operation list:

https://drafts.css-houdini.org/css-typed-om-1/#transformvalue-objects

To parse to a transform list you'd use this API:

https://drafts.css-houdini.org/css-typed-om-1/#dom-cssstylevalue-parse

I see.

That functionality wasn't specified when DOMMatrix was designed. I agree that it removes the original reason for supporting this constructor.

 

The only reason to support parsing of transform lists for CSSMatrix except for possibly backwards compatibility with WebKitCSSMatrix.

I'd prefer we didn't though and kept the parsing as a layer on top of these low level math types.

It's still valuable to parse a transform string directly into a matrix. I suspect that developers prefer the direct approach of the string, as opposed to going though the extra constructor of CSSStyleValue and all the checking

[Elliott Sprehn]

On Mon, Mar 20, 2017 at 1:25 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Mon, Mar 20, 2017 at 12:57 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Sat, Mar 18, 2017 at 10:57 AM, Rik Cabanier <caba...@gmail.com> wrote:

On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.

One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.

CSS supports the transform syntax, so DOMMatrix has to support it as well.

That's not how Typed OM works. It represents transforms as an operation list:

https://drafts.css-houdini.org/css-typed-om-1/#transformvalue-objects

To parse to a transform list you'd use this API:

https://drafts.css-houdini.org/css-typed-om-1/#dom-cssstylevalue-parse

I see.

That functionality wasn't specified when DOMMatrix was designed. I agree that it removes the original reason for supporting this constructor.

 

The only reason to support parsing of transform lists for CSSMatrix except for possibly backwards compatibility with WebKitCSSMatrix.

I'd prefer we didn't though and kept the parsing as a layer on top of these low level math types.

It's still valuable to parse a transform string directly into a matrix. I suspect that developers prefer the direct approach of the string, as opposed to going though the extra constructor of CSSStyleValue and all the checking

Why are they parsing the matrix from CSS syntax though? I'm curious what the use case is that isn't covered by typed om.

I don't think we should ship a CSS tokenizer and parser embedded in the platform's Matrix class. I think we should remove that constructor from whatever we ship in blink to start at least.

- E

[Rik Cabanier]

It would be for ease of use. I know I would use it since the CSS transform syntax makes a lot of sense and is easier to type than javascript functions.

Ideally, we should base this decision on developer feedback but if you feel strongly that this shouldn't be done for technical reasons, it can be removed.

[Philip Jägenstedt]

On Tue, Mar 21, 2017 at 4:58 AM Elliott Sprehn <esp...@chromium.org> wrote:

On Sat, Mar 18, 2017 at 10:57 AM, Rik Cabanier <caba...@gmail.com> wrote:

On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.

One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.

CSS supports the transform syntax, so DOMMatrix has to support it as well.

That's not how Typed OM works. It represents transforms as an operation list:

https://drafts.css-houdini.org/css-typed-om-1/#transformvalue-objects

To parse to a transform list you'd use this API:

https://drafts.css-houdini.org/css-typed-om-1/#dom-cssstylevalue-parse

The only reason to support parsing of transform lists for CSSMatrix except for possibly backwards compatibility with WebKitCSSMatrix.

Being able to alias WebKitCSSMatrix is IMHO the main reason to ship DOMMatrix at all. There isn't much chance of ever removing WebKitCSSMatrix, so would there be anything to gain by keeping the ugly parts of WebKitCSSMatrix out of DOMMatrix?

[Philip Jägenstedt]

Hi all,

What is the plan for ClientRect vs. DOMRect? It would make sense, I think, to try replacing use of ClientRect with DOMRect in the same milestone that ships DOMRect. Otherwise, we will simultaneously ship two rect interfaces and not be sure if we could reduce that to one interface again.

Similarly, I think that shipping DOMMatrix ought to be coupled with making it an alias of WebKitCSSMatrix. Does that make sense?

On Thu, Mar 9, 2017 at 2:57 AM xlai <xl...@chromium.org> wrote:

Contact emails

jinho...@samsung.com, caba...@adobe.com, dsch...@chromium.org, esp...@chromium.org,

chri...@chromium.org, p...@chromium.org

Spec

https://drafts.fxtf.org/geometry/

Summary

The specification provides basic geometric interfaces to represent points, rectangles,

quadrilaterals and transformation matrices that can be used by other modules or specifications.

We will ship following interfaces:

 - DOMMatrix and DOMMatrixReadOnly

 - DOMRect and DOMRectReadOnly

 - DOMQuad

 - DOMPoint and DOMPointReadOnly

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/V_bJNtOg0oM/lECG9SikFwEJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

http://test.csswg.org/suites/geometry-1_dev/nightly-unstable/html/toc.htm

More conformance tests will be followed up.

Debuggability

You can enable the geometry interfaces by passing "--enable-blink-features=GeometryInterfaces" to Chrome and try the constructors and functions of these interfaces.

Interoperability and Compatibility Risk

The specification has been proposed in 2013 and some browsers have shipped the interfaces since 2014, so generally the risk is low.

As the specification has undergone several changes (https://drafts.fxtf.org/geometry/#changes) since 2014, other browsers have not picked up the new constructors for

several ReadOnly interfaces yet; but such a non-interoperability will be short-termed as other browsers match the latest specification in the future.

Edge: No signals

Firefox: Shipped

Safari: Shipped

Web developers: Positive

OWP launch tracking bug

http://crbug.com/388780

Entry on the feature dashboard

http://www.chromestatus.com/features/6015941766807552

[Rik Cabanier]

On Mon, Mar 20, 2017 at 8:59 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Hi all,

What is the plan for ClientRect vs. DOMRect? It would make sense, I think, to try replacing use of ClientRect with DOMRect in the same milestone that ships DOMRect. Otherwise, we will simultaneously ship two rect interfaces and not be sure if we could reduce that to one interface again.

Similarly, I think that shipping DOMMatrix ought to be coupled with making it an alias of WebKitCSSMatrix. Does that make sense?

Would the advantage be that there will only ever be 1 matrix interface in the platform? If so, yes, that makes sense.

 

On Thu, Mar 9, 2017 at 2:57 AM xlai <xl...@chromium.org> wrote:

Contact emails

jinho...@samsung.com, cabanie...@adobe.com, dschulze@chromium.org, esprehn@chromium.org,

chri...@chromium.org, pdr@chromium.org

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

On Tue, Mar 21, 2017 at 2:35 PM Rik Cabanier <caba...@gmail.com> wrote:

On Mon, Mar 20, 2017 at 8:59 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Hi all,

What is the plan for ClientRect vs. DOMRect? It would make sense, I think, to try replacing use of ClientRect with DOMRect in the same milestone that ships DOMRect. Otherwise, we will simultaneously ship two rect interfaces and not be sure if we could reduce that to one interface again.

Similarly, I think that shipping DOMMatrix ought to be coupled with making it an alias of WebKitCSSMatrix. Does that make sense?

Would the advantage be that there will only ever be 1 matrix interface in the platform? If so, yes, that makes sense.

Right, I think we should avoid a situation where we hope to replace WebKitCSSMatrix with DOMMatrix, but fail to actually do so and end up with both in perpetuity. 

[Fredrik Söderquist]

There'd still be two (DOMMatrix and SVGMatrix[1]) though, so maybe you should phrase that as "one matrix interface per usage domain" (since AFAICS, WebKitCSSMatrix is only a "loose data type" ATM - i.e not used for data-exchange like SVGMatrix is.)

/fs

[1] SVGMatrix should be replaced by DOMMatrix, but that will need to be done in a reasonably "atomic" fashion. Probably while doing all the other SVG{Point,Rect,...} to DOM{Point,Rect,...} at the same time.

[Philip Jägenstedt]

Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.

Concretely, this is how I think we should ship the Geometry interfaces:

• Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.
• Exposing DOMRect* and making ClientRect* an alias of those.
• Exposing the other geometry interfaces at the same time that we ship some API that takes or returns one of those types.

It would be nice to do all of that in a single milestone, but not necessary.

xlai@, do you think doing it like this makes sense, or would you prefer another path?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jinho Bang]

2017년 3월 21일 화요일 오후 10시 10분 6초 UTC+9, Philip Jägenstedt 님의 말:

Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.

Concretely, this is how I think we should ship the Geometry interfaces:

• Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.
• Exposing DOMRect* and making ClientRect* an alias of those.
• Exposing the other geometry interfaces at the same time that we ship some API that takes or returns one of those types.

It would be nice to do all of that in a single milestone, but not necessary.

xlai@, do you think doing it like this makes sense, or would you prefer another path?

Hi Philip,

I totally agree with you :)

BTW, Have you already checked the current status shared by gogag2@ here?

 - https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/cAiTOdSGyes/XHJ28sJyBwAJ

The multiply() and inverse() doesn't be resolved yet.

Can we ignore them or do we have to change the geometry interface spec?

(I think they are edge cases but...)

[Philip Jägenstedt]

Thanks for pointing that out again.

I looked for sites using multiply() with no arguments and all I found was the string '.multiply()' inside documentation. In other words, that change has very little chance of breaking stuff in the wild.

For inverse(), there is no argument, so the question is if anything depends on the exception being thrown and would break when all the attributes are NaN instead. It's hard to guess, but in all likelihood it would be more risky to make the change in the other direction. Since Gecko already does the NaN thing, I think we should too.

What I'm still not clear about is DOMQuad and DOMPoint. Does it make sense to hold off on those until there are APIs using them, or does that become a different kind of mess?

[PhistucK]

The Chrome 58 beta blog post mentions -

"To improve JavaScript parsing time, SVGPoint, SVGRect, and SVGMatrix have been transferred to new interfaces outside of Geometry."

Looks like those were aliased (not transferred, unless "transferred" means "copied") and not outside of Geometry (what does that even mean? The specification? Some interface?), but into Geometry (the specification, as constructors with new names on the global object).

Is my understanding correct?

Also, it links to a blog post that, while mentioning some new implemented interfaces (DOMPoint, DOMQuad, DOMRect), it also mentions things that were not implemented (GeometryUtils, getBoxQuads) and can give the readers the wrong idea.

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Fredrik Söderquist]

On Tue, Mar 21, 2017 at 10:25 PM, PhistucK <phis...@gmail.com> wrote:

The Chrome 58 beta blog post mentions -

"To improve JavaScript parsing time, SVGPoint, SVGRect, and SVGMatrix have been transferred to new interfaces outside of Geometry."

Looks like those were aliased (not transferred, unless "transferred" means "copied") and not outside of Geometry (what does that even mean? The specification? Some interface?), but into Geometry (the specification, as constructors with new names on the global object).

Is my understanding correct?

Unfortunately none of that is correct =( (and even if the flag [1] was enabled it wouldn't be.) Any chance we could get that redacted? (I set the chromestatus entry back to "Behind a flag" for now.)

/fs

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5?type=cs&q=GeometryInterfaces+package:%5Echromium$&l=429

[Elliott Sprehn]

On Tue, Mar 21, 2017 at 6:09 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.

Concretely, this is how I think we should ship the Geometry interfaces:

• Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.

I would like to see us drop the CSS parsing from DOMMatrix to fix the layering and make the geometry types into a stand alone set of low level concepts.

To retain backwards compatibility for WebKitCSSMatrix we can introduce a separate constructor that takes a string and has the legacy behavior, just like we have Image(width, height) and HTMLImageElement.

There's no reason to ever ship WebKitCSSMatrix in workers or anywhere besides the main thread, and right now shipping DOMMatrix is implicitly shipping the CSS parser and tokenizer to background threads.

• Exposing DOMRect* and making ClientRect* an alias of those.
• Exposing the other geometry interfaces at the same time that we ship some API that takes or returns one of those types.

It would be nice to do all of that in a single milestone, but not necessary.

xlai@, do you think doing it like this makes sense, or would you prefer another path?

On Tue, Mar 21, 2017 at 8:41 PM Fredrik Söderquist <f...@opera.com> wrote:

On Tue, Mar 21, 2017 at 6:37 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Mar 21, 2017 at 2:35 PM Rik Cabanier <caba...@gmail.com> wrote:

On Mon, Mar 20, 2017 at 8:59 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Hi all,

What is the plan for ClientRect vs. DOMRect? It would make sense, I think, to try replacing use of ClientRect with DOMRect in the same milestone that ships DOMRect. Otherwise, we will simultaneously ship two rect interfaces and not be sure if we could reduce that to one interface again.

Similarly, I think that shipping DOMMatrix ought to be coupled with making it an alias of WebKitCSSMatrix. Does that make sense?

Would the advantage be that there will only ever be 1 matrix interface in the platform? If so, yes, that makes sense.

Right, I think we should avoid a situation where we hope to replace WebKitCSSMatrix with DOMMatrix, but fail to actually do so and end up with both in perpetuity. 

There'd still be two (DOMMatrix and SVGMatrix[1]) though, so maybe you should phrase that as "one matrix interface per usage domain" (since AFAICS, WebKitCSSMatrix is only a "loose data type" ATM - i.e not used for data-exchange like SVGMatrix is.)

/fs

[1] SVGMatrix should be replaced by DOMMatrix, but that will need to be done in a reasonably "atomic" fashion. Probably while doing all the other SVG{Point,Rect,...} to DOM{Point,Rect,...} at the same time.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Elliott Sprehn]

On Tue, Mar 21, 2017 at 5:32 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Mar 21, 2017 at 6:09 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.

Concretely, this is how I think we should ship the Geometry interfaces:

• Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.

I would like to see us drop the CSS parsing from DOMMatrix to fix the layering and make the geometry types into a stand alone set of low level concepts.

To retain backwards compatibility for WebKitCSSMatrix we can introduce a separate constructor that takes a string and has the legacy behavior, just like we have Image(width, height) and HTMLImageElement.

There's no reason to ever ship WebKitCSSMatrix in workers or anywhere besides the main thread, and right now shipping DOMMatrix is implicitly shipping the CSS parser and tokenizer to background threads.

I see also there's setMatrixValue, but looking internally and across github I can't really find usage. Did we UseCount the API here?

I see one for WebKitCSSMatrix itself, but not for any of the API surface.

[Rik Cabanier]

On Tue, Mar 21, 2017 at 5:32 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Mar 21, 2017 at 6:09 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.

Concretely, this is how I think we should ship the Geometry interfaces:

• Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.

I would like to see us drop the CSS parsing from DOMMatrix to fix the layering and make the geometry types into a stand alone set of low level concepts.

To retain backwards compatibility for WebKitCSSMatrix we can introduce a separate constructor that takes a string and has the legacy behavior, just like we have Image(width, height) and HTMLImageElement.

Would the only measurable side effect be that that constructor is not available in workers?

 

There's no reason to ever ship WebKitCSSMatrix in workers or anywhere besides the main thread, and right now shipping DOMMatrix is implicitly shipping the CSS parser and tokenizer to background threads.

Is that a problem?

It seems that this is another reason to support this constructor since CSSStyleValue is not supported in workers so you won't be able to parse a transform string there.

[Elliott Sprehn]

On Tue, Mar 21, 2017 at 7:41 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Tue, Mar 21, 2017 at 5:32 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Mar 21, 2017 at 6:09 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.

Concretely, this is how I think we should ship the Geometry interfaces:

• Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.

I would like to see us drop the CSS parsing from DOMMatrix to fix the layering and make the geometry types into a stand alone set of low level concepts.

To retain backwards compatibility for WebKitCSSMatrix we can introduce a separate constructor that takes a string and has the legacy behavior, just like we have Image(width, height) and HTMLImageElement.

Would the only measurable side effect be that that constructor is not available in workers?

It also avoids the unnecessary coupling in the codebase and makes more sense at the platform level.

 

 

There's no reason to ever ship WebKitCSSMatrix in workers or anywhere besides the main thread, and right now shipping DOMMatrix is implicitly shipping the CSS parser and tokenizer to background threads.

Is that a problem?

It seems that this is another reason to support this constructor since CSSStyleValue is not supported in workers so you won't be able to parse a transform string there.

 

If we want to expose the CSS parser inside workers we should do that, we shouldn't be coupling the CSS parser to the low level geometry types. Just like new Array() shouldn't parse JSON.

[Philip Jägenstedt]

On Wed, Mar 22, 2017 at 12:44 PM Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Mar 21, 2017 at 7:41 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Tue, Mar 21, 2017 at 5:32 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Mar 21, 2017 at 6:09 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.

Concretely, this is how I think we should ship the Geometry interfaces:

• Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.

I would like to see us drop the CSS parsing from DOMMatrix to fix the layering and make the geometry types into a stand alone set of low level concepts.

To retain backwards compatibility for WebKitCSSMatrix we can introduce a separate constructor that takes a string and has the legacy behavior, just like we have Image(width, height) and HTMLImageElement.

Would the only measurable side effect be that that constructor is not available in workers?

It also avoids the unnecessary coupling in the codebase and makes more sense at the platform level.

 

 

There's no reason to ever ship WebKitCSSMatrix in workers or anywhere besides the main thread, and right now shipping DOMMatrix is implicitly shipping the CSS parser and tokenizer to background threads.

Is that a problem?

It seems that this is another reason to support this constructor since CSSStyleValue is not supported in workers so you won't be able to parse a transform string there.

 

If we want to expose the CSS parser inside workers we should do that, we shouldn't be coupling the CSS parser to the low level geometry types. Just like new Array() shouldn't parse JSON.

I think that the strongest reason for shipping DOMMatrix with the string parsing intact is that Gecko has already shipped it:

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4961

In httparchive:har.2017_01_15_chrome_requests_bodies there are 571 hits for 'setMatrixValue', and most of them are various versions of this library:

http://animate.adobe.com/runtime/4.0.0/edge.4.0.0.min.js

(Not all are hosted at adobe.com, so Adobe alone can't fix the problem.)

b.CSSMatrix is set from window.WebKitCSSMatrix. I haven't tried stepping through the code, but it looks like it would break if we remove setMatrixValue().

To avoid having to parse this syntax in workers, how about we just add [Exposed=Window] to the setMatrixValue() method, and define the string variant of the constructor to throw TypeError if invoked in a worker?

That wouldn't address the layering concerns, but it seems too late for that, it's been like this on WebKitCSSMatrix since 2009 and Gecko's DOMMatrix since 2014.

[Philip Jägenstedt]

Elliott, any thoughts on the options here?

[Chris Harrelson]

There were several potential concerns I heard on this thread and some others. They included: (a) performance, (b) API layering, (c) compatibility with the existing matrix class, and (d) potential duplication or different implementation of geometric types in different places in various web APIs.

I think we need to put this intent on hold for a bit while these items are discussed some more. I will consult with the various people who have raised ideas or concerns, coordinate finding answers to these questions that we can get consensus on, and come back to this thread with the results.

Chris

--

[Rik Cabanier]

On Tue, Mar 28, 2017 at 9:23 AM, Chris Harrelson <chri...@chromium.org> wrote:

There were several potential concerns I heard on this thread and some others. They included: (a) performance, (b) API layering, (c) compatibility with the existing matrix class, and (d) potential duplication or different implementation of geometric types in different places in various web APIs.

I think we need to put this intent on hold for a bit while these items are discussed some more. I will consult with the various people who have raised ideas or concerns, coordinate finding answers to these questions that we can get consensus on, and come back to this thread with the results.

I'm unsure how much is left to discuss. 

Mozilla already implemented them and WebKit is in the process of adding them [1]

If Elliott has technical objections, he should file them.

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

[Chris Harrelson]

On Tue, Mar 28, 2017 at 4:32 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Tue, Mar 28, 2017 at 9:23 AM, Chris Harrelson <chri...@chromium.org> wrote:

There were several potential concerns I heard on this thread and some others. They included: (a) performance, (b) API layering, (c) compatibility with the existing matrix class, and (d) potential duplication or different implementation of geometric types in different places in various web APIs.

I think we need to put this intent on hold for a bit while these items are discussed some more. I will consult with the various people who have raised ideas or concerns, coordinate finding answers to these questions that we can get consensus on, and come back to this thread with the results.

I'm unsure how much is left to discuss. 

Mozilla already implemented them and WebKit is in the process of adding them [1]

It may be that this is the best thing to do at this point. However, for due diligence at least I would like to generate answers to all of the pending questions raised on various threads related to this Intent (within Google, though on public lists), and summarize them here, so that we can make the most informed decision possible. I'll also make sure to file spec issues as appropriate if there are any, and make sure you are in the loop as well.

(Note that I'm writing in my capacity as one helping to move along this intent itself, not as an API owner. I won't be acting as an API owner for this particular feature.)

[Philip Jägenstedt]

There is one part of this intent that I think should be entirely unproblematic, and that is replacing ClientRect* with DOMRect*.

Gecko seems to only expose the geometry APIs on Window. If we did the same, the DOMMatrix off-main-thread parsing problem would go away. The remaining issue with DOMMatrix would be that it does any parsing at all, but to make real progress on that we'd have to pry it out of WebKitCSSMatrix and convince Gecko to try the same for their DOMMatrix.

Elliott?

For DOMPoint and DOMQuad, I would prefer to ship those together with some API that makes use of them, is that on the horizon?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Elliott Sprehn]

On Thu, Mar 30, 2017 at 8:47 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

There is one part of this intent that I think should be entirely unproblematic, and that is replacing ClientRect* with DOMRect*.

Gecko seems to only expose the geometry APIs on Window. If we did the same, the DOMMatrix off-main-thread parsing problem would go away. The remaining issue with DOMMatrix would be that it does any parsing at all, but to make real progress on that we'd have to pry it out of WebKitCSSMatrix and convince Gecko to try the same for their DOMMatrix.

Elliott?

I'd much prefer we avoided coupling the Matrix type to the parser (for the reasons listed above and a few others that come from bringing in the whole CSS parser), that does make aliasing this hard of course so perhaps we just need to live with it. Certainly we need to fix the bug where the code is trying to use ComputedStyle from the wrong thread before shipping!

I also filed some bugs against the spec, having thought about integration with the various specs and existing ecosystem more I do wonder if exposing the matrix operations as something that takes a typed array is actually better since it composes with the existing WebGL API without having to go through 3 copies or a large spec retrofit, could be easily invoked from wasm, and similarly lets you use it with a SharedArrayBuffer in a simple way (though maybe that requires specing the order of operations to avoid exposing intermediate state? What does SAB say about concurrent writes/reads and consistency?).

I feel like I've communicated my concerns here and I defer to ikilpatrick@ about what he'd like to see the next steps be. I agree we need to make some progress, and I don't want perfect to be the enemy of good enough (though fwiw pulling the entire CSS parser into other threads is a big thing to couple with a geometry type...).

 

For DOMPoint and DOMQuad, I would prefer to ship those together with some API that makes use of them, is that on the horizon?

Custom layout or paint might want DOMPoint or DOMQuad, ikilpatrick@ would know more.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rik Cabanier]

On Mon, Apr 3, 2017 at 11:00 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Thu, Mar 30, 2017 at 8:47 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

There is one part of this intent that I think should be entirely unproblematic, and that is replacing ClientRect* with DOMRect*.

Gecko seems to only expose the geometry APIs on Window. If we did the same, the DOMMatrix off-main-thread parsing problem would go away. The remaining issue with DOMMatrix would be that it does any parsing at all, but to make real progress on that we'd have to pry it out of WebKitCSSMatrix and convince Gecko to try the same for their DOMMatrix.

Elliott?

I'd much prefer we avoided coupling the Matrix type to the parser (for the reasons listed above and a few others that come from bringing in the whole CSS parser), that does make aliasing this hard of course so perhaps we just need to live with it.

In a previous message, you mentioned that we could add a separate constructor that would only be available in the main thread, That might be a good compromise since there won't be css parsing in a worker and people will likely use this constructor on the main thread.

 

Certainly we need to fix the bug where the code is trying to use ComputedStyle from the wrong thread before shipping!

I agree.

 

I also filed some bugs against the spec, having thought about integration with the various specs and existing ecosystem more I do wonder if exposing the matrix operations as something that takes a typed array is actually better since it composes with the existing WebGL API without having to go through 3 copies or a large spec retrofit, could be easily invoked from wasm, and similarly lets you use it with a SharedArrayBuffer in a simple way (though maybe that requires specing the order of operations to avoid exposing intermediate state? What does SAB say about concurrent writes/reads and consistency?).

We tried to make DOMMatrix palatable to all people by providing low level constructors and attributes for arrays and high level matrix functions. The interface caters to easy of use and not high performance.

We discussed a similar proposal to yours a couple of years ago and the conclusion was that people that use array buffers, likely want to use their own library so there would be little upside of having built-in matrix operators.

[Elliott Sprehn]

On Wed, Apr 5, 2017 at 8:08 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Mon, Apr 3, 2017 at 11:00 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Thu, Mar 30, 2017 at 8:47 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

There is one part of this intent that I think should be entirely unproblematic, and that is replacing ClientRect* with DOMRect*.

Gecko seems to only expose the geometry APIs on Window. If we did the same, the DOMMatrix off-main-thread parsing problem would go away. The remaining issue with DOMMatrix would be that it does any parsing at all, but to make real progress on that we'd have to pry it out of WebKitCSSMatrix and convince Gecko to try the same for their DOMMatrix.

Elliott?

I'd much prefer we avoided coupling the Matrix type to the parser (for the reasons listed above and a few others that come from bringing in the whole CSS parser), that does make aliasing this hard of course so perhaps we just need to live with it.

In a previous message, you mentioned that we could add a separate constructor that would only be available in the main thread, That might be a good compromise since there won't be css parsing in a worker and people will likely use this constructor on the main thread.

 

Certainly we need to fix the bug where the code is trying to use ComputedStyle from the wrong thread before shipping!

I agree.

 

I also filed some bugs against the spec, having thought about integration with the various specs and existing ecosystem more I do wonder if exposing the matrix operations as something that takes a typed array is actually better since it composes with the existing WebGL API without having to go through 3 copies or a large spec retrofit, could be easily invoked from wasm, and similarly lets you use it with a SharedArrayBuffer in a simple way (though maybe that requires specing the order of operations to avoid exposing intermediate state? What does SAB say about concurrent writes/reads and consistency?).

We tried to make DOMMatrix palatable to all people by providing low level constructors and attributes for arrays and high level matrix functions. The interface caters to easy of use and not high performance.

We discussed a similar proposal to yours a couple of years ago and the conclusion was that people that use array buffers, likely want to use their own library so there would be little upside of having built-in matrix operators.

The upsides are:

- Fewer bytes over the wire since you don't need to send a whole geometry library.

- Can use SSE and Neon to be faster.

I also want to challenge the idea that good ergonomics and performance are mutually exclusive. I don't believe we should ship things that are designed to be "easy but slow".

[Rik Cabanier]

On Wed, Apr 5, 2017 at 8:44 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Wed, Apr 5, 2017 at 8:08 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Mon, Apr 3, 2017 at 11:00 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Thu, Mar 30, 2017 at 8:47 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

There is one part of this intent that I think should be entirely unproblematic, and that is replacing ClientRect* with DOMRect*.

Gecko seems to only expose the geometry APIs on Window. If we did the same, the DOMMatrix off-main-thread parsing problem would go away. The remaining issue with DOMMatrix would be that it does any parsing at all, but to make real progress on that we'd have to pry it out of WebKitCSSMatrix and convince Gecko to try the same for their DOMMatrix.

Elliott?

I'd much prefer we avoided coupling the Matrix type to the parser (for the reasons listed above and a few others that come from bringing in the whole CSS parser), that does make aliasing this hard of course so perhaps we just need to live with it.

In a previous message, you mentioned that we could add a separate constructor that would only be available in the main thread, That might be a good compromise since there won't be css parsing in a worker and people will likely use this constructor on the main thread.

 

Certainly we need to fix the bug where the code is trying to use ComputedStyle from the wrong thread before shipping!

I agree.

 

I also filed some bugs against the spec, having thought about integration with the various specs and existing ecosystem more I do wonder if exposing the matrix operations as something that takes a typed array is actually better since it composes with the existing WebGL API without having to go through 3 copies or a large spec retrofit, could be easily invoked from wasm, and similarly lets you use it with a SharedArrayBuffer in a simple way (though maybe that requires specing the order of operations to avoid exposing intermediate state? What does SAB say about concurrent writes/reads and consistency?).

We tried to make DOMMatrix palatable to all people by providing low level constructors and attributes for arrays and high level matrix functions. The interface caters to easy of use and not high performance.

We discussed a similar proposal to yours a couple of years ago and the conclusion was that people that use array buffers, likely want to use their own library so there would be little upside of having built-in matrix operators.

The upsides are:

- Fewer bytes over the wire since you don't need to send a whole geometry library.

- Can use SSE and Neon to be faster.

I also want to challenge the idea that good ergonomics and performance are mutually exclusive. I don't believe we should ship things that are designed to be "easy but slow".

DOMMatrix certainly isn't slow; it's just not as fast as a raw array buffer. It will be leaps faster than the current approach of constant stringification and parsing of transform strings.

As engineers, we're used to dealing with opaque arrays but they're not friendly for web developers.

[Dimitri Glazkov]

Folks, as a meta-point: I see y'all having what looks like a design discussion on the intent to ship for and I am worried: 1) it seems pretty late in the process to have a discussion of this kind, and 2) blink-dev is a Chromium's web platform implementation mailing list, rather than a more inclusive W3C list. Would y'all consider gathering the stakeholders,  sync-ing up offline on the course of action and come back with a clear resolution?

:DG<

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

On Thu, Apr 6, 2017 at 9:20 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

Folks, as a meta-point: I see y'all having what looks like a design discussion on the intent to ship for and I am worried: 1) it seems pretty late in the process to have a discussion of this kind, and 2) blink-dev is a Chromium's web platform implementation mailing list, rather than a more inclusive W3C list. Would y'all consider gathering the stakeholders,  sync-ing up offline on the course of action and come back with a clear resolution?

FYI I mentioned this a few messages back, and am currently working on just what you suggested. Will report back soon.

 

:DG<

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dimitri Glazkov]

\o/

 

:DG<

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

Hi all,

As promised, I wrote up a doc and contacted many of the people on this thread for feedback. Sorry for the delay.

A summary of proposed actions is below.

For M60, I propose shipping the following:

1. Ship DOMMatrix as-is, but *without* setMatrixValue.

2. Make WebkitCSSMatrix an exact alias of DOMMatrix.

I have added the following use-counters and merged them into M58 beta:

WebkitCSSMatrixSetMatrixValue. M58 beta channel data indicates this occurs on ~0.0067% of page visits

WebkitCSSMatrixConstructFromString. M58 beta channel also indicates that this occurs on ~1.1% of page visits

Unfortunately, the use-counter data does not support removing the DOMMatrix constructor from a string, based on beta channel data. If the stable channel for M58 disagrees, we can revisit.

Furthermore, we can, in the future, ship DOMMatrix in workers with the omission of the constructor from CSS text. It's a little gross, but I can't see a better way forward given the UseCounter data.

We could perhaps instead ship DOMMatrix with one fewer constructor than WebkitCSSMatrix, but that also seems gross?

Finally, I believe there is also a reasonable story (see the referenced document) for adding a typed array version of DOMMatrix in the future, which makes this launch reasonably future-compatible.

Chris

...

[Message clipped]  

[Philip Jägenstedt]

A very helpful writeup, and illuminating use counters, thanks Chris!

It looks like the WebKitCSSMatrix(string) constructor stands in the way of really splitting WebKitCSSMatrix from CSS parsing. I looked for "new WebKitCSSMatrix(" in httparchive, 5843 hits. It looks like the most common thing was this: 

https://github.com/nolimits4web/Swiper/blob/d9f17789d48a514f63e9d3aef89cfcf121a1536e/src/js/core.js#L2243

This uses getComputedStyle(el).transform/webkitTransform as the input, and so presumably will break. Another similar and frequent pattern was `new WebKitCSSMatrix(window.getComputedStyle(e).webkitTransform)`.

That combined with Edge's support of the string constructor suggests that the compat constraint is real, and that it'd be a serious undertaking to get rid of it. For the purposes of this intent, I think we should accept it and assume it will not go away.

With that starting point, getting rid of just setMatrixValue does not fix the layering problems, so although the risk is lower, I wonder if it's really worth trying to remove it?

I've commented on https://github.com/w3c/fxtf-drafts/issues/122#issuecomment-296997884 about how we could limit the parsing to the main thread, would that be a good-enough compromise?

[Chris Harrelson]

On Tue, Apr 25, 2017 at 6:10 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

A very helpful writeup, and illuminating use counters, thanks Chris!

It looks like the WebKitCSSMatrix(string) constructor stands in the way of really splitting WebKitCSSMatrix from CSS parsing. I looked for "new WebKitCSSMatrix(" in httparchive, 5843 hits. It looks like the most common thing was this: 

https://github.com/nolimits4web/Swiper/blob/d9f17789d48a514f63e9d3aef89cfcf121a1536e/src/js/core.js#L2243

This uses getComputedStyle(el).transform/webkitTransform as the input, and so presumably will break. Another similar and frequent pattern was `new WebKitCSSMatrix(window.getComputedStyle(e).webkitTransform)`.

That combined with Edge's support of the string constructor suggests that the compat constraint is real, and that it'd be a serious undertaking to get rid of it. For the purposes of this intent, I think we should accept it and assume it will not go away.

With that starting point, getting rid of just setMatrixValue does not fix the layering problems, so although the risk is lower, I wonder if it's really worth trying to remove it?

You make a reasonable point. I think leaving setMatrixValue and limiting to the main thread would be an ok compromise given the compatibility situation.

Given that, LGTY?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

On Tue, Apr 25, 2017 at 11:25 PM Chris Harrelson <chri...@chromium.org> wrote:

On Tue, Apr 25, 2017 at 6:10 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

A very helpful writeup, and illuminating use counters, thanks Chris!

It looks like the WebKitCSSMatrix(string) constructor stands in the way of really splitting WebKitCSSMatrix from CSS parsing. I looked for "new WebKitCSSMatrix(" in httparchive, 5843 hits. It looks like the most common thing was this: 

https://github.com/nolimits4web/Swiper/blob/d9f17789d48a514f63e9d3aef89cfcf121a1536e/src/js/core.js#L2243

This uses getComputedStyle(el).transform/webkitTransform as the input, and so presumably will break. Another similar and frequent pattern was `new WebKitCSSMatrix(window.getComputedStyle(e).webkitTransform)`.

That combined with Edge's support of the string constructor suggests that the compat constraint is real, and that it'd be a serious undertaking to get rid of it. For the purposes of this intent, I think we should accept it and assume it will not go away.

With that starting point, getting rid of just setMatrixValue does not fix the layering problems, so although the risk is lower, I wonder if it's really worth trying to remove it?

You make a reasonable point. I think leaving setMatrixValue and limiting to the main thread would be an ok compromise given the compatibility situation.

Given that, LGTY?

 

Yes, that would minimize compat and interop risk, so I'd be on board with that. The layering would remain odd forever, though.

(Earlier in the thread I mentioned the option of, effectively, [Exposed=Window] for all of these interfaces, but I don't see much reason to do that unless those working on the implementation would prefer it.)

At this point, there are a few issues in https://github.com/w3c/fxtf-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20geometry that ought to be resolved, in particular #122 in some way. #55, the test for that, #120 and #124 are also worth a look, but not blocking if we're already matching Gecko for those things.

xlai@ et al., do you feel like you have clarity in what spec and implementation changes need to happen to finally get this out the door?

[Joseph Orbegoso Pea]

Why does `setMatrixValue` not accept an array of numbers? converting strings to numbers is expensive compared to passing number directly. Let's change that.

Being able to pass a CSS transformList is *currently* convenient because one might like to get a DOM element from the DOM, and create a numerical matrix from it's CSS transform value.

But with that said, the CSSOM should just provide a way to get and set the numerical DOMMatrix of an HTMLElement anyway. And in this case, CSS transformList is not needed anywhere in the DOMMatrix spec. This would be best for performance, which we should aim for.

On Saturday, March 18, 2017 at 7:59:17 AM UTC-7, Elliott Sprehn wrote:

I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.

On Sat, Mar 18, 2017 at 5:17 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 3/17/17 1:14 PM, Rik Cabanier wrote:

Can that be done later, or will that move have other subtle side effects?

Moving from an overload set where all overloads have one argument, with one of them possibly optional, to a single overload with a single possibly optional union should not have caller-observable effects.  If it does, that's a bug in the webidl spec which we should fix forthwith.

I'm not aware of such bugs at the present time, though they have existed in the past (e.g. <https://github.com/heycam/webidl/issues/123>).

-Boris

[Joseph Orbegoso Pea]

On Monday, March 20, 2017 at 1:25:10 PM UTC-7, Rik Cabanier wrote:

On Mon, Mar 20, 2017 at 12:57 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Sat, Mar 18, 2017 at 10:57 AM, Rik Cabanier <caba...@gmail.com> wrote:

On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.

One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.

CSS supports the transform syntax, so DOMMatrix has to support it as well.

That's not how Typed OM works. It represents transforms as an operation list:

https://drafts.css-houdini.org/css-typed-om-1/#transformvalue-objects

To parse to a transform list you'd use this API:

https://drafts.css-houdini.org/css-typed-om-1/#dom-cssstylevalue-parse

I see.

That functionality wasn't specified when DOMMatrix was designed. I agree that it removes the original reason for supporting this constructor.

 

The only reason to support parsing of transform lists for CSSMatrix except for possibly backwards compatibility with WebKitCSSMatrix.

I'd prefer we didn't though and kept the parsing as a layer on top of these low level math types.

It's still valuable to parse a transform string directly into a matrix. I suspect that developers prefer the direct approach of the string, as opposed to going though the extra constructor of CSSStyleValue and all the checking

I much prefer being able to get or set a DOM matrix to/from a DOM element without ever touching a CSS string. DOM is already slow enough, let's try to make it faster.

[Joseph Orbegoso Pea]

On Tuesday, April 18, 2017 at 2:01:26 PM UTC-7, Chris Harrelson wrote:

Hi all,

As promised, I wrote up a doc and contacted many of the people on this thread for feedback. Sorry for the delay.

A summary of proposed actions is below.

For M60, I propose shipping the following:

1. Ship DOMMatrix as-is, but *without* setMatrixValue.

matrix.setValue([1,2,3,4,5, ...]) // iwhtout redundant extra "matrix" word

is easier than

matrix.m11 = 1

matrix.m12 = 2

matrix.m13 = 3

matrix.m14 = 4

matrix.m21 = 5

 

\o/

 

:DG<

<div class="m_3562094609087605155m_-1457832378083732814m_-6494700340715770940m_-5004652172647091950m_-7259415047987974766m_-3211645023326551307m_-766980658197

[xlai]

Based on the discussion so far, I think we should ship geometry interfaces after the following to-do items are cleared:

1. As chrishtr@ suggested, make WebkitCSSMatrix an exact alias of DOMMatrix.

    The issue (crbug.com/581955) is currently started and an implementation CL is in progress.

2. Avoid overloading constructors for DOMMatrix/DOMMatrixReadOnly.

     In the spec pull request #135, the discussion has been gone to that we should use Union for the constructors; reviewing is going on. We should follow with an implementation change after #135 is fixed.

3. Make DOMMatrix not depend on the CSS parser

     This is discussed in the spec pull request #122. Whilst quite a few people agree on this, we do not have sufficient user usage to support the decision.

     At the current state we've come to a conclusion that we want to ship DOMMatrix first in order to gather more user counter statistics that chrishtr@ has added (WebkitCSSMatrixConstructFromString, WebkitCSSMatrixSetMatrixValue). However, we do not want to expose the string-based DOMMatrix constructor and the setMatrixValue function to Worker yet.

4. Spec/Implementation mismatch on Stringifier

    This is an implementation-wise task mentioned in the spec pull request #120. gogag1@ already have a CL in progress.

5. "None"/"undefined" argument in the DOMMatrix/DOMMatrixReadOnly constructor

    This is mentioned in both spec pull request #55 and spec pull request #351 (as well as discussion in chrishtr@'s doc). There is an open task to add web-platform-tests for new DOMMatrix('none'). Other than that, code implementation should follow as well.

6. Web platform tests for geometry interfaces

    Currently, hs1217.lee@ is actively working on the issue. After the conformance tests are updated, we should make sure that they all passed in Chrome.

There are still quite a few other to-do items for the geometry interfaces (e.g. remaining spec git pull requests, performance issue, etc). But to make things simple, I think only the above items should be considered as "blocking" to shipping this.

If there is anything I miss in the list, please comment.

[/#!/JoePea]

On Thu, Apr 27, 2017 at 12:51 PM, xlai <xl...@chromium.org> wrote:

Make DOMMatrix not depend on the CSS parser

​It would be sweet for CSS APIs to instead return a DOMMatrix when requested.

/#!/JoePea

[Chris Harrelson]

Hi Joe,

This is indeed planned as part of typed CSSOM (some links at the end of this document).

More generally, feature requests or discussions for future work should happen on the bug tracker for the standard. Let's keep this thread focused on whether to ship the current feature.

/#!/JoePea

[Rick Byers]

Man, this is a messy one for sure (sorry for the delay - took me quite a while to get caught up on all the discussion).

Given the compat constraints, this plan sounds pragmatic to me (making WebkitCSSMatrix an alias for DOMMatrix is a big win IMHO).  LGTM3 to the below plan.

foolip@ any concerns with this plan?

jochen/dglazkov@ let us know ASAP if any of the changes in this thread have invalidated your prior LGTM (otherwise we should assume it still stands I think).

[Jochen Eisinger]

my lgtm still stands

[Justin Novosad]

FYI: With xlai@ on leave, fserb@ has accepted to take ownership of this intent to ship and will follow the plan outlined by xlai@ in this thread.

[Philip Jägenstedt]

Just to make it explicit, the 6-point plan LGTM, thanks for your patience, everyone!

[Simon Pieters]

On Fri, 05 May 2017 15:24:09 +0200, Philip Jägenstedt
<foo...@chromium.org> wrote:

> Just to make it explicit, the 6-point plan LGTM, thanks for your
> patience,
> everyone!

An update on the progress on these issues... Right now (1), (3) and (4)
are still open, but almost there! Thanks everyone involved!

>>>> On Thu, Apr 27, 2017 at 3:51 PM, xlai <xl...@chromium.org> wrote:
>>>>
>>>>> Based on the discussion so far, I think we should ship geometry
>>>>> interfaces after the following to-do items are cleared:
>>>>>

>>>>> *1. As chrishtr@ suggested, make WebkitCSSMatrix an exact alias of
>>>>> DOMMatrix.*

>>>>> The issue (crbug.com/581955) is currently started and an

>>>>> implementation CL <https://codereview.chromium.org/2709763004/> is in
>>>>> progress.

I think this one is basically ready to land.

There is more work to do on the spec side with adding WebIDL syntax for
aliases and testing it in idlharness.js, and updating the relevant specs
to use the the new syntax. But I think that shouldn't block
WebKitCSSMatrix since the end result is the same.

https://github.com/heycam/webidl/issues/362
https://github.com/heycam/webidl/pull/364


>>>>> *2. Avoid overloading constructors for DOMMatrix/DOMMatrixReadOnly.*

>>>>> In the spec pull request #135

>>>>> <https://github.com/w3c/fxtf-drafts/issues/135>, the discussion has

>>>>> been gone to that we should use Union for the constructors;
>>>>> reviewing is
>>>>> going on. We should follow with an implementation change after #135
>>>>> is
>>>>> fixed.

The spec is fixed, tests added to WPT, and implementation has landed.

https://github.com/w3c/fxtf-drafts/pull/136
https://github.com/w3c/web-platform-tests/pull/5719
https://codereview.chromium.org/2859293002


>>>>> *3. Make DOMMatrix not depend on the CSS parser*

>>>>> This is discussed in the spec pull request #122

>>>>> <https://github.com/w3c/fxtf-drafts/issues/122>. Whilst quite a few

>>>>> people agree on this, we do not have sufficient user usage to
>>>>> support the
>>>>> decision.
>>>>> At the current state we've come to a conclusion that we want to
>>>>> ship DOMMatrix first in order to gather more user counter statistics
>>>>> that
>>>>> chrishtr@ has added (WebkitCSSMatrixConstructFromString

>>>>> <https://www.chromestatus.com/metrics/feature/popularity#WebkitCSSMatrixConstructFromString>
>>>>> , WebkitCSSMatrixSetMatrixValue
>>>>> <https://www.chromestatus.com/metrics/feature/popularity#WebkitCSSMatrixSetMatrixValue>).

>>>>> However, we do not want to expose the string-based DOMMatrix
>>>>> constructor

>>>>> <https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/geometry/DOMMatrix.idl?l=15>
>>>>> and the setMatrixValue
>>>>> <https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/geometry/DOMMatrix.idl?l=73>
>>>>> function
>>>>> to Worker yet.

The spec is fixed, tests added to WPT. Not yet implemented.

https://github.com/w3c/fxtf-drafts/pull/141
https://github.com/w3c/web-platform-tests/pull/5769
https://bugs.chromium.org/p/chromium/issues/detail?id=722305


>>>>> *4. Spec/Implementation mismatch on Stringifier*

>>>>> This is an implementation-wise task mentioned in the spec pull

>>>>> request #120 <https://github.com/w3c/fxtf-drafts/issues/120>. gogag1@

>>>>> already have a CL in progress.

After discussion with CSS WG this was resolved to throw if any values are
non-finite. Spec has been fixed and new tests added to wpt. The CL is just
missing the throwing for non-finite I believe.

https://github.com/w3c/fxtf-drafts/pull/148
https://github.com/w3c/web-platform-tests/pull/5885
https://codereview.chromium.org/2846523002/


>>>>> *5. "None"/"undefined" argument in the DOMMatrix/DOMMatrixReadOnly
>>>>> constructor*

>>>>> This is mentioned in both spec pull request #55

>>>>> <https://github.com/w3c/fxtf-drafts/issues/55> and spec pull request
>>>>> #351 <https://github.com/heycam/webidl/issues/351> (as well as
>>>>> discussion
>>>>> <https://docs.google.com/document/d/1khotobXxQJX72vVF4Z_pd9G10tKIB0lDQJBB5j4o15U/edit?disco=AAAABI0Gj50>

>>>>> in chrishtr@'s doc). There is an open task to add web-platform-tests
>>>>> for new DOMMatrix('none'). Other than that, code implementation
>>>>> should
>>>>> follow as well.

The spec is fixed, tests added to WPT, and implementation was already
correct.

https://github.com/w3c/fxtf-drafts/issues/55
https://github.com/w3c/csswg-test/issues/1173


>>>>> *6. Web platform tests for geometry interfaces*

>>>>> Currently, hs1217.lee@ is actively working on the issue

>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=699610>. After

>>>>> the conformance tests are updated, we should make sure that they all
>>>>> passed
>>>>> in Chrome.

This bug is resolved fixed.

>>>>> There are still quite a few other to-do items for the geometry
>>>>> interfaces (e.g. remaining spec git pull requests, performance
>>>>> issue, etc).
>>>>> But to make things simple, I think only the above items should be
>>>>> considered as "blocking" to shipping this.
>>>>>
>>>>> If there is anything I miss in the list, please comment.

cheers
--
Simon Pieters
Opera Software

[Fernando Serboncini]

Just one thing, regrading #3. I don't think that's this, but maybe I missed something.

#3 was http://crbug.com/703908, right? Which we fixed by conforming to spec and not allowing the CSS parser on Workers.

There's also this spin off: https://github.com/modating to what we currently have, i.e., depend on CSS parser not SVG parser).w3c/fxtf-drafts/issues/149 (this is basically accommodating to what we currently have, i.e., depend on CSS parser not SVG parser!).

The related thing that you point out, i.e., stringifier, is not even implemented, afaik. The WPT tests just got in today for that, but if I understood correctly this was not on the original list of issues.

I'm considering all those new compatibility bugs being issued to not be on the critical path for launching Geometry Interfaces. I.E., having lower priority than the 6 items on this list. Also, a lot of them don't even have proper (or just got) WPT tests yet. I'd rather ship this and work on the compatibility bugs later, but we could talk about it. :)

[Simon Pieters]

Ah yes, you're correct, (3) is implemented. Sorry, got a related issue mixed up! I agree issues not in this list shouldn't block shipping.

SVG parser vs CSS parser would be good to resolve, it basically amounts to the Gecko implementation to align with Chromium (and WebKit's WebKitCSSMatrix; unsure what Edge does). The spec PR and WPT PR for that is awaiting review.

--
Simon Pieters
Opera Software

[PhistucK]

From the latest Safari preview release notes -

• Added support for DOMMatrix and DOMMatrixReadOnly (r216959)

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUichEB%3D8Z%3DU7_3nN%3DS5NgQRuVRE6XwSb4ApAiC5mpQ3iY8ww%40mail.gmail.com.

[Fernando Serboncini]

The last CL needed for this (WebkitCSSMatrix alias) has landed today.

All the depending bugs on http://crbug.com/388780 have been fixed.

It seems that our list of requirements have been met and we are ready to ship.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

Great! Thanks for pushing this through. Let ship it. You have all the needed approvals.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUichEB%3D8Z%3DU7_3nN%3DS5NgQRuVRE6XwSb4ApAiC5mpQ3iY8ww%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADp2-T_d%2BH2XvQz1Q-xEhVag%2Bshisak2qztS0k%2Btp29Ur2B1pA%40mail.gmail.com.

[Jinho Bang]

FYI, the landed CL[1] breaks existing web. So, I reverted the CL[2]

The original CL[1] replaced existing WebKitCSSMatrix implementation with DOMMatrix implementation.

But DOMMatrix was not enabled yet in there. So, after the CL, WebKitCSSMatrix didn't work well.

For example,

// Before the CL,

var matrix = new WebKitCSSMatrix();

matrix.inverse();   // It works well.

// After the CL,

var matrix = new WebKitCSSMatrix();

matrix.inverse();   // It doesn't work well.

Anyway, I'm trying to reland it with shipping GeometryInterface now[3].

[1] https://codereview.chromium.org/2709763004/

[2] https://codereview.chromium.org/2943213002/

[3] https://codereview.chromium.org/2938413005/

2017년 6월 15일 목요일 오전 6시 51분 14초 UTC+9, Chris Harrelson 님의 말:

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUichEB%3D8Z%3DU7_3nN%3DS5NgQRuVRE6XwSb4ApAiC5mpQ3iY8ww%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[maksimk...@gmail.com]

Мне бы хотелось получить на русском языке

[Fernando Serboncini]

I don't know if this requires a separate Intent email, but I've decided to FYI here instead.

I've prepared CL: https://chromium-review.googlesource.com/c/559978/

to replace ClientRect/ClientRectList with DOMRect/DOMRectList.

The reason we still need DOMRectList (instead of sequence<DOMRect>) is that there's code in the wild that expects '.item()'. So we have this legacy interface that won't be directly exposed, but it's returned by get*ClientRects functions. This has been spec'ed out (although not 100% it has been submitted yet).

If this needs a separate email, let me know. Otherwise, it's FYI.

[Christian Biesinger]

Removing an existing interface should require a new intent, IMO,
considering that it can easily break existing websites (who may use
instanceof or constructors).

Christian

On Thu, Jul 6, 2017 at 11:24 AM, 'Fernando Serboncini' via blink-dev

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADp2-T-7hLro84E-D2_b1q9WCnf%3DcEdQYyb52pgA76Y%3DanCGxA%40mail.gmail.com.

[Philip Jägenstedt]

There is indeed a bit of risk with removing ClientRect/ClientRectList, that Gecko doesn't have either doesn't mean that it's necessarily safe. I searched for 'ClientRect.prototype' and 'ClientRectList.prototype' in httparchive:har.2017_07_15_chrome_requests_bodies, and only found one instance on boxy-svg.com. That used ClientRect.prototype and I've emailed the maintainer saying that it'll break.

There are other ways of depending on ClientRect* as well, and some more research would be in order.

fserb@, sorry we didn't suggest this from the beginning, but would you mind sending an intent for ClientRect(List) for visibility and as a place to discuss this? If it's looking risky, then an option is to add ClientRect* back as aliases of DOMRect*.

[Simon Pieters]

On Fri, 04 Aug 2017 17:56:53 +0200, Philip Jägenstedt
<foo...@chromium.org> wrote:

> There is indeed a bit of risk with removing ClientRect/ClientRectList,
> that
> Gecko doesn't have either doesn't mean that it's necessarily safe. I
> searched for 'ClientRect.prototype' and 'ClientRectList.prototype'
> in httparchive:har.2017_07_15_chrome_requests_bodies, and only found one
> instance on boxy-svg.com. That used ClientRect.prototype and I've emailed
> the maintainer saying that it'll break.
>
> There are other ways of depending on ClientRect* as well, and some more
> research would be in order.
>
> fserb@, sorry we didn't suggest this from the beginning, but would you
> mind
> sending an intent for ClientRect(List) for visibility and as a place to
> discuss this? If it's looking risky, then an option is to add ClientRect*
> back as aliases of DOMRect*.

I did some analysis for ClientRect in
https://github.com/w3c/fxtf-drafts/issues/163#issuecomment-302332055

Conclusion there was "I think we should try not having a ClientRect
alias.".

[Chris Harrelson]

To close off the thread (unless there is other API owner disagreement): LGTM to go forward with the removal of ClientRect, given the supporting research from Simon.

Note that the change which implements it is in Chrome 61 beta.