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

[Mike Schinkel]

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.

"Less" is the keyword in nightmare, but it is still leaves a nightmare to
think that tools can solve so that hand-coding are unimportant.

What strikes me as so unusual is that direct seems to be counter to the W3C
philosophies for so many years.  I'm curious; has TimBL weighed in on this
issue?  

>> http://wiki.whatwg.org/wiki/HtmlVsXhtml

That looks like a great resource. I've printed it and will read and
contemplate it when away from the computer (I'm too A.D.D. when at the
computer.)

>> > P.S. If markdown IS the answer, I think the W3C needs to define a 
>> > standard for such markdown.  There are too many competiting 
>> > implementations for userrs to learn today.
>> 
>> hundreds, each developers implementing a Wiki is starting with 
>> the WikiWikiWeb syntax and then add stuff. If there is an abstract 
>> model of "Web Documents", then the rest is just a question of 
>> serialization. What Sam Ruby is doing in fact in the discussion.

In a nutshell, my issues with "markdown" per say are the following:

1.) There are too many competing versions. This would be not so bad if those
who needed to learn them were IT folks, but they are instead targeted at the
average Joe. Presented with too many syntaxes to learn and differentiate,
most people will just choose to do without using the web.
http://webrepair.org/01why/ has a great definition for accessibility:

	Contrary to popular belief, accessibility applies to any type 
	of access, not just to people with disabilities. When access 
	to some content is made dependant upon some technique 
	that cannot be relied upon to be available (javascript, CSS, 
	Flash, PDF, any specific Web browser, etc.), accessibility is 
	degraded. When DIV soup replaces semantic mark-up, 
	accessibility is degraded. When things like font-size are not 
	left up to the user, accessibility is degraded. When only 
	access through large screen/high bandwidth desktop 
	computers is anticipated, accessibility is degraded.

Using that definition, I believe the proliferation of markdown languages
negatively impacts web accessibility.  

What's more, it negatively impact interoperability. One of the the W3C's key
principles and one I firmly believe in is the principle to reuse instead of
build if at all possible (reuse schemes, reuse content types, reuse
protocols, etc.). This reuse ensures a greater percentage of previously
educated humans and existing software can already use and interoperate with
it, and each new implementation that uses it leverages the network effect.
With markdown, we have the opposite dynamics.

2.) As markdown languages evolve, their user desire them to become more
powerful and their developers add more features.  What they do, in essense,
is develop an alternate to HTML often co-opting HTML syntax because it is
easier to just pass-thru.  In my experience whenever people try to create a
technology that is designed to be a subset alternate of another technology
they invariably don't design if for functional scalability from the start so
as the developers add in more and more functionality its architecture starts
bursting at the seams. 

Look at Mediawiki. In some ways it's got a nice and elegant syntax (external
links just being enclosed in square brackets is very easy) but as they
needed more and more functionality the markup gets uglier and uglier (have
you ever tried to create a complex table in Mediawiki.  Yeech!)

So it seems to me that we'd all probably be better off if wiki's and forums
and blogs and cms and other just allowed HTML; then there would only be one
language to learn.  

OTOH, I could see another way.  I think this would make a lot of sense (this
is not a completely formed thought; consider the overall concept if not the
exact specifics, and also each point individually):

A.) Define varying levels (subsets) of HTML each with their own
doctype/media-type. 
B.) The subsets would remove various unsafe and difficult to implement
functionality.
C.) Wikis forums could then allow users to implement those subsets.

And/or:

A.) Analyze the needs of the markdown community.  
B.) Study all the different syntaxes.
C.) Come up with a markdown standard that can be incorporated into HTML
where existing HTML and the new systax could be mixed and matched.

For an example of this latter, imagine a new tag <subset> that can contain
any HTML but that also follow more markdown editing rules, i.e.:

<subset>
George W. Bush lives at the [http://www.whitehouse.gov White House]. Some
people love him, but others really [b]hate[/b] him.  

Many people want to see Bush impeached, for
[http://en.wikipedia.org/wiki/Movement_to_impeach_George_W._Bush#Rationales_
for_impeachment these reasons and more]:

* NSA warrantless surveillance 
* Justification for Invasion of IRAQ
* Violating the Geneva Convention
* Declassifying information for political purposes 

>From June to October 2006, support for impeachment increased 8%:
<table>
<tr><th>Impeachment</th><td>Zogby Poll 6/27-29</th><th>Ipsos Poll
10/8-9</th></tr>
<tr><td>Support</td><td>42%</td><td>50%</td></tr>
<tr><td>Oppose</td><td>50%</td><td>44%</td></tr>
</table>
Source: [http://www.afterdowningstreet.org/?q=node/3528
AfterDowningStreet.org]
</subset>

In addition, the <subset> element could accept a level parameter that
identifies to the browser what level of HTML subset should it allowed. For
example, the following could be defined by the browser as something that
just won't run:

<subset level="safe">
<script language="javascript" src="http://badlands.com/evil.js" />
<script language="javascript">
doSomethingEvil()
</script>
</subset>

Of course the problem user on the forum wouldn't include the <subset>
elements, the forum software would wrap his content with <subset> tags
(after first stripping "<subset" and "</subset>" from his contribution) thus
sandboxing anything he posts.

So if we were to embed the markdown into HTML and then have the browser
processes it we'd get:

* The markdown would actually go through an architecture design process as
opposed to being hacked together and evolved over time
* Ability for anyone to scale up or scale down what they use from the simple
markdown to full fledged XHTML and vice versa.
* A convergence toward a common markdown for end users with all the
associatiate benefits of commonality therein:
	* One markdown for people to learn
	* One markdown to write parsers for
	* Critical mass would invite publishs to offer books and cover in
magazines
* Better Security because markdown security is then handled by the browser.
No longer does each individual website and web app have to keep on top of
security holes, which most don't.

After writing this, it seems pretty clear that fragmented markdown is a
pretty big problem for web accessibility, and a divergent HTML/XHTML will
only make it worse.

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

P.S. Is "markdown" the best term? I just used the same term Rusty used.