Mark McLellan <mark.mclellan@mmenterprises.co.uk> wrote:
[color=blue]
> Following the oft-repeated advice here and ciwas I have made my site
> nearly 4.01 strict (working on it).[/color]
Actually there are two schools on this. My school says that it's important
to write logical markup and separate structure and content from visual
appearance, as far as feasible. This normally means using Strict, but
that's not the goal, just a side effect.
[color=blue]
> 1. Hidden fields
>
http://www.zoo.co.uk/~mmenterprises/contact.htm
> I am using FormMail from Matt's Script Archive.[/color]
Gasp. You mean the original unreliable version that is a serious security
threat? But that's a different issue.
[color=blue]
> The W3C validator
> objected to the hidden fields unless I put, say, P round them.[/color]
Indeed. Part of being Strict is the requirement of putting all "inline
elements" inside block level containers. A bit silly if you ask me, though
it's _mostly_ a useful principle. But there's little point in it as regards
to form fields for example.
[color=blue]
> That gave me unwanted blank lines.[/color]
You could suggest a different rendering by using CSS. But why did you
use P? It's really not a paragraph in any sensible interpretation of the
word.
[color=blue]
> So I put a DIV round them and styled them
> as display: none[/color]
That's not needed since hidden fields aren't displayed anyway (by default
that is - and if a browser wanted to display them for some strange reason,
we had better not interfere).
[color=blue]
> but that seems too much like a kludge![/color]
So the display: none part is not needed. The DIV markup isn't a kludge,
unless you regard the "blocking" principle of Strict itself a kludge.
When you have no logical alternative and you need (or want) to make
something a block, DIV is the only sensible alternative. And it could even
be logical in a sense, for grouping hidden fields together.
Now that I look at your markup, you seem to have made each hidden field a
paragraph, which may imply some spacing in rendering, and therefore you
have wrapped them inside a DIV with display: none. But that's not needed:
you can simply use <div><input ...><input ...>...<input ...></div>.
[color=blue]
> 2. Images do not flow
>
http://www.zoo.co.uk/~mmenterprises/kgs/index.html
> I had a whole lot of small images one after the other with no gaps. I
> was aiming for a fluid design and I expected them to wrap. Instead they
> formed one huge long horizontal line.[/color]
That's a bit surprising, since images normally wrap even when you have no
spaces between them (<img ...><img ...>). But it seems that this does not
happen if the images are inside a table cell!
So this is not directly related to Strict vs. Transitional, except in the
sense that if you applied the "spirit of Strict", you wouldn't use a table
for layout and you would avoid the problem. :-) (Strict does not disallow
layout tables of course, but the idea of Strict is, in part, to
delegate presentation to style sheets.) Seriously, I think the use of a
table is not very serious here, and replacing it by CSS would be a major
effort.
It seems that if you set
td img { float: left; }
in a style sheet, the presentation becomes what you want - though you need
to take care of stopping the floating after a string of images, e.g.
with <br style="clear:both"> (that's the nominally Strict way of saying
<br clear="all">).
[color=blue]
> 3. Free counter[/color]
Counters considered harmful.
[color=blue]
> The HTML fragment from the free webcounter does not validate.[/color]
TANSTAAFL. :-)
[color=blue]
> I can fix
> the border and target attributes but what suggestions do you have for
> for language="JavaScript"? Apart from remove the javascript completely?[/color]
You can remove the language attribute, and need to do so if you wish to
comply with Strict rules. Removing it has no effect, since browsers that
support scripting use JavaScript as the default scripting language anyway.
The only need for the language="..." attribute is in the rare situations
where you wish to distinguish between different versions of JavaScript.
[color=blue]
> 4. Any other comments or suggestion?
> Apart from get rid of tables for layout and improve my alt tags. What
> else should would be good to do?[/color]
As I wrote, I wouldn't regard layout tables as a big problem here. I don't
think the alt attributes for the photos can be made essentially better
(though this depends on whether codes like b1, b2, ... have some
informative value to a person who does not see the images - I cannot guess
what the codes are). For the counter, there's no good alt text, but
"Visited by fastcounter people since 17 March 1996"
is fairly odd; alt="some number of" would make more sense.
--
Yucca,
http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring:
http://www.cs.tut.fi/~jkorpela/www.html 
