- From: Mike Schinkel <w3c-lists@mikeschinkel.com>
- Date: Sat, 14 Apr 2007 19:49:47 -0400
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- CC: public-html@w3.org
Benjamin Hawkes-Lewis wrote: > 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. > Agreed. Understanding that is a good starting point. > Everyone here is technically minded compared to common authors, > And that's exactly the situation I was lamenting and why I said their concerns are under-represented here. > and for all you know I'm less technically minded than you. > I've seen your posts and your website for many months now, and I know for certain that you are more technically minded than me! > No offence, but why should we assume you have greater empathy with > common authors than > > other contributors to the list? > Good question, and maybe I erred, but I've been around development, training, and business for almost 20 years and I've come to recognize different patterns in value systems. What I see here in the value system among the people who are active in discussions is the value system of technical elegance. What I haven't really seen is the value system of pragmatic solution, at least not from the user perspective. I also know from experience that in discussions with people of varying technical skills (from my seven years of training programmers, and more) the more skilled people are the ones who discuss things and the less skilled are afraid to say anything for fear of looking stupid. I'm different; I know I'm stupid and have no problem being considered stupid, so I speak my mind. So there may be a majority on this list who have greater empathy for common authors, but it does seem many of them are speaking up. Again, this is as I see it, so I could be off base, but I can only report how I see it. I'm a rare breed as I really appreciate elegance, and actually prefer it, but I also recognize the value of pragmatism. > 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.) > I wish I did. You don't know bad I wish I did. I've looked for it but as you mention, it is hard to come by. 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. And I have a well known and well respective advocate for same, Jon Udell. (This is just one example where he addresses this, but his other comments are hard to find because what is unique there to google? [1]) >> 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). > I disagree that this is the issue you say it is. What's more, 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. You can ignore this or embrace it. Embracing it means not ignoring the fact authors will do the easiest thing, and if the easiest thing is not accessible, then you'll get inaccessible content. Make the easiest thing accessible, and you'll get what you want. <blockquote> misused is less accessible than <indent>; and least the latter is unknown vs. misused. But rather than continue this debate adnaseum maybe we should look at addressing this problem with more correct semantic markup? Add a @rel or @type attribute, or create a handful of new elements. But whatever the case, <blockquote> is misused and it creates a problem and ignoring that fact is not addressing that fact. > 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". > That still seems consistent to me. > 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. > That sentence did not make sense to me. Was it incomplete? > 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? > Yes, most of the time it would mean something, though not always, in the case of someone just wanting the visual appeal. Often it means "pay attention to this", so in that case it's the same as <em>. But then this would mean something too, no? <p style="margin-left:40px;">foo bar</p> So in essence you are arguing for elimination of inline styling, because people may use it when then should have denoted it with some semantic markup, right? (I know I'm attributing words to you that you did not say, but you did the same for me. ;-) The problem with requiring all content to be semantically marked up is that not everything fits into nice little buckets, especially if the analysis has yet to be done to identify those buckets. You've got to give people tools to express things as they will go around you if you do not. I've got a heavy database background, and I've spent the past 20+ years trying to fit data into nicely defined fields but I've come to realize that, no matter how much analysis I do, there is always something that doesn't quite fit so it's better to create catch-alls rather than trying to force everything to be a round peg. Universal accessibility is a nice goal, but its not realistic when you have most of the first world becoming content authors. You have to do your best to optimize accessibility, but draconian methods to enforce will just result in people going the virtual walls you built. 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! > 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?" ;-) > > 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? > 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? > 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. See my above comments to address your comments here. > (Compare how > much easier it is to add something to a wiki than to make your own site > from scratch.) > 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. 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. >> 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. > But almost completely impractical for the average person to get the company to change. 99.999% of people will just consider the source and go about their business. > If you can't make a strong accessibility or general business > case, then your desires probably revolve around styling not > communication. > Huh? The strong business case is empowering a lot more people to not write incorrect semantic markup, but that is apples and oranges as we were discussing the everyman's ability to get a company to change on his request, which is completely unrealistic to expect on a general basis. > 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? > Well, that's rather loaded. Any examples I give you you will just say were "not serious." But at risk of you using that tactic and understanding that my recognition is far better than my recall and that I use Windows thus far so those are the examples I know best: * HoTMetaL * FrontPage * Visual Studo * NetBeans * DreamWeaver * Windows Live Writer (which I love, but it is still far from WYSIWYG perfect) * The HTML editor in Outlook * The HTML editor in Word * Any and every Javascript-based WYSIWYG editor * The HTML editor in the Thunderbird that I am using right now On the flipside, give me ONE, just ONE HTML editor that can represent the full set of HTML w/o switching to a source.. 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. >> 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: > I'm confused too because I was replying to your comment about WYSIWYG. > 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.) If you'll get everyone to agree to that, I'll drop my request. > > 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. That is a fallacious argument. > 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. > Hand authoring went out with the Mac and Word for Windows? What planet are you living on? >> <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. > 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. > Having said that, I think semantics make hand-authoring HTML /easier/ > not harder, even for common authors. > Possibly, but that's tangential to the points here: * <blockquote> is misused and a semantics-free markup would be beneficial * HTML should be pragmatic, not ideological * Hand-authorability should be a goal. > (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? >> 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. Address the majority of the issues (i.e. @rel or @type for <indent>), but let the rest be free to do it without misuse (i.e. <blockquote>). > 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/ > Toolicious (see my signature) has many of the same goals, and might be able to work in conjunction with yours. >> 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. > We must agree to disagree then as I believe I am being exceedingly pragmatic, especially since you've not proposed an alternative. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us [1] http://www.infoworld.com/article/04/04/30/18OPstrategic_1.html
Received on Saturday, 14 April 2007 23:50:09 UTC