Open
Bug 1501480
Opened 6 years ago
Updated 2 years ago
mask-image and SVG on input element fails in Firefox, Safari, and Edge, works in Chrome
Categories
(Core :: Layout, defect, P3)
Tracking
()
NEW
Webcompat Priority | P3 |
People
(Reporter: karlcow, Unassigned)
References
()
Details
(Whiteboard: [webcompat])
Attachments
(4 files)
This is difficult to know in which category this is falling. SVG or CSS
The HTML
<input type="checkbox" class="dragndrop" title="Unchecked" id="c1"><label for"c1">Non coché par défaut</label> <input type="checkbox" class="dragndrop" title="Checked" checked id="c2"><label for"c2">Coché par défaut</label>
The CSS
.dragndrop {
width: 2em;
height: 1.5em;
-webkit-mask-image: url(https://open-time.net/public/share/dragndrop.svg#mask);
mask-image: url(https://open-time.net/public/share/dragndrop.svg#mask);
}
.dragndrop:before {
content: "";
display: inline-block;
width: 2em;
height: 1.5em;
background: red;
}
.dragndrop:checked:before {
background: green;
}
.dragndrop + label {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}
The SVG
<svg id="mask" viewbox="0 0 16 16" xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMinYMin meet">
<path d="M7.9 7.9l2.1 7.5 1.7-2.6 3.2 3.2 1.1-1.1-3.3-3.2 2.7-1.6z" fill="#91DC5A">
</path>
<path d="M8 12h-7v-9h12v5.4l1 0.2v-6.6h-14v11h8.2z" fill="#91DC5A">
</path>
</svg>
This is working in Chrome and Safari
Not in Firefox.
Reporter | ||
Comment 1•6 years ago
|
||
Sorry this is NOT working in Safari.
Comment 2•6 years ago
|
||
(In reply to Karl Dubost :karlcow from comment #1)
> Sorry this is NOT working in Safari.
Ahá, that makes sense (I asked Karl on IRC to double-check this). This is very likely bug 1418470 then...
Flags: needinfo?(bwerth)
Comment 3•6 years ago
|
||
Actually, I don't think this is the case since this doesn't render properly on release either, even with -moz-appearance: none.
Flags: needinfo?(bwerth)
Summary: mask-image and SVG on input element fails in Firefox, works in Chrome → mask-image and SVG on input element fails in Firefox and Safari, works in Chrome
Comment 4•6 years ago
|
||
Probably needs some investigation of what's supposed to happen here. I don't even know what's supposed to happen when you mask over a replaced element...
Comment 5•6 years ago
|
||
Yeah, so there are a variety of issues with this test-case, will post test-cases in a second.
Comment 6•6 years ago
|
||
Mats, do you know if there's something that would justify this? This looks very wrong, but I'm about to sleep so would appreciate some sanity-checking, I'll file a Blink bug tomorrow if you agree this is a bug.
Flags: needinfo?(mats)
Comment 7•6 years ago
|
||
<input type="checkbox"> also generates pseudos in WebKit, fwiw... This is all very broken.
Comment 8•6 years ago
|
||
Edge behaves as us though...
Comment 9•6 years ago
|
||
Second issue is bug 1486252, which is that foo.svg#mask wasn't working properly. That's fixed in 63, but that explains why the test-case with `appearance: none` on the input doesn't work on 62.
Blocks: 1486252
Comment 10•6 years ago
|
||
Comment 11•6 years ago
|
||
Issue #3 (and this is why the original test-case fails on WebKit, and why attachment 9019544 [details] fails on trunk) is bug 1418470... The load is blocked due to CORS.
Brad, does it sound reasonable to send a console warning whenever an image is blocked due to CORS? It'd certainly save some headache. Do you want me to ge
No longer blocks: 1486252
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1501503,
https://bugzilla.mozilla.org/show_bug.cgi?id=1486252
Summary: mask-image and SVG on input element fails in Firefox and Safari, works in Chrome → mask-image and SVG on input element fails in Firefox, Safari, and Edge, works in Chrome
Comment 12•6 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)
> Brad, does it sound reasonable to send a console warning whenever an image
> is blocked due to CORS? It'd certainly save some headache. Do you want me to
> ge
Err, sorry, I never finished to type this because I went ahead and just filed bug 1501503 for that.
Blocking loads without a signal of failure to the web developer sounds bad.
So, to summarize, the original test-case:
* Fails in Firefox and Edge because of WebKit and Blink generating pseudo-elements for <input type="checkbox"> while we and Edge don't.
* Fails in Firefox and WebKit because of bug 1418470.
* Even with that, it'd fail in Firefox 62< because of bug 1486252.
Fun times :(
Comment 13•6 years ago
|
||
The TL;DR: Is that it shouldn't work anywhere because the mask should be blocked due to CORS per:
https://drafts.fxtf.org/css-masking-1/#priv-sec
But still the pseudo-element bit is amazing. I bet we have a bug on file for that one.
Comment 14•6 years ago
|
||
We support pseudos on -webkit-appearance:none checkbox/radio though,
in which case we just create a normal box per 'display'
(which we had to do for web-compat with Chrome (in bug 605985)).
Chrome supports ::before/::after on all sorts of supposedly
replaced elements, which I think is non-complaint with specs.
But web devs seems to want more control over stuff like this,
see for example:
https://github.com/w3c/csswg-drafts/issues/3226
So extending what we did for checkbox/radio to more controls
is probably inevitable, and then we get pseudo support at
least for -webkit-appearance:none for free. I'd rather not
support it without -webkit-appearance:none though...
We need better specs for all this for sure...
Hopefully the spec that Simon Pieters is working on for
-webkit-appearance / form controls layout can address this too...
Flags: needinfo?(mats)
Updated•6 years ago
|
Priority: -- → P3
Comment 15•6 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Webcompat Priority: --- → ?
Comment 16•6 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•5 years ago
|
Webcompat Priority: ? → revisit
Updated•2 years ago
|
Webcompat Priority: revisit → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•