Re: DogFood (and inline/block constraints)

Olaf,

> For chapters, sections, subsections etc HTML5 introduces the
> section element - having used (la)tex for several texts too, I
> know, that this language has a similar concept to structure
> text in a useful way and to brace the pleat thoughts of authors
> smooth ;o)

But that was my point, that HTML needs a LaTeX-like (and docbook-like)
possibility to mark up paragraphs based on the natural laguage
semantics, not just based on a visual processing model where the bit of
text following a display has to be in a new <p> because it is
conventionally typeset starting on a new line.


Adam,

> I don't think that its correct to allow paragraphs to have just any  
> block level elements (what is the meaning of a paragraph within a  
> paragraph?)


I don't think anyone is arguing to allow p in p (or body in p...)
the languages I cited (docbook, xhtml2, latex) don't allow that either.


> I think, rather, that it might be worth creating a third  
> categorization of elements, ones that are both block and inline  
> elements, perhaps with marginally different semantics in each case.

exactly, and this (in an ideal world free of legacy implementation
constraints) would be essentially all block level things that are not
releated to document structure like headings and sections, so tables,
maths, lists, pre, blockquote etc.

> 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 found the following markup at
> http://www.w3.org/Math/XSL/pmathml2.xml

yes, I  know of that file. (I wrote it:-)

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


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

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

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

Received on Wednesday, 12 December 2007 23:57:39 UTC