[whatwg] Authoring tools (was Graceful Degradation and Mime Types)

At 23:35 -0500 UTC, on 2006-12-02, Mike Schinkel wrote:

[...]

> Consider a blog/wiki/forum/cms/whatever [...]
> All of those web apps allow users to post comments. And
> many of the genre allow users to embed (a subset of) HTML to format their
> documents.  [...]
>
> [...] they will
> contribute to a (potentially) conforming site markup that does not conform.
>
> So what are the various answers to this solution?

[assuming you meant "solutions to this problem" ;)]

[1] Accept garbage and serve garbage
[2] Acept no garbage and return incomprehensible error message
[3] Accept no garbage & return excellent explanatory error message
[4] Accept garbage and change it into (at the very *least*) valid markup, at
the risk of changing it into something the author didn't mean

I would favour [4] for any site I run that needs to accept markup from
non-professionals, with an option to set it to behaviour [3] as a help tool
for professionals.

Option [1] will probably be practiced 'forever' by some, but if so then
that's just the case. If the owner of the site, or the author of the
publishing system has no ambition to produce accessible/useable/reliable
sites, no amount of magic is going to change that.

In the mean time, providing easy to work with tools that do produce reliable
and accessible sites, will probably make a change. Over time, people will
find out that with such tools, publishing on the Web is just less of a
headache. Especially if the current trend of user-agents becoming more
standards-compliant continues.

> -- Have the apps tell the user contributing how to clean up their
> contribution?  Nah, because most developers of these web apps won't include
> such validation then instruction, and most users wouldn't understand it if
> they did.

In many situations such behaviour would even be counter productive. What
would be appropriate and even what would be appreciated by the users of such
systems will depend on the situation.

I generally see 2 categories for Automated Web Publishing Systems [AWPS] as
I've dubbed such code generators: ones that need to accept content from
everyone, and ones that accept only from specific users.

For the first group I agree that it's a bad idea to put people off with
complaints about their markup skills. At the same time those people probably
aren't considering their forum post to be the next Mona Lisa, so option [4]
of fixing their markup at the risk of it looking different from what they
expected, seems quite appropriate to me.

For the second group, there will usually be one or more admins who should be
able to decide who can post what, including what level of markup they are
allowed to enter and whether or not a particular contributor's entries can be
publicized right away or should be queued for approval (markup-wise) by an
admin. The AWPS needs to provide methods that allow (configuration) of such
control levels.

The latter approach would allow such a system to not bother content
contributors too much (ideally definable in levels, per user or group) but
keep them happy and bug the admin with whatever cleaning up needs to be done
before the content can go public. The admin should use mode [3] to help him
with this task.

For either approach an AWPS should do its best to guide content providers.
Provided that is done unobtrusively, many people will probably prefer such
guidance to having to dump things in a black box. I'm convinced that many
people who are 'clueless' today are in fact quite willing to learn some
things, as long as they are being treated respectfully (which
incomprehensible error messages don't do). This is basically about general UI
design.

> -- Have the apps convert to the proper format. Possibly, but unlikely.  It
> is only likely if good and liberally-licensed open-source implements for
> *all* significant platforms are provided

Yeah, that should help. There are already a few tools out there, that AWPS
authors can integrate within their product. Besides validators, I'm aware of
various Tidy implementations and TagSoup (a markup cleanup engine). More are
needed though. Especially ones that provide very user-friendly error
messages. Providing such as free modular tools, that AWPS authors can
integrate into their products, should make it easier to get them to make the
effort. (Exactly how easy it will be to properly integrate such a tool into a
specific AWPS will of course depend on that AWPS's architecture. The cleaner
the architecture, the easier.)

ISOC recently started the Web Repair Initiative, a project that aims to get
some things moving on this terrain. See <http://webrepair.org/>. Will be a
lot of work, for sure. But we believe this can help improve the situation.
Contributions, in any shape or form, are more than welcome.

[...]

> -- Let HTML5 be the lax superset of XHTML.  Everything works great, users
> contribute what they know how to contribute, and there is no problem.

May sounds nice, but there will definitely be problems. "What they know" can
never be equal to "HTML 5" or whatever standard. HTML 5 can include an ESP
engine spec; define how certain common authoring mistakes should be treated,
so they'll result into something predictable. But there is no way HTML 5 can
define everything that people might possibly throw at the Web. To quote a
remark you made earlier: "(although how to ensure the clueless get a clue, I
have no suggestions.)  So this option is not very likely to produce good
results."


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Sunday, 3 December 2006 01:43:53 UTC