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

Re: [From Mozilla Editor List] Make Bold and similar operations

From: Charles McCathieNevile <charles@w3.org>
Date: Mon, 22 Mar 1999 19:31:26 -0500 (EST)
To: Kynn Bartlett <kynn@idyllmtn.com>
cc: WAI AU Guidelines <w3c-wai-au@w3.org>, mozilla-editor@mozilla.org
Message-ID: <Pine.LNX.4.04.9903221856100.16729-100000@tux.w3.org>
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
Received on Monday, 22 March 1999 19:31:37 GMT

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