W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: Proposing <indent> vs. <blockquote>

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Sat, 14 Apr 2007 15:02:12 +0100
To: public-html@w3.org
Message-Id: <1176559332.11681.114.camel@galahad>

Mike Schinkel wrote:
> It is becoming clear that the "common" author of HTML content if 
> woefully under-represented here.

I /am/ trying to speak on behalf of the common author and reader of HTML
content. But we have very different views about what would help common
authors and what the source of their "trials and tribulations" really
are. Everyone here is technically minded compared to common authors, and
for all you know I'm less technically minded than you. No offence, but
why should we assume you have greater empathy with common authors than
other contributors to the list? If you have some analysis or empirical
evidence to support your viewpoint that what common authors really need
in order to communicate it effectively is a hand-authored presentational
language, feel free to present it. (I'm not implying that hard evidence
of either point of view is easy to come by.)

> The problem you are ignoring is that screen readers would do better to
> ignore presentational markup than to recognize improperly used
> semantic markup.

That doesn't seem to hold true in formats that mix presentational and
semantic information in the document content, such as ODF and PDF. There
screen readers typically give access to both presentational and semantic
information. In fact, some screen readers (e.g. JAWS) give access to
this information even in HTML. That may aid authoring a bit, but it's
crucial when misinformed authors rely on presentational elements to
communicate. If yet more presentational markup is available, ignoring it
will not be an option either. Authors will use it to communicate, and
worse still will misuse it in lieu of servicable semantic markup (e.g.
indent instead of blockquote, li, and p).

You ask "how does [presentational markup] reduce the ability to
communicate" but then go on to suggest that we need presentational
information in order to organize material for "visually for maximum
comprehension". Surely any case where you need to specify custom visual
prompts to make HTML communicate points either to a paucity of semantics
in HTML or to a failure in the default rendering by browsers. Can you
think of any examples where there is not the case? What could indent
communicate that a semantic element with an effective default rendering
could not? And if it wouldn't communicate anything, than why would we
want common authors using it?

HTML isn't designed as a medium for visual self-expression, unlike Flash
for example. Our odd culture of formatting HTML differently on every
site and providing a hideous default presentation has been far more
burdensome on ordinary authors than semantic markup has. (Compare how
much easier it is to add something to a wiki than to make your own site
from scratch.)

> Try getting (almost) any company to change their CMS because it doesn't
> accomodate your needs

If you can make a strong accessibility or general business case it's not
impossible. If you can't make a strong accessibility or general business
case, then your desires probably revolve around styling not
communication. And if your problem is with an open source CMS, then you
can report the bug and either fix the problem yourself, hope someone
else fixes it, or even pay a bounty for someone else to fix it.

> People have been working on that problem most of my adult life.

I keep seeing variations of this claim, but I don't remember anybody
providing any tangible examples. As far as I can tell from our HTML
composing began with WYSIWIG and hand-authoring and ended up being
pathway-dependent on those models. I haven't noticed any attempts until
recently to develop serious interfaces for mass authoring of semantic
HTML, such as:

http://accessify.com/tools-and-wizards/

http://webrepair.org/

http://www.wymeditor.org/

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-February/009539.html 

What were their forebears that failed?

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

I'm confused. As far as I'm concerned, what makes WYSIWIG inappropriate
for HTML is that:

1. HTML is about what you mean (content/semantics), not what you see
(presentation).

2. The application of styles to HTML is not consistent across user
agents.

You seem to be want to turn HTML into a presentational language (or at
east provide presentational alternatives to semantic elements, which
amounts to practically the same thing). WYSIWIG would seem to be at
least a passable model for authoring in such a language, whereas
hand-authoring went out with the Mac and Word for Windows.

> You mean "w/o cite?" 

I mean using whatever reliable mechanism for associating citations with
quotations HTML5 ends up providing.

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

Even hand-authoring requires tools. e.g. a CMS is a tool; a text editor
is a tool. I'm just saying we should make those tools more fit for
purpose.

Having said that, I think semantics make hand-authoring HTML /easier/
not harder, even for common authors. (Not necessarily for newbie
authors, but that's not the same thing.)

> Anyway, I love <sic> the "encourage people to have better habits" 
> solution mindset.

Well, when I say that I include empowering people to do the right thing
by giving them the right tools for the job and taking away the features
that lead them astray as a /necessary/ component: evangelization alone
is not enough. So I've been hacking away on at least one crude tool to
do the job of associating quotations and citations:

http://www.benjaminhawkeslewis.com/www/hypertextuality/

(The next step is to hook that up to a ZOOM API so the browser can query
libraries for bibliographic information over the Z39.50 protocol; but
that will requiring implementation in XPCOM ... and that will require me
learning C++ and Mozilla internals. So progress will be slow.)

> we need pragmatic solutions, not idealistic ones.

Your devotion to the common author is an ideal we share, but I don't
think there's anything especially pragmatic about what you're proposing.

--
Benjamin Hawkes-Lewis
Received on Saturday, 14 April 2007 14:31:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:42 UTC