site critique please
Hi all
I would appreciate any critiques of http://www.inscale-scales.co.uk
Many Thanks
Peter
Share: 
- Your doctype declaration (XHTML 1.0 Transitional) doesn't match your content type (text/html). This is considered harmful. You should at least try to be "HTML-compatible" by inserting a space before the invalid "/>" terminator.
- I get a horizontal scroll bar at 1024x768 and below, and at 640x480 some text overlap the right-hand column.
- You don't specify the primary natural language (add a "lang" and an "xml:lang" attribute to the <html> tag).
- Lose the deprecated "language" attribute in your <script> tags.
- A number of images have a blank as their text equivalent. Are they spacer images?
- You should simplify your markup and get rid of a lot of extraneous id's and classes. Your front page weighs in at 20+ KB excluding images. That's too much to be dial-up friendly.
- Try to use CSS instead of deprecated presentational attributes such as "width" and "border", and instead of deprecated presentational elements such as <s> (which Lynx shows as [DEL: ... :DEL]).
- Use <p> elements instead of <div> with a bunch of <br/>'s.
- Should all the list items in the first table be read with strong emphasis? (And why a table in the first place?)
- Use relative units of measurement (em, %) instead of pixels in your style sheet.
- Your style sheet has rules with uppercase element names. This won't work if you send the proper content type, since XHTML is case sensitive.
On the whole, the front page feels extremely busy. It's not something I'd like to listen through with a screen reader.
Tommy has left the building
Share:
># Your doctype declaration (XHTML 1.0 Transitional) doesn't match your >content type (text/html). This is considered harmful. You should at least >try to be "HTML-compatible" by inserting a space before the invalid "/>" > >terminator.
I'm afraid to say that having just climbed onboard the xhtml bandwagon for all the wrong reasons i was not aware of this issue. I see that what I'm doing 'may' be acceptable but its not, as you say, what i SHOULD be doing.
I clearly need to read the (above my skill level) article you linked to Toolman though any quick pointers for idiots would be appreciated .
I understand there are issues with using
<meta http-equiv="content-type"
content="application/xhtml+xml" /> for ie 6 and all major browsers
though the site seemed to behave when i tested it - however it the validator couldn't even begin to validate it.....
It did behave/validate ok with <meta http-equiv="content-type"
content="application/xhtml+xml; charset=iso-8859-1" />
but is this just too dumb to even comment on?
....and I'm still concerned about how browsers that don't accept application/xhtml+xml will render the site.
So until I understand which is the best way to go i've left it at text/html and make sure i steer clear of xhtml until i really need it!
># I get a horizontal scroll bar at 1024x768 and below, and at 640x480 >some text overlap the right-hand column.
A scroll bar at 1024? and also at 800 or did you mean 800? The site looks crap at 640 - i tried to fix the overlapping by setting a min-width: 800px; for the top div but that doesn't seem to help. The only thing i can see to do is to put the central section above the right column using z index but thats a bit of poor fix. (this is my first go at a css based site too!)
Any suggestions again welcome. Otherwise people will need to increase
their screen resolution to use the site which i am embarrased about. Am i way out of line here for accessibility?
># You don't specify the primary natural language (add a "lang" and an >"xml:lang" attribute to the <html> tag).
Fixed
># Lose the deprecated "language" attribute in your <script> tags.
Fixed
># A number of images have a blank as their text equivalent. Are they >spacer images?
I thought that i should leave decorative graphics as empty " " - is it better to describe them alt="decorative graphic"?
># You should simplify your markup and get rid of a lot of extraneous id's >and classes. Your front page weighs in at 20+ KB excluding images. >That's too much to be dial-up friendly.
agreed - i'm new to css - hopefully i'll get better.
># Try to use CSS instead of deprecated presentational attributes such as >"width" and "border", and instead of deprecated presentational elements >such as <s> (which Lynx shows as [DEL: ... :DEL]).
will do - i've removed the instances from the template and will tidy up the others as i go
># Use <p> elements instead of <div> with a bunch of <br/>'s.
ok. will try to get more systematic/tidy with my scripting
># Should all the list items in the first table be read with strong emphasis? >(And why a table in the first place?)
not really - its just a method i used to make the text a different color from the bullet discs. i know thats not cool really but i don't knoww how else to do it. any suggestions?
i used a table because it was late(!) and i couldn't figure out the css i needed to put the bullets adjacent rather than under the javascript that rotates the images.
># Use relative units of measurement (em, %) instead of pixels in your >style sheet.
>i've got to get my head round these - i know px are a cop out but they >seem more reliable and they can still be manipulated by the text size >setting on the browser. Am i way out of line here for accessibility?
># Your style sheet has rules with uppercase element names. This won't >work if you send the proper content type, since XHTML is case sensitive.
Fixed
A big thank you TOOLman for your taking the time today.
I will make a point of visiting a more often
Share:
| peter d wrote: |
| I clearly need to read the (above my skill level) article you linked to Toolman though any quick pointers for idiots would be appreciated . |
OK, basically, people seem to believe that XHTML is much 'cooler' than boring old HTML, and that all you have to do is add a slash before the right-hand angle bracket on some tags and slap on another doctype declaration.
Unfortunately, it's rather more complicated than that.
XHTML is a 'reformulation of HTML as an XML application'. That means XHTML is XML, which just happens to look a lot like HTML. The fact that it looks like HTML makes it 'work' in old browsers made even before XHTML was invented.
The only reason it works, is that no browser seems to be capable of properly parsing SGML (the basic markup language that HTML is 'based' upon). In fact, when you write
| Code: |
| <br/> |
a fully compliant browser should output a line break, followed by a '>' character, because the slash should terminate the SGML tag. Browsers seem to ignore the slash they don't understand, and that's why it works.
Next, XML is case sensitive, whereas HTML is not. All tags and attributes must be written in lowercase, so no more onClick="doSomething()". Furthermore, all attribute values must be quoted in XML, even if they only contain letters and digits. And of course, XML must be well-formed, which means that all elements must be closed and nested elements must be closed in the proper order.
CSS works perfectly well with XML. CSS is case insensitive in the parts that are controlled by CSS. Element names and attributes are not, so rules like
| Code: |
| A:hover {color:#0f0} |
will not work with XHTML (must be 'a:hover').
The next can of worms is JavaScript or, rather, the DOM (Document Object Model). Old friends like 'document.write' won't work properly in XHTML; you need to use more complicated constructs as 'createElementNS' to create elements or nodes in the proper namespace. Also, functions like 'document.getElementsByTagName' have slightly different behaviour in XHTML, due to case-sensitivity.
"But all this stuff is working with my XHTML pages!" you cry.
Yes, because you're not really using XHTML. You use XHTML markup, but serve it with a content type of 'text/html'. Browsers don't use the doctype to decide what kind of markup they're dealing with, not really. They check the content type, which should be 'application/xhtml+xml' for XHTML documents. The W3C says that you may use 'text/html' for XHTML 1.0 that is 'HTML compliant' according to Appendix C of the XHTML 1.0 specification. The word may doesn't mean 'do what you like', but 'if you absolutely must, and if you are fully aware of the consequences'.
| peter d wrote: |
| I understand there are issues with using
<meta http-equiv="content-type" content="application/xhtml+xml" /> for ie 6 and all major browsers |
Sorry, mate, but that won't work. A browser needs to know the content type before it even tries to parse a single character. The content type must be sent as a proper HTTP header:
| Code: |
| Content-Type: application/xhtml+xml; charset=iso-8859-1 |
Adding a <meta> element inside the document won't work, because when the browser encounters it, it's far too late. It can help the W3C validator understand that you want to validate it as XHTML, but browsers will still parse and render the page as tag soup (HTML).
OK, so you change the web server setting to send the proper content type, or you use a server-side scripting technique like PHP or ASP to send the headers yourself. Now what? Chaos and mayhem, that's what.
Only the most modern browsers understand the XHTML content type. Mozilla, Firefox, Opera 7, maybe a few more. Notably, Internet Explorer does not. It will ask you what you wish to do with this exotic and unknown file, but it won't render it (although it is capable of rendering XML+CSS).
| peter d wrote: |
| ....and I'm still concerned about how browsers that don't accept application/xhtml+xml will render the site. |
They won't. What you need to do is something called content negotiation. You need a server side script that examines the HTTP Accept header sent by the browser, and determines the proper content type to use. If the browser accepts and prefers XHTML (you need to look at the quality values), you send XHTML markup and set the content type to 'application/xhtml+xml'. If the browser doesn't accept XHTML, or prefers HTML, you send HTML markup and set the content type to 'text/html'. You can do this without having to write two versions of each document, but it's not trivial.
Check out my site with Mozilla and IE, and you'll see the effect. Look at the source in each browser, and you'll see that Mozilla gets XHTML 1.1, while IE gets HTML 4.01 Strict. I use PHP, but you could use ASP, JSP, or whatever language or technique you fancy.
| peter d wrote: |
| So until I understand which is the best way to go i've left it at text/html and make sure i steer clear of xhtml until i really need it! |
Yes, and my recommendation is that you also stick with HTML markup until that time, because what you're doing right now is sending invalid HTML to all browsers. You're relying on their error handling.
| peter d wrote: |
| A scroll bar at 1024? and also at 800 or did you mean 800? |
I get a horizontal scroll bar at 1024x768, at 800x600, and at 640x480. It's gone only at 1280x1024.
| peter d wrote: |
| i tried to fix the overlapping by setting a min-width: 800px; — — — Am i way out of line here for accessibility? |
Maybe not way out of line, but somewhat.
Not all browser windows are 800 pixels wide, even when maximized. At a resolution of 800x600, a browser window has a rendering area with a width of 740-770 pixels, depending on the browser and the operating system. But then some people like to have a favourites bar open ...
There are also devices like PDAs and mobile phones, whose displays can be as small as 128 pixels.
| peter d wrote: |
| ># A number of images have a blank as their text equivalent. Are they >spacer images?
I thought that i should leave decorative graphics as empty " " - is it better to describe them alt="decorative graphic"? |
If they are purely decorative, you could put them in as background images through CSS. In HTML, you should use alt="" (not alt=" ") for decorative images. Browsers that cannot display images display the alt text instead, so if you use alt=" ", there will be a space there.
| peter d wrote: |
| ># Should all the list items in the first table be read with strong emphasis? >(And why a table in the first place?)
not really - its just a method i used to make the text a different color from the bullet discs. i know thats not cool really but i don't knoww how else to do it. any suggestions? |
CSS, of course!
Rule #1: never use (X)HTML to control presentation.
HTML is used for marking up the structure of a document, and presentation should be handled strictly by CSS. It's not a perfect world, and sometimes you need to add some extraneous <div> and <span> elements as 'hooks' for styling.
If you want the text to be a different colour from the list bullets, you have two options:
- Create a bullet image in the colour you want, and use the 'list-style-image' CSS property to set it.
- Set the 'color' property for the list or list items to the colour you want for the bullets. Then wrap a <span> around the text, and set a different colour for 'li span'.
| peter d wrote: |
| i used a table because it was late(!) and i couldn't figure out the css i needed to put the bullets adjacent rather than under the javascript that rotates the images. |
<groan/>
'Because I was late' is not a valid excuse, mate. Sorry.
Styling lists with CSS can be a bit daunting, because the specs are a bit vague, and all the browsers implement it in different ways. You'll have to play around with 'margin' and 'padding' for both the <ul> and the <li>'s. For a pixel-perfect layout, you may even have to set 'list-style:none' and use a bullet image as a background image of the <li>'s, with the proper left padding.
| peter d wrote: |
| ># Use relative units of measurement (em, %) instead of pixels in your >style sheet.
>i've got to get my head round these - i know px are a cop out but they >seem more reliable and they can still be manipulated by the text size >setting on the browser. Am i way out of line here for accessibility? |
If you specify the font size in pixels, the text cannot be resized in IE. Percentages are buggy in IE, at least for nested elements, but ems do work rather well. In IE, you should set the base font size (for <html> or <body>) as a percentage (preferably 100% if you ask me). Then you can use ems for everything else. (If you don't set the base font size as a percentage, an IE bug will make sub-1em text microscopic.)
The ability to change text size is crucial for accessibility. Using ems to set sizes of 'columns' and stuff lets you create what is known as an elastic design. That's much like a fixed-width design, but the width is set in ems rather than pixels.
In a pixel-based fixed-width design, when you increase the text size, there will be room for fewer characters on a line. Sooner or later it won't fit, as you've seen in your design at 640x480. If you go elastic, the entire design gets wider or narrower as you change the font size, but the number of characters on a line is constant. Of course, if you increase the text size enough, you'll have to scroll sideways, but that's better than having an illegible design with overlapping text.
Tommy has left the building
Share:
'War & Peace'. Tommy 
Share:
That's an excellent and clear interpretation of the XHTML problems though, worth formatting into a full and glorious XHTML (served as HTML ) page IMHO, because, like peter, I and I suspect a lot of people, just didn't "get" Ian's comments until the 5th or 6th read.Kajun
Share:
[quote]my recommendation is that you also stick with HTML markup until that time[/quote]
agreed. i've swapped the site doctype back to html but i'm keen to keep going forward so i have made it 4.01 strict.
the home page (my starting point) is not validating though because
[quote]document type does not allow element "INPUT" here; missing one "P", "H1", "H2", "H3", "H4", "H5", "H6", "PRE", "DIV", "ADDRESS" start-tag ...e="3f01ab87036b38f51479845b2e794e33" />
[/quote]
I'm embarrased to say that I have no idea where this comes from!
[quote]I get a horizontal scroll bar at 1024x768, at 800x600, and at 640x480. It's gone only at 1280x1024. [/quote]
yeah so do i - in mozilla (and probably everything except ie
). there must be something weird about how i've set the logo. i'll come back to once i've got it validating.
[quote]you should use alt=""[/quote]
and
[quote]Then wrap a <span> around the text, and set a different colour for 'li span'. [/quote]
understood. thanks for putting me straight.
Regards the posistioning lists etc i'll need more time to refine my use of them. I've got to get my head around the mess that is the site at 640
I said incorrectly in the last email that i used pixels to set the font size. This wasn't strictly true - i did use pixels to set the font size for the elements in the top banner because it got disturbed and ugly when i increased the font size.
For the body of each page I use x-small / small / medium etc etc. This can be resized. Is using these cool?
And i set the left and right hand columns at 22% - that is elastic right or not really?
[quote]If you go elastic, the entire design gets wider or narrower as you change the font size, but the number of characters on a line is constant. [/quote]
When i increase the font size on my site the column widths don't get any wider or narrower - would they if i set them using ems and if so how do i do that as that may help me solve the problem
thanks toolman
Share:
| enigma wrote: |
| 'War & Peace'. Tommy |
Don't I know it.
I wish I could be more concise, but that's a skill I've yet to acquire.
| Kajun wrote: |
| I suspect a lot of people, just didn't "get" Ian's comments until the 5th or 6th read. |
I, too, had to read through it a few times before the full implications got to me. I did the same thing as Peter and about a gazillion others: XHTML markup served as text/html. My first reaction when I read Ian's article was defensive. Like most human beings, I don't like to be told I'm wrong.
Then I swallowed my pride and read the article again, and I realised that he's probably right. Then I examined some of the problems, like CSS and the DOM, and I found that he's very definitely right, no doubt about it.
| peter d wrote: |
| i've swapped the site doctype back to html but i'm keen to keep going forward so i have made it 4.01 strict. |
That's the one I'd recommend too.
| peter d wrote: |
| the home page (my starting point) is not validating though |
Without looking at the code, I'd say you're having a <form> somewhere. In strict HTML, forms may only contain block-level elements, e.g. <fieldset>, <div> or <p>. Just make sure that you don't have any 'loose' <input> elements as immediate children of the <form>, and you'll be fine.
| peter d wrote: |
| yeah so do i - in mozilla (and probably everything except ie ). |
My intuitive guess: you have set a width of something to '100%' and then specified left and/or right padding on it. Padding is supposed to be added to the specified width, but IE gets it wrong. In IE6, you can make it behave properly if you specify the correct doctype. Google for 'quirks mode' or 'doctype switching' and you'll find lots of info about this, in case you're not aware of the issue.
| peter d wrote: |
| For the body of each page I use x-small / small / medium etc etc. This can be resized. Is using these cool? |
I don't know about 'cool', but it is absolutely valid and aids accessibility.
| peter d wrote: |
| And i set the left and right hand columns at 22% - that is elastic right or not really? |
That's what we call 'liquid'. Elastic is when you set the column width in ems. Both are good, and both present some intricate problems for the designer, although not nearly as much as a fixed-width design does for the user.
| peter d wrote: |
| When i increase the font size on my site the column widths don't get any wider or narrower - would they if i set them using ems and if so how do i do that as that may help me solve the problem |
Yes, that would do it. There will be people who say you should always go liquid (percentages) and there will be people who say you should always go elastic (ems). There will also be a bunch of people who say you should always go with a fixed width in pixels, but don't listen to them.
I'll try to be short this time, but here's a brief run-down of the issues with the three design models.
Fixed-width
This means that the widths of design elements are set in pixels, inches, centimetres, etc. Units that correspond to a physical dimension.
If the width is larger than the display size (which it will be for some displays, no matter what width you choose) there will be a horizontal scroll bar. Horizontal scroll bars are not good for usability, and IMO not for accessibility either.
If you set a narrow enough width, in order to fit it into the most commonly used screen resolutions, the result will be a thin stripe of a page, usually in the centre of the screen. It can look ridiculous.
Here's the clincher: if you enlarge the text size, fewer and fewer characters will fit into your fixed-width columns. Eventually, the design will break and the text will begin to overlap.
Liquid
This means that all major design elements (think 'columns' if you will) are specified as percentages (of the viewport size, i.e. the browser window).
A liquid design adapts nicely to any screen size. However, when the window size is sufficiently reduced, a percentage-based column will not be wide enough to contain its content. This is more of a problem in languages such as Swedish, where we have some really long words, but sooner or later you'll get caught even if you're writing in English. Besides, images will be a problem, unless you learn how to specify their widths as percentages as well.
Another problem is that the lines of text will become too long to read on large displays. CSS includes a very handy property for handling this (max-width) but, sadly, it's not supported by IE and is therefore not a viable stand-alone solution in the real world. You'll have to resort to JavaScript to get it to work in IE, which opens a whole 'nuther can of worms.
Elastic
This means that column widths are specified in 'em' (or, more exotically, in 'ex').
It's a good way to keep line lengths at a readable number of characters. If you change the font size, the columns become wider or narrower.
The problems with an elastic design are similar to those of a fixed-width design. Small displays just cannot display a total of 80em, or whatever you'll arrive at. Large displays will show a narrow page in the centre or on the left, with lots of 'wasted' space around it.
Hybrid
Hybrid designs, also known as 'fusion' designs, combine techniques from liquid and elastic designs. For instance, in a three-column layout, the menu column can be set in ems, while the two content columns can be set in percentages of the remaining width.
As with fully liquid designs, this can lead to overly long lines of text (or excessive white space) on large displays, or ridiculously narrow columns in small windows.
Conclusion
Unfortunately, there is no panacea, no ideal solution for all circumstances.
A fixed-width design is probably the worst choice under most circumstances (the possible exception being a controlled environment such as an intranet).
An elastic design or, more commonly, a liquid/elastic hybrid, often works best under a wide range of screen resolutions. It can never be perfect, and it's not quite as easy to accomplish as a fixed-width design, but life is all about compromises, isn't it?
If it weren't for dinosaur browsers like Internet Explorer, a liquid or hybrid design would be almost perfect. Since life is unfair, and since a vast majority of people use the worst available browser, we'll have to cater for the lowest common denominator.
Tommy has left the building
Share:
| TOOLman wrote: | ||
Don't I know it. I wish I could be more concise, but that's a skill I've yet to acquire. |
I disagree. Your style is relaxed, fluid and easily read. There's a lot to be said against my style: convoluted and challenging with too many nested concepts.
Well done, mate, a pleasure to read
And you get the odd thing or two correct
Share:
| enigma wrote: |
| Your style is relaxed, fluid and easily read. There's a lot to be said against my style: convoluted and challenging with too many nested concepts.
Well done, mate, a pleasure to read And you get the odd thing or two correct |
Agreed. Anyone else here think Tommy should start-up his own drop in chat sessions? He could get funding from somewhere and become... <voice-of-doom>The Advisor</voice-of-doom>.
Jon Gibbins, dotjay.co.uk, accessibility.co.uk wiki.
Share:
ROTFLMAO! Tommy has left the building
Share:
Hi all
i'm still doing my damndest to get this page vaildated but still cannot see where i'm going wrong.
the problem 'seems' to be the form tag itself (ie if i remove everything between the form tags it still fails!) though i'm sure it isn't
i've created a page [url]http://www.inscale-scales.co.uk/index3.php[/url][size=18][/size]
with just the rascal code. i'd love for somebody to run there eye over it and give me a clue as to the problem. i know i need to work this out for the future.
Thanks all esp ... 'The Advisor'
Share:
Slip the <input> it refers to into the <div> below.
Original code:
| Quote: |
| <form action="" method="post" style="margin: 5px 0px 5px 0px;"><input type="hidden" name="PHPSESSID" value="" />
<div id="basketdropdown"> <select name="currency" class="productdropdown"> <option>GBP Sterling</option> |
Newcode:
| Quote: |
| <form action="" method="post" style="margin: 5px 0px 5px 0px;">
<div id="basketdropdown"> <input type="hidden" name="PHPSESSID" value="" /> <select name="currency" class="productdropdown"> <option>GBP Sterling</option> |
It seems a bit weird, but when you're specifing a strict doctype, inline elements such as input need to be within another block-level element such as p or div. <form> doesn't count as block-level for strict validation, even though most people think it should. Hence
Kajun
Share:
| Kajun wrote: |
| It seems a bit weird, but when you're specifing a strict doctype, inline elements such as input need to be within another block-level element such as p or div. <form> doesn't count as block-level for strict validation, even though most people think it should. Hence |
That's not entirely correct, unless I've misunderstood something vital.
The problem is that the <form> element may only contain block-level elements in the strict DTD. That's why you can't have <input> elements (which are inline) as immediate children of a <form>.
The <form> element itself is block-level (has an implicit line-break before and after).
Tommy has left the building
Share:
| TOOLman wrote: |
| The <form> element itself is block-level (has an implicit line-break before and after). |
True, true. What I should have said is that the <form> element doesn't act like other block-level elements do in the strict DTD, even though it's a block-level element, which is why it becomes confusing. As you say, you can't have inline elements as immediate children.
Apparently, this part of the DTD helps.
Kajun
Share: