Re: conflation of issues or convergence of interests?

On Sat, Jul 28, 2007 at 02:34:03PM +0100, Patrick H. Lauke wrote:

> My response was directly related to your "different architecture" 
> statement, assuming that you meant "architecture of the language" rather 
> than "architecture of current practices". But it seems that you were indeed 
> referring to the latter. Again, this seems disingenuous to me...let's not 
> look at HTML 4's language constructs when devising new elements, but rather 
> look at how current sites have (ab)used the markup at this point in time. 
> As was noted before, even if a large percentage of sites/authors here and 
> now don't take advantage of an HTML 4 language feature, that doesn't 
> necessarily mean that the feature should be scrapped...but I guess that's 
> really the crux of this argument.

I agree with the above. Nevertheless, current practices can reveal lacunae or
inadequacies in the features of the language. For example, navigational menus
are ubiquitous on the Web, yet prior to XHTML 2.0, no corresponding HTML
element was defined. The HTML 5 NAV element also addresses this concern, and
for good reasons.

The prevalence of navigational links on Web pages, combined with the utility
of exposing these as logical document structures to UAs and other tools,
comprises a strong ground for bringing HTML into line with Web practice by
adding the necessary element, as has been achieved in the current draft.

I would argue that lack of widespread application of a language feature should
only lead to deprecation if there are clear reasons as to why the feature has
not been commonly used or implemented, and these reasons indicate a flaw in
the design that needs to be corrected. This is not a conservative position,
however, since deprecating existing language features is a necessary part of
the process of adopting new solutions. On the other hand, deprecating a
feature without substituting a superior solution only weakens the design of
the resulting language by leaving those who would benefit from the semantics
formerly provided with unaddressed needs.

If a certain document structure occurs widely, across a diverse range of Web
content, and there are identifiable benefits to be gained by exposing it to
HTML processors, then there is a prima facie argument for its inclusion in the
specification. This needs to be balanced against competing considerations, of
course, such as the need to minimize over-all complexity. Having chosen to add
a feature, though, it is important that it be designed well - and this
includes satisfaction of i18n, accessibility and other pertinent requirements,
which should in fact be regarded as central parts of good design rather than
as extraneous demands arising from outside the process.

The inclusive nature of the HTML working group also subjects the design to
ongoing influence by a range of potential implementors, authors and other
interested parties. This is the right way to collect expertise regarding which
features are and would be useful, and to enable judgments concerning adoption
and implementation concerns, in so far as these matters can be predicted in
advance of the CR stage.

Received on Sunday, 29 July 2007 06:44:26 UTC