[whatwg] Mathematics in HTML5

[James Graham]

White Lynx wrote:
> James Graham wrote:
>> You have to choose your battles and, personally, I 
>> agree with the idea that, if the proponents of CSS-based maths want to 
>> work in the structure of the WHATWG, they should demonstrate the 
>> feasibility of their approach using a microformat. Given the constraints 
>> under which they have chosen to operate it should be possible to do this 
>> without any  difficulties. 
> 
> As I already said several times, when it comes to rendering maths with CSS,
> there are no real difference between HTML based microformat and XML application.

Except that XML will not work with HTML4. One of the big difficulties 
with MathML is that XML is /too hard/ for authors. That's why WHATWG has 
spent so much effort designing a backwards-compatible HTML parsing 
algorithm with predefined error handling - because authors cannot 
migrate to XML based solutions.

> Whether fraction will be marked as 
> <span class="fraction"><span class="num">numerator</span><span class="den">denominator</span></span>
> or
> <fraction><num>numerator</num><den>denominator</den></fraction>
> does not matter for the purpose of further rendering with CSS.

Which is why the microformat approach will work.

> However it matters for usability, readability and authoring purposes.

Indeed. If you require documents to be well formed XML authors will not 
use your technology. Of course there is no difficulty in producing a 
tool that takes an XML tree as input and outputs a microformats-style 
HTML4 tree with the same meaning, if you believe that this will be 
easier for authors.

> So sending us to microformats.org is basically saying that it is not worth
> to allocate separate element names for maths.

At this point I would certainly agree with that sentiment, at least at 
present. I would certainly change my mind in the future, if you could 
demonstrate high quality typesetting of mathematics with a range broad 
enough to satisfy professional mathematicians.

>> This should allow 
>> the language to evolve as it encounters real-world needs so, if and when 
>> it is formally standardized, it will be a better product than typically 
>> results from an standardization-before-implementation approach.
> 
> We prefer parallel process, so what we propose to standardize today can
> be consistently rendered today in browsers, later when it will be realistic
> to add more features they will be gradually added.

That's not a convincing case for putting everything in HTML5 today - 
it's much easier to pick up new ideas later once they have some proven 
success than it is to drop stillborn markup which was believed to be 
good at the time but failed to solve real world problems. A microformat 
for HTML 4 (and even your own XML dialect in its own namespace for 
XHTML) seem like the ideal solution as it allows you to develop a 
standard but does not add dozens elements from an unproven technology to 
HTML 5.