weired repeating of fieldset border in ie (6 AND 7)

[ToonMariner]

ok have a look at these two images.

 

The first is my registration form the second is that form being submitted and errors in the users input detecting with info about the error being displayed beneath the relevant field.

 

http://www.imagebin.eu/pics/d524388dd23fd8a7bb6597f17e48b382.gif

 

http://www.imagebin.eu/pics/ae11bce68e33f623e0c272ac55afe254.gif

 

the only difference in the html is that in the second case a <p class="error"> tag is present...

 

If anyone has experienced anything like this before I would really appreciate some ideas as to why it happens and if possible how to stop it...

[haku]

Links? Hard to say what the difference is without seeing it live.

[ToonMariner]

http://www.quest4fame.com/register

 

 

[haku]

I just looked at that for about 20 minutes and my verdict is...

 

I have no clue whatsoever. 

 

Seriously, that's a weird one! Never seen anything like it, couldn't figure out what it was.

 

Do you have the IE web developer toolbar? I used it and couldn't find the problem but maybe you can do better than I.

[ToonMariner]

#bump#

 

Do you think I should email the link to the IE staff?

[haku]

I never thought about that. Maybe, it can't hurt. Although I would be somewhat surprised if they got back to you, because then everyone would be mailing them links to things they cannot get to work!

 

But still, it can't hurt. Definitely a strange bug.

 

Maybe try validating the code on your page first. I looked at the errors, and I didn't see how they would be causing the troubles you are having, but its not impossible.

[dbrimlow]

This is why using an XHTML is dangerous (particularly XHTML 1.1).

 

you are using the mime-type:

 

<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" />

 

Under no circumstances does any IE understand what that means.

 

I assume you may be using a php browser sniffer for IE? To change the mime-type to "text/html" for IE?

 

Still doesn't work. You have some serious errors in the mime-type (could be the server is not configured to serve "application/xhtml+xml").

 

It is auto defaulting to "text/html" and causing invalidation.

 

Also, your form fields are not valid - particularly for any strict doctype which xhtml 1.1 is.

 

Fieldsets, legends, select and input elements can be styled (somewhat) when semantically wrapped in a logical block level element ... like paragraph, header, list.

 

Here is an example from a site of mine using a valid xhtml1.0 strict ("text/html") doctype (some customers want to see XHTML thinking it means we are better coders, so give it to them, but serve it as text/html and ALWAYS XHTML 1.0):

 

<ul>
      <li>
<fieldset>
         <legend>AREA</legend>
         <select name="sect" size="1" id="label">
         <option value="ALL" selected="selected">All Areas</option>
         <option value="UPPER EASTSIDE">Upper East Side</option>
         <option value="UPPER WESTSIDE">Upper West Side</option>
         <option value="DOWNTOWN">Downtown</option>
         <option value="MIDTOWN EAST">Midtown East</option>
         <option value="MIDTOWN WEST">Midtown West</option>
         <option value="UPPER MANHATTAN">Upper Manhattan</option>
      </select>
      </fieldset>
      </li>
      </ul>

 

But get a handle on your doctype and validation. If it is invalid, you can't trust any cross-browser compatibility.

[haku]

I've been thinking about something lately. What if you used conditional contents to serve the mimetype as "application/xhtml+xml"  for browsers that accept it, and as "text/html" for IE. Are there any drawbacks to this? It gives the maximum it can to each browser.

[dbrimlow]

I don't see why that wouldn't work. There are also php sniffers for browsers that some people use. But if you do, DON'T use XHTML 1.1, use XHTML 1.0.

 

The W3C says that XHTML 1.1 "SHOULD NOT" be served as "text/html", while XHTML 1.0 "MAY" be  served with that mime-type.

 

But the main point is ... why?

 

If you aren't parsing XML then there is no reason to use XHTML in the first place. All it does is serve it using HTML 4.01 specs (with a closing slash for unclosed single elements like breaks, img, hr).

 

In HTML 4.01, you can still use all the same strict coding syntax, well-formedness, lower case, closing paired tags, etc. as XHTML (without the closing slash for unclosed single elements).

 

So what's the point of using XHTML?

 

Like I said, some clients who don't know better, think a coder is more advanced if they use XHTML. When in essence what they are really asking for is standards compliant, valid, clean, uncluttered, non-tag soup, proper semantic structured, non-transitional doctype with CSS styled code.

 

And for that, all that is needed is HTML 4.01 STRICT. Any coder who uses a transitional doctype is either lazy or has a client who insists on features that are not allowed in HTML 4.01 Strict - like "target=", "embed" and other deprecated elements.

 

TM was trying to do the right thing with the mime-type. But he still has validation issues. XHTML 1.1 is really unforgiving. It is a strict doctype by default. And IE will render any XHTML that is not valid as quirks mode.

 

While IE 8 is supposedly going to be 100% Acid tested CSS2 spec compliant, Microsoft has (so far) been avoiding even responding to any questions about whether it will support application/xhtml+xml or not.

[dbrimlow]

Actually, I forgot the most important aspect of why TMs document is failing doctype validation in all browsers.

 

XHTML 1.1 needs an xml declaration if the charset is other than the default of UTF-8 or UTF-16:

 

<?xml version="1.0" encoding="UTF-8" ?> (version 1.0 is used here even in xhtml 1.1)

 

From the w3c:

Note that in this example, the XML declaration is included. An XML declaration like the one above is not required in all XML documents. XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16.

 

TM can try changing his charset to UTF-8 to see if that validates, but then it isn't an xml parsed document, so it may not.

[ToonMariner]

Thanks for some of the suggestiosn guys but unfortunately to no avail....

 

This does look like a bug of some sort for the time being I have had to give the p tag a negative left margin, left padding, a border and a background colour to get it somewhere near...

 

I am away to find an email address for Tantek Celik - see if he can find out why this happens...

 

Now if this is a bug - what can I call it?

 

The Toon bug will provide fame but not descriptive enough...

 

[dbrimlow]

TM, it isn't a bug. If it looks and acts like float clearing issues ... it is.

 

If you float it ... clear it. You "form labels are floated but not clearing. This causes the frameset line to ride up in a classic case of non-cleared floated elements.

 

I noticed that your IE7 float clears are not complete; you left out what makes it work ... the :first-child pseudo element.

Using *+html is not enough and doesn't do anything. You need to change it to: * :first-child + html.

 

You also need to add floated form fields to your clearing scheme.

 

/*Clearing for IE7 only*/

*+html div#mediaactions {min-height:1px;}

 

/*Clearing for IE7 only*/

*+html #ajaxapp {min-height:1px;}

[ToonMariner]

Jesus H....

 

completely missed that...

 

sorry dbrim its a case of woods and trees for me - I'll make the amends this evening...

 

feel foolish now...

[dbrimlow]

feel foolish now

 

Now?  I feel foolish at LEAST 4 or 5 times a day!