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/