53 replies [Last post]
rogermakrm2006
Offline
Regular
Last seen: 14 years 4 weeks ago
Joined: 2005-08-15
Posts: 29
Points: 0

Hello Genius again:

all my webpages are required to be passed by w3c (xhtml 1.0 strict) and my opening form tag looks like this:

<form name="register" method="get" enctype="application/x-www-form-urlencoded" onsubmit="return checkregisterform()">

and it works when i try to check this:

if (document.register.Name.value == "")blabla();

but got an error message from w3c when scanning the file...

Error Line 71 column 12: there is no attribute "name".

<form name="register" method="get" enctype="application/x-www-form-urlencoded"

please help me out! is choking me....

thank you very much!

From roger =D

Tags:
tripleshift
Offline
Enthusiast
Last seen: 13 years 6 weeks ago
Timezone: GMT+2
Joined: 2005-03-22
Posts: 70
Points: 0

&lt;form&gt; problem, pls help!

from w3c validator explanation of the error:

Quote:
You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).

This error may also result if the element itself is not supported in the document type you are using, as an undefined element will have no supported attributes; in this case, see the element-undefined error message for further information.

How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.

if i got the problem here, you should go with "id" instead of "name" and strict validator will do fine.

bye
tripleshift

...

I left my good sign in the other pants

rogermakrm2006
Offline
Regular
Last seen: 14 years 4 weeks ago
Joined: 2005-08-15
Posts: 29
Points: 0

thanks for help but

Hello Genius :

thanks for your help firstly

"name" should be an attribute in the <form> tag, otherwise, i wouldn't how to access the elements (textboxes...etc) with in the form....but w3c doesn't let me use it.....

is there any way, i can reach the form's elements (buttons, textbox..) with out know the name of the form???

thank you very much! please reply!!
From roger

tripleshift
Offline
Enthusiast
Last seen: 13 years 6 weeks ago
Timezone: GMT+2
Joined: 2005-03-22
Posts: 70
Points: 0

&lt;form&gt; problem, pls help!

sincerely I don't know.
sure ID doesn't work?
i have a few form were I swapped names with ids in order to validate strict and it works.

i'm sorry but probably you shall wait for somebody with more knowledge on this matter...

bye
tripleshift

...

I left my good sign in the other pants

larmyia
Offline
Elder
London
Last seen: 11 years 3 days ago
London
Timezone: GMT+1
Joined: 2005-01-25
Posts: 1060
Points: 0

&lt;form&gt; problem, pls help!

doesn't id work? I would have thought it did (did you try it when I suggested it in another post?)

dittoing tripleshift, I dont' really know much about forms...but try it and let us know the results.

really would have thought it would have worked tho...

larmyia

HellsBells
HellsBells's picture
Offline
Leader
Bedford, UK
Last seen: 11 years 20 weeks ago
Bedford, UK
Joined: 2004-04-07
Posts: 851
Points: 0

&lt;form&gt; problem, pls help!

Hi

There's a lot of scripts out there that rely on name and won't work with id - ran into this problem myself a couple of weeks ago.

Could you post you're whole form and a quick explanation of what you want it to do - might be easier to find a solution if we can see the whole thing.

My strategy is so simple an idiot could have devised it!

"Also, your CSS (no offence) makes me want to gouge my eyes out with a rusty spoon" - TPH

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

In strict, name has been deprecated as an attribute for the form element (w3c reference). Its still available as an attribute for form controls, where it isn't a fragment identifier but a binding to server side variables. In javascript/DOM you should be using document.getElementById('formid').

Alternatively, you could change the doctype to transitional which will allow deprecated items.

larmyia
Offline
Elder
London
Last seen: 11 years 3 days ago
London
Timezone: GMT+1
Joined: 2005-01-25
Posts: 1060
Points: 0

&lt;form&gt; problem, pls help!

Sorry Chris and HB, I'm a bit confused. can you use id with form? why does it create problems?

larmyia

HellsBells
HellsBells's picture
Offline
Leader
Bedford, UK
Last seen: 11 years 20 weeks ago
Bedford, UK
Joined: 2004-04-07
Posts: 851
Points: 0

&lt;form&gt; problem, pls help!

I'm not a JS expert - I just try to get existing scripts to work how I want!

"id" has replaced "name" as the official way to identify a form in XHTML 1.0 strict. As Chris said it's fine however to have both in the elements that make up a form like text boxes etc.

I've found that a lot of scripts will identify the form they're to work with by "name" and won't work with a straight swap to "id" so it takes some fiddling to get it to work at all without either dropping the DOCTYPE down or failing validation or completely re-writing it.

I do find it faintly confusing and odd that certain elements can have both name and id and others can't - doesn't seem logical at all. Either allow both or get rid of one on all elements.

My strategy is so simple an idiot could have devised it!

"Also, your CSS (no offence) makes me want to gouge my eyes out with a rusty spoon" - TPH

rmfred
rmfred's picture
Offline
Elder
Rock Springs, WY
Last seen: 49 weeks 1 day ago
Rock Springs, WY
Timezone: GMT-6
Joined: 2004-01-31
Posts: 1073
Points: 31

&lt;form&gt; problem, pls help!

It might be something as simple as Name vs name?

Strict requires all lowercase... or perhaps the JS has Name and the form has name?

Something like this should validate..

<form id="testform" method="post" action="sendtestform.asp" onsubmit="return validate(this);">

<label for="firstname">First Name</label><input type="text" name="firstname" id="firstname" /></div>

function validate(testform) {

//validate first name
if (testform.firstname.value.length < 2) {
alert("Please enter your FIRST NAME");
testform.firstname.focus();
return false;
}

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

HellsBells wrote:
I do find it faintly confusing and odd that certain elements can have both name and id and others can't - doesn't seem logical at all. Either allow both or get rid of one on all elements.

In most cases id and name are what XML calls fragment identifiers - unique values that identify one element only. XML rules only allow one fragment identifier. XHTML has decided to go with id as its fragment identifier. So, name has been deprecated on all those elements where name has no use besides being a fragment identifier. There are some elements left, ie. the form controls (input, textarea, button, select), where name is a binding to the value returned by the form.

For the form controls id can't do the job of name. An id must be unique to one particular element, but for a group of radio buttons to work they must all be bound to the same form value. Similarly, it can make sense to bind several different buttons to the same form value (a button only returns a value if its clicked*). Again they share a common name, but must have different ids (or no ids at all).

* except for <button> elements in IE which can return their value no matter what.

HellsBells
HellsBells's picture
Offline
Leader
Bedford, UK
Last seen: 11 years 20 weeks ago
Bedford, UK
Joined: 2004-04-07
Posts: 851
Points: 0

&lt;form&gt; problem, pls help!

Thanks for explaining that Chris - it does make a sort of sense to me now!

Here's a slightly OT question for you on similar lines.

With internal page links I currently do <a id="content" name="content"></a> which is perfectly valid under XHTML 1.0 strict (I checked!). I understand that the name bit is there because our friend IE doesn't recognise the id bit in such a link.

So if I were to try to serve this page as application/xhtml+xml (and ensure the server actual did serve it as this) would I get an error because of including the "name" bit in the link?

edited for silly typos!

My strategy is so simple an idiot could have devised it!

"Also, your CSS (no offence) makes me want to gouge my eyes out with a rusty spoon" - TPH

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

HellsBells wrote:
With internal page links I currently do <a id="content" name="content"></a> which is perfectly valid under XHTML 1.0 strict (I checked!). I understand that the name bit is there because our friend IE doesn't recognise the id bit in such a link.

I think this is a realisation of the real world. In XHTML strict you shouldn't use a name attribute on an anchor element as it has been deprecated. But some browsers* won't work with links to the id attribute of anchor elements. Commonsensically, w3c says, on an anchor element its ok to use a identical values for both id and name attributes (refer xhtml1.0, Appendix C8). Most (all?) the other tags where name has been deprecated will generate validation errors if name is present.

FYI - W3C validator doesn't check that the name and id values are identical.

HellsBells wrote:
So if I were to try to serve this page as application/xhtml+xml (and ensure the server actual did serve it as this) would I get an error because of including the "name" bit in the link?
I doubt it. At present the attribute has been deprecated but it is still present, which means browsers should support it. Only in a later XHTML version when the attribute has been removed are errors likely to crop up.

* Probably early versions of browsers, I am thinking IE4, Netscape 4 or even earlier. IE5.5/Win & IE6/Win work with both id & name. It would be interesting to know which browsers don't support linking to anchor elements with ids to then properly decide if its worth leaving in the name attribute.

Of course, you could always server your page as HTML4 strict and avoid the problem. Smile

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 35 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

&lt;form&gt; problem, pls help!

No you wont get an error from the XML parser on the attribute. If it passes validation then it will be parsed doesn't really matter if the file is delivered as text/html or application/xhtml+xml.

The attribute is deprecated however and really the only place you will find it is as discussed above in form controls as with all deprecated elements I always think that it is better to avoid them if possible.

I would be interested to know which browsers don't support the ID attribute used this way as Chris says IE5/6 do as well as FF and Opera

Are we talking about browsers so old that we really should not be paying lip service to them anymore such as NN4; if so I would think that it's time to drop the name attribute used in this way.

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

HellsBells
HellsBells's picture
Offline
Leader
Bedford, UK
Last seen: 11 years 20 weeks ago
Bedford, UK
Joined: 2004-04-07
Posts: 851
Points: 0

&lt;form&gt; problem, pls help!

Just dug up this from Jim Thatcher's site:

Quote:
As pointed out in an email from Nick Johnson, the anchor should have both an id attribute and name attribute: "If the XHTML is being parsed by an SGML/HTML parser, it will only pay attention to the name attribute, whilst if it's being parsed by an XML parser, it'll only pay attention to the id attribute. Hence, it's a very good idea to use both in anchors when writing in XHTML."

My strategy is so simple an idiot could have devised it!

"Also, your CSS (no offence) makes me want to gouge my eyes out with a rusty spoon" - TPH

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 35 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

&lt;form&gt; problem, pls help!

:? Not sure that's correct at all .

I can use a anchor ID in a page when delivered as text/html with a xhtml Doctype hence parsed by the sgml parser.

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

HellsBells
HellsBells's picture
Offline
Leader
Bedford, UK
Last seen: 11 years 20 weeks ago
Bedford, UK
Joined: 2004-04-07
Posts: 851
Points: 0

&lt;form&gt; problem, pls help!

See this is why I love the internet! You end up with totally conflicting answers to a question!

In the absence of any further proof I hearby decide that Chis and Hugo are right because it's Chris and Hugo and I don't know the other guy from Adam.

My strategy is so simple an idiot could have devised it!

"Also, your CSS (no offence) makes me want to gouge my eyes out with a rusty spoon" - TPH

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 35 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

&lt;form&gt; problem, pls help!

Smile I hesitated to ask who he was and whether he actually knew Adam.

Out of interest in trying to find out which browsers couldn't handle the ID on an anchor I came across a well known site (which shall remain nameless) that made this statement at the end of an explanation of anchor ID's "currently most browsers don't support ID on anchors" my immediate reaction was to assume that the page was extremely old but checking for a page/content date produced nothing more than a 2005 copyright.

Moral of that story is that one needs to be careful what one believes on the web and of the validity of the people disseminating information sometimes.

You confirmed that the validtor was happy to pass the name attribute on the anchor thus the XML parser would process it without fatal error. where the information in that email came from I'm not sure but there may be something I am missing here as it does read as a definite fact ?

Edit: that email quoted is maybe not that inaccurate:

From W3C xhtml 1.0 guidelines:

  • When a user agent processes an XHTML document as generic XML, it shall only recognize attributes of type ID (i.e. the id attribute on most XHTML elements) as fragment identifiers.
  • If a user agent encounters an attribute it does not recognize, it must ignore the entire attribute specification (i.e., the attribute and its value)
  • In XML, URI-references [RFC2396] that end with fragment identifiers of the form "#foo" do not refer to elements with an attribute name="foo"; rather, they refer to elements with an attribute defined to be of type ID, e.g., the id attribute in HTML 4. Many existing HTML clients don't support the use of ID-type attributes in this way, so identical values may be supplied for both of these attributes to ensure maximum forward and backward compatibility (e.g., <a id="foo" name="foo">...</a>).

therefore you are probably correct to use both 'Name' and 'ID'. Using 'Name' will not break the page in the XML parser. You must use the ID fragment identifier on the a, form, img elements in XHTML and as according to the W3C many UA don't support :? the ID on anchors then it is advised to use 'Name for backwards compatibility.

I would still like to know who these browsers are that cannot work with IDs on anchors though as I prefer to not use deprecated tags and the browsers that I can determine work with anchor IDs certainly don't baulk using the sgml parser on them nor the xml for that matter.

Hugo.

[/]

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

I have checked further.

I found the language in the spec's a little confusing at my first reading. They talk about anchor names, and only later explain that "An anchor name is the value of either the name or id attribute when used in the context of anchors."

That's in HTML4 spec. The earliest version I could find is dated Dec-1997. The current 4.01 spec is dated Dec-1999. That "should" mean all browsers produced since that time support id as the destination of a URL fragment.

The previous, HTML3.2 spec does not include id attributes - its dated Jan-97.

Matching that to IE history ....
IE3 - 08-1996
IE4 - 10-1997
IE5 - 09-1998
would imply IE3 doesn't support id, IE5 does, IE4 ?? (this is a guestimate I don't have access to IE below 5.5 to verify).

and navigator history ...
NN3 - 08-1996
NN4 - 06-1997
would imply NN3 doesn't support id, NN4 ?? (guestimate again).

Also, O'Reilly Dynamic HTML, says id is supported by both NN4+ and IE4+ although it doesn't say for which browsers ids can serve as anchor names.

So, for this whole names in anchors thing, we are most likely talking about browsers released before 1997 including NN3 & IE3 and possibly including browsers released in 1997 including NN4 & IE4.

:idea: I discovered, ids don't have to be on anchor elements to serve as the destination for URL fragments. Linking to #id will cause the browser to move to #id no matter what element it belongs to.

Conclusion, eight years is probably long enough, you most likely can drop name from anchor elements without causing big problems. In fact you can probably do away with using <a> elements as anchors and use id's on an appropriate nearby element.

HellsBells
HellsBells's picture
Offline
Leader
Bedford, UK
Last seen: 11 years 20 weeks ago
Bedford, UK
Joined: 2004-04-07
Posts: 851
Points: 0

&lt;form&gt; problem, pls help!

Wow thanks for checking out all that Chris.

My understanding was that IE didn't recognise this sort of anchor link unless it had a "href" in it - even if it was just a #.

My strategy is so simple an idiot could have devised it!

"Also, your CSS (no offence) makes me want to gouge my eyes out with a rusty spoon" - TPH

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 35 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

&lt;form&gt; problem, pls help!

Nice investigative work Chris and as I figured were talking of rather outdated browsers that require 'Name' :roll:

Chris..S wrote:


:idea: I discovered, ids don't have to be on anchor elements to serve as the destination for URL fragments. Linking to #id will cause the browser to move to #id no matter what element it belongs to.

Conclusion, eight years is probably long enough, you most likely can drop name from anchor elements without causing big problems. In fact you can probably do away with using <a> elements as anchors and use id's on an appropriate nearby element.


Have to admit that this matter has arisen before in a thread and I questioned why the an anchor was being created just for a link point and did point out that you could reference any ID on any element which is what I tend to do, usually sticking an ID on the body.
I thought this was common knowledge. Your conclusion is correct the anchor should be done away with and existing ID targeted especially as it seems that all modern browsers will support this use, contrary to my last assertion that in accordance with the W3C xhtml guidelines it was probably correct to use both Name and ID, guidelines supposedly updated 2002. I think maybe they ought to rethink the "Many existing HTML clients don't support the use of ID-type attributes in this way" sentence.
Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

HellsBells wrote:
My understanding was that IE didn't recognise this sort of anchor link unless it had a "href" in it - even if it was just a #.

IE doesn't need an href to get anchors to work. This is my test page. The three links at the bottom all link to a different url fragment identifier.
- h1 id
- anchor id
- anchor name

Also, the anchor element has both a name and an id, they are different values.

The page doesn't validate:

  • W3C validator fails it for the (deprecated) name attribute on the image element
  • HTML tidy gives a warning for the anchor name and id being different, W3C doesn't mention it.

[/]
roytheboy
roytheboy's picture
Offline
Guru
North Wales, UK
Last seen: 6 years 7 weeks ago
North Wales, UK
Timezone: GMT+1
Joined: 2004-09-18
Posts: 2233
Points: 41

&lt;form&gt; problem, pls help!

Just a thought (having just read this thread for the first time)... the term 'anchor' literally suggests that the purpose of an 'anchor' tag is to mark a definite, fixed place within the document layout. Therefore an anchor tag with a name or id would logically and semantically seem the correct tag to use as a fragment identifier.

Therefore, using an anchor tag for a hyperlink would seem to be illogical and un-semantic. Such a tag ought to be called <link>, but the 'link' tag is already used in the document head for a different purpose! :?

Anyway, I just wanted to give you something to think about before you do away with anchor tags for fragment identifiers Wink

Life's a b*tch and then you die!

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

roytheboy wrote:
Just a thought (having just read this thread for the first time)... the term 'anchor' literally suggests that the purpose of an 'anchor' tag is to mark a definite, fixed place within the document layout. Therefore an anchor tag with a name or id would logically and semantically seem the correct tag to use as a fragment identifier.

Maybe*. Smile

roytheboy wrote:
Therefore, using an anchor tag for a hyperlink would seem to be illogical and un-semantic. Such a tag ought to be called <link>, but the 'link' tag is already used in the document head for a different purpose! :?

Yes. Laughing out loud

* An anchor tag adds no meaning to the document itself. Its used to assist in navigation of long documents. Making a link to, e.g., a header by using its id, makes more sense than placing additional html. But...if there was a browser smart enough to generate a page table of contents from anchor tags then why not! Wink

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 13 years 4 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

&lt;form&gt; problem, pls help!

Chris..S wrote:
IE doesn't need an href to get anchors to work. This is my test page. The three links at the bottom all link to a different url fragment identifier.

I don't *think* the techniques in your test page would work in IE (any flavour) if the anchor was not at the top (of the body) of the page.
Jim Thatcher (who he?) and others attempt to explain and demonstrate.
http://www.jimthatcher.com/news.htm
Whereas it may work for top of page, it does not work, from my experience, for top of content. And, I don't think it would work on a series of in-page links within the "content". Top of "page" has been proven to me by a number of blind visitors to be somewhat redundant because their screen-reader will take them there at a (key) stroke. Sighted keyboard-only users seem to get by quite happily with Alt+D and tab on down.

HellsBells wrote:
My understanding was that IE didn't recognise this sort of anchor link unless it had a "href" in it - even if it was just a #.

That has been my understanding since 1997 when a bit of point and click, copy and paste caused the code to be generated by ... FrontPage Shock .
I would have changed to one of the techniques described by Jim, if what I was doing had not worked for eight years and if it was not being used on the websites of two acknowledged "accessibility experts" whose opinions I respect and *tend* to trust: that respect and trust also extends to the redoubtable Mr Thatcher.
http://www.autisticcuckoo.net/blog.php
http://www.seowebsitepromotion.com/
Both use a href="#foo",
One uses link rel="bookmark", in the document head, for a similar purpose.
I copied that idea - he knows and helped me to apply it to several "skip links" on the same page.
One uses a href="#" for stylesheet switching.
Don't do no style switching, mesel' - instead I provide a short tutorial on how to customize browsers so that a visitor's preferred style works on all sites.
Both use id="foo" only.
However, after acting on information received Wink and adding name="foo" back into my site, at the cost of some late nights, I'll stick with both for the time being.

Chris..S wrote:
But...if there was a browser smart enough to generate a page table of contents from anchor tags then why not!

I suppose a screen-reader is a virtual browser and this is what it makes of the following little snippet of code from within page contents, if this is what you mean by a page table of contents.
<p><a id="menu" name="menu"></a>Page Menu - all links go to items on this page:</p>
<ul>
<li><a href="#first">first steps</a></li>
<li><a href="#setup">set up and installation</a></li>
<li><a href="#need">you will need</a></li>
<li><a href="#onoff">switching on and off</a></li>
<li><a href="#care">care and maintenance</a></li>
<li><a href="#enjoy">enjoy your computer</a></li>
</ul>
<hr />
<a id="first" name="first"></a>
<h2>First steps</h2>

A screen-reader sees:

Quote:
Page Menu - all links go to items on this page:
Link 4: first steps
Link 5: set up and installation
Link 6: you will need
Link 7: switching on and off
Link 8: care and maintenance
Link 9: enjoy your computer
___________________________________________________________
Heading: First steps

PS The third item on Jim Thatcher's news page, may be a bit of an eye-opener not to suggest we go off-topic, yet again, of course. :roll:

DeprecatedDiva
DeprecatedDiva's picture
Offline
Enthusiast
NW Louisiana
Last seen: 12 years 39 weeks ago
NW Louisiana
Timezone: GMT-6
Joined: 2005-06-12
Posts: 135
Points: 0

&lt;form&gt; problem, pls help!

I'm VERY confused!

I use anchors on my page and they validate strict!

Here's how:

<a name="bookmarkname">Anchor Object</a>

The anchor cannot be left empty or it will fail validation. I found this out when I kept experimenting to get it to pass validation. Laughing out loud

DeprecatedDiva

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 13 years 4 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

&lt;form&gt; problem, pls help!

DeprecatedDiva wrote:
The anchor cannot be left empty or it will fail validation

I'm not entirely sure what an "empty anchor" is but this bit of code validates XHTML 1.0 Strict and works as expected - seems kinda devoid of filling to me.
<p><a id="menu" name="menu"></a>Page Menu - all links go to items on this page:</p>

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

Test page updated to reflect Lorraine's extra information. Thanks for that.

But...

IE's problem is not to do with using id or name or anchor elements. It is to do with whether or not the location of a url fragment identifier is within an element that hasLayout.

Test page 1 - Fragment identifiers nested within container element that hasLayout.
Test page 2 - Fragment identiers nearest ancestor with hasLayout is <body>.

Follow Jim Thatcher's instructions from Lorraine's link and try to access the different links using tab key to navigate and return key to activate the link. In all cases on both test pages activating the link takes you to the correct page location. Its what IE does next which is the "proprietory behaviour". Using the tab key to move off the link will move the focus to the first element from the start of the nearest ancestor with hasLayout. So if that is the <body> you are back at the beginning of the document again - I can imagine that would be extremely frustrating.

Also take a look at Test page 3 and Test page 4. These differ slightly from test page 1 in which element is given layout, in 3 its h1, in 4 its the anchor. Both behave as Test Page 2 - tabbing takes you to first link in body, not next link after anchor point.

Tentative conclusion from these tests. Its ok to target a link with a url fragment identifier at an anchor with an id and no name or at an id on an a non-anchor element, but for accessibility concerns with IE, the target id should be nested within an element with hasLayout.

e.g.

<div class='layout'><sometag id='destination'>...</sometag></div>

More testing is most likely required as test page 3 doesn't behave in accordance with this conclusion. The anchor tag is nested within an element which hasLayout but it doesn't respond correctly to tabbing.

----------------

What I meant about page table of contents, was that there was no set of links in the html, but that the browser could create a list of content links automatically from the anchors elements in the page.

----------------

Deprecated Diva, the test pages above all pass w3c validation. There is no content in the anchor element.

DeprecatedDiva
DeprecatedDiva's picture
Offline
Enthusiast
NW Louisiana
Last seen: 12 years 39 weeks ago
NW Louisiana
Timezone: GMT-6
Joined: 2005-06-12
Posts: 135
Points: 0

&lt;form&gt; problem, pls help!

Gads! I hate being a total newb! So much still to learn. I was just proud of myself for fixing something that was previously "broken."

That may be Lorraine. I must have previously done something wrong for it to not validate.

But it does now...

"That's my story and I'm sticking to it!"....for now Laughing out loud Laughing out loud

edited to add: I saw that Chris. Laughing out loud Now that I think about it, I am betting it's because I didn't have block level tags surrounding the anchor. Hmmm.? :roll: Laughing out loud

DeprecatedDiva

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 13 years 4 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

&lt;form&gt; problem, pls help!

Chris..S wrote:
IE's problem is not to do with using id or name or anchor elements.

I don't think I said it was. I tried to point out that your (original) test page probably wouldn't show it didn't work in IE if the anchor was at the top of the page/body.
Quote:
So if that is the <body> you are back at the beginning of the document again - I can imagine that would be extremely frustrating.

Quite so Laughing out loud
Quote:
There is no content in the anchor element.

No content passes validation, granted, but I wonder if Mr T has a point in his final para about empty anchors:
Quote:
The anchor element (a) is not empty, but contains an invisible gif. Without that (or some other text content), it turns out that visual focus doesn't work correctly.

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

Lorraine wrote:
No content passes validation, granted, but I wonder if Mr T has a point in his final para about empty anchors:

Quote:
The anchor element (a) is not empty, but contains an invisible gif. Without that (or some other text content), it turns out that visual focus doesn't work correctly.

I am not sure what is meant by visual focus, but I did check content within the anchor - there are two further test pages (5,6), where the text is nested inside the anchor. From what I could tell they behaved the same as 3 & 4 where the anchor was empty.

If I get the time I'll try to prepare a proper single test page to look at all the variations.

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 13 years 4 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

&lt;form&gt; problem, pls help!

Chris..S wrote:
I am not sure what is meant by visual focus,

Mr T wrote:
Here is how to test any in-page link:

1. Hide the mouse so you don't mess up this experiment.
2. Use the TAB key to move to the in-page link that is to be tested.
3. Press ENTER; that will reposition the visual focus on the page so that the target of the in-page link is at the top of the visual window (if there is enough of a page to refocus).
4. Now, and this is the key, press TAB again. This time the TAB key should move to the first link below the target of the in-page link. Often this is not what happens; instead this TAB puts focus on the first link of the page, or generally some other unwanted place.
For instance, open his page, TAB into it until Skip Navigation becomes visible, then ENTER. The next TAB should take you to "Keyboard Navigation and IE". The following TAB should take you to the first link within the Keyboard Navigation and IE section. Subsequent TABS should take you right through the page, including the other sections listed in the top list. It works this way because content is first in the source.

Following this through on your test pages, one would expect the first TAB and ENTER to take you to header:
<h2 id='h2' class="layout"><a id="header" name="top"></a></h2>
and the next TAB to take you to the first of the three "links" at the bottom of the page. However, you are taken back to the first "link" on the page.

Regrettably, Jim's partner in crime has shot himself in the foot rather. Select the link to Mike Cherim's experiment: http://www.greenbeastcms.com/_research/tabfocus/fixed.php
If you TAB to Navigation, ENTER and TAB again the page acts as expected. However, if you open the page again (level playing field), TAB to Content, ENTER then TAB again, you are bounced back to Navigation. Not what Mike intended I'm sure, but his page is laid out a bit err... clumsily for demonstration purposes.

However, at the bottom of Mike Cherim's page is a link to Liam McGee's site:
http://www.communis.co.uk/
TAB until Skip to Content becomes visible, ENTER. A link to Skip to Navigation becomes visible at the start of content, ENTER then TAB again and you're on the top nav bar. If you open the page afresh and ENTER when on Skip to Content, then TAB again you'll go to the News "column" which Liam has chosen to put first in the main content source. That's a bit more like it.

I reckon to give this sort of thing a good test, you may need a longer page with several individually identifiable headings on largish sections of text, so that you can readily identify where visual focus has actually landed.

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 4 years 48 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

&lt;form&gt; problem, pls help!

I thought back on page 2 that it was safe to only use IDs, but now I'm not sure again. Did we reach a consensus on this or not?

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 4 years 48 weeks ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

&lt;form&gt; problem, pls help!

Lorraine wrote:
However, at the bottom of Mike Cherim's page is a link to Liam McGee's site:
http://www.communis.co.uk/

A question also about this site: tabbing through the links makes the dropdowns appear as you tab through the submenus. Their menu uses javascript but can the same thing be achieved using a CSS approach like with the Suckerfish dropdowns?

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

Ok, I get visual focus. It was a terminology thing. Never in IE did visual focus not shift. But as you and Jim point out the problem is where keyboard (& visual) focus goes on the next tab / shift-tab after activating an in-page link with the keyboard.

My test pages should be long enough. The link targets are now towards the centre of the page. If you still see everything on the one screen, narrow your browser window. All the test pages, bar the first page exhibit the buggy behaviour described by Jim. The first page has his fix and it does go away.

Tyssen wrote:
I thought back on page 2 that it was safe to only use IDs, but now I'm not sure again. Did we reach a consensus on this or not?

It should be safe to only use IDs - but ensure your intended audience isn't using navigator 4, IE4 or similar.

There is a problem with IE and in-page links that happens irrespective of whether the targets of those links are names on anchors, ids on anchors or ids on other elements.

For the id or anchor name to be keyboard accessible in IE it should be nested within an element that hasLayout, details are given in Jim's article. The only issue is with two of my test pages, (3 & 5, which have the fix on the anchors yet the fix doesn't appear to work.

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 13 years 4 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

&lt;form&gt; problem, pls help!

Thatcher wrote:
This is the coding for a typical target.
<div style="width:0%;height:0px;">
or hasLayout by any other means
<a name="maincontent" id="maincontent">
<img src="\images\1-pix.gif" width="0" height="0" alt="" />
or text/something within the anchor
</a>
</div>

Chris
It's target of the links that needs the jiggery-pokery. Your test page 1, which works as expected, has a target being the h2 coded thus:
<div class="layout"><h2 id='h2'><a id="header" name="top"></a>&ldiv class="layout"&gt;&lt;h2 id='h2'&gt;&lt;a id="header" name="top"&gt;&lt;/a&gt;&lt;/h2&gt;&lt;/div&gt;</h2></div>
From what I can see (I only looked at four of them) the h2 on the other pages has not been so privileged. On the other pages hasLayout resides in <body>(page 2) or h2 does not reside within its own div (pages 3/5/6). I *think* a div sandwich is required as a substitute for the table technique at the start of Jim's article. Quirkly, it also seems that <div class="layout"> does the trick by itself because h2 has an empty anchor Smile

PS Not too sure about id="header" name="top" though and FF HTML Tidy issues two warnings about page 1 in h2, an unescaped ampersand and "<a> id and name attribute value mismatch" Wink

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 35 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

&lt;form&gt; problem, pls help!

At some point would one of you two like to draw up an easy to read conclusion to this discussion as it's becoming v.difficult to follow and mildly confusing to many I would think.

P.S Lorraine I thought you weren't in to theory Wink

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

Lorraine wrote:
From what I can see (I only looked at four of them) the h2 on the other pages has not been so privileged. On the other pages hasLayout resides in <body>(page 2) or h2 does not reside within its own div (pages 3/5/6). I *think* a div sandwich is required as a substitute for the table technique at the start of Jim's article. Quirkly, it also seems that <div class="layout"> does the trick by itself because h2 has an empty anchor Smile

Exactly!

I don't mind that they are failing. Smile

On 3 & 5, according to my reading of Jim's theory, the h2 link should fail (and it does) but the anchor links shouldn't fail as they reside within the h2 element which hasLayout - but the anchor links do fail (content within the element doesn't seem to matter as one has content and the other doesn't).

Hugo, I'll draw something up when I have figured it out, in the meantime if someone else has figured it out, pls post away Laughing out loud

roytheboy
roytheboy's picture
Offline
Guru
North Wales, UK
Last seen: 6 years 7 weeks ago
North Wales, UK
Timezone: GMT+1
Joined: 2004-09-18
Posts: 2233
Points: 41

&lt;form&gt; problem, pls help!

Hugo wrote:
At some point would one of you two like to draw up an easy to read conclusion to this discussion as it's becoming v.difficult to follow and mildly confusing to many I would think.

...you read my mind Hugo Laughing out loud What a monster thread rogermkrm has started! ...but this is why I love this forum so much; because people are more concerned about getting things right than about proving themselves right. If only all forums were like this one: low on egos and high on quality Smile

Life's a b*tch and then you die!

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 13 years 4 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

&lt;form&gt; problem, pls help!

Chris
Methinks your eye is alighting only on that which proves what you are saying.
In my view, on the pages that don't work it is 'cos the target ain't within a div (never mind your empty anchor bit).

Please, do me one favour: take the code that works on page 1
<div class="layout"><h2 id='h2'><a id="header" name="top"></a>&ldiv class="layout"&gt;&lt;h2 id='h2'&gt;&lt;a id="header" name="top"&gt;&lt;/a&gt;&lt;/h2&gt;&lt;/div&gt;</h2></div>
Copy it into one of the "failing" pages to replace the h2 target and check how it behaves.
It should take you less time than it took me to test pages 2/3/5/6 to prove what I was saying (at least to me) before I made my post. Although I did wonder if just the "empty anchor" comment would rise to the top.

Hugo
This ain't theory. Call it attention to *all* the detail, if you like - or even a mindset that tries to prove rather than disprove when doing the practical activity that is only code debugging after all.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 35 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

&lt;form&gt; problem, pls help!

I was going to throw using tab indexes into the melting pot as a means of perhaps establishing some order with IE and it's never ending uselessness, when I found this piece by Gez Lemon which discusses this possibility:

http://juicystudio.com/article/ie-keyboard-navigation.php
Just for theorys sake of course Wink

This discussion has really devolved into a subset of the original somewhat off tangent discussion of whether one should/can use 'ID' over 'Name' and whether one should use an anchor element or just target an element ID to the problems bloody IE (the accessibility browser) manages to throw up which is fine and needs airing and if possible a way of dealing with mooted but it would be nice to draw a line under the first point of discussion to keep things clear.

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 13 years 4 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

&lt;form&gt; problem, pls help!

Hugo wrote:
I was going to throw using tab indexes into the melting pot ... when I found this piece by Gez Lemon which discusses this possibility:

Well they do say great minds think alike and at almost the same time too.
I *can* do theory, theoretically, of course.

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

&lt;form&gt; problem, pls help!

Well spotted Hugo. After all that effort a simple elegant solution Smile

I think that should make the ultimate conclusion:

Quote:
With regard to internal page navigation:
  • destinations can be ids on any elements (refer IE techniques 1 & 2).
  • you don't need to use <a> anchors* (refer IE technique 2) but it may be simpler to use an anchor rather than IE technique 1 on a pre-existing element.
  • you don't need to use the name attribute*
IE Techniques - used to overcome the bugginess of IE's keyboard navigation
  1. Ensure the element is near the top (above any elements that can receive keyboard focus) of a containing element of type body, div, span, table, tr, td and which hasLayout or is itself an element of one of those types and hasLayout.
  2. Give the destination element a tabindex. If the element should not be in the actual tab order then give it a tabindex value of -1 (e.g. tabindex='-1'). Be aware that this may cause validation problems. Not all elements may have a tabindex attribute (A, AREA, BUTTON, INPUT, OBJECT, SELECT, TEXTAREA can) and not all doctypes recognise '-1' as a valid value, XHTML1 does, HTML4 doesn't.
The above may not apply to early model browsers (e.g. IE3, NN3) which do not understand id. Always determine who your audience will be and test your web pages in the environments your audience will be using.

* this isn't meant to imply you can't use these or that it is wrong to use them, just that it is probably not necessary.

reference: http://juicystudio.com/article/ie-keyboard-navigation.php
test page: http://wiki.jalakai.co.uk/css-demos/ie-keyboard-navigation

For anyone interested, you can try all this stuff at the final version of my test page.

Putting aside the elegant tabindex solution described above, fwiw:

In IE, after navigating using the keyboard to an intra-page destination, IE moves keyboard focus to the top of the nearest containing element (incl. the element itself) which hasLayout AND is one of, body, div, span, table, tr, th, td. Of these, body, table & td automatically have layout. I haven't exhaustively tested all elements, just many :?

[/][/]
Electric
Offline
Regular
Last seen: 14 years 9 weeks ago
Joined: 2005-07-15
Posts: 50
Points: 0

&lt;form&gt; problem, pls help!

with your javascript use document.getElementById('form_name').field_name.value

this will get you around it Smile

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 35 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

&lt;form&gt; problem, pls help!

Nice summation Chris, I think that covers things pretty well , one small point (and I'll have to re-visit the juicy studio piece) but did I read correctly that in actual fact the XHTML DTD is wrong in it's allowance of a negative value as the DTD allows for generic cdata values rather than actual numeric values, although whether this is relevant if it passes validation (as it would) is another matter.

Now if you could just exhaustively test every element rather than some flimsy claim to have tested many your job will be done Smile

Edit: Ah ok, have just looked at your revised testcase page, very nice elegant looking bit of work Chris, can I make one small suggestion , that perhaps it would be better if you could write up the explanation of the test case in English rather than Latin, as my Latin is appalling.

Hugo.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

roytheboy
roytheboy's picture
Offline
Guru
North Wales, UK
Last seen: 6 years 7 weeks ago
North Wales, UK
Timezone: GMT+1
Joined: 2004-09-18
Posts: 2233
Points: 41

&lt;form&gt; problem, pls help!

Hugo wrote:
can I make one small suggestion , that perhaps it would be better if you could write up the explanation of the test case in English rather than Latin, as my Latin is appalling.

Laughing out loud =D>

Life's a b*tch and then you die!

Lorraine
Lorraine's picture
Offline
Elder
UK
Last seen: 13 years 4 weeks ago
UK
Timezone: GMT+1
Joined: 2005-01-04
Posts: 1001
Points: 0

&lt;form&gt; problem, pls help!

Elegant test page Chris. Smile
Sorry I doubted your motives.
I see the debate now moves (back) to href and (on) to tabindex.
I think I'll just avoid in-page links like the plague - with the exception of "href-ed skips" of course. Wink
Cheers
Lorraine

Anyone interested can find an English version of the Latin text here:
http://beta-154104.server1.dotnetsandbox.net/scroll.aspx
on this thread yer:
http://www.csscreator.com/css-forum/ftopic11436.html&highlight=
Warning- slightly adult content. Tongue

rogermakrm2006
Offline
Regular
Last seen: 14 years 4 weeks ago
Joined: 2005-08-15
Posts: 29
Points: 0

it works everybody

Hey Guys:

Thanks alot for your helps! it works

i changed name to id firstly

<form id="orderform" action="http://tl28serv.uws.edu.au/iwsdinfo/form.asp" method="post" enctype="application/x-www-form-urlencoded">

secondly i used this to access elements inside the form

eg.

total = total + parseFloat(document.getElementById('orderform').fishertotal.value);

and guess what , no more errors..hehe
thanks alot! this is an awesome forum.

From roger =D

rogermakrm2006
Offline
Regular
Last seen: 14 years 4 weeks ago
Joined: 2005-08-15
Posts: 29
Points: 0

weird w3c validations errors, please help! Thank you!

Hello Helpers:

i don't know the rules here much, but i didn't want to post this as a new topic...so i decided to post a reply here, but these are new weird errors i have from w3c....they seem to all work but w3c doesnt like them... : <
i keep getting this error from w3c but i don't see a problem with it and most of all, it works..but w3c (so fussy) has rejected it:

Problem 1:
========

Error Line 687 column 65: value of attribute "disabled" cannot be "true"; must be one of "disabled".

<input type="text" name="vegetotal" size="10" disabled="true" />

Problem 2:
=======
Error Line 779 column 14: there is no attribute "name".

<img name="couponerror" src="blankimage.gif" width="350" height="10" border=

Problem 3:
========
Error Line 779 column 80: there is no attribute "border".

<img name="couponerror" src="blankimage.gif" width="350" height="10" border="0" alt="for error image" />

issue 4:
=====
for the reason included name attribute within the img tag is because, i have used a function in javascript to display different gifs when errors occurs ...and my function looks like this

//functions for calculations
function showImage(imagename, imageurl, errors) {
document[imagename].src = imageurl;
}

and so when i call this function, say to display a different gif and "coupon error"....it will look like this

showImage("couponerror", "couponerror.gif", true);

it works fine .....but w3c doesn't like it....

i have tried replacing the name with id...but it doesn't work at all.

i just want to disable a text box, and w3c dosen't like it...

got any ideas? please help!
sorry, my questions are so so so OFF TOPIC here
thanks alot!
From roger

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 6 years 51 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

Re: weird w3c validations errors, please help! Thank you!

rogermakrm2006 wrote:
i keep getting this error from w3c but i don't see a problem with it and most of all, it works..but w3c (so fussy) has rejected it:

You could try a less restrictive doctype, perhaps xhtml-transitional.

For your validations errors the explanation included with the error pretty well says it all. As we mentioned at the start of this thread, name has been deprecated from all elements bar form controls. You should use id instead. In your javascript use document.getElementById("the_id").

Problem 1:
========

<input type="text" name="vegetotal" size="10" disabled="disabled" />

Problem 2:
=======

<img id="couponerror" src="blankimage.gif" width="350" height="10"

Problem 3:
========
Error Line 779 column 80: there is no attribute "border".

Set the border in CSS or use style="border:...;"

issue 4:
=====

//functions for calculations
function showImage(imageid, imageurl, errors) {
document.getElementById(imageid).src = imageurl;
}

Mike Cherim
Mike Cherim's picture
Offline
Enthusiast
Nottingham NH
Last seen: 12 years 30 weeks ago
Nottingham NH
Joined: 2005-08-26
Posts: 126
Points: 0

&lt;form&gt; problem, pls help!

Lorraine wrote:
[...]Regrettably, Jim's partner in crime has shot himself in the foot rather. Select the link to Mike Cherim's experiment: http://www.greenbeastcms.com/_research/tabfocus/fixed.php
If you TAB to Navigation, ENTER and TAB again the page acts as expected. However, if you open the page again (level playing field), TAB to Content, ENTER then TAB again, you are bounced back to Navigation. Not what Mike intended I'm sure, but his page is laid out a bit err... clumsily for demonstration purposes.[...]

Hello all, nice to meet you.

First post here. I Google myself now and then to see what's happening in the world that involves me. Usually I find some interesting stuff, and today is no exception. Wink

I read this thread and just wanted to clarify that the three pages I created for Jim and Liam (linked in the quote) have two purposes and I'd like to apologize if they aren't clear on their own. Obviously I failed on that end.

1) They were made for the purpose of trying to determine what fails and what doesn't. These were learning pages and they were changed several times during the day in which they were built.

2) They are meant to have tab failures in IE as the second reason for their existence. The purpose being to allow people to experiment with different tabbing methods, different widths, and different bookmark types to determine for themselves which ones work and which ones don't on their browser. As designed, you'll find that the only tab-target to work correctly in IE by maintaining focus in the right place is the Navigation one as that's the only one in its own parent div (with the hasLayout property -- width).

3) As far as the clumsy thing, perhaps. I was shifting gears as I was making them so that is likely. They are pretty simple, though. Just three pages with a box (Nav) floated in each one. Clumsy or not, hopefully they serve their intended purpose.

Anyway, nice to meet you folks. I didn't know about this forum but I do now. I'll put it on my favorites list and stop back to check it out more.

Sincerely,
Mike Cherim