Re: Proposing <indent> vs. <blockquote>

Elliot:

My battling of email clients is difficult enough as it is. Ironically 
it's because I'm using a somewhat WYSIWYG editor when I really want to 
be editing the raw text so I can have control, but Thunderbird does not 
let me.  So sorry, but no.

-Mike


Elliott Sprehn wrote:
> Can you please add a blank line before and after your responses mixed 
> in with the cited email? It makes it easier for everyone to read it 
> and figure out what's a quote and what isn't.
>
> Thanks,
> - Elliott
>
> On Apr 16, 2007, at 3:32 AM, Mike Schinkel wrote:
>
>>
>> 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 08:33:10 UTC