Most would agree that a browser’s default style sheet does a pretty good job of making text
legible. Typically, the font size will be a non-squint-inducing 16px, with black text on a white
background. In the following sections, we’ll start with this default styling and apply numerous
CSS properties to the markup (without adding any further elements to it) in order to explore
the multitude of available techniques for creating good-looking web text.
Create a new document called text.html and type the following (X)HTML into it. You
can also grab the complete text.html file from the Chapter 4 folder in the code download at
www.apress.com:
<html>
<head>
<title>Chapter 4: Text</title>
</head>
<body>
<h1>Content is King</h1>
<p>This is a paragraph. Nothing particularly special about it, but the ➥
visitor is going to read it anyway, so it may as well say something useful.</p>
<h2>True Fact</h2>
<p>Useful. OK. Did you know that a shrimp's heart is actually in its head? ➥
It's true.</p>
</body>
</html>
A shrimp’s heart is actually in its head. Bet you didn’t know that, did you? This incredibly
informative text (just two headings and two paragraphs) will be used throughout the rest of this
chapter.
Let’s get down to the serious business and forget about seafood. Firefox will display this
(X)HTML as shown in Figure 4-5 using its default style sheet.
While this display is very legible, it isn’t very stylish. It is likely that the default style sheet
will specify either Arial or more likely Times New Roman for the font, giving that classic
“unstyled” feel.
Showing posts with label BROWSER. Show all posts
Showing posts with label BROWSER. Show all posts
Saturday, October 23, 2010
Thursday, September 30, 2010
A browser test suite
when various browsers were created, their approximate
share of the market, and the major problems they cause. However, it’s important to
note that the market is in continual change—just a quick look at Netscape’s fortunes
should be enough to prove that. Utterly dominant during the period when the Web first
started to become mainstream, its share of the market was decimated by the then-upstart
Internet Explorer, and it’s now all but vanished. The point, of course, is that you cannot
predict how the browser market will change, and although Internet Explorer is sitting
proud today, its share of the market has been hit hard in recent years by Firefox, and this
downward trend for Microsoft’s browser could continue . . . or not. Also, each year sees
new releases of web browsers, with new features and updated—but usually incomplete—
standards support.
All of this is a roundabout way of saying that you need to think hard about browsers when
you’re creating your work. Don’t only test sites in a single browser, and don’t use the most
popular for your starting point if it’s not the most standards-compliant. Instead, use a
browser with a good grasp of web standards for your first line of tests, until you’ve got
your templates working. I personally use the Gecko engine as a starting point—more
specifically, I favor Firefox as an initial choice of browser. Opera is also a decent choice,
and Mac users can probably get away with using Safari for initial tests.
Once the basic structure is up and running, I test in a range of alternate web browsers, typically
in the following order:
share of the market, and the major problems they cause. However, it’s important to
note that the market is in continual change—just a quick look at Netscape’s fortunes
should be enough to prove that. Utterly dominant during the period when the Web first
started to become mainstream, its share of the market was decimated by the then-upstart
Internet Explorer, and it’s now all but vanished. The point, of course, is that you cannot
predict how the browser market will change, and although Internet Explorer is sitting
proud today, its share of the market has been hit hard in recent years by Firefox, and this
downward trend for Microsoft’s browser could continue . . . or not. Also, each year sees
new releases of web browsers, with new features and updated—but usually incomplete—
standards support.
All of this is a roundabout way of saying that you need to think hard about browsers when
you’re creating your work. Don’t only test sites in a single browser, and don’t use the most
popular for your starting point if it’s not the most standards-compliant. Instead, use a
browser with a good grasp of web standards for your first line of tests, until you’ve got
your templates working. I personally use the Gecko engine as a starting point—more
specifically, I favor Firefox as an initial choice of browser. Opera is also a decent choice,
and Mac users can probably get away with using Safari for initial tests.
Once the basic structure is up and running, I test in a range of alternate web browsers, typically
in the following order:
1. The other compliant browsers: Typically, I use Firefox as a starting point, although
sometimes I use Safari. Whichever one you choose to start in, it’s a good idea to
test in the other compliant browsers first. Sometimes, one will pick up a coding
error the others don’t, and it’s a good sanity check to ensure everything’s working
well. If you’re lucky, everything will work fine right away in all of these browsers, on
both Mac and Windows.
2. A browser in text mode: What I mean by this is testing the site without CSS, which
is a way of somewhat figuring out if it’s usable on alternate devices. Old hands
might use Lynx for this, but I instead use the Accessibility layout option of Opera’s
User mode (see the following screenshot). The Firefox Web Developer toolbar
(www.chrispederick.com) offers similar options.
3. Internet Explorer 7 for Windows: Although this release of Internet Explorer is a vast
improvement over previous efforts, it’s not as standards-compliant as the other
mainstream browsers. Therefore, tests need to be done to ensure everything’s
working properly, not least because Internet Explorer 7 is the most popular
browser in terms of market share. If things aren’t working right, conditional comments
need to be used (see the “Dealing with Internet Explorer bugs” section later
in the chapter).
4. Internet Explorer 6 for Windows: Previously the most popular browser, this release
is still in heavy use. Fairly compliant, it nonetheless has a raft of bugs, and complex
CSS layouts will almost certainly need a little tweaking to work properly, again via
the use of conditional comments. Note that because only Windows XP users can
upgrade from Internet Explorer 6 to 7 (7 being the native browser for Windows
Vista), a fair number of users—those with an earlier version of Windows—will likely
use 6 for some time to come.
is still in heavy use. Fairly compliant, it nonetheless has a raft of bugs, and complex
CSS layouts will almost certainly need a little tweaking to work properly, again via
the use of conditional comments. Note that because only Windows XP users can
upgrade from Internet Explorer 6 to 7 (7 being the native browser for Windows
Vista), a fair number of users—those with an earlier version of Windows—will likely
use 6 for some time to come.
5. Internet Explorer 5.5 for Windows: How far you go back, in terms of versions of
Internet Explorer, depends on your target market, the client’s budget, and general
expectations. Typically, I test the most recent three major versions of Microsoft’s
browser, due to their heavy usage. Internet Explorer 5.0 can be considered almost
extinct, however. Overall, Internet Explorer 5.5 has more problems than Internet
Explorer 6, although most of them are easy enough to work around. Generally, I
don’t aim to get sites working perfectly in this browser—a few cosmetic oddities
are acceptable, in my opinion, because there’s no point in compromising a totally
compliant site to make it more compatible for an aging browser whose market
share is in rapid decline. Ensuring content is accessible in the browser is essential,
however, and the primary concern when dealing with obsolete browsers.
6. Everything—all over again: When any major changes are made, you need to go back
through your browsers and make sure the changes haven’t screwed anything up.
There are other browsers out there, but the preceding list will deal with the vast majority
of your users. However, always try to find out the potential audience for a website to
ascertain whether you should place more focus on a particular browser. For example, if
authoring a site for a mostly Mac-based audience, it might make sense to use Safari as the
basis for testing, and perhaps even wheel out the long-canceled Internet Explorer 5 for
Mac, just to make sure your site works in it.
At each stage of testing, I recommend that you save HTML and CSS milestones on a very
regular basis. If something fails in a browser, create a copy of your files and work on a fix.
Don’t continually overwrite files, because it’s sometimes useful—and, indeed, necessary—
to go back to previous versions.
Whichever browsers you test in, it’s important to not avoid the “other side.” Windows
users have long seen the Mac as being inconsequential, but at the time of writing Safari
now counts for about 4% of all web users, and the trend for Mac sales (as a percentage of
the market) is upward. Usefully, there’s now a version of Safari for Windows, but even the
Mac and Windows versions of Firefox show slight differences in the way sites are handled
(mostly regarding text). Even worse, many Mac-based designers don’t test on a Windows
PC or in Internet Explorer, which has the bulk of the market. If you’re a Windows user, grab
a cheap Mac that’s capable of running Mac OS X (such as a second-hand iBook or a Mac
mini), and if you’re a Mac user, either grab a cheap Windows PC to test with or run
Windows as a virtual machine (via Parallels Desktop or VMware Fusion) on an Intel Mac or
using Virtual PC if you have a PPC-based machine. (You can also use Boot Camp on an Intel
Mac, but that requires booting back and forth between Windows and Mac OS X, so using
a virtual environment is more efficient unless you have two computers.) Linux users also
have a range of browsers to test on. Firefox is popular on that platform, and Safari is a
rough analog for Konqueror. It is worth noting, however, that the default fonts with Linux
vary considerably from those that you’d expect on a Mac or Windows PC—so you should
always define fallback fonts accordingly, and test in Linux if possible. See Chapter 3 for
more on font stacks.
of your users. However, always try to find out the potential audience for a website to
ascertain whether you should place more focus on a particular browser. For example, if
authoring a site for a mostly Mac-based audience, it might make sense to use Safari as the
basis for testing, and perhaps even wheel out the long-canceled Internet Explorer 5 for
Mac, just to make sure your site works in it.
At each stage of testing, I recommend that you save HTML and CSS milestones on a very
regular basis. If something fails in a browser, create a copy of your files and work on a fix.
Don’t continually overwrite files, because it’s sometimes useful—and, indeed, necessary—
to go back to previous versions.
Whichever browsers you test in, it’s important to not avoid the “other side.” Windows
users have long seen the Mac as being inconsequential, but at the time of writing Safari
now counts for about 4% of all web users, and the trend for Mac sales (as a percentage of
the market) is upward. Usefully, there’s now a version of Safari for Windows, but even the
Mac and Windows versions of Firefox show slight differences in the way sites are handled
(mostly regarding text). Even worse, many Mac-based designers don’t test on a Windows
PC or in Internet Explorer, which has the bulk of the market. If you’re a Windows user, grab
a cheap Mac that’s capable of running Mac OS X (such as a second-hand iBook or a Mac
mini), and if you’re a Mac user, either grab a cheap Windows PC to test with or run
Windows as a virtual machine (via Parallels Desktop or VMware Fusion) on an Intel Mac or
using Virtual PC if you have a PPC-based machine. (You can also use Boot Camp on an Intel
Mac, but that requires booting back and forth between Windows and Mac OS X, so using
a virtual environment is more efficient unless you have two computers.) Linux users also
have a range of browsers to test on. Firefox is popular on that platform, and Safari is a
rough analog for Konqueror. It is worth noting, however, that the default fonts with Linux
vary considerably from those that you’d expect on a Mac or Windows PC—so you should
always define fallback fonts accordingly, and test in Linux if possible. See Chapter 3 for
more on font stacks.
DEALING WITH BROWSER QUIRKS : Weeding out common errors
Testing in browsers isn’t everything; in fact, you may find that your site fails to work for no
reason whatsoever, tear your hair out, and then find the problem lurking in your code
somewhere. With that in mind, you should either work with software that has built-in and
current validation tools (many have outdated tools, based on old versions of online equivalents),
or bookmark and regularly use the W3C’s suite of online tools: the Markup
Validation Service (http://validator.w3.org/), CSS Validation Service (http://jigsaw.
w3.org/css-validator/), Feed Validation Service (http://validator.w3.org/feed/),
Link Checker (http://validator.w3.org/checklink), and others (www.w3.org/QA/Tools/)
as relevant.
reason whatsoever, tear your hair out, and then find the problem lurking in your code
somewhere. With that in mind, you should either work with software that has built-in and
current validation tools (many have outdated tools, based on old versions of online equivalents),
or bookmark and regularly use the W3C’s suite of online tools: the Markup
Validation Service (http://validator.w3.org/), CSS Validation Service (http://jigsaw.
w3.org/css-validator/), Feed Validation Service (http://validator.w3.org/feed/),
Link Checker (http://validator.w3.org/checklink), and others (www.w3.org/QA/Tools/)
as relevant.
Other useful online services include WDG Link Valet (www.htmlhelp.com/tools/valet/),
WDG HTML Validator (www.htmlhelp.com/tools/validator/), and Total Validator (www.
totalvalidator.com/). Accessibility-oriented services include HP’s Color Contrast Verification
Tool (www.hp.com/hpinfo/abouthp/accessibility/webaccessibility/color_tool.html);
Etre’s Colour Blindness Simulator (www.etre.com/tools/colourblindsimulator/); and
the Cynthia Says Portal Tester (www.cynthiasays.com/fulloptions.asp), which can
aid you in Section 508 and WAI (Web Accessibility Initiative—see www.w3.org/WAI/)
compliance.
Here are some of the more common errors you might make that are often overlooked:
WDG HTML Validator (www.htmlhelp.com/tools/validator/), and Total Validator (www.
totalvalidator.com/). Accessibility-oriented services include HP’s Color Contrast Verification
Tool (www.hp.com/hpinfo/abouthp/accessibility/webaccessibility/color_tool.html);
Etre’s Colour Blindness Simulator (www.etre.com/tools/colourblindsimulator/); and
the Cynthia Says Portal Tester (www.cynthiasays.com/fulloptions.asp), which can
aid you in Section 508 and WAI (Web Accessibility Initiative—see www.w3.org/WAI/)
compliance.
Here are some of the more common errors you might make that are often overlooked:
Spelling errors: Spell a start tag wrong and an element likely won’t appear; spell an
end tag wrong and it may not be closed properly, wrecking the remaining layout. In
CSS, misspelled property or value names can cause rules—and therefore entire layouts—
to fail entirely. British English users should also remember to check for and
weed out British spellings—setting colour won’t work in CSS, and yet we see that
extra u in plenty of web pages (which presumably have their authors scratching
their heads, wondering why the colors aren’t being applied properly).
Incorrect use of symbols in CSS: If a CSS rule isn’t working as expected, ensure
you’ve not erred when it comes to the symbols used in the CSS selector. It’s a
simple enough mistake to use # when you really mean . and vice versa.
Lack of consistency: When working in XHTML, all elements and attributes must be
lowercase. In CSS, tag selectors should also be lowercase. However, user-defined id
and class values can be in whatever case the author chooses. Ultimately, decide
on a convention and stick to it—always. If you set a class value to myvalue in CSS
and myValue in HTML, chances are things won’t work. For the record, I prefer
lowerCamelCase, but there’s no reason for choosing a particular case.
lowercase. In CSS, tag selectors should also be lowercase. However, user-defined id
and class values can be in whatever case the author chooses. Ultimately, decide
on a convention and stick to it—always. If you set a class value to myvalue in CSS
and myValue in HTML, chances are things won’t work. For the record, I prefer
lowerCamelCase, but there’s no reason for choosing a particular case.
Not closing elements, attributes, and rules: An unclosed element in HTML may
cause the remainder of the web page (or part of it) to not display correctly.
Similarly, not closing an HTML attribute makes all of the page’s content until the
next double quote part of the attribute. Not closing a CSS rule may cause part or
all of the style sheet to not work. Note that CSS pairs that aren’t terminated with a
semicolon may cause subsequent rules to partially or wholly fail. A good tip to
avoid accidentally not closing elements or rules is to add the end tag/closing
bracket immediately after adding the start tag/opening bracket. This also helps to
avoid incorrect nesting of elements.
Multiple rule sets: In CSS, ensure that if you use a selector more than once, any
overrides are intentional. It’s a common error for a designer to duplicate a rule set
and have different CSS property values conflicting in different areas of the CSS.
Errors with the head and body elements: As stated earlier in the book, HTML content
should not appear outside of the html element, and body content should not
appear outside of the body element. Common errors with these elements include
placing content between the closing head element tag (</head>) and the body start
tag (<body>), and including multiple html and body elements.
Inaccessible content: Here, we’re talking in a more general sense, rather than about
accessibility for screen reader users. If you create a site with scrollable areas,
ensure users can access the content within, even if browser settings aren’t at their
defaults. Problems mostly occur when overflow is set to hidden. Similarly,
textarea elements that don’t have properly marked-up cols and rows settings
will often be tiny when viewed without CSS (these attributes are functional as well
as presentational). The same is true for text input fields without a defined size
attribute.
Dead links: These can take on many forms, such as a link to another page being
dead, an image not showing up, or external documents not being accessible by the
web page. If a JavaScript function isn’t working for some reason, try checking to see
whether you’ve actually linked it—in some cases, the simpler and most obvious
errors are the ones that slip through the net. Also, if things aren’t working on a live
site, check the paths—you may have accidentally created a direct link to a file on
your local machine, which obviously won’t be accessible to the entire Internet.
Spaces within href values or the original file names can also be accidentally overlooked.
Whitespace errors: In CSS, do not place whitespace between class/id indicators and
the selector name, or between numerals and units for measurements. However, do
not omit whitespace from between contextual selectors, otherwise you’ll “combine”
them into a new, probably unknown, one.
Using multiple units: In CSS, a value can only accept a single unit—the likes of
50%px can cause a rule to partially or wholly fail.
Subscribe to:
Posts (Atom)