[whatwg] XHTML Considered Harmful

[Brad Neuberg]

Hi folks. I've recently put up a blog post that
mentions the WHAT working group and which brings up
issues that I think are important in the creation of
WHAT standards. The post is basicly a list of reasons
on the mistakes and problems with XHTML and why the
XHTML religion is impeding progress on the web.  Some
of these issues could be solved by the WHAT working
group's respecification of a new XHTML standard, which
I know is currently happening:

http://codinginparadise.org/weblog/2005/08/xhtml-considered-harmful.html

I'd love to see people's responses to what I've posted
there, and to see the lessons spelled out there
incorporated into WHAT specs.

Best,
  Brad Neuberg
  bkn3 at columbia.edu
  http://codinginparadise.org


--- Matthew Raymond <mattraymond at earthlink.net> wrote:

> James Graham wrote:
> > Matthew Raymond wrote:
> > 
> >>Ian Hickson wrote:
> >>
> >>
> >>>On Fri, 26 Aug 2005, Matthew Raymond wrote:
> >>>
> >>>
> >>>>So, effectively, what you're saying about
> <textarea accept="text/html"> 
> >>>>is the following:
> >>>>
> >>>>1) The HTML in a <textarea> is unstyled (at
> least unstyled by the parent 
> >>>>document) unless styles or stylesheets are
> specified within the 
> >>>><textarea> contents.
> >>>
> >>>There is no defined rendering for <textarea>. The
> UA would be perfectly 
> >>>within its rights to interpret the contents of
> such an element and style 
> >>>it using the styles of the containing document.
> >>
> >>
> >>   The trouble is that if you don't have a DOM,
> CSS really doesn't make
> >>a lot of sense. For instance, "textarea p" is
> illogical because the <p>
> >>element isn't actually a child of the <textarea>
> because the control can
> >>only have a text node as its child.
> > 
> > 
> > Right but there's nothing to stop a UA creating a
> DOM from the text in 
> > the textarea and making this avaliable in some
> implementation-dependent 
> > way.
> 
>    Yes there is: XHTML. Legacy XHTML user agents
> will treat the document
> as invalid. In theory, you could require that the
> initial text be
> encoded and transformed into HTML at load time, but
> that's a pain for
> developers, and some have already voiced their
> opposition to it.
> 
> > I can certianly imagine a Firefox extension
> designed to replace a 
> > <textarea accept="text/html"> with an <iframe
> contentEditable> to allow 
> > WYSIWYG HTML editing.
> 
>    I don't like the idea of a rich control as being
> the OPTIONAL method
> of editing the content. In the long term, people
> will just use
> |contenteditable| and XBL2, which is suboptimal from
> a compatibility and
> efficiency standpoint.
> 
> > I can equally imagine a situationwhere WYSIWYG 
> > isn't required and instead the textarea is
> presented as an ordinary 
> > control but with UA-provided syntax highlighting
> (this should be easy to 
> > implementgt where browsers use native widgets that
> already support 
> > highlighting) or a situation where the user is
> given an "edit..." button 
> > on the textarea that opens the contents in an
> emacs (or other external 
> > editor) buffer and allows changes to be made.
> 
>    That would be nice in some cases, but it doesn't
> really match the
> rich textbox use case. Besides, I don't advocate the
> removal of
> |accept|. It's great for stuff like BBCode and the
> like.
> 
> > Clearly these last two
> > willalso work if the accept value is
> application/javascript or 
> > whatever,as well as HTML.
> 
>    Exactly. <textarea accept> is better suited for
> enhanced editing,
> whereas <htmlarea> is better suited for
> WYSIWYG-style editing.
> 
> > Not having a required WYSIWYG rendering for
> <textarea 
> > accept="text/html"> may be a strength rather than
> a weakness.
> 
>    That depends on the use case. It's a strength for
> experts that want
> control of the actual markup. For more basic users,
> they may not even
> understand the markup and would prefer a simple
> WYSIWYG editing interface.
>