Re: Proposing <indent> vs. <blockquote>

Benjamin Hawkes-Lewis wrote:
> Since helping authoring tools is now within its remit, should not the
> Working Group conduct some actual usability testing with ordinary people
> from different constituencies and with various abilities (e.g. geeks who
> aren't web professionals, technophobic newbies, political bloggers,
> MySpace users, people with visual or mobile or learning disabilities) of
> different authoring forms? It is impossible to settle the question of
> whether there are better models for web authoring than WYSIWYG or text
> editor authoring without first developing tools exploring such models.
The problem there is it is a complex question so how does one accurately 
design a usability study whose results would be valid?
> But we could at least assess how easy people really find using HTML with
> current WYSIWYG and text editor systems (and learn how to make both
> easier and produce superior markup).
I think the very fact that no tools except text editors are available in 
all environments where HTML is applicable argues strongly that HTML 
should be designed with a strong leaning towards hand-authorability.
> In addition, should not the Working Group conduct some actual usability
> testing for each feature, or at least each new feature, in HTML5? I do
> not believe that simply dumping features on the World Wide Web
> constitutes usability testing of any meaningful sort, since HTML
> features are filtered through crass educational systems (e.g. w3schools,
> MSDN, the dire deadtree books people learn HTML from), broken user
> agents (e.g. the sorry fate of <q>), broken CMS (e.g. generating invalid
> and oft inaccessible HTML), and broken WYSIWYG authoring tools (e.g.
> misuse of <strong> for the [B] (bold) button).
Maybe a good idea, but it would be extremely vast in scope and hence and 
hence wonderfully expensive.
>> But I do have anecdotal evidence that the languages that have been 
>> easy to hand code have gained more rapid adoption.  RSS vs RDF, HTML 
>> vs SGML, Visual Basic vs. C++, Python vs. Perl, for example.
> I think the problem with this is that what may hold true for developers
> programming does not necessarily hold true for ordinary people writing
> web content. My experience of recommending text editor authoring over
> WYSIWYG to everyone who asks on the basis that WYSIWYG tools are
> fundamentally broken suggests that ordinary newbies generally prefer
> WYSIWYG and consider text editor authoring to be scary "programming".
You are looking at today, not 10 or 15 years out.  Many of those people 
who view it to be scary will be retired, and many of the kids who cut 
their teeth on computers will be using HTML.

But fundamentally, tools constantly change as vendors get bought or 
morph, new products constantly emerge, and we never get to a "perfect" 
tool. A language as fundamental as HTML shouldn't be designed that it 
*requires* a tool beyond a text editor.  Tools should be viewed as 
beneficial but not a requirement.
> This even holds true with newbie visually impaired authors, who I'd have
> thought would be a natural non-technical constituency for text editor
> authoring. See for example:
>
> http://www.gwmicro.com/Support/GW-Info_Archives/index.php?postID=10515
>
> http://www.freelists.org/archives/nvda/04-2007/msg00215.html
Over time, the number of people willing to be hamstrung my a requirement 
for tools will be less and less.  Tools will be beneficial, but they add 
a layer of complexity on top of text that should be able to be peeled 
away because I doubt anyone will ever be able to build a WYSIWYG tool 
that will be available in all environments and will meet the needs of 
all users. This is such a fundamental principle I find it hard to even 
discuss it; To me it's a lot like a postulate; something that is so 
obviously true that its proof is difficult if not impossible.
> most authors don't care about accessibility because it is a lot more 
> "costly" to develop accessible content than not.  Most authors 
> implicitly make a cost-benefit decision and chose not to address it.
>
> This remains true of many web professionals and people commissioning
> small retail websites. I doubt it's an accurate characterization of the
> "common" authors of social media.
I don't follow who you are referring to.
> Web accessibility issues are a novelty
> to most of the ordinary people I speak too. They don't know what screen
> readers are, for instance; some express surprise that blind people can
> use the web at all.
Exactly. Until you people actually experience the need, most will never 
even consider it.  Sad, but true.  So we need to make accessibility come 
as close to "free" as possible.
>> <blockquote> misused is less accessible than <indent>
> I don't think people's desire to format text should take priority over
> everyman accessibility issues. 
You don't get it!.  You don't have the ability to make that choice for 
them; they will make their own choices no matter what you think.  If you 
want to make things better you need to accommodate the fact people will 
do what is easiest, accessibility be damned. Make the easiest thing the 
most accessible thing and accessibility wins a lot.  Make the easiest 
thing less bad and accessibility wins a little. That's what I'm proposing.
> If newbie authors need to understand one
> thing above all others, it's that HTML is about what they mean not 
> WYSIWYG.
Newbie authors don't NEED to understand anything. They will understand 
what they will, your opinions be damned.  What YOU need to understand is 
this reality, and that to improve things you have to cater to them.
> I think supporting "visual appeal" within HTML itself makes the language
> harder to use for both authors and readers.
I'll say again, it's not what you think that is important, it's what 
people will do.
> And anything that even sometimes "mean[s] something" must /not/ be 
> ignored by assistive technology.
Again, it is better to have an unknown than a known that is misused.  I 
still don't think you've addressed that (at least not thus far in my 
reading of your replies.)
> I regard inline styling as a detrimental practice. But I don't seek the
> style attribute's deprecation from HTML. Ruby on Rails is successful
> because it is "opinionated software": it makes good practices trivially
> easy without making "bad" (but conceivably /useful/) practices
> impossible; I believe that is a good model for HTML 5 to follow.
That sounds like an argument for <indent>...

BTW, don't get me starting on Ruby on Rails. ;-)
> I'd prefer W3C provided demonstrable use-cases with
> new (preferably semantic) elements /before/ said use-cases pollute the
> web with misused markup. 
Frankly, I'd prefer a lot of things but we have to work with what "is" 
and not with what we'd like.
> XHTML 2's roles module, the microformats movement, and WHATWG's aim of 
> making HTML5 forwards compatible are all attempts to meet this need.
As an aside, I think the microformats movement as is is destined to 
create far more problems than it will solve.  JMTCW
> 100% accessibility is an ideal not a target, but I certainly believe
> that mass accessibility is reconcilable with widespread authorship and a
> sine qua non of mass authorship.
Can you provide any support for this belief?

>> And the misuse of <blockquote> is a perfect example. The irony is
>> I'm arguing for an <indent> with no semantics (or something similar)
>> for the exact reason you are arguing against it; to improve the
>> quality of semantic markup on the web!
> Semantic markup that common authors aren't going to use doesn't 
> particularly interest me (I recognize TEI and MathML have their places 
> in specialist circles, but we're talking HTML here.)
What semantic markup are you referring to here?
>>> And if it wouldn't communicate anything, than why would we want 
>>> common authors using it?
>>>
>> You know, doesn't that sound a bit "Big Brother-ish?" ;-)
> Not really. Big Brother was all about shutting down thought. I want to
> prevent the free flow of ideas being hindered by styling misused to
> express ideas in ways that everyman (i.e. almost every person) cannot
> understand.
But you still want to control things, and I'm saying it's better to 
loosen the reigns and empower people. Given the constraints but no so 
much that they suffocate.
>>> HTML isn't designed as a medium for visual self-expression, unlike 
>>> Flash for example.
>> It isn't?  I feel like I'm expressing myself every time I use HTML. 
>> What am I missing?
> But you're not /visually/ expressing yourself (to me) when I view your
> blog in Lynx, fire it up in my mobile browser, apply a user stylesheet
> to it in Firefox, or have Opera read it to me. And that's how HTML was
> designed. By contrast, Flash was designed for animations.
You may use Lynx, and you may apply a user stylesheet in Firefox or 
Opera, but most people don't.  And I'm expressing myself to the vast 
majority of people when I write in HTML, not the outliers.  And I'll bet 
the vast majority do the same.
> And that's how HTML was designed. By contrast, Flash was designed for 
> animations.
Although I'll give you Flash, I'm pretty sure HTML was designed for 
both. OTOH, I think you would have liked for it to be designed without 
visual aspects, but reading "Weaving the Web" that's not what I read. 
And that's not what has happened. For the most part HTML is about 
pragmatic publishing of information which includes both semantics and 
presentation.
>>> Our odd culture of formatting HTML differently on every site and 
>>> providing a hideous default presentation
>> Our culture?  I'm confused.  Isn't it user agents that render, not 
>> people?  Do user agents have culture? Do androids dream of electric 
>> sheep?
> I meant the (human) culture that creates styled content and
> develops and chooses browsers to view it.
Besides me really being confused by your comment, I was hoping you'd 
catch my subtle cultural reference.  Too bad, I think it was a good pun. :-)
>>> has been far more burdensome on ordinary authors than semantic 
>>> markup has.
>> Semantic markup has not been a burden because the authors do not see 
>> it, so they ignore it.
> The evidence is against the notion that ordinary authors don't use
> semantic markup. Consider the front page of a popular American political
> blog:
> <snip>
> If authors do not "see" this markup, it is because they choose WYSIWIG
> tools over text editor authoring and do not see /any/ markup at all.
Two websites from professional bloggers do not make a statistically 
accurate point. I could easily find two counterexamples, but it would 
prove nothing.
>> A wiki is a perfect example of the kind of problem that occurs! Look 
>> at Mediawiki's syntax; it's so complex now as to be overwhelming.
> At least in the case of Wikipedia, that's largely because there's more
> than one way to do any one thing. That's another reason not to introduce
> <indent>.
Not really. Are there multiple ways to do bold?  Underline?  Italics?  
And the big one: tables? 
>> I've actually thought a lot about this, and if I had a platform to 
>> make changes I would be advocating that we get rid of wiki syntax and
>> just get everyone to understand HTML. That way they could learn it 
>> once and be done with it. Of course HTML would need to become a bit
>> easier to hand-author.
>
> More like a /lot/ easier - starting with the need to encode ampersands.
That I don't debate. But the problem is any markup language used to 
simplify HTML ends up becoming increasingly more complicated as its 
evolution forces it to approaches HTML's functionality.  Better to 
simplify basic HTML and have only one markup language for people to 
learn rather than tens or hundreds of obscure ones.
> I suspect the business case for accessibility is stronger than most
> people realize. Also, by raising the spectre of litigation, tightening
> accessibility laws are strengthening it still further.
Again, I support your goal. We just disagree on how to get there.
> But perhaps the way to combat individual web user powerlessness against
> companies is to begin to organize corporate action. I've been thinking
> recently that many inaccessible sites remain inaccessible because the
> people experiencing the problems don't have the technical skills to
> identify and articulate problems and solutions, and wondering if
> creating a bugzilla where reports could be refined before being mailed
> to webmaster would help. Even a template email where users report what
> OS, browser, and assistive technology they are using and how what
> happens differs from their expectations, and which provides links to WAI
> and other resources, would help.
Good idea, but who would implement?   

Bringing up a suggestion I made on another forum, things would be a lot 
better if IE would display a green icon for valid HTML and a red one for 
invalid HTML so validity would finally become "visible."
>> On the flipside, give me ONE, just ONE HTML editor that can represent
>> the full set of HTML w/o switching to a source..
> How is representing "the full set of HTML", rather than the /relevant/
> set of HTML, a useful goal?
Who defines relevant?
>> One of the biggest problems with the "TOOLS WILL SAVE THE WORLD" 
>> mindset is that each tools is only available in a subset of the 
>> contexts where HTML can be used, yet text editors are available in 
>> 100% of the contexts where HTML will be used.  This is the 
>> insurmountable reality that the toolset mentality can never address.
>>
>> AND, you are ignoring the benefits of the "view source" effect. 
>> Hand-authorable HTML is also a lot more readable.
> I don't object to hand-authorable HTML at all, but only to the notion
> that HTML is /best/ authored by hand. 
I don't think it is best authored by hand either. But I think it should 
be *able* to be hand authored as a primary requirement.  Not having this 
as a requirement ends up giving rise to justifications for overwhelming 
complexity with rationalization like "Don't worry, the tools will handle 
it."  That's what the primary author of XBRL told Jon Udell when Jon 
complained of inability to author XBRL by hand. Jon believed that the 
inability to author XBRL by hand was to XBRL's detriment. And I 
wholeheartedly agree.
> And because I think hand-authoring
> HTML in a text editor is a technical task, I don't think the "view
> source" effect has much relevance for common authors like bloggers and
> forum posters who tend to choose WYSIWYG tools.
People learn from view source.  People often discover how to fix broken 
links with view source.  People discover ids (for URL fragments) with 
view source. View source is one of the many powerful reasons why the web 
has been such a success. Just because most people won't use it doesn't 
mean it should be dismissed.
> I think <indent> would be detrimental to source view. I find semantic
> elements buried in presentational soup extremely difficult to read. It
> gives me headaches trying to untangle the stuff.
Here's where you and I disagree.
>>> 1. HTML is about what you mean (content/semantics), not what you see 
>>> (presentation).
>>>
>> If that is actually completely true, then we should eliminate ALL 
>> default presentational behavior from ALL elements (p, h1..hn, 
>> table/tr/td, ol/ul/li, etc.)
>
> That's a non sequitur. 
Is it really?  You said "HTML is about what you mean 
(content/semantics), not what you see (presentation)"  If it is not 
about what you see, why shouldn't we remove ALL default presentational 
behavior?

Honestly, I asked the question to trap you. It is not a non sequitur 
because if your assertion is false, i.e. that presentation should not be 
part of HTML then your arguments against presentation do not hold.  You 
can't have it both ways. 
> What I'd like to see is authors writing semantic
> HTML and user agents rendering all features of that HTML in a consistent
> (at least within a single user agent), beautiful, and understandable
> manner by default. Ordinary authors wouldn't have to worry about CSS.
> Web designers could continue to use CSS. I'd like to see W3C produce
> suggested stylesheets containing default presentation for all elements.
> Web designers might wish to use those stylesheets as a base, so they
> don't have to specify everything from scratch. I want the pain taken out
> of web authoring.
I actually agree with all of that, which is why your dislike for solving 
the misuse of <blockquote> so surprises me.
>>> You seem to be want to turn HTML into a presentational language
>>>
>> You seem to misread my intentions.  I don't want to turn it into a 
>> pure presentational language any more than I want to pure semantic 
>> language. I want to address most common use cases in a pragmatic way.
>>
>>> (or at east provide presentational alternatives to semantic 
>>> elements, which amounts to practically the same thing).
>>>
>> Your assertion that they are the same does not make it true.
>
> What I mean is that creating presentational elements that could be used
> instead of semantic ones will leave the semantic elements largely unused
> by "common" authors, so they might as well not exist.
The problem is you can't get common semantic ones for every use-case, so 
you need catch-alls for those that don't fit.  Over time we can identify 
new common use-cases and there will be less and less need for 
catch-alls, but the need will still be there.  It's why we database 
developers put a "Notes" field in most entity records to give users a 
place to put stuff that doesn't fit elsewhere.
>> And I am saying we first make it hand-authorable with a text editor, 
>> THEN we build those tools. Doing otherwise, therein lies madness; 
>> believing that we can use tools to hide too complex markup will lead 
>> us down a sordid path from which we cannot recover.
> No objections here but: my experience is that semantic markup produces
> simpler markup every single time.
I'm not sure I disagree, but how do you deal with the things were 
nothing quite fits?  Currently HTML has many cases where things just 
don't quite fit.
>> * HTML should be pragmatic, not ideological
> In the absence of concrete distinctions this is fluff, but I think I 
> agree.
One concrete example is <indent> vs. no <indent>!
>>> (Not necessarily for newbie authors, but that's not the same thing.)
>> Can you define your distinction between common and newbie authors as 
>> I believe many of the former are the latter?
> Fair point: newbie authors are properly a subset of common authors. What
> I was getting it is this: newbies may initially find writing with
> semantics confusing, just as once people found writing with WYSIWYG
> interfaces confusing. But once familiar, semantics make writing much
> easier. As social media uptake spreads and semantics becomes as
> culturally familiar as WYSIWYG, this obstacle will cease to
> exist - unless we occlude semantics with broken WYSIWYG tools, which is
> what is in fact happening.
Well, I believe people won't learn semantics until there is some visual 
benefit they get out of it.  That's why I hope to achieve with Toolicious.
>>>> 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.
>> But an abstinence/prohibition stance is not workable either.
> The operating idea here is that people abuse markup because they want to
> achieve presentational effects. While this is obviously commonplace, I
> think it often points to an underlying desire to express a semantic to
> which HTML authoring tools do not properly cater. If authoring tools had
> dropdowns for "Foreign phrase..." (using <span lang="whatever">) and
> "Book title" and "Movie title" (using <span> with hCite), I think a lot
> of <em> abuse would disappear. If tools offered even more functionality
> around such features, such as reading your text with the correct
> pronunciation or inserting (say) Amazon and IMDB links automatically,
> then abuse of <em> might disappear from new content almost entirely.
But expecting tools to solve these problems is a Faustian bargain as you 
can't depend on the tools to be available. That's why raw HTML needs to 
be designed to address the problem.

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

Received on Monday, 16 April 2007 07:33:34 UTC