[whatwg] Graceful Degradation and Mime Types [was: trailing slash]
karl at w3.org
Tue Dec 5 16:16:55 PST 2006
Le 5 déc. 2006 à 22:44, Benjamin Hawkes-Lewis a écrit :
> On Tue, 2006-12-05 at 09:25 +0900, Karl Dubost wrote:
>> but there's a point that we might take into consideration: People.
>> People do not want spend time structuring information, only a
>> minority like me.
> (X)HTML is clearly not for people unwilling to structure information.
That is the wish, but that would be purely academic to think that it
is happening. The Web is used by people, any kind of people. :) some
with strange habits
> By contrast, having semantic formats
> cleanly separated from presentational formats, means that
> technology can
> safely rely on the first and attempt to disambiguate the treacherous
Yes this is the benefit of well designing the technology. Though this
is not a rendering question (browsers) but typically an authoring
question (editors). We can develop thousand of ways to have rich
semantics documents that user agents take advantages of, but if at
the start the editing is failing, it is useless. As we say in French,
"Mettre la charrue avant les boeufs."
I think in English, the equivalent is: "To put the cart before the
>> The only way to do structure editing is to have a normalized
>> templating language, which can trigger specific UI for editing.
>> use this because they can have an immediate benefit of their editing.
> I think we're on a similar page, but "normalized templating
> language" is
> a bit too vague for me to be sure.
> IMHO, a good editor would make better
> use of the web itself, integrating automatically with online
> sources of
> metadata for languages, acronyms, abbreviation, acronyms, addresses,
> citations, and text/image/audio alternatives, only prompting the human
> user for metadata when required, and learning from their
> preferences. A
> good editor would ease communication by checking readability where
… but it is not enough. :)
The problem is to find also tools which are easy to develop for
authoring tools implementers.
For example, I do not like the multiplication of elements in XHTML 2
and Web Apps 1.0. I'm a lot more inclined to see things like
microformats and RDFa to enrich the semantics of a document. And I
really think it is easier for a developers to trigger UIs based on
attributes values than elements. In one case you have to ship a new
release of your products and then deal with different versions of
In the other case the microformats and RDFa can be designed in a way
which can be loaded automatically from the Web.
So it's why I would recommend to not overload the semantics of Web
Apps 1.0 by too many elements features, but having a well defined
mechanism for extensibility. The core would be a solid base, then the
rest being developed by community process. XHTML is a language which
is "good" for computing engineers (code, var, kbd, samp) and
scientists (q, cite, "mathml"). Not that much for people doing
litterature (poem, verse, etc.), for example.
>> Challenges indeed.
> Perhaps we need a language for HTML fragments? Or perhaps web pages
> HTML forms need to provide a sort of shell like
> <html>[...]<body></body></html> to the external editor? Or perhaps we
> need a meta language mapping BBCode, Markdown, Wiki markup, and
> flavours of (X)HTML to each other, so that end-users can write
> they feel comfortable with? At the very least, textarea should specify
> relevant specifications, namespaces, and microformat profiles,
The irony of things is that all of this equilibrium exercise comes
from the lack of HTTP PUT and control mechanisms for editing only
part of a document (which is in the process.)
>> Edit in textmate doesn't work in
>> - Camino
> Just to be clear, not even the cmd + ctrl + e hot key shortcut
> in the email I cited works?
Yes it's what I meant.
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
QA Weblog - http://www.w3.org/QA/
*** Be Strict To Be Cool ***
More information about the whatwg