Closed
Bug 1320751
Opened 8 years ago
Closed 8 years ago
Checkboxes and radio buttons should show their :before and :after content.
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
DUPLICATE
of bug 605985
| Tracking | Status | |
|---|---|---|
| firefox53 | --- | affected |
People
(Reporter: wisniewskit, Unassigned)
References
Details
(Whiteboard: [webcompat])
Attachments
(2 files)
Facebook is using :before and :after content in conjunction with -moz-appearance:none, in order to style radio and/or checkbox inputs as they please (at least on mobiles).
This works in Chrome, but not in Firefox, where the :before and :after styles are not being rendered for those elements. As such, the radio/checkbox will vanish because of the -moz-appearance:none, but nothing will be shown in their place.
|
Reporter | |
Comment 1•8 years ago
|
||
|
||
Comment 2•8 years ago
|
||
It doesn't look like we're overriding the pseudoelement styles anywhere, so it looks like we're just not supporting them for these frames.
I'm... not sure how to add pseudoelement support to a nsFormControlFrame like the radio and checkbox input fields...
I _think_ we want to somehow get here:
http://searchfox.org/mozilla-central/rev/957458d8fa2328c2a760dbb30e7f1f1efa55b4d0/layout/generic/nsFrame.cpp#10035
but I'm really not sure. Hey bz, tips on how to add this support? Perhaps an example bug or implementation I can look at?
Flags: needinfo?(bzbarsky)
|
||
Comment 3•8 years ago
|
||
We intentionally don't support pseudo elements on replaced elements.
Although I don't know if the decision has changed ever since for interoperability/compatibility with Chrome.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
|
|
||
Comment 4•8 years ago
|
||
Note that the functionality was removed here: bug 169334
|
||
Comment 5•8 years ago
|
||
So first of all... per CSS spec what Chrome is doing is complete nonsense.
I had thought at one point that what WebKit did was to just make these non-replaced elements when appearance:none is used (which incidentally would be just fine per spec), but that is NOT what they do. They render the ::before/::after but not actual DOM kids. Doing that would actually be quite easy, for what it's worth, and not observably different unless someone adds some actual DOM kids to the checkbox or radio. At least in terms of web page rendering. I can't tell whether the change of AccessibleType() would be OK in this case; that's something to check with the accessibility folks.
Trying to make this work within nsFormControlFrame would suck. For example, reproducing Chrome's rendering of this testcase:
<!DOCTYPE html>
<style>
input { -webkit-appearance: none; display: inline; border: 1px solid green }
input::before { content: "This is some text "; }
</style>
<body style="width: 0">
Hey <input type="radio"> there
</body>
would be well-near impossible that way. Or this one:
<!DOCTYPE html>
<style>
input { -webkit-appearance: none; display: table; }
input::before { content: "Row"; display: table-row; }
input::after { content: "Caption"; display: table-caption; }
</style>
<body>
<input type="radio">
</body>
So what I would propose if we really want to support this is the following, possibly in separate bugs to make it easier to bisect:
1) Change the default display of checkbox/radio from "inline" to "inline-block". That's what https://html.spec.whatwg.org/multipage/rendering.html#the-input-element-as-a-checkbox-and-radio-button-widgets says to do anyway.
2) Change nsStyleDisplay::CalcDifference to reconstruct frames when appearance goes from checkbox/radio to none or vice versa.
3) Change nsCSSFrameConstructor::FindInputData to return nullptr when type is checkbox/radio and appearance is none. This will then fall through to constructing by display type, which will give you the ability to style it however you want. The a11y people will need to be coordinated with to sort out what should happen with AccessibleType() here.
Then we should push for Chrome to align with that behavior; for them I expect it just means removing whatever code suppresses creation of layout boxes for normal kids of a checkbox/radio. We _could_ add such code ourselves if we had to, but I'd rather not add that complication, especially because I expect for web compat it does not matter.
|
|
||
Comment 6•8 years ago
|
||
Reopening, since I read this bug as "make checkbox/radio with appearance:none not be replaced elements", or at least that's what my proposed fix would do, so bug 241985 is irrelevant here.
Oh and we would presumably file a bug on the HTML spec to spec that behavior...
Flags: needinfo?(bzbarsky)
|
|
||
Updated•8 years ago
|
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
|
||
Updated•8 years ago
|
Whiteboard: [webcompat]
|
|
Reporter | |
Comment 7•8 years ago
|
||
CLoudflare is also having issues with this, as per the new "see also".
|
|
Reporter | |
Comment 8•8 years ago
|
||
This seems to have been fixed in bug 605985, so I'm closing this as a dupe.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•