< August 2003 >
How to work around small fonts in Internet Explorer (31st August 2003)
This item will show some of the common methods of dealing with text that is too small to read in Internet Explorer. In addition to the common methods I will also demonstrate a technique I developed myself. Internet Explorer users have can have problems with font sizing that other browser users do not have. These are related to two root causes:
- Limit of five levels of text sizing.
- Some text cannot be resized. (Fonts specified using "
px" values in CSS)
The limited level of text zoom Internet Explorer offers can be compensated for using screen magnification utilities. The second problem can also be overcome using some of Internet Explorers accessibility options available from the tools menu. In recent versions of Internet Explorer going to the Tools menu and selecting the "Internet Options..." item will give you access to configuration options that can modify how Internet Explorer displays pages. Under the "General" tab there should be a button for accessibility options usually labelled "Accessibility...". Selecting this button will open the screen for setting accessibility options.
The screen shot above shows the accessibility dialog, the important point to note here is the option to "Ignore font sizes specified on Web pages". This option is the important one because many web pages are set up to use small text by default. There are some web sites where the size of text cannot be increased by Internet Explorer. By ignoring font sizes pages that try too set a really small font won't be able to do so.
The uncommon solution
After briefly outlining two ways you can adjust Internet Explorers settings to better suit a persons preferred text size I'll outline another method I have developed, however first of all I'll identify a couple of weaknesses in the methods outlined above.
- Ignoring font sizes can break the layout of a page.
- Ignoring text sizes does not allow images containing text to be resized.
- A screen magnifier can be troublesome to start and use if you only need it occasionally.
I developed a couple of bookmarklet links for Internet Explorer that will resize a web page, including its graphics, to make the page more readable. This method has the advantage that it preserves the layout of the page and enlarges pictures as well as text. The two bookmarklets are my Zoom +25% bookmarklet that will zoom in on a page by 25% each time it is clicked, and my Zoom 100% bookmarklet that returns a page to its original size. These can be placed on the links bar so they are always available to click on and zoom in on a page. If you have Internet Explorer you can test if they work for you by clicking on the links in this page.
To add these bookmarklets to your link bar you need to first make sure the link bar is visible, go to "View", "Toolbars" and check that "Links" is selected. Drag the links bar so it is big enough to put the links on (the toolbars may be stop you resizing them, if so you need to unlock them by removing the check next to "Lock the toolbars" in the toolbars menu). When the links bar is big enough for them just click on the two links (Zoom +25%, Zoom 100%), keep the mouse button held down, and drag them to the toolbar, then let go. The links should be visible on the toolbar as shown in the screen shot above.
These bookmarklets do not work with other browsers such as Opera or Mozilla, however these browsers have generally better text resizing than Internet Explorer to start with and so don't require these workarounds.
Update: This guy seems to have come up with a similar idea to mine.
Thinking Of "Refactoring"? Not Got Any Unit Tests In Place? Bad Coder! (10th September 2003)
Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure.
Martin Fowler
I believe that sometimes code needs to be refactored. For example, an improvement in the internal structure of a software system is sometimes necessary in order to improve its extensibility. All too often however refactoring is taken to mean ripping out the guts of the system and starting again. It is a common problem that programmers will try to make the move to cleaner code by throwing out the existing body of work and beginning from scratch.
To be effective refactoring needs to be understood for what it really is. There are a couple of keys to effective use of refactoring in a project:
- Refactor in small iterations. After each iteration the external behaviour should be the same.
- Check that the external behaviour remains the same! This is where you run the test suite. You do have one don't you?
- Modifying or adding functionality is not refactoring! They are separate steps, keep them separate (using small refactoring steps reduces the temptation to merge these different processes)
Without rigorous testing of refactored code can you be sure that the code is functionally equivalent? If you are "refactoring" code and not testing it then you are potentially introducing bugs for no external benefit! I am reminded of a quote from Lou Montulli:
I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.
You cannot refactor code if you do not understand what its external behaviour is. When you perform refactoring in small steps with frequent testing then you will begin to get the benefits from it. Two key insights to refactoring are:
- It's easier to rearrange the code correctly if you don't simultaneously try to change its functionality.
- It's easier to change functionality when you have clean (refactored) code.
I cover this subject today because of a discussion I was involved in concerning the CSS property visibility and its value collapse. In investigating the situation with respect to the rendering of these properties I discovered that it was rendered incorrectly in a variety of browsers. Investigating whether this had been brought up in bug tracking system of the mozilla project I came across bug number 77019. The problem had been identified, reading the comments on the bug I came across this beauty of a comment:
Oh Noooooo, we had the collapse code working in the tree for years and it was simply optimized away. Hmm may be optimized is not the correct word for it.
And here lies the moral of this tale, refactoring without understanding the existing code or without rigorous testing equals the introduction of both regressions and new errors into the software system.