Talk:Comparison of web browsers/Page layout discussion

From Wikipedia, the free encyclopedia

Contents

[edit] 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)

[edit] 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)

[edit] 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

[edit] 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)

[edit] 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)