[wp-hackers] Re: [wp-svn] [2476] trunk/wp-admin/quicktags.js: Quicktag enhancements

[jill]

Bruce Alderson wrote:

>
>> I think button labels should match output as closely as possible. If the button says 
>"strong",
>> the output should be <strong></strong>, and if it says "bold", the output should be
>> <b></b>. Second-guessing users' familiarity with markup is to start down a broad paved
>> road leading directly to the tiger pit. 
>
>Even better, why not just use a rich editor?  This tag soup is
>
>http://www.themaninblue.com/experiment/widgEditor/
>
>GPL, portable, etc.

It's really pretty. I mean that. And easy to use off the bat. But it's not XHTML 1.1 compliant,
either, according to the readme. And more to my point, it also has buttons that set up an
equivalency between "bold" and "strong" and "emphasis" and "italic".  These are not
synonyms. "Strong" does equate to "bold", nor "emphasis" to "italic". The bolded or italicised
text display is merely the default visual rendition of strongly or emphatically spoken
phrases. Via CSS, <strong> can be displayed as damn near anything, without losing its
auditory essence, and the same with <em>. Treating the default visual display as being cast
in stone, as is done when the button label indicates bold while the output is <strong>,
serves in the long run to limit the user without in any way clarifying the reasoning behind
creating semantic tags and promoting their use. Website owners end up tagging by rote,
rather than by design.

I know from just the last few months working with WP that it was not coded with the idea
that styled text de facto equals good, semantically rich design. I would hate to see it lose that
quality even through such a lauditory effort as that of easing new users into semantically
differentiated markup, through use of presentationally oriented labels for the buttons used to
create that markup.

jill
-- 
<http://pericat.ca/>