proposal: remove PRE from Structural model (purely presentational) [XHTML2 ACTION-70]

aloha!

in order to mark XHTML2 WG Action Item 70, in which i was asked to 
describe the problems with PRE:

http://www.w3.org/MarkUp/tracker/actions/70

as "pending review", here are my thoughts, suggestions & recommendations:

first, what precisely constitues, in the words of the latest editors' 
draft of XHTML2, quote whitespace in the enclosed text [which] has 
semantic relevance unquote?  if one needs to preserve whitespace, such 
as in an example of python code, one should either use code or 
blockcode for that purpose, as the definition of the three elements 
makes clear:

1) http://www.w3.org/MarkUp/2009/ED-xhtml2-20090407/mod-structural.html#edef_structural_blockcode

2) http://www.w3.org/MarkUp/2009/ED-xhtml2-20090407/mod-text.html#edef_text_code

3) http://www.w3.org/MarkUp/2009/ED-xhtml2-20090407/mod-structural.html#edef_structural_pre

if explicitly designated as "code" an assistive technology could respect 
and report the whitespaces contained in the string of code, something 
which is not possible with the PRE element, unless each and every 
whitespace to be preserved is explicitly expressed with a character 
entity 
value;

this would mitigate the necessity of definitively communicating 
multi-modally the presence and number of whitespaces in an example 
through the use of the character entity value of a "non-breaking 
space" (e.g.   or either   or   (i'm not sure which is 
right, the first value is from an online list, the second from XML 1.0 
Fourth Edition) -- if the whitespace has "semantic meaning", then the 
amount of whitespace MUST be explicitly expressed with markup (or the 
containing element MUST respect and not conflate whitespace in strings 
marked with the CODE or BLOCKCODE element) in order to make the number 
of whitespaces perceivable (theoretically definable on a per-element 
basis through the "layout" attribute), as well as endowing a human or 
assistive technology to process  the precise number of whitespaces 
correctly.  therefore, best practice  would be to use either   or 
  or   for each whitespace the  author desires to be 
preserved, as variable space dileneation is a hallmark of some 
programming languages, and a user needs the ability to count the 
whitespaces (or have them correctly rendered when sent to a refreshable 
braille display or when embossed into tactile braille)

optimally, one would want to use a character entity code to indicate a 
TAB or multiple TABs, as some programming languages use TAB dilineation, 
and the purpose of CODE and BLOCKCODE is to ENSURE that any user can 
copy and paste the sample of CODE, with whitespaces and explicitly 
declared TABs preserved...

so, since the following is explicitly stated in the current editors' 
draft of XHTML2' Structural module:

<quote 
src="http://www.w3.org/MakUp/2009/ED-xhtml2-20090407/mod-structural.html#edef_structural_pre">

Note that while historically one use of the pre element has been as a 
container for source code, the new blockcode element more appropriate for 
that. 
</quote>

AND

since the example of the "bad poem" in the definition of PRE should be 
controlled either by style sheets, the "layout" attribute (set to 
relevant) or the xml:space attribute, defined in Section 2.10 ("White 
Space Handling") in the Fifth Edition of XML:

<quote cite="http://www.w3.org/TR/xml/#sec-white-space">

A special attribute named xml:space may be attached to an element to 
signal an intention that in that element, white space should be 
preserved by applications. In valid documents, this attribute, like 
any other, must be declared if it is used. When declared, it must be 
given as an enumerated type whose values are one or both of "default" 
and "preserve". For example:

<!ATTLIST poem  xml:space (default|preserve) 'preserve'>

</quote>

AND

since the "conformance definition" for whitespace in XHTML2 states:

<quote 
src="http://www.w3.org/MarkUp/2009/xhtml2-ED-2009-04- 
07/conformance.html#conf_whitespace"

White space must be handled according to the rules of [XML]. All XHTML 2 
elements preserve whitespace.

The user agent must use the definition from CSS for processing white 
space characters [CSS3-TEXT].

</quote>

PROPOSED 1: the PRE element is no longer necessary, and therefore should 
be removed from the XHTML2 Structural Model.

CAVEAT 1.1: at the VERY least -- PRE should be deprecated into a legacy 
module, but removing it altogether will eliminate future headaches and 
break authors of the lazy habit of using PRE; superior mechanisms other 
than PRE, such as CODE and BLOCKCODE, have been introduced, and there is 
widespread support for CSS to control columnization, thereby eliminating 
another abuse of PRE.

PROPOSED 2: That the definition of CODE and BLOCKCODE be amended to 
indicate that whitespace, line breaks, and other "layout" components 
contained within CODE or BLOCKCODE is intended to be preserved, and that 
all current references to the PRE element be removed.

PROPOSED 3: that the "bad poem" example be changed to reflect Section 
2.10 of XML 1.0 Fifth Edition through the use of the xml:space "preserve" attribute, as follows:

<!-- begin 'bad poem' example --> 
<!-- in HEAD --> 
<!ATTLIST poem xml:space (preserve) #FIXED 'preserve'> 
<!-- in BODY --> 
<!-- ... --> 
<p xml:id="poem" layout="relevant" xml:space="preserve"> 
               If 
            I   had 
         any       talent 
            I   would 
             be a 
             poet 
</p> 
<!-- end 'bad poem' example -->

PROPOSED 4: That the "bad poem" example be removed from the draft 
altogether, an the use of spacing for stylistic effect be covered 
elsewhere in the document (although this could also be, and perhaps 
should be, handled by a pass-off to a CSS recommendation

note that as soon as this post is archived and designated a URI, i will 
create an ISSUE in the WG's tracker for eliminating PRE

gregory. 
------------------------------------------------------- 
lex parsimoniae: 
* entia non sunt multiplicanda praeter necessitatem. 
------------------------------------------------------- 
the law of succinctness: 
* entities should not be multiplied beyond necessity. 
------------------------------------------------------- 
Gregory J. Rosmaita, oedipus@hicom.net 
       Camera Obscura: http://www.hicom.net/~oedipus/ 
-------------------------------------------------------