[whatwg] Mathematics in HTML5
jg307 at cam.ac.uk
Sun Jun 18 04:21:11 PDT 2006
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>
> 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
More information about the whatwg