Re: Intent to unship SVGZoomAndPan interface

[Boris Zbarsky]

On 9/28/19 11:41 PM, Cameron McCormack wrote:

Both Chrome and Safari still implement the zoomAndPan IDL attribute.  The actual 
functionality behind the zoomAndPan="" attribute was never implemented in any 
browser.


Ah, ok.  In that case, removing seems pretty reasonable.


It would be good to have a historical test to ensure the property is gone, too, 
not just the SVGZoomAndPan interface.


Yes, please.

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [blink-dev] Re: What to do about scroll anchoring?

[Emilio Cobos Álvarez]

On 9/29/19 5:07 AM, Rick Byers wrote:
On Fri, Sep 27, 2019 at 10:16 AM Emilio Cobos Álvarez 
mailto:emi...@mozilla.com>> wrote:


Hi Steve,

On 9/27/19 4:03 PM, Steve Kobes wrote:
 > Hi Emilio,
 >
 > My recollection is that scroll anchoring was, in fact, a mess.  I
do not
 > personally have any opinion about whether scroll anchoring should be
 > removed from Gecko.
 >
 > We (Chrome) decided to accept some compat issues for the sake of
 > launching the feature.  This was a judgment call and could
reasonably
 > have gone the other way.

Right, my concern is that taking compat fallout with Chrome's market
share may be acceptable, because people will likely fix their websites
if they misbehave.

But web developers may not take the same time to fix their site if it's
broken on Firefox for Android, for example, which in turn drives
Firefox
users away (and you know this is a vicious cycle, the less users you
have, the less people will care about fixing their websites in your
browser).

That being said, more generally, I care about being interoperable /
predictable here for web developers, and seems like that ship may have
sailed if we need to fix some Gecko-specific issues by tweaking our
heuristics, but Chromium / Blink doesn't change them in the same way
(which is understandable, I guess, though I've filed spec issues for
our
reasoning behind these changes, which I think would apply to Chrome as
well).


FWIW, I agree with this principle. I'm sorry you've had to do a lot of 
compat work on this Emilio. Are you saying you've found many cases where 
chromium's behavior doesn't match the spec / web-platform-tests and the 
different is relevant to real-world website compat (forcing you to 
invest in "bug-for-bug compatibility")? That would definitely make me 
very sad. Or is the issue more about compat with sites which have 
UA-conditional behavior (either explicit or implicit based on some other 
Gecko/blink difference?).


Well, part of it is that. The initial implementation took a lot of just 
figuring out what Chromium was doing rather than implementing the spec, 
because the spec had clear issues (like referencing the DOM rather than 
layout stuff).


Some of them like [1] were pretty obvious and were caught during our 
initial implementation of the feature. Others like [2] Ryan probably 
found by testing Chromium's behavior.


Some other still pretty significant behavior differences were only 
caught later by me and people finding compat issues in the wild, like 
[3]. I was sad that the spec reflected absolutely nothing like what 
Blink implements. For this issue in particular, Blink roughly uses 
"whatever inherits from LayoutBox can be an anchor", which is obviously 
not something that you can reasonably spec, and definitely not "block 
boxes and text", which is what the spec said.


Those are off the top of my head, Ryan probably has more examples.

IMHO In general, either an initially chromium-only feature is valuable 
enough that we should continue to invest as necessary to achieve interop 
with other engines when they implement (eg. adding web-platform-tests 
and improving the spec for the inevitable cases that appear with a 
second implementation), or we should decide the feature isn't worth the 
cost to properly support on the web at large and remove it from chromium.


Steve is the expert and can probably elaborate on details, but IIRC the 
real world web compat constraints of scroll anchoring ended up requiring 
a number of tough tradeoffs. If you're learning about new web compat 
constraints, then it's entirely possible that the cost/benefit equation 
is now different and we should be re-evaluating whether it still makes 
sense to keep scroll anchoring in chromium. Like David I like the 
feature - but only to the extent that it works alright for most of the 
web as it exists today, and developers can reliably reason about it (eg. 
by replacing any heuristics designed under the constraints of web-compat 
with explicit APIs).


Can you give us a week or so to chat about this within the Chrome team 
and get back to you?


Thanks, and sorry again for the frustration. When we ship a feature 
first in chromium, it's always our intent that subsequent compatible 
implementations should be MUCH easier to ship (it's one of the main 
reasons we invest so much in web-platform-tests).


Sure, no worries, and thanks for the reply.

 -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/3480
[2]: https://github.com/w3c/csswg-drafts/issues/3319
[3]: https://github.com/w3c/csswg-drafts/issues/4247



   -- Emilio

 > On Fri, 27 Sep 2019 at 09:09, Emilio Cobos Álvarez
mailto:emi...@mozilla.com>
 > >> wrote:
 >
 >     And, to be clear, we _can_ fix these compat issues, some way
or another.
 >
 >     One 

Re: What to do about scroll anchoring?

[Matt Woodrow]

On 29/09/19 1:54 PM, Cameron McCormack wrote:

How useful is scroll anchoring outside of the two cases mentioned in 
https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and ad 
iframes being inserted?  Would it be feasible to make scroll anchoring a much 
less general mechanism, and to scope it down to handling these specific cases?


The virtual-scroller[1]/rendersubtree[2] demo that the Chromium team 
demoed at TPAC was also relying on scroll anchoring.


When you use the scrollbar to jump to a given spot, the custom scroller 
element then makes surrounding elements visible. Making them visible 
changes them from using their content-size [3] placeholder size to the 
real size, and we don't want the viewport to move in the process.


- Matt


[1] https://github.com/WICG/virtual-scroller

[2] https://github.com/whatwg/html/pull/4862

[3] https://github.com/w3c/csswg-drafts/issues/4229
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform