You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@hlmksw.com> on 2007/01/22 20:51:32 UTC
RFC: HTML/CSS Best Practices
The proposed HTML/CSS coding guidelines/best practices. My comments are in
brackets [] - they are not intended to be a part of the final version.
These guidelines are short and to the point. I could go into more detail, but
then that would be bordering on writing a book about web design. Instead, I took
the approach that the reader has already read books on HTML and CSS, and they
just need some basic guidelines.
Your comments and suggestions are welcome. Once everyone has commented, I will
post the final version on the Wiki.
---------------------------------
OFBiz HTML and CSS Best Practices
---------------------------------
--- Web Standards and Browser Compatibility ---
OFBiz HTML and CSS code should strive to conform to the latest W3C standards.
Browser-specific extensions should be avoided.
If a particular browser does not conform to the latest standards, then the
HTML/CSS code should strive to produce a usable web page with that browser. In
other words, OFBiz developers should not "dumb down" the user interface to
support a non-conforming browser, yet someone using a non-conforming browser
should still be able to use OFBiz.
[As Andy Clarke said, "For such a young and dynamic medium as the web, the
notion that designers should not push design boundaries forward because of only
one browser, even when that browser is the market leader, seems incompatible
with progress."]
--- HTML Guidelines ---
HTML should be well structured, concise, and free of styling information. Well
structured HTML is easily styled with style sheets (CSS) - therefore all styling
code should be kept in the style sheets.
[Brief "good" versus "bad" code example goes here.]
HTML tables should be used for rendering tabular data only - they should not be
used for general layout.
All HTML should pass validation.
--- CSS Guidelines ---
Style sheets should be concise and organized.
Class IDs are preferred over class names.
Build from the bottom up. Assign common properties to basic HTML elements first,
then embellish the elements with additional selectors (CSS inheritance).
Give the class names/selectors meaningful names that describe what they are
styling. Class names should be easily understood by non-technical people - such
as graphics artists. Class names should not imply positioning or styling.
Examples of improper class names: "topRightButton" "leftMenuBar" "boldRedText" -
those all imply position/style.
Recurring HTML element collections (navigation bars, button bars, screenlets)
should be styled as a whole - using contextual or descendant selectors.
Be consistent with property values. Use EMs for sizing - which allows the page
to be resized gracefully. Use the hex notation for colors - which allows a
graphic artist to search/replace colors.
[Brief "good" versus "bad" code example goes here.]
--- HTML/CSS Testing Guidelines ---
Don't make assumptions in your code. Don't assume everyone reads left-to-right.
Don't assume everyone can distinguish between subtle shades of gray. Don't
assume everyone uses their browser's default settings. Test your code on several
browsers, then change the browser's settings. Reverse the layout direction (CSS
direction: rtl;). Change the language. Resize the browser window - make it
really tiny. The page should make sense under any circumstance.
After you're satisfied that your HTML/CSS code will display correctly under any
circumstance, run the page through a validator to catch any errors.
Re: RFC: HTML/CSS Best Practices
Posted by Adrian Crum <ad...@hlmksw.com>.
David E. Jones wrote:
> Still, even if that statement was true we want the templates to be as
> easy to customize as possible so that creating a fancy site that works
> well across browsers is as easy as possible. It is perhaps best to
> think of this as a chance to collaborate, especially among those of us
> who do custom ecommerce sites. Actually that might be a little bit
> silly to say because that is true for all of OFBiz.
I was picturing getting the UI refactoring done in the back office apps first -
where there will be less of a browser compatibility issue. Then we could apply
some of the lessons learned there plus toss in some cross-browser hacks to get
the eCommerce component done. What do you think?
I agree that eCommerce should work well out of the box.
Re: RFC: HTML/CSS Best Practices
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Jan 23, 2007, at 12:47 PM, Jacques Le Roux wrote:
> It's ok to me, eCommerce is another beast ! But I guess we have not
> to worry much about it too because I guess nobody is really
> using OFBiz eCommerce component OOTB.
If only it were true!
Still, even if that statement was true we want the templates to be as
easy to customize as possible so that creating a fancy site that
works well across browsers is as easy as possible. It is perhaps best
to think of this as a chance to collaborate, especially among those
of us who do custom ecommerce sites. Actually that might be a little
bit silly to say because that is true for all of OFBiz.
-David
Re: RFC: HTML/CSS Best Practices
Posted by Jacques Le Roux <ja...@les7arts.com>.
Adrian
From: "Adrian Crum" <ad...@hlmksw.com>
> Jacques Le Roux wrote:
> > Adrian,
> >
> > IMO it may be possible to use only Firefox or even IE 7 for backend (and recommend them).
> >
> > Just a question I'm asking myself : could that have any implications in the future ?
> >
> > Jacques
>
> From what I've read, newer CSS standards should make layout easier, and I'm
> sure once those become available the OFBiz developers will take advantage of them.
Sure !
> Browsers seem to be doing a better job of following the standards with each new
> version. So overall I see things improving. The latest version of Firefox and IE
> do an excellent job of layout - everything behaves as it should, and there are
> few quirks.
> In other words, if we stick to the published standards, and the browsers do the
> same, then we shouldn't be too concerned about the future.
>
> In the process of working on the conversion from table-based layout to div-based
> layout, I discovered a HUGE difference in the way older browsers handle layout.
> At first I thought I would just put in a few hacks to support older browsers. I
> quickly discovered that there are many of them and getting all of them to render
> the same page decently is near impossible. I gave up on that attempt and settled
> on supporting the most recent ones (which would include IE 6). My thought was it
> would be easier to support fewer browsers. That's when I discovered that just
> getting IE 6 to render properly is a nightmare.
Yes that's explained Jeffrey Zeldman in his book. And why it was recommending continue to use table in such case. But we are not in
the same situation, specially for backend : we may indeed recommend 1 or 2 browsers and that's all.
> So, as far as the back office applications are concerned, I don't think it's
> unreasonable to code to the current standards and the browsers that conform to
> them. It's a waste of time to worry about any of the older browsers.
It's ok to me, eCommerce is another beast ! But I guess we have not to worry much about it too because I guess nobody is really
using OFBiz eCommerce component OOTB. So we may end up with the same conclusion : recommend 2 or 3 browsers (I guess Opera 9.02 is
doing a good job too). FDYT folks ?
Jacques
Re: RFC: HTML/CSS Best Practices
Posted by Adrian Crum <ad...@hlmksw.com>.
Jacques Le Roux wrote:
> Adrian,
>
> IMO it may be possible to use only Firefox or even IE 7 for backend (and recommend them).
>
> Just a question I'm asking myself : could that have any implications in the future ?
>
> Jacques
From what I've read, newer CSS standards should make layout easier, and I'm
sure once those become available the OFBiz developers will take advantage of them.
Browsers seem to be doing a better job of following the standards with each new
version. So overall I see things improving. The latest version of Firefox and IE
do an excellent job of layout - everything behaves as it should, and there are
few quirks.
In other words, if we stick to the published standards, and the browsers do the
same, then we shouldn't be too concerned about the future.
In the process of working on the conversion from table-based layout to div-based
layout, I discovered a HUGE difference in the way older browsers handle layout.
At first I thought I would just put in a few hacks to support older browsers. I
quickly discovered that there are many of them and getting all of them to render
the same page decently is near impossible. I gave up on that attempt and settled
on supporting the most recent ones (which would include IE 6). My thought was it
would be easier to support fewer browsers. That's when I discovered that just
getting IE 6 to render properly is a nightmare.
So, as far as the back office applications are concerned, I don't think it's
unreasonable to code to the current standards and the browsers that conform to
them. It's a waste of time to worry about any of the older browsers.
Re: RFC: HTML/CSS Best Practices
Posted by Jacques Le Roux <ja...@les7arts.com>.
Adrian,
IMO it may be possible to use only Firefox or even IE 7 for backend (and recommend them).
Just a question I'm asking myself : could that have any implications in the future ?
Jacques
----- Original Message -----
From: "Adrian Crum" <ad...@hlmksw.com>
To: <de...@ofbiz.apache.org>
Sent: Tuesday, January 23, 2007 4:57 PM
Subject: Re: RFC: HTML/CSS Best Practices
> David,
>
> Thank you very much for your comments! You brought up some very good points.
> They are helpful.
>
> I've been using the Party Manager application as a testbed for the new layout
> methods and it all works very well with Firefox and IE 7. IE 6 has a lot of
> problems with DIV based layout, and Mozilla displays well but looks slightly
> different. I started researching how to fix the IE 6 layout issues and got
> overwhelmed.
>
> Bottom line is, if the development community is okay with requiring users to use
> Firefox or IE 7 for the back office apps, then that takes a load off my mind and
> it will make the UI refactoring move a lot faster.
>
> Re: eCommerce - I agree that it requires a unique set of guidelines because it
> is public facing. I've never used eCommerce, so I'll have to rely upon the
> community's suggestions on guidelines for that.
>
> Another unique set of guidelines that comes to mind is designing the UI for
> handheld devices. I guess we'll cross that bridge when we get to it.
>
>
> David E. Jones wrote:
> >
> > My first thought is that 2 parts of this seem to contradict each other,
> > namely the first section (Web Standards and Browser Compatibility) and
> > the last section (HTML/CSS Testing Guidelines).
> >
> > The de-facto standard so far (not perfectly applied, BTW) has been
> > split into 2 parts:
> >
> > 1. the internal applications (all of the managers): work well in
> > standards compliant browsers (test with something like Firefox at
> > least), don't worry too much about IE
> >
> > 2. the public/customer facing application (really just ecommerce right
> > now): things here should be initially developed to be standards
> > compliant and work in standards compliant browsers; however for these
> > we can't stop there as the fact is much of the consuming public uses IE
> > and it is necessary to create sites that work well in IE; this doesn't
> > have to break the standards compliant stuff, but sometimes requires
> > browser-specific variations in order to work well in the needed browsers
> >
> > -David
> >
> >
> > On Jan 22, 2007, at 12:51 PM, Adrian Crum wrote:
> >
> >> The proposed HTML/CSS coding guidelines/best practices. My comments
> >> are in brackets [] - they are not intended to be a part of the final
> >> version.
> >>
> >> These guidelines are short and to the point. I could go into more
> >> detail, but then that would be bordering on writing a book about web
> >> design. Instead, I took the approach that the reader has already read
> >> books on HTML and CSS, and they just need some basic guidelines.
> >>
> >> Your comments and suggestions are welcome. Once everyone has
> >> commented, I will post the final version on the Wiki.
> >>
> >> ---------------------------------
> >> OFBiz HTML and CSS Best Practices
> >> ---------------------------------
> >>
> >> --- Web Standards and Browser Compatibility ---
> >>
> >> OFBiz HTML and CSS code should strive to conform to the latest W3C
> >> standards. Browser-specific extensions should be avoided.
> >>
> >> If a particular browser does not conform to the latest standards,
> >> then the HTML/CSS code should strive to produce a usable web page
> >> with that browser. In other words, OFBiz developers should not "dumb
> >> down" the user interface to support a non-conforming browser, yet
> >> someone using a non-conforming browser should still be able to use
> >> OFBiz.
> >>
> >> [As Andy Clarke said, "For such a young and dynamic medium as the
> >> web, the notion that designers should not push design boundaries
> >> forward because of only one browser, even when that browser is the
> >> market leader, seems incompatible with progress."]
> >>
> >> --- HTML Guidelines ---
> >>
> >> HTML should be well structured, concise, and free of styling
> >> information. Well structured HTML is easily styled with style sheets
> >> (CSS) - therefore all styling code should be kept in the style sheets.
> >>
> >> [Brief "good" versus "bad" code example goes here.]
> >>
> >> HTML tables should be used for rendering tabular data only - they
> >> should not be used for general layout.
> >>
> >> All HTML should pass validation.
> >>
> >> --- CSS Guidelines ---
> >>
> >> Style sheets should be concise and organized.
> >>
> >> Class IDs are preferred over class names.
> >>
> >> Build from the bottom up. Assign common properties to basic HTML
> >> elements first, then embellish the elements with additional selectors
> >> (CSS inheritance).
> >>
> >> Give the class names/selectors meaningful names that describe what
> >> they are styling. Class names should be easily understood by non-
> >> technical people - such as graphics artists. Class names should not
> >> imply positioning or styling. Examples of improper class names:
> >> "topRightButton" "leftMenuBar" "boldRedText" - those all imply
> >> position/style.
> >>
> >> Recurring HTML element collections (navigation bars, button bars,
> >> screenlets) should be styled as a whole - using contextual or
> >> descendant selectors.
> >>
> >> Be consistent with property values. Use EMs for sizing - which allows
> >> the page to be resized gracefully. Use the hex notation for colors -
> >> which allows a graphic artist to search/replace colors.
> >>
> >> [Brief "good" versus "bad" code example goes here.]
> >>
> >> --- HTML/CSS Testing Guidelines ---
> >>
> >> Don't make assumptions in your code. Don't assume everyone reads
> >> left-to-right. Don't assume everyone can distinguish between subtle
> >> shades of gray. Don't assume everyone uses their browser's default
> >> settings. Test your code on several browsers, then change the
> >> browser's settings. Reverse the layout direction (CSS direction:
> >> rtl;). Change the language. Resize the browser window - make it
> >> really tiny. The page should make sense under any circumstance.
> >>
> >> After you're satisfied that your HTML/CSS code will display correctly
> >> under any circumstance, run the page through a validator to catch any
> >> errors.
> >>
> >
Re: RFC: HTML/CSS Best Practices
Posted by Adrian Crum <ad...@hlmksw.com>.
David,
Thank you very much for your comments! You brought up some very good points.
They are helpful.
I've been using the Party Manager application as a testbed for the new layout
methods and it all works very well with Firefox and IE 7. IE 6 has a lot of
problems with DIV based layout, and Mozilla displays well but looks slightly
different. I started researching how to fix the IE 6 layout issues and got
overwhelmed.
Bottom line is, if the development community is okay with requiring users to use
Firefox or IE 7 for the back office apps, then that takes a load off my mind and
it will make the UI refactoring move a lot faster.
Re: eCommerce - I agree that it requires a unique set of guidelines because it
is public facing. I've never used eCommerce, so I'll have to rely upon the
community's suggestions on guidelines for that.
Another unique set of guidelines that comes to mind is designing the UI for
handheld devices. I guess we'll cross that bridge when we get to it.
David E. Jones wrote:
>
> My first thought is that 2 parts of this seem to contradict each other,
> namely the first section (Web Standards and Browser Compatibility) and
> the last section (HTML/CSS Testing Guidelines).
>
> The de-facto standard so far (not perfectly applied, BTW) has been
> split into 2 parts:
>
> 1. the internal applications (all of the managers): work well in
> standards compliant browsers (test with something like Firefox at
> least), don't worry too much about IE
>
> 2. the public/customer facing application (really just ecommerce right
> now): things here should be initially developed to be standards
> compliant and work in standards compliant browsers; however for these
> we can't stop there as the fact is much of the consuming public uses IE
> and it is necessary to create sites that work well in IE; this doesn't
> have to break the standards compliant stuff, but sometimes requires
> browser-specific variations in order to work well in the needed browsers
>
> -David
>
>
> On Jan 22, 2007, at 12:51 PM, Adrian Crum wrote:
>
>> The proposed HTML/CSS coding guidelines/best practices. My comments
>> are in brackets [] - they are not intended to be a part of the final
>> version.
>>
>> These guidelines are short and to the point. I could go into more
>> detail, but then that would be bordering on writing a book about web
>> design. Instead, I took the approach that the reader has already read
>> books on HTML and CSS, and they just need some basic guidelines.
>>
>> Your comments and suggestions are welcome. Once everyone has
>> commented, I will post the final version on the Wiki.
>>
>> ---------------------------------
>> OFBiz HTML and CSS Best Practices
>> ---------------------------------
>>
>> --- Web Standards and Browser Compatibility ---
>>
>> OFBiz HTML and CSS code should strive to conform to the latest W3C
>> standards. Browser-specific extensions should be avoided.
>>
>> If a particular browser does not conform to the latest standards,
>> then the HTML/CSS code should strive to produce a usable web page
>> with that browser. In other words, OFBiz developers should not "dumb
>> down" the user interface to support a non-conforming browser, yet
>> someone using a non-conforming browser should still be able to use
>> OFBiz.
>>
>> [As Andy Clarke said, "For such a young and dynamic medium as the
>> web, the notion that designers should not push design boundaries
>> forward because of only one browser, even when that browser is the
>> market leader, seems incompatible with progress."]
>>
>> --- HTML Guidelines ---
>>
>> HTML should be well structured, concise, and free of styling
>> information. Well structured HTML is easily styled with style sheets
>> (CSS) - therefore all styling code should be kept in the style sheets.
>>
>> [Brief "good" versus "bad" code example goes here.]
>>
>> HTML tables should be used for rendering tabular data only - they
>> should not be used for general layout.
>>
>> All HTML should pass validation.
>>
>> --- CSS Guidelines ---
>>
>> Style sheets should be concise and organized.
>>
>> Class IDs are preferred over class names.
>>
>> Build from the bottom up. Assign common properties to basic HTML
>> elements first, then embellish the elements with additional selectors
>> (CSS inheritance).
>>
>> Give the class names/selectors meaningful names that describe what
>> they are styling. Class names should be easily understood by non-
>> technical people - such as graphics artists. Class names should not
>> imply positioning or styling. Examples of improper class names:
>> "topRightButton" "leftMenuBar" "boldRedText" - those all imply
>> position/style.
>>
>> Recurring HTML element collections (navigation bars, button bars,
>> screenlets) should be styled as a whole - using contextual or
>> descendant selectors.
>>
>> Be consistent with property values. Use EMs for sizing - which allows
>> the page to be resized gracefully. Use the hex notation for colors -
>> which allows a graphic artist to search/replace colors.
>>
>> [Brief "good" versus "bad" code example goes here.]
>>
>> --- HTML/CSS Testing Guidelines ---
>>
>> Don't make assumptions in your code. Don't assume everyone reads
>> left-to-right. Don't assume everyone can distinguish between subtle
>> shades of gray. Don't assume everyone uses their browser's default
>> settings. Test your code on several browsers, then change the
>> browser's settings. Reverse the layout direction (CSS direction:
>> rtl;). Change the language. Resize the browser window - make it
>> really tiny. The page should make sense under any circumstance.
>>
>> After you're satisfied that your HTML/CSS code will display correctly
>> under any circumstance, run the page through a validator to catch any
>> errors.
>>
>
Re: RFC: HTML/CSS Best Practices
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
My first thought is that 2 parts of this seem to contradict each
other, namely the first section (Web Standards and Browser
Compatibility) and the last section (HTML/CSS Testing Guidelines).
The de-facto standard so far (not perfectly applied, BTW) has been
split into 2 parts:
1. the internal applications (all of the managers): work well in
standards compliant browsers (test with something like Firefox at
least), don't worry too much about IE
2. the public/customer facing application (really just ecommerce
right now): things here should be initially developed to be standards
compliant and work in standards compliant browsers; however for these
we can't stop there as the fact is much of the consuming public uses
IE and it is necessary to create sites that work well in IE; this
doesn't have to break the standards compliant stuff, but sometimes
requires browser-specific variations in order to work well in the
needed browsers
-David
On Jan 22, 2007, at 12:51 PM, Adrian Crum wrote:
> The proposed HTML/CSS coding guidelines/best practices. My comments
> are in brackets [] - they are not intended to be a part of the
> final version.
>
> These guidelines are short and to the point. I could go into more
> detail, but then that would be bordering on writing a book about
> web design. Instead, I took the approach that the reader has
> already read books on HTML and CSS, and they just need some basic
> guidelines.
>
> Your comments and suggestions are welcome. Once everyone has
> commented, I will post the final version on the Wiki.
>
> ---------------------------------
> OFBiz HTML and CSS Best Practices
> ---------------------------------
>
> --- Web Standards and Browser Compatibility ---
>
> OFBiz HTML and CSS code should strive to conform to the latest W3C
> standards. Browser-specific extensions should be avoided.
>
> If a particular browser does not conform to the latest standards,
> then the HTML/CSS code should strive to produce a usable web page
> with that browser. In other words, OFBiz developers should not
> "dumb down" the user interface to support a non-conforming browser,
> yet someone using a non-conforming browser should still be able to
> use OFBiz.
>
> [As Andy Clarke said, "For such a young and dynamic medium as the
> web, the notion that designers should not push design boundaries
> forward because of only one browser, even when that browser is the
> market leader, seems incompatible with progress."]
>
> --- HTML Guidelines ---
>
> HTML should be well structured, concise, and free of styling
> information. Well structured HTML is easily styled with style
> sheets (CSS) - therefore all styling code should be kept in the
> style sheets.
>
> [Brief "good" versus "bad" code example goes here.]
>
> HTML tables should be used for rendering tabular data only - they
> should not be used for general layout.
>
> All HTML should pass validation.
>
> --- CSS Guidelines ---
>
> Style sheets should be concise and organized.
>
> Class IDs are preferred over class names.
>
> Build from the bottom up. Assign common properties to basic HTML
> elements first, then embellish the elements with additional
> selectors (CSS inheritance).
>
> Give the class names/selectors meaningful names that describe what
> they are styling. Class names should be easily understood by non-
> technical people - such as graphics artists. Class names should not
> imply positioning or styling. Examples of improper class names:
> "topRightButton" "leftMenuBar" "boldRedText" - those all imply
> position/style.
>
> Recurring HTML element collections (navigation bars, button bars,
> screenlets) should be styled as a whole - using contextual or
> descendant selectors.
>
> Be consistent with property values. Use EMs for sizing - which
> allows the page to be resized gracefully. Use the hex notation for
> colors - which allows a graphic artist to search/replace colors.
>
> [Brief "good" versus "bad" code example goes here.]
>
> --- HTML/CSS Testing Guidelines ---
>
> Don't make assumptions in your code. Don't assume everyone reads
> left-to-right. Don't assume everyone can distinguish between subtle
> shades of gray. Don't assume everyone uses their browser's default
> settings. Test your code on several browsers, then change the
> browser's settings. Reverse the layout direction (CSS direction:
> rtl;). Change the language. Resize the browser window - make it
> really tiny. The page should make sense under any circumstance.
>
> After you're satisfied that your HTML/CSS code will display
> correctly under any circumstance, run the page through a validator
> to catch any errors.
>
Re: HTML/CSS Best Practices
Posted by Adrian Crum <ad...@hlmksw.com>.
Thanks Chris!
As David mentioned, there are actually two sets of guidelines needed for OFBiz -
one set for back office apps and another for the eCommerce component.
I think I got this guidelines effort off to a bad start by not being more
specific. The EM guideline would be acceptable for the back office apps, but
maybe not for eCommerce.
Chris Howe wrote:
> Hey Jacques,
>
> Thanks for that excerpt. In reading that did you find any discussion
> on the
> BODY{
> font-size:62.5%;
> }
> trick?
>
> This dampens much of the default font size extremes (though doesn't
> completely eliminate it). This sets the default size of the page to
> the following depending on the user's settings:
>
> Default|Result
> 16px | 10px
> 14px | 8.75px
> 12px | 7.5px
> 10px | 6.25px
>
> Notice it's only decreasing font-size by 1.25 px per 2 px step.
>
> --- Jacques Le Roux <ja...@les7arts.com> wrote:
>
>
>>Adrian, all,
>>
>>I do not agree on em being best practise let me explain why with this
>>extract from chapter 13 of Jeffrey Zeldman's "Designing With
>>Web Standards" (as I said before it's a little verbose):
>>
>>
>
> ==============================================================================
>
>>The Heartbreak of Ems
>>Accessibility advocates and the creators of CSS have long agreed that
>>ems are the way to go. Sadly, they are often the way to go to
>>hell. Listen to all the lectures, read all the books and articles,
>>and you will come away feeling dirty and ashamed if you use
>>anything other than ems to specify your type sizes. But the beautiful
>>theory of ems breaks down in coarse practice and not only in
>>browsers that fail to support the common default font size.
>>
>>On a minor note, there is the problem of old browsers. Netscape 4
>>ignores em and ex units that are applied to text, although it
>>bizarrely respects these units when they are used for line height.
>>IE3 treats em units as pixels. Thus, 2em is mistranslated as 2
>>pixels tall. Almost no one uses IE3 any more, but still.
>>
>>Likewise, older browsers often bungle inheritance on nested elements
>>sized with em units. Because fewer and fewer people are stuck
>>with Netscape 4, we won't waste your time going into the details of
>>that browser's mishandling of relatively sized nested elements.
>>Just know that if you need to support outdated browsers and if you
>>use em units (especially on nested elements), you are letting
>>yourself and your users in for a world of pain [13.11].
>>
>>13.11. What's in an em? Not cross-platform, cross-browser size
>>consistency, that's for sure
>>(http://www.thenoodleincident.com/tutorials/box_lesson/font/).
>>
>>
>>User Choices and Em Units
>>A more common problem with em units is that users often downsize
>>their default font size settings as noted several times in this
>>chapter. Mac users switch back to 12px/72ppi; Windows folks set their
>>browsers' View: Text Size menu to "small" rather than
>>"medium." Such changes make any text sized below 1em smaller than it
>>is supposed to be and might make it too small to be read. In
>>2002, CSS/DHTML expert Owen Briggs tested every available text sizing
>>method across a vast range of browsers and platforms to find
>>out what worked and what failed. 264 screen shots later, despite
>>hoping to prove that ems were always viable, he had actually
>>discovered the opposite [13.11].
>>
>>Ems work well as long as you never spec your text below the user's
>>default size. Ems work well as long as users never adjust their
>>preferences. But most designers and many clients favor smaller type
>>and many designs require them. Many users consider the 16px
>>default size uncomfortable for normal reading and change their
>>preference settings accordingly. When em units are used to design
>>sites, the designer's and user's shrinkage efforts compound on one
>>another, resulting in text that might be hard to read or even
>>entirely illegible.
>>
>>When you set small type with em units (or percentages), you run afoul
>>of a universe of unknowable, uncontrollable user preference
>>settings. What looks elegant on your monitor might be mouse type on
>>your users'. If you commit this act in the name of
>>accessibility, you're kidding yourself.
>>
>>In the i3Forum site, we tried to minimize the potential damage by
>>sticking to sizes that were only slightly smaller than 1em. But
>>the user's mileage might vary.
>>
>>Alternatively (http://www.alistapart.com/stories/dao/), client and
>>aesthetics permitting, you can design all your sites using only
>>normal or oversized type set with em units. This will avoid
>>size-based accessibility problems. But very few designs work with a
>>default size of 16px and higherand some users will complain that your
>>site is ugly because the text is "too big." If the moral seems
>>to be that you can't please everybody, the additional moral is that
>>you are even less likely to please everybody when you use em
>>units to specify your text size.
>>
>>Some standards evangelists and some accessibility advocates will
>>choose to disbelieve what we've said, just as some people choose to
>>believe that the 1969 moon landing was a hoax. Was it T.S. Eliot or
>>Woody Allen who said, "Too much reality is not what the people
>>want."? Whoever said it first, he was right.
>>
>>So what do the people want? They might want the two methods described
>>in the remainder of this chapter, which seem to work better
>>than any we have considered so far, although even the methods we are
>>about to discuss have their problems.
>>
>
> ==============================================================================
>
>>The 2 methods he advocates are "Pixels Prove Pixels Work" and "The
>>Font Size Keyword Method" (Fahrner's Method). If you are
>>interested by those I may put a link on my site for this stuffes
>>(perhaps I should have better do that for extract above also)
>>
>>Jacques
>>
>>
>>----- Original Message -----
>>From: "Adrian Crum" <ad...@hlmksw.com>
>>To: <de...@ofbiz.apache.org>
>>Sent: Monday, January 22, 2007 8:51 PM
>>Subject: RFC: HTML/CSS Best Practices
>>
>>
>>
>>>The proposed HTML/CSS coding guidelines/best practices. My comments
>>
>>are in
>>
>>>brackets [] - they are not intended to be a part of the final
>>
>>version.
>>
>>>These guidelines are short and to the point. I could go into more
>>
>>detail, but
>>
>>>then that would be bordering on writing a book about web design.
>>
>>Instead, I took
>>
>>>the approach that the reader has already read books on HTML and
>>
>>CSS, and they
>>
>>>just need some basic guidelines.
>>>
>>>Your comments and suggestions are welcome. Once everyone has
>>
>>commented, I will
>>
>>>post the final version on the Wiki.
>>>
>>>---------------------------------
>>>OFBiz HTML and CSS Best Practices
>>>---------------------------------
>>>
>>>--- Web Standards and Browser Compatibility ---
>>>
>>>OFBiz HTML and CSS code should strive to conform to the latest W3C
>>
>>standards.
>>
>>>Browser-specific extensions should be avoided.
>>>
>>>If a particular browser does not conform to the latest standards,
>>
>>then the
>>
>>>HTML/CSS code should strive to produce a usable web page with that
>>
>>browser. In
>>
>>>other words, OFBiz developers should not "dumb down" the user
>>
>>interface to
>>
>>>support a non-conforming browser, yet someone using a
>>
>>non-conforming browser
>>
>>>should still be able to use OFBiz.
>>>
>>>[As Andy Clarke said, "For such a young and dynamic medium as the
>>
>>web, the
>>
>>>notion that designers should not push design boundaries forward
>>
>>because of only
>>
>>>one browser, even when that browser is the market leader, seems
>>
>>incompatible
>>
>>>with progress."]
>>>
>>>--- HTML Guidelines ---
>>>
>>>HTML should be well structured, concise, and free of styling
>>
>>information. Well
>>
>>>structured HTML is easily styled with style sheets (CSS) -
>>
>>therefore all styling
>>
>>>code should be kept in the style sheets.
>>>
>>>[Brief "good" versus "bad" code example goes here.]
>>>
>>>HTML tables should be used for rendering tabular data only - they
>>
>>should not be
>>
>>>used for general layout.
>>>
>>>All HTML should pass validation.
>>>
>>>--- CSS Guidelines ---
>>>
>>>Style sheets should be concise and organized.
>>>
>>>Class IDs are preferred over class names.
>>>
>>>Build from the bottom up. Assign common properties to basic HTML
>>
>>elements first,
>>
>>>then embellish the elements with additional selectors (CSS
>>
>>inheritance).
>>
>>>Give the class names/selectors meaningful names that describe what
>>
>>they are
>>
>>>styling. Class names should be easily understood by non-technical
>>
>>people - such
>>
>>>as graphics artists. Class names should not imply positioning or
>>
>>styling.
>>
>>>Examples of improper class names: "topRightButton" "leftMenuBar"
>>
>>"boldRedText" -
>>
>>>those all imply position/style.
>>>
>>>Recurring HTML element collections (navigation bars, button bars,
>>
>>screenlets)
>>
>>>should be styled as a whole - using contextual or descendant
>>
>>selectors.
>>
>>>Be consistent with property values. Use EMs for sizing - which
>>
>>allows the page
>>
>>>to be resized gracefully. Use the hex notation for colors - which
>>
>>allows a
>>
>>>graphic artist to search/replace colors.
>>>
>>>[Brief "good" versus "bad" code example goes here.]
>>>
>>>--- HTML/CSS Testing Guidelines ---
>>
> === message truncated ===
>
>
Re: HTML/CSS Best Practices
Posted by Chris Howe <cj...@yahoo.com>.
Hey Jacques,
Thanks for that excerpt. In reading that did you find any discussion
on the
BODY{
font-size:62.5%;
}
trick?
This dampens much of the default font size extremes (though doesn't
completely eliminate it). This sets the default size of the page to
the following depending on the user's settings:
Default|Result
16px | 10px
14px | 8.75px
12px | 7.5px
10px | 6.25px
Notice it's only decreasing font-size by 1.25 px per 2 px step.
--- Jacques Le Roux <ja...@les7arts.com> wrote:
> Adrian, all,
>
> I do not agree on em being best practise let me explain why with this
> extract from chapter 13 of Jeffrey Zeldman's "Designing With
> Web Standards" (as I said before it's a little verbose):
>
>
==============================================================================
> The Heartbreak of Ems
> Accessibility advocates and the creators of CSS have long agreed that
> ems are the way to go. Sadly, they are often the way to go to
> hell. Listen to all the lectures, read all the books and articles,
> and you will come away feeling dirty and ashamed if you use
> anything other than ems to specify your type sizes. But the beautiful
> theory of ems breaks down in coarse practice and not only in
> browsers that fail to support the common default font size.
>
> On a minor note, there is the problem of old browsers. Netscape 4
> ignores em and ex units that are applied to text, although it
> bizarrely respects these units when they are used for line height.
> IE3 treats em units as pixels. Thus, 2em is mistranslated as 2
> pixels tall. Almost no one uses IE3 any more, but still.
>
> Likewise, older browsers often bungle inheritance on nested elements
> sized with em units. Because fewer and fewer people are stuck
> with Netscape 4, we won't waste your time going into the details of
> that browser's mishandling of relatively sized nested elements.
> Just know that if you need to support outdated browsers and if you
> use em units (especially on nested elements), you are letting
> yourself and your users in for a world of pain [13.11].
>
> 13.11. What's in an em? Not cross-platform, cross-browser size
> consistency, that's for sure
> (http://www.thenoodleincident.com/tutorials/box_lesson/font/).
>
>
> User Choices and Em Units
> A more common problem with em units is that users often downsize
> their default font size settings as noted several times in this
> chapter. Mac users switch back to 12px/72ppi; Windows folks set their
> browsers' View: Text Size menu to "small" rather than
> "medium." Such changes make any text sized below 1em smaller than it
> is supposed to be and might make it too small to be read. In
> 2002, CSS/DHTML expert Owen Briggs tested every available text sizing
> method across a vast range of browsers and platforms to find
> out what worked and what failed. 264 screen shots later, despite
> hoping to prove that ems were always viable, he had actually
> discovered the opposite [13.11].
>
> Ems work well as long as you never spec your text below the user's
> default size. Ems work well as long as users never adjust their
> preferences. But most designers and many clients favor smaller type
> and many designs require them. Many users consider the 16px
> default size uncomfortable for normal reading and change their
> preference settings accordingly. When em units are used to design
> sites, the designer's and user's shrinkage efforts compound on one
> another, resulting in text that might be hard to read or even
> entirely illegible.
>
> When you set small type with em units (or percentages), you run afoul
> of a universe of unknowable, uncontrollable user preference
> settings. What looks elegant on your monitor might be mouse type on
> your users'. If you commit this act in the name of
> accessibility, you're kidding yourself.
>
> In the i3Forum site, we tried to minimize the potential damage by
> sticking to sizes that were only slightly smaller than 1em. But
> the user's mileage might vary.
>
> Alternatively (http://www.alistapart.com/stories/dao/), client and
> aesthetics permitting, you can design all your sites using only
> normal or oversized type set with em units. This will avoid
> size-based accessibility problems. But very few designs work with a
> default size of 16px and higherand some users will complain that your
> site is ugly because the text is "too big." If the moral seems
> to be that you can't please everybody, the additional moral is that
> you are even less likely to please everybody when you use em
> units to specify your text size.
>
> Some standards evangelists and some accessibility advocates will
> choose to disbelieve what we've said, just as some people choose to
> believe that the 1969 moon landing was a hoax. Was it T.S. Eliot or
> Woody Allen who said, "Too much reality is not what the people
> want."? Whoever said it first, he was right.
>
> So what do the people want? They might want the two methods described
> in the remainder of this chapter, which seem to work better
> than any we have considered so far, although even the methods we are
> about to discuss have their problems.
>
==============================================================================
>
> The 2 methods he advocates are "Pixels Prove Pixels Work" and "The
> Font Size Keyword Method" (Fahrner's Method). If you are
> interested by those I may put a link on my site for this stuffes
> (perhaps I should have better do that for extract above also)
>
> Jacques
>
>
> ----- Original Message -----
> From: "Adrian Crum" <ad...@hlmksw.com>
> To: <de...@ofbiz.apache.org>
> Sent: Monday, January 22, 2007 8:51 PM
> Subject: RFC: HTML/CSS Best Practices
>
>
> > The proposed HTML/CSS coding guidelines/best practices. My comments
> are in
> > brackets [] - they are not intended to be a part of the final
> version.
> >
> > These guidelines are short and to the point. I could go into more
> detail, but
> > then that would be bordering on writing a book about web design.
> Instead, I took
> > the approach that the reader has already read books on HTML and
> CSS, and they
> > just need some basic guidelines.
> >
> > Your comments and suggestions are welcome. Once everyone has
> commented, I will
> > post the final version on the Wiki.
> >
> > ---------------------------------
> > OFBiz HTML and CSS Best Practices
> > ---------------------------------
> >
> > --- Web Standards and Browser Compatibility ---
> >
> > OFBiz HTML and CSS code should strive to conform to the latest W3C
> standards.
> > Browser-specific extensions should be avoided.
> >
> > If a particular browser does not conform to the latest standards,
> then the
> > HTML/CSS code should strive to produce a usable web page with that
> browser. In
> > other words, OFBiz developers should not "dumb down" the user
> interface to
> > support a non-conforming browser, yet someone using a
> non-conforming browser
> > should still be able to use OFBiz.
> >
> > [As Andy Clarke said, "For such a young and dynamic medium as the
> web, the
> > notion that designers should not push design boundaries forward
> because of only
> > one browser, even when that browser is the market leader, seems
> incompatible
> > with progress."]
> >
> > --- HTML Guidelines ---
> >
> > HTML should be well structured, concise, and free of styling
> information. Well
> > structured HTML is easily styled with style sheets (CSS) -
> therefore all styling
> > code should be kept in the style sheets.
> >
> > [Brief "good" versus "bad" code example goes here.]
> >
> > HTML tables should be used for rendering tabular data only - they
> should not be
> > used for general layout.
> >
> > All HTML should pass validation.
> >
> > --- CSS Guidelines ---
> >
> > Style sheets should be concise and organized.
> >
> > Class IDs are preferred over class names.
> >
> > Build from the bottom up. Assign common properties to basic HTML
> elements first,
> > then embellish the elements with additional selectors (CSS
> inheritance).
> >
> > Give the class names/selectors meaningful names that describe what
> they are
> > styling. Class names should be easily understood by non-technical
> people - such
> > as graphics artists. Class names should not imply positioning or
> styling.
> > Examples of improper class names: "topRightButton" "leftMenuBar"
> "boldRedText" -
> > those all imply position/style.
> >
> > Recurring HTML element collections (navigation bars, button bars,
> screenlets)
> > should be styled as a whole - using contextual or descendant
> selectors.
> >
> > Be consistent with property values. Use EMs for sizing - which
> allows the page
> > to be resized gracefully. Use the hex notation for colors - which
> allows a
> > graphic artist to search/replace colors.
> >
> > [Brief "good" versus "bad" code example goes here.]
> >
> > --- HTML/CSS Testing Guidelines ---
>
=== message truncated ===
Re: HTML/CSS Best Practices
Posted by Jacques Le Roux <ja...@les7arts.com>.
Adrian, all,
I do not agree on em being best practise let me explain why with this extract from chapter 13 of Jeffrey Zeldman's "Designing With
Web Standards" (as I said before it's a little verbose):
==============================================================================
The Heartbreak of Ems
Accessibility advocates and the creators of CSS have long agreed that ems are the way to go. Sadly, they are often the way to go to
hell. Listen to all the lectures, read all the books and articles, and you will come away feeling dirty and ashamed if you use
anything other than ems to specify your type sizes. But the beautiful theory of ems breaks down in coarse practice and not only in
browsers that fail to support the common default font size.
On a minor note, there is the problem of old browsers. Netscape 4 ignores em and ex units that are applied to text, although it
bizarrely respects these units when they are used for line height. IE3 treats em units as pixels. Thus, 2em is mistranslated as 2
pixels tall. Almost no one uses IE3 any more, but still.
Likewise, older browsers often bungle inheritance on nested elements sized with em units. Because fewer and fewer people are stuck
with Netscape 4, we won't waste your time going into the details of that browser's mishandling of relatively sized nested elements.
Just know that if you need to support outdated browsers and if you use em units (especially on nested elements), you are letting
yourself and your users in for a world of pain [13.11].
13.11. What's in an em? Not cross-platform, cross-browser size consistency, that's for sure
(http://www.thenoodleincident.com/tutorials/box_lesson/font/).
User Choices and Em Units
A more common problem with em units is that users often downsize their default font size settings as noted several times in this
chapter. Mac users switch back to 12px/72ppi; Windows folks set their browsers' View: Text Size menu to "small" rather than
"medium." Such changes make any text sized below 1em smaller than it is supposed to be and might make it too small to be read. In
2002, CSS/DHTML expert Owen Briggs tested every available text sizing method across a vast range of browsers and platforms to find
out what worked and what failed. 264 screen shots later, despite hoping to prove that ems were always viable, he had actually
discovered the opposite [13.11].
Ems work well as long as you never spec your text below the user's default size. Ems work well as long as users never adjust their
preferences. But most designers and many clients favor smaller type and many designs require them. Many users consider the 16px
default size uncomfortable for normal reading and change their preference settings accordingly. When em units are used to design
sites, the designer's and user's shrinkage efforts compound on one another, resulting in text that might be hard to read or even
entirely illegible.
When you set small type with em units (or percentages), you run afoul of a universe of unknowable, uncontrollable user preference
settings. What looks elegant on your monitor might be mouse type on your users'. If you commit this act in the name of
accessibility, you're kidding yourself.
In the i3Forum site, we tried to minimize the potential damage by sticking to sizes that were only slightly smaller than 1em. But
the user's mileage might vary.
Alternatively (http://www.alistapart.com/stories/dao/), client and aesthetics permitting, you can design all your sites using only
normal or oversized type set with em units. This will avoid size-based accessibility problems. But very few designs work with a
default size of 16px and higherand some users will complain that your site is ugly because the text is "too big." If the moral seems
to be that you can't please everybody, the additional moral is that you are even less likely to please everybody when you use em
units to specify your text size.
Some standards evangelists and some accessibility advocates will choose to disbelieve what we've said, just as some people choose to
believe that the 1969 moon landing was a hoax. Was it T.S. Eliot or Woody Allen who said, "Too much reality is not what the people
want."? Whoever said it first, he was right.
So what do the people want? They might want the two methods described in the remainder of this chapter, which seem to work better
than any we have considered so far, although even the methods we are about to discuss have their problems.
==============================================================================
The 2 methods he advocates are "Pixels Prove Pixels Work" and "The Font Size Keyword Method" (Fahrner's Method). If you are
interested by those I may put a link on my site for this stuffes (perhaps I should have better do that for extract above also)
Jacques
----- Original Message -----
From: "Adrian Crum" <ad...@hlmksw.com>
To: <de...@ofbiz.apache.org>
Sent: Monday, January 22, 2007 8:51 PM
Subject: RFC: HTML/CSS Best Practices
> The proposed HTML/CSS coding guidelines/best practices. My comments are in
> brackets [] - they are not intended to be a part of the final version.
>
> These guidelines are short and to the point. I could go into more detail, but
> then that would be bordering on writing a book about web design. Instead, I took
> the approach that the reader has already read books on HTML and CSS, and they
> just need some basic guidelines.
>
> Your comments and suggestions are welcome. Once everyone has commented, I will
> post the final version on the Wiki.
>
> ---------------------------------
> OFBiz HTML and CSS Best Practices
> ---------------------------------
>
> --- Web Standards and Browser Compatibility ---
>
> OFBiz HTML and CSS code should strive to conform to the latest W3C standards.
> Browser-specific extensions should be avoided.
>
> If a particular browser does not conform to the latest standards, then the
> HTML/CSS code should strive to produce a usable web page with that browser. In
> other words, OFBiz developers should not "dumb down" the user interface to
> support a non-conforming browser, yet someone using a non-conforming browser
> should still be able to use OFBiz.
>
> [As Andy Clarke said, "For such a young and dynamic medium as the web, the
> notion that designers should not push design boundaries forward because of only
> one browser, even when that browser is the market leader, seems incompatible
> with progress."]
>
> --- HTML Guidelines ---
>
> HTML should be well structured, concise, and free of styling information. Well
> structured HTML is easily styled with style sheets (CSS) - therefore all styling
> code should be kept in the style sheets.
>
> [Brief "good" versus "bad" code example goes here.]
>
> HTML tables should be used for rendering tabular data only - they should not be
> used for general layout.
>
> All HTML should pass validation.
>
> --- CSS Guidelines ---
>
> Style sheets should be concise and organized.
>
> Class IDs are preferred over class names.
>
> Build from the bottom up. Assign common properties to basic HTML elements first,
> then embellish the elements with additional selectors (CSS inheritance).
>
> Give the class names/selectors meaningful names that describe what they are
> styling. Class names should be easily understood by non-technical people - such
> as graphics artists. Class names should not imply positioning or styling.
> Examples of improper class names: "topRightButton" "leftMenuBar" "boldRedText" -
> those all imply position/style.
>
> Recurring HTML element collections (navigation bars, button bars, screenlets)
> should be styled as a whole - using contextual or descendant selectors.
>
> Be consistent with property values. Use EMs for sizing - which allows the page
> to be resized gracefully. Use the hex notation for colors - which allows a
> graphic artist to search/replace colors.
>
> [Brief "good" versus "bad" code example goes here.]
>
> --- HTML/CSS Testing Guidelines ---
>
> Don't make assumptions in your code. Don't assume everyone reads left-to-right.
> Don't assume everyone can distinguish between subtle shades of gray. Don't
> assume everyone uses their browser's default settings. Test your code on several
> browsers, then change the browser's settings. Reverse the layout direction (CSS
> direction: rtl;). Change the language. Resize the browser window - make it
> really tiny. The page should make sense under any circumstance.
>
> After you're satisfied that your HTML/CSS code will display correctly under any
> circumstance, run the page through a validator to catch any errors.
Re: RFC: HTML/CSS Best Practices
Posted by Jonathon -- Improov <jo...@improov.com>.
Adrain,
Very nice guidelines. To some of us, it's mostly second nature by now. But always good to have it
put up somewhere for easy reference.
> If a particular browser does not conform to the latest standards, then
> the HTML/CSS code should strive to produce a usable web page with that
> browser. In other words, OFBiz developers should not "dumb down" the
> user interface to support a non-conforming browser, yet someone using a
> non-conforming browser should still be able to use OFBiz.
>
> [As Andy Clarke said, "For such a young and dynamic medium as the web,
> the notion that designers should not push design boundaries forward
> because of only one browser, even when that browser is the market
> leader, seems incompatible with progress."]
The above is so difficult to achieve. But I usually err on the safe side. I code for the lowest
denominator first, add dazzle for better-equipped browsers later.
Jonathon
Adrian Crum wrote:
> The proposed HTML/CSS coding guidelines/best practices. My comments are
> in brackets [] - they are not intended to be a part of the final version.
>
> These guidelines are short and to the point. I could go into more
> detail, but then that would be bordering on writing a book about web
> design. Instead, I took the approach that the reader has already read
> books on HTML and CSS, and they just need some basic guidelines.
>
> Your comments and suggestions are welcome. Once everyone has commented,
> I will post the final version on the Wiki.
>
> ---------------------------------
> OFBiz HTML and CSS Best Practices
> ---------------------------------
>
> --- Web Standards and Browser Compatibility ---
>
> OFBiz HTML and CSS code should strive to conform to the latest W3C
> standards. Browser-specific extensions should be avoided.
>
> If a particular browser does not conform to the latest standards, then
> the HTML/CSS code should strive to produce a usable web page with that
> browser. In other words, OFBiz developers should not "dumb down" the
> user interface to support a non-conforming browser, yet someone using a
> non-conforming browser should still be able to use OFBiz.
>
> [As Andy Clarke said, "For such a young and dynamic medium as the web,
> the notion that designers should not push design boundaries forward
> because of only one browser, even when that browser is the market
> leader, seems incompatible with progress."]
>
> --- HTML Guidelines ---
>
> HTML should be well structured, concise, and free of styling
> information. Well structured HTML is easily styled with style sheets
> (CSS) - therefore all styling code should be kept in the style sheets.
>
> [Brief "good" versus "bad" code example goes here.]
>
> HTML tables should be used for rendering tabular data only - they should
> not be used for general layout.
>
> All HTML should pass validation.
>
> --- CSS Guidelines ---
>
> Style sheets should be concise and organized.
>
> Class IDs are preferred over class names.
>
> Build from the bottom up. Assign common properties to basic HTML
> elements first, then embellish the elements with additional selectors
> (CSS inheritance).
>
> Give the class names/selectors meaningful names that describe what they
> are styling. Class names should be easily understood by non-technical
> people - such as graphics artists. Class names should not imply
> positioning or styling. Examples of improper class names:
> "topRightButton" "leftMenuBar" "boldRedText" - those all imply
> position/style.
>
> Recurring HTML element collections (navigation bars, button bars,
> screenlets) should be styled as a whole - using contextual or descendant
> selectors.
>
> Be consistent with property values. Use EMs for sizing - which allows
> the page to be resized gracefully. Use the hex notation for colors -
> which allows a graphic artist to search/replace colors.
>
> [Brief "good" versus "bad" code example goes here.]
>
> --- HTML/CSS Testing Guidelines ---
>
> Don't make assumptions in your code. Don't assume everyone reads
> left-to-right. Don't assume everyone can distinguish between subtle
> shades of gray. Don't assume everyone uses their browser's default
> settings. Test your code on several browsers, then change the browser's
> settings. Reverse the layout direction (CSS direction: rtl;). Change the
> language. Resize the browser window - make it really tiny. The page
> should make sense under any circumstance.
>
> After you're satisfied that your HTML/CSS code will display correctly
> under any circumstance, run the page through a validator to catch any
> errors.
>
>