Talk:Comparison of layout engines (HTML5)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
edit·history·watch·refresh Stock post message.svg To-do list for Comparison of layout engines (HTML5):
  • Add references where appropriate.
  • Add version numbers where needed.
  • Decide what to do with features that aren't in HTML5 proper, but are considered part of the HTML5 ecosystem. (Currently in the "Related specifications" section.)
  • Add HTML5 features that aren't yet in the article (including parsing, etc.).

? cells[edit]

Why did you remove the unk template ? --Fenring 20:46, 27 July 2007 (UTC)

I changed the {{unk}} to ? simply because I thought it looked better, it takes up a lot less room and conveys the same information -- Gudeldar 23:25, 29 July 2007 (UTC)
What about the {{dunno}} or {{?}} templates ? --Fenring 00:16, 30 July 2007 (UTC)
It doesn't really matter to me if you want to use the style="background: #ececec; color: #2C2C2C; font-size: smaller; vertical-align: middle; text-align: center; " class="unknown table-unknown"|? or ? template to me, in fact I'm not sure why I didn't change it to the {{?}} template -- Gudeldar 13:59, 30 July 2007 (UTC)
I will add / added the {{?} template in othe comparisons. I think that this indicates more to users that this cell need more research and somebody need to look after. it is fixing the focus of a user on this particular cell... Mabdul (talk) 23:25, 12 April 2008 (UTC)

Thirdparty libs[edit]

Why removing useful notes about thirdparty libs ? (the other comparisons pages have plenty of them: example) --Fenring 20:46, 27 July 2007 (UTC)

Perhaps your right, I will add the notes back but I don't think that the cells should have a link to the notes -- Gudeldar 23:25, 29 July 2007 (UTC)

Title of this article[edit]

Shouldn't we change the title of this article to Comparison of layout engines (HTML5) ? If we do, should we integrate the HTML5 features in Comparison of layout engines (HTML) ? --Fenring 20:46, 27 July 2007 (UTC)

Your probably right about that too, WHATWG is the name of the body that is trying to get these features standardized, although the W3C has adopted the WHATWG recommendations for its HTML5 working group. I don't think that it should be included in the Comparison of Layout Engines (HTML) because that would just be confusing -- Gudeldar 23:25, 29 July 2007 (UTC)
I will rename the article. The question of merging with Comparison of layout engines (HTML) should be reconsidered when it becomes a recommendation. --Fenring 00:16, 30 July 2007 (UTC)

Structure and sections[edit]

Should we put the two tables in common (afaik, html5 doesn't do the difference) ? --Fenring 20:46, 27 July 2007 (UTC)

I'm in favor of merging both tables into one, perhaps separated by a row header. -- Gudeldar 23:25, 29 July 2007 (UTC)
If we don't completely merge the two tables, and keep both features separated by a header, I would rather keep the table in separated sections. Long tables are terrible, to read, to edit. --Fenring 00:16, 30 July 2007 (UTC)

Columns Header[edit]

I agree this article is part of the "comparison of layout engines" and is named after them. But the HTML5 features involves more than the layout engine of a browser. It is related to the scripting engine also. So like in the Comparison of layout engines (ECMAScript), shouldn't we choose other titles than the layout engines (gecko, presto, ...), and simply use the browsers name ? --Fenring 20:46, 27 July 2007 (UTC)

AFAIK the layout engine is the part responsible for implementing these features not the overall browser, for example IceWeasel which is based on Gecko would support all the same features as Firefox because they both use Gecko -- Gudeldar 23:25, 29 July 2007 (UTC)
Not strictly speaking. HTML5 defines some scripting API (ie: getElementByClassName). A browser can use a full HTML5 compliant layout engine (say Gecko 5.0) while still using a script engine that doesn't support getElementByClassName. --Fenring 00:16, 30 July 2007 (UTC)
getElementByClassName is a DOM object, and is a host object implemented by the rendering engine. It is not part of the scripting engine, and to take Opera for example, they recently changed their scripting engine, but it's still the same host. (There may be some changes in the host to better accomodate the new scripting engine, but I still think you see my point.) -- liorean 14:07, 25 January 2008 (UTC) —Preceding unsigned comment added by Liorean (talkcontribs)
Ok, I finally think having consistencies between the other comparison articles is better. I'll replace safari by webkit as it includes webcore and javascriptcore. It's a pity the other vendors make no distinction between the layout engine and the application framework (or maybe they do). Anyway, one can say spidermonkey is part of gecko, too. --Fenring (talk) 12:09, 5 January 2008 (UTC)
What WebKit is to WebCore, XPFE is to Gecko. And I'm sure if you dig deep enough you'll find something similar for IE, too... --Grey (talk) 22:16, 6 January 2008 (UTC)


I didn't put any IE column initially, because all the lines would be no. but... shouldn't we ? --Fenring 20:46, 27 July 2007 (UTC)

I think that IE should be included even if the answer to all the questions is no. -- Gudeldar 23:25, 29 July 2007 (UTC)
Don't be so sure, many HTML5 features are just standardization of de-facto standards. For instance don't IE support both contenteditable and autocomplete? Carewolf 14:59, 30 July 2007 (UTC)


No browser is 100% perfect in its support for Canvas. Wouldn't it be better with some percentage instead of yes or no?--itpastorn (talk) 20:42, 3 February 2008 (UTC)

I have changed the results to partial. For more info, visit --itpastorn (talk) 17:20, 9 March 2008 (UTC)

Dumping reference about IE 8[edit]

IE 8 B 1 has a few HTML 5 features. I was chatting with one of the main contributors to HTML 5 tests (Philip). The logs are down right now, but they are at (Look at March 15). I got this tip: We should update the table to say that MSIE 8 b 1 supports client side storage and a few more things. I have not got the time to do it for a few days though.--itpastorn (talk) 13:36, 15 March 2008 (UTC)

Safari (WebKit) Updates?[edit]

According to the new Safari 3.1 update, support has been added for the <video> and <audio> tags, as well as some other non-related things. The link to the update's information page is if anyone wants to check on these. Both of those tags are marked as "Nightly build" levels, so maybe they need updated? --Michael Herold (talk) 04:18, 20 March 2008 (UTC)


This version is Safari. Not is WebKit. WebKit layout engine, up to CSS Reflection, CSS Masks, CSS Canvas Drawing, CSS Gradients, GDI Text, querySelector, querySelectorAll, Native getElementsByClassName, Web Inspector with Inline CSS Editing, Support for Downloadable Fonts,Database Browser, New CSS Properties, Multi-plataform Support, HTML 5 Media Support, and more —Preceding unsigned comment added by (talk) 13:00, 10 May 2008 (UTC)

give us the correct verion of webkit...Mabdul (talk) 15:12, 10 May 2008 (UTC)
Only stable releases count. For the time being, webkit "version numbers" follow Safari releases, because WebKit only has build numbers and there is no stable builds (at least none I can see). Hence I think that's the right way to do it. --Grey (talk) 17:16, 11 May 2008 (UTC)
Bollocks. Webkit != Safari. The WebKit browser summary lists Chrome as using a later version of WebKit than Safari. If you want to pin it to a browser release, pin it to the most up-to-date in that list. —Preceding unsigned comment added by (talk) 12:22, 21 October 2009 (UTC)

Gecko audio/video[edit]

According to [1], much progress has been made since the last update to this article regarding that, but I'm unsure of exactly how the article should be changed to reflect this. It's not part of the usual nightly builds, although they are available to everyone at [2]. —Preceding unsigned comment added by Asztal (talkcontribs) 12:29, 30 May 2008 (UTC)

Trident support? Version number for engine or browser?[edit]

It appears to me that Trident (IE) supports several features of WebForms 2.0. Why then does this page show "NO" for almost all of them? I see no reference or external link that supports this. In particular, here is a web page that demonstrates several WF2.0 features working in IE: PenguiN42 (talk) 21:58, 17 February 2009 (UTC)

NEVER MIND!!! With a bit more research I have discovered that the above demo is using a special javascript add-in for IE to support the WF2.0 features. They aren't built in to IE after all. PenguiN42 (talk) 22:03, 17 February 2009 (UTC)
The tables of supported features seem to be listing the IE8 browser version number, 8.0 rather than the Trident version number corresponding to that browser. Based on the info in Trident (layout engine) those "8.0"s should be "5.0".
IE8 == Trident 4.0! and the work is going on, see Talk:Comparison of layout engines (CSS) for th discussion. I will start in a few days if I find enough time! mabdul 00:29, 14 May 2010 (UTC)
Putting "4.0" and "5.0" instead of "8.0" and "9.0" is technically correct, which as we know is the best kind of correct. If we care about facilitating reading comprehension, we ought to consider alternative, slightly more verbose cell contents, such as "4.0 (IE 8.0)" and "5.0 (IE 9.0)" (talk) 07:27, 20 May 2010 (UTC)

Presto version number[edit]

The article currently seems to be using the version number of the Opera browser instead of the version number of the Presto layout engine (currently 2.2) —Preceding unsigned comment added by (talk) 23:17, 29 June 2009 (UTC)

I fixed this a while ago. —Ms2ger (talk) 20:15, 7 January 2010 (UTC)

Changes to references[edit]

I changed the way references are handled on this page to group them by engine:

 <ref group="note"/> → Note
 <ref group="t"/> → Trident Ref
 <ref group="g"/> → Gecko ref
 <ref group="w"/> → Webkit ref
 <ref group="p"/> → Presto ref

Does anyone have any feedback? I'd like to do this on the other comparison pages. --Gyrobo (talk) 23:14, 7 February 2010 (UTC)

I do find this a very good feature that you tested here ;) It become so more readable and the tables don't such a big space between them... mabdul 00:24, 8 February 2010 (UTC)

Add/remove engines discussion[edit]

There is a discussion going on at Talk:Comparison of layout engines (Cascading Style Sheets)#Adding new engines regarding which engines should be added to/removed from the comparison pages. Requesting the participation of any interested parties. --Gyrobo (talk) 02:24, 18 February 2010 (UTC)

Firefox placeholder[edit]

Firefox seems to have added the placeholder attribute(, but I'm not sure which version it will appear in. In one hand, this should probably be "Experimental"(and this part of the information is reliable), but the article currently references the version number, which I can't be sure of. What should we do? Add just "Experimental" and leave it different from everything else? Just "assume" it will be available in 1.9.3? Either way, saying it doesn't support placeholder is clearly outdated. —Preceding unsigned comment added by (talk) 18:57, 26 February 2010 (UTC)

If the bug for an unsupported element/property/feature is resolved, it changes from {{no}} to {{nightly|«next version»}}
--Gyrobo (talk) 19:09, 26 February 2010 (UTC)

Separate HTML5 Audio/Video Article?[edit]

Tables for audio/video codec support were recently added to this article. Should there be a separate comparison page specifically for HTML5 Audio/Video support? Such an article would include not just supported codecs, but any elements, attributes, DOM bindings and anything else related to HTML5 Audio/Video. --Gyrobo (talk) 18:20, 5 March 2010 (UTC)

I do think only one article is enough! html5 media. We don't need to separate them. see discussion down on this page! mabdul 16:42, 15 March 2010 (UTC)

Splitting out of other sections[edit]

I was very surprised to see the recent splitting out of HTML5 Media, as video/audio make up quite a small part of the the overall HTML5 spec, so I didn't really think they would warrant an entire article. Or at least, I thought other sections of the spec. would warrant more space than Media would. However, following the split, the Comparison of layout engines (HTML5 Media) article looks quite good, and it seems to have been a good idea. Given that, perhaps other (in my view more substantial) sections of HTML5 would benefit from being split out.

Mainly, the APIs which now have a pitiful single table-row each in this article, despite the fact that the likes of Web Storage, Web Database, Web Workers et al are enormous specs in themselves, with many distinct elements within them.

May I suggest splitting into Comparison of layout engines (HTML5 Markup) and Comparison of layout engines (HTML5 Related APIs), or something similar... ? ɹəəpıɔnı 15:16, 12 March 2010 (UTC)

This article has so far been a catch-all for every aspect of HTML5. Sections should certainly be split out where such an article would be substantial -- I for one would love a comparison page on the Canvas element. We could even create a separate row in Template:Layout_engines specifically for HTML5 comparison articles.
--Gyrobo (talk) 17:49, 12 March 2010 (UTC)
A further point of interest: the page Comparison of layout engines (HTML) only documents support of HTML4 elements and generic attributes. I believe the article should contain information on all elements and attributes (in summary, all HTML Markup) from both HTML4 and HTML5.
--Gyrobo (talk) 16:32, 13 March 2010 (UTC)
I hadn't considered that page.. in reality I'd say that should've been named Comparison of layout engines (HTML4) all along, should it not?
As for putting HTML4 and HTML5 Markup all on the same page, I'd say that would be a bad idea - the markup included on this page now only encompasses *new* elements in HTML5, whereas HTML5 does actually include many elements from HTML4, and, perhaps more importantly, excludes some elements from HTML4. On top of that, some HTML4 elements have changed their usage definitions. Putting the two markup specs on one page would be highly confusing.
I'd say rename Comparison of layout engines (HTML) to Comparison of layout engines (HTML4) and split this article into Comparison of layout engines (HTML5 Markup) and Comparison of layout engines (HTML related APIs) - after which the related APIs one can be split further into Canvas 2D, et al as it grows, if necessary. ɹəəpıɔnı 19:29, 13 March 2010 (UTC)
Several properties in CSS2.1 were changed in CSS3, but Comparison of layout engines (Cascading Style Sheets) doesn't distinguish altered behavior between specs, just whether the property is supported. As for dropped/deprecated elements/attributes, Comparison of layout engines (Non-standard HTML) has a section devoted specifically for that. Since HTML5 is a (rough) superset of HTML4, it makes sense to include all markup in one page. There aren't separate pages for CSS2 and CSS3, or SVG1.1 and SVG1.2, so all markup comprising HTML (regardless of version) should be in one page.
--Gyrobo (talk) 20:54, 13 March 2010 (UTC)
That's true about the CSS comparison, but it has actually become a problem with that page and I have commented to that effect (not on the talk page there, but on one of my edits) - the current draft of the CSS tables are extremely inaccurate as a result. A split of that article might not go astray, though given CSS is a comparatively smaller spec overall, I don't think it will really be necessary, just a slightly complex cleanup should do there.
The alternative suggestion would be to follow HTML5 spec in an "HTML Markup" article, and relegate HTML4 markup to the "deprecated" sections in the "Non-standard HTML" article. However as HTML5 is currently officially classed as a working draft, and likely to remain so until 2022, now would be far too soon to do that - while people are making HTML5 sites, HTML4 is the current recommendation, so they need to be shown concurrently. I do think this would be far clearer if they were kept separate, and would also make editing easier when it is time to relegate HTML4 to "deprecated". ɹəəpıɔnı 13:51, 14 March 2010 (UTC)

we should rename the article: Comparison of layout engines (HTML) to Comparison of layout engines (HTML4). or what do you think? mabdul 14:36, 14 March 2010 (UTC)

@Mabdul - Yes, that is what I was suggesting. ɹəəpıɔnı 17:28, 14 March 2010 (UTC)
But if the markup comparisons for HTML4 and HTML5 become separate pages, won't the HTML5 page duplicate much of the tables in HTML4? Also, I support separating HTML5 markup from the related APIs. I don't think I mentioned that earlier.
--Gyrobo (talk) 19:41, 14 March 2010 (UTC)
@Lucideer oh, ah I understand. I read again ;) @Gyrobo I'm not so familiar with the new html5 specs: Are any parts of HTMl4 replaced/removed? Otherwise I would include a short sentences that html5 is including all the standards which are created/included/changed in html4... mabdul 20:49, 14 March 2010 (UTC)
@Mabdul: there are several differences between HTML 4 and 5, some elements/attributes have been dropped/deprecated, and some behaviors have been changed. The more we discuss this, the more I believe Lucideer is correct for trying to keep the articles separate and avoid the issues of the CSS article.
--Gyrobo (talk) 23:31, 14 March 2010 (UTC)

now a totally new alternativ. I started a few month back, bud didn't find any Idea to integrate this: User:Mabdul/sandbox. As you can see, I never finished my work. Maybe this should be an alternative... mabdul 09:45, 15 March 2010 (UTC)

A small amendment to my original suggestion - I don't think HTML should be renamed to HTML4 - rather the HTML article should reflect the current recommended version of HTML (which it currently does - so I would leave that article as is), whereas a future iteration of HTML is denoted by being versioned (as this one currently is).
So to summarise, I'd say leave Comparison of layout engines (HTML) as is with no change, split this article into Comparison of layout engines (HTML5 Markup) and Comparison of layout engines (HTML5 Related APIs) - this can later be renamed to Comparison of layout engines (HTML Markup) and Comparison of layout engines (HTML Related APIs) in 2022 or whenever HTML5 becomes recommendation. ɹəəpıɔnı 14:02, 15 March 2010 (UTC)
Ok, but what happen to the Comparison of layout engines (HTML5) article? I mean, why not merge all the articles in one: the other are also long. I don't think that it is necessary that video and other parts have their own articles. (topography is ok since it comvers differen technics!) what happens to the new canvas2d and metadata specs? should we also cover these in extra artciles? mabdul 15:02, 15 March 2010 (UTC)
Comparison of layout engines (HTML5) would be renamed to Comparison of layout engines (HTML5 Markup), to clarify the distinction between it and "Related APIs". One could include all related APIs in this article without a split, but it would be huge - each of the APIs is quite large, the current single table row for each is an extremely deficient representation of support - it's equivalent to saying a browser does or doesn't support HTML5 Markup, whereas clearly they all have varying levels of support. ɹəəpıɔnı 16:38, 15 March 2010 (UTC)
ah. ok. ok That seems to work for me. should wikipedia really cover alle the support (esp. the apis)? Or is it not enough? I give my go! We should make a longer description/introduction on every page explaining the whole html5 stuff (and the maybe releasedate 2022!) mabdul 16:45, 15 March 2010 (UTC)

OK, in that case, does this make sense? :

  • "Form elements and attributes", "Elements" and "Attributes" should go under HTML5 Markup
  • "APIs" and "Related specifications" under HTML5 Related APIs
  • From "Other features" - "Microdata", "Parsing" and "noreferrer" go under HTML5 Markup, "window.onhashchange" and "element.classList" I'm not too sure about. ɹəəpıɔnı 18:05, 18 March 2010 (UTC)

Future support[edit]

Just thought I'd further explain my revision. The {{nightly}} value, when it was added to Template:Explanation of the tables2, was intended as a catch-all for any properties/elements that either already exist in a nightly build ("supported to some extent in an experimental/nightly build"), or have been announced ("Future support is expected").
--Gyrobo (talk) 16:21, 18 March 2010 (UTC)

Then it should be called something else. "nightly" logically means "present in a nightly build", not "future support is expected". —Aryeh Gregor (talk • contribs) 17:30, 18 March 2010 (UTC)
I don't really any real benefit in documenting what may be supported in future... Everything here could be supported at some point.
I understand, given users do have free and open access to every iteration of all open source engines, there is something of an imbalance whereby closed-source browser engines may have non-public builds which contain features not listed here. This does make the table look somewhat less favourably on Trident and Presto, but this is just the nature of how open-source works. ɹəəpıɔnı 17:58, 18 March 2010 (UTC)

“Everything here could be supported at some point.”

Yes, but {{nightly}} indicates concretely that support is forthcoming.

‘"[N]ightly" logically means "present in a nightly build", not "future support is expected".’

True, but as Lucideer said, this unfairly penalizes closed-source engines which may very well have support enabled in internal builds. I don't feel the need to create a separate table value specifically for closed-source roadmaps.
--Gyrobo (talk) 19:22, 18 March 2010 (UTC)
While I did say Opera and Trident are unfairly penalised, I think the point that I was attempting to make is that penalising them is simply a reflection of reality. Wikipedia is not here to re-balance such imbalances, it's here to represent facts as facts, regardless of how fair/unfair those facts may be to certain parties. ɹəəpıɔnı 19:44, 18 March 2010 (UTC)
Would {{pending}} be good for representing future support, then?
--Gyrobo (talk) 19:47, 18 March 2010 (UTC)
I'm still not convinced it adds anything to the article, but.. maybe {{planned}} ? ɹəəpıɔnı 00:50, 19 March 2010 (UTC)
My view is that we should leave the article as it currently is, keeping {{nightly}} as a catch-all for future support. Like you said, it doesn't really add to the article to differentiate such similar conditions.
--Gyrobo (talk) 01:07, 19 March 2010 (UTC)
{{nightly}} is fully ok. The rest "problems" which we get aren't enough to splitter the or change the rest. mabdul 10:47, 19 March 2010 (UTC)

missing specified attributes[edit]

What about the script defer attribute? -- (talk) 16:16, 13 April 2010 (UTC)

defer is part of HTML4. Luiscubal (talk) 17:34, 21 September 2010 (UTC)[edit]

Hey, maybe add reference to html5 test site in the article?

That's an unofficial website, which probably doesn't meet the rules for external links. If we added links to every website like that, we'd have way too many links. —Aryeh Gregor (talk • contribs) 16:57, 26 April 2010 (UTC)
I wolud add this page. The development is also adding more test. nobody says that inoffical lnks aren't allowed! mabdul 18:54, 26 April 2010 (UTC)
I agree -- there are already many unofficial sites like this on the comparison pages and related articles, and overall, they are helpful.
--Gyrobo (talk) 19:04, 26 April 2010 (UTC)
Ok -- what about adding a table analog to ? A nice overview of the current status of each browser on the above mentioned test. —Preceding unsigned comment added by (talk) 21:10, 16 June 2010 (UTC)

Firefox & Inline MathML and SVG[edit]

Since the HTML5 parser is now enabled by default in the current nightly builds, should these items be changes to nightly too? —Preceding unsigned comment added by RyanJones (talkcontribs) 22:13, 4 May 2010 (UTC)

Splitting up "Form elements and attributes"[edit]

Should the section on Form elements and attributes be split up? There are already separate sections for new elements and attributes. Would it make sense to move the form elements to the elements section, and the form attributes to the attributes section, or keep all form elements/attributes together?
--Gyrobo (talk) 14:41, 5 May 2010 (UTC)

Question regarding WebKit placeholder support[edit]

When I tested the form attribute "placeholder" in Chrome, it worked exactly as expected, and even displayed the placeholder in a lighter font color like it ought to. So why is WebKit's placeholder attribute support listed as "Partial"? -- (talk) 01:20, 16 May 2010 (UTC)

  • Good point, I've changed it. If anyone knows why it was marked as Partial, feel free to revert my change, but please also state a reason/leave a reference.--Zirrozify (talk) 21:12, 16 May 2010 (UTC)

Web Database[edit]

Since Web Database seems to be unlikely to ever be standardized(as noted by the spec itself), I don't think it is relevant to have it in the article. As far as we're concerned, it is basically as much of a W3C standard as VML. Therefore, I propose removing it from the article. Eventually, we'll want to add Indexed DB to the article(although it might be a bit too early for that). Luiscubal (talk) 18:05, 27 May 2010 (UTC)

Web Database has been implemented by three out of five of the most popular browsers - not comparable to VML in any way. Why was this edit not objected to immediately when it was done?
If the relative "stability" of a spec. is a reason not to include it here, then a lot more than WebDB should be removed from the article. Beyond that, Wikipedia doesn't speculate about what will or won't happen within the W3C. (talk) 20:36, 14 June 2010 (UTC)
This wasn't objected to because, as it says in the Web SQL Database spec, "all interested implementors have used the same SQL backend (Sqlite), but [the specification] need[s] multiple independent implementations to proceed along a standardisation path." This has nothing to do with stability; the specification just doesn't have enough different implementations to proceed.
--Gyrobo (talk) 21:10, 14 June 2010 (UTC)
The spec itself claims that an "impasse" has been reached:
"This specification has reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. Until another implementor is interested in implementing this spec, the description of the SQL dialect has been left as simply a reference to Sqlite, which isn't acceptable for a standard. Should you be an implementor interested in implementing an independent SQL backend, please contact the editor so that he can write a specification for the dialect, thus allowing this specification to move forward."
So Web SQL at this point is looking just like VML. A candidate standard which failed and has been replaced(VML by SVG, Web SQL by Indexed DB).
Should the impasse be solved, then by all means we should add it back. And, by the way, regarding " then a lot more than WebDB should be removed from the article", which specs are in the same dead-end situation as Web SQL? Luiscubal (talk) 14:34, 19 June 2010 (UTC)
I've read the spec, but the facts remain - it was drafted by the W3C, it is deemed related to HTML5 and it HAS BEEN IMPLEMENTED - beyond that, I see no extra criteria precluding its inclusion here. ɹəəpıɔnı 22:37, 19 June 2010 (UTC)

Gecko 2.0[edit]

Gecko 1.9.3 is "in the process of being renumbered to Gecko 2"(as seen in Firefox 4 for developers). I've replaced the nightly version of Firefox in the article from 1.9.3 to 2.0. If someone thinks it's too early, feel free to revert. Also, it might be the case that the correct version number will be "2.0.0" and not "2.0", but I've left it just 2.0 since I could find no information on this topic and, besides, the article already uses "1.9" instead of "1.9.0". Luiscubal (talk) 15:19, 27 June 2010 (UTC)

Probably a good idea.
--Gyrobo (talk) 18:13, 27 June 2010 (UTC)

Regarding Gecko HTML5 forms references[edit]

Up to now, I've been looking at Mozilla's wiki and bugzilla to know when to update support from "No" to "Nightly (2.0)". However, looking at the wiki's history it appears that development has frozen. Up to now, assuming otherwise would be original research. However, I've discovered a patch queue showing that there is indeed progress and that some elements do have nightly support. Should we use this page as new reference and update the HTML5 forms table or should we keep using the Bugzilla/Wiki? Luiscubal (talk) 17:50, 9 July 2010 (UTC)

  • Mounir, who is the primary developer when it comes to HTML5 forms in Gecko is currently away until the 12th of July. That's likely the reason as to why work appears to have stalled. And yes, there are many patches ready, but not yet checked in. As long as they are not checked into mozilla-central, there is no guarantee that they will make it into the final version. I think that we should leave them as "No" until the patches in question are checked in. --Zirrozify (talk) 19:31, 9 July 2010 (UTC)
    • Actually, I misread that patch queue page. I saw the progress element patch and forgot the 6th month was June and not July, so I thought there *was* indeed progress(9th July was today and I thought there was progress today rather than one month ago). So my first comment probably doesn't make much sense. Just ignore it. Luiscubal (talk) 22:26, 9 July 2010 (UTC)

Can device technically be considered HTML5?[edit]

The device element is not in the W3C version of HTML5. It is only in WHATWG's HTML5 "(including next generation additions still in development" which "actually now defines the next generation of HTML after HTML5"(see the "Is this HTML5?" section). As a result, the WHATWG-specific features of HTML can't really be considered HTML5(they *could* be called "HTML6", but no official name has been given). Device is one of those WHATWG-specific features. So, since this is about HTML5, should we remove device from it(or at least move it to the same category as Web Workers, Indexed DB, etc.)? Luiscubal (talk) 21:51, 15 July 2010 (UTC)

  • I think a new "HTML6" section within this article, would do. I've seen it mentioned myself that not all features currently defined in the WHATWG HTML5 spec is going to be a part of the HTML5 standard. Which means, they are meant for a new version of HTML. When the "HTML6" section grows too large for this article, we could move it to it's own article. What do you say? --Zirrozify (talk) 22:17, 15 July 2010 (UTC)
    • Let's not call it "HTML6", though. Let's call it "Future features" or something like that, since technically there is no official name. Luiscubal (talk) 13:58, 16 July 2010 (UTC)
    • Done. I've added the section. Although it might not be perfect, it's a good start. Luiscubal (talk) 14:14, 16 July 2010 (UTC)

Comparison of layout engines (HTML5 Media)[edit]

Currently, there is an article in Wikipedia called Comparison of layout engines (HTML5 Media). The contents of that article are very relevant to this article as well, so shouldn't we add a link to it somewhere? My first thought was to replace the <video> link to that article, but the article is HTML5 *Media*, not just video. So what would be the best way to deal with this? Also, does it make sense to have two separated pages for HTML5 comparison? If so, are then more features that could be in their own article(Comparison of layout engines (IndexedDB), Comparison of layout engines (Canvas), etc.)? Luiscubal (talk) 15:22, 17 July 2010 (UTC)

There was talk about splitting other parts of HTML5 into their own comparison articles, but nobody got around to it. For the media elements, we could include a {{See also}} at the top of the Elements section.
--Gyrobo (talk) 16:06, 17 July 2010 (UTC)
Was there a consensus to do it but nobody actually bothered or was there no consensus? Because if there was a consensus, I could easily split it myself. Luiscubal (talk) 20:48, 17 July 2010 (UTC)
Ah, never mind. I found the section. The debate seems to have ended early, though, with no conclusions. Perhaps it is time to finish it? Luiscubal (talk) 21:10, 17 July 2010 (UTC)
Yeah, I think we got sidetracked by what to do with HTML4. If you wanted to make separate articles for Canvas or Web Workers, or any of the other APIs, I don't think anybody would object.
--Gyrobo (talk) 02:43, 18 July 2010 (UTC)
I'm starting the comparison page for canvas, in an experimental page. Contributions are welcome, but I'm still unsure whether the "Canvas 2D context" part will remain that way, or whether I should also include the getContext/toDataURI functions, and also whether the WebGL spec should be included. So far, it is mostly speculation about Trident and WebKit, since I didn't check and have no references on what they will support, so there is a chance that information on those two might be wrong. However, this *is* an experimental page, so I guess it's acceptable(it will only be unacceptable when the page is migrated). Feedback and edits are welcome. Luiscubal (talk) 22:43, 18 July 2010 (UTC)
 Done I've finished the canvas comparison. It's in Comparison of layout engines (HTML5 Canvas). I removed the "2D" from the name, since the article also compares "toDataURL", "getContext" and (briefly) mentions WebGL. A current TODO is figuring out whether we should also include WebGL in that same article. Feedback is appreciated. Also, what's next? Should we split the HTML5 Forms comparison to a separated page?Luiscubal (talk) 21:30, 20 July 2010 (UTC)
I think a single page for all things canvas is enough, and I don't think HTML5 forms has enough content to merit its own article.
--Gyrobo (talk) 03:02, 21 July 2010 (UTC)

Webkit updates?[edit]

According to this Webkit bug report, Webkit already suports the figure, figcaption, details, summary, command, and menu tags. --Millbrooky (talk) 03:54, 28 September 2010 (UTC)

I can't find the exact bugs where any of those were added.
--Gyrobo (talk) 01:11, 29 September 2010 (UTC)

Web SQL again[edit]

See "Status of this document: Beware. This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further." See also:!/plhw3org/statuses/5369948008349696 Web SQL Database is now "deprecated" (he appears to be a member of the W3C) So I will once again remove Web SQL from the article. --Luiscubal (talk) 12:56, 19 November 2010 (UTC)

There is precedent for keeping track of deprecated stuff (i.e., Comparison of layout engines (Non-standard HTML)). Just because development of the spec has ceased doesn't mean it isn't useful to list which browsers support the spec as it stands; if a new standard comes along to supplant it, it might be nice to know what fallback mechanisms are possible.
--Gyrobo (talk) 15:55, 19 November 2010 (UTC)
Unless I'm missing something, the CSS page specifically mentions that CSS 2.0 is not referenced, as "as CSS2.1 was intended to replace it". The deprecated stuff is in a page *specifically* made for that purpose. I do not think this is the correct page for that. So even if Comparison of Web SQL should be in Wikipedia, this does not seem to be the correct page for that. --Luiscubal (talk) 20:57, 19 November 2010 (UTC)


The release of the HTML5Labs means IE9's support for IndexedDB and Web Sockets has improved. However, I do not know whether this means we should switch to Nightly or Nightly/Partial. Can anyone find a source specifying whether IE9 has full or only partial support? Luiscubal (talk) 17:42, 21 December 2010 (UTC)

Whether it's going to have full or partial support, we should just set it to Nightly. Then when the full version is released, we can change it to either Yes or Partial. --Gyrobo (talk) 22:14, 21 December 2010 (UTC)
That would be inconsistent with what we already do. For instance, Gecko's IndexedDB supported appears as both Nightly *AND* Partial.Luiscubal (talk) 01:03, 23 December 2010 (UTC)
That value is specifically known to be partial. If the level of support is unknown, I'd just stick it as a regular Nightly until more information is available.
--Gyrobo (talk) 01:30, 23 December 2010 (UTC)

Todo list for HTML5 article[edit]

The TODO list mentions adding HTML5 parts that aren't in the article right now, such as parsing. But parsing *is* in the article now. So I think we need to compile a list of TODOs. My first suggestion is encoding detection rules. Any other missing features? Luiscubal (talk) 00:34, 17 January 2011 (UTC)

Global Comparison Page[edit]

We will eventually have to move the "Related Specifications" to other pages. My idea is to create some sort of global comparison page with the various technologies. Something like this:

The table below is JUST AN EXAMPLE, not checked for factual accuracy(since it's not an article)

Trident Gecko WebKit Presto
HTML 4 Yes Yes Yes Yes
HTML 5 Partial Partial Partial Partial
ECMAScript 3 Partial Partial Partial Partial
IndexedDB Partial Partial Partial No

Something like this. For the multiple technologies, such as HTML, SVG, CSS, ECMAScript, IndexedDB, WebSockets, etc. We probably should separate HTML4 from HTML5, CSS1 from CSS2, etc. This could either go to an entirely new page, or to Comparison of web browser engines. Luiscubal (talk) 22:39, 26 January 2011 (UTC)

I think Comparison of web browser engines is exactly the right place for it, because it's so broad in its intent and coverage.
--Gyrobo (talk) 22:44, 26 January 2011 (UTC)
This would be a good idea and the logical move after the full comparison of web browsers --> nearly all in with the exception of the layout engines part(I mean in one table as you exactly described above). If nobody will create such a new table, I will do in 9 days after my exams will be finished. mabdul 23:10, 26 January 2011 (UTC)

What technologies should we include? I mean, HTML, SVG, CSS and ECMAScript are pretty obvious, but others like VML, ActiveX, NPAPI and XUL are not. Perhaps we could separate by categories, like W3C recommendations, W3C drafts, ECMA standards and proprietary technologies.

Trident Gecko WebKit Presto
W3C Recommendations
HTML 4 Yes Yes Yes Yes
W3C Drafts
HTML 5 Partial Partial Partial Partial
IndexedDB Partial Partial Partial No
ECMA Standards
ECMAScript 3 Yes Yes Yes Yes
Proprietary technologies
XUL No Yes No No

Again, the table above is just an example, not checked for factual accuracy Luiscubal (talk) 01:37, 28 January 2011 (UTC)

I would not include the "Proprietary technologies" part. (also not NPAPI or whatever); but you're table looks good for this part. I would add related HTML5 technologies(geolocation, etc.); the xhtml and dom parts and what we already had on the other pages. Image support I would ignore since we could nearly include the complete first table. mabdul 02:47, 28 January 2011 (UTC)

So, let's see, we want HTML4, HTML5, ECMAScript 3, ECMAScript 5, CSS 1, CSS 2.1, CSS 3, SVG 1.1 Tiny/Basic/Full, SVG 1.2 Tiny/Full, all technologies in the "Related Specifications", MathML (versions?), XHTML 1.1, XHTML5 (not sure if its worth to, since right now HTML5-enabled browsers also have XHTML 5), XBL 2.0, DOM 1, DOM 2 and DOM3. Am I missing something? Luiscubal (talk) 00:10, 7 February 2011 (UTC)

Probably canvas too. --Gyrobo (talk) 02:56, 7 February 2011 (UTC)
You mean 2D context and WebGL? Sounds ok. What about Typed Arrays(related to WebGL) Luiscubal (talk) 23:32, 7 February 2011 (UTC)

Possibly Misleading[edit]

I notice that the rendering is tabulated based on the engine represented, and that many specific browsers are listed as examples. This is somewhat misleading because of the implementation of those engines. For example, I have both safari and chrome on my macbook, and there is a marked difference between what is supported by each browser. Both are built on webkit, they're just implemented differently. The way the article is currently constructed, it seems that browsers should render the same based on their rendering engine. (talk) 03:06, 29 January 2011 (UTC)

The reason for that is that chrome is faster in adopting the new version of webkit than apple (safari) is doing it. mabdul 08:42, 29 January 2011 (UTC)
Would it make sense, for clarity sake, to include this disclaimer in the article? (talk) 03:05, 30 January 2011 (UTC)

No support for meta charset?[edit]

The article lists support for attribute charset of element meta as "No" for all engines. I believe this is a major [Citation Needed]. In fact, MDN seems to suggest Mozilla supports it: I'm not going to change this since I have no equivalent citation for the other browsers, but I definitively think the information in the article is either wrong or will require a Note. Luiscubal (talk) 14:37, 27 December 2011 (UTC)

Thanks for the note, Luiscubal - I think I will change it based on the authority of the page which is clearly the result of actual testing. Bosmon (talk) 17:25, 6 February 2012 (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)

When should we remove Presto?[edit]

Opera's decision to drop Presto in favour of Webkit means it should be removed from this comparison at some point. My question to everyone is: when? It makes sense to keep it for now. A large number of users probably still have pre-Webkit Opera browsers, but that won't always be the case.  —Sowlos  17:08, 4 April 2013 (UTC)

I would suggest at least a full calendar year after a non-beta, non-RC, Presto-free Opera has been released for the desktop. Of course there's also the issue of stats, there are countries on StatCounter such as Russia with high Opera usage, which should influence the decision too, plus the issue of Opera in embedded devices such as TVs. I would imagine Blink being added, Presto being removed, and Servo being added, in that order. :) Hexene (talk) 07:44, 16 April 2013 (UTC)

Severely outdated[edit]

This article is severely outdated.I am not for removing Presto yet but we should add blink.Also,all the information on what is and is not supported must be updated. — Preceding unsigned comment added by (talk) 08:46, 9 December 2013 (UTC)

Agree! The lack of Blink is a major deficiency here. And, there ought not to be a rush to remove Presto, which is still widely used. Kace7 (talk) 14:35, 21 April 2015 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Comparison of layout engines (HTML5). Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.—cyberbot IITalk to my owner:Online 14:51, 22 February 2016 (UTC)