This is not WAI guidance, this is just my personal opinion...
Actually I think the question is slightly wrong. If you want to
emphasise arbitrary text, then you take the first approach (although you
should make it all XML legal rather than having overlapping elements.
However this is not a particularly helpful thing to have users do in most
cases - the value of <EM> or <B> or whatever is to allow a single word or
a short phrase to be given emphasis.
Otherwise, the use of emphasis is a presentation mechanism for making
clear visually the type of a particular structural element - for example,
the difference between H1, H2, H3, and H4 is often represented to a visual
user by differences in text size. Phrases which are in a foreign language,
or quotations, are often presented visually as italicised text. This
should be done by encouraging the author to use a stylesheet to determine
their preferred presentation of the various structures available to them
in HTML (or any other mark-up language - the same principles apply to
MSWord, which uses some kind of internal markup, and are second nature to
people who know anything much about how to use it)
Another approach is to allow authors to visually style their document in
terms of font-size, font-weight, etc, and then compare the various formats
they have used to determine the structure implicit in the document, and
automatically generate the mark-up, using the user styles to generate the
stylesheet by example.
There are various common clues - larger and bolder text is generally more
important (higher level heading) than smaller text, and nesting of formats
is a pretty obvious clue.
Although this would only be relevant to authors who are working in a
visual mode, the ability to apply the structure recognition to other
documents would allow scanned documents to be automatically marked up with
structure, and thus navigated more efficiently, broken into smaller
sections for efficient transfer of subsections, etc etc.
Charles McCathieNevile
On Mon, 22 Mar 1999, Kynn Bartlett wrote:
This is forwarded from the Mozilla Editor list, the people who
are developing the next version of what's now known as "Netscape
Composer". It may be too technical for the level of discussion
on _this_ list, but I'm wondering what guidance (if any) the WAI
would give on this topic. How _should_ 'Make Bold' be implemented
in editors? Do we have any advice on this and other practical
topics?
--Kynn
>>>>
Resent-Date: Fri, 19 Mar 1999 11:50:29 -0800 (PST)
To: mozilla-editor@mozilla.org
Path: not-for-mail
From: Steve Clark
Newsgroups: netscape.public.mozilla.editor
Subject: Make Bold and similar operations
Date: Fri, 19 Mar 1999 11:49:48 -0800
Organization: Another Netscape Collabra Server User
Lines: 146
NNTP-Posting-Host: h-206-222-241-103.netscape.com
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
Resent-From: mozilla-editor@mozilla.org
X-Mailing-List: archive/latest/629
X-Loop: mozilla-editor@mozilla.org
Resent-Sender: mozilla-editor-request@mozilla.org
any and all feedback welcome.
Manipulating Text Properties in Gecko
author: Steve Clark
last updated: 10/19/99
----------
There are lots of ways to get "bold" in CSS.
Type Selectors: XX {font: bold} // all XX's are bold
Descendant Selectors: H1 XX {font: bold} // only XX's in H1's are bold
Child Selectors: H1>XX {font: bold} // only XX's that are direct decendants of H1's are bold
Adjacent Siblings: H1 + XX {font: bold} // only XX's that are the next sibling of H1's are bold
ID Selectors: XX.bold {font: bold} // only XX's with ID="bold" are bold
Attribute Selectors XX[title] {font: bold} // only XX with title attribute are bold
XX[title="foo"] {font: bold} // only XX with title attribute="foo" are bold
XX.foo {font: bold} // only XX with class attribute="foo" are bold
* [title="foo"] {font: bold} // any element with a title attribute of "foo" is bold
ID Selectors XX#foo {font: bold} // only XX with ID="foo" are bold
Pseudo Class Selectors XX:first-child {font: bold} // only the first child of XX is bold
Dynamic Pseudo Classes XX:hover {font: bold} // XX is only bold when the mouse is hovering over it
Pseudo Elements XX:first-line {font: bold} // the first line within XX is bold
Generated Content XX.foo:before {content: "Crap!"} // normal rules apply to XX.foo, so Crap! could be made bold even
// though it's not really in the content model at all!
Inheritance XX {font: inherit} // XX will get the ancestor's resolved font
bolder and lighter XX {font: bolder} // XX will be bold only if it's resolved style is font-weight normal
This of course is in addition to content markup like <B>.
So what does this mean for editing? Well, it certainly means that "make bold" isn't always as easy as wrapping the selection in a <B> tag.
Basically, we have 2 choices (well, a whole continuum of choices in between, but broadly...)
1. Assign special meaning to <B> so "make Bold" means "wrap the selection in <B> as necessary" and "make not Bold" means remove <B> as needed.
Benefits:
A. It's all content, baby.
B. It's what we sorta already know how to do from composer, so we should already know most the rules.
Drawbacks:
A. This won't always work if applied in a straightforward manner. There are cases where the selection will include tags that alter boldness with higher precedence the <B>. For example, if this fragment is selected:
text <XX>special</XX> more
text special more
with style:
XX {font-weight: normal}
and we "make Bold", we'd get:
<B>text <XX>special</XX> more</B>
text special more
we could do this:
<B>text</B> <XX><B>special</B></XX> <B> more </B>
text special more
but this leads to an ugly proliferation of tags (what if XX were I?) corresponding to lots of extra tree-twiddling
B. If the user is editing a document where <B> is reassigned via CSS to mean something other than {font: bold}, they may get unexpected results.
2. Don't assume anything special about B tag. Pay attention to CSS. Use style and spans and worry about translation to <B> on output.
Benefits:
A. We can make this work for every bizzare document we ever see: HTML, CSS, XML, ...
B. We can guarantee predictability: make bold will add emphasis to the selected text in any context.
B. Even if we only get part way down this path, it's going down the right path. This is where we need to get to eventually.
Drawbacks:
A.This is HARD. We need to understand and interpret the resolved style of frames much more than we had planned.
B. This puts a lot more pressure on our output system. We would need to be able to output
DIV.foo { font-weight: bold; font-style: italic}
<DIV.foo>bold text</DIV>
as
<B><I>bold text</I></B>
in "output to HTML 3.2" mode.
Conclusion
I'm leaning heavily towards the first solution. We just don't have time to get into style sheet editing. So I'm building a matrix mapping context to behavior. If anybody has any insights to make building this matrix easier, I'd sure appreciate hearing them. Any pointers into the existing code?
<<<<
--
Kynn Bartlett <kynn@idyllmtn.com> http://www.kynn.com/
Chief Technologist, Idyll Mountain Internet http://www.idyllmtn.com/
Professional ALT-text author http://www.kynn.com/+alt
Spring 1999 Virtual Dog Show! http://www.dogshow.com/
WWTBLD? Validate your HTML! http://validator.w3.org/
--Charles McCathieNevile mailto:charles@w3.org
phone: +1 617 258 0992 http://www.w3.org/People/Charles
W3C Web Accessibility Initiative http://www.w3.org/WAI
MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA