Moving to 4.01 strict: problem with hidden fields et al.

**Jukka K. Korpela** · Jul 23 '05, 11:13 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

Mark McLellan <mark.mclellan@ mmenterprises.c o.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:bo th"> (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="JavaS cript"? 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

**Uncle Pirate** · Jul 23 '05, 11:13 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

Mark McLellan wrote:
[color=blue]
> Dear all
>
> Following the oft-repeated advice here and ciwas I have made my site
> nearly 4.01 strict (working on it). There are some items on which I would
> appreciate your advice:
>
> 1. Hidden fields
> http://www.zoo.co.uk/~mmenterprises/contact.htm
> I am using FormMail from Matt's Script Archive. The W3C validator
> objected to the hidden fields unless I put, say, P round them. That gave
> me unwanted blank lines. So I put a DIV round them and styled them as
> display: none but that seems too much like a kludge! What is the cleaner
> way to handle hidden form fields?[/color]

#1 Don't use Matt's script. It's insecure allowing spammers to bounce
mail off of the server you use.

#2 Read the specs about the errors you see. You will find that <input>
is an inline element that must be enclosed within a block level element.
The recommended element for form elements is <fieldset> but <div> or
<p> (<input> is not a paragraph though) will work. I sometimes use
fieldset and set it to not display the default border.
[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. So I put a space between each image
> then they behaved as expected. However I would like to use border
> properties instead of spaces. Is there a way to make them wrap without
> inserting the space?[/color]

I'm not sure what images you are referring to. Place them in 100% wide
<div>s?
[color=blue]
>
> 3. Free counter
> Any page (e.g. the above cited)
> The HTML fragment from the free webcounter does not validate. I can fix
> the border and target attributes but what suggestions do you have for for
> language="JavaS cript"? Apart from remove the javascript completely?[/color]

language is deprecated. You are already using the correct attribute,
type; that's all that's needed.
[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?
>
> Many thanks
>
> Mark.
>[/color]

Do some google searching on "list links css." You can get rid of those
ugly | between links in your menu. It sounds like you've already
decided on some other correct improvements/changes (table,alt attributes).

One other suggestion. It looks like you may be doing already. Read
read read; the recommendations , this newsgroup, alt.html, ciwas
(stylesheets), books, tutorials, whatever.

--
Stan McCann "Uncle Pirate" http://stanmccann.us/pirate.html
Webmaster/Computer Center Manager, NMSU at Alamogordo
Cooordinator, Tularosa Basin Chapter, ABATE of NM; AMA#758681; COBB
'94 1500 Vulcan (now wrecked) :( http://motorcyclefun.org/Dcp_2068c.jpg
A zest for living must include a willingness to die. - R.A. Heinlein

**Jukka K. Korpela** · Jul 23 '05, 11:13 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

Uncle Pirate <stan@surecann. com> wrote:
[color=blue]
> The recommended element for form elements is <fieldset> but <div> or
> <p> (<input> is not a paragraph though) will work.[/color]

I haven't noticed any specific recommendation on using <fieldset> in
general in W3C material. However there are clearly situations where it is
most adequate logically, like for grouping a set of radio buttons.
It would be odd to use it e.g. if you have just one hidden field.

Moreover, the <legend> element is obligatory in <fieldset>, making it
rather unsuitable for hidden fields. (You can use empty content there,
<legend></legend>, but the markup might still affect rendering.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

**Uncle Pirate** · Jul 23 '05, 11:13 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

Jukka K. Korpela wrote:[color=blue]
> Uncle Pirate <stan@surecann. com> wrote:
>
>[color=green]
>> The recommended element for form elements is <fieldset> but <div> or
>><p> (<input> is not a paragraph though) will work.[/color]
>
>
> I haven't noticed any specific recommendation on using <fieldset> in
> general in W3C material. However there are clearly situations where it is
> most adequate logically, like for grouping a set of radio buttons.
> It would be odd to use it e.g. if you have just one hidden field.[/color]

Wrote without checking. Let me rephrase; I've seen it recommended by
some to use <fieldset>. A <div> may well be more appropriate in instances.
[color=blue]
>
> Moreover, the <legend> element is obligatory in <fieldset>, making it
> rather unsuitable for hidden fields. (You can use empty content there,
> <legend></legend>, but the markup might still affect rendering.)
>[/color]

True. I've used empty or just a space (don't remember off hand) for the
<legend> element. Typically, when using <fieldset>, I group a number of
fields within. Rarely, do I find one hidden field to be very useful;
usually, I group several within a <fieldset>. What would be nice is if
<fieldset> were rendered much like a table; I've resorted to tables to
display form input as it makes for an easy columnar layout for the
labels and input fields. I've also used divs to make a columnar layout,
but then there is the problem of maintaining a row's proper display.

--
Stan McCann "Uncle Pirate" http://stanmccann.us/pirate.html
Webmaster/Computer Center Manager, NMSU at Alamogordo
Cooordinator, Tularosa Basin Chapter, ABATE of NM; AMA#758681; COBB
'94 1500 Vulcan (now wrecked) :( http://motorcyclefun.org/Dcp_2068c.jpg
A zest for living must include a willingness to die. - R.A. Heinlein

**Tim** · Jul 23 '05, 11:13 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

Mark McLellan <mark.mclellan@ mmenterprises.c o.uk> wrote:
[color=blue][color=green]
>> but what suggestions do you have for for language="JavaS cript"? Apart
>> from remove the javascript completely?[/color][/color]

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> posted:
[color=blue]
> 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]

Noticing that the page mentions type="text/javascript" as well as using a
language attribute, but your comment about JavaScript being the default
language for browsers seems to be suggesting there's no need to bother
specifying the script as being JavaScript on the page. Wouldn't not
specifying the scripting language be a bit of a kludge? (Relying on
*current* browser behaviour.) In the future, if the page is around long
enough, something else might be the default.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

**News Me** · Jul 23 '05, 11:13 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

Tim wrote:
[color=blue][color=green]
>>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]
>
> Noticing that the page mentions type="text/javascript" as well as using a
> language attribute, but your comment about JavaScript being the default
> language for browsers seems to be suggesting there's no need to bother
> specifying the script as being JavaScript on the page. Wouldn't not
> specifying the scripting language be a bit of a kludge? (Relying on
> *current* browser behaviour.) In the future, if the page is around long
> enough, something else might be the default.[/color]

I agree. Relying on default behavior is bad practice.

If one is in doubt, you can always consult the HTML 4.01 spec, which, in
section 18.2.1, "The SCRIPT element", referring to the type atrribute of
the <script> tag, says:

"This attribute specifies the scripting language of the element's
contents and overrides the default scripting language. The scripting
language is specified as a content type (e.g., "text/javascript").
Authors must supply a value for this attribute. There is no default
value for this attribute."

Note the spec says "Authors MUST supply a value..."

In section 18.2.2, "Specifying the scripting language", the spec states:

"Authors should specify the default scripting language for all scripts
in a document by including the following META declaration in the HEAD:"

<META http-equiv="Content-Script-Type" content="<type> ">

where <type> is one of "text/javascript", "text/vbscript", etc.

Note here the keyword is SHOULD, not MUST.

NM

--
convert uppercase WORDS to single keystrokes to reply

**Markus Ernst** · Jul 23 '05, 11:13 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

Mark McLellan wrote:
[...][color=blue]
> 1. Hidden fields[/color]
[...][color=blue]
> So I put a DIV round them and styled
> them as display: none but that seems too much like a kludge! What is
> the cleaner way to handle hidden form fields?[/color]

Additionnally to Jukka's and others' posts: Usually there are existing
containers for the visible fields, so why not just put the hidden fields in
one of those:

<form>
<p>
Name: <input type="text" name="thename">
</p>
<p>
<input type="hidden" name="whatever" value="whatever value">
<input type="hidden" name="onemore" value="one more">
<input type="submit" name="submit" value="Send data">
</p>
</form>

HTH
Markus

**Jukka K. Korpela** · Jul 23 '05, 11:13 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

Tim <tim@mail.local host.invalid> wrote:
[color=blue][color=green]
>> 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]
>
> Noticing that the page mentions type="text/javascript" as well as using
> a language attribute, but your comment about JavaScript being the
> default language for browsers seems to be suggesting there's no need to
> bother specifying the script as being JavaScript on the page.[/color]

I addressed the problem of the language attribute. I didn't comment on the
type attribute, since it's not a problem. It's actually needed according to
the formal syntax.
[color=blue]
> Wouldn't
> not specifying the scripting language be a bit of a kludge? (Relying
> on *current* browser behaviour.)[/color]

Actually, the type attribute is a useless kludge (though I did not and I do
not say that it should not be used - it's a harmless formality). It is
useless since it (unlike language) does not allow the language _version_ to
be specified. It is a kludge because we have been told to use
"text/javascript", which is an _unregistered_ media type, hence incorrect
since the subtype does not begin with "x-". I wonder how the W3C expects us
to take their recommendations seriously when they themselves take the IETF
procedures this way - they even used the mediatype "text/css" for years
before bothering to register it at IANA.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

**LÄÊ»ie Techie** · Jul 23 '05, 11:14 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

On Sun, 16 Jan 2005 21:12:37 +0000, Jukka K. Korpela wrote:
[color=blue]
> 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]

According to http://www.ietf.org/rfc/rfc2045.txt , we CAN specify
parameters in a content type declaration. I move that we standardize
"version" as such an acceptable parameter for text/javascript

<script type="text/javascript; version=1.3">
alert("I'm using JavaScript 1.3!");
</script>

Anyone have any other suggestions?

La'ie Techie

**Jukka K. Korpela** · Jul 23 '05, 11:14 PM

Re: Moving to 4.01 strict: problem with hidden fields et al.

=?UTF-8?b?TMSByrtpZSB UZWNoaWU=?=
<laie@win_remov e_get_nospam_so lutions.com> wrote:
[color=blue]
> According to http://www.ietf.org/rfc/rfc2045.txt , we CAN specify
> parameters in a content type declaration.[/color]

Yes, to the extent that the definition (specification) of the content type
permits that.
[color=blue]
> I move that we standardize
> "version" as such an acceptable parameter for text/javascript[/color]

I don't think c.i.w.a.h. is formally or factually competent to decide on
such matters.

Besides, the type text/javascript itself has not been registered. Using it
is a violation of RFC 2045. _If_ it were registered, the registration might
define parameters. And then you would just allow eight years for browser
vendors to consider implementing that.

ObHTML: even the type text/html has no parameters; instead, deciding on
language version is in practice based on grotesque doctype sniffing.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Moving to 4.01 strict: problem with hidden fields et al.

Moving to 4.01 strict: problem with hidden fields et al.

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment