- From: Mike Schinkel <w3c-lists@mikeschinkel.com>
- Date: Sat, 14 Apr 2007 06:59:26 -0400
- To: public-html@w3.org
Benjamin Hawkes-Lewis wrote: > Ease of use is a crucial goal, but I doubt HTML suitable for writing > everything from documents to web applications ever has been or ever will > be suitable for mass, still less universal, hand authoring. > It is becoming clear that the "common" author of HTML content if woefully under-represented here. Just as Microsoft's developers were all C++ developers in the 90's and Visual Basic developer's needs got ignored when APIs were developed, so are the needs of the "common" HTML author being ignored because of the tremendous experience of those participating in this working group. My guess is that almost nobody in this working group can actually appreciate the trials and tribulations of an HTML author does not have the skill to build everything from scratch and that doesn't understand HTML and CSS specs intuitively. Comprehending what is just too hard for most people is outside of your grasp. And that is a real shame, because there are many orders of magnitude more "common" HTML authors than there are with people who have your level of understanding. > Reintroducing presentational elements would (at best) introduce further > layer of indirection between what people mean and their HTML. The > problem is not that presentational markup is necessarily > non-interoperable, but that it is deeply ambiguous. Screen readers and > voice browsers, for example, would either need to ignore indent (risking > communication failure) or report it every time in case it was being used > with special purpose, slowing down reading time and forcing the user to > guess what it might mean in any given instance. > The problem you are ignoring is that screen readers would do better to ignore presentational markup than to recognize improperly used semantic markup. > One could make HTML a little more suitable for widespread hand authoring > by removing the requirement to encode ampersands, forcing use of a > unicode character set where entities would be unnecessary except to > escape HTML markup, and separating out a kernel of semantic markup used > for basic communication (e.g. a, quote, p, br, em, ul, ol, li, abbr, > section, heading, img, video, table, tr, th, td, and span for changes of > language). Adding indent, i, b, font, and friends would dramatically > complicate that subset while reducing its ability to communicate across > the board. > Dramatically? Are you sure you are not being a touch melodramatic? And how does it reduce the ability to communicate? > We do have a way of encoding information that is usable for mass hand > authoring: it's called text/plain and many authors already use it for > blog comments. It's also trivial to produce a client that word-wraps > automatically and follows URIs in plain text: most email clients do this > already. Please re-read my prior emails; I mentioned blog posts in addition to comments, and few serious bloggers use only text/plain. There is an explosion in the use of HTML in social media; text/plain just doesn't cut it for all those things; if it did, we wouldn't have this WG. text/plain has it's uses, but this is not the TEXTPLAINWG. > If formatting HTML is difficult, effective responses would be: > > 1) To improve CSS's usability. I think the usability problems of CSS > relate primarily to page layout not text formatting though. > That's well outside the scope of this WG. Also given CSS' history, I would look to it addressing any issues any time soon. > 2) To encourage authors to rely on browsers' default presentation. > You mean get people to display content in ways that are not organized visually for maximum comprehension? This makes no sense to me. > 3) To improve browsers' default presentation (e.g. by increasing > line-height to say 1.5 improve legibility). > I probably agree but that addresses line-height not margin and the principles I brought up. > The more limited benefit adduced to including presentational elements is > to allow authors who do not control the presentation of host documents > to force a useful presentation in the sections they author. This sounds > like it should be mentioned to the authors and possibly reported as a > bug with the default CSS and documentation for the CMS in question. > That is a completely unrealistic solution. Try getting (almost) any company to change their CMS because it doesn't accomodate your needs. Good luck. > Many CMS require input by hand authoring because we haven't devised > effective tools for expressing what people mean rather than how people > want to format their text. People have been working on that problem most of my adult life. It's not going to be solved soon. > Many other systems use would-be WYSIWIG GUIs, presumably because their creators don't agree that hand authoring is > easier than using tools. > 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. <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. > With regard to how robots can treat blockquote currently, any blockquote > with the cite attribute is highly unlikely to be misused for > indentation. So rather than introducing indent we should encourage > providing citations for quotations. > You mean "w/o cite?" Anyway, I love <sic> the "encourage people to have better habits" solution mindset. If that worked, we'd all be at our ideal weight, no one would be procrastinate and be unsuccessful, no one would be addicted to drugs, and there would be no AIDS epidemic. But we both know that's not the reality and so we need pragmatic solutions, not idealistic ones. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us
Received on Saturday, 14 April 2007 10:59:57 UTC