Re: Doctypes and the dialects of HTML 5

Mike Schinkel wrote:
> Lachlan Hunt wrote
>> Mike Schinkel wrote:
>>> <head>  <supports type="hmme"> </head>
>>
>> Specifically, what is the problem you are trying to
>> solve?
> 
> I'm not trying to solve any specific problem for myself. I was trying to
> address the issue others were bringing up when they asked for versioning
> because of "the need for special markup and/or behaviors for different
> clients."

It doesn't matter who's problem it is, it only matters what the problem 
is.  I do not understand what the issue is and why versioning is being 
requested, and I do not understand the intent of your solution.  If you 
do not know what the problem is, how can you possibly have a solution 
for it?

It think it's important for everyone, particularly those with less 
experience in developing and contributing to specs, to learn and 
understand the difference between a solutions, use cases and problems. 
Before any solution can be developed or proposed, we need to clearly 
define what the use cases are and problems are.

Without knowing and understand the problem and use cases to be solved, a 
successful solution cannot be developed; and a solution looking for a 
problem isn't really a solution at all.

To illustrate the concept of use cases, problems and solutions, this is 
basically how we solved the DOCTYPE problem in HTML5.

---

The Use Case:

Authors need to be able to make use of standards compliant parsing and 
rendering behaviour in browsers because standards are easier for authors 
to develop, due to quirks mode being non-standards compliant unpredictable.

* Note that the use case states both *what* is needed and *why* it is 
needed.

The Problem:

1. We need a way to trigger standards mode in browsers.
2. The solution should be easy to remember and type.

Scope:

The solution should be unrelated to validation, as that is a separate 
problem with other solutions.  It does not need provide any version 
information.

The Solution:

Triggering standards mode requires a DOCTYPE.  Initially, the DOCTYPE 
was this:
   <!DOCTYPE html PUBLIC "-//WHATWG//NONSGML HTML5//EN">

That solved problem #1, but wasn't such a great solution for problem #2. 
  PUBLIC identifiers in SGML are generally associated with DTDs and it 
also also provides a version number.  So that solution went a little bit 
out the scope.

It was later discovered that the PUBLIC identifier could be omitted 
entirely and still trigger standards mode.  Thus, we ended up with:

   <!DOCTYPE html>

---

Compare this with the requests for versioning or profiling in this thread:

The Use Case:

We need a way to specify the version of html because ...?

The Problem:
1. ?

The Scope:

Unknown.

The Solutions:

1. Add a version attribute
2. Add a number to the PUBLIC identifier in the DOCTYPE.
3. New element: <supports type="hmme">

It should be clear to anyone that coming up with those solutions doesn't 
make any sense because there is no clear use case (it doesn't state why 
we need it) and there is no problem or scope.  Without any of those, we 
  have solutions looking for problems, rather than problems looking for 
solutions, which is clearly backwards.

---

Finally, Jirka eventually raised an interesting problem in this this 
thread and Henri provided a reasonable solution [1].  So one last 
example to illustrate that:

The Use Case:

Authors have existing tool chains to generate HTML, including 
technologies such as XSLT.  It should be easy for authors to continue 
using such tools while migrating to HTML5.

The Problem:

1. XSLT apparently does not allow DOCTYPEs to be emitted without either 
a PUBLIC and/or SYSTEM identifier.
2. Authors should be able to continue using XSLT in their tool chains if 
they wish.

Scope:

The solution only needs to make it possible to emit conforming HTML 
documents from existing tool chains.  It does not need to provide for 
any DTD based validation or versioning.

Solutions:

1. Append an HTML5 serialiser to the end of the tool chain.
2. Allow conforming HTML documents to include a PUBLIC identifier for 
use by authors using tools that cannot emit only <!DOCTYPE html>.
   e.g. <!DOCTYPE html PUBLIC "HTML">

Assuming that really is a limitation with XSLT (I don't know if it is or 
not, I only know what Jirka has stated), solution #1 is potentially 
costly.  It would require an update to the authors system which may or 
may not be easy or cheap.

Solution #2 is a more pragmatic approach.  Including a PUBLIC identifier 
is harmless and it nicely solves both problems.

[1] http://www.w3.org/mid/038233E6-D123-4A54-98B1-924629324695@iki.fi

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Sunday, 25 March 2007 11:16:06 UTC