Re: Proposing <indent> vs. <blockquote>

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