Meta tag list: HTML5-style charset is not displayed / meta tags in body are displayed

NEW
Unassigned

Status

()

Firefox
Page Info Window
7 years ago
3 years ago

People

(Reporter: kohei, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

7 years ago
HTML5 allows <meta charset="UTF-8"> instead of the traditional <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> format.

In the meta tag list, this new format is ignored and displayed as a blank line.

You can test this at http://mozilla.jp/

The expected result would be
Name: charset
Content: UTF-8

Comment 1

7 years ago
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/html/nsIDOMHTMLMetaElement.idl?force=1

Hmm nsIDOMHTMLMetaElement.idl doesn't have a HTML5 charset property. Which would make it easier for PageInfo.
(Reporter)

Updated

7 years ago
Depends on: 584326
What's hard about getAttribute()?
(Reporter)

Comment 3

7 years ago
Created attachment 462743 [details] [diff] [review]
patch

Comment 4

7 years ago
Array.forEach(metaNodes, function(node) {
  if (node.hasAttribute("charset")
    gMetaView.addRow("charset", node.getAttribute("charset"));
  else
    gMetaView.addRow([metaNodes[i].name || metaNodes[i].httpEquiv, metaNodes[i].content]);
}
(Reporter)

Comment 5

7 years ago
I just found that <meta property="*" content="*" /> tags were also not displayed properly. Such tags are used in the Open Graph protocol:
http://opengraphprotocol.org/

Will update the patch.
Assignee: nobody → kohei.yoshino.bugs
Status: NEW → ASSIGNED
Summary: HTML5-style charset is not displayed in the meta tag list → HTML5-style charset and Open Graph properties are not displayed in the meta tag list
(Reporter)

Comment 6

7 years ago
And we should also support the itemprop attributes.
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta
(Reporter)

Comment 7

7 years ago
Created attachment 496758 [details] [diff] [review]
patch v2
Attachment #462743 - Attachment is obsolete: true
(In reply to comment #5)
> I just found that <meta property="*" content="*" /> tags were also not
> displayed properly. Such tags are used in the Open Graph protocol:
> http://opengraphprotocol.org/

I feel pretty strongly that we should not support those proprietary extensions.

(In reply to comment #6)
> And we should also support the itemprop attributes.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta

Personally, I'm not sure we should do this until we support microdata (Bug 591467). Don't feel strongly about this one, though.
(In reply to comment #5)
> I just found that <meta property="*" content="*" /> tags were also not
> displayed properly. Such tags are used in the Open Graph protocol:
> http://opengraphprotocol.org/

I think it doesn't make sense to display the property attribute an <meta> when RDFa allows it on any element. Furthermore, it doesn't make sense to display it without resolving the CURIE and without the context of the larger RDF graph. However, I think we should keep CURIEs out of Gecko and displaying a larger RDF graph in a user friendly way isn't (AFAIK) a solved UI problem in general.

I think we should keep CURIEs out of Gecko, because RDFa 1.0 CURIEs rely on markup features that parse differently in HTML and XHTML and, therefore, violate the HTML Design Principles. I think we should keep RDFa 1.1 CURIEs out of Gecko, because they have the same author confusion characteristics as XML Namespaces (see http://wiki.whatwg.org/wiki/Namespace_confusion ) and implementing them would either be bad for performance or require added complexity to Gecko's DOM implementation to make the prefix resolution fast.

Doing only what the patch does is a slippery slope towards doing more. People would cite is as precedent for *some* RDFa support and ask for more, which would bring in the above-mentioned CURIE badness and the RDF graph complexity issues.

As for the Open Graph Protocol specifically, I think we shouldn't add support for de facto vendor-specific markup (in this case de facto Facebook-specific, AFAICT) even if the markup has "Open" in its name.

(In reply to comment #6)
> And we should also support the itemprop attributes.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta

If we add support for Microdata features, it would make sense to use the APIs from bug 591467 to do so. However, I think it doesn't make sense to single out the participation of the <meta> element in Microdata and show it detached from the larger Microdata data model just like it doesn't make sense to detach RDFa-participating <meta> elements from the larger RDF graph.

I suggest going back to attachment 462743 [details] [diff] [review]. r- from me on attachment 496758 [details] [diff] [review], though I realize I'm not the module owner.
Duplicate of this bug: 618763
Duplicate of this bug: 618763

Updated

6 years ago
Duplicate of this bug: 664494
(Reporter)

Comment 13

6 years ago
OK, let's just forget the Open Graph Protocol.

I've found another issue: the <meta> elements in the <body> are listed.
e.g. http://schema.org/docs/gs.html#advanced_missing

> var metaNodes = gDocument.getElementsByTagName("meta");

querySelectorAll resolves the issue. Will update my patch soon.
Summary: HTML5-style charset and Open Graph properties are not displayed in the meta tag list → Meta tag list: HTML5-style charset is not displayed / meta tags in body are displayed
(Reporter)

Comment 14

6 years ago
Created attachment 560790 [details] [diff] [review]
patch v3
Attachment #496758 - Attachment is obsolete: true
Are we sure we don't want to show charset metas from outside the head? (They can take effect.)
(Reporter)

Comment 16

6 years ago
I think this Meta Tag List feature in Firefox has intended to display metadata [1] specified in the <head>. So gDocument.querySelectorAll("head meta") would work.

[1] http://wiki.whatwg.org/wiki/MetaExtensions
Is the patch considered ready for review at this point? I wonder if it's possible to write a unit tests for this with reasonable effort.
(Reporter)

Comment 18

4 years ago
Still relevant, but I have no time to write tests. Resetting the assignee.
Assignee: kohei.yoshino → nobody
Status: ASSIGNED → NEW
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1013910
Comment on attachment 560790 [details] [diff] [review]
patch v3

Review of attachment 560790 [details] [diff] [review]:
-----------------------------------------------------------------

::: pageInfo.js
@@ +465,4 @@
>    document.getElementById("encodingtext").value = encoding;
>  
>    // get the meta tags
> +  var metaNodes = gDocument.querySelectorAll("head meta");

I think this should be done in a separate bug since it's orthogonal to the original issue.

@@ +482,5 @@
>  
> +    Array.forEach(metaNodes, function(node) {
> +      if (node.hasAttribute("charset")) {
> +        // get the HTML5-style short-hand charset
> +        gMetaView.addRow("charset", node.getAttribute("charset"));

This feels a bit weird since it's assigning a name of "charset" which could mislead people into thinking the page has <meta name="charset" content="…"> which is invalid. An alternative to this approach would be to simply omit <meta charset="…"> from the list since the resolved encoding is a few lines above the Meta tree. It also feels a bit weird to omit some <meta> elements but I think slightly less so.
Attachment #560790 - Flags: feedback-
Duplicate of this bug: 1075481
You need to log in before you can comment on or make changes to this bug.