Jump to content

Talk:Comparison of browser engines/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2

Merging Articles

I'd like to cast my vote for not merging this article with "List of Layout Engines". If you look at the separate article on "Comparison of Layout Engines (HTML5)", you can see it is a little more useful than this "Comparison of Layout Engines" article. It would be nice if this article itself expanded upon layout engine support of individual XHTML1 tags (and perhaps yet a separate article doing the same for HTML4). Combining all of this information into one article would make it very unwieldy and less user-friendly in my opinion. Biturica (talk) 17:08, 23 November 2009 (UTC)

Actually I just found an article that compares layout engines for XHTML (though it doesn't get to the tag level of specificity). That seems to be the only purpose for layout engine "comparison" articles, to break down at a minute level the support for individual specifications (one spec per article). So in view of that, I guess this generic "comparison" article serves no purpose beyond the "list of layout engines" article, and could actually be merged. The more specific "comparison" articles (by spec) should be retained separately from the "list of" article.Biturica (talk) 17:30, 23 November 2009 (UTC)
I removed the tag sinces there is no discussion any more! mabdul 15:04, 24 February 2010 (UTC)

webcore for linux

Isn't webcore avaiable for linux by now? http://gtk-webcore.sourceforge.net/

Definition of "dropped"?

What's the definition of 'dropped' for the support colum? (Mostly mentioning because IE/Mac is no longer under development, even for OS X.)

But (I believe that) the Tasman layout engine is still used in MS Office for Mac. This is comparison of layout engines, not web browsers. --minghong 15:20, 4 August 2005 (UTC)
In my understanding "dropped" means "while previous versions exist for that platform, the most current doesn't". Therfore, IE Mac shouldn't be listed as "dropped" for MacOS X, imho. Grey 21:35, 4 June 2006 (UTC)
Mozilla products aren't available for BSD any more either.

IE for Unix

What rendering engine does IE for Unix use? It is no longer being developed, but I imagine that puts it into a similar category as IE for Mac. http://www.microsoft.com/unix/ie/default.asp

Wikibooks

Wouldn't the Comparision of layout engines series of articles fit better in Wikibooks than in Wikipedia? Aapo Laitinen 18:23, 30 December 2005 (UTC)

I would like to have at least three more articles:

1. Support for ECMAScript

2. Support for de-facto standards in scripting (innerHTML, XMLHttpRequest, self.offsetWidth, etc.)

3. Support for E4X

And maybe (with all appropriate warnings highlighted)

4. Support for non-standard HTML (old tags like marquee, spacer, etc. and new HTML 5 tags).


--itpastorn 20:32, 12 March 2006 (UTC)

1.) now exists 2.) isn't that the new coming dom0 spec? 3.) part of 1.) 4.) now exists, missing many values! —Preceding unsigned comment added by Mabdul (talk • contribs) 13:23, 30 April 2008 (UTC)

Trident free?

"While the source code is not free, the Trident engine is available as a DLL module for free, excluding the cost of Microsoft Windows." This seems like a strange thing to say. Why should the cost of Windows be excluded?

Good/bad colours for open source

Not everyone holds that open source is "good" and that closed source is "bad". So why are they labelled green and red respectively – colours that are almost universally used to represent "good/bad" and "pass/fail"? El T 02:19, 23 May 2006 (UTC)

It's not a matter of opinion whether open source is good. With open source, companies have the option of hiring someone to fix bugs or add features they want. That is an advantage closed source software does not have. Are you disputing this as a clear advantage? -- Schapel 13:53, 24 May 2006 (UTC)
I'm therewhile not sure if OpenSource should be a category at all. There is a license column that covers all needed facts and more. LGPL/GPL => OpenSource. Proprietary => ClosedSource. Easy as is. Grey 21:26, 4 June 2006 (UTC)
Agreed, while personally I'm an open source proponent the Open Source column is completely redundant, even if you don't know that GPL means open source you can easily find that out by going to the GPL page. I'm removing the column and if anyone has any objections it can discussed further. -- Gudeldar (talk) 19:33, 20 December 2007 (UTC)
Green merely means "yes" and red merely means "no." We're presenting facts. See also the template talk pages. --Karnesky 00:17, 13 March 2007 (UTC)

What's the point of the "latest testing release" column?

The "Latest testing release" column (under release history) is pretty useless. Two products - Gecko and Webcore - claim to be released at least daily, meaning no link to their current testing release is possible. Presto is listed as having no testing release, which isn't true.

But seriously, who is going to update these things once a week, or whenever they're announced? Much better is simply a link to the test release page, if one exists, rather than attempting to name the specific current build. El T 16:27, 21 July 2006 (UTC)

Preparing to delete

I'm sure people must have an opinion on this. But if not, I'll delete the latest release columns in a few days.

I agree, there is no point in continually updating such a trivial piece of data. --Wulf 00:38, 20 October 2006 (UTC)

Tasman

I've changed Tasman's Leading Application to Entourage, given the fact that IE for Mac isn't officially available anymore.

I've also changed it's latest release to 1.0 ("11 May 2004 (?)"). But, I'm not sure that's the proper release date. So, I'll be contacting Microsoft sometime this week, unless somebody already knows the proper date.

Wulf 03:52, 14 October 2006 (UTC)

Update: I've now changed the price for Tasman to $399.99, because the only way to get it is as part Office 2004 for Mac. I'm currently waiting for a response from Microsoft regarding the release date. --Wulf 00:30, 20 October 2006 (UTC)

Update: They've shuffled me off to another team, which I'll be contacting by phone tomorrow. --Wulf 19:19, 22 October 2006 (UTC)

Resolution: Okay, I called the Product Information Team (which actually started off by reading this article to find out ), which called the Office 2004 for Mac team, which directed me to Microsoft Mactopia, where I found somebody's HTTP header from Entourage 2004, which says "User-Agent: … Tasman 1.0…". And, since Entourage was the first public release of Tasman since the set-top box development, the Tasman 1.0 release date should indeed by 11 May 2004… I've updated the article accordingly. --Wulf 21:21, 25 October 2006 (UTC)

What needs to be cleaned up / expanded

I don't see anything that needs cleaning up or expanding in its current form so I am going to remove the tag, unless anyone has objections. -- Gudeldar 14:14, 23 July 2007 (UTC)

It would be good if each products' codebase was documented (e.g., Java, C++ C etc.) —Preceding unsigned comment added by Bcwilmot (talk • contribs) 04:19, 24 February 2010 (UTC)

OK, I integrated the info I found in the articles. Fell free to add information that are missing! More requests? mabdul 15:04, 24 February 2010 (UTC)

Pidgin's layout engine

According to Sean Egan (lead developer of Pidgin), Pidgin has never used GtkHTML. On the other hand, it is also implied in that post that Pidgin may have WebCore support in the future, as a plugin. malept (talk) 02:32, 14 December 2007 (UTC)

Software license

Ok you're right that "Proprietary" is not an license. But look in other software comparisons: they have all this text in the tables. How to you want to tell the reader which license a software/layout engine has, if there isn't any reference (explanation)? Mabdul (talk) 15:07, 2 April 2008 (UTC)

Sorry but if we don't know the correct information we don't just stick in wrong information while we wait for something better to come along. And just because other articles have something wrong, doesn't mean we should make this one match. AlistairMcMillan (talk) 19:51, 3 April 2008 (UTC)
Actually, correct me if I'm wrong, but I don't think any of the layout engines that were listed as using a "proprietary" license are released under any license at all. What I mean is that, for example, Opera/Microsoft/etc don't release their layout engine for anyone else to use. AlistairMcMillan (talk) 20:02, 3 April 2008 (UTC)
ehm, no! The Presto layout engine is used also in other programms (see the presto article!).
Ok here is a list of articles which should had been changed (and some you had changed!):
  • Comparison of layout engines
  • Comparison of e-mail clients
  • Comparison of web browsers
  • Comparison of file sharing applications
  • Comparison of instant messaging clients
  • Comparison of LAN messengers
  • Comparison of Internet Relay Chat clients
  • Comparison_of_Gnutella_software#Software
  • Comparison of DNS server software
and I don't think that this is a full list :p maybe we should think of an alternative. how about to say it is closed source? Mabdul (talk) 20:42, 3 April 2008 (UTC)
All the articles you have listed are fixed. If you can find out what license Opera distribute their layout engine under, please update the article accordingly. AlistairMcMillan (talk) 00:33, 4 April 2008 (UTC)
I don't think that there will be any licence. I think there will be more such thing like a agreement with the company (in this case adobe)... Mabdul (talk) 10:53, 4 April 2008 (UTC)
Oh and I forgot: what about to say it is "closed source" instead of "Proprietary"? If we say it is closed source, we can del the column "open source: y/n" and the comparisons would be clearly arranged by becoming smaller. Mabdul (talk) 10:58, 4 April 2008 (UTC)

Chrome and Safari as leading application

Safari was the first application that uses Webkit. Apple forked KHTML and integrated it in Safari. Safari is the leading web browser on Mac OS X. Chrome is really relative new and is primary on windows. Both applications are under the "leading 5". I would name both! mabdul 15:47, 10 April 2010 (UTC)

Makes sense.  Done --Gyrobo (talk) 16:00, 10 April 2010 (UTC)

I think the "leading" means essentially "most popular". WebKit is the most popular browser on Mac OS X for the same reason that IE is the most popular browser on Windows -- most users don't know what a browser is and just click on the icon they know will "get them on the Internet". Chrome is popular for the same reason that Firefox is -- users choose to download it. It's more popular than Safari, and is also popular on the most popular OS, Windows, where Safari is rarely used. -- Schapel (talk) 23:25, 10 April 2010 (UTC)

Agreed. Chrome has the most users. Whichever browser has the most users is the most popular, and is the only browser that should be listed.
--Gyrobo (talk) 00:20, 11 April 2010 (UTC)
OK, again: Apple does the most work on WebKit! And again: Safari is the most used web browser on mac os. why not add the "big 5" to the table and argue with market share? I mean: otherwise we could also remove presto! or we have to rename the column to most used application. mabdul 01:30, 11 April 2010 (UTC)
The column is already "Leading application", which means the most popular application. Apple's contributions to WebKit are noted in the "Creator" column. I'm unsure where the Presto connection comes from. Do we even need the "leading application" column at all? A list of applications using each engine already exists on the pages for those engines.
--Gyrobo (talk) 02:23, 11 April 2010 (UTC)
I disagree. As the rest of the table is about development, my natural assumption was that "Leading application" was about the application which contributed the most to the development, which would be Safari.
--kickme (talk) 08:30, 26 June 2010 (UTC)
The term "Leading application" refers to the single most prominent implementation of any given engine, it is unrelated to development of the engine itself. It's much harder to verifiably determine the volume and relevance of code contributions than market share. But I agree that contributions to the development of an engine is important, which is why I think the column should be removed as redundant and uninformative.
--Gyrobo (talk) 13:26, 26 June 2010 (UTC)
the development of Safari lead the development of Webkit. I do not think that the original purpose of this column was to show most popular browser, but rather the best associated browser. I shall propose renaming the column to be "Associated Browser" rather than "Leading Application". —Preceding unsigned comment added by 72.131.47.49 (talk) 03:09, 11 July 2010 (UTC)
Then you propose Netscape 6 be the Associated Browser for Gecko, and we should reinstate Internet Explorer (Mac) as the Associated Browser for Tasman? -- Schapel (talk) 03:59, 11 July 2010 (UTC)

Market share

An inference of market share would be very interesting to have in these tables somewhere. -- Beland (talk) 17:42, 19 February 2011 (UTC)

I removed the tag after I add the image. Is this that you expected? mabdul 18:38, 19 February 2011 (UTC)

Proposed moves

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was no consensus. --BDD (talk) 19:30, 16 October 2012 (UTC) (non-admin closure)

– "I noticed that there are a series of articles on support for various things in different browser engines. The use of parenthesis makes sense if the reader already knows this but (like in my case) they are puzzling titles for someone who comes an individual article in the series in isolation." ... "I suggest they all be moved to along the lines of Comparison of XXX support in web browser engines" RA (talk) 27 June 2012. Posted as a move-multi by PBS (talk) 15:41, 7 September 2012 (UTC)

I came across Comparison of layout engines (ECMAScript) by accident while googling something completely different. I took me quite some time to figure out what it was about — and when I did it took me some time again to figure out how it got that title.

I noticed that there are a series of articles on support for various things in different browser engines. The use of parenthesis makes sense if the reader already knows this but (like in my case) they are puzzling titles for someone who comes an individual article in the series in isolation.

The complete list is:

  • Comparison of layout engines (HTML5)
  • Comparison of layout engines (graphics)
  • Comparison of layout engines (ECMAScript)
  • Comparison of layout engines (XML)
  • Comparison of layout engines (Scalable Vector Graphics)
  • Comparison of layout engines (web typography)
  • Comparison of layout engines (HTML5 canvas)
  • Comparison of layout engines (HTML5 media)
  • Comparison of layout engines (MathML)
  • Comparison of layout engines (Cascading Style Sheets)
  • Comparison of layout engines (HTML)
  • Comparison of layout engines (XHTML)
  • Comparison of layout engines (Document Object Model)
  • Comparison of layout engines (XHTML 1.1)
  • Comparison of layout engines (non-standard HTML)

I suggest they all be moved to along the lines of "Comparison of XXX support in web browser engines", so:

--RA (talk) 16:33, 27 June 2012 (UTC)

There are existing discussions of article titles. Why not link from existing discussions of article titles to here?
Titles like "Comparison of [web] browser layout engines (XXX [support])" would be clearer, but surely titles should be no longer than absolutely necessary. Adding one word "browser" makes it clearer, and the added items in [square brackets] could be left out—but surely people who don't understand what "layout engines" means will also not understand what "Document Object Model" (for example) means. In other words, I wouldn't consider even the addition of the one word "browser" to be really necessary. Current naming of other existing articles such as Document Object Model:Layout Engines and Cascading Style Sheets:Browser support seems fairly consistent, so I don't see any need for large-scale renaming of articles. LittleBen (talk) 04:38, 28 June 2012 (UTC)
There come a point where efficiency eats into effectiveness. That's what happened when I came across "Comparison of layout engines (ECMAScript)". I know what all the words mean but the title made no sense. My initial reaction was to ask how can any engine layout ECMAScript? Then I wondered if referred to how the DOM was implemented in different ECMAScript implementation? Or is it a comparison of layout engines written in ECMAScript? The words were all there but the combination made no sense.
In other cases, this eating into effectiveness means the title does make sense ... but means something completely different. Take "Comparison of layout engines (Scalable Vector Graphics)", for example. That article compares SVG support in different web browser engines (e.g. in Gecko, Trident, Webkit, etc.). But a straight-forward reading of the title would suggest it compares layout engines for SVG (e.g. ImageMagick, librsvg, etc.) Remember, a "layout engine" doesn't just mean a web browser engine. It's any piece of software that lays out text and images (definition).
So, it's not merely a case that "people who don't understand what 'XXX' means will also not understand what 'YYY' means". You can understand perfectly what both terms mean but, without a few extra words to explain what this particular combination of them means, they make no sense or mean something completely different. Additionally, making too many presumptions about what pre-existing knowledge a reader has doesn't satisfy Wikipedia:Make technical articles understandable.
(That discussion look pretty dead, BTW — last post in 2010 — but I've posted the standard template on all the pages.) --RA (talk) 16:48, 28 June 2012 (UTC)
Immediately following the titles of the above articles you will see a sentence like "The following tables compare XXX compatibility and support for a number of layout engines." If you click on the layout engine link then it's perfectly clear that it's referring to web browser layout engines.
The definition that you cite also says that "layout engines" usually means "web browser layout engines", and if you Google for "layout engine" then you will see Gecko (layout engine) and Trident (layout engine) near the top of the results. It seems to be so widely understood that "layout engine" means "web browser layout engine" that "web browser" is omitted. If you still think that it's not clear, then why not prefix "layout engines" in the first sentence of the articles with "browser"?
PS: email software uses layout engines for displaying HTML email. LittleBen (talk) 05:14, 29 June 2012 (UTC)
PPS: The main reason to — as far as possible — avoid changing page titles, doing page moves and the like, is that the page title is part of the page URL, so changing the page title breaks all the links to the page from within English Wikipedia and from other language Wikipedias. It creates a lot of work for somebody to fix. LittleBen (talk) 06:34, 29 June 2012 (UTC)
Putting the burden for explaining an article title on the first sentence does not meet policy on article titles (specifically criteria for an article title: recognizability, naturalness, and precision). A lot of your objections seems to hang on the term "layout engine" vs. "web browser engine". First, I'd point out that this article, which is the main article for the series, uses the term "web browser engine". Second, the term layout engine redirects to web browser engine. So for consistency (which is one of the WP:CRITERIA) "web browser engine" would appear to be more appropriate.
With respect to the titles of "Trident (layout engine)" and "Gecko (layout engine)": all web browser engines are layout engines, but not all layout engines are web browser engines. Those articles are about software called Trident and Gecko respectively. However, there are more prominent subjects called "Gecko" and "Trident". Therefore disambiguation of some sort is needed. The word in parenthesis is added for disambiguation. Disambiguating the title with the word "layout engine" suffices disambiguation because there are no other layout engines (of the web browser type or any other) of that name.
RE: "The main reason to — as far as possible — avoid changing page titles, doing page moves and the like, is that the page title is part of the page URL, so changing the page title breaks all the links to the page from within English Wikipedia and from other language Wikipedias." — By default moving a page will leave a redirect behind. That immediately fixes most problems (both within en.wiki, intra-wikilinks, and in-coming external links). "Layout engine", which was moved on 24 May 2010‎ to "Web browser engine", is an example of this. A bot fixes double redirects usually within 24 hours. Moving a page doesn't doesn't break links (see Wikipedia:Moving a page). --RA (talk) 11:01, 29 June 2012 (UTC)
I agree that changing (XXX) to (XXX support) in the "Comparison of layout engines (XXX)" titles would improve clarity. LittleBen (talk) 06:25, 30 June 2012 (UTC)
It's quite easy to determine which term is more widely used and understood — "layout engine" or "browser engine". Enter the following into Google: site:wikipedia.org "layout engine" and repeat for site:wikipedia.org "browser engine". This will show you that there are more than four times the number of pages containing the adjacent words "layout engine" than there are pages containing the adjacent words "browser engine". If you look at the results then there are far more instances of "layout engine" in titles. You will get the same results if you repeat the search using the plural "engines". This surely shows which term is more recognizable, natural, and consistent. You can also check usage outside Wikipedia by Googling for "layout engine" -site:wikipedia.org and "browser engine" -site:wikipedia.org. LittleBen (talk) 10:45, 30 June 2012 (UTC)
I also explained that the more general term "layout engine" is more appropriate than "browser engine" because these same ("browser") engines are used by email clients for rendering HTML mail, they are not limited to web browsers. As for "Layout engine" being moved on 24 May 2010‎ to "Web browser engine", I think the simplest solution might be to move it back. Pointless moves do happen. The great majority of the related articles use "layout engine". However there are related and overlapping articles called Comparison of web browsers and List of web browser engines. So maybe the present title is the best compromise.
If you still think that it's not clear, then why not prefix "layout engines" in the first sentence of the articles with "browser" or with "browser and email" (*see note below)? This is surely simpler and more natural than trying to precisely define and explain every word used in a title within the title itself. Note: email layout engines tend to be stripped down versions of browser engines; they often don't provide much support for CSS, and usually don't support ECMAScript (Javascript) for security reasons.
It would be useful to add your list of "Comparison of layout engines (XXX)" to the See also section of this article, or to the box below the See also section if they are not already in the box. It would also be useful to tag all these related articles with the same Category tag. As I have explained, I personally prefer Category:Layout_engines, and you will note that Category:Web_browser_engines is already a subcategory of Category:Layout_engines. However, somebody has made Category:Free_layout_engines a subcategory of Category:Web_browser_engines, go figure ;-) Tagging these related "Comparison of ..." articles with the same category would be less work and would probably be more useful in helping people find related items than filling out the "See Also" section in each. LittleBen (talk) 15:59, 29 June 2012 (UTC)
The "Page View Statistics" link on the History tab shows how popular a Wikipedia page is. Of the pages that you have listed, it appears that the HTML5 and CSS pages are the most popular, and the History tab of these pages shows the user who has been most actively involved in maintaining these pages. So it would be a good idea to first try to get this person's opinion before putting up public notices everywhere. LittleBen (talk) 04:38, 30 June 2012 (UTC)
"Make technical articles understandable" but not inaccurate. The current titles are fine because they are about layout engines that support the thing in parentheses. 1. Those 5 you refer to are widely used in applications that are not web browsers; 2. there are many layout engines not used for web browsing, see Comparison of layout engines (Scalable Vector Graphics) and Comparison of layout engines (Cascading Style Sheets). There's no need to adapt article titles (read "narrow the scope of the articles") to your personal (partial) understanding of the things, is it? --151.75.27.193 (talk) 21:36, 3 July 2012 (UTC)
HTML used to be used to create (table-based) layouts, as described here, but (X)HTML is now supposed to be used primarily for semantic markup—CSS is now supposed to be used for layout and presentation. The "layout engines" listed in all these Comparison of layout engines (XXX) articles are primarily web browser engines, but the term "layout engines" is much more popular for historical reasons, and because these same engines are still used for rendering (table-based) HTML email layouts as well as in web browsers. The reason that HTML tables are still used for layout of HTML email is that enabling full support for CSS and Javascript in HTML email creates security problems. Is this explanation helpful? LittleBen (talk) 22:58, 3 July 2012 (UTC)
Note: my previous msg was addressed to R. A. 151.75.27.193 (talk) 23:20, 4 July 2012 (UTC)
Addressed to you Not only in email. They're included in any application that displays HTML, unless the application developer has written his own layout engine. But writing a new layout engine would require more effort and time than to write the application. Instead, common practice is to link a plugin or library that contains a well known engine, then it works(TM).
Addressed to R.A. The fact that people associate html to the Web is not a justification for moving titles - first go learn programming, and once you know what's behind the scenes, you'll know they're just HTML+CSS renderers and that web usage is the top of the iceberg. I also ask to move this very page to "Comparison of layout engines", because it clearly is NOT about web browsing, as you can see PrinceHTML and XEP are in the list as well. --151.75.27.193 (talk) 22:58, 4 July 2012 (UTC)
There exists no such thing as a web browser engine. --151.75.27.193 (talk) 23:04, 4 July 2012 (UTC)
The terms layout engine and web browser engine are both widely used, but layout engine is between two and four times as popular as web browser engine, as explained above. See the paragraph that starts with "It's quite easy to determine which term is more widely used and understood — layout engine or browser engine" above. LittleBen (talk) 10:18, 8 July 2012 (UTC)
This discussion has dropped down a rabbit hole I really never envisioned. Almost the entirety of it is being given over to "layout engine" vs. "web browser engine". That doesn't actually do much to address my initial concerns.
@*.193, thanks for your suggestion that I should go and learn programming. Should I first begin by reading one of these books, for which there very definitely is such a thing as a web browser engine? Here's what WebKit for Dummies has to say:

What is a Web Broswer Engine?

Glad you asked (You did as, right?) A web web browser engine is a highly complicated piece of software that has one main task: to make your web browsing experience as seamless and as fast as possible. The browser engine does the low-level (basic, unglamorous, but essential) work of a browser — including loading webpages and other document, figuring out hw a page should be displayed, running scripts in the web page, and much more.

Corvette or clunkier: Every browser has one

Engine, that is. Every web browser (such as Internet Explorer, Mozilla Firefox and Google Chrome) has a browser engine (sometimes called a layout engine or rendering engine) at its core. Think of a web browser engine as similar to the engine of a car: It's the part of the software that does the actual work behind the scenes. …

Table 1-1 lists the most common web browser engines, along with the web browsers that use them. …

[Table 1-1 then lists browsers, such as Internet Explorer, Firefox, Safari, Chrome, etc., with their associated engines, i.e. Trident, Gecko, WebKit, etc.]

Another term, as indicated in the quote above, is (web) browser rending engine. Here is another definition that makes specific reference to use of these engines in contexts other than web browsing:

browser rendering engine Software that renders HTML pages (Web pages). It turns the HTML layout tags in the page into the appropriate commands for the operating system, which causes the formation of the text characters and images for screen and printer. Also called a "layout engine," a rendering engine is used by a Web browser to render HTML pages, by mail programs that render HTML e-mail messages, as well as any other application that needs to render Web page content. For example, Trident is the rendering engine for Microsoft's Internet Explorer, and Gecko is the engine in Firefox. Trident and Gecko are also incorporated into other browsers and applications.

--RA (talk) 11:59, 8 July 2012 (UTC)
@LittleBen, regarding comparing Google hits for "layout engine" -site:wikipedia.org vs. "browser engine" -site:wikipedia.org. "Browser engines" are a subset of all "layout engines", therefore it is unsurprising that "layout engine" would a more prevalent term. Narrow the search to only the type of layout engines we mean here and you will get a different result: compare "layout engine" WebKit Gecko Trident -site:wikipedia.org to "browser engine" WebKit Gecko Trident -site:wikipedia.org.
Many of the suggestions you made from the second paragraph at 04:38, 30 June 2012 are valid, helpful and very useful but I feel this discussion has tripped far too much into a wasteful and mal-informed debate on "browser engine" vs. "layout engine" that positive discussion is being lost amongst all of the fluff. --RA (talk) 12:19, 8 July 2012 (UTC)
Since some of the articles on the web are just quoting Wikipedia, and they attribute Wikipedia by name, I did the following searches: "layout engine" WebKit Gecko Trident -site:wikipedia.org –wikipedia　: 38,100 and "browser engine" WebKit Gecko Trident -site:wikipedia.org –wikipedia : 4,580 which still suggests that "layout engine" is the most common term used to describe WebKit, Gecko, and Trident. LittleBen (talk) 14:17, 8 July 2012 (UTC)
I get the opposite (and very different) results:
Are you sure you used a minus sign? Additionally, the … for Dummies ref cited above would suggest (web) browser engine is the more common term ("…a browser engine (sometimes called a layout engine or rendering engine)…")
As I wrote above too, I'm not surprised that "layout engine" is common: all browser engines are layout engines so calling WebKit, for example, a layout engine is entirely correct. Part of the source for confusion, as I see it, is that not all layout engines are browser engines (and it is unclear from these article's titles that we are talking about support for these features in specifically browser engines, like WebKit, etc.).
Look it, I'd be pleased at this stage to just leave this discussion and would be happy with something like your first suggestion: "Comparison of browser layout engines (XXX support)". --RA (talk) 16:18, 8 July 2012 (UTC)
The problem is probably that if you're logged into a Google account when you search, then Google search will show you what it thinks you want to see, based on your past search history, as described here. I agree with the (XXX support) change suggestion, though it's a lot of work for somebody. Best regards. LittleBen (talk) 16:53, 8 July 2012 (UTC)
PS: I'm under the impression that redirects and moves — not just renaming of sections — breaks links to sections within an article. The link does not turn into a redlink, but I understand that clicking such a link, after the page has been renamed or moved, will take you to the top of the renamed or moved page rather than to the section within the page. You can get an idea of the number of backlinks from "What links here", but that doesn't tell you if the links are to a section rather than to the top of the page. It's difficult to find and fix such problems. LittleBen (talk) 13:17, 9 July 2012 (UTC)
Redirects don't break links. Example: Comparison of layout engines#General_information. --RA (talk) 14:07, 9 July 2012 (UTC)
Thanks for the reassurance! But multiple moves do create double redirects and the like, which are troublesome to find and fix. LittleBen (talk) 16:56, 9 July 2012 (UTC)
Fear not! There are bots on the case. Example: Special:Contributions/AvicBot --RA (talk) 21:06, 9 July 2012 (UTC)
I've just discovered that EPUB is based on XHTML and CSS. You are probably aware of Amazon's claim that they now sell more ebooks than paper books, so this is really big. (Both EPUB and Webkit are Open Source.) I added a bit to the two "Web Browser Engine" articles to link them logically to the series of "Comparison of Layout Engines (XXXX)" articles. As I said before, I don't think anyone will have any objection to your changing (XXXX) to (XXXX support). My EPUB discovery suggests that there is a pretty good case for renaming the two "Web Browser Engines" articles back to "Layout Engines" (and the categories probably need cleaning up too); what's your opinion on this? LittleBen (talk) 07:09, 19 July 2012 (UTC)
Correct me if I'm wrong, but the premise of this line of argument is that because these kinds of applications, etc. may not be internet connected, or may only allow access to local files, or may be restricted to a walled garden, etc., they are not "web" or "browser"?
XHTML and CSS are web technologies (see the W3C), irrespective of whether the individual XHTML or CSS files are local or remote (or accessed via HTTP or any other protocol). I agree that not every application that uses these technologies may be a browser (e.g. an EPUB reader) but the layout engine that lies behind the application would still be a web browser engine (e.g. Gecko). For example: EPUB plugin for Firefox. --RA (talk) 07:48, 19 July 2012 (UTC)
Yes, the same layout engine (Webkit mainly, it seems) is used in web browsers and (in modified form) in email clients and also in e-book readers. It is certainly not being used as a web browser engine in email clients and e-book readers, but it certainly is being used as a layout engine in all of browsers, email clients and e-book readers. The W3C "open web platform" standards supported by layout engines are not just web browser standards but also e-book standards like MathML (for writing math formulas in future e-books), used for CSS animation (future online games) and for UI (whether web-connected or not).
I also tried comparing [site:w3.org "browser engine"] with [site:w3.org "layout engine"], and the latter is more popular there, too. Probably the easiest way to test if a layout engine supports the standards is by running tests using the layout engine in a web browser, and it looks as if most of the instances of "browser engine" on the W3C web site refer to this case. LittleBen (talk) 13:55, 19 July 2012 (UTC)
  • Support. By all means make this move. Parentheses in titles are for disambiguation, not subsections. I think this used to be in the title policy or style manual – was it removed at some point? – Pnm (talk) 03:48, 25 September 2012 (UTC)

  • Oppose: Alternative suggestion: RA originally proposed multiple moves and it was discussed in several places. RA was confused by the (XXX). I believe that RA and I concluded that the pattern "Comparison of layout engines (XXX support)" would be optimal, but he didn't go ahead with the move.
  • The pattern "Comparison of SUBJECT (with-regards-to disambiguation)" is short, simple, and easy to understand.
  • The main problem with the title is the category naming: although the category is "Web browser engines", half of the articles in the category are already correctly named "XXX (layout engine)". The problem is even more obvious if you look at the category "Web browser engine comparisons". "Layout engine(s)" is more appropriate, because the same engines are used in email software (for HTML rendering), in ebook readers and the like, but there need to be redirects from "web browser engines", because that term is also used (but not as frequently). If you read the article carefully, it's not a comparison of browsers: for example, WebKit (in the tables) is the name of a layout engine that is used in several browsers, ebook readers and the like. WebKit is not the name of a browser. The lead paragraph of the article also makes it quite clear that it's a comparison of layout engines. The two category names need to be fixed, as well as the above article titles and this article. Also see Template:HTML and Template:Web browser engines. (Looks like a big job to do properly, I'm not volunteering to do it).
  • When this originally came up, it occurred to me that this sort of problem (lack of consistency between article titles and category titles) occurs frequently and repeatedly because most WP users can't work out how to search categories. Categories are not searched by the default basic WP search. So, as you can see here, I tried to get a link from WP:AT to an explanation of how to search categories before deciding on article titles, however... LittleBen (talk) 15:06, 11 October 2012 (UTC)
The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Requested move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: not moved. —Darkwind (talk) 01:09, 20 January 2013 (UTC)

– See discussion. Relisted. BDD (talk) 19:52, 20 December 2012 (UTC) LittleBen (talk) 15:00, 2 November 2012 (UTC)

  • As discussed here, above, the main problem with the existing title is the category naming: although the category is "Web browser engines", half of the articles in the category are already correctly named "XXX (layout engine)". The problem is even more obvious if you look at the category "Web browser engine comparisons". "Layout engine(s)" is more appropriate, because the same engines are used in email software (for HTML rendering), in ebook readers and the like, but there need to be redirects from "web browser engines", because that term is also used (but not as frequently). If you read the article carefully, it's not a comparison of browsers: for example, WebKit (in the tables) is the name of a layout engine that is used in several browsers, ebook readers and the like. WebKit is not the name of a browser. The lead paragraph of the article also makes it quite clear that it's a comparison of layout engines. The two category names need to be fixed, as well as the above article titles and this article. Also see Template:HTML and Template:Web browser engines. (Looks like a big job to do properly, I'm not volunteering to do it).
  • Of the items above proposed for moving, I have listed only the items where web standards are changing, or where there might be confusion as to the meaning of the article name. LittleBen (talk) 15:00, 2 November 2012 (UTC)
  • eBooks seem to be based on web standards. MathML is one example of a standard that is maintained by W3C but is as useful for ebook and book layout of formulas and equations as for web layout. I agree that there are non-web typesetting languages or markup languages (and associated rendering software) like (La)TeX, but I'm not aware of the term "layout engines" being associated with such software. Are you? LittleBen (talk) 09:00, 3 November 2012 (UTC)
  • Oppose the first two; I and I think many others have a good idea of what a web browser engine does while layout engine is esoteric and possibly also ambiguous. Unsure of the others. Andrewa (talk) 08:59, 10 November 2012 (UTC)
  • Oppose the first two per WP:CRITERIA because "web browser engine" is more recognisable and precise. "Layout engines" include PDF engines, PowerPoint readers, font renderers, etc. as well as web browser engines. Support the other moves as well but would prefer to use "web browser engine" there too. Also per WP:CRITERIA, consistency in particular in this occasion. --RA (talk) 20:02, 10 November 2012 (UTC)
  • As discussed above, "The main problem with the title is the category naming: if you look at the bottom of the page you will see that the relevant categories have been renamed from "Web browser engines" and "Web browser engine comparisons" to "Layout engines" and "Layout engine comparisons" because over half of the articles in the first category are already correctly named "XXX (layout engine)" and all of the articles in the second are named "layout engine" (see CfD discussion here). "Layout engine(s)" is more appropriate, because the same engines are used in email software (for HTML rendering), in ebook readers and the like (there need to be redirects from "web browser engines", because that term is also used (but not as frequently)). If you read the article carefully, it's not a comparison of browsers: for example, WebKit (in the tables in the article) is the name of a layout engine that is used in several browsers, ebook readers and the like. WebKit is not the name of a browser. Likewise for Gecko, Trident and all the others that are compared in the table: they are not browsers, they are layout engines. The lead paragraph of the article also makes it quite clear that it's a comparison of layout engines". And the template box at the bottom of the page links to related articles that are all layout engines.
  • If you think it would be clearer, another alternative would be to rename the first two as follows:
I prefer to omit the "web browser" part, because the engines that are discussed are not limited to "web browsers". A huge part of future CSS3 standards will focus on ebooks and their layout engines (mainly Webkit). Note also that there is already a separate article Comparison of web browsers which is correctly named.
  • Quote: "Layout engines" include PDF engines, PowerPoint readers.   Comment: Surely it's the reverse, PDF viewers, Powerpoint viewers, and web browsers include (incorporate) layout engines, but they are not themselves layout engines. LittleBen (talk) 00:46, 12 November 2012 (UTC)
Comment Only reflowable eBook formats require a layout engine. DjVu, a collection of scanned images with an optional text overlay, does not, nor does PostScript, which describes static pages, or the Portable Document Format (except in the seldom-used content view. EPUB, XHTML content with XML metadata, is displayed in a web browser or a rendered by a layout engine. .mobi/.azw, reflowable simple text with embedded images, is rendered by a native layout engine in the Amazon Kindle, but few details about the proprietary software are available publicly and an article is unlikely. Amazon's new KF8 format is a subset of HTML5 that's rendered by WebKit.
PowerPoint, an XML format since 2007, is rendered by MSHTML. (WP:OR, but you can confirm with Spy++.) Font renderers name themselves as "<qualifier> layout engine", either as a "<brand> layout engine" or a "text layout engine" [1]. Pro forma for PDF, CSS and other layout engines [2]. They should probably be mentioned in a new section here, but there are currently no articles on any of these variants, and a hatnote is sufficient should any materialize. Yappy2bhere (talk) 01:34, 12 November 2012 (UTC)
  • Support the first two per elements 1, 2, and 5 of WP:NAMINGCRITERIA, Weak Support of the others per element 3.
tl;dr? (1) layout engine is the vernacular name, (2) topical articles all used this name until 2010, when (3) a disruptive editor substituted a neologism for the accepted name, creating WP:SURPRISE and inconsistent names, even though (4) innovation is not our purpose here. Yappy2bhere (talk) 19:33, 11 November 2012 (UTC)
First, because layout engine is the vernacular name of this bit of software among the people who design them and the people who incorporate them into other applications. It is used almost exclusively to web browser engine at Microsoft (3500 to 8), Mozilla (3360 to 2), and Opera (1460 to 6). WebKit has styled itself a web browser engine [3] since it forked from KHTML (which itself preferred HTML engine), but even at WebKit layout engine is more common than the official neologism (328 to 233). The conventional layout engine is strongly preferred by Apple developers (developer.apple.com; 67 to 1) and at Chromium (68 to 3). (It's interesting that the neologism is almost unknown at developer.apple.com while it's nearly as common as the conventional layout engine at Apple overall (811 to 760). Perhaps Apple corporate worries, as do some WP editors, that users will be befuddled by the technical term and slips them a description instead.) The story is the same in books (2810 to 471), patents (4230 to 1090), and journals (1180 to 167). Layout engine an "esoteric" term? Absurd. (And "possibly ambiguous" is comical in any context.)
Second, because the move restores consistency between the names of articles about layout engines and the articles under discussion that prevailed before these two articles were renamed. An oddly precocious [4] disruptive editor moved Layout engine to Web browser engine 2-1/2 years ago [5] because he felt that the new phrase was more descriptive than the vernacular name [6]. He began to change all instances of layout engine to web browser engine [7] but gave up, then attempted to rationalize the name change per of RA's reasoning above [8] but gave up, then wandered away a month later. Before Barsamin the meta-articles under discussion were named consistently with the articles on specific layout engines which these articles summarize and abstract, and layout engine was used consistently throughout to name this bit of software. Most sourced topical articles such as Web browser retain the original, vernacular layout engine in the body of the article, but now the wikilinks to layout engine redirect users to Web browser engine, a WP:SURPRISE to users who discover that the meta-article about layout engines seems to abandon the nomenclature used in every article about an actual layout engine. Even Web browser engine is itself only incompletely bowdlerized, retaining the original usage from the lede forward. The proposed move, followed by reversion of affected wikilinks to the original term, will substantially restore the naming consistency that prevailed before Barsamin's innovation.
Third, because improving upon the vernacular is not what we do here. There are other venues for novel usages; what we want in an article on software technology is the terminology used by software technologists who are skilled in the art described by the article. Whatever "I and I think many others have a good idea of" is irrelevant - you can't (and shouldn't) rename Sonic hedgehog for that reason, either. If it's not what they say in Sunnyvale, then it's not what we say at WP. Yappy2bhere (talk) 19:17, 11 November 2012 (UTC)
I have just revisited the web research that RA did in the previous RfM, and compared Googling the following two
and the first is way ahead. But, Googling
appears to give the latter a very slight edge. Ironically, the WebKit.org site says that "WebKit is an open source web browser engine". This is ironic because WebKit is surely a major engine used in e-books.

I thought of Web browser layout engine (or Browser layout engine) as reasonable compromise naming for Web browser engine, but Googling
　suggests that "web browser engine" is more widely recognized. So maybe the best compromise is to leave just this first one (in the list) as it is. In this case, real world is messy.
As for the second one in the list, comparing
supports the idea of moving Comparison of web browser engines → Comparison of layout engines
Caution: When Googling, make sure that you are logged out of Google, or your previous search history may affect your search results.
What do you think (TIA)? LittleBen (talk) 02:40, 12 November 2012 (UTC)
Well, I think that if practitioners, those who design and use these things, call them layout engines then WP should call them layout engines, regardless of the current usage in the blogosphere. (Itself an object lesson in why not to invent terms.) If W3C prefers layout engine (694 to 43), and Microsoft, Mozilla, Google, and the technical contingent at Apple do too, then we should as well. That's why I restricted my searches as I did. Yappy2bhere (talk) 02:20, 14 November 2012 (UTC)
  • It seems that, as you suggested above, large numbers of people (who do not know the correct term) search for "browser engines", and more knowledgeable people who want to compare features—like support for HTML5, CSS3 etc—use "layout engines". LittleBen (talk) 03:25, 14 November 2012 (UTC)
Really? I don't think I did. A Google search can't tell you who is looking for what, only what is out there to find. (But WP can - in the last 30 days, 2/3 of the page views of Web browser engine have been redirects from Layout engine, so the current names are more a hindrance than a help to readers [9] [10].) Yappy2bhere (talk) 05:36, 14 November 2012 (UTC)
A bit higher, since the hits on Web browser engine include the redirects to it from Layout engine. (Or did I read that wrong?) Yappy2bhere (talk) 08:15, 14 November 2012 (UTC)
  • It's counter-intuitive, but the "web browser engine" hits don't include redirects from "layout engine". There are some articles where the number of hits on the page title is less than the number on all the redirects. LittleBen (talk) 11:30, 14 November 2012 (UTC)
  • First, it is hardly surprising that WebKit, Gecko, etc. are referred to as "layout engines". They are layout engines. Specifically, they are browser engines, which are a subset of all layout engines. HTML is not the only technology that is laid out. Other layout engines include GLE (LaTeX), Ghostscript (PDF), Pango (text), XEP (XSL-FO) and so on. So, is this article about a comparison of all layout engines, or just those that layout HTML?
  • Second, "browser engine" is not a neologism created in the blogosphere. It is the term used since the creation of the world wide web to refer to layout engine that layout HTML. See a comparason of sources. Note two things: (1) use of the term "layout engine" predates the creation of the first web browser (1990); (2) use of the term "browser engine" begins with the creation of the first web browser.
  • Third, with regard to how ever many hits to Web browser engine come from the article Layout engine, Yappy2bhere, you modified the article Layout engine to redirect to Web browser engine on the 2 November. That may be appropriate (many of the in-coming links to Layout engine refer more specifically to HTML layout engines). However, it is disingenuous to make argument based on where that article redirects to after you modified where it redirects to.
--RA (talk) 00:30, 15 November 2012 (UTC)
Don't be insulting, RA. Those are page views over the last 30 days; I changed the redirect [11] within 8 minutes of posting my response to LittleBen [12]. Twiddle the figures by 180ppm, if you like. According to LittleBen's first post, the redirect page needed to be updated subsequent to moving List of layout engines - that's what I did.
Your graph indicates that the use of layout engine among people who know enough to write a book has grown rapidly, as rapidly even as the number of web browsers in the world, and has eclipsed the use of browser engine.
Once more, slowly: Static formats don't require a layout engine - text and image placement is predefined in the file. Reflowable formats do require a layout engine - the size or orientation of the display can change placement, or the substitution of one image for another of a different size, and so on. Of the formats you listed, only XSL (of which XSL formatting objects is a subset) is reflowable and is the only one that requires a layout engine. That's why layout engine isn't mentioned in any of the articles you listed except RenderX, which makes a niche XML layout engine that renders to a PDF file instead of to a framebuffer.
However, RenderX is a tiny company ("with hundreds of worldwide customers" [13]) compared to even the smallest browser maker, and it never calls its product a layout engine but qualifies it consistently as a page layout engine [14]. So, as I said earlier, a layout engine in the vernacular of the valley is a component of a web browser, and makers of software for other layout tasks qualify the term ("page layout engine") so that their software won't be mistaken for a browser component.
Finally, Graphics Layout Engine is a scripting language and not any sort of layout engine at all. Yappy2bhere (talk) 07:38, 15 November 2012 (UTC)
  • It's quite easy to show the page views for the two terms "Web browser engine" and "Layout engine" for several months as follows:
' 10/04 10/05 10/06 10/07 12/07 12/08 12/09 12/10
Web browser engine 0 672 1797 2360 4660 4476 4575 5462
Layout engine 7528 6904 3615 3551 3913 3399 3396 3467
Total 7528 7576 5412 5911 8573 7875 7971 8929
  • Comparison of layout engines (Cascading Style Sheets), with 5567 views, seems to be by far the most popular of the "Comparison of layout engines (XXXX)" articles.
  • The naming picture is rather murky. I'm currently reading the book "High Performance JavaScript", and that explains that the "layout engine" implements the DOM (supports (X)HTML and CSS) while ECMAscript (JavaScript) is implemented as a separate scripting module that talks to the layout engine. Different browsers that share the same layout engine (WebKit) have different JavaScript engines: Chrome uses "V8" and Safari uses "SquirrelFish". It's not clear whether support for SVG, or for HTML5 Canvas (for example) is part of the layout engine or a separate module. So the picture is a bit murky—but it's surely modules ("engines") within the browser that handle this stuff, not the browser itself.
  • Page description languages like PCL and Postscript were designed for laying out stuff on a fixed (predefined-size) paper "canvas", and don't allow text to be reflowed (like when you resize a browser window or switch from portrait to landscape mode on a mobile browser), although Postscript allows magnify/reduce. Such software engines are surely described as "rendering" or "rasterization" engines rather than "layout engines". LaTeX and PostScript (GhostScript) are known as "document markup" or "page description" languages. Postscript (PDF rendering) within a browser is usually done by a plugin, a module or engine used within the browser, it seems. Pango is a multilingual localization tool (it can be used with PHP in WordPress—with Pango, dictionaries are compiled to *.po files, and Pango enables the language of standard menu items to be switched on the fly depending on the preferred language of the user or browser).
  • Likewise, there are libraries that programmers can use for drawing graphics, Cairo is one, but they are not called "layout engines".
  • To sum up briefly, and answer RA's main concern (ECMAscript): It is certain that ECMAscript (JavaScript) support is provided by a scripting engine (module) in the browser that is separate from the layout engine, and this is a separate module rather than an inseparable part of the browser. However, it is fair to say that it is more specific to the browser than to the layout engine—unlike DOM, HTML, and CSS support (which are implemented by the layout engine). Internet Explorer can be scripted by separate scripting engines (modules) that implement VBScript and JScript, for example. So yes: ECMAscript seems to be the "odd man out" in the above. Must leave it at that for now.
  • PS: It seems that Comparison of web browser engines → Comparison of layout engines is justified, and
  • As you can see above, that was my original suggestion, but when I researched it I found that virtually nobody uses such a term in the real world. It seems to me that the above Google results are telling us that people who don't know the term "layout engine" find the "Web browser engine" article and learn the correct term there. On the other hand, geeks—and technically-inclined people who want to learn more and compare technical features of these engines—almost all search for "Comparison of layout engines". Unless we match Wikipedia article naming to what people in the real world are using to search for information, people are going to have trouble finding stuff on Wikipedia. Of course it's possible to add a redirect from the term that you suggested—but the article title should be what the majority are searching for, to provide a good experience for the majority by avoiding (unpleasant) surprises. Does that help? LittleBen (talk) 05:49, 21 November 2012 (UTC)
The links you provided don't show what people search for. They show what people find. (And I don't know how you are determine what 'kind' of user searches for which term.)
Google provides a tool to compare terms people search for. And what people search for is pretty much neck-and-neck.
As has been explained, however, "layout engine" is a broader term. "Browser engines" are a subset of all "layout engines". Like 213.246.91.158 puts succinctly, "layout engine" alone lacks context. And I don't believe the intention is that these articles should be about all layout engines, just specifically the "browser engine" kind. --RA (talk) 00:36, 23 November 2012 (UTC)
  • Hi, thanks for getting back to me.  I've taught a community college course on web research/web analytics for a couple of years, and also passed the "Google Analytics IQ" exam. twice, so maybe I was assuming a bit too much about your background, and not explaining my thinking in enough detail. My reasoning/logic for deducing that "(web) browser engine" is the term used in searches by ordinary users, and that "layout engine" is the term used by geeks is as follows: I think you'll agree that almost everybody knows the words "web" and "browser", and also the combination "web browser". But relatively few "ordinary" users will know the term "layout engine". Nevertheless, as you show, search strings that contain "web browser" and "layout engine" occur with about the same frequency. One might expect that "ordinary" users would far outnumber "geeks". But geeks search a lot for specific information—they want to compare layout support for CSS3 and HTML5 support ("ordinary" users don't know what CSS3 and HTML5 are, so they are not going to be interested in comparing the different layout engines' support—only the geeks will be doing that). So you will find many articles if you search for "comparison of layout engines" (layout engines is the term that the geeks will be using) and very few by searching for "comparison of browser engines".
  • To revisit this logic backwards: good web copywriters research the popularity of keywords. If they give their article a good title, and it's a well-written and valuable article compared with the competition, then it will grow in popularity and "float up" to near the top of the search rankings for the keywords. If you're interested in learning more about this, I wrote a long explanation here. (Note: Google Insights was much more useful than Google Trends, but Google seems to have decided that it was too commercially valuable to give away for free). You may also be interested in WP:Search engine test, which I've greatly expanded.
  • As I've explained above—if you research it—you will find that "layout engine" is now used virtually exclusively for these HTML/CSS engines, and other terms such as "page description　languages" and "rendering" or "rasterization" engines are used for the other applications. Postscript is a vector language, and the "rendering" or "rasterization" engine converts the vectors to a bit map. On the other hand, for a layout engine—apart from SVG support and font rendering—the main functionality is supporting HTML semantic markup "this is a level-1 heading" and CSS layout (positioning) and color etc. Web page layout used to be done using HTML tables, but is now done using CSS, that's where the term "layout" came from. I agree that the rasterization functions are there, but they are an invisible black box. I'm not completely sure how 2D and 3D graphic hardware support is implemented, but it seems most likely that they are part of the invisible black-box rasterization functions; most likely the black box talks to hardware APIs like OpenGL and OpenCL. Does this explanation help? LittleBen (talk) 14:33, 24 November 2012 (UTC)
  • PS: I've thought about it a bit more, and it occurs to me that geeks are also likely to do lazy searches (i.e. searches that are as short as possible) about (say) CSS or HTML support in specific browsers, when they really want to go to the layout engine (whose name they may not remember) that powers the browser. So they may search for "Safari CSS3 support", "Chrome CSS3 support" or "Android (browser) CSS3 support". But these three are all based on the same Webkit layout engine, so at least the (more popular) first two should redirect to "Comparison of layout engines (CSS3)". Likewise "Firefox CSS3 support" and "IE CSS3 support". Another word that people doing a search might use instead of "support" is "compatibility". SEO, trying to map the words that users actually use in searches to where they really want to go and what they are really looking for, clearly requires a lot of imagination and research ;-) LittleBen (talk) 18:09, 24 November 2012 (UTC)
  • You can also see that "layout engine" has the edge if you try the following searches:
  • http://www.google.com/search?q="browser engine" AND "HTML 5 support" -wikipedia -site:wikipedia.org (27,600 items)
  • http://www.google.com/search?q="layout engine" AND "HTML 5 support" -wikipedia -site:wikipedia.org (64,400 items)
  • http://www.google.com/search?q="browser engine" AND "CSS 3 support" -wikipedia -site:wikipedia.org (224 items)
  • http://www.google.com/search?q="layout engine" AND "CSS 3 support" -wikipedia -site:wikipedia.org (494 items)  LittleBen (talk) 16:00, 1 December 2012 (UTC)

As mentioned above, currently the only items that I suggest should be changed are

  • Comparison of web browser engines → Comparison of layout engines   is justified, and
  • Comparison of layout engines (ECMAScript) → Comparison of browser engines (ECMAScript support)   would be an improvement. LittleBen (talk) 00:04, 21 December 2012 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

While I find the discussion of moving articles truly fascinating (truly!), I'd like to ask why exactly it is that the Blink engine isn't listed here. I would think that since Google has the best adaptation to HTML5, Blink would have an average or better performance in comparison to other engines. If I were to want to find this pile of data myself, would anyone have suggestions as to where and how to find it? Thanks. — Preceding unsigned comment added by TheLastWordSword (talk • contribs) 13:30, 9 June 2014 (UTC)

Basilisk will be discontinued and Pale Moon Goanna version (UXP) heavily differs from K-Meleon Goanna version (Tycho) i.e K-Meleon uses an obsolete version of Goanna

The page must be updated regularly to reflect the changes of the few engines and browsers which remain in development.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Comparison_of_browser_engines/Archive_1&oldid=1165837280"