[whatwg] Graceful Degradation and Mime Types [was: trailing slash]

[Benjamin Hawkes-Lewis]

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.
text/plain, ODF, PDF, and perhaps some variety of SVG are all more
suitable formats, perhaps embedded in (X)HTML using OBJECT. If W3C or
WHATWG cared to come up with a simple, purely presentational markup
language, I'm sure that would be fine too.

Whenever people treat (X)HTML markup as presentational, they render
correctly authored documents ambiguous in practice, destroying their
interoperability and accessibility. 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.

> If the only way to edit structured document is hand coding then it  
> will fail. Always. 

The viability of hand coding depends on the complexity of the language
(HTML is overly complex, e.g. with the ampersand encoding rules) and on
people's existing training. There was a time when everyone was
effectively "hand coding" documents in WordPerfect and on Amstrad. There
was a time when WYSIWIG itself was what needed to be learnt. People
sometimes seem to forget that. BBCode is hand coding too. For some
reason, techies assume people find square brackets less confusing than
angle ones, even though BBCode was only devised as an alternative to
proper input checking:

http://en.wikipedia.org/wiki/BBCode

More importantly, WYSIWIG vs. hand coding is a false dichotomy. One can
imagine more intelligent, GUI editors that do not involve WYSIWIG. Lyx
offers a very crude, and poorly marketed, example; and something like
Lyx is much more applicable to online publishing than deadtree
publishing. Mellel looks like a prettier alternative, but without the
Latexy goodness:

http://www.redlers.com/mellel.html

> 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. 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. A good editor would use a real table builder, perhaps like:

http://accessify.com/tools-and-wizards/accessibility-tools/table-builder/

A good editor would radically and rigorously separate content from
presentation layers (i.e. alternate stylesheets), and make the later as
easy as possible (think templates in Latex and Apple's Pages). A good
editor UI would deal with different strengths of emphasis, not buttons
for [I] and [B]. A good editor would make structuring hypermedia easy
the way spreadsheets make relating numbers easy, the way PhotoShop makes
image editing easy. At the end of day, most people are no more familiar
with the correct typographical rules for indicating relevant concepts
than they are with the relevant concepts themselves. It therefore makes
more sense for them to deal with structure to begin with, than to throw
them into a presentational morass.

> Yep I think that would be a move forward. A real one.
> It would likely to remind the time of OpenDoc/CyberDog on Mac OS 8  
> for example
> 
Hmm. CyberDog is new to me:

http://en.wikipedia.org/wiki/Cyberdog

But that looks very similar to what the Mozilla applications already
provide (perhaps with less integration). If you want /more/ integration,
there's always Emacs. ;)

> > Web Forms 2.0 tries to help by including a type attribute. This is
> > better than nothing, but it's not great for two reasons. First,  
> > because usually user-contributed content comes in the form of parts
> > of documents (e.g. a string of HTML) not whole documents. Second,
> > because text/html is not nearly specific enough to cover even the
> > different branches of (X)HTML, let alone the microformats and so
> > forth.
> 
> 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.
> 
> 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?

--
Benjamin Hawkes-Lewis