[web] CSS and Firefox problem

Remove the clear: both from div.FormRow and find some other way of making the dasked box contain the form.

When in doubt, IE is wrong and FireFox is right.

Quote:

Original post by Sander Remove the clear: both from div.FormRow and find some other way of making the dasked box contain the form. When in doubt, IE is wrong and FireFox is right.

lol, so true.

I managed to get the page looking a bit better! And it works on both Firefox and IE! I had to explicitly set the height of the rows so that the labels would line up with their controls. Is that okay, or is that a dirty hack? Will it always work? Are there any other problems with the way I'm doing this?

Quote:

Original post by BradDaBug I managed to get the page looking a bit better! And it works on both Firefox and IE! I had to explicitly set the height of the rows so that the labels would line up with their controls. Is that okay, or is that a dirty hack? Will it always work? Are there any other problems with the way I'm doing this?

I normally only use tables when I need a tabular layout, such as a calendar. The only other time I use a table is when I have a form that is in the layout that you have, where the label, or title, for the form items is to the left. If you maintain the current layout, I recommend using tables as it will save a lot of hassle (a lot).

If you want to try a different approach:


This way you can still define the layout, somewhat, with CSS, but generally, at least this is what I've seen and am used to, form layout should be simple and not require a lot of styling, unless there is something special to the form.

And for your method, it seems fine but not entirely necessary. It doesn't appear to be any hack, though I'm not CSS expert.

Another note, more of a tip: You can also condense your CSS a little with attributes such as padding and margin, by defining top, right, bottom, and left (in that order) behing the attribute:

Quote:

When in doubt, IE is wrong and FireFox is right.

And as a side note, even the IE 7 RC has it wrong.

Quote:

Original post by Sander Remove the clear: both from div.FormRow and find some other way of making the dasked box contain the form. When in doubt, IE is wrong and FireFox is right.

When following CSS, maybe. When following the underlying html standard, not so much. Try this:

<b<i>test</i></b>

Internet Explorer: Correct Behavoir
Opera: Correct Behavoir
Mozilla and Firefox: Most incorrect behavoir possible

Quote:

And as a side note, even the IE 7 RC has it wrong.

No surprise there! [grin]

Quote:

Mozilla and Firefox: Most incorrect behavoir possible

That is a surprise. Did you file a bug about that?

Hey, it fixed my lack of a close tag on the b for me. That was a little strange.

Quote:

Original post by Sander Quote: And as a side note, even the IE 7 RC has it wrong. No surprise there! [grin] Quote: Mozilla and Firefox: Most incorrect behavoir possible That is a surprise. Did you file a bug about that?

Maybe I missed something.

Quote:

Original post by tstrimp Maybe I missed something.

Yep you did [smile]
Note the opening bold tag in Michalson's post doesn't have a ">". It is just "<b"

Quote:

Original post by tstrimp Quote: Original post by Sander Quote: And as a side note, even the IE 7 RC has it wrong. No surprise there! [grin] Quote: Mozilla and Firefox: Most incorrect behavoir possible That is a surprise. Did you file a bug about that? Maybe I missed something.

You miss typed the source code. Go back to my post and read it more carefully.

<b<i>test</b></i>

Under the most basic principles of the HTML standard, a tag starts with a < character followed by an ASCII letter (comments are slightly different, and frankly no browser follows the original specification for them). From there HTML identifers can contain ASCII letters, numbers, dashes, underlines and periods. An HTML identifer can be terminated either by whitespace, or a > character. With attributes you can also end the identifer with a "=". If an invalid character is used, the identifer is still considered an identifer, but one with an invalid character.

There are four ways the HTML fragment I provided could be parsed, ranging from most correct to most incorrect.

The most correct is to see that the "b" tag is not a known tag (the name of the tag contains an invalid character, <), and then see that the "i" tag isn't a tag at all because it's just noise inside another tag. The result is that neither the italic nor bold attribute is set: test.

A less correct interpretation would be to correctly interpret the "b" tag as badly named, but then go back assume that the < itself was erroneous - a < followed by whitespace can be considered a non-intentional (erroneous) tag start, in which case it is processed as plain text (for example try the source code "< test>" - you'll see it rendered as a plaintext, rather then being interpretted as a tag). In this slightly less correct interpretation the "i" tag would then become legal because it is not inside another tag. The result would be test. This kind of interpretation would indicate an overly

An even less correct interpretation would be to consider the second < to be a valid whitespace /end character (most likely due to an oversight in the source code where both < and > are treated the same), and thus make the "b[illegal character]" tag be seen as a "b" tag. The "i" tag would be still be invalid, as it is just noise inside the b tag. The result would be test

Lastly, the most incorrect way possible would be to not only make "b[illegal character]" into a "b" tag, but also interpret the "i" tag, despite the fact that it is inside the supposed "b" tag. Such an interpretation would show that the parser itself was fundimentally flawed - that a proof of concept parser bashd out overnight was still being used in a final product. The completely incorrect result of course would be test

Do the HTML specifications say what to do? If not, it's undefined behavior and no interpretation is more correct than another. You'd then be at the mercy of how the parser was written. You can quibble over what makes the most sense, but at the end of the day it's still an arbitrary decision. It would be like asking what should a C compiler do with the following code:

int x float y;

Quote:

The completely incorrect result of course would be ...

While I agree with you on a technical nature, I disagree on a practical level. It's obvious in that situation with two valid tags that are both then closed what the author meant to do. So now you have a choice to make: should you interpret an error on a "on error resume next" approach or a "best guess" approach. (Personally, if I were writing a browser, I'd take the former approach [IE's in this case] because it would seemingly be a lot easier to do...)

Obviously if the HTML standard does say what to do in such a case (and I don't know about this particular example) and a browser doesn't follow, the above doesn't apply and it is a bug.

Really, the most correct thing to do is flag a parsing error, but unfortunately the first web browsers didn't do that, and now the web is so messy it would be impossible to surf like that.

Well, you seem to have raised a valid point. While some sources say it is not allowed at all in the HTML subset, I have found some that say recognizing SGML SHORTTAG constructs is only, quote "strong discouraged" in HTML parsers, rather then completely banned.

Of course that opens up a whole new discussion. It would seem, if we are too assume that this is intentional behavior (rather then just ignoring the entire SGML basis of HTML and making some half-assed parser), that the Mozilla/FireFox team has gone to the trouble of implementing perhaps the most obscure and rarely used part of SGML (even most SGML parsers skip over it because it doesn't actually do anything new, it just repeats existing functionality with fewer letters in an entirely unreadable fashion. For example the popular open source lib-perl project lists the SHORTTAG features under, quote "SGML FEATURES WE WILL PROBABLY IGNORE FOREVER"[emphasis theirs]).

Why don't we take a look at this implimentation of a SHORTTAG parser in FireFox.

We've already seen that FireFox appears to understand unclosed tags. Lets confirm that:

First, a more complex usage. Maybe understanding just one additional tag was a bug?

<b<i<strike>test</strike></i></b>

Nope, this produces the correct SGML behavior: test

Now let's try the other end:

<b><i>test</i/b>test

This should produce this testtest if SGML closed tags are being implemented, but it actually produces this: testtest

That's very strange. Why would the Mozilla team go to the trouble of implementing half of the closed tag feature? Maybe there is a bug. Lets go check out the other SHORTTAG features – if the Mozilla team has decided to include the SHORTTAG extension intentionally, the rest should be there.

SHORTTAG Empty [start/end] tags:

<ul>
<li>First item
<>Second item
<>Third item
</ul>

This should produce a list of three items with a bullet point in front of each one if SHORTTAG functionality exists (the empty [start/end] tags are assumed to be the same as the last full [start/end] tag encountered). What does Mozilla do?

• First item <>Second item <>Third item

Strange, it doesn't work. What's wrong with Mozilla's SHORTTAG support? Well, we've got one last feature to test, null end tags.

Null end tags mean we should be able to use a non-identifer, non html-character (the suggested one is "/") immediately following a tag name. The result is as if the tag had been terminated. As soon as that character is encountered again, it should be interpreted as a closing tag.

For example <b> bold </b> could be written as <b/ bold /

What does Mozilla/FireFox produce: (blank)

So there we have it. Half of a SHORTTAG construct supported, the rest not. So either the Mozilla team intended to support a rarely used feature of SGML, but got it horribly wrong, or they just ignored the standard entirely, and arrived at the functionality by accident, because the Mozilla parser isn't using the SGML (HTML) lexical rules its supposed to be, it's just doing a blind search for "<".

On a hunch I just checked something:

<b <i>test</i></b>

Under Mozilla this again produces the test behavoir.

Under SGML, and subsequently HTML, that is not a recognized tag construct (this "<xxx <yyy>" possiblity is explicitly highlighted by SGML documents). Under the HTML/SGML standards there are only two interpretations - under strict SGML the whole thing is considered not a tag, and under relaxed HTML it is considered a b tag with noise inside it.

<xxx<yyy> is explicitly identified in standards documents as a special construct covered under the SHORTTAG feature extension, and is clearly not fully implimented in FireFox, nor are the rest of the SHORTTAG extensions.

<xxx <yyy> is explicitly identified in standards documents as an invalid tag construction.

I doubt that mozilla implemented half a shorttag feature. It's just a result of their engine dealing with bad HTML. Any resemblance to a shorttag implementation is purely accidental :-)

Quote:

Original post by Michalson It would seem, if we are too assume that this is intentional behavior (rather then just ignoring the entire SGML basis of HTML and making some half-assed parser), that the Mozilla/FireFox team has gone to the trouble of implementing perhaps the most obscure and rarely used part of SGML ...

The real problem is that the HTML4 parsing algorithm is underspecified, and so you can't say one browser is wrong. (Nobody uses SGML, particularly to parse a web full of tag-soup, so the HTML spec doesn't pretend that user agents should be full SGML parsers.)
XHTML avoids that by forcing a strict (and more verbose) syntax, and 'HTML5' fixes it by specifying the behaviour of the parser (which, as far as I can tell, follows Gecko's behaviour in that a '<' in the middle of a tag name forces that tag to be emitted as if there was a '>').

Firefox gives the expected results for these tests, and Opera and IE give another two different results. And the Mozilla developers believe they're following the spec as much as possible.

In any case, IE might appear to give the result you expect, but it's horrid underneath: try your code in the DOM viewer. Given the input

<!DOCTYPE html><b<i>Hello</i></b>

Firefox outputs

DOCTYPE: htmlHTML  HEAD  BODY    B      I        #text: Hello

and Opera outputs

HTML  BODY    b <i=""      #text: Hello

and IE outputs

#comment: CTYPE htB<IHTML  HEAD    TITLE  BODY    #text: Hello    /I    /B

So Opera thinks that the 'i' is an empty attribute on the 'b' tag. (Note that 'b' is different to the 'B' (bold) tag, and so it doesn't give the output in bold).
IE decides that you really intended to have some empty tags called 'B<I', '/I' and '/B', one of which is moved to the front of the entire document before the implied <html>. (Also note what it does to the DOCTYPE line...)

It's only luck that the visible output in IE and Opera is what you seem to expect, with no bold or italics surviving the mangling. Firefox simply acts as if you forgot to add the closing angle bracket. Still think Firefox has the most broken parser? [smile]

(NB: I mostly use Opera, so I'm hopefully not defending Firefox out of fanboyism...)

FYI: I tried the code in FireFox 1.5 with various doctypes and with or without wrapping it in a proper html/body tag set. It makes no difference at all. FireFox adds the closing tag for you. That's fine by me, but I think that a parsing error should be given for XHTML1.1 strict.

Quote:

Original post by Sander I think that a parsing error should be given for XHTML1.1 strict.

The XHTML doctype doesn't make it XHTML – you have to send the data with a content-type like application/xhtml+xml to get that (or, in IE's case, to get a useless download dialog), and otherwise it's just parsed as HTML tag soup (and is considered harmful). That DOM viewer treats its contents as text/html, so you can't give it proper XHTML and get the right error messages.

In Firefox, you can test the difference easily by saving an XHTML document on your local disk as something.html and as something.xhtml – it complains about XML syntax errors in the .xhtml but not the .html version, because it assumes different content-types for the files. Or compare this page and this one (in anything except IE), where the second results in "XML Parsing Error: no element found" as expected.