Talk:Comparison of web browsers/Page layout discussion

Page Size and layout discussion

Is this list too big? On smaller screen sizes, I don't think it fits horizontally. Should we have some standard of notability for inclusion here? Should we split it up by platform? Rhobite 02:27, Oct 15, 2004 (UTC)

Mildly off-topic, but I gather Wikidata is intended to allow us to include dynamically-generated user-editable infoboxes and, hopefully, comparision charts such as this one. Does you know if this is true, or if they could use any help? Saucepan 06:50, 17 Oct 2004 (UTC)

It actually doesn't even fit horizontally on my 1024x768 display :/ --Spug 22:56, 20 Oct 2004 (UTC)

Okay, Ed g2s put in a few line breaks now. Still doesn't fit (I don't know if that was what you were trying to achieve, but still), but I use the Default skin with the navbar to the left, so that might be the reason. Then again, the majority of Wikipedia readers probably do. -Spug 17:45, 21 Oct 2004 (UTC)

Ed g2s only put line breaks into places where the browser should automatic put line breaks (my Mozilla 1.7 on Windows XP did), since it'd be too wide otherwise. Besides, it's a chart. It's supposed to be whatever size it has to be to properly show the data. GPHemsley→◊ 22:34, Oct 21, 2004 (UTC)

Agreed, adding browsers horizontally will get increasingly painful. How about a layout something like this instead:

Overview
Browser	Creator	Release Date	Mode	Latest stable version	Cost (USD)
Netscape	Netscape Communications Corporation	October 1994	Graphical	7.2	Free
Internet Explorer	Microsoft NCSA (Mosaic)	August 1995	Graphical	6.0 SP2 (Win) 5.2.3 (Mac OS X) 5.1.7 (Mac OS 9)	Free
General
Browser	Free or Open License	Layout engine
Netscape	Partial	Gecko
Internet Explorer	Proprietary	Trident (Win) Tasman (Mac)

That is, browsers as rows, and features as columns, but with the table sort-of split into as many subtables as needed to hold all the features. This has the advantage during editing of making your position obvious since the features can usually be identified from their content, removing the need for the marker comments.

The subtables could be merged into a big table, as in my example, or could be split into separate tables. Merging them makes all the column sizes line up all the way down the page, but may result in suboptimal allocation of column widths. Saucepan 00:40, 22 Oct 2004 (UTC)

Maybe I'm missing something here but is there a reason why the table should fit horizontally? I can see the table spills off the right-hand side but why is that a problem? Readers already have to scroll vertically, so why is scrolling horizontally as well bad? Why not just add the row headers to the right-hand side in the same way that we have the column header at the top and bottom?

Not that I'm saying Saucepan's suggestion doesn't have merit. Just playing devil's advocate. AlistairMcMillan 02:19, 22 Oct 2004 (UTC)

It's good to question one's assumptions, even (especially?) when the answer seems obvious. I gave it some thought, and I still think that horizontal scrolling is worth eliminating here, if possible. Compared with vertical scrolling, which is ubiquitous, horizontal scrolling tends not to be as well-supported by input devices, browser UIs and rendering engines, and the brains of internet users. Google turned up an interesting rant here. Excerpt:

The visitor must move the pointing device back and forth, back and forth, between the two scrollbars; it's hard to be confident that you've seen every option on the page. All in all, scanning such a page is a little like trying to read a magazine looking through a cardboard tube.

Use the arrow keys! lysdexia 12:58, 23 Oct 2004 (UTC)

The article is several years out-of-date and many of the layout problems it complains about have been fixed in newer browsers, but the "cardboard tube" argument remains a strong one. Saucepan 03:25, 22 Oct 2004 (UTC)

And don't forget printing. In Firefox's print preview, the table cuts off in the middle of Epiphany, even if the font size is turned way down. Rhobite 03:54, Oct 22, 2004 (UTC)

While Saucepan's idea may be a good idea that sounds like it'd work, I'm not sure it'd make a difference. As far as I know, there are just as many (or more) statistics and categories as there are browsers, and putting the browsers down the left side wouldn't help with the horizontal scrolling. It would take a lot of rearranging, recategorizing, splitting, and the like to make it fit, and by that time, the table might not be very pleasing to read. As for printing, that's what they make the Landscape view for. In my opinion, it should be left as it is. GPHemsley→◊ 19:31, Oct 22, 2004 (UTC)

Ctachme's proposition

I know that the table used to be vertical and was changed because it was too wide, I would like everyone to seriously reconsider reverting it back to the horizontal orientation. Why? As anyone who has gone to school learns, the x axis is independent data, and the y axis dependent. The features depend on the browser, not the other way around. Besides, every single other comparison table has the im clients/os's/mediplayer along the top. Consistency is important, and this page looks weird in comparison to the other pages. Most importantly, as more features get added to the table, it will become necessary to scroll horizontally anyway. It's safe to say there are more features for web browsers, than there are browsers themselves. look at something like [1]. That's what we should do. Besides, scrolling horizontally is less important than consistency and extensibility. The following tables compare general and technical information for a number of Web browsers. Please see the individual products' articles for further information. The first table is of browsers with graphics capabilities.

Forgive me if this is out of line, but I've added below what I think the table should look like. It just barely fits at 1024 x 768, but even the current table doesn't fit at anything below that. Personally, I think we can remove the less-important browsers from the table and make it even narrower. I think a more indepth comparison of the top 10 browsers would be much more usefull than a very shallow comparison of 10 common browsers and 10 rare browsers.

Browser:	Internet Explorer	Netscape	Mozilla	Firefox	Camino	Opera	Safari	OmniWeb	Konqueror	Galeon	Epiphany	Amaya	K-Meleon	Dillo
Creator	Microsoft NCSA (Mosaic)	Netscape Communications Corporation	Mozilla Foundation	Mozilla Foundation	Mozilla Foundation	Opera Software	Apple	Omni Group	KDE	GNOME	GNOME	W3C	?	?
First public release date	August 1995	October 1994	December 1998	September 2002	February 2002	September 1996	June 2003	March 1995	October 2000	June 2000	Dec 2002	November 1996	?	?
General
Latest stable version	6.0 SP2 (Win) 5.2.3 (Mac)	7.2	1.7.3	0.10.1 (1.0PR)	0.8.1	7.54	1.2.3	5.0.1	3.3	1.3.18	1.4.4	8.5	?	?
Cost (USD)	Free ∫	Free	Free	Free	Free	Free with ads; $39 without	Free ∫	$30	Free	Free	Free	Free	Free	Free
Free or Open License	Proprietary	Partial	MPL	MPL	MPL	Proprietary	Proprietary + GPL	Proprietary + GPL	GPL	GPL	GPL	W3C	GPL	GPL
Layout engine	Trident (Win) Tasman (Mac)	Gecko	Gecko	Gecko	Gecko	Presto	WebCore (Modified KHTML)	WebCore (Modified KHTML)	KHTML	Gecko	Gecko	Unnamed	Gecko	Unnamed
Supported Platforms
Windows	Yes	Yes	Yes	Yes	No	Yes	No	No	No	No	No	Yes	Yes	No
Mac OS X	Discont. 2004	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	Yes	No	No
Linux	No	Yes	Yes	Yes	No	Yes	No	No	Yes	Yes	Yes	Yes	No	Yes
BSD	No	Yes	Yes	Yes	No	Yes	No	No	Yes	Yes	Yes	Yes	No	Yes
Unix	Discont. 2002	Yes	Yes	Yes	No	Yes	No	No	Yes	Yes	Yes	Yes	No	Yes
Features
JavaScript	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	Yes	Yes
Download manager	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	?	?	?	?	?	?
Frames rendering	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	Yes	No
PNG RGBA support	Mac only	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	Yes	No	Yes	No
Tabbed browsing	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	Yes	No
Search Engine in Location Bar	No	No	Yes	Yes	Yes	Yes	Yes	No	?	?	?	?	?	?
Component Object Model Extensibility	Yes	No	No	No	No	No	No	No	No	No	No	No	No	No
Popup Blocking	Yes	?	Yes	Yes	Yes	Yes	Yes	Yes	?	?	?	?	?	?
Ad Blocking	No	?	?	?	?	?	No	?	?	?	?	?	?	?
Spellchecking	No	?	?	?	Yes	?	Yes	Yes	?	?	?	?	?	?
Full Page Zoom	No	?	?	?	Partial (OS-Based)	Yes	Partial (OS-Based)	Partial (OS-Based)	?	?	?	?	?	?
Browser:	Internet Explorer	Netscape	Mozilla	Firefox	Camino	Opera	Safari	OmniWeb	Konqueror	Galeon	Epiphany	Amaya	K-Meleon	Dillo

The following table contains a comparison of browsers not capabable of displaying graphics.

Browser:	Lynx	Links
Creator	Montulli Grobe Rezac et al.	Patocka et al.
First public release date	July 1993	November 1999
General
Latest stable version	2.8.3	0.99
Cost (USD)	Free	Free
Free or Open License	GPL	GPL
Layout engine	Unnamed	Unnamed
Supported Platforms
Windows	Yes	Yes
Mac OS X	Yes	Yes
Linux	Yes	Yes
BSD	Yes	Yes
Unix	Yes	Yes
Features
JavaScript	No	Partial
Download manager	?	?
Frames rendering	No	Yes
Tabbed browsing	No	No
Browser:	Lynx	Links

So there, that's what I think we should do. If noone objects I change it in a while.--Ctachme 23:34, 8 Nov 2004 (UTC)

Also, are there any browsers that should be struck? I know I've never seen some of those last few... maybe that's just me though. --Ctachme 02:39, 9 Nov 2004 (UTC)

The table's alignment must not be changed; for one thing, look at all the comments you've had to add to make it legible while editing! Information about a single browser should be on the same row as the browser's name. Besides, English speakers read left-to-right. It's unnatural to force readers to read down columns (which might require scrolling). Incidentally, note that the very reason for placing independent data on the X axis is because that makes it easy to view e.g. a graph horizontally.

But cartesian coordinates aren't even applicable here. It is useful in math to use the X axis for independant data, but it isn't always necessary (see parametric equation). Not all problems can be solved with a single rule.

It's curious to talk about independent and dependent variables at all; does Mozilla depend on the Mozilla Foundation, or is it the other way around? --[[User:Eequor|ᓛᖁᑐ]] 10:00, 6 Dec 2004 (UTC)

Color coding

I find the blue=yes, green=partly color coding irritating. Green=yes, blue=partly would be better UI IMHO. A quick search showed (at least) Comparison of file systems and Comparison of instant messengers using the same scheme tho. Are there any guidelines about this? 134.130.183.83 00:11, 1 Dec 2004 (UTC)

Acutally green=yes yellow=partial red=no would be the best system. I agree this should be changed. --Ctachme 01:59, 1 Dec 2004 (UTC)

Shades of red, green, and blue are used because it's easiest to keep uniform (since hex triplets use that format). It should be reddish for no, blueish for partial, and greenish for yes. In other words, just simply switch yes and partial, and be done with it. GPHemsley→◊ 23:02, Dec 1, 2004 (UTC)

Yellow is just #ffff00, it isn't that hard to remember. Besides, I don't see how blue is partial and green is complete. Green yellow and red would be just like a traffic light; something that is widely held to be effective. --Ctachme 02:48, 2 Dec 2004 (UTC)

Red (#ffdddd) and green (#ddffdd) are used because of their analogy to a traffic light. Blue (#ddddff) is used for partial because it is simply an anagram of the other two triplets. GPHemsley→◊ 21:09, Dec 2, 2004 (UTC)

Also, the blue will look mostly greyish next to the red and green, without being dull grey. There should be some contrast. --[[User:Eequor|ᓛᖁᑐ]] 10:14, 6 Dec 2004 (UTC)

So, uhhh... what should we do with the colors? I don't really think they are very clear the way they are right now. Any suggestions? --Ctachme 02:50, 18 Dec 2004 (UTC)

I just modified the "Supported Platforms"(->yellow) and "Features"(->blue) tables above in "Ctachme's proposition". IMHO the yellow is too bright for being between green and red. #aaaa00 or something might look better, but then it becomes really arbitrary. Thus, if noone objects, I'll switch everything to green/blue/red in a couple of days 134.130.183.83 20:06, 18 Dec 2004 (UTC)

Maybe if the colors were a little darker overall? How's this part of a table below? There's green=yes yellow=partial orange=only by plugin/extension red=no/discontinued --Ctachme 05:19, 20 Dec 2004 (UTC)

	CSS	Frames	Java	JavaScript	Tabbed browsing	Download manager	Toolbar searching	Spell checking	Ad blocking	Pop-up blocking	Full page zoom
Links (Non-graphical)	No	Yes	No	Partial	No	?	?	?	?	No	?
Lynx (Non-graphical)	No	No	No	No	No	?	?	?	?	No	?
Mosaic	No	No	No	No	No	?	?	?	?	No	?
Mozilla	CSS2	Yes	Yes	Yes	Yes	?	?	?	?	Yes	?
Mozilla Firefox	CSS2	Yes	Yes	Yes	Yes	Yes	Yes	extension	extension	Yes	No
Netscape	CSS2	Yes	Yes	Yes	Yes	?	?	?	?	Yes	?
OmniWeb	CSS2	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No
Opera	CSS2	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Partial	Yes	Yes
Safari	CSS2	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	Yes	No
WorldWideWeb (Non-graphical)	No	No	No	No	No	?	?	?	?	No	?
	CSS	Frames	Java	JavaScript	Tabbed browsing	Download manager	Toolbar searching	Spell checking	Ad blocking	Pop-up blocking	Full page zoom

Differentiation between "—" and "?"

I've been for the most part staying out of the way of the debates over table orientation and coloring but I just wanted to pop in to say that, as it is right now, I have absolutely no idea what an em-dash (—) on a light-green background is supposed to mean. "?" pretty clearly means "unknown", but as for the other... this needs to be explained, as it's rather confusing.

Also, as for IE support for PNGs being "Mac only"—as I'm sure you all are aware, IE/Win can support PNGs, it just has issues with alpha transparency. I'm of the opinion that it should either be changed to "Yes" with a footnote for IE/Win, or have an additional column added for "PNG-24 with alpha transparency" if any other browser have partial support. And what about PNGs with 16-bit channels? ;) --Miles | Talk 06:58, Dec 20, 2004 (UTC)

I've gone ahead and done this [the png thing]. However, something really must be done about the green em-dashes. If indeed they do mean "unknown", they should not be green, and they should probably be question marks instead of em-dashes, which seem to mean "not applicable" in ordinary contexts. --Miles | Talk 03:27, Dec 21, 2004 (UTC)

I was feeling bold so I recolored the table and got rid of the em-dashes. Do with it what you will. --Miles | Talk 04:00, Dec 21, 2004 (UTC)

Footnotes

I was bold, and changed all footnotes to the ref/note template. New notes can now easily be added by just typing {{ref|SomeName}} in the table, which will automatically link to the note which can be prefixed with *{{note|SomeName}}. SomeName should be an unique identifier, I've tried to find good ones for all existing notes.
Note that this is intentionally incorrect use of the ref/note template, but there simply is no better one available (yet?), and it is far better than the manually numbered notes (imnsho). Jordi·✆ 6 July 2005 23:40 (UTC)

Update: use {{refun|SomeName}} for notes. This prevents them from being numbered, as we have no way to make sure the numbering will be correct. Jordi·✆ 6 July 2005 23:50 (UTC)