- From: Sam Ruby <rubys@intertwingly.net>
- Date: Thu, 19 Feb 2009 07:58:02 -0500
- To: Ian Hickson <ian@hixie.ch>
- CC: Larry Masinter <masinter@adobe.com>, HTML WG <public-html@w3.org>
Ian Hickson wrote: > On Thu, 19 Feb 2009, Sam Ruby wrote: >> The only way forward in situations like this is to start over with a new >> format. > > That's one way forward, but not the only one. HTML5's approach has been to > embrace the reality of implementations, and replace previous > specifications with a definitive comprehensive set of requirements that > matches implementations, including their really strange behaviour (such as > "quirks mode" in HTML). > > It's a whole hell of a lot more work than writing a new language from > scratch, but it has the advantages of not requiring consumers to support > two languages (one of which is effectively undefined) instead of just one, > and of not requiring producers to start from scratch when updating to the > new technologies (the latter is not a big problem for feed formats, where > the feeds typically are generated from source material, but is quite a big > deal for original-form formats like HTML, where the content exists only in > the form of the "legacy" language). By snipping in the way you did, you made it appear as it there is a disagreement between you and me on this subject, where in fact, there is none; at least not at the broad brush level. By working on HTML you voluntarily accept the constraints that there is only so much you can fix in terms of forms (for example). If one wanted to improve this further one would need to (possibly) create entirely new elements with new behavior or (and may even be preferably) create an entirely new format. The one thing that doesn't work too well in practice is where a subtle change in one or two bytes in one part of a file (generally the top) makes a dramatic and visible change to how a completely different part of the file is processed. Increasing the length of the version identifier (like has been tried with DOCTYPES) doesn't help. Moving this to someplace invisible (like a HTTP header) doesn't either. For completeness, I feel compelled to state that none of these principles can ever be cleanly applied. GIF and JPEG can both be used to produce similar effects. For a number of reasons, there was need for something more, and PNG was created. How do browsers tell them apart? By looking at the data. Whether this is a flagrant violation of web architecture (Authoritative Metadata[1]) or is an prime example of Extending and Versioning Languages[2] is a matter of perspective. While I said above that we (you and I) agree on broad brush level, there are a few details that we need to continue to work through. The A-List-Apart and WordPress crews believe that they are doing XHTML no matter how much we might believe differently. Flagging uses of meta charset which do not contradict other sources of metadata as non-conformant is an example where something invisible causes something else which tools like Venus have a real use case for to be considered invalid. - Sam Ruby [1] http://www.w3.org/2001/tag/doc/mime-respect [2] http://www.w3.org/2001/tag/doc/versioning
Received on Thursday, 19 February 2009 12:58:16 UTC