W3C home > Mailing lists > Public > www-html-editor@w3.org > January to March 2000

Nokia's last call comments on XHTML Basic

From: <louis.theran@nokia.com>
Date: Wed, 15 Mar 2000 20:34:19 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E46011FB359@bseis01nok>
To: www-html-editor@w3.org
Cc: Ora.Lassila@nokia.com, hubbard@w3.org

XHTML Basic last call comments


XHTML Basic is intended to be the minimal subset of XHTML that will be used
as the basis for a number of new markup languages in the XHTML family that
will cater to the needs of small devices. This paper represents Nokia's
comments on XHTML Basic for last call. 

General comments

After much thought, Nokia cannot support the current XHTML-Basic proposal.
We agree with the proposition that subsets or profiles of XHTML--defining
minimum sets of supported functionality for broad classes of devices--would
be extremely useful. However, we do not believe that a single common profile
for all device classes can be usefully specified. Inevitably it will exclude
some feature that turns out to be essential for some class of devices. For
example, we believe that events are essential for phone class devices.
However, we would not argue that events should be included in a single
minimal subset, since there are almost certainly other device classes for
which events are not an essential feature. We see no point in agreeing on a
single, static, common subset when this subset is sure to be broken for some
class of devices. Instead, if we agree that subsets or profiles are needed
for broad classes of devices, then we should be working towards a standard
mechanism to specify such profiles. 

We understand the argument for a single, lowest-common-denominator, markup:
theoretically, this would allow content developers to create content that
could be rendered on any device with at least minimum usability. This is a
very attractive proposition. However, we don't believe there is any factual
evidence that such a set can be created, nor is there any practical
experience on which we can base discussions about what such a subset would
contain. Remember, the XHTML specification was the result of a vast amount
of distilled experience with real content on the Web. The XHTML Basic
specification is, in contrast, simply an a priori postulation of what a
common subset would look like. Almost none of the discussion is based on
practical experience of using such a subset to create useful content for
real devices. That XHTML Basic fails to explicitly note that decreasing the
number of elements can simplify the markup without simplifying the rendering
semantics that user agents need to support is a symptom of this. 

We include a number of examples of issues with the XHTML Basic specification
that we believe support our view, but we emphasize that these examples are
not intended to suggest changes to XHTML Basic. Rather, we view the
following examples as evidence that any attempt to produce a single core
subset of XHTML will fail to address the needs of a large number of device


Event handling

XHTML Basic intentionally excludes any sort of support for events or event
handlers with the comment that a generic event mechanism would be more
appropriate. While we agree with this assertion, we believe that any markup
language with no event support will be poorly received by content providers
working with handsets, since many of the common navigation idioms are
implemented using internal events in WML (e.g., onenterforward, ontimer).
Similarly, there may be need for browsers running on a handset to handle
externally generated events, such as push or incoming calls. Any markup
language used in this space will need to have the correct event handling


As with events, script support is needed in a markup language that will be
used on mobile phones. User agents on mobile phones are expected to
integrate cleanly with the phone environment, which means that they will
handle push events, support telephony interfaces and be capable of
interacting with specialized hardware on the phone. The natural way to
accomplish many of these tasks is through script. Scripting languages allow
the developer to gracefully handle errors that may occur using event
processing, while markup-only interfaces do not. We don't see arguments
about the desirability of eliminating inline script sources to be germane,
since XHTML Basic doesn't replace <script> with an alternative. 


To return to a point made in out general comments, XHTML Basic removes a
large number of tags just to decrease markup complexity. We consider this
misguided, since it decreases the amount of structural information available
to the user agent without removing any rendering burden. Similarly, elements
such as <b> can be ignored as easily as class attributes, so removing them
doesn't really accomplish much. 
Received on Wednesday, 15 March 2000 21:36:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:08:22 UTC