Dean Edwards has produced a nice application that fixes a number of Internet Explorer's most glaring failures in supporting web standards. Fittingly, he has called this app IE7.
Update 2006.01.03:
Firefox 1.5.0.1 will break the current release version of Spellbound (0.7.3). However, you can give the SpellBound Development version. I've been running it for a while now, and it seems to be stable.
Update 2004.09.21:
Spellbound works great with the preview release of Firefox 1.0. I had to reinstall the extension, but after that everything was smooth spelling.
Update 2004.07.13:
For all of you who are having problems installing Torisugari's spell check extension working should check out SpellBound. I just installed this new spell checker extension on a machine with Firefox 0.9.2, and the installation was flawless.
In February I wrote a piece on getting Torisugari's form spell checker extension working with Firefox 0.8, which was linked to a good bit. Since I some had difficulties getting the spell check extension working with Firefox 0.9, I figured that I'd share how I got the extension working this time.
The following is the successful procedure that go the spell checker working on my Windows XP machine.
Firefox 0.9.1 was released today. 0.9.1 is a minor maintenance release, which fixes some bugs in the new extension manager and updates some of the default theme's icons.
I'm happy to report that I've installed this version directly on top of an existing install of 0.9 and the spell checker extension still works :)
John Haller has created a handy Firefox package that will run off of a USB drive. While I don't personally have too much of a use for this application, I'm sure some people will consider the portablity invaluable.
A release candidate for Mozilla Firefox 0.9 was released last week. The two most notable changes for this release are a new extension manager and a new default theme, with the later causing a bit of controversy.
Henrik Gemal has posted an amusing Mozilla swear word count, listing the number of times fuck, shit, crap, and bastard appear in the Mozilla source code.
Dave Shea has written down a gret set of techniques for side-stepping CSS problems in IE.
A couple quick modifications can get rich Text Editing in Movable Type working for Mozilla (and Firefox).
iCapture, a new site, allows you to see how any page looks in Safari.
The mozillazine forums have a nice thread about tuning Firefox for optimal performance.
While I find the default configuration of Firefox quite fast, some of these tweaks can significantly help those with unusual connections (slow dialup, satellite, etc.).
This week it was reported that a Windows code leak made a portion of Windows Nt/2000 source code publically available.
While there have a been a number of spins on this incident, and I'm sure that a number of people in Redmond have gotten red-faced over this development, I'm not so sure that this will end up being a bay thing for Microsoft. I've often rolled my eyes when hearing that microsoft's hidden OS code is a security feature, because I think that this deters skilled, benevolent people from reviewing the code. It also disallows these same people from quickly developing and distributing a fix for for any holes found.
While I'm pondering this subject, I have to ask myself wouldn't it be great if the Internet Explorer source code got leaked so people could work on fixing some of IE's more painful rendering bugs?
Update 2004.07.13:
For all of you who are having problems installing Torisugari's spell check extension working should check out SpellBound. I just installed this new spell checker extension on a machine with Firefox 0.9.2, and the installation was flawless.
Update: 2004.06.18
I've posted a note on how to get the spell check extension working in Firefox 0.9.
A number of people have reported difficulties getting this extension to work in the new Firefox 0.8 release. I've gotten the extension up and running on my Windows XP machine by doing the following:
- Make a copy of the composer.xpt file in the Firebird components directory
- Uninstall Firebird
- Grab the stuff I want from my old profile (bookmarks, etc), which is still labeled Phoenix, and then delete the profile
- Install Firefox, but not starting the program immediately after the install
- Place a copy composer.xpt into the Firefox components directory
- Start Firefox
- Install spellcheck.xpi from:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/windows-xpi/
- Shut down Firefox
- Install fromspellcheckerfe0_4_0.xpi :
http://cgi29.plala.or.jp/~mozzarel/addon/firebird/spellchecker/
(You can also get the composer.xpt file here as well in case you've deleted it)
- Shut down Firefox again
- Start Firefox
I'm thinking that the majority of people's problems getting the spell checker to work for Firefox stems from the installer defaulting to a new program directory than the Firebird installer. This new components directory will not have the composer.xpt file in it (it was dropped from Firebird/Firefox builds a while ago. I can't remember exactly when.). Since I believe that this is the problem you could probably get by without having to wipe your old profile before.
Hope this helps.
Update: 2004.02.12
Two things:
1. I noticed that the a thread on the Mozillaziine forums covered this issue, and it looks like you can install the composer.xpt file after running Firefox and, at least from what I read, that there is no need to wipe your old profile.
2. I read on the same forum version 0.3.5 of the spellcheck xpi is actually the most current version, and that 0.4 version was more of an experiment that has been abandoned (although it still works fine).
Designers moving to the use of CSS for page layout often find that the min-width, max-width, min-height and max-height properties are indispensable for constructing a layout that meets their needs. There's just one problem: Internet Explorer doesn't support these properties.
Fortunately, there is a JavaScript workaround available that makes these properties work for Microsoft's browser.
I've found a new favorite listing of CSS Hacks and Filters. Very well done.
It looks like Mozilla now supports the indirect adjacent sibling combinator.
An example of this selector would be h1 ~ pre:
h1 ~ pre
would select the <pre> element in the following example.
<h1>Header</h1>
<p>some text</p>
<p>some text <code>some code</code></p>
<pre>some preformatted text</pre>
The Burning Edge - Mozilla Firebird nightly build blog is a great place to keep up to date about what is currently happening with the development of Mozilla Firebird.
I wrote last month about the need for textarea spell checking in Mozilla.
Well, it looks like the wait is over.
A working solution has been posted in the Mozillazine forums by Torisugari. I've loaded it onto my Firebird 0.7 build and it's been working great so far. I encourage anyone wanting this functionality in Mozilla or Firebird to give this a try.
Update: 2004.06.18
I've posted a note on how to get the spell check extension working in Firefox 0.9.
I've often thought about trying out Browsercam. This urge has increased over the last few months as the number of pertinent prominent browsers (primarily Safari) that can't be tested on a windows machine has increased.
This might be the perfect excuse for me to plunk down the cash for one of those new spiffy iMacs, or it might cause me to start thinking about design in a more device-neutral way by creating less complex sites that wouldn't require extensive testing.
I've been using ieSpell for a while now and have been loving it. I've wished for a similar type od application for my primary browser, Mozilla Firebird, for a while now.
While it isn't as tightly integrated as ieSpell is MozEx will accomplish what I'll after. In addition to letting you choose an application to edit textarea text with, it also allows you to choose which applications should handle view page source, mailto, news, telnet, and ftp links, and download files.
AOL Cuts Remaining Mozilla Hackers
While part of me was sad to hear this news, Mozilla might just be better off on it's own.
The Mozillazine forums has a great thread, about:something, where you can learn about all of the about: combinations that you can type into the Mozilla address bar to retrieve all sorts of information. The only one that I use with any regularity is about:config, although about:kitchensink is good for a smile.
Mozillazine has posted a note about the Branch Cut for Mozilla 1.5 Alpha. While Mozilla has stated that 1.4 will be the last version before switching to distributing standalone components (e.g., Firebird, Thunderbird, etc.), they are continuing development of the suite-based product until the standalone versions are ready for prime time.
I was reading Joel Spolsky's blog and came across an entry reporting that IE 6 will be the last standalone version of the browser.
Freshmeat has a review of Lightweight Web Browsers for Linux written by Kamil Klimkiewicz. Kamil reviews and compares Links, Dillo, Amaya, and w3m.
Mozilla has released version 0.6 of its Firebird browser (formerly known as Phoenix). I've been using it for the better part of today and it has been smooth browsing so far..
Mozilla released version 1.4b of their browser suite yesterday.
1.4 appears to be the last version for the integrated Mozilla suite. The new Mozilla development roadmap states that next versions will incorporate standalone email and browser applications (now known as Firebird and Thunderbird respectively).
Personally, I've switched much of my mail browsing over to Firebird. It's a great, highly-customizable browser.
Opera has released yet another version of their browser.
Opera 7.10 incorporates a few new features including:
Recently, after public outcry, Opera released an upgrade to version 6 of its browser. Version 6.06 fixes some security issues that were discovered after version 7 had already been released. This breaks with the company's previous tradition of not releasing updates for browser versions other than the most current release.
I applaud this move, even though I, unlike many others, prefer Opera 7 over 6. Opera is, after all, commercial software, and customers should expect a certain level of continuing support for software that they've purchased.
The following was a little piece that I wrote in response to some posts on the Web4Lib discussion list commenting on the inherent inaccessibility of DHTML menus.
***************************************
Replies inline:
TD> that you have
TD> a responsibility to support users who use keyboard navigation and those
TD> who have Javascript disabled. Making essential site navigation
TD> available only through Javascript mouseovers is a serious accessibility
TD> failure.
Very true, but it isn't as hard to make such things accessible as some
people would have you believe.
Creating a keyboard navigation-compatible DHTML menu isn't any more
difficult than creating keyboard navigation on any other page.
It's also quite easy to make JavaScript-based navigation degrade to simple HTML links when
JavaScript is turned off.
<div class="menuLabel" id="menuLabel1"><a class="ml" onclick="menuShow(event,1); return false;"
onmouseover="menuShow(event,1)" href="items.html" accesskey="l"><span style="text-decoration: underline;">L</span>abel1</a></div>
<div class="menuBox" id="menu1">
<a class="m" href="item1.html" accesskey="1">Item <span style="text-decoration: underline;">1</span></a><br>
<a class="m" href="item2.html" accesskey="2">Item <span style="text-decoration: underline;">2</span></a><br>
<a class="m" href="item3.html" accesskey="3">Item <span style="text-decoration: underline;">3</span></a><br>
</div>
The example above shows the markup for a simple DHTML menu.
The first couple lines contain define the menu label. Including an
href and the "return false" within the on onclick event handler allows
the menu label to function as a plain HTML link when JavaScript is
turned off.
Also, you'll notice that each of the menu links employs an accesskey
to ease keyboard navigation.
EO> please also include
EO> some method to skip the navigation for text/limited-or-no-sight browser
EO> users. Methods include the 1x1 pixel "invisible" gif with link to anchor
EO> after the navigation and/or use CSS to create an aural (and/or print)
EO> stylesheet. If anyone has another method, please let me know.
Another method is to use CSS set the link text's display to "hidden".
Examples of both methods are below:
<a name="topofpage" id="linktocontent" href="#content" style="display:hidden;">skip to main content</a>
<a href="#content" title="skip to main content"><img src="spacer.gif" alt="skip to main content - image link" border="0"></a>
Both of these methods will satisfy section o of Section 508:
A method shall be provided that permits users to skip repetitive
navigation links.
PLP> I run into this issue frequently. Some people think javascript mouseover
PLP> menus are a good way of cramming lots of choices on the page, without making
PLP> it look crowded.
Menus are a very good way of placing many choices into a small area.
Additionally, menu conventions are firmly established, with OS GUIs
making wide use of menus.
PLP> So, before using javascript, I think one should try to organize their pages
PLP> better, perhaps a different schema is needed if the menus are necessary.
Menus are rarely necessary, however they can greatly clean up an
interface that would otherwise be cluttered. Also,
PLP> If on the other hand, it must be, my understanding of accessibility is that
PLP> as long as there is an alternative, it is fine.
Yes and no.
Yes, if you can't make your pages accessible through other means, then
alternatives are needed. Again, this is clearly stated in Section
508:
(k) A text-only page, with equivalent information or functionality, shall be
provided to make a web site comply with the provisions of this part, when
compliance cannot be accomplished in any other way. The content of the
text-only page shall be updated whenever the primary page changes.
Please note the words "cannot be accomplished in any other way"
above.
In addition to creating a duplicate site maintenance need, alternative
content and/or functionality is all too often simply slapped onto a
site. While this may technically provide compliance, it can lead to
an attitude of complacency towards accessibility and site design for
alternate access devices.
Remember, accessibility is just one part of site design. You still
must make an effort to make sure that your users will be able to
effectively interact with your site no matter which user agent they
are using. You can create a site that complies with all of the
accessibility guidelines, yet still be a nightmare to use with an
alternate access device.
Just like site design for conventional visual browsers, accessibility
(ensuring cross-browser compatibility is simply accessibility applied
to visual browsers) is just one aspect of ensuring that your site
functions well, and no level of accessibility guideline compliance
alone will ensure that your users will be able to easily use your
site.
--
Andrew
The following was a little piece that I wrote in response to some posts on the Web4Lib discussion list commenting on the inherent inaccessibility of DHTML menus.
***************************************
Replies inline:
TD> that you have
TD> a responsibility to support users who use keyboard navigation and those
TD> who have Javascript disabled. Making essential site navigation
TD> available only through Javascript mouseovers is a serious accessibility
TD> failure.
Very true, but it isn't as hard to make such things accessible as some
people would have you believe.
Creating a keyboard navigation-compatible DHTML menu isn't any more
difficult than creating keyboard navigation on any other page.
It's also quite easy to make JavaScript-based navigation degrade to simple HTML links when
JavaScript is turned off.
<div class="menuLabel" id="menuLabel1"><a class="ml" onclick="menuShow(event,1); return false;"
onmouseover="menuShow(event,1)" href="items.html" accesskey="l"><span style="text-decoration: underline;">L</span>abel1</a></div>
<div class="menuBox" id="menu1">
<a class="m" href="item1.html" accesskey="1">Item <span style="text-decoration: underline;">1</span></a><br>
<a class="m" href="item2.html" accesskey="2">Item <span style="text-decoration: underline;">2</span></a><br>
<a class="m" href="item3.html" accesskey="3">Item <span style="text-decoration: underline;">3</span></a><br>
</div>
The example above shows the markup for a simple DHTML menu.
The first couple lines contain define the menu label. Including an
href and the "return false" within the on onclick event handler allows
the menu label to function as a plain HTML link when JavaScript is
turned off.
Also, you'll notice that each of the menu links employs an accesskey
to ease keyboard navigation.
EO> please also include
EO> some method to skip the navigation for text/limited-or-no-sight browser
EO> users. Methods include the 1x1 pixel "invisible" gif with link to anchor
EO> after the navigation and/or use CSS to create an aural (and/or print)
EO> stylesheet. If anyone has another method, please let me know.
Another method is to use CSS set the link text's display to "hidden".
Examples of both methods are below:
<a name="topofpage" id="linktocontent" href="#content" style="display:hidden;">skip to main content</a>
<a href="#content" title="skip to main content"><img src="spacer.gif" alt="skip to main content - image link" border="0"></a>
Both of these methods will satisfy section o of Section 508:
A method shall be provided that permits users to skip repetitive
navigation links.
PLP> I run into this issue frequently. Some people think javascript mouseover
PLP> menus are a good way of cramming lots of choices on the page, without making
PLP> it look crowded.
Menus are a very good way of placing many choices into a small area.
Additionally, menu conventions are firmly established, with OS GUIs
making wide use of menus.
PLP> So, before using javascript, I think one should try to organize their pages
PLP> better, perhaps a different schema is needed if the menus are necessary.
Menus are rarely necessary, however they can greatly clean up an
interface that would otherwise be cluttered. Also,
PLP> If on the other hand, it must be, my understanding of accessibility is that
PLP> as long as there is an alternative, it is fine.
Yes and no.
Yes, if you can't make your pages accessible through other means, then
alternatives are needed. Again, this is clearly stated in Section
508:
(k) A text-only page, with equivalent information or functionality, shall be
provided to make a web site comply with the provisions of this part, when
compliance cannot be accomplished in any other way. The content of the
text-only page shall be updated whenever the primary page changes.
Please note the words "cannot be accomplished in any other way"
above.
In addition to creating a duplicate site maintenance need, alternative
content and/or functionality is all too often simply slapped onto a
site. While this may technically provide compliance, it can lead to
an attitude of complacency towards accessibility and site design for
alternate access devices.
Remember, accessibility is just one part of site design. You still
must make an effort to make sure that your users will be able to
effectively interact with your site no matter which user agent they
are using. You can create a site that complies with all of the
accessibility guidelines, yet still be a nightmare to use with an
alternate access device.
Just like site design for conventional visual browsers, accessibility
(ensuring cross-browser compatibility is simply accessibility applied
to visual browsers) is just one aspect of ensuring that your site
functions well, and no level of accessibility guideline compliance
alone will ensure that your users will be able to easily use your
site.
--
Andrew
Mozilla released version 1.4a of its browser suite this week.
This release is widely rumored to be the basis for the next Netscape release, which to this point has been based on the 1.0 branch. This would appear to make sense with the new Mozilla project plans announced in the newly revised Mozilla Roadmap, which states that the 1.4 branch will replace the 1.0 branch as the "stable" branch.
A handy Internet Explorer plug-in that I frequently use is ieSpell, which will spell check text that you type into forms. It's great for help ensuring that this blog comes to you type-free.
MozillaNews hosts a page where users comment on the quality of Mozilla nightly builds.
This page is also useful if you've been waiting for a particular feature to land.
ZDNet has a great articles this week "What if Netscape had won?"
Charles Cooper fantasizes about a world were Netscape would have won the browser war and reflects on the current, one browser state of the Web, where Microsoft has had little incentive to innovate since 1999.
In addition to the article, there is a lively "Talkback" section where users get to voice their opinions on the Cooper's thoughts.
Thanks to Andy King's WebReference Update for highlighting this article.
Opera releases version 7.03 of its browser.
This fixes some security issues..
Mozilla released version 1.3 of its browser today.
Among the new features in 1.3 are Mozilla Midas (rich text editing controls), improved spam filtering, and the ability to dynamically switch profiles.
Opera has released version 7.02 of its browser.
This is a minor maintenance release.
Opera has already released an update to the latest version of their browser.
I've been playing around with the Beta 2 release of Opera 7 this past week.
I'd noticed that a few pages using font-size keywords now map the keyword values as the more intuitive medium=default size way instead of previous small=default size.
I've come across some general rumblings about this release introducing Doctype-switching, but haven't come across any listing of the specific doctypes that cause the browser to go into "quirks" mode, so I decided to look into this myself.
The table below is the result of a quick and dirty test by creating a simple page with <span style="font-size:meduim;">test</span> and seeing wihcih DOCTYPEs caused the Opera to render "medium" text as the "quirky" larger than default. As you can see that vast majority of DOCTYPEs will put Opera into its new "standards" mode.
No DOCTYPE | Quirks |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> | Quirks |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> | Quirks |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict //EN"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict //EN" "http://www.w3.org/TR/html4/strict.dtd"> | Standards |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> | Standards |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> | Standards |
I've been playing around with the Beta 2 release of Opera 7 this past week.
I'd noticed that a few pages using font-size keywords now map the keyword values as the more intuitive medium=default size way instead of previous small=default size.
I've come across some general rumblings about this release introducing Doctype-switching, but haven't come across any listing of the specific doctypes that cause the browser to go into "quirks" mode, so I decided to look into this myself.
The table below is the result of a quick and dirty test by creating a simple page with <span style="font-size:meduim;">test</span> and seeing wihcih DOCTYPEs caused the Opera to render "medium" text as the "quirky" larger than default. As you can see that vast majority of DOCTYPEs will put Opera into its new "standards" mode.
No DOCTYPE | Quirks |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> | Quirks |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> | Quirks |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict //EN"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> | Standards |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict //EN" "http://www.w3.org/TR/html4/strict.dtd"> | Standards |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> | Standards |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> | Standards |
In case you were sleeping under a rock yesterday, Apple released their Safari web browser.
The new browser is based on the KHTML engine (previously used for the KDE browser, Konqueror).
Mark Pilgrim has collected a very nice set of Safari-related links.
Also, Eric Meyer reports that:
Meanwhile, I've heard credible rumors that Apple, while it was working on Safari, filed Bugzilla evangelism bugs so that the Standards Evangelists at Netscape (of which I'm one) would get the sites to fix their code to work with Gecko and other standards-compliant browsers. This would then, they apparently hoped, get the sites working in Safari as well. If this turns out to be true, I'm going to be furious; just the idea that it could be true makes me angry. I don't mind helping out Apple. I'm a Macintosh guy and have been for more than a decade now. I do mind being tricked into doing their work for them. Hey, guys, what's wrong with saying, "We're both working on standards-based browsers, so let's work together to get sites to support standards?" You know, being honest? How about that? Anyone think of that?
Mozilla released version 1.0.2 of their browser yesterday.
You can read comments about the browser at Mozillazine.
Personally, I've found the later Mozilla releases just as stable as the 1.0 branch.
If you don't need or want a mail client included with your browser check out Phoenix. Be sure to check out my favorite Phoenix theme, Breeze.
The 0.5 release of Phoenix came out this past week and I've found myself using it more and more.
If you've found yourself switching from Netscape to Mozilla for a less cluttered browser only to find that you'd like even less clutter, then I'd recommend checking this browser out.
Now if only I could magically convert all of my old table-based pages that break in Gecko-based browsers when certain DOCTYPES are used :) .