On CSS specifities: * Here in English, but I don’t find it that clear: http://meyerweb.com/eric/css/link-specificity.html * Here in French (I’ll try to translate it one day): http://blog.empyree.org/post/2837 The test case uses two styles (in that writing order): /* specificity 0,0,2 */ html table :before, html table :after {content:inherit} /* specificity 0,0,1 */ abbr:after {content:" ("attr(title)")"} Even though it is the last one, the second one shall be overridden by the first, by virtue of specificities. This is the case with Opera (I did not check with Gecko).
Created attachment 13817 [details] Testcase
WebKit just ignores content:inherit right now, since it's kind of a crazy thing to right in CSS2.1 when it can only apply to generated content.
Now looks like a duplicate of bug 13097.
*** This bug has been marked as a duplicate of 13097 ***
Shall I understand this is the same mechanism that governs inheritance and specificity? Even if this is the case, it appeared to me as two different applications of the same problem, and it would be worth checking the two of them, but you certainly know better (no irony in this sentence—you’re just better than me at developping a browser).
We ignore content:inherit completely. This is why it looked like a specificity issue (when it wasn't).
(In reply to comment #6) > We ignore content:inherit completely. This is why it looked like a specificity > issue (when it wasn't). > Thank you. Do you have an approximation on when you will start working on content:inherit? At least for compatibility reasons with Opera (and maybe even for standards reason, but I am not sure here), content="" will have hideous side effects on Opera, contrary to content inherit Example: table :before, table :after {content:inherit /* For space reaason, I avoid any generated content in a table. Do not use content:"", or it will break in Opera — plus, this is not the intended effect*/}