Talk:Comparison of layout engines (CSS)

From Wikipedia, the free encyclopedia

This article was nominated for deletion on 24 February 2007. The result of the discussion was keep.

Contents 1 How is this useful? 2 Alternative table layout suggestion 3 Comparsion of "web browser"? 4 More tables 5 CSS problems in this article 6 CSS3 7 Tasman 8 Criteria of CSS versions? 9 Empty link note 10 CSS3 and IE 11 New Safari Documentation 12 Prepare for update 13 Suggestion: Last checked versions 14 Some visual enhancements: valign="top" and <td> to <th>; need for better borders 14.1 Example of what I mean 14.2 Use of classes? 14.3 Another comment! 15 Explain major and minor 16 What about Prince? 17 condense columns? 18 Opera 9.0 release 19 CSS3 shouldn't be listed 20 Test cases 21 I clarified some issues on the CSS2 CSS2.1 and CSS3 aural and speech properties. 22 CSS 2.1 and CSS3 23 Experimental as a yes (green) 24 CSS3 and Browser specific extensions

[edit] How is this useful?

The tables will be HUGE. And why version number (instead of just a "Yes")? Also, it is meaningless to list out all the properties, as some properties are so similar, e.g. if it supports margin, there will be not way that it doesn't support margin-left. Shorthands are good enough for this situtation. iCab (except the older versions) is using WebCore, so the column should be dropped. WebCore is based on KHTML, but there should be subtle differences. The "KHTML" column should be added. P.S. The page, if it is going to exist, should include also the various selectors and pseudo-classes. --minghong 07:03, 16 Apr 2005 (UTC)

1. Yes, the table will be huge, that's no problem, my scroll bar can handle it :-) The article is intended to be thorough.
2. I have decided to include version numbers as it is very useful for web developers (like myself) to know what version of a browser supports which properties. It doesn't affect the general user (who can just look at the colours), so there's no harm in adding additional data.
3. Shorthands are not good enough for this situation as there could be many properties where the expanded form is buggy but the reduced is not, or vice versa. For instince early versions of WinIE do not support the expanded form of the 'background' properties but only supports the shorthand, a perfect example directly contradicting your point.
4. iCab does not use WebCore, it has it's own rendering engine. I think you are mistaking it for OmniWeb (which now uses WebCore but previously did not. I have restored the iCab column accordingly.
5. The KHTML column would be identical to the WebCore column, just with different version numbers for particular features. I decided to use 'WebCore' as the title because first of all I have accurate data for WebCore, and secondly because more browsers use that than KHTML.
6. The page does include selectors and psudo-classes, they were at the bottom of the page but I've nw moved them to the top.

• I laughed when I read your comment about the Mozilla version number! Yes, my mistake, sorry!
• Whilst CSS Level 3 remains in Draft I do not recomended adding CSS3 properties to this table, it would be better to create a new table for each CSS3 Module (possibly in a new article) anyway. Adding CSS3 to this table would mess up the ordering and create confusion regarding properties such as content, whose implementation changed between CSS 2 and CSS 3 (just as :hover did between 1 and 2)

Nicholas 09:58, 17 Apr 2005 (UTC)

I've just added KHTML, as WebCore is going to become more and more different from KHTML [1]. I've removed iCab as it is not that widely used. Add it back if you object. Maybe the CSS3 stuffs should be split into its own tables. But if you do so, please split CSS2 from CSS1. Thanks. :-) I think it will be better from us to stick with the latest version only, as seen in comparison of web browsers. The version numbers just make it hard to read. --minghong 10:12, 17 Apr 2005 (UTC)

iCab is not more widely used than Konqueror, both have about 0.01% of the market! :-) Also, the differences Dave Hyatt speaks of such as input="search" which are not in KHTML are also not in the W3C standards so wouldn't be included here anyway. Everything in the W3C standards (CSS or otherwise) that is implemented in WebCore is also merged into KHTML, the only differences are the interface between KHTML/KJS and Apple's KWQ shim which exposes an Objective-C interface to the library, which doesn't affect rendering, and various input control and font-related drawing methods, which don't affect CSS.

I also disagree that version numbers make the table hard to read. One mostly checks by colour, and those should always be the colour of the most recent version anyway. There's little practical difference between a green box that says Yes and a green box that has a number in it, except that the latter conveys more information. Nicholas 10:55, 17 Apr 2005 (UTC)

I don't mean the non-W3C stuffs Safari developers added, but the standard CSS stuffs that Dave Hyatt added to pass the Acid2 test. I don't check those codes are checked in KHTML as well. I don't think we should drop the KHTML column. KHTML version number is not inline with WebCore version number, right? At least it should be renamed as "KHTML/WebCore" if you are 100% sure that they are identical --minghong 15:42, 17 Apr 2005 (UTC)

At any given point they will not be identical, but KHTML changes are quickly picked up by the WebCore team (within a few days to a week) and WebCore changes are incorperated into KHTML with each new public release of WebCore, so for the users/web developer's point of view they are both very close, from the programmer's point of view, who work with them day in day out, their closeness varies like the tide coming in and going out :-) Nicholas 18:56, 17 Apr 2005 (UTC)

Here're some differences between KHTML and WebCore. Jiu 16:54, 21 Apr 2005 (UTC)

Another problem of listing version number is that it could be hard to get the right version number, e.g. width is supported in version 1 (but wrongly) and corrected in version 2, so what should I put? Version 1? Version 2? So it is better to not show the version number, as the comparison is always based on the latest versions. --minghong 18:20, 17 Apr 2005 (UTC)

That's exactly what I explain at the top of the article. You put "2" in a green box, make it a link and explain that in version 1 xyz attribute was broken. If "2" has not been released, put "1" in a yellow box and explain the problem below. Nicholas 18:56, 17 Apr 2005 (UTC)

[edit] Alternative table layout suggestion

Gropuing in terms of CSS levels can show how good/bad the layout engine is. It also allow comparison of experimental CSS3 stuffs (e.g. opacity, which is really useful), without messing the rest of the table. e.g.

		Trident	Tasman	Gecko	WebCore	Presto	iCab
Relationship selectors
CSS1	descendant (E F)	Yes	Yes	Yes	Yes	Yes	Yes
CSS2	adjacent sibling (E + F)	Yes	Yes	Yes	Yes	Yes	Yes
	child (E > F)	Yes	Yes	Yes	Yes	Yes	Yes
CSS3	sibling (E ~ F)	Yes	Yes	Yes	Yes	Yes	Yes
		Trident	Tasman	Gecko	WebCore	Presto	iCab

(These are just some dummy data.) --minghong 16:02, 17 Apr 2005 (UTC)

That's a better design than I was contemplating - I had tried putting in a "Level" column (5% wide) with "1" or "2" in it before the Trident column, but it just looked a bit crap, so i took it out again :-)

If you want to start doing the CSS1/2/3 column I'd have no objections, but if you don't say so quick I'll do it myself.

I think we should use the exact terminology used in the CSS standards for naming the rows too, I think the above is correct, but I've not checked. Nicholas 19:02, 17 Apr 2005 (UTC)

I'm doing it now anyway Nicholas 19:25, 17 Apr 2005 (UTC)

However, I found one problem: something maybe redefined/amended in each CSS level. e.g. :first-letter is used for block elements only in CSS2, but any elements in CSS3 [2]. Some engines may support the older version, but some may support the new version. How do we deal with this problem? --minghong 08:10, 18 Apr 2005 (UTC)

Yes, I told you that already, that's why I didn't want to mix up CSS2 and CSS3 fin the first place! Nicholas 11:52, 18 Apr 2005 (UTC)

Yup, that's why I said this is a suggestion. But since you had made the changes already... maybe just live with it. --minghong 15:53, 18 Apr 2005 (UTC)

It's easy to change back. We should decide what is best, then do that. Is it better to have one big table for everything, or separate tables for CSS 1, 2 and 3 ? Is it a good idea to have the "CSS1/2/3" column there or can we represent this in another way (colour of the header cells, perhaps?).

I also think the second and third columns (e.g. "*" and "Universal") should be switched around, and the description be the <th> cell for the row. What do you think? Nicholas 17:05, 18 Apr 2005 (UTC)

I think the current layout is ok.

Opera 8.0 says it support CSS Speech Module [3]. But the module seems to be quite different from the CSS2 Aural Module [4]. How would we handle this? :-S --minghong 08:38, 19 Apr 2005 (UTC)

Aural style sheet in CSS2.1 is deprecated and it's just left as an appendix. I don't think this article should list them. Jiu 18:31, 25 Apr 2005 (UTC)

Deprecated! Oh yes.... really [5]. No wonder Opera goes straight to CSS3 Speech module... --minghong 18:49, 25 Apr 2005 (UTC)

[edit] Comparsion of "web browser"?

I can only see layout engines here. Maybe this should be better named as "Comparison of layout engine CSS support". --minghong 16:02, 17 Apr 2005 (UTC)

Yeah, I created the article name before I changed my mind and put layout engines instead of browsers (no point duplicating stuff for all the different Gecko-based browsers, for example). Maybe it should be moved, but then again maybe not. Lets wait until some other people comment first. Nicholas 18:58, 17 Apr 2005 (UTC)

As I've just created list of layout engines, what about "Comparison of layout engines (CSS)"? I want to create "Comparison of layout engines (DOM)" too. :-P This can be expanded to, say, "Comparison of layout engines (XHTML)". --minghong 07:32, 19 Apr 2005 (UTC)

[edit] More tables

We also need to compare CSS values and units (e.g. system color, system font) and colors. --minghong 08:15, 18 Apr 2005 (UTC)

You can probably put values, units and colours all in one table, but it should go at the end i think. Do you want to do that now? Nicholas 14:32, 18 Apr 2005 (UTC)

Yup, I'm looking at these pages right now [6] [7] [8]. --minghong 15:54, 18 Apr 2005 (UTC)

Created. However, I'm not sure if we should add keywords of the properties like display, cursor, etc [http://f57.aaa.livedoor.jp/~motohiko/CSS/css2.1.html, as IE only supports block and inline ^^:. --minghong 18:09, 18 Apr 2005 (UTC)

[edit] CSS problems in this article

When the page is viewed under IE or Opera, the background color of the cells for Yes/No is black, hence making the text not viewable. Also, part of the table border is sometimes not visible in Gecko. I don't know why. May fix it then when I have idea. --minghong 11:34, 18 Apr 2005 (UTC)

I haven't seen any problems here using Gecko or Opera, but as happens with all web pages on wikipedia, sometimes the last bottom border of a table doesn't draw in Safari if I scroll quickly (scrolling slow make it all draw correctly), is that what you see? Nicholas 14:35, 18 Apr 2005 (UTC)

The border of the upper part of the table sometimes disappears [9]. --minghong 15:53, 18 Apr 2005 (UTC)

[edit] CSS3

For the CSS3 stuffs, if no one support it yet, don't list them. --minghong 13:23, 18 Apr 2005 (UTC)

I disagree, firstly because it is useful to know that no-one supports them, secondly because support will likely come soon, especially from Opera and Mozilla, thirdly it is best to be complete and thorough (if we aren't, someone else will add them soon anyway) and fourthly because until you have tested everything with the latest versions you don't know if it's supported or not, and as you say you don't have a Mac so can't check two of them (WebKit and iCab). If you disagree with me, could you please explain why, I am open to good reasons. Nicholas 14:30, 18 Apr 2005 (UTC)

I agree with point 3. OK by me. --minghong 15:53, 18 Apr 2005 (UTC)

[edit] Tasman

From the Tasman, the latest version is 0.9. So it is obvious that the version number of Tasman is not the same as that of IE for Mac. Also, Tasman was not used until IE for Mac 5. So version 4 of the browser may be still using Trident, or migrating from Trident to Tasman.

Anyway, the version numbers in the table have to be corrected. --minghong 13:09, 20 Apr 2005 (UTC)

[edit] Criteria of CSS versions?

REC CSS2? CR CSS2.1? latest CSS2.1? or WD CSS3? I see there're some inconsistencies in this article. Let's say the white-space property, it seems we're now using CR CSS2.1 as the criteria due to "Partial" support of Gecko, but the Webcore and Presto should also be "Partial" if we really do so. In this case, Presto should be "Partial" in counter-* property. And content property support of Gecko should be "Yes" again while that of Presto is somewhat between CR CSS2.1 and WD CSS3 level. Another issue is the changes from CR CSS2.1 to latest CSS2.1. Since latest CSS2.1 is not in public yet, it's hard to find out all the changes until now. But its section 12.4 has been rewritten as far as I know. If we use this as criteria, that row will become "Partial" in KHTML column as what KHTML implements is the specs in CR CSS2.1. It's also crucial to define how can we put "Yes" into the table? "Yes" if the layout engine has partial support? buggy support? or only what they claims they support?

N.B. Some "experimental" support listed here are actually the superset of the formal CSS specs. How should we comment on this? Jiu 19:08, 25 Apr 2005 (UTC)

That's the problem we face in the current table layout. Suggestion? You can put your suggested layout here. P.S. "Yes" is put for full support only (based on CSS2.1). --minghong 13:27, 25 Apr 2005 (UTC)

By the way, please try to offer footnotes for the "partial" support. Currently, for some of the items we don't know why it is "partial" but not "full". I know that's difficult, and some are actually made by me... --minghong 18:47, 25 Apr 2005 (UTC)

[edit] Empty link note

":link — Triggers on anchors with empty href attributes. (i.e. <a href="">blah</a>). An empty string is not a valid URI [5]." but linked RFC says: " A URI reference that does not contain a URI is a reference to the current document. In other words, an empty URI reference within a document is interpreted as a reference to the start of that document"

Opera 8b1/Mac and Firefox display <a href="">blah</a> as visited link. Safari always as unvisited, but "Partial" is on Presto. This all doesn't make sense.

[edit] CSS3 and IE

Explorer DOES support some CSS3 properties. Microsofts properties for layout of asian text is part of CSS Text Module. It's bit unfair to say "No" in the table. But probalby it there's need for more precise support level than "no/minor/major/yes", to avoid impression that IE is anywhere near other browsers.

[edit] New Safari Documentation

The following just appeared:

• Safari CSS Reference
• Safari HTML Reference

[edit] Prepare for update

IE7 will include several CSS improvements, e.g. CSS 2.0 selectors. And Firefox 1.5 (Gecko 1.8) may also bring some new things this summer. --minghong 05:03, 30 July 2005 (UTC)

[edit] Suggestion: Last checked versions

It would help maintaining it. A no always means that it will probably be included in a future version. So for anybody who whants to help keeping this huge list up to date it would be a relief to know what version was the last checked. E.g. in Safari it is written "Property XYZ: No" - I got no idea when with what version this was checked back the last time.

I don't get your question. A "no" just means a "no": It isn't supported in the past, not now. Future? We don't know. It doesn't mean anything else. --minghong 01:51, 19 August 2005 (UTC)

I get it. He means that there are always updates (especially Safari and Firefox) which fix things and implement new (css) features, so maybe the version of Safari which was used to check the css property should be noted. It'd make maintaining the page easier. 85.1.125.112 20:37, 31 January 2007 (UTC)

I think that would clutter the page up big time and make the DOM article in the series unmaintainable. We don't need to be superprecise. As far as Gecko and Presto go, they'll be maintained good enough anyway (and IE... *laugh*). Then again, we can't used it for Safari/WebKit as some people started adding dates to features/properties with "No template" indicating Nightly support. So the layout engines that could possibly benefit are KHTML and iCab... and this does (imho) not justify the mess -- Grey 01:50, 1 February 2007 (UTC)

[edit] Some visual enhancements: valign="top" and <td> to <th>; need for better borders

I've added the code valign="top" to each of the cells that span multiple rows. At the moment it's impossible to tell which rows belong to which cell. Further, I've converted the CSS1, CSS2, and CSS3 cells from td to th, as they should have been all along.

I also suspect it would help to provide some sort of border where the breaks between CSS1, CSS2, and CSS3 occur; at the moment it's all a little confusing! El T 12:22, 14 November 2005 (UTC)

[edit] Example of what I mean

To clarify what I meant about borders, this is the article's Grammar and Rules section as I think it should be:

			Trident	Tasman	Gecko	WebCore	KHTML	Presto	iCab
CSS1	!important	Weight increasing	4.0	0	1.0	85	Yes	7.0	Yes
	/* Comment */	Comments	3.0	0	1.0	85	Yes	7.0	Yes
	@import	Import stylesheet	4.0	0	1.0	Yes	Yes	7.0	Yes
CSS2	@charset	Character set	5.5	?	1.0	?	?	7.0	Yes
	@media	Media-specific rules	5.5	0.9	1.0	Yes	Yes	7.0	3.0
	@page	For paged media	5.5	No	No [10]	?	?	7.0	No
	@font-face	Define font	5.5	No	No [11]	No	?	No	No
CSS3	@namespace	Namespace declaration	No	No	1.0	?	?	8.0	No
			Trident	Tasman	Gecko	WebCore	KHTML	Presto	iCab

I know it would require some additional coding, but I think it might really help the legibility of this guide.

[edit] Use of classes?

I know this isn't possible at the moment, but it's a pain that Wikipedia doesn't let you define your own stylesheets. Imagine how much simpler it would be if instead of style="border-bottom: solid 1px #ccc; background: #dfd;" you could just put class="implemented underrule" (where the second class indicates it needs a bottom border)!

El T 12:35, 14 November 2005 (UTC)

[edit] Another comment!

If anyone implements the border suggestion (which I think would be great), make sure you use style="border-top: solid 1px #ccc;", not border-bottom:.... When you think about it, using border-top means you can just apply the rule to the cells of one row rather than different rows, as is the case with border-bottom. El T 12:38, 14 November 2005 (UTC)

[edit] Explain major and minor

These terms are not defined. Does "minor" mean "minor problems" or "minimal support". Or does it refer to a software version? The article never states which is "better". (but the Trident column gives some clues) —Ryan 15:35, 5 June 2006 (UTC)

[edit] What about Prince?

Since we speak about layout engines, not browsers ... why not include Prince XML formatter? It's the forerunner in CSS implementation as far as I know. Albeit only for print media ... Grey 23:29, 5 June 2006 (UTC)

[edit] condense columns?

Having noticed that often, standards tend to be implemented at once, i.e. the entire column of sub-section is the same thing repeated over and over again (e.g. Gecko's support of Visual formatting model CSS level 1 is all 1.0), wouldn't it be a good idea to simply rowspan as much as is common within the distinct CSS levels? For example (I suck at wiki table formatting, so I'm not even going to bother trying that) iCab's column would be a single cell 3.0 in the BoxModel (under properties) from border to padding-left and then another cell from border-top-color to border-left-style (with 3.0 again), and finally a "No" element for the next two rows... IMacWin95 18:19, 27 July 2006 (UTC)

I've started by doing it for the selectors. I wish there were some quicker way of doing it, hmm. —Simetrical (talk • contribs) 23:50, 27 July 2006 (UTC)

I restored most of them. Because that kind of ad-hoc spanning hurt readability and make editing difficult. But I think it is OK to span for modules that are not yet implemented. --minghong 17:22, 17 November 2006 (UTC)

[edit] Opera 9.0 release

Though while new versions of all the browsers are almost always being released (hem, well cept one or two), Opera 9.0 has been released not to long ago and i'm sure its final support is greater then its alpha stage support for css. I personally am not sure what it now supports that is not on the list (I'm testing but I don't even know what half of the css3 are suppose to do). If someone could help me "test", that would be helpful. 69.95.252.54 16:36, 31 July 2006 (UTC)

[edit] CSS3 shouldn't be listed

CSS3 isn't yet a standard. Lots of its component parts are still being thought out; many will be radically changed between now and the final version; and many will never even make it as a standard. So is there a point to marking browsers on their CSS3 support? El T 17:39, 4 August 2006 (UTC)

There would be no point if no browsers attempted to implement any CSS3 properties. However, some have attempted to implement them, so it's reasonable enough to list them, even if they may become obsolete at some point in the future. Anyway, CSS 2.1 is officially a Working Draft, whereas several CSS3 modules have become Candidate Recommendations, so it's not like there's been a CSS standard since CSS1 that's been declared final (and not had its finality revoked). —Simetrical (talk • contribs) 22:19, 4 August 2006 (UTC)

[edit] Test cases

Where the test suites can be obtained to check / augment the tables? We should make these test suites publicly avaiable to make this information verifieble, to conform to Wikipedia standards. --Maxim Masiutin 00:13, 15 January 2007 (UTC)

[edit] I clarified some issues on the CSS2 CSS2.1 and CSS3 aural and speech properties.

I clarified some issues on the CSS2 CSS2.1 and CSS3 aural and speech properties. CSS2.1 is a draft and should not be cited as a current recommendation. Also true for CSS3. I think this article could do better to keep that issue in the forefront of the reader’s mind. Also, the section did not keep clear the difference between CSS3 speech and aural modules. If we’re going to include CSS3 discussion, those should be kept straight. Things like "volume" and 'voice-volume' are not the same property. In CSS3 one is an aural property and the other is a speech property. A similar distinction could be made between 'voice-balance' and 'azimuth' or 'balance'. --SoTuft 08:39, 22 February 2007 (UTC)

[edit] CSS 2.1 and CSS3

I think there's nothing wrong with the article discussing these working drafts. However, I think the article should make clear that these are proposed recommendations (working drafts, candidate recommendations, etc.). Saying that something is deprecated in CSS2.1 is misleading. It would be better if it said something like “CSS2.1 proposes the deprecation of …” Likewise for CSS3. It's definitely of interest since browsers are already anticipating CSS2.1 and CSS3 and so this article should probably include what browsers support the proposed features in each .

However, many of the additions of CSS2.1 are in CSS3, so even if CSS3 was never adopted it wouldn't really matter. Many of the properties and the like (at-rules, keywords and modules) that are deprecated in CSS2.1 are reintroduced in much the same form in CSS3. If certain CSS3 modules reach recommendation status before CSS2.1, it really becomes confusing. I almost think the deprecations of CSS2.1 are meant to be a marketing gimmick so that one implementation or another can claim “FULL CSS 2.1 support”. The only thing that is deprecated by CSS2.1 that remains so in CSS3 (that I can think of off the top of my head) is the 'display:marker' value and the 'marks' property from the CSS2 paged media module. There may be a few others, but they're part of nonpublic drafts and shouldn't be discussed here. --SoTuft 08:39, 22 February 2007 (UTC)

Just as another example of the ways it’s misleading to discuss CSS2.1 as a done deal look at the @font-face rule. Currently the article says that “@font-face removed in CSS 2.1” However, the CSS3 WebFonts Module (which is at the same “Last Call” status) includes the @font-face rule. So again, if they both reach recommendation status at the same time, then CSS2.1 merely serves as a marketing document so an implemntation can claim full CSS2.1 support. It doesn't really help web designers or web consumers since fully supporting CSS2 would be a more expressive implementation. It sounds better for a browser to say it fully supports CSS2.1 than to say it fully supports CSS2. However, CSS2 give designers, content creators and content consumers more to work with than CSS2.1. --SoTuft 08:39, 22 February 2007 (UTC)

Another thought on disentanbling the current CSS recommendations from proposed recommendations woudl be to add explicit separation between CSS2 and CSS2.1. Perhaps repeating properties when the meaning changes from one recommendation to another (it doesn't happen that much).. That way it would be eawier to show whether an engine implemented one or the other of the recommendations. Also an introductory table like this could help:

	Trident	Tasman	Gecko	WebCore	KHTML	Presto	iCab	Prince
CSS1	6.0	Yes	1.0	85	Yes	7.0	Yes	Yes
CSS2 (2.0)	Partial	Slight	Partial	Partial	Partial	Partial	Partial	Mostly
CSS2 (2.1)	Partial	Partial	Mostly	Mostly	Mostly	Mostly	Mostly	Mostly
CSS3	No	No	Slight	Slight	Slight	Slight	Slight	Slight

Since 2.1 deprecates Aural and the page context, I would imagine Gecko and probably Presto, WebCore and KHTML will be nearly 2.1 complete this year. However, I think it's disingenuine to give that much credit when the recommendation changed to match their feature set (and also for a recommendation that is not yet a recommendation). Then I think in the other tables adding ana dditional section for CSS2 and CSS2.1 (explicitly differentiating them), would help make things clearer. Any other thoughts?--SoTuft 08:49, 22 February 2007 (UTC)

[edit] Experimental as a yes (green)

I changed over the experimental designations to yes in the article. Let me explain here why. The experimental designation has become the norm throughout the UA development world. Any property or selector that is only part of a draft recommendation is only going to get implemented with the name-spaced prefix. However, content creators are free to start using these properties and selectors right away. They simply require repeating the declarations for each implementation. Once the recommendation is finalized, you can expect those browsers that already have the prefixed implementation will quickly offer the non-prefixed version. This is good practice for everyone since it let's early adopters try out the features and the implementations; identify bugs early; and ensure the final rollout has the greatest amount of interoperability. So I think these make the most sense as green in the table since that's the most we should expect from CSS3 properties and selectors. Once CSS3 becomes a recommendation, it might make sense to change these back to partial (though I don't think tat we'll have the window of opportunity to do that). --SoTuft 09:25, 22 February 2007 (UTC)

[edit] CSS3 and Browser specific extensions

I believe that the sections for which the W3 hasn't at least got to 'Candidate Recommendation' status should either be removed or have a thumping great warning attached (something akin to {{future}}) -- it's potentially unfair to judge a browser on a stard before it has been finalised (after all, that's why the Box model was "wrong" in IE, as it correctly implemented one of the WD implementations)

I also don't think that browser proprietary extensions should be listed at all (all those starting with a '-') -- Ratarsed 10:21, 25 February 2007 (UTC)

Concerning CSS3, the situation is difficult... we should include modules that have been CRs (Selectors, primarily), but the CR documents are in part obsoleted by their respective Working Drafts now. It's just an obscurity of the W3C's standards track that specs go back in status and we have to deal with it. It would be a shame to exclude the selectors module, just because it is not CR any more (implementations are forthcoming). Regarding "proprietary extensions"... they aren't listed unless they copy the behaviour of a spec'ed property, which makes them "experimental". See above section for opinions about those (I don't like that they are there/"green", but some disagree)... --Grey 19:34, 25 February 2007 (UTC)

I'm the one who suggested changing the experimental implementations of the working drafts to green (and I went ahead and did so). However, I would agree that a better appraoch would be to simply not include CSS 2.1 or CSS 3 at this point. I think the proposals should actually reach recommendation status before they're included in this article. Until they reach that stage they're in constant flux. It's difficult to even find realiable sources that assess whether the various rendering engines have completely, partially, implemented the feature and whether it's buggy or dangerous or such things. Also, by focussing on the stable recommendations, we could focus more attention on the subtle differences and similaritiesin these rendering engines. CSS 2.1 and CSS 3 open a whole other can of worms that complicates the issues. If CSS 2.1 reaches recommendation status it could be added back in. Also as far as CSS 3 is concerned, I think each of it’s modules should be treated separately by this article, just as the W3C is doing. --207.168.161.13 17:31, 1 March 2007 (UTC)