Talk:Comparison of layout engines (Cascading Style Sheets)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computer graphics (Rated Stub-class)
WikiProject icon This article is within the scope of WikiProject Computer graphics, a collaborative effort to improve the coverage of computer graphics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Stub-Class article Stub  This article has been rated as Stub-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Note icon
This article has been automatically rated by a bot or other tool as Stub-Class because it uses a stub template. Please ensure the assessment is correct before removing the |auto= parameter.
WikiProject Computing / Software  
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.
WikiProject Internet  
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
edit·history·watch·refresh Stock post message.svg To-do list for Comparison of layout engines (Cascading Style Sheets):

See Talk:Comparison of layout engines (Cascading Style Sheets)#Trident version numbers

This article has been mentioned by a media organisation:
  • Bert Bos (February 14 2012). "CSS software". World Wide Web Consortium (W3C).  Check date values in: |date= (help) ()

Trident version numbers[edit]

  • This issue appears to have been left unresolved (since 2010?), rendering this page of limited use. Version values for Trident in the tables appear to be IE browser versions rather than Trident engine versions - e.g., lots of "8.0" and "9.0" when "Engine nomenclature" states the most recent Trident version is "5.0" (IE10). If version numbers have been used (more intuititive IMO), how about updating "Engine nomenclature" to state this? --Psdie (talk) 18:55, 16 August 2011 (UTC)

This discussion was going on on the todo for this page, thought I'd post it here:

Combining IE7, IE6, IE5 and older versions together into one category would be very unhelpful, since each engine is fairly widespread and each renders properties very differently. That might work in 10 years, when IE8 is the oldest version of IE in use.
--Gyrobo (talk) 23:17, 23 March 2010 (UTC)
ie7mobile has the triden 3.1 indentification: so let be bold and change back all to 1, 2, 3, and 4 mabdul 23:56, 23 March 2010 (UTC)
Microsoft has never confirmed any version of Trident other than 4.0=IE8 and 5.0=IE9, and such a version scheme has never been used before anywhere. It would have no resonance with developers who equate Trident with Internet Explorer, and may be inaccurate. I asked on the IEBlog a month ago for Microsoft to clarify the version scheme. If they don't provide documentation, we shouldn't act.
--Gyrobo (talk) 00:51, 24 March 2010 (UTC)
Trident 3.1 is IE7Mobile which is a port of IE7... mabdul 10:07, 24 March 2010 (UTC)
Trident 3.1 is "a version between Internet Explorer 7 and 8". Microsoft hasn't confirmed that IE7 itself is Trident 3.0. Any version system we create for Trident prior to 4.0 would be WP:OR.
--Gyrobo (talk) 14:30, 24 March 2010 (UTC)
Then let us NOW correct them and say pre4.0 and make notes of the IE version. It doesn't matter if this happens in 10 years or now! mabdul 14:45, 24 March 2010 (UTC)
But that wouldn't be useful. Web developers need to know differences in support between IE5, IE6 and IE7, and doing what you propose would put them all in the same category. I've asked the IE Team again, and I hope they will respond.
--Gyrobo (talk) 14:52, 24 March 2010 (UTC)

Now we got the answer: then let us change it to pre 4.0 and make to every cell the note in which IE it was first presented. every dev could read this! mabdul 16:53, 25 March 2010 (UTC)

Is there a notation that would not be cumbersome? In my opinion, changing each cell from 3.0, 4.0, 5.0, 5.5, 6.0 and 7.0 to <4.0note x would make it much less readable. When Opera versions were changed to Presto versions, all versions of Opera prior to 9.0 became Presto 1.0, with Opera 9.0 as Presto 2.0. Following the same pattern, all IE versions prior to 8.0 would become Trident 4.0.
--Gyrobo (talk) 19:13, 25 March 2010 (UTC)
but as you said above: in a few years this will happen: so why not do it no: make (or i do) a accumulative note: pro version of ie one note: makes 6 notes for the whole page mabdul 20:56, 25 March 2010 (UTC)
I believe that a notation formula like <4.0note x would not improve the article, but would make it much harder to determine when support was added. Until there is a better syntax, or the older versions of IE become unimportant, I don't think the version numbers should be changed.
--Gyrobo (talk) 21:40, 25 March 2010 (UTC)
My 2c - I don't think changing from Opera version numbers to Presto version numbers made the article more readable or easy to understand, even though Presto has a simple versioning system than either Gecko or Webkit. The engine versions are used not to make the article more readable, but to make the article more accurate and "proper" - if readability were the priority, using browser version numbers across the board would be far easier to understand. However, doing this would not be representative of the fact that Gecko is used in KMeleon and Camino, Webkit is in Midori and iCab and Trident is in Avant and Maxthon, a fact that DOES need to be represented. My point is, it's worth remembering that readability isn't the motivation for this change.
May I suggest using the same versioning as the Trident article - i.e. for IE4 call the engine "MSHTML 4.0" and drop the "MSHTML" part as soon as published Trident version numbers start. ɹəəpıɔnı 23:38, 25 March 2010 (UTC)
ok this is way between - for say years as Gyrobo said: then change it to the read version numbering, but we need an explanation for this! mabdul 23:31, 25 March 2010 (UTC)
How about something like:
color <4.0[IE 3.0]
E[attr] <4.0[IE 7.0]
E:lang() 4.0
opacity 5.0

Is this what you were thinking of?
--Gyrobo (talk) 23:59, 25 March 2010 (UTC)

yeah, this comes really near... @Lucideer what about you? mabdul 08:13, 26 March 2010 (UTC)
OK, I will start (and end) to convert the articles by the end of the next week if nobody will say against it any more. mabdul 02:00, 15 April 2010 (UTC)
I modified Comparison of layout engines (graphics) as it is relative representative. is it so good? If I get a ok, I will modify the others also! mabdul 06:24, 9 August 2010 (UTC)
Since we know that Trident 3.1 includes everything in IE7, we could have something like
color <3.1[IE 3.0]
E[attr] 3.1
E:lang() 4.0
opacity 5.0

Where IE7 == Trident 3.1 and <3.1 == IE3, 4, 5, 5.5 and 6 (in brackets).
--Gyrobo (talk) 14:38, 9 August 2010 (UTC)

I'm going to make a template for version of Trident <3.1.
--Gyrobo (talk) 14:40, 9 August 2010 (UTC)
Yes check.svg Done The template is available at {{IE}} and it should make things easier.
--Gyrobo (talk) 14:59, 9 August 2010 (UTC)
OK, thanks. I will update the ofter articles tomorrow. mabdul 15:29, 9 August 2010 (UTC)
The following articles have been updated:
Pages that still need updating:
When updating an article, please add it to the list here to keep track of it. --Gyrobo (talk) 16:02, 9 August 2010 (UTC)


After the issue of Trident version numbers is resolved, I'd like to archive this page because the number of conversations is making it hard to discuss things.
--Gyrobo (talk) 16:50, 9 August 2010 (UTC)

I just moved all old talks to Talk:Comparison of layout engines (Cascading Style Sheets)/Archive 2. It should be easier to find things now.
--Gyrobo (talk) 02:43, 11 August 2010 (UTC)

Notes section[edit]

All of the other comparison pages have a separate section devoted entirely to notes. The CSS page does it differently, the way the other pages once did, by having separate notes sections after each table. The notes are linked to within the table cells, which will make it hard to switch over the #Trident version numbers. Should all the notes here (probably hundreds) be combined into a single notes section to make the Trident switch easier?
--Gyrobo (talk) 02:35, 11 August 2010 (UTC)

I see the prince column and a few references on the page to prince; yet, there is not mention of a prince in layout engines. This is the link for prince

I do not think it belongs here. Its not a layout engine, comparable in use, to the other layout engines. Gary johnson 53 (talk) 21:45, 15 May 2014 (UTC)

Status of non-CSS3 pseudo-classes[edit]

All of the pseudo-classes from E:indeterminate onward, as well as the E::selection pseudo-element, aren't defined in the CSS3 Selectors Module. Should they continue to be listed under CSS3?
--Gyrobo (talk) 23:40, 26 October 2010 (UTC)

Compination of @font-face and font-size in Gecko[edit]

I've experienced that FireFox, but not Epiphany-gecko, renders @font-face specified fonts with incorrect size if the size is specified using font-size (but not e.g. <big>text</big>).— Preceding unsigned comment added by (talkcontribs)

Generated Content CSS2 vs CSS3[edit]

I made this edit (forgetting to login - apologies), and Gyrobo requested I justify it.

The CSS3 spec. has additional requirements for some pre-existing properties - so browsers that fully support a CSS2.1 property may now only partially support it according to CSS3, if they haven't updated to meet the new requirements. As far as I see it there are a number of ways we could represent this in a table:

  1. As the CSS3 Generated and Replaced Content Module is the current Working Draft, it should be followed and CSS2.1 should be ignored - in this case, browsers not meeting CSS3 will be marked "partial" and there'll be no information on CSS2 support. This seems suboptimal.
  2. As CSS2.1 is a W3C standard, adherence to it should be represented - in which case we need two separate rows, one for CSS2.1 adherence, and one for CSS3 adherence.

Gyrobo's removal of the section seems to follow a third route - ignoring the existence of CSS3 completely, and also orphaning 5 linked notes at the base of the section.

Thoughts? ɹəəpıɔnı 04:08, 17 December 2010 (UTC)

I'm not advocating that we ignore changes to properties between CSS versions, just that they appear once in whatever iteration they were introduced in. Footnotes can qualify changes in behavior between versions. The fact that there are such changes between revisions was a major issue in Talk:Comparison of layout engines (HTML5)#Splitting out of other sections.
--Gyrobo (talk) 04:15, 17 December 2010 (UTC)
Just realized you were in that conversation also. I guess we're finally going to sort out how to handle this.
--Gyrobo (talk) 04:17, 17 December 2010 (UTC)
The HTML5 page is more an issue of size, rather than of version numbers (as it is an entire page dedicated to version 5). We could have separate pages for CSS2.1 and CSS3, but I think that might be overkill, which is why having separate sections will suffice I think.
If you're not advocating changes between specs, how are you suggesting we display whether or not browsers do or don't comply to the latest spec. We could just mark them all with partial support, but I think that would misrepresent the fact they supported a previous iteration.
I really don't see the problem with the separate sections I reverted to. It's clear, complete, unambiguous - there seems no disadvantage to doing it that way - it gives the reader all the information they may want. ɹəəpıɔnı 03:30, 24 December 2010 (UTC)
The problem I see is that it creates a situation where some properties will become useless. If properties are listed twice, once for CSS2 support and once for CSS3 support, and the behavior has changed, the older field will be of diminishing value. The way I read the article, a property appears under whatever version of CSS it was introduced under, but the support level refers to the current behavior defined by the most recent spec. Any deviation from the most current spec can be detailed in a footnote as a result of changes between CSS revisions. Having the same property listed under more than one revision of CSS risks causing confusion; someone may wonder if a property that was unchanged between revisions, and hence not listed twice, still exists in the current spec. Or they may wonder if the behavior has changed, and just isn't listed.
--Gyrobo (talk) 03:40, 24 December 2010 (UTC)
Gyrobo, I understand what you are saying, but I don't agree with it. Take text-indent for example. All browsers support it fully in 2.1 (value, percentage), but none support it for 3.0, hanging and each-line. By making two lines, it tells the user that one, anything that one would expect from the 2.1 specification works, but what is new does not work. If a person only sees one line, than it is assumed that the specification did not change between version 2.1 and 3.0. If an item is deprecated, then there needs to be a notation for deprecated under 2.1. If it has changed, then write deprecated under 2.1 and its current status under 3.0. To mark text-indent as incomplete would be confusing to the user, because a person would not understand why it is incomplete. Does the old notation no longer work or has something been added? That is the question that the table must answer for the reader, and that is the question that the table does not answer. — Preceding unsigned comment added by Zzmonty (talkcontribs) 02:48, 15 December 2011 (UTC)

writing-mode property[edit]

According to, the draft for writing-mode property is still under progress. Is there an authenticity to the reason why Trident's implementation is compared with that of Webkit's to justify its incorrectness? Or is it some MacMan’s personal grudge? --Pak1standby (talk) 01:40, 11 March 2011 (UTC)

CSSOM View module[edit]

The article is missing this CSS module: (talk) 21:38, 13 March 2011 (UTC)

text-decoration-style and text-decoration-color[edit]

Can someone please add a section for the two items above under CSS3 text. These are both supported in Mozilla Firefox 5 nightly per bug 59109. — Preceding unsigned comment added by RyanJones (talkcontribs) 19:06, 31 March 2011 (UTC)

Trident's support for CSS 2.1[edit]

In the "CSS version support" section, Trident's support for CSS 2.1 is listed as "Mostly", however looking through the rest of the tables on the page, I can't find any CSS 2 properties that Trident (as of IE 9.0) doesn't fully support. Is it safe to say that "Mostly" can now be changed to "Yes"? Mlms13 (talk) 18:33, 29 April 2011 (UTC)

I think the tables are outdated. For example "text-overflow" is fully supported by Opera... Someone with time should check the table and update it. --APPER (talk) 14:39, 8 June 2011 (UTC)
Here you can find the offcial W3C CSS 2.1 conformance test results. IE is clear leader in CSS 2.1 support over all other current browsers. (talk) 19:07, 29 June 2011 (UTC)

PRINT properties, replacing PDF![edit]

For "standard Wikipedia readers" is very difficult to compare engines in the "print" aspect.

The CSS2 @page, page-break, etc. properties and CSS3 page, size, column, break, etc. are essential properties for print, and for web browser to compete with softwares like "PDF readers".

SUGESTION: a section for "print properties" in the article. — Preceding unsigned comment added by (talk) 06:46, 6 July 2011 (UTC)

YES, and there are 3 possible topic names: "Typography", "Paged media", "Print Profile". — Preceding unsigned comment added by (talk) 21:05, 21 July 2011 (UTC)

Add a new table[edit]

Some properties evolves with CC3, I think it would be good to detail this: for example. Zéfling (talk) 12:59, 10 December 2011 (UTC)

I was going to bring up with same issue. But I personally think that your table is too detailed for one article. The specification is 10 separate PDF files. What about this format: User:Zéfling/Test#2nd example for text-indent I just added my example to end of yours. Hope that you don't mind. — Preceding unsigned comment added by Zzmonty (talkcontribs) 02:35, 15 December 2011 (UTC)

CSS version support[edit]

I've decided to go remove the CSS version support summary table at the top. Before you go reverting those changes, let me explain my rationale:

  • There is no static "CSS3" version, so no browser can ever claim full support for it. Furthermore, it invites people to bikeshed over things like "mostly", "partial", or "slight" in terms of support.
  • CSS1 is effectively dead as far as anyone is concerned.
  • It's not clear what the objective criterion of "full support" for CSS 2.1 should be, since no browser (as of this writing) actually passes 100% of the CSS 2.1 conformance tests, and the test reports are not being run on a regular basis.
  • Therefore, the table is pretty much worthless as far as conveying information is concerned.

If you decide to revert my changes on the basis that the table is useful, define objective criteria for deciding when entries move to mostly/partial/slight, or consider referencing CSS snapshots instead of versions. (talk) 04:15, 25 February 2012 (UTC)

: -moz-any-link and :-webkit-any-link[edit]

Should we note :any-link with prefixes are supported in CSS4 colomn ? It's not really experimental... — Preceding unsigned comment added by (talk) 10:17, 21 July 2012 (UTC)

done for Gecko, but I couldn't find the correct reference for webkit ( ) — Preceding unsigned comment added by Retrovertigo en (talkcontribs) 07:43, 21 December 2013 (UTC)

Move discussion in progress[edit]

There is a move discussion in progress on Talk:Comparison of web browser engines which affects this page. Please participate on that page and not in this talk page section. Thank you. —RMCD bot 15:44, 7 September 2012 (UTC)

Trident =! IE[edit]

Everywhere Trident is mentioned, it reference to the version number of Internet Explorer, Trident has a sepperate versioning: IE7 and lower has Trident, IE8 has Trident 4, IE9 has Trident 5 and IE10 has Trident 6.-- (talk) 16:22, 29 November 2012 (UTC)

There should be change this, but I do not know well enough IE for do it. Zéfling (talk) 10:34, 16 August 2013 (UTC)
It could be done refering to this article I guess:, but how should it be layed out in the table? "Trident ( IE )" in the column header and to us "!important" as an example this numbering "- ( 7.0 )" and "@namespace" as a second example this numbering "5.0 ( 9.0 )". Ona side note I wanted to mention that this would make it more exact, but also harder to read from my perspective as a developer. Retrovertigo en (talk) 07:09, 21 December 2013 (UTC)

Add Blink column in all tables[edit]

Now, Chrome and Opera use Blink (a fork of Webkit). I think that it's a new column for these web browsers. Zéfling (talk) 10:27, 16 August 2013 (UTC)

Should probably replace the Presto column. (talk) 19:06, 20 February 2014 (UTC)
There are still some people browsing with the pre-Blink version of Opera. So I would have thought of replacing Prince, but to be honest I have no idea how widespread/relevant Prince is. Who would be the one to make such a call? Retrovertigo en (talk) 06:42, 23 November 2014 (UTC)

break-inside support update[edit]

If you reference the two footnotes for break-inside (under multi-column layout), it looks like those two engines with No and a footnote, actually now support column break-inside. Someone want to verify my findings to confirm and edit? (talk) 20:33, 25 February 2014 (UTC)