ISSUE-8 (PRE obolete & should be removed): remove PRE from Structural model (purely presentational [XHTML2]

ISSUE-8 (PRE obolete & should be removed): remove PRE from Structural model (purely presentational [XHTML2]

http://www.w3.org/MarkUp/tracker/issues/8

Raised by: Gregory Rosmaita
On product: XHTML2

as documented at:

http://lists.w3.org/Archives/Public/public-xhtml2/2009Jul/0004.html

1. RATIONALE

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> 

=-=-=
2. PROPOSALS
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" compenents 
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

=-=-=

Received on Wednesday, 1 July 2009 22:06:58 UTC