[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Strict XHTML 2.0
To handle some of the problems that Peter advises, are these proposals for a "strict" subset of XHTML 2.0. 1. A <section> element contains only <h> and <p> elements. 2. A <p> element contains text content, <l>, <img>, <table>, and list and inline elements. 3. A <enum> element is new -- it represents an item in an inline list. Note there is no "container" for <enum> elements -- that would foremost break the definition of an "inline" element. It's named <enum> because I believe that the items in an inline list are more correctly called "enumerations"; lists have a vertical orientation while enumerations flow with the text of their paragraph's text content. Their numbering by default is to be restarted within the <enum>'s parent <l> or <p> element, but there should be attributes on the <enum> element for control formatting details. I have never seen bulleted inline lists, so there is no doubt that the <l> is overloaded with interpretation of a <ol>, and the <enum> has the interpretation of a <li> -- how is that done -- Modular XHTML's "class" declarations I think are tied in with the CSS display classes, so it may be easy to associate these with the right default behaviors. I acknowledge that seamlessly converting a group of items within an inline enumeration into items within a block list, is not possible in this proposal. Nevertheless, I see that issue more as an application issue, rather than an information exchange issue -- my expectation is that most decent editors will have a general interface for converting elements of one type to another as the need arises during any cut and paste operation that occurs, so it's definitely suboptimal to strive for all elements used in both contexts, to have the same name. The second point worth noting about the proposal is that the problem of accidentally using a <ol> rather than a <section> to represent a structural <item>, is addressed by forbidding <ol> elements as children of a <section> element. This strict interpretation of XHTML places all block lists into a container that requires text content or inline elements. This means that every block list must be accompanied by "explanatory" text content. Also, <p> elements must always begin with text content or inline elements. These rules apply equally to other block elements -- <img> and <table> -- that may only occur in the context of a paragraph element; a <p> element is essentially defined by its text content, and hence text content is required content of a <p> element. Regardless of the order of elements within the <p>, a different display order can nevertheless be defined by CSS positioning attributes attached to the list, <img>, <table>, <div>, or <l> children of the <p>. Off the topic is the notion of a <pg/> element, an empty element that represents a page-break -- this would be very useful to many applications, and would be easy for the user to enter in any inline-element context. The <br/> element, defined also as an empty element, had so many obvious and useful applications, that it has been formalized as an <l> block element. They were lucky on that one, because the <l> element exists exactly on the boundary of the block world and the inline world so its interpretation can slosh around a little. Regards, John
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]