- From: Karl Dubost <karl@w3.org>
- Date: Wed, 6 Dec 2006 09:16:55 +0900
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 ***
Received on Tuesday, 5 December 2006 16:16:55 UTC