Bug 460 - New/New Wizard inserts non-conforming <meta http-equiv=* content=*/> in XHTML5 documents
Summary: New/New Wizard inserts non-conforming <meta http-equiv=* content=*/> in XHTML...
Status: RESOLVED FIXED
Alias: None
Product: BlueGriffon
Classification: Unclassified
Component: General (show other bugs)
Version: trunk
Hardware: All All
: P5 normal
Target Milestone: 1.6
Assignee: Daniel Glazman
URL: http://lists.w3.org/Archives/Public/p...
Keywords: BGEE_DONE, BGEE_WANTED
Depends on:
Blocks:
 
Reported: 2012-11-06 12:16 PST by Leif Halvard Silli
Modified: 2013-01-03 07:19 PST (History)
1 user (show)

See Also:


Attachments
fix (6.53 KB, patch)
2012-12-03 05:25 PST, Daniel Glazman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Leif Halvard Silli 2012-11-06 12:16:18 PST
BlueGriffon’s New/New Wizard command inserts the http-equiv="Content-Type" meta element if the user choose the XHTML5 syntax:

   <meta http-equiv="Content-TYpe" content="text/html;charset=UTF-8"/>

However, per the HTML5 specification, the XHTML5 syntax does not permit this, see Validator.nu as well as the specification itself: http://dev.w3.org/html5/spec/the-meta-element.html#charset

The only <meta> that can be used for specifying encoding in a XHTML document, is the <meta charset="UTF-8" /> and in that case the value *must* be UTF-8, see the spec: http://dev.w3.org/html5/spec/the-meta-element.html#the-meta-element
Comment 1 Daniel Glazman 2012-12-03 00:51:14 PST
(In reply to comment #0)

> The only <meta> that can be used for specifying encoding in a XHTML document,
> is the <meta charset="UTF-8" /> and in that case the value *must* be UTF-8, see
> the spec: http://dev.w3.org/html5/spec/the-meta-element.html#the-meta-element

This is wrong, Leif... See section 4.2.5 of html5 in
http://dev.w3.org/html5/spec/the-meta-element.html#character-encoding-declaration

  If an HTML document does not start with a BOM, and its encoding
  is not explicitly given by Content-Type metadata, and the document
  is not an iframe srcdoc document, then the character encoding used
  must be an ASCII-compatible character encoding, and the encoding
  must be specified using a meta element with a charset attribute or
  a meta element with an http-equiv attribute in the Encoding
  declaration state.

Closing as invalid, sorry, and the validator should be fixed.
Comment 2 Leif Halvard Silli 2012-12-03 04:19:31 PST
(In reply to comment #1)

This bug was about *XHTML5*. You are citing rules that applies to *HTML5*. Hence I open this bug again, setting it to "Unconfirmed" (as there is no other priviliges in my possession).

Two quotations from the spec:

http://dev.w3.org/html5/spec/the-meta-element.html#attr-meta-http-equiv-content-type

]] The Encoding declaration state may be used in HTML documents, but elements with an http-equiv attribute in that state must not be used in XML documents. [[

http://dev.w3.org/html5/spec/the-meta-element.html#charset

]] The charset attribute specifies the character encoding used by the document. This is a character encoding declaration. If the attribute is present in an XML document, its value must be an ASCII case-insensitive match for the string "UTF-8" (and the document is therefore forced to use UTF-8 as its encoding). [[

PS: Neither a meta charset element nor a meta http-equv has any *effect* in XHTML document as the encoding of an XHTML document can only be affected via 
 * encoding declaration (<?xml version="1.0" encoding="UTF-8"?>)
 * BOM
 * external protocol.
Comment 3 Leif Halvard Silli 2012-12-03 04:21:59 PST
(In reply to comment #2)

> PS: Neither a meta charset element nor a meta http-equv has any *effect* in
> XHTML document as the encoding of an XHTML document can only be affected via 
>  * encoding declaration (<?xml version="1.0" encoding="UTF-8"?>)
>  * BOM
>  * external protocol.

I forg to say: So the permissoin to use exagly <meta charset="UTF-8" /> and none of the others options, is purely a conformance rule, motivated - as the spec says - from a desire to promote easy format swithing/exchange between XHTML5 and HTML5.
Comment 4 Daniel Glazman 2012-12-03 05:25:59 PST
Created attachment 455 [details]
fix
Comment 5 Daniel Glazman 2012-12-03 05:27:20 PST
Fixed and checked in, revision 1086