As discussed with fantasai. Attaching first draft.
Created attachment 174067 [details]
I'm not sure, but it might be a good idea to read
<http://www.quirksmode.org/bugreports/archives/mozilla/index.html>, and perhaps
incorporate some of the comments there into this document.
There are a huge number of mistakes here. Off the top of my head, without
This should be called a CSS2 support chart, since it doesn't mention any CSS3 stuff.
There were versions before 1.0. You should at least indicate ≤1.0.
:active varies in quirks mode just like :hover
counter-increment and counter-reset are not supported
font-size-adjust is supported on some platforms
quotes was partly supported (only the first pair of values) before 1.8
some values for content are not supported
table-layout has been supported for a long time
visibility: collapse has been supported for a long time
white-space is only partially supported (it's too buggy on inlines to actually
call it supported)
I was planning to CC the CSS crew later, when my draft was a bit better, but I
guess this works as well.
To make the document more useful and easier to critize we should define support
for a property, selector and at-rule. Probably in this bug. (thanks bz)
I'm planning to add CSS 3 as well. Although I will not list all properties as
with CSS 2.1, just the ones that are supported. I guess it would make sense to
put those in a separate table. (And the CSS 3 selectors in a separate table as
well. Perhaps the CSS 2.1 selector table is not needed anymore then.)
I'm not sure about defining support. If we really did not support the property
or selector, it would go back to -moz- I guess like we have done before. So
every property or selector that does not have that is supported.
However, most of them have minor problems or problems are created thanks to CSS
2.1. Those should be listed in the notes field.
Also, I will maintain the document. I follow most (if not all) CSS related bugs
and I have commit access to the website to make changes when necessary.
Also, you still haven't defined what "Yes" and "No" mean, which is why a bunch
of us think support charts are a bad idea.
Created attachment 174213 [details]
This document makes things a bit clearer and includes suggestions from both
fantasai and dbaron.
Yes = release (starting from 1.0) since when Mozilla recognizes the property
and its values and does something with it. (Important bugs should be noted in
No = not supported
The note about :selected is flat wrong -- we do allow styling of all those
elements. There are just some properties (a very very few) that have !important
rules overriding any styles the page sets.
I see no notes about the dynamic bugs with :first-child, :last-child,
:only-child, :empty. The note on :empty isn't in English.
1.8 is not released yes, so I'm not sure why you're saying it supports something
(said support may end up being removed....). I guess for a draft that's ok...
Why write "negation" instead of ":not()"?
The ::before/::after notes should mentions something about support (or lack
thereof) for the values allowed by CSS2.1 for display, overflow, float.
"descendant" is not spelled "descendent". I'm not sure what the note here has
to do with how we implement it. Same for the note on child combinators and
direct adjacent combinators. Why are these last "combinators", btw, instead of
"combinator"? That applies to all of them.
Why are notes in the Gecko support chart talking about what IE supports?
border-collapse has known dynamic issues, last I checked (eg insertion of cells,
As of 1.8, we will have support for "cursor: <uri>" at least on some platforms.
I'm not sure it's worth mentioning 1.8a4 in the comments for overflow....
mention "1.8" (once that's released).
We have limited support for page-break-before/after, iirc.
I didn't really review the version numbers.
(In reply to comment #7)
> Why are notes in the Gecko support chart talking about what IE supports?
Perhaps IE should not be mentioned. While it may be useful, this is a Gecko
reference and including other browser information (except those based on Gecko)
would mean more work.
A section for Mozilla only CSS properties may be helpful as well (i.e. for
(In reply to comment #8)
> A section for Mozilla only CSS properties may be helpful as well (i.e. for
> extension developers).
As I mentioned in the documentation newsgroup that should only include
properties like -moz-margin-end and such. But I do not think I want them on this
Created attachment 174315 [details]
This addresses most of Boris' comments and adds some bug numbers as requested
by Robert Kaiser. I also added an acknowledgements section to credit people who
contributed to this.
There is a temporary |border="1"| added to make reviewing these drafts easier.
Comment on attachment 174315 [details]
Just some random things as I see them...
> of <ABBR>CSS</ABBR> support. Implented features may have (filed or unfiled) bugs, and
> build from Gecko 1.7.5. Mozilla Suite version numbers are equal to those of
> Gecko.) Versions prior to version 1.0 are listed as 1.0. The author of this
> document does not consider Gecko versions released before 1.0 to be of any
> importance on today�s web.
Instead of the last sentence, could you perhaps just say that versions prior to
1.0 are listed as 1.0 to save space? The last sentence seems somewhat odd as
it sits, and if I were writing this I'd try to remove it. Realistically, no
one cares about pre-1.0 CSS support, so I'm not sure it's worth explicitly
addressing in this manner. (Actually, on second thought a better idea might be
to specify that the version number listed is the number of the first stable
milestone release to support that property. That automatically excludes <1.0
if my knowledge of project history is correct.)
> </P><P>Since you should never rely on Mozilla extension properties they are not
> listed. If you are using them at the moment you should not be surprised to
> find out Mozilla does no longer support the property you are using.
"Mozilla CSS extensions (those prefixed with <code>-moz-</code>) are not listed
here. They are intended for internal use within the browser only and must not
be relied upon to work in web pages, because <strong>they can and will
> <P class="note">All non-normative (informative) properties are not listed. This basically means that
> the entire <A title="Aural style sheets" href="http://www.w3.org/TR/CSS21/aural.html">appendix A</A>
> is excluded from this list.
"Non-normative (informative) properties, including those specified for aural
style sheets in <A href="http://www.w3.org/TR/CSS21/aural.html">appendix A</A>
of the <abbr>CSS</abbr> 2.1 specification, are not listed."
Created attachment 174583 [details]
This addresses most (if not all) of the comments so far.
Created attachment 174859 [details]
Markup improvements and included suggestions from fantasai (IRC,
It'll take me some time to get to this (busy with other things)
Comment on attachment 174583 [details]
putting a dummy review request to myself on an older version so I remember to
look at it too
Gecko does not support few values of CSS 2.1 display property either.
e.g. run-in, inline-block, and inline-table.
> cursor Yes 1.0 Mozilla does not support the <uri> value yet. (Bug 38447.)
Yes, 'cursor: url(uri)' is supported in 1.8 in some platforms, and 'cursor:
progress' is not supported in 1.6 and before (Bug 230343).
> font-weight Yes 1.0
'bolder' and 'lighter' keywords are not supported. Bug 93725.
> page ? - -
> page-break-after ? - -
> page-break-before ? - -
> page-break-inside ? - -
'page-break-before: always' and 'page-break-after: always' are supported, left
things are not supported. Bug 132035.
And 'widows' and 'orphans' are not supported, I think.
IMHO, changing title to 'CSS support chart for Firefox 1.0.x and Mozilla
Application Suite 1.7.x' will make this chart better thing, because users will
want 'Is this property/value supported in my browser?', not development history
And please add value 'Partly' to 'Supported' column. e.g. in the draft
'white-space' property says 'Yes', but in notes there are words 'not supported'
(In reply to comment #17)
> IMHO, changing title to 'CSS support chart for Firefox 1.0.x and Mozilla
> Application Suite 1.7.x' will make this chart better thing, because users will
> want 'Is this property/value supported in my browser?', not development history
> ('Supported since').
I beg to differ. I expect web developers to care about the browser versions in
which their CSS works, so they can say "This webpage requires Mozilla 1.4 or
newer" or somesuch.
I will add 'outline', the notes on 'display', 'cursor:url()', the notes on
'font-weight', the notes on 'cursor:progress', 'page-break-*', Partly and remove
'page' which was from CSS2 in draft #6.
About the title and 'supported since', that is not going to change.
> 'bolder' and 'lighter' keywords are not supported. Bug 93725.
This goes back to the definition of "supported" (see comment 4). If a property
is buggy in edge cases (which is what we have here), is it "supported"? What
makes something an "edge case"?
See the definition of supported in comment 6 which is more recent and more correct.
bolder and lighter are supported, they're just not fully correct; then again, we
basically only support two font weights anyway, so really all of font-weight has
that caveat, not just bolder and lighter.
(In reply to comment #13)
> Created an attachment (id=174859) 
> draft #5
Needs update for Gecko/1.8.
These selectors are newly supported in Gecko/1.8:
:enabled and :disabled (bug 84400)
:valid, :invalid, :in-range and :out-of-range (bug 302462)
:required and :optional (Bug 302608)
Not only 'inline-block' (Bug 9458), but also 'run-in' (Bug 2056) and
'inline-table' (Bug 18217) are not supported.
clip works since 1.0.
If it's all the same to everyone (and Anne agrees to it and to the licensing of this under the Creative Commons: Attribute-Sharealike license), I'll add this to the MDC documentation wiki.
Let me know if that's ok (or not ok), and I'll set aside a couple of hours to do this over the weekend.
It's ok. But note that I still haven't recieved any "full" reviews so far. But now that it will be on a wiki I guess that's not really an issue anymore.
If we add this to the wiki, we should very clearly and in big letters say that it's not authoritative... I, for one, have no idea whether this chart is correct or not (nor time to check).
But yeah, if we wiki it as a "work in progress", that would be a decent idea, I think.
One other thing. If we're putting this out in public, is someone volunteering to keep it updated as things change? With 1.9a happening, this will be fairly often, I suspect.
Having it in the MDC wiki should at least simplify the process of keeping it updated. Having someone volunteer to "own" it and ensure updates are made (and reviewed) would be beneficial. I'm just not sure who that could/should be.
I've migrated this chart into the English MDC wiki here:
Review to ensure that I've migrated it all correctly would be appreciated. It is open for editing/updating, so feel free to make corrections or additions directly.
If there's anything else I can do to help with this, let me know.
*** Bug 451708 has been marked as a duplicate of this bug. ***