[whatwg] Authoring tools (was Graceful Degradation and Mime Types)

Sander Tekelenburg wrote:
>> In the mean time, providing easy to work with 
>> tools that do produce reliable and accessible 
>> sites, will probably make a change. Over time, 
>> people will find out that with such tools, 
>> publishing on the Web is just less of a headache. 
>> Especially if the current trend of user-agents 
>> becoming more standards-compliant continues. 

Tools are not the answer for many reasons.  One is that compatible tools are
not ubiqutiously available in all potential use cases.  If tools *were* the
answer, we could move to a binary format to save bandwidth.  One core reason
HTML/HTTP/URLs have been so successful is that the only tool people ever
really need to use them is a text editor.

>> those people probably aren't considering their 
>> forum post to be the next Mona Lisa, so 
>> option [4] of fixing their markup at the risk of 
>> it looking different from what they expected, 
>> seems quite appropriate to me.

Forum posting is but one of many contexts. I daresay non-technical people
who write blogs and wikis care about format, as do even forum posters.

>> For the second group, there will usually be one 
>> or more admins who should be able to decide 
>> who can post what, including what level of markup 
>> they are allowed to enter and whether or not a 
>> particular contributor's entries can be publicized 
>> right away or should be queued for approval 
>> (markup-wise) by an admin. The AWPS needs to 
>> provide methods that allow (configuration) of such 
>> control levels.

I think defining people in these two groups where one doesn't case about
what it looks like and the other will have the skills is either naive or
just wishing thinking.

>> Yeah, that should help. There are already a few 
>> tools out there, that AWPS authors can integrate 
>> within their product. Besides validators, I'm aware 
of various Tidy implementations and TagSoup (a markup 
>> cleanup engine). 

The tools need to be standard and compatible. That means the HTML5 Standard
needs to recognize a single base implementation on all relevent platforms,
and that implementation must be free to deploy without licensing
entanglements.  Otherwise, we will just have chaos.  I watched the chaos in
the Microsoft 3rd party developer tools community for 12 years; that's one
of the reasons I finally got fed up enough to leave. Without a catalyst to
give people a reason to all pick one specific implementation, then chaos
reigns. That is great in the market for solutions, but not something as
fundamental as HTML.

>> ISOC recently started the Web Repair Initiative, a 
>> project that aims to get some things moving on this 
>> terrain. See <http://webrepair.org/>. 

Interesting.  I will check it out.

>> >> -- Let HTML5 be the lax superset of XHTML.  
>> >> Everything works great, users contribute what 
>> >> they know how to contribute, and there is no 
>> >> problem.
>> May sounds nice, but there will definitely be problems. 
>> "What they know" can never be equal to "HTML 5" or 
>> whatever standard. 

I didn't say they would know HTML5.  They already know some HTML and some
XHTML; they should be able to use that and/or learn move of the common
subset.

>> HTML 5 can include an ESP engine spec; 

ESP engine spec?

>> But there is no way HTML 5 can define everything that 
>> people might possibly throw at the Web. 

I think you misunderstand what I propose.  I propose that XHTML and HTML5
move on a convergence path as opposed to a divergence path.  I'm not
suggesting it handle everything people want; quite the contrary. I'm just
suggesting they both do their best to both handle things the same way, as
much as possible, and that if it is valid in XHTML then HTML5 should accept
it whenever technically possible.

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/

Received on Sunday, 3 December 2006 21:48:38 UTC