On Wed, 26 Nov 2014 07:24:31 +0100, Ian Hickson <i...@hixie.ch> wrote:
On Wed, 26 Nov 2014, Sanjoy Pal wrote:
As per specification [1][2], <menuitem> should not have end tag, but few
websites uses <menuitem>Some markup</menuitem> which resulted in broken
sites[3][4].
Firefox allows <menuitem>Some markup</menuitem>. So, we are wondering if
specification can be modified to allow <menuitem>Some markup</menuitem>
for backward compatibility.
Do we know how many sites are affected?
As I see it there's basically three choices -- in my order of preference,
they would be:
- break the sites: if there aren't many, and especially if they can be
evangelised to avoid these mistakes, then we should just do that
- rename <menuitem> to something else, like <command>: this would be
unfortunate, since the feedback from Mozilla a few years ago was that
they'd rather have <menuitem> than <command>, and it would also mean some
parser churn, which is always bad, but it would probably be reasonably
safe to do if we can find a good replacement element name
- change <menuitem>'s semantics so that the label comes from the
element's
textContents instead of a label="" attribute (and charge the parser
accordingly): not sure how compatible this would be; it has numerous
disadvantages, too, like making people think they can put markup in the
element (look at the Apple page for an example), which wouldn't work
There may be other options that aren't immediately coming to mind.
- Make the end tag optional and have <menuitem>, <menu> and <hr> generate
implied </menuitem> end tags. (Maybe other tags like <li> and <p> can also
imply </menuitem>.) The label attribute be honored if specified, otherwise
use the textContent with leading and trailing whitespace trimmed.
This would allow either syntax unless I'm missing something.
--
Simon Pieters
Opera Software
