Wikipedia Help Start‑class Low‑importance

This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp articles Start This page does not require a rating on the project's quality scale. Low This page has been rated as Low-importance on the project's importance scale.

I see /small tags in Firefox 1.5.0 under Linux, see http://artax.karlin.mff.cuni.cz/~fukav1am/small.png --Vladimír Fuka 20:51, 2 December 2005 (UTC)[reply]

This page would be best on meta...for the different wikipedias are not encoded the same way. Some browsers work well on the en, but not at all on the meta for example.

Exemple : My best choice on the en.wiki is Opera. The quickest. However I cannot use it when a page is too long, since it is cutting it in parts. It is also the best choice when I jump on the fr.wiki. However, it is a disastrous choice for the meta, as it destroys all the special characters.

When the page is too long, I switch to Netscape. But must then change my settings, as it doesnot support the cologne settings (overlapping text and quick bar). However, Netscape is not a good choice either on the meta, where it tends to add weird spaces in the text.

If you stay on the same wiki all the time, life is *good* :-)

If it were on meta, no one would ever see it. I wouldn't, to be sure. The idea is practical usefulness and I think the Wikipedia namespace is the right home for that. There could be something more elaborate and "meta" on meta, referenced from here, but I'd like this page to answer the question:

Is it me or my browser?

Ortolan88 PS - for such practical purposes, each language of wikipedia should have its own version of this page.

hum, ok. You're probably right each wiki needs one page on its own. But I'd like a page to answer these questions

• If I am 50% of my time on the fr:, 30% on the en:, 10% on the m: and 10: on the german, which browser should I use (or not use) ?
• when one wiki doesnot recognise me while I jump through magic links, is that me or my browser ?
• if I go to the japanese (or russian, or ...), just to add a magic link, is that safe for me to use Opera or would I damage the page ?

See m:meta.wikipedia.org technical issues for a list of browsers that are known to work or not work correctly with the UTF-8 encoded wikis (meta, Japanese, Chinese, Russian, Esperanto; and post-conversion Polish, Hebrew, Arabic, etc.) As for the mystery logouts when using multiple wikis, I can only say that I've never had a problem with Mozilla which I use regularly, nor with intermittent tests on Internet Explorer 5.5 (W2k) or Konqueror 2.2.0. --Brion 00:49 Nov 9, 2002 (UTC)

I use Internet Explorer 6.0. When I have been surfing the web and I want to keep the web pages I have seen, I can copy them from the IE-cache. However, of wikipedia articles only the graphic files are stored. The htm-files are not there. I can only save them one by one during surfing, not afterwards. What is the cause of that, and can I do something about that? - Patrick 03:41 Jan 10, 2003 (UTC)

There were (some months ago) significant problems with old versions of pages getting 'stuck' in IE browser caches (eg edit a page, hit save, you're sent back to the page... and you see the previous version still!), so the software was changed to simply tell browsers not to cache. It would be better to be able to report the last-modified date of the wiki page in the HTTP headers and be able to interact appropriately with browsers' requests to fetch updates when the exist while allowing unchanged pages to be cached, but this hasn't been done yet. If you know how to do it right, help would be welcome, otherwise I have to stare at RFCs for a while and figure it out. :) --Brion 04:30 Jan 10, 2003 (UTC)

Thanks. No, I don't know how to do it. Out of curiosity, how are browsers told not to cache, is that in the html file? I do not see a parameter or command like cache or nocache or so. - Patrick 11:55 Jan 10, 2003 (UTC)

The software sends http headers for it:

               header( "Expires: 0" );
               header( "Cache-Control: no-cache" );
               header( "Pragma: no-cache" );
               header( "Last-modified: " . gmdate( "D, j M Y H:i:s" ) . " GMT";

(The last one fixes a problem with an old version of IE that would cache pages anyway, based on the last-modified header which by default was the date the program was last modified.) --Brion 19:07 Jan 10, 2003 (UTC)

None of the Macintosh browsers seems to pick up the different background colors between article and talk pages. I didn't even know they existed until I was baby-sitting the grandchildren the other night and had to use my son's Wintel (ugh!).

You mean the yellow(buff)/white difference? Certainly present on IE 5.1 on OS 9. Is there another color difference I'm missing?

I don't have any problem in my mac os 10 about color. What do you mean by pick up? -- Taku 05:45 Feb 26, 2003 (UTC)

The tan background for talk pages displays as white on the latest versions of Opera, Safari, Netscape Navigator, OmniWeb, and Internet Explorer running under OS X 10.2.4, and have never shown up on any OS X version of any browser. I am going to put this bug back in the article. I haven't tried OS 9, but I will, as my brother runs it. Ortolan88

Alarmo falso -- evidently this is a problem with my flat-screen display. Regular cheap CRT shows tan, but expensive flat-screen doesn't, despite endless fiddling with display configuration params. Dang! Ortolan88

Shouldn't the pages at least be conforming HTML? At the moment checking this page itself on the w3c validity service reveals some errors that could be easily fixed. Michaeln Fri Jul 11 00:56:18 UTC 2003

I invite you to help fix any remaining problems in our parser. http://wikipedia.sourceforge.net/ Get crackin! :) --Brion 01:09 11 Jul 2003 (UTC)

Point taken :) At least this is a known problem. Sadly, I don't have the time to learn PHP and contribute. -- Michaeln Thu Jul 17 01:43:51 UTC 2003

I have had some trouble logging in. This is probably a browser problem for Safari users (Safari has problems with this site!). Too bad for us Safari users. --66.47.86.47 13:52 Feb 23, 2003 (UTC)

Safari is based on the Konqueror HTML rendering engine, I don't know whethter that encompases such things as login/cookie management, but everything works fine under Konqueror - maybe you could describe your problems more acurately. --snoyes 15:04 Feb 23, 2003 (UTC)

Here's a more indepth description: When I go to the login page and type in my user name and password and click "login", red lettered words inform me that my user name does not exist. At other times I can login with no problem. --66.47.86.47 15:59 Feb 23, 2003 (UTC)

see Wikipedia:Browser notes & leave a note there -- Tarquin 15:06 Feb 23, 2003 (UTC)

Sign-on with Safari for Windows, version 3.0.2 (522.13.1) worked fine for me. Perhaps you were using a different version and/or OS? The OS and version information will also help to place the comments in the right section of this article.Mwarren us 00:31, 11 July 2007 (UTC)[reply]

A few months ago, Safari 4.0.2 on OS X 10.4.11 started often displaying only a blank page when I tried to open a Wikipedia page. In all cases a page refresh loads the page properly, but it happens so often, it's danged annoying. SteubenGlass (talk) 21:11, 15 December 2009 (UTC)[reply]

'

I'm noticing different behaviour with graphic layouts between IE and Netscape; it first came up with a version (now fixed using table rather than div) of curvature; see: [1]. In IE it renders correctly (at least, as intended!) but in Netscape, it renders quite weirdly. I don't think this used to occur in Netscape (although I mostly use IE).

I also notice that currently, in Netscape 4.7:

• The Wikipedia logo slightly obscures the "M" in "Main Page" on article pages.
• There is no horizontal rule bwteen the upper navigation section and the title of the article;
• There is no vertical rule between the left hand navigation items and the article body.

None of these effects are seen in IE. Has something changed recently? Chas zzz brown 23:09 Mar 14, 2003 (UTC)

I get the same thing in IE8, the logo obscures the title and some of the introductory text. 83.183.219.250 (talk) 18:42, 23 April 2010 (UTC)[reply]

A lot of things are broken in Netscape 4 (the exact set of broken things will vary from page to page, setting to setting, day of the week to phase of the moon) and I'm afraid there's little interest among the developers in supporting it. You are more than welcome to make specific suggestions for improvements to the HTML output that will make Netscape 4 render most things correctly without breaking the code in general. (By specific suggestions, I mean an actual example of working code.) My honest recommendation, though, is to upgrade to a more capable browser. [2][3][4][5] --Brion

C'mon! (all that follows is good-natured. don't be angry.) I hate Microsoft like you hate Hitler. And I don't like AOL too much, either. Netscape 4.7 is fine. Calling it merely "obsolete" is like calling a mint-condition 1940 Maserati "obsolete". Even LYNX (my first browser, before Mosaic was written) is still a perfectly functional web browser. I often use it. Beats the crap of the modern gas hogs. 4.7 shows the logo funny? What a disaster. It looks funny. So what? So did my third girl friend. Arthur 00:33 Mar 15, 2003 (UTC)

I added an HTML comment to a page I was working on (for a semi-good reason) and it munged up the editing process in Konqueror - the existence of the comment caused it give up before finishing the textarea. I assume it doesn't affect (at least some) other browsers, since someone else went in and removed the comment and it was fine after that. Is this a known bug? -- Bth

This sounds like it's probably a bug in Konqueror. All "<" and ">" characters are turned into &lt; and &gt; before they're put into the textarea, so they can't possibly be interpreted as actual tags or comments. (By the way, you'll find a link to our bug-tracking system at Wikipedia:Bug reports; if you find what seems to be a bug, please report it there and we'll be able to keep track of it better.) --Brion VIBBER

Is this still a problem with KDE 3.1x? --Brion 19:57 Apr 18, 2003 (UTC)

All I want to do is make a small user page! I go to User:DrRetard and edit the page like I've edited every page since I starting editing here, and it looks fine. And then I click on a link like this one, User:DrRetard, or the one at Talk:Free_will_and_the_problem_of_evil, and I get a page with no text. Waaagh! I want to die!

Thanks for your help! -- Dr. Retard

Have you tried refreshing the "blank page"? Sometimes my browser gives me the old version of a page. -- isis 14 Sep 2002

It must be something like that - I checked and your user page does exist, with text and all. Andre Engels 19:35 Sep 14, 2002 (UTC)

Yes, I kept refreshing and refreshing. Even logging out and back in. Now it appears to work! I don't know why! Waagh! I still want to die! Thanks again for your help! -- Dr. Retard

In Internet Explorer, if you sit behind a proxy cache, sometimes you have to hold down Shift while clicking on the refresh icon, to really convince the program to refresh. http://freespace.virgin.net/john.cletheroe/pc_int/ieoe/shift.htm

I have no idea what that means, but I found out the hard way it's true -- I've had trouble several times on Wikipedia when an image in an article had been updated, and I kept getting the old one even when I refreshed the article page. I'm using IE 5.5. -- isis 14 Sep 2002

A proxy server sits between you and the rest of the internet and (invisibly to you) stores ("caches") web pages so that they load faster the second time around. Internet Service Providers often run caching proxys. If these proxy servers are not configured correctly, the above problem occurs. AxelBoldt

I'm having trouble with the character encoding on my brower - it's mozilla 1.1 and the default encoding is iso8859-1. It makes any accents or unusual characters turn into rubb!sh and make a mess of the edit. Anyone know about this? User:andrewthorne

I never had problems with Mozilla 1.1a, and have no problems now with Mozilla 1.2a (on Windows 2000). Could you give examples of particular pages and particular actions which produce problems, and describe precisely what happens, and tell us which operating system you're running on? --Brion 04:15 Oct 1, 2002 (UTC)

I used to get those login timeouts. Not any more. That is workin "bueno" now. The diffs though occasionally only leave a very small portion of the current revision visible, and of course there is no scroll-bar with this browser. I have tried to figure what could possibly cause such a rare and totally capricious behaviour. It's a mystery. -- Cimon Avaro on a pogo stick 21:37 31 May 2003 (UTC)

Moved from Wikipedia:Village pump on Tuesday, July 8th, 02003.

Current Events doesn't render properly in Safari - the text goes over the sidebar. I don't know enough HTML to consider editing... Also, I found that typing Loma-Prieta in the search bar brings up the Mira Loma entry, even though there is a Loma-Prieta page (it was empty, so I changed it to a redirect to Loma Prieta - oh, I just realized it should have been Loma Prieta Earthquake!). Anyway, the search behaved the same both before and after I added the redirect to the page. -Aion 18:58 5 Jul 2003 (UTC)

Safari renders all pages here at Wikipedia just fine. The only thing that does not work is when you make the page too small from left to right. Then the text in the upper right region overlap the left column. Drag the Safari window bigger (the horizontal size) and see if that fixes things. Also, are you using the latest Safari 1.0 (v85)? As I said, Safari works fine for me at Wikipedia. Good luck. --Mahongue 02:02 6 Jul 2003 (UTC)

There was an HTML error on the Current events page, which I've now fixed. Does it render properly now? --Zundark 19:23 5 Jul 2003 (UTC)

No, it's still the same. It looks like maybe the "Hong Kongese constitutional changes" item is setting the width of the sidebar to be too wide? It renders properly in IE, and Netscape, though. So it might be a Safari problem. -Aion 21:15 5 Jul 2003 (UTC)

Putting 'loma prieta' in the search box and hitting 'go' brings up Loma Prieta earthquake for me. Current events looks fine in Safari 1.0 for me, though if you shrink the window down real small of ourse you get problems. More detail please? --Brion 22:06 5 Jul 2003 (UTC)

End moved discussion.

Help! Is there any browser out there that doesn't screw up something on wiki? IE does bizarre things to some pictures, won't go into pages over 32K (or rather chops the end off) and turns <small></small> captioned text into spidery unreadable stuff, Netscape won't recognise <small></small> at all, putting all text into the same size (which sort of f**ks up captions carefully laid out using the commands), safari is brilliant but times out after 60 seconds (which means that 4 times out of 5 lately on wiki it fails to enter a page, change a page, etc). I thought camino was fail-safe but no, now I find that it too won't accept the <small></small> command. It is as if the designers of these things all get a perverted pleasure in putting some little glitch just to annoy users. :-) Is there anything out there for a mac that doesn't chop pages, muck up captions, move around pictures or time out after a minute? FearÉIREANN 02:22 7 Jul 2003 (UTC)

A minimal test page for <small> looks ok for me in Mozilla 1.4 and Camino 0.7... Can you point to a specific page that's problematic? --Brion 02:41 7 Jul 2003 (UTC)

Short answer: No. There is no perfect browser. But Mozilla and Opera seem to be the least prone to weirdness, in my experience. -- Wapcaplet 02:52 7 Jul 2003 (UTC)

I always use Mozilla 1.3 on Mac OS X. I suspect that it randomly inserts newlines sometimes in edit boxes, but pics and html and exotic fonts all seem to work fine. Stan 03:22 7 Jul 2003 (UTC)

See Wikipedia:Browser notes, if you haven't already. You can look for browsers with no problems reported and report the problems you have encountered not already listed there. --Ellmist 03:59 7 Jul 2003 (UTC)

The article Chives doesn't look right in Mozilla. The separation line cuts the right-hand size table into halves. It is not the only articles with such problem. Wshun

This behavior seems to be triggered by going into standards compliant mode... if I break the doctype to put it in quirks mode, the <hr> will not pass through the floated box. Hopefully there's a sane way to work around this. :P

Bug is listed at bugzilla, supposedly there's a patch in the works.

As a workaround, I've patched our JavaScript bits to hack the CSS to revert just <hr> to the quirks mode handling if you're running a Gecko-based browser. :P Hit reload to get the new code. --Brion 04:32 10 Jul 2003 (UTC)

Opps, Brion, sorry I forgot to come back and tell you about the problem with Camino not recognising the <small></small. command. Quite simply it never ever recognises it. For example Papal Tiara, James I of England. Also the top of the Recent Changes page. FearÉIREANN 02:00 15 Jul 2003 (UTC)

(running a test here!)

The above for example, irrespective of whether the <div> commands are in or simply the middle line is used here, appears as large italics on Camino 0.7 but small italics on IE. (Good God. I knew if I wated long enough I'd find something good to say about Explorer. So it isn't 100% crap, merely 95%! FearÉIREANN 02:00 15 Jul 2003 (UTC)

That might explain why Camino's not yet up to version 1.0. ;) - Hephaestos 02:07 15 Jul 2003 (UTC)

Looks fine to me... OS X 10.2.6, Camino 0.7. --Brion 05:15 15 Jul 2003 (UTC)

File:Camino-showing-small-tags.jpg

I've discovered a bit of the problem. Camino + Cologne Blue together don't show small!!! I was using Cologne Blue. :-( So I guess that leaves me with the problem of which do I chose - nice skin + IE (aaaaaagh!) or yuch skin + camino (aaaaagh!) Maybe I'll sleep on it. BTW, re the floating quickbar, does it ever actually float??? :-) FearÉIREANN 05:51 15 Jul 2003 (UTC)

Reload the page and you should find the <small> tags operating as expected under Cologne Blue. Apparently for reasons unclear, using an absolute point size for the text (eg, font-size: 10pt) causes the smallish effect of the <small> tag to become very very slight in Camino (and hence unnoticable at 10pt). Putting an explicit small { font-size: 75%; } into the style sheet declaration makes it work more as expected:

File:Camino-showing-smaller-tags.jpg

As far as the floating quickbar; Cologne Blue really isn't set up for that, so you just get the boring one that's stuck at the top of the page when you scroll. Sorry. --Brion 06:19 15 Jul 2003 (UTC)

I am not a font expert, but isn't this a simple case of not having the appropriately-sized bitmap font? If Camino defines "small" to mean "80%-size", and your bitmapped font has, say, 16 pixel and 10 pixel sets, and your normal font is 16 pixels, 80% would come out to 12.8 pixels, which might just be rounded up to 16 pixels again (purely hypothetical, of course, but you see my point). Does the lack-of-small problem occur with all font sizes? What happens if you zoom in/out, or choose a different "default" font in your preferences? (if Camino has such capabilities - I haven't used it). -- Wapcaplet 11:24 15 Jul 2003 (UTC)

Bit map fonts? MacOS X does not understand your strange terminology, it's all magic vector truetype display PDF smoothy anti-aliased crud. ;) Defining 80% also works fine, while pumping the font zoom up to HUGE shows only the tiniest of visible changes without the explicit percentage definition. --Brion 16:24 15 Jul 2003 (UTC)

Clearly I am no Mac expert either ;-) I suppose my next question would be, has anyone actually measured the height of the "small" font in pixels? Could just be a quirk of human visual perception that 80% looks too similar to 100% for some fonts. -- Wapcaplet 23:56 15 Jul 2003 (UTC)

No, the trouble is the way that it handles the 'smaller' font size keyword, which is specified for the <small> tag in Mozilla's default style sheets. It's not a percentage value (which works fine if we force it, be it 75% or 80% or whatever), rather it ratchets down to the next-smaller value in a fixed list. Certain values are particularly bad: 10pt translates to something like 13.33 pixels, and so it picks the next-smaller size of... 13 pixels! If you zoom the text size way up in Camino, the 0.33 difference turns into a couple of whole pixels and is visible, but at normal size the font scaling rounds the 10pt text to 13px, the same as the "smaller" text. See bugs 72164 and 201811 in bugzilla. This may be fixed in more recent versions; but Camino hasn't updated (at least not in release versions) and I haven't tested the just-released Mozilla 1.4 (nor will I have a chance to for a while). --Brion 01:41 16 Jul 2003 (UTC)

Opera 7.20 -- I recently downloaded the new opera 7.20 browser, and while normal pages appear just fine, the main page is all screwed up -- the tables don't seem to align properly. Thoughts? Brassratgirl 00:51, 6 Oct 2003 (UTC)

Since using iCab 2.97 on my iBook (running Mac 10.2.8) I have been unable to view the Hebrew in the Bible translations article. I've tried with MSIE 5.2.3 and the Hebrew doesn't work. It works with Mozilla and Safari. Also, the 'hide' in the table of contents box is hidden. Can anyone confirm these things? - iHoshie 06:26, 22 Dec 2003 (UTC)

Hello, I use an updated version of IE on a quite updated previous century GUI OS from Redmond, WA, and after I started using the 'new default skin' (?) after the recent server installs, both stub links and broken links display the same -- as red links. Before, with the 'yellow' skin ('standard'?), stubs had a brownish color while only broken links were red. Could somebody help me out here? (or point me to a more relevant place to get help?). I have already checked several hopefully relevant FAQs but to no avail. --Wernher 18:25, 1 Jun 2004 (UTC)

It seems to be allright now (has been for some time, starting a couple of days after my posting above). --Wernher 15:55, 12 Jun 2004 (UTC)

I'm adding Mozilla Firefox and Mozilla itself to the list of supported browsers with "no problems" for Unix/Linux. I'm certainly having no problems with them. (Mozilla 1.4, Firefox 0.9.1 here) --Ardonik 03:47, 9 Jul 2004 (UTC)

Version numbers for the Firething and lizard are imperative: older versions of Gecko have serious CSS implementation failures which affect the new standard Wikipedia skin. But Gecko 1.4 seems to work relatively good on Windows also. Anárion 09:07, 9 Jul 2004 (UTC)

Can anyone explain to me why the following, from Reign of Terror, shows a period (".") rather than a colon (":") after the italicized word Terror?

Source: On [[September 5]], the Convention, pressured by the people of Paris, institutionalized ''The Terror'': systematic and lethal repression of perceived enemies within the country.

Result: On September 5, the Convention, pressured by the people of Paris, institutionalized The Terror: systematic and lethal repression of perceived enemies within the country.

Jmabel 05:52, Jul 28, 2004 (UTC)

Actually, I think it is showing a colon - it's just that when the r in Terror is italicised, it touches the colon's upper dot, making it look like the dot is part of the r. I can't think of any solution to the problem, though, except to add in a space (giving Reign of Terror : instead of Reign of Terror:). -- Vardion 06:21, 28 Jul 2004 (UTC)

An alternate solution is to italicise the colon as well. Reign of Terror: The typography police are probably going to write me up for suggesting it. -- Cyrius|✎ 06:24, 28 Jul 2004 (UTC)

Most of my clients' style guides call for applying italic to ending punctuation after italic text--including periods and commas because they can show up oddly, too, if not italicized. Elf | Talk 04:39, 29 Jul 2004 (UTC)

Donald Knuth's TeXBook also calls for typesetting the punctuation mark following bold/italic text as bold/italic. BACbKA 21:16, 2 Aug 2004 (UTC)

It looks fine in Mozilla 1.7/Cologne Blue. You could try changing your browser/skin.

chocolateboy 16:01, 28 Jul 2004 (UTC)

• The fact that there is a browser/skin in which the article looks right is not the issue. We should be striving for copy that will look right to all viewers. The suggestion of italicizing the punctuation is probably a good one. -- Jmabel 06:27, Jul 29, 2004 (UTC)

We should be striving for standards that are supported by all sane browsers, and not implementing hacks that annoy users who don't happen to experience your viewing idiosyncrasies. What browser/platform/skin are you using?

chocolateboy 08:08, 29 Jul 2004 (UTC)

This is a well-known IE rendering limitation/bug, unlikely to get fixed in the next four years or so... -- Gabriel Wicke 23:25, 29 Jul 2004 (UTC)

We should not be ignoring a browser used by a larger number of people than any other browser on the Internet. It's one thing to have a policy like that for tools used by our active participants, but we want our content to look good to people who are turning to us as an encyclopedia, not as a hobby. -- Jmabel 00:55, Jul 30, 2004 (UTC)

Despite all the browser bashing (it looks bad in netscape too, btw), the correct solution is to italicize the : so that it does not run into the r. Italic punctuation was created specifically to fix that problem. --ssd 05:13, 30 Jul 2004 (UTC)

I do not think that articles should try to account for ephemeral font and browser issues, even of popular browsers. At most, the Wikipedia software could be tweaked to render such cases for buggy browsers, the underlying code staying the same (the tweaking could simply be removed once the browser improves). Many unicode entities used in existing articles are not rendered properly by any browser yet. But Wikipedia is here 'for ever', and unicode is here to stay too, so it is reasonable to expect them to render correctly in the near future. (in firefox, btw, the colon looks fine). Italic punctuation exists for whole italicized paragraphs. I don't think it's good practice to italicize punctuation after a single word in italics (but I am not Donald Knuth); Btw, is there any sort of punctuation-standards-enforcing wikipedia-bot/script? Dbachmann 08:15, 3 Aug 2004 (UTC)

Practical standards and guidelines are good, but in the end typography is like writing. In many cases, you have to make the call and do what works best in the situation. Italicizing the colon here is the right choice. —Michael Z. 00:38, 2005 Jan 16 (UTC)

By the way, all the Gothic characters work fine in my browser (Safari 1.2.4), but only because I downloaded Code2001 font.

The Link http://en.wikipedia.org/wiki/Wikipedia:Browser_notes#Textarea_tools included on Help:Contents as "How to edit with an external editor". However this page doesn't contain any information about how to use an external editor with wikipedia. What I expected to find was information about syntax highlighting for different editors and such.

--Ados 12:51, 12 Aug 2004 (UTC)

Something like works for most Wikis. It found it trivial to adapt this synthighligh for SciTE. Anárion 13:07, 12 Aug 2004 (UTC)

There's also an article dedicated to the topic on Wikipedia. I changed the link on Help:Contents to that page. Seems like the more appropriate place to put it. --Ados 14:16, 12 Aug 2004 (UTC)

Using Opera 7.53, I'm experiencing permanent problems with mouse-selecting a text on the Web-pages (both on-line and saved to my HDD). The selection block is either missing corner parts of the paragraphs or remains on screen despite following mouse actions. And this bug seems to be irrelevant to what page or Web-site I'm browsing. Michael the Web-designer (User:Mzajac) says the page codes (or mark-up or something) are IE-dependent so they need updating to meet Opera standards. Any other opinions? Should I change some settings? AlexPU

I upgraded from Firefox 1.0 to 1.0.1, and it renders the "diff" pages differently (and badly). The yellow and green boxes are missing, as is the red-bolding of the changed text. The latter in particular has a serious impact on usability. There are other, minor, but still regressive rendering changes.

I still have 1.0 on another machine and it renders the pages just fine, as does IE. Has anyone else seen this? One problem I had was that I installed 1.0.1 not realizing you were supposed to remove 1.0 first, then removed 1.0 and found 1.0.1 was removed too, so I had to reinstall it. I'll try a clean upgradeinstall (in a virtual machine) to see if that works. David Brooks 04:25, 5 Mar 2005 (UTC)

Looks fine to me. Try clearing the cache or forcing a reload (shift+reload or ctrl+reload, I forget which) to make sure you don't have a bogus stylesheet stuck in your cache. --Brion 05:02, Mar 5, 2005 (UTC)

Also looks fine to me (Firefox 1.01 on Windows 2000). Dd-b 05:05, 5 Mar 2005 (UTC)

<slaps forehead> and I've been doing this to browsers since 1994. Thanks, that worked. David Brooks 20:44, 5 Mar 2005 (UTC)

This is what it used to look like (roughly) before my edit:

• Add-ons
  • Internet Explorer
  • ...
  • Mozilla and Firefox
  • ...
  • Safari
    • UnicodeChecker
      • doesn't work for Firefox

Which part doesn't fit in? The part that says "doesn't work for Firefox." Now if UnicodeChecker was listed as a cross-browser solution, then it would make sense to say that it doesn't work with a non-Safari app, but it's specifically listed under Safari... --69.214.227.51 08:26, 10 Apr 2005 (UTC)

This is getting silly, but I'll explain why I did my second edit. "Safari" got replaced with "Mac OS X browsers" by someone else, so my second edit reverted that. UnicodeChecker and CocoAspell aren't Mac OS X browsers, they're Safari add-ons, which they were originally listed under as. Secondly, yes UnicodeChecker is a system service, but it isn't the system service's fault that it doesn't work with Mozilla apps: Mozilla & Firefox currently haven't been coded to work with * any* Mac system service, so it wouldn't be descriptive or necessary to point out that one particular service doesn't work with Firefox, no matter how big Firefox is, because none of the system services work with it. Furthermore, I'll reiterate my original point: It doesn't make sense to point out that UnicodeChecker doesn't work with Firefox when UnicodeChecker is specifically listed as a Safari solution. Also, making your edit for the second time, Mzajac, without discussion in the talk page was trollish and obviously uncalled for. --69.214.227.51 16:18, 10 Apr 2005 (UTC)

They're not Safari add-ons, they're system services that work with any OS X program, including web browsers, which use the standard system text fields. This may already include OmniWeb or Opera, for all I know. It dose work in a web browsing tab in NetNewsWire.

That they don't work with Firefox is significant, because the Wikipedia audience would favour that browser, and it's good to point that out before people go to the trouble of downloading and installing software.

You can change the wording any way you like. —Michael Z. 2005-04-10 17:13 Z

So I slipped -- it would have been clearer if I said that UnicodeChecker was a solution for Firefox, as opposed to an add-on. Indeed, it's an independent application as opposed to a browser plug-in, for example, and it works with other browsers. Much of the items under 6.3.1 (as indexed in the TOC) "Built-in Tools" are also non-browser specific system-wide solutions (BTW "Tools" should've been lowercased). Strangely though 6.3.1 is a sub-sub-category of 6 "Browser add-ons & proxies" when system services aren't plugins or proxies. Perhaps 6 could be renamed to "Browser plugins, proxies, and system-wide services" and a "proxies & system-wide services" sub-section could list operating systems or desktop environments, followed by system services for each. Under the OS X section, there could be an asterisk saying that Firefox doesn't support system services as of now. For the Plug-ins section, on the other hand, it would make sense to list browsers as opposed to desktop environments.

"it's good to point that out before people go to the trouble of downloading and installing software" It would be inconvenient for themselves if users did that, but when UnicodeChecker is listed specifically under Safari, they shouldn't expect it to work with Firefox. Also, if a user has ever used Firefox on OS X and are aware about system services, they should know that Firefox works with not a single system service in the Services menu, even about a dozen that comes included with the OS. There's nothing that system services can do since Firefox has not been coded to take advantage of it. I can see how some sort of warning for Firefox users could be added somehow, somewhere, eventually.

"Opera kiosk mode filtering" is listed under "Browser add-ons & proxies." From what I can tell, it's neither, right? Ack, this article is a bit messy. I was also wondering if the undo feature in textareas and textfields are something that comes with the Windows OS because it seems like practically every tf/ta in every Windows app has this feature, while this isn't the case with OS X. If it is some sort of Windows thing, then it might also be listed under a hypothetical future "system services" section. --69.214.227.51 18:26, 10 Apr 2005 (UTC)

Is it just me, or does the editing toolbar not appear in Safari? I'm using Safari 2.0.2 (416.12) on Mac OS X 10.4.3. I also have PithHelmet, but the toolbar doesn't appear even when I reload the page unfiltered. --Kenyon 22:09, 22 November 2005 (UTC)[reply]

The toolbar can be disabled in the Wikipedia preferences (I do not see it as well). Maybe this is the problem. I also think that JavaScript must be enabled for it to work. Paolo Liberatore (Talk) 17:06, 23 November 2005 (UTC)[reply]

The toolbar is enabled in my preferences. It works in Firefox on my Linux machine. JavaScript is enabled in my Safari prefs. Still no toolbar in Safar. Strange... --Kenyon 03:08, 3 December 2005 (UTC)[reply]

I'm surprised this hasn't been noted here before (or it just me!?), but I've noticed that Firefox seems to ignore automatic separation between image and tables/text in Wikipedia articles. This causes some images to overlap text and tables. (For an example, see the Wikipedia article, Timeline of glaciation. There is a difference between how that article shows up in Firefox and IE - look at the first image and table.) Yet, when I open Wikipedia articles in IE, images and tables/text are automatically separated as they should be. I haven't been able to find any troubleshooting references to this here in Wikipedia, unless I've missed something. While I do know that this overlap problem can be resolved by changing the size of images as they show in the articles, some may not want to go to the trouble or even know how to deal with this irksome problem. (I have left that first image size deliberately unedited in the example article mainly to illustrate this problem) Is Wikipedia working on this problem of Firefox ignoring automatic separation between image and tables/text? NorthernFire 20:15, 15 February 2006 (UTC)[reply]

The

answer to that is, quite literally: it's not a bug, it's a feature. CSS boxes are allowed to overlap, which is good, because they're boxes, and so anything else would result in oddity. Consider the checkmark at the right: its box overlaps this paragraph's box. Fortunately, this paragraph is nice and flexible, so it can flow around the checkmark; tables aren't so flexible, so they can't. Start points of blocks are fixed by their position and attributes; you can't just shove around blocks with clear: none. IE does, and in this respect it does not comply with standards.

(Note: the above is correct to the best of my knowledge; my proficiency in CSS is moderate. But see Mozilla Bug #241,031.) —Simetrical (talk • contribs) 15:14, 19 June 2006 (UTC)[reply]

Someone on the #wikipedia IRC channel has just informed me that the same "bug" occurs in Opera 9. —Simetrical (talk • contribs) 15:24, 19 June 2006 (UTC)[reply]

I am having a similar issue. On the Cantonese language page, the box showing how Cantonese is written overlaps the article's table of contents page. This happens in Firefox 2.0 with the window at about 60% of screen width (1024x768), but not when Firefox is maximized nor in IE6 at 60% width. Amber Firecat 17:29, 29 November 2006 (UTC)[reply]

I undestrand that this is not a bug, but this floating feature causes sometimes problems. One example is the Gambier Islands article. If firefox browser is 1280 pixels wide, then the panorama image covers the demographics numbers in the info box. —Preceding unsigned comment added by Erkiheiki (talk • contribs) 14:26, 14 January 2009 (UTC)[reply]

I don't know if it's intentional, but I think it'd be more useful to link to individual browser homepages. People w. problems can then check easily for a newer version.

I'm removing some text from the Internet Explorer section. Much of it is vague or doesn't even make sense (or perhaps just no longer applies). I am currently using IE6 on XP, SP2.

Perhaps most annoying are not the times when content doesn't appear in IE, but the times when Microsoft has gone out of their way to ensure that it does appear where other web browsers have stuck to the standards—see this revision for an example of what can occasionally result. More instances follow.

I don't think the beginning makes sense. Also, the given revision and the previous (and next) revisions look exactly the same to me, layout-wise. Overall, though, this should probably be put back with a concrete example.

IE cannot handle numeric character references (NCRs) in UTF-8: if a page uses this encoding and NCRs the encoding must be set to User Defined.

I've tried various websites and Wikipedia pages, and I think NCRs work fine for me.

Ardric47 02:24, 10 July 2006 (UTC)[reply]

There is no mention of Crazy Browser here. Anyone with information about this browser is welcome to add in the details here. --Siva1979^{Talk to me} 03:19, 1 September 2006 (UTC)[reply]

It seems to be just an IE shell, not a true distinct browser; as such, it probably has no rendering differences. *Dan T.* 22:37, 23 September 2006 (UTC)[reply]

If you take a look at Serie A there should be a table half way down detailing the results of the season so far. In IE, it is perfect, with the names along the top being shown vertically. But in Firefox, the names are being shown horizontally accross the page making the table far to wide when using firefox. Any fixes ? Niall123 22:21, 23 September 2006 (UTC)[reply]

Opera 8.54 on Win98SE here. I'm getting a sporadic error editing large pages, usually data tables and such, where <sup> gets replaced with >sup>, or colspan="2" with colspan="2" for example. Anybody else gets these glitches? Femto 11:27, 17 October 2006 (UTC)[reply]

Anyone else having trouble with alt-e and alt-s not editting pages but instead going to the Firefox Edit menu with 2.0? I just noticed this tonight (I think this is the 1st time I've tried in 2.0). Could be something dumb I've done or could be 2.0 issue. -Jcbarr 05:49, 16 November 2006 (UTC)[reply]

Firefox 2.0 has pre-empted ALT for the menus, and the default web page key bindings are now based on alt-shift instead. So alt-shift-s should work to save where alt-s used to. (Annoying!). Boojum 03:32, 9 December 2006 (UTC)[reply]

Agreed, extremely annoying. I found the way to undo this feature on this MozillaZine post, which is to browse to about:config and set the following variables:

ui.key.chromeAccess = 5
ui.key.contentAccess = 4

It works for me, and I haven't yet seen any undesirable side effects. – ipso 23:40, 6 January 2007 (UTC)[reply]

Using Blazer 4.3 under PalmOS Garnet v. 5.4.9 on a Palm T|X, Wikipedia text is rendered unreadable, as indicated on the main page for this talk page. When following the suggestions on the main page (attempted under username togr-palm), my handheld now crashes when I try to load the wikipedia main page in Blazer.

I'll try to find exactly which part of the stylesheet is the problem, but thought I'd report the problem at once. togr-palm

They appear below the text. See the screenshot of Toronto Raptors here: http://img95.imageshack.us/my.php?image=ffyg9.png —The preceding unsigned comment was added by MC (talk • contribs) 00:24, 5 May 2007 (UTC).[reply]

I have two problems with Firefox on Mac OS X (at the office, since I use M$ Windows [before] and Ubuntu Linux [now] at home).

The first is on Firefox 2, where the links in ANY Wikipedia page are shown to the left of their normal position. The more towards the right of a line they are, the more to the left they end up, to the point of overlapping the last or last 2 or 3 characters of the previous word. Consequently, any word to the right of the link is also moved a little bit towards the left, but there is (usally) the normal space between the link and it.

The second is with the new Beta 3 release of Firefox 3, issued today. It gives me all gibberish: instead of regular text (and I repeat: "regular" text, as the links all display properly), I get all kinds of odd characters.

An image of the problem I get can be seen at http://jetetrouve.com/fonttrouble.jpg (sorry I don't know how to get files on Wikipedia properly).

I think it has to do with some font (or fonts) being used under their "Pro" version, as I've had a similar problem when I used the font "Adobe Garamond Pro": the "Expert" version of this font can display similar characters. However it is not the font used here, as Garamond has serif and the "Firefox Wikipedia Font Problem" font has no serif.

Anyway I'm rather inexperimented with Mac OS (and I also find very stupid the way you need to "Activate" fonts in Suitcase in order to use them... on M$ and Linux, you install a font, you install a font: no need to activate it or whatever), so I have no clue how to fix this problem.

I was going to say that I don't have this problem with any other site, but today when I checked my own Web site, http://jetetrouve.com, which is for now just an "Online soon" page with no HTML encoding whatsoever (wrong may to do things, I know), it displayed similar gibberish.

Any help will be appreciated. Thanks in advance.

CielProfond (talk) 01:59, 20 February 2008 (UTC)[reply]

Suitcase is an Adobe App. OS X comes with something called FontBook by default, and requires fonts to be installed, but there's no separate activation. I suspect you're dealing with something your office has set up.

Your problem is almost undoubtedly related to a bad font -- I had the same problem until I deactivated a few duplicate fonts. FontBook can clean up duplicates and solve the problem, but I don't know how to address it with Suitcase, although probably someone else does.

If you have further questions about using OS X, I recommend the excellent forums at MacMentor. -- Avocado (talk) 21:57, 21 February 2008 (UTC)[reply]

I regularly use Firefox 41.0.2 with Mac OS X 10.6.8. IIRC, I did see font problems with Firefox and Wikipedia, some years ago. Works quite well now. Even non-Latin fonts render well, in many cases. I know the Cyrillic alphabet (as used in Russian). Just checked Hebrew, of which I have only a very partial knowledge, but seems to work. Am adding Firefox to list of OK browsers for Mac OS X. Among the Brahmic scripts, many work, but some don't. Oaklandguy (talk) 19:05, 31 October 2015 (UTC)[reply]

Wouldn't it make much more sense to order the browsers according to the used rendering engine? Shouldn't the exact number of the version of the browser (and the version number of the rendering engine if available) which causes the problem also be cited?

Example of ordering:

Mac OS X

WebKit based

• Safari
• OmniWeb 4.5+
• iCab 4.0+
• Shiira

Gecko based

• Mozilla Firefox
• Netscape
• Mozilla Suite
• Seamonkey
• Camino

Elektra based

• Opera 4 to Opera 6

Presto based

• Opera 7+

iCab prior to 4.0

OmniWeb prior to 4.5

--Liebeskind (talk) 18:57, 19 July 2008 (UTC)[reply]

Be bold and do it! -- Avocado (talk) 19:46, 19 July 2008 (UTC)[reply]

This seems to show artcile pages differently as from today with the inforbox on top of the artcile rather than at the side. If I swicth to IE it displays normally. Apologie sif not right place, but I am not sure whether this is a Wiki chnage or the new Firefox version.? Jezhotwells (talk) 16:36, 7 July 2009 (UTC)[reply]

I cant't update long articles on my new laptop Acer. I have a fast Adsl conection through ethernet cable. Do I have to change some setting ? When I save the article after some time of waiting the session is cancelled.

MSacerdoti —Preceding unsigned comment added by MSacerdoti (talk • contribs) 07:28, 22 April 2010 (UTC)[reply]

I have understood some browsers has limitions with page size. I hope someone can give an input on archive page size discussions based on current technology situation. --Kslotte (talk) 13:36, 4 September 2010 (UTC)[reply]

Hi,
For Linux ... Dillo, "Cookies are tricky, so logging in is tricky".

Thanks for the warning. =8~/ Someone who has succeeded to log in, please give tips to resolve the trickiness. Can an image be uploaded to Commons using Dillo?

Background
For several years I've used Firefox in Debian. Recently, probably since an upgrade, Firefox crashes frequently reporting "channel error". A documented bug.

This afternoon information for two uploaded images was almost complete when Firefox vanished from the screen. Troubleshooting Firefox will be a goose chase which may never succeed. At this rate the project may never be completed. If Dillo can work, good. It's fast. It isn't bogged with JavaScript.

Thx, ... PeterEasthope (talk) 23:01, 15 September 2022 (UTC)[reply]

my lynx version: 2.9.0dev.6-3~deb11u1 on debian bullseye. i have enabled color profile of lynx.lss on lynx.cfg & copy pasted code given on lynx.lss, both located at /etc/lynx/. is this issue for current version? <_>jindam, vani (talk) 05:58, 8 October 2022 (UTC)[reply]

i did ask on lynx-dev mailing list about diff pages: assign or view colors on INS: or DEL: on wikipedia diff page with the below settings (provided by Thomas Dickey at lynx-dev mailing list) in lynx.lss, you can view diff pages similar to gui browsers.
ins: reverse: green
del: reverse: red
the above settings working for me on Lynx Version 2.9.0dev.10 (11 Aug 2021) libwww-FM 2.14, SSL-MM 1.4.1, GNUTLS 3.7.7, ncurses 6.2.20201114(wide) Built on linux-gnueabihf.
lets hope this will bring more users..... <_> Jindam vani (talk) 14:41, 19 October 2022 (UTC)[reply]