Re: Intent to unship SVGZoomAndPan interface
On Sun, Sep 29, 2019, at 1:22 PM, Boris Zbarsky wrote: > Sure, we could pass that by making it a mixin, not an interface, but > that says nothing about the `zoomAndPan` attribute on SVGSVGElement and > SVGViewElement. What does the compat situation look like for those? Both Chrome and Safari still implement the zoomAndPan IDL attribute. The actual functionality behind the zoomAndPan="" attribute was never implemented in any browser. It would be good to have a historical test to ensure the property is gone, too, not just the SVGZoomAndPan interface. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship SVGZoomAndPan interface
On 9/28/19 9:41 AM, longs...@gmail.com wrote: In [1] I intend to unship the SVGZoomAndPan interface. To be clear, this is unshipping that interface _and_ the mixin onto elements that adds a `zoomAndPan` attribute on them, right? The SVG WG decided to remove this interface in [2] as it's either not implemented at all or does nothing in current implementations. Do you know whether Chrome and Safari have any specific plans to remove it? All other browsers already pass the historical test [3] that the SVGZoomAndPan mixin interface must not be exposed Sure, we could pass that by making it a mixin, not an interface, but that says nothing about the `zoomAndPan` attribute on SVGSVGElement and SVGViewElement. What does the compat situation look like for those? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What to do about scroll anchoring?
On Sunday 2019-09-29 10:54 +1000, 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? I think it's also quite useful for horizontal resizes of the browser window (which can include device rotation on mobile, window resizing/maximization on desktop, and also hiding/showing of browser sidebar UI). -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What to do about scroll anchoring?
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? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship SVGZoomAndPan interface
On Sat, Sep 28, 2019, at 11:41 PM, longs...@gmail.com wrote: > In [1] I intend to unship the SVGZoomAndPan interface. The SVG WG > decided to remove this interface in [2] as it's either not implemented > at all or does nothing in current implementations. Our implementation > is currently the "does nothing" kind i.e. you can get and set the > property but it there's no functionality beyond that. Sounds good, thanks Robert. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship SVGZoomAndPan interface
Hi, In [1] I intend to unship the SVGZoomAndPan interface. The SVG WG decided to remove this interface in [2] as it's either not implemented at all or does nothing in current implementations. Our implementation is currently the "does nothing" kind i.e. you can get and set the property but it there's no functionality beyond that. All other browsers already pass the historical test [3] that the SVGZoomAndPan mixin interface must not be exposed [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1578003 [2] https://github.com/w3c/svgwg/issues/56#issuecomment-507411510 [3] https://wpt.fyi/results/svg/historical.html?label=master=chrome%5Bexperimental%5D=edge=firefox%5Bexperimental%5D=safari%5Bexperimental%5D ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What to do about scroll anchoring?
On 27/09/2019 23:19, Botond Ballo wrote: Emilio, thanks for all your work on this! On Fri, Sep 27, 2019 at 8:23 AM Emilio Cobos Álvarez wrote: Does anyone have strong opinions against removing scroll anchoring from Gecko, based on the above? My 2c: it would be unfortunate to give up on scroll anchoring as a feature altogether. Yes. However, if we need to disable it for now, until its spec is in better shape, I can understand that; I'd be concerned that if we disable it, we'll in effect no longer be providing useful implementation feedback to help shape the spec, and neither site nor spec authors will be guided towards anything better or more clearly defined than "however Chrome behaves". especially as the code would (presumably) still be there and users for whom it works well and really want it can turn it back on by flipping the pref. Although our chances of noticing regressions in this code will be greatly diminished (as well as the likelihood of noticing site authoring problems and spec shortcomings). JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
