14

I'm working on a jQuery theme which includes styling for as many form elements as possible. Initially it was developed for Webkit (Chrome). Now I want to make it work with Firefox as well.

Problem is; Firefox has problems with some Webkit-specific syntax.

For example:

input[type="range"]::-webkit-slider-thumb,
input[type=radio],
input[type=checkbox] {
    -webkit-appearance: none !important;
    -moz-appearance: none;
    width: 1.2em;
    height: 1.2em;
    border: 1px solid black;
    background: #666666 url(images/ui-bg_highlight-soft_50_666666_1x100.png) 50% 50% repeat-x;
}

The problem is the input[type="range"]::-webkit-slider-thumb, bit. Remove it and Firefox works fine. It also does this for other syntax like ::-webkit-file-upload-button, ::selection and all other things using the ::-webkit-... labels. It recognizes it's own ::-moz-... labels, like ::-moz-selection just fine though.

Webkit seems to just ignore the ::-moz- labels.

Is there any convenient way to make Firefox ignore the ::-webkit-... labels or otherwise deal with this problem without having to maintain multiple copies of every CSS block?

Using freshly updated versions of Chrome and Firefox.

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
Martijn
  • 3,696
  • 2
  • 38
  • 64
  • What do you mean when you say WebKit just ignores the `::-moz-` labels? Does it apply the rule anyway, ignoring only the pseudo-element with that prefix? (It's not supposed to...) – BoltClock Nov 29 '11 at 22:05
  • @BoltClock I mean that WebKit just renders the rule. As if the `::-moz-` label wasn't there; ignoring only the pseudo-element with that prefix. If you had `div, span::-moz-whatever, p { color: red; }`, WebKit would apply the rule to div and p. – Martijn Nov 30 '11 at 17:27

3 Answers3

10

Unfortunately, it's not possible without duplicating the declaration blocks, as the CSS spec stipulates that browsers must behave this way when encountering unrecognized selectors in CSS rules:

The selector consists of everything up to (but not including) the first left curly brace ({). A selector always goes together with a {}-block. When a user agent can't parse the selector (i.e., it is not valid CSS3), it must ignore the {}-block as well.

In this case, it's one vendor's browser being unable to recognize another vendor's prefixes, so it has to ignore the rule.

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
  • 1
    And this is why I hate vendor prefixes in selectors and at-rules. – BoltClock Nov 29 '11 at 21:52
  • Thanks for the answer. Not the one I was hoping for but it'll have to do. Then again... shouldn't `::-webkit-...` be just as correct or incorrect as a `::-moz-...` prefix? If Mozilla understands one, why should it fail on the other? – Martijn Nov 30 '11 at 17:30
  • 1
    @Martijn: Because WebKit's implementation is meant for WebKit's use only. Vendors should never try to parse or apply styles that don't use their own prefixes. Why WebKit isn't failing an entire rule on `::-moz-` as you noted above, though, is beyond me... – BoltClock Nov 30 '11 at 17:37
  • IE10 fails in the same way as Firefox. See this [JSFiddle](http://jsfiddle.net/qSa7B/) for an example. I understand the {}-block must be ignored if the selector is invalid CSS3, but as far as I can tell it is valid CSS3 - just unrecognized. – RichB Nov 14 '12 at 10:55
  • @RichB: That's alright, because "unrecognized" and "invalid" mean the same thing as far as a browser is concerned. If a browser doesn't understand the selector, it should ignore the whole rule, that's what the spec says. In this case, the behavior is as expected. – BoltClock Nov 14 '12 at 11:07
  • A comma is used to separate multiple selectors, it doesn't seem desirable that one selector in the list being invalid should ever be handled as the entire set being invalid. – The Mighty Chris May 19 '16 at 16:31
  • @The Mighty Chris: See http://stackoverflow.com/questions/13816764/invalid-css-selector-causes-rule-to-be-dropped-what-is-the-rationale/13831877#13831877 – BoltClock May 19 '16 at 16:32
6

I had to read a little bit to answer this question, here are some good resources, Gecko Style Engine Further Reading on the Engine Implementation, Still i did not see any pointers as why it would drop it, but i can give you my best guess, I think the engine is dropping the whole selector, suppose that mozilla implements -moz-slider-thumb pseudo selector and try to use it with -webkit- and it will be dropped as well.

I have seen this behavior before in all browsers, and i think its being used as a hack to target some browsers sometimes.

This will work

input[type=radio],
input[type=checkbox] {
    -webkit-appearance: none !important;
    -moz-appearance: none;
    width: 1.2em;
    height: 1.2em;
    border: 1px solid black;
}

This wont

input[type="range"]::-webkit-slider-thumb,
input[type=radio],
input[type=checkbox] {
    -webkit-appearance: none !important;
    -moz-appearance: none;
    width: 1.2em;
    height: 1.2em;
    border: 1px solid black;
}

or this

input[type="range"]::-moz-slider-thumb,
input[type=radio],
input[type=checkbox] {
    -webkit-appearance: none !important;
    -moz-appearance: none;
    width: 1.2em;
    height: 1.2em;
    border: 1px solid black;
}

I think you will have to rewrite the properties-values on two or more different selectors, this will only affect the size of the stylesheet as the engines will keep dropping the selectors they dont own.

I really hope this helped a little bit at least.

EDIT:

As noted by user @BoltClock in the comments my guess was correct here is a link to the spec w3.org/TR/css3-syntax/#rule-sets

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
rroche
  • 1,262
  • 1
  • 13
  • 29
2

FYI, I ended up going for a different solution.

Since my end product is a stylesheet, I decided to use a CSS compiler to generate the .CSS file based on a source file. So far it's working fine.

I've used LessPHP because the .less format is reasonably popular and I'm familiar with PHP, but any of the other ones will do.

Note that I'm using LessPHP only for compiling a static .CSS file, so it won't be a requirement for end-users of this project unless they want to change the .less source files themselves.

Martijn
  • 3,696
  • 2
  • 38
  • 64