I can't remember where I learned HTML, but I remember that there is no
</OPTION> tag in HTML (but browsers don't care if you have them)
I've discovered that I sometimes get blank entries in my <SELECT>
controls, even though none of the <OPTION>'s are blank. This happens
with the current Opera browser (and back quite a few releases).
The workaround is to add the un-necessary, and possible illegal
</OPTION> tags.
Presumably this is a problem that I should report to Opera, but I
thought I'd check my facts first.
In article <j6k2q79ihed6srqhqvkp4c7copob4lm...@4ax.com>,
Swifty <steve.j.sw...@gmail.com> wrote:
> I can't remember where I learned HTML, but I remember that there is no
> </OPTION> tag in HTML (but browsers don't care if you have them)
> I've discovered that I sometimes get blank entries in my <SELECT>
> controls, even though none of the <OPTION>'s are blank. This happens
> with the current Opera browser (and back quite a few releases).
> The workaround is to add the un-necessary, and possible illegal
> </OPTION> tags.
> Presumably this is a problem that I should report to Opera, but I
> thought I'd check my facts first.
You've got it backwards. </OPTION> is legal, but optional in some contexts.
An option element's end tag may be omitted if the option element is immediately followed by another option element, or if it is immediately followed by an optgroup element, or if there is no more content in the parent element.
-- Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Swifty wrote:
> I can't remember where I learned HTML, but I remember that there is no
> </OPTION> tag in HTML (but browsers don't care if you have them)
> I've discovered that I sometimes get blank entries in my<SELECT>
> controls, even though none of the<OPTION>'s are blank. This happens
> with the current Opera browser (and back quite a few releases).
> The workaround is to add the un-necessary, and possible illegal
> </OPTION> tags.
It is not illegal, it is optional in HTML 4.01, but required in XHTML. I typically put in all optional closing tabs because it fined it makes it easier to debug and see my errors...
In article <jnrmsj$n4...@dont-email.me>,
"Jonathan N. Little" <lws4...@gmail.com> wrote:
> Swifty wrote:
> > I can't remember where I learned HTML, but I remember that there is no
> > </OPTION> tag in HTML (but browsers don't care if you have them)
I think it was optional even in 3.2 days but I am not surprised at your memory because the typical examples (you could see them pasted inside the cabins of horse drawn buggies) are as in
> > I've discovered that I sometimes get blank entries in my<SELECT>
> > controls, even though none of the<OPTION>'s are blank. This happens
> > with the current Opera browser (and back quite a few releases).
> > The workaround is to add the un-necessary, and possible illegal
> > </OPTION> tags.
> It is not illegal, it is optional in HTML 4.01, but required in XHTML. I > typically put in all optional closing tabs because it fined it makes it > easier to debug and see my errors...
> > Presumably this is a problem that I should report to Opera, but I
> > thought I'd check my facts first.
> With out the code in question, it is hard to say if there is a bug in > Opera or *your* markup.
Odd things can happen in quirks mode where browsers make out however. In such mode, a browser can fail to trigger an implicit close of a prior element and maybe all sort of other things can happen. So it would be interesting to see the markup that gives Swifty this problem.
2012-05-03 1:32, dorayme wrote:
>>> I can't remember where I learned HTML, but I remember that there is no
>>> </OPTION> tag in HTML (but browsers don't care if you have them)
> I think it was optional even in 3.2 days
The </OPTION> tag has always been optional in HTML; in XHTML it is required of course.
End tags are forbidden in HTML only for elements with EMPTY declared content, such as <BR>. The OPTION element has (#PCDATA)* declared content, i.e. plain text content; even though this includes the possibility of the empty string, this is quite different from elements with EMPTY declared content. So <OPTION></OPTION> is valid.
> Odd things can happen in quirks mode where browsers make out however.
And even in "standards" mode. Even more surprisingly, the omission of the optional </p> tag may trigger very nasty bugs on IE 7, IE 8, IE 9 in "standards mode", bugs that do not exist in quirks mode! See
http://www.cs.tut.fi/~jkorpela/quirks-mode.html#iebug
> In such mode, a browser can fail to trigger an implicit close of a
> prior element and maybe all sort of other things can happen. So it
> would be interesting to see the markup that gives Swifty this problem.
It would indeed be interesting as a theoretical issue. The practical conclusion, however, is simple: it's safer to close all elements with explicit end tags, except for the elements with EMPTY declared content.
In article <jnt2no$as...@dont-email.me>,
"Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
> > Odd things can happen in quirks mode where browsers make out however.
> And even in "standards" mode. Even more surprisingly, the omission of > the optional </p> tag may trigger very nasty bugs on IE 7, IE 8, IE 9 in > "standards mode", bugs that do not exist in quirks mode! See
> http://www.cs.tut.fi/~jkorpela/quirks-mode.html#iebug
Interesting. I believe you without looking. As you so truly say, best course is to close all elements that have end tags. I have my editor set to disclose and warn and even fix any failure to observe this.
> > In such mode, a browser can fail to trigger an implicit close of a
> > prior element and maybe all sort of other things can happen. So it
> > would be interesting to see the markup that gives Swifty this problem.
> It would indeed be interesting as a theoretical issue. The practical > conclusion, however, is simple: it's safer to close all elements with > explicit end tags, except for the elements with EMPTY declared content.
On Thu, 03 May 2012 08:32:42 +1000, dorayme <dora...@optusnet.com.au>
wrote:
>So it >would be interesting to see the markup that gives Swifty this problem.
I'll have to see if I can generate some test HTML. The original is on
our corporate Intranet so accessible only to those who've taken the
pledge.
The HTML is generated by a CGI script. In the past, I've saved the
page as a simple HTML file, and that never causes the problems. The
problem also only ever happens in Opera. I'm not in quirks mode,
unless some of my "creative" HTML has forced Opera to change its mind,
after encountering the:
Reloading the page also makes the problem come and go, but as it's
generated by a CGI script, that might just be down to the script
intermittently generating empty <OPTION> tags. It is not doing this,
my first step whenever I get these blank options is to look at the
source, and the options are never blank. The first one often carries a
null VALUE, but that's not the same thing.
As you may imagine, the CGI script generates the sequence of <OPTION>
tags by running a simple loop. Adding the optional </OPTION> tags is a
trivial 9-character patch to my code. Once this is in place, the
problem never comes back...
