W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 1999

[From Mozilla Editor List] Make Bold and similar operations

From: Kynn Bartlett <kynn@idyllmtn.com>
Date: Mon, 22 Mar 1999 11:07:56 -0800
Message-Id: <3.0.5.32.19990322110756.00afed20@mail.idyllmtn.com>
To: w3c-wai-au@w3.org
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/
Received on Monday, 22 March 1999 14:14:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:52:54 GMT