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
second.
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
horses."
The only way to do structure editing is to have a normalized
templating language, which can trigger specific UI for editing.
People
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.
Yes… :)
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
necessary.
… 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
your tools.
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
with
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
various
flavours of (X)HTML to each other, so that end-users can write
whatever
they feel comfortable with? At the very least, textarea should specify
relevant specifications, namespaces, and microformat profiles,
somehow.
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
mentioned
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 ***
