Close tags should be generated for <tag/> only in strict mode

VERIFIED DUPLICATE of bug 84633

Status

()

Core
HTML: Parser
VERIFIED DUPLICATE of bug 84633
17 years ago
17 years ago

People

(Reporter: Harshal Pradhan, Assigned: harishd)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
Currently the parser adds a </tag> for <tag/> unconditionally. This is not
correct. It should only do so in strict mode.
(Reporter)

Comment 1

17 years ago
Created attachment 62339 [details]
small test case

In this test case the options are not populated in the drop down because of
this problem

Changing 
<option value="one" />Select one
<option value="2001" selected />2001

To 
<option value="one" >Select one
<option value="2001" selected >2001

in the test case makes the options appear.
validator.w3.org does not seem to have any objections to the this testcase.
(Reporter)

Comment 2

17 years ago
>validator.w3.org does not seem to have any objections to the this testcase.

I meant that for quirks DTD's of course.

(Reporter)

Comment 3

17 years ago
Created attachment 62340 [details] [diff] [review]
proposed fix

Simple fix that checks for strict mode before adding </tag>
That's XHTML empty-tag syntax.  <option> is not an empty element (but the end
tag may be left off, per OMITTAG).  Remove the slashes, and you should really
avoid that syntax, anyway, unless you're using XHTML.  WONTFIX.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
This should have been marked invalid, but I'll verify this.

Reporter, please make sure you understand the spec next time.  The proper way to
do  OPTIONs in XHTML is

<select name="foo">
 <option value="bar">Bar</option>
 ...
</select>

Your testcase was doing this:

<select name="foo">
 <option value="bar"></option>Bar
 ...
</select>

Thus we were correct in having empty options.  See
http://www.w3.org/TR/html401/interact/forms.html#edef-OPTION
Status: RESOLVED → VERIFIED
(Reporter)

Comment 6

17 years ago
Don't get me wrong.....
I am certainly not arguing that this markup is correct. Its certainly not 
correct XHTML and it should certainly not work in strct mode (either xhtml or 
html-strict) I have already stated that this is a quirks-only thing.

But the point is, that if you look at the code that my patch addressed and 
comments by rickg over there (and bugs they referance) then it will be apparent 
that this code was written for strict mode. It was never meant for quirks.

I believe that the patch makes the code actually work as was intended. The 
patch also would make us a bit more robust about wrongly used empty tags in 
quirks mode.

And no ... this html is not mine. I noticed it on ibm.com and they corrected it 
promptly when contacted, so I cant show it to you. 

But... just for fun, I passed it through validator.w3.org. I was actually 
surprised to see that the parse-tree that it gave me for HTML4.01-Transitional. 
Please have a look:

http://validator.w3.org/check?uri=http%3A%2F%2Fbugzilla.mozilla.org%
2Fattachment.cgi%3Fid%3D62339%26action%3Dview&charset=%28detect+automatically%
29&doctype=HTML+4.01+Transitional&sp=

(Sorry for the truncated url, but bugzilla wraps it)

So we are being robust in a way that w3c want us to be. On this basis, I still 
think that the patch is justified. Can you please give it a little more thought 
and one more consideration.

Thanks.
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---
Ah.  Your patch may be correct after all, it's just tangled up with the issues in bug 94284.  Unfortunately, I don't have the time to completely sort things out right now.  FWIW, I generally dislike making quirks mode more "robust" at this stage of the game,as all it really does is encourage perpetuation of bad markup...perhaps harishd can tell you whether or not we should be doing this piece of fixup.
(Reporter)

Comment 8

17 years ago
Thanks for the pointer to bug #94284.
After looking at bug #84633 (that is referenced in that bug), I realize that 
this is a dup of that.

But then validator is misleading me ... hmmm ... probably I should go and tell 
them that.

*** This bug has been marked as a duplicate of 84633 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 9

17 years ago
Verified duplicate of 84633

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.