Re: Proposing <indent> vs. <blockquote>

Benjamin Hawkes-Lewis wrote:
> Ease of use is a crucial goal, but I doubt HTML suitable for writing
> everything from documents to web applications ever has been or ever will
> be suitable for mass, still less universal, hand authoring.
>   
It is becoming clear that the "common" author of HTML content if 
woefully under-represented here. Just as Microsoft's developers were all 
C++ developers in the 90's and Visual Basic developer's needs got 
ignored when APIs were developed, so are the needs of the "common" HTML 
author being ignored because of the tremendous experience of those 
participating in this working group. My guess is that almost nobody in 
this working group can actually appreciate the trials and tribulations 
of an HTML author does not have the skill to build everything from 
scratch and that doesn't understand HTML and CSS specs intuitively. 
Comprehending what is just too hard for most people is outside of your 
grasp. And that is a real shame, because there are many orders of 
magnitude more "common" HTML authors than there are with people who have 
your level of understanding.
> Reintroducing presentational elements would (at best) introduce further
> layer of indirection between what people mean and their HTML. The
> problem is not that presentational markup is necessarily
> non-interoperable, but that it is deeply ambiguous. Screen readers and
> voice browsers, for example, would either need to ignore indent (risking
> communication failure) or report it every time in case it was being used
> with special purpose, slowing down reading time and forcing the user to
> guess what it might mean in any given instance.
>   
The problem you are ignoring is that screen readers would do better to 
ignore presentational markup than to recognize improperly used semantic 
markup.
> One could make HTML a little more suitable for widespread hand authoring
> by removing the requirement to encode ampersands, forcing use of a
> unicode character set where entities would be unnecessary except to
> escape HTML markup, and separating out a kernel of semantic markup used
> for basic communication (e.g. a, quote, p, br, em, ul, ol, li, abbr,
> section, heading, img, video, table, tr, th, td, and span for changes of
> language). Adding indent, i, b, font, and friends would dramatically
> complicate that subset while reducing its ability to communicate across
> the board.
>   
Dramatically?  Are you sure you are not being a touch melodramatic?  And 
how does it reduce the ability to communicate?
> We do have a way of encoding information that is usable for mass hand
> authoring: it's called text/plain and many authors already use it for
> blog comments. It's also trivial to produce a client that word-wraps
> automatically and follows URIs in plain text: most email clients do this
> already.
Please re-read my prior emails; I mentioned blog posts in addition to 
comments, and few serious bloggers use only text/plain. There is an 
explosion in the use of HTML in social media; text/plain just doesn't 
cut it for all those things; if it did, we wouldn't have this WG. 
text/plain has it's uses, but this is not the TEXTPLAINWG.
> If formatting HTML is difficult, effective responses would be:
>
> 1) To improve CSS's usability. I think the usability problems of CSS
> relate primarily to page layout not text formatting though.
>   
That's well outside the scope of this WG.  Also given CSS' history, I 
would look to it addressing any issues any time soon.
> 2) To encourage authors to rely on browsers' default presentation.
>   
You mean get people to display content in ways that are not organized 
visually for maximum comprehension?  This makes no sense to me.
> 3) To improve browsers' default presentation (e.g. by increasing
> line-height to say 1.5 improve legibility).
>   
I probably agree but that addresses line-height not margin and the 
principles I brought up.
> The more limited benefit adduced to including presentational elements is
> to allow authors who do not control the presentation of host documents
> to force a useful presentation in the sections they author. This sounds
> like it should be mentioned to the authors and possibly reported as a
> bug with the default CSS and documentation for the CMS in question.
>   
That is a completely unrealistic solution.  Try getting (almost) any 
company to change their CMS because it doesn't accomodate your needs. 
Good luck.

> Many CMS require input by hand authoring because we haven't devised
> effective tools for expressing what people mean rather than how people
> want to format their text. 
People have been working on that problem most of my adult life. It's not 
going to be solved soon.

> Many other systems use would-be WYSIWIG GUIs, presumably because their creators don't agree that hand authoring is
> easier than using tools.
>   
And I have yet to see a WYSIWYG GUI for HTML that doesn't have 
significant limitations.  Name one and I'll show you one that has 
unacceptable limitations.

<Soapbox>TOOLS ARE NOT AND NEVER WILL BE THE ANSWER.</Soapbox>
Hand-authorable content is what is needed, and tools can we created on 
top of it.
> With regard to how robots can treat blockquote currently, any blockquote
> with the cite attribute is highly unlikely to be misused for
> indentation. So rather than introducing indent we should encourage
> providing citations for quotations.
>   
You mean "w/o cite?" 

Anyway, I love <sic> the "encourage people to have better habits" 
solution mindset.  If that worked, we'd all be at our ideal weight, no 
one would be procrastinate and be unsuccessful, no one would be addicted 
to drugs, and there would be no AIDS epidemic. But we both know that's 
not the reality and so we need pragmatic solutions, not idealistic ones.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us

Received on Saturday, 14 April 2007 10:59:57 UTC