Re: DogFood (and inline/block constraints)

>
> On 13-Dec-07, at 10:03 AM, David Carlisle wrote:
>
>> I'm not convinced that you're right. Math doesn't have to be declared
>> as anything. It is simply a different thing.
>
> but (depending what the final story on compound document types is)  
> it is
> usally the job of the outer document type spec to say where, if
> anywhere, foreign material is allowed. You are assuming one, very  
> open,
> possibilit) Other document types are more constraing.

Ah. Yes I have been assuming exactly that. HTML gets used as a wrapper  
for a lot of different things and that is likely to continue. I don't  
think that it is a very wise decision for HTML5 to say which things  
its willing to play with as new things will come along in the future  
and existing things will evolved differently. HTML has no good reason  
to be restrictively constraining.

>> 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).
>
> well it defers the meaning of that to CSS, so actually it does in this
> case, but as I say mathml wasn't the real point of the example.

Actually, what I mean is that the meaning of what a 'block' is can  
change spec to spec. For example, if I were to define "LegoML" (as an  
absurd example) a 'block' element would mean something very different  
than it does here.

>> and more conventionally written the same paragraph as:
> The usage I gave was hardly unconventional, the mathematical  
> literature
> is full of documents that have displayed equations mid sentence.

I by conventional I meant "normal" prose, the thing that we all learn  
to write in grammar school. Technical conventions are frequently  
different.

My point is that the reason why scientific literature would render a  
paragraph with an equation in it in such a way that appears in a line/ 
block on its own, has nothing to do with the semantics of the sentence  
in which it is found. Rather, its a convention that arose because of  
the limitations of original printing presses, or because its simply  
easier for readers to read, or something similar. The fact that it  
appears on its own line has nothing to do with the semantic meaning of  
the equation or the paragraph in which it belongs, its pure style.

>> Both paragraphs are structurally identical and should be marked up  
>> the
>> same.
>
> yes exactly!!!! my point (so since you said that you disagreed with
> that, you must have missed my point), so I'll give a non-math, non  
> list,
> example.
>
> 	<p>The subject of this paragraph is <q>horses that rock</q> where
> horses are black things with four legs.</p>
>
> is structurally the same as
>
> 	<p>The subject of this paragraph is <blockquote>horses that rock</ 
> blockquote> where
> horses are black things with four legs.</p>

You're using a faulty analogy (or is it a hasty generalization). That  
MathML and lists should be allowed within paragraphs is something that  
we both agree on. However, you seem to be reasoning that since math  
and lists, which are typically rendered as blocks, that all (or many)  
elements that are typically rendered as blocks should be allowed  
within paragraphs. I whole heartedly disagree. The reason why math and  
lists should be allowed within paragraphs is that it is reasonable (as  
I've endeavoured to show) to render them in a paragraph as inline  
elements.

I can think of no example of embedding a block quote in a paragraph in  
which it wouldn't break or confuse the semantic meaning of a  
paragraph. For example:

	<p> Ben told me, <blockquote><p>Estrud nec conulputem, quatums  
velisl, sociis enit, peraese sollicitudin hent consenisim ipsum.  
Feuiisse utpat aliquisi. Elesequ praestis mincidunt onse eleifend.  
Volesed feuisi lute atinit coreetue; vitae inciduipit ing magnis  
dolendit. Blandipisisi adiam blaor summy tat consent.</p><p>Eugiam  
commolor lectus eugiamconse adio diam henis ercilis; velenis montes  
magnim delent. Consed delit esequi dolent velesse te elesequ  
vulluptatum hendrerit, inciduipit sequam laoreet. </p></blockquote>  
which is complete nonsense to me.</p>

which would be rendered as:
	Ben told me,
		"Estrud nec conulputem, quatums velisl, sociis enit, peraese  
sollicitudin hent
		consenisim ipsum. Feuiisse utpat aliquisi. Elesequ praestis  
mincidunt onse
		eleifend. Volesed feuisi lute atinit coreetue; vitae inciduipit ing  
magnis
		dolendit. Blandipisisi adiam blaor summy tat consent.
		
		"Eugiam commolor lectus eugiamconse adio diam henis ercilis; velenis  
montes
		magnim delent. Consed delit esequi dolent velesse te elesequ  
vulluptatum
		hendrerit, inciduipit sequam laoreet."
	which is complete nonsense to me.

completely breaks (to my mind) the concepts of both paragraphs and of  
sentences.

> and should be marked up the same way, it's just a stylistic choice to
> display large quotations. But the latter is invalid so you have to do
>
> 	<p>The subject of this paragraph is </p><blockquote>horses that
> rock</blockquote><p class="noindent"> where
> horses are black things with four legs.</p>
>
> which looks OK visually but is structurally horrible, or you have to  
> do
>
> 	<div>The subject of this paragraph is <blockquote>horses that rock</ 
> blockquote> where
> horses are black things with four legs.</div>
>
> which is structurally much cleaner, but proposed to be banned in  
> html5.

I wasn't aware of this, but, for reasons I've already said, I'm in  
favour of it.

> David
>
>
>> [How to do this for the  html serialization?]].
> Now there's a good question....

Perhaps with an innocuous prefix? <_math>, <_lego> Not very appealing.  
Perhaps you could limit it to the XML serialization

>> 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,
>
> that was _exactly_ my argument, but it's been strongly stated that
> existing legacy parser deployment mean that there is no way to
> change the fact that you can't have block level elements inside a <p.>
> in text/html and doing it hust for text/xhtml+xml seems too confusing.
>
> So you have to look for something else.

Oh. I hadn't heard that before. I didn't know that browsers used  
validating parsers. In fact, I thought that they avoided those  
explicitly because they're too slow for practical purposes. I just ran  
out and did a test to see what happens. I and see that (in safari at  
least) it changes the dom structure. Annoying.

>> 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.
>
> but mixing inline and block level elements is exactly what you need to
> do do model a list inside a sentence. Also this has been allowed (and
> used) since whenever div was added to html (was it 3.2 or earlier?)
> so it's not at all clear that it's advisable to change this now even  
> if
> that was thought desirable.

I am beginning to see the problem. If practicality says that we can't  
change the behaviour of the existing block tags without breaking the  
internet then we need to find a different way. The first thing is that  
we shouldn't change the behaviour of the div, although it would be  
worth providing non-normative text for authors encouraging them not to  
mix inline and block elements as a general rule, except in the  
following types of situations... A compromise.

If we can't change existing syntax, we can add new syntax to capture  
our use cases. For example, lets introduce a new list tag called <l>  
(or <list>?) that can be either inline or block and its child elements  
are <d> and <t> (I'm generalizeing from the DL tag). We can also add  
an "ordered" attribute and we've covered all the necessary semantic  
cases. Further we can say that used in the inline context, it may also  
have inline content (but only the d and t tags have meaning for the  
list), but those are forbidden in the block context. The  
implementation of numbering and other rendering aspects can be  
adequately handled by CSS 2.1 counters (http://www.w3.org/TR/CSS21/syndata.html#counter 
)

Since my visit to the mathml example I cited worked fine on my  
browsers (FF) I don't think that there is any hinderance there, save  
that a UA should implement mathml for it to be useful.

Adam

Received on Thursday, 13 December 2007 19:11:53 UTC