- From: Jewett, Jim J <jim.jewett@eds.com>
- Date: Wed, 14 Apr 2004 14:25:57 -0400
- To: www-html@w3.org
Looking at http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/Overview.html my first response is: Wow, this is simpler and more compatible than xhtml2.0 -- maybe it will actually get used. The details raised a few questions, though. (1) There are several places where the draft ignored the problem of restricting grandchild elements. For example, a <form> cannot contain another <form>, but it can contain block elements like <div>, which can then contain another <form>. <object> and <iframe> are inline, but they can take anything as contents, so a <div> again opens it to anything. On the other hand, lists cannot be contained directly within a paragraph (regardless of styling), and <br> is still core (to allow breaks within a paragraph) so maybe the block/inline issue is still there, and the div escape is just a bug. If this relaxation is OK for xhmtl1, it is probably also OK for xhtml2 -- and would solve some of the block/inline problems. (2) Several elements moved from the Core Text module to a Presentation (Text Extension) module. Unfortunately, there isn't any clarification on what the remaining elements mean. While the difference between <b> and <i> is clearly presentational, it isn't clear that there is any difference between <em> and <strong>. As best I can tell, <em>, <strong>, <b>, <i>, <tt>, <big>, <small>, <sup>, <sub> and even <span> all mean exactly the same thing: "I'm grouping this text for special attention." The different element names are just style suggestions on how to request that attention. There is an assumption that people will recognize which groupings are *really* important (so that <em>=<strong>, but the others do not suggest extra importance), and that people will "just know" what the presentation "really means". Unfortunately, we've already heard that <small> will suggest different things in English and Chinese. If xhtml 2.0 is serious about marking up only semantics, then it should probably deprecate all but <em> (possibly with a strength attribute, or a <deemph> counterpart) and <span>. (3) It really looks like the computer terms <code>, <kbd>, <samp>, <var> should move into their own module; it's hard to justify these as more fundamental than the edit module, or tables. (4) Does <pre> have any meaning other than being a shortcut for <p xml:space="preserve"> -jJ
Received on Wednesday, 14 April 2004 14:26:32 UTC