- From: Adam van den Hoven <adam.vandenhoven@gmail.com>
- Date: Thu, 13 Dec 2007 09:26:10 -0800
- To: David Carlisle <davidc@nag.co.uk>
- Cc: public-html@w3.org
> > On 12-Dec-07, at 3:57 PM, David Carlisle wrote: > Adam, > >> This is a faulty example as you have confused rendering with >> semantics. > > No quite the opposite, I argue that the thing is a sentence and > forcing > people to mark up the second half of the text as a new p just because > it starts a new line is due to a visual rendering view. Now you didn't > suggest starting a new p but instead using mathml which is fine, so > long > as you allow <math> to be both inline and block. My point was that > the fact that the block needs to be inside p is a feature of __p_ not > mathml. I used a math example because I'm a mathematician but the same > comment would apply to a textual display with blockquote. I'm not convinced that you're right. Math doesn't have to be declared as anything. It is simply a different thing. I don't see how HTML5 can impose a meaning of "Block or inline or both" upon an entity that is defined by another spec. Its seems a little presumptuous. Even if MathML does define <math> as a "block" element, there is no reason to think that block has the same meaning as it does in HTML (in fact it probably doesn't). You haven't convinced me that your example is not about rendering. I would have just as easily, and more conventionally written the same paragraph as: The subject of this paragraph is the equation E=mc^2 where c denotes the speed of light. Or I might have said: The subject of this paragraph is horses that rock where horses are black things with four legs. I might have wanted to render that as: The subject of this paragraph is horses that rock where horses are black things with four legs. but that is only style, not meaning. My point is that just because you want to show the equation on a separate line, doesn't make that "rendering on a new line" a semantic issue. Its purely presentational. Think about how that same paragraph would be rendered by an aural browser. In either case I would mark up your example as: <p>The subject of this paragraph is the equation <em>E=mc^2<!-- or mathml --></em> where c denotes the speed of light.</p> <p>The subject of this paragraph is <em>horses that rock</em> where horses are black things with four legs.</p> Both paragraphs are structurally identical and should be marked up the same. Its possible that I'm making a faulty analogy, but I don't think so. >> I found the following markup at >> http://www.w3.org/Math/XSL/pmathml2.xml > > yes, I know of that file. (I wrote it:-) Cool. I picked the right reference then :) >> So, using semantics which are not defined in HTML (like MathML) >> solves >> your problem adequately. > > The content model of an html5 p is defined by html 5, whether or not > the > block uses foreign markup It's up to the HTML5 spec to say whether > foreign elements are allowed at any particular place, and in the > case of > math, there is still (I hope) the possibility of a less "foreign" > relationship between HTML5 and math markup. Ah. So you're saying that Math is a sufficiently important usecase that it deserves mention in the spec directly? Perhaps, but that begs the question of which "foreign" specs deserve comment. I'd like to see NITF get a mention too. Unless you mean that a general statement about tags from foreign specs. If that's the case, I would think that a normative statement like: "HTML5 allows tags from other specifications to be used within HTML5 documents. They are neither block or inline, but content authors SHOULD treat them consistently. In the XML serialization, they should be identified using the appropriate namespace [[How to do this for the html serialization?]]. If a user agent understands the relevant namespace, it must render the element(s) accordingly, if the user agents that are not aware of the namespace should treat them in the same way they would a span" or something like that. Basically, make a "play well with others". Of course, a standard way to introduce a replaced element (like an image, or something), would be cool too. I've always assumed that HTML5 must play well with others was the default position. >> Its all well and good to want to render something that way > > Rendering should be the least of the concerns. Ideally one could > come up > with a markup that allowed lists (as equations) to be easily switched > between inline and display rendering with the markup being essentially > the same in either case (following the meaning). For lists it's quite > hard actually to do this as punctuation styles are influened by the > display type in rather delicate ways, as you indicate. We spent some > time in LaTeX trying to get a good model for that, not with 100% > success. Actually, I don't think its that hard. For my inline list example, I might have the following CSS: p > ul > li:after { content: ", ";} p > ul > li:nth-last-child(2):after { content: " and ";} p > ul > li:nth-last-child(1):after { content: none;} Of course, this does mean that the paragraph in question cannot be understood as a "proper" grammatical sentence without a UA that understands CSS, but I'm not sure that's a bad thing. Its also possible that I've been using a strawman here, picking off the easy bit. >> I'm not saying that there aren't elements that are defined as block >> elements that shouldn't be allowed, for example, in paragraphs. I >> just >> don't think that if we're going to do it we need to be picky about >> what things we want to allow and why. "I want to render something >> this >> way," is not a justification. We should be saying, "the meaning of >> this requires a list" or something simiilar > > for p you have the option of being "picky" as currently p allows > nothing, so any relaxation is an improvement, It's not at all clear > to me > that you really have that option for div which currently allows any > mixture, so there being picky is invalidating existing content > (including a lot of my content, as it happens). Paragraphs are real meaningful semantic entities and they should only allow things who's semantic meaning is consistent with a grammatic paragraph, or rather a sentence (as a paragraph is a collection of sentences). As I think I've demonstrated (and as I'm sure at least all native english speakers have learned in grade school) you can have a list in a sentence (I like apples, pears and carrots.) suggesting that lists (ordered, unordered, perhaps definition?) should be allowed in paragraphs, with, potentially, the ability to mix PCDATA and LI. Other constructs, like a table, needs to have compelling arguments for them. Non-HTML5 elements must not be forbidden but authors should be encouraged to maintain the semantic meaning of paragraphs. Divs are meaningless semantic entities as such there is no need to be picky. The only thing I think is important is that authors must not mix inline with block level elements. That is just semantically confusing, IMHO. Adam
Received on Thursday, 13 December 2007 17:30:33 UTC