Skip to content
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.

Make HTML4/XHTML1 Strict doctypes non-conforming #729

Closed
stevefaulkner opened this issue Nov 16, 2016 · 3 comments
Closed

Make HTML4/XHTML1 Strict doctypes non-conforming #729

stevefaulkner opened this issue Nov 16, 2016 · 3 comments
Assignees
@adanilo
Labels
Should be deprecated? technical improvement
Milestone
HTML 5.2 WD 6

Comments

@stevefaulkner
Copy link
Contributor

Over on WHATWG @sideshowbarker wrote:

It was never intended that HTML4 Strict and XHTML1/1.1 Strict doctypes would remain conforming forever. Given that HTML4 is nearly 20 years old (and XHTML1 is just a reformulation of HTML4 in XML), it’s time to consider making the HTML4 Strict and XHTML1/1.1 Strict doctypes non-conforming—just as are all other HTML4 and XHTML1/1.1 doctypes (and HTML 3.2, etc., doctypes are).

The spec currently defines that the HTML4 Strict and XHTML1/1.1 Strict doctypes are obsolete but still conforming—obsolete permitted DOCTYPEs—and says that “Authors should not use obsolete permitted DOCTYPEs, as they are unnecessarily long”.

The reason the spec states for allowing them in conforming documents is in order to “help authors transition from HTML4 and XHTML1”.

But at this point continuing to allow HTML4 Strict and XHTML1/1.1 Strict doctypes as conforming isn’t helping authors transition; instead it seems to be having the effect of continuing to proliferate use of those doctypes long past what rightly should have been their proper expiration date.

For the HTML checker I still get issue reports from authors requesting that if they put an HTML4 or XHTML1 doctype on a document, the checker should evaluate it using HTML4/XHTML1 requirements (as the SGML/DTD-based legacy W3C validator does and as validator.nu used to do) instead of requirements in the current HTML spec.

In other words, some authors are continuing to intentionally use the HTML4/XHTML1 doctypes so that their documents can be “valid” even though they contain markup that the current HTML spec defines as non-conforming.

So, it’d be helpful if we made the spec clearly disallow use of all legacy HTML doctypes, including the HTML4 Strict and XHTML1/1.1 Strict doctypes (the only remaining legacy docytpes still allowed).
@chaals
Copy link
Collaborator

chaals commented Nov 18, 2016

@cstrobbe can you explain why you disagree please?

It makes sense to me that HTML 5.x doesn't include doctype markers that are specifically intended to identify documents as some other, but related, language.

@komputist
Copy link

For the validator - and the spec - I would like to propose the opposite direction: Rather than tightening the screw on what validates, any DOCTYPE that triggers no-quirks mode should get status as "obsolete but conforming".

And, as well: if there is a problem in the validator, it should be solved in the validator. There are several options for how to do that without changing the spec. The HTML5 validator does not need to accept the obsolete but conforming features by default.

The message of having the obsolete but conforming doctypes is (1) that the DOCTYPE does not matter and (2) that only no-quirks mode matters and (3) keeping them obsolete - but conforming, shows that HTML does not include versioning signals.

Further, the DTDs of the legacy DOCYPEs add some (XML) features that are seemingly not widely available in XML authoring tools unless one reference a DTD: They declare named character references and they declare the id attribute to have ID-ness (though, ID-ness is not declared for the new elements of HTML 5.x.)

Bringing in HTML 3.2 is counterproductive because that DOCTYPE triggers quirks mode.

As for making any no-quirks DOCTYPE obsolete but conforming, this would solve problems I have when need to work with certain common XML tools. Then, I find myself needing to declare ID-ness, and the only cross-tool way I could do that was by inserting a data URL in the SYSTEM variant of the HTML 5 doctype. For example, this example declare ID-ness for the article element - without triggering quirksmode:

<!DOCTYPE html SYSTEM "data:application/xml-dtd,%3C!ATTLIST%20section%20id%20ID%20%23IMPLIED%3E">

Note that it would be OK to treat this a obsolete (but conforming) because it ought not be necessary to do it this way, but unfortunately it is.

@chaals
Copy link
Collaborator

chaals commented Nov 20, 2016

@komputist it doesn't seem like what you are writing is HTML 5.2 anyway, but something else related. If the doctype you use suits your purpose, allowing the specific HTML 4 / XHTML 1.1 doctypes in HTML 5.2 makes no difference I can see. What am I missing?

@chaals chaals added this to the HTML 5.2 WD 6 milestone Mar 6, 2017
adanilo pushed a commit to adanilo/html that referenced this issue Mar 29, 2017
Make HTML4/XHTML1 stict DOCTYPES non-conforming. Issue w3c#729.
16ec8c0
@adanilo adanilo mentioned this issue Mar 29, 2017
Merged
chaals pushed a commit that referenced this issue Mar 30, 2017
Make HTML4/XHTML1 stict DOCTYPES non-conforming. Issue #729. (#840)
c1cbc95
@chaals chaals closed this as completed Mar 30, 2017
W3C-HTML-Bot pushed a commit that referenced this issue Mar 30, 2017
Built by Travis-CI: c1cbc95 Make HTML4/XHTML1 stict DOCTYPES non-conf…
afca668 
…orming. Issue #729. (#840)
arronei pushed a commit to arronei/html that referenced this issue Apr 17, 2017
@arronei
Make HTML4/XHTML1 stict DOCTYPES non-conforming. Issue w3c#729. (w3c#840
20e1239 
)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@adanilo adanilo

Labels
Should be deprecated? technical improvement
Projects
None yet
Milestone
HTML 5.2 WD 6
Development

No branches or pull requests
4 participants
@komputist @stevefaulkner @adanilo @chaals