W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007

Re: WYSIWYM editors

From: Robert Accettura <robert@accettura.com>
Date: Sat, 17 Mar 2007 23:29:30 -0400
Message-ID: <1174188570.45fcb21ab09ca@green.mynethost.com>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: Geoffrey Sneddon <geoffers@gmail.com>, public-html@w3.org

Quoting Daniel Glazman <daniel.glazman@disruptive-innovations.com>:

> Hear me well : this just does not work. It is *totally* utopic to expect
> from average people (worst case: the sales director of your company)
> they're ever going to think that way.
> So if you're not only trying to make them think in terms of content but
> also want them to understand what's a tag/element and that their content
> should be readable without style, I'm afraid you're totally lost in
> outerspace...

I still think it's possible, just not in the present form.  For example, getting
a designer (who is concerned with pixels rather than data organization) to
understand what HTML really is... is a waste of time... BUT it's possible, if
you work WITH rather than against.

Take the following as an example (it's not really a proposal): If the markup
were so that all tags were equal (think <span>,<a>,<img>,<input>, and a handful
of others as the only tags not depricated), and an attribute ("datatype") were
to describe the data in more casual terms of what it contains ("quote",
"citation", "navigation", "paragraph", etc. it's much more intuitive.  What's
actually being done is allowing for design to be done only through CSS, hiding
bullets in lists, making lists horizontal for the purpose of a nav, no more
block level/inline elements to confuse, and no worries about markup
"correctness".  At this point as long as you follow the xml-like rule of
nesting tags nicely... your golden.  Afterwards one can go and describe the
data, for SEO/Effective practices by using the datatype attribute.

This makes for a more practical approach.  A designer is often the one creating
the html for a web page.  Daniel is right... They don't care that a menu is
technically a list, or
that text is a paragraph, and not just a chunk of text with <br> thrown between.
 They won't bother to think that way.  Programmers who do think that way often
can't fix these mistakes.  So it's a lost cause.

If this approach were adopted, it would be easy to go back and define something
as a header, footer, menu, quote, etc. etc. without disturbing the design.

In the past this approach was in the reverse... separate the design out from the
data model.  What should be done is separate the data model out from the design.

As long as we have problems such as adding a header (<h1>) changes fonts
around... it will be a mess.  As long as we have obscure markup <q>, it will be
under utilized.  Despite the efforts of css, there is still design in HTML.

Just my $0.02.  Daniel is right, it hasn't worked, and won't work.  But I don't
think hope is lost.  The problem is that it doesn't work with a typical web
development workflow.

Content on the web isn't created by geeks, it's created by a more and more broad
group.  That needs to be understood.

/sorry for the long msg.

Robert Accettura
Received on Sunday, 18 March 2007 03:29:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 18 March 2007 03:29:46 GMT