Re: [whatwg] menuitem: Issue reported by the web developers
On Mon, 08 Dec 2014 21:50:56 +0100, Simon Pieters sim...@opera.com wrote: On Thu, 27 Nov 2014 01:15:20 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 26 Nov 2014, Simon Pieters wrote: - 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. That's another option, yeah. Probably the best so far if we can't just power through and break the sites in question. It's not yet clear to me how many sites we're talking about here and how possible it is to evaneglise them. In httparchive http://bigqueri.es/t/analyzing-html-css-and-javascript-response-bodies/442 : FTR, the numbers were slightly wrong. I didn't count top-level pages, I counted resources (including e.g. iframes). Also there is a bug in the data with duplicate entries for some pages (https://twitter.com/zcorpan/status/542363458671747072 ). * 10101 pages use menuitem 8929 pages use menuitem SELECT page, COUNT(*) as num FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), r'menuitem\s') GROUP BY page ORDER BY num desc * 39 have no label attribute * 0 have non-whitespace content * 15 have no end tag Based on this, it seems possible to keep it as a void element and only use the label attribute. SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'menuitem\s([^]+\s)?label\s*=') THEN label present ELSE no label END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), r'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10062 label present 2 39 no label 8900 have label present (so 29 no label). SELECT page, COUNT(*) as num FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), r'menuitem\s([^]+\s)?label\s*=') GROUP BY page ORDER BY num desc SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'menuitem[^]*(\s*[^]+)+\s*/menuitem') THEN has content ELSE no content END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), r'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10101 no content SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'/menuitem') THEN end tag ELSE no end tag END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), r'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10086 end tag 2 15 no end tag -- Simon Pieters Opera Software
Re: [whatwg] menuitem: Issue reported by the web developers
On Thu, 27 Nov 2014 01:15:20 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 26 Nov 2014, Simon Pieters wrote: - 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. That's another option, yeah. Probably the best so far if we can't just power through and break the sites in question. It's not yet clear to me how many sites we're talking about here and how possible it is to evaneglise them. In httparchive http://bigqueri.es/t/analyzing-html-css-and-javascript-response-bodies/442 : * 10101 pages use menuitem * 39 have no label attribute * 0 have non-whitespace content * 15 have no end tag Based on this, it seems possible to keep it as a void element and only use the label attribute. SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'menuitem\s([^]+\s)?label\s*=') THEN label present ELSE no label END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), r'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10062 label present 2 39 no label SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'menuitem[^]*(\s*[^]+)+\s*/menuitem') THEN has content ELSE no content END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), r'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10101 no content SELECT COUNT(*) as num, CASE WHEN REGEXP_MATCH(LOWER(body), r'/menuitem') THEN end tag ELSE no end tag END as stat FROM [httparchive:runs.2014_08_15_requests_body] WHERE mimeType CONTAINS html AND REGEXP_MATCH(LOWER(body), r'menuitem') GROUP BY stat ORDER BY num desc Row num stat 1 10086 end tag 2 15 no end tag -- Simon Pieters Opera Software
Re: [whatwg] menuitem: Issue reported by the web developers
On Mon, 08 Dec 2014 21:50:56 +0100, Simon Pieters sim...@opera.com wrote: On Thu, 27 Nov 2014 01:15:20 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 26 Nov 2014, Simon Pieters wrote: - 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. That's another option, yeah. Probably the best so far if we can't just power through and break the sites in question. It's not yet clear to me how many sites we're talking about here and how possible it is to evaneglise them. In httparchive http://bigqueri.es/t/analyzing-html-css-and-javascript-response-bodies/442 : A related issue that has come up is menu type=context vs menu type=popup. * 10070 pages use menu type=context * 0 pages use menu type=popup * 100 pages use menu type=toolbar or some other value https://groups.google.com/a/chromium.org/d/msg/blink-dev/MkEDloT-yu8/wJhIK6jVSXMJ Based on this I suggest we rename popup to context in the spec. -- Simon Pieters Opera Software
Re: [whatwg] menuitem: Issue reported by the web developers
On Mon, 08 Dec 2014 21:50:56 +0100, Simon Pieters sim...@opera.com wrote:
SELECT COUNT(*) as num,
CASE
WHEN REGEXP_MATCH(LOWER(body),
r'menuitem[^]*(\s*[^]+)+\s*/menuitem') THEN has content
ELSE no content
END as stat
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE mimeType CONTAINS html
AND REGEXP_MATCH(LOWER(body), r'menuitem')
GROUP BY stat
ORDER BY num desc
Row num stat
1 10101 no content
Hixie pointed out that this doesn't catch element children. So flipping it
gives:
SELECT COUNT(*) as num,
CASE
WHEN REGEXP_MATCH(LOWER(body), r'menuitem[^]*\s*/menuitem') THEN
no content
ELSE has content
END as stat
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE mimeType CONTAINS html
AND REGEXP_MATCH(LOWER(body), r'menuitem')
GROUP BY stat
ORDER BY num desc
Row num stat
1 10085 no content
2 16 has content
15 of these are omitting the end tag, as seen by the other query. So what
is the last one doing?
SELECT url,body
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE mimeType CONTAINS html
AND LOWER(body) CONTAINS 'menuitem'
AND LOWER(body) CONTAINS '/menuitem'
AND NOT REGEXP_MATCH(LOWER(body), r'menuitem[^]*\s*/menuitem')
Row url body
1 http://www.dod.gr/lib/menuData_v483.php menus !-- BOTTOM NAVIGATION
MENU --- menu id=BottomNavigationMenu type=main x=30 y=30
menuitem x=120 y=120 imagecommunity.swf/image
labelcommunity/label ...
Yep, mislabeled XML.
For completeness, the 15 pages with no end tags fall in two categories:
* for(i=0;imenuitems.length;i++)
* xml id=SolpartMenuDI onreadystatechange=if (this.readyState ==
'complete') spm_initMyMenu(this,
spm_getById('dnn_dnnMENU_ctldnnMENU'))rootmenuitem id=2533
title=صفحه اصلی url=/Default.aspx?tabid=2533 lefthtml=lt;img
alt=quot;*quot; BORDER=quot;0quot;
src=quot;/images/breadcrumb.gifquot;gt; css= /
Previous conclusion stands. :-)
--
Simon Pieters
Opera Software
Re: [whatwg] menuitem: Issue reported by the web developers
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 menuitemSome markup/menuitem which resulted in broken sites[3][4]. Firefox allows menuitemSome markup/menuitem. So, we are wondering if specification can be modified to allow menuitemSome 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
Re: [whatwg] menuitem: Issue reported by the web developers
On Wed, 26 Nov 2014, Simon Pieters wrote: - 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. That's another option, yeah. Probably the best so far if we can't just power through and break the sites in question. It's not yet clear to me how many sites we're talking about here and how possible it is to evaneglise them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] menuitem: Issue reported by the web developers
Hello Friends, We have implemented contextmenu attribute in blink as per the specification. There is an issue reported by the web developers. As per specification [1][2], menuitem should not have end tag, but few websites uses menuitemSome markup/menuitem which resulted in broken sites[3][4]. Firefox allows menuitemSome markup/menuitem. So, we are wondering if specification can be modified to allow menuitemSome markup/menuitem for backward compatibility. Please provide your guidance on the same. [1] https://html.spec.whatwg.org/multipage/forms.html#the-menuitem-element https://html.spec.whatwg.org/multipage/forms.html#the-menuitem-element [2] https://html.spec.whatwg.org/multipage/syntax.html#void-elements https://html.spec.whatwg.org/multipage/syntax.html#void-elements [3]https://crbug.com/412945 [4]https://crbug.com/434240 Thanks and regards, Sanjoy Pal
Re: [whatwg] menuitem: Issue reported by the web developers
On Wed, 26 Nov 2014, Sanjoy Pal wrote: As per specification [1][2], menuitem should not have end tag, but few websites uses menuitemSome markup/menuitem which resulted in broken sites[3][4]. Firefox allows menuitemSome markup/menuitem. So, we are wondering if specification can be modified to allow menuitemSome 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
