Re: DogFood (and inline/block constraints)

>
> 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