Academic Kids talk:Browser notes

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 (http://validator.w3.org/check/referer) 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 (http://sourceforge.net/tracker/index.php?func=detail&aid=731509&group_id=34373&atid=411192). Sadly, I don't have the time to learn PHP and contribute. -- Michaeln Thu Jul 17 01:43:51 UTC 2003

Contents

1 Safari problems

2 IE and Netscape layout rendering

3 Konqueror

4 IE and refreshes

5 Character encoding in Mozilla 1.1

6 Links on Linux

7 Current Events bug in Safari

8 Problems with iCab--Can anyone confirm?

9 Stub lks display like broken lks

10 Firefox and Mozilla are OK?

11 Evil wiki magic

12 How to edit with an external editor

13 Opera

14 Opera

15 Firefox 1.0.1 bug rendering diffs?

16 Removed a bit of quirkiness from the article

Safari problems

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)

IE and Netscape layout rendering

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] (http://www.wikipedia.org/w/wiki.phtml?title=Curvature&oldid=746795). 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)

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] (http://www.mozilla.org/)[3] (http://netscape.com)[4] (http://www.opera.com)[5] (http://www.kde.org/) --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)

Konqueror

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 < and > 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)

IE and refreshes

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

Character encoding in Mozilla 1.1

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)

Links on Linux

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)

Current Events bug in Safari

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 captioned text into spidery unreadable stuff, Netscape won't recognise 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 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 (http://leuksman.com/misc/smalltest) 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 (http://bugzilla.mozilla.org/show_bug.cgi?id=84887), 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. 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)

wearing the 1834 Triple Tiara
of Pope Gregory XVI

(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)

Missing image
Camino-showing-small-tags.jpg
Image: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 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 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:

Missing image
Camino-showing-smaller-tags.jpg
Image: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 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 (http://bugzilla.mozilla.org/show_bug.cgi?id=72164) and 201811 (http://bugzilla.mozilla.org/show_bug.cgi?id=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)

Problems with iCab--Can anyone confirm?

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)

Stub lks display like broken lks

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)

Firefox and Mozilla are OK?

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)

Evil wiki magic

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 (http://home.att.net/~jameskass/code2001.htm) font.

How to edit with an external editor

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 this (http://www.voip-info.org/tiki-index.php?page=vim+syntax+highlighting) 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)

Opera

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

Opera

Firefox 1.0.1 bug rendering diffs?

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 ~~upgrade~~install (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)

Removed a bit of quirkiness from the article

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)

Retrieved from "https://academickids.com:443/encyclopedia/index.php/Academic_Kids_talk:Browser_notes"

Academic Kids talk:Browser notes

Safari problems

IE and Netscape layout rendering

Konqueror

IE and refreshes

Character encoding in Mozilla 1.1

Links on Linux

Current Events bug in Safari

Problems with iCab--Can anyone confirm?

Stub lks display like broken lks

Firefox and Mozilla are OK?

Evil wiki magic

How to edit with an external editor

Opera

Opera

Firefox 1.0.1 bug rendering diffs?

Removed a bit of quirkiness from the article

Navigation

Search

Toolbox

Personal tools