W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2006

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

From: Karl Dubost <karl@w3.org>
Date: Tue, 5 Dec 2006 09:25:22 +0900
Message-ID: <01363CDD-6F77-4048-88E8-9A3F6B1612BE@w3.org>

Le 5 d?c. 2006 ? 08:27, Benjamin Hawkes-Lewis a ?crit :
> On Mon, 2006-12-04 at 15:07 +0900, Karl Dubost wrote:
>
>> Give the possibility that the "textarea" of a form to trigger an
>> editor, (A kind of setenv $EDITOR "editorname")(potentially wysiwyg).
>> and/or implement a real wysiwyg editor for forms in browsers (which
>> sounds a bit silly when you really think about it)
>
>> There will be less nightmare of hand code editing.
>
> Nothing based on WYSIWIG principles will /ever/ produce good semantic
> markup.

agreed.

> Semantic markup is about what we think not what we see;

agreed.

> and what we think is difficult to deduce unambiguously from what we  
> see.

agreed.

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.
If the only way to edit structured document is hand coding then it  
will fail. Always. Microformats/RDF have the same problem. It is too  
complicated to hand edit. So let's look around us and identify when  
people do structure editing:

- Spreadsheet software (structured tables)
- Templates in word processing tools
- addressbooks (form-oriented applications)
- DB applications with UI
- Weblogs (only title, content, and category)

They are all based on constraints given by an editing template. 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.


> Also, the sheer variation of browsers and their configuration  
> ensures that
> others will rarely see the same thing anyway.

Not a problem. I was answering to the message which was advocating  
for hand coding. Hand coding addresses only a minority of Web  
technologies users.

> With that caveat, especially given the fact that most browsers compete
> to make textarea as unusable as possible, allowing users to open an
> external editor for text inputs and textarea is an extremely sane  
> idea.
> It's suggested by UUAG:
> http://www.w3.org/TR/UAAG10-TECHS/topics.html#form-control-orientation

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

> 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.

> CURRENT EXTERNAL EDITORS:

Thanks for all the references. Very helpful.

> Apparently, you can open a textarea in OmniWeb with TextMate using the
> "Edit in Textmate" Cocoa input manager:
[?]
> Safari also uses Cocoa, so this will work there too; it may also  
> work in
> Camino, though not as seamlessly:

Edit in textmate doesn't work in
	- Camino
	- Firefox
But it works perfectly in
	- Safari.

-- 
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 Monday, 4 December 2006 16:25:22 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:50 UTC