1561310 - allow -moz-element() in user and UA sheets only

Status: NEW

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Frederik Braun [:freddy]]

My personal opinion is that -moz-element() is a bit of a wart. -moz-element allows pointing to a different element to use as a value for a background property. The rendering of the element that's pointed to will be used as the background for the styled element.

We have some frontend code that will need to modify before anyone can unship -moz-element though.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

I don't think there's a good reason to allow this on UA sheets? What's the purpose of that?

Also, I recall Jeff wanting to unship this at some point for unrelated reasons, is that still true Jeff?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

So I did a bit of poking at this.

• If we unship this we should also unship Document.mozSetImageElement. From a quick search it doesn't seem to have a lot of usage, so may be feasible. There are a couple internal callers.

• Just limiting it to chrome and UA sheets may need some fixing around, since there's code in here that sets it using the style attribute, which just wouldn't work.

• If we want to completely remove this we need a bunch more work since there are various things to use -moz-element pointing to a <canvas> like this. Seems like there were already plans of changing this years ago (bug 1308695).

Comment 3

[Jeff Muizelaar [:jrmuizel]]

I wanted to unship this because it adds a recursion into the painting code that often gets in the way of refactoring. i.e. I spend more time fixing up problems with this code than I'd like to considering it's not very widely used on the web.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We should also think about whether we would want this to be used on the web for the use cases that it addresses. In other words, would we rather have this, or various properties specific to reflections and other similar effects, assuming we were forced into doing one or the other?

I think this is something we implemented because we thought it was a better solution for web developers than alternatives in other engines (which also aren't cross-browser -- I think WebKit-only).

Do we want to invest in pushing this forwards, do we want to accept the alternatives, or do we really just want to hope the entire demand for the feature (reflection-type effects and similar) goes away?

I don't think we've put much effort into bringing this before the working group or trying to get other browsers to implement it -- so it's possible that we could turn it into something that's cross-browser if we put the effort into doing so. (And it might be better than the other solutions to the same problem that are floating around. Or maybe it isn't...)

But I'd like us to be a little more intentional about thinking about how we want the platform to evolve from the perspective of developers and users and not just from an implementor perspective.

Comment 5

[Markus Stange [:mstange]]

Note that there's also bug 1496065 which suggests removing the feature entirely.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

In Chrome -webkit-box-reflect is implemented as a filter effect. https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/filter_effect_builder.cc?l=386&rcl=901c1000e295fd677307c2c2f07fd04a3ae64c8e. I think that's a way to deal with these effects with much less implementation complexity.

Adding an '<feTransform>' filter effect to SVG that performed an arbitrary 2d transformation on an image would be sufficient for being able to make this reflection effect.

I suspect getting other browsers to implement an '<feTransform>' would be much easier than getting them to implement moz-element. Direct2D, for example, already has this kind of filter effect. https://docs.microsoft.com/en-us/windows/win32/direct2d/2d-affine-transform. '<feTransform>' is very similar to the existing '<feOffset>' so there shouldn't really be much additional infrastructure needed. Implementing moz-element requires being able to render an arbitrary other element during background painting of a different element and I suspect other browsers would have already implemented this if it was easy. Also the number of open questions in the existing spec https://drafts.csswg.org/css-images-4/#element-notation suggests that spec'ing this isn't even obvious.

Houdini Paint also seems like a better solution to the current use cases of -moz-element(canvas)/-webkit-canvas.