Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Is </OPTION> optional?
33 views
Skip to first unread message
Swifty
May 2, 2012, 11:26:38 AM5/2/12
to
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.
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
</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.
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Barry Margolin
May 2, 2012, 11:53:41 AM5/2/12
to
In article <j6k2q79ihed6srqhq...@4ax.com>,
contexts.
http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission
says:
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 <steve....@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
> 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.
contexts.
http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission
says:
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 ***
Jonathan N. Little
May 2, 2012, 12:20:34 PM5/2/12
to
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
> 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.
typically put in all optional closing tabs because it fined it makes it
easier to debug and see my errors...
When in doubt, why not look it up?
http://www.w3.org/TR/html401/index/elements.html
>
> Presumably this is a problem that I should report to Opera, but I
> thought I'd check my facts first.
>
Opera or *your* markup.
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
dorayme
May 2, 2012, 6:32:42 PM5/2/12
to
In article <jnrmsj$n4i$1...@dont-email.me>,
your memory because the typical examples (you could see them pasted
inside the cabins of horse drawn buggies) are as in
<http://www.w3.org/TR/REC-html32#select>
> > 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...
>
> When in doubt, why not look it up?
>
> http://www.w3.org/TR/html401/index/elements.html
>
> >
> > 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.
--
dorayme
"Jonathan N. Little" <lws...@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
> 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)
> >
your memory because the typical examples (you could see them pasted
inside the cabins of horse drawn buggies) are as in
<http://www.w3.org/TR/REC-html32#select>
> > 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...
>
> When in doubt, why not look it up?
>
> http://www.w3.org/TR/html401/index/elements.html
>
> >
> > 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.
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.
--
dorayme
Jukka K. Korpela
May 3, 2012, 12:48:59 AM5/3/12
to
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
>>> 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
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.
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.
conclusion, however, is simple: it's safer to close all elements with
explicit end tags, except for the elements with EMPTY declared content.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
dorayme
May 3, 2012, 7:56:53 AM5/3/12
to
In article <jnt2no$as1$1...@dont-email.me>,
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.
--
dorayme
"Jukka K. Korpela" <jkor...@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
> > 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
>
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.
--
Swifty
May 4, 2012, 10:48:54 AM5/4/12
to
On Thu, 03 May 2012 08:32:42 +1000, dorayme <dor...@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:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
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...
wrote:
>So it
>would be interesting to see the markup that gives Swifty this problem.
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:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
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...
0 new messages