[whatwg] Mathematics in HTML5

[James Graham]

White Lynx wrote:
> James Graham wrote:
>> I remain sceptical about this. However, if there is a serious effort to replace 
>> MathML I believe the resulting language must fulfil the following requirements:
>> 1) Easy conversion from standard LaTeX2e.
> There are plenty of different packages and low level presentational commands,
> so it does not seem to be possible to keep simple  markup language isomorphic to LaTeX.

I know there are many packages. But we must aim to be as compatible as possible 
with the basic LaTeX equation environment and, if possible, with popular 
packages such as the AMS ones. If LaTeX -> HTML converters don't work no-one 
will use the language and it will be a complete waste of effort.

>> ISO standards that no-one uses are 
>> irrelevant in practice; LaTeX matters.
> Basically you require to replace CSS rendering engine with LaTeX typesetting system
> which is outside the scope of current initiative.

No. I propose that the [X|HT]ML syntax follows the LaTeX model as closely as 
possible within the constraints imposed by the XML data model. This should make 
it easy for people to write converters which is the _only_ thing that matters 
for high adoption.

>> 2) Excellent typography. 
> Typography is not something that has to be defined by specification.
>> Faking radical signs and so on is simply unacceptable. 
> It is the matter of implementation, we could draw radical signs with SVG
> but using borders only is more reliable at the moment. In any case presentation
> should not be hardcoded in specification.

Using border only my be more reliable but it is unacceptably poor. This issue 
must be solved. If it cannot be solved within the CSS model, CSS must be 
improved or the enterprise must be dropped. There is no point in wasting time on 
something that produces embarrassingly unprofessional looking output.

>> 3) The provision of alternative fallback content should be easy. For 
>> accessibility reasons it should be possible to provide the LaTeX source and/or a 
>> textual description of the equation. 
> Textual description can be provided using something like alt attribute. 

Sure. But I consider that a requirement. (and I would argue that 'alt' is a 
poorly designed model)

>> It should also be possible to provide an 
>> image to display instead of the rendered equation.
>> Indeed, it would be extremely 
>> beneficial if there were some way to make the current generation of browsers 
>> render the image and ignore the mathematical content which,
> There is similar "fallback" in MathML. No one uses it. 
> In any case it is worth to think about it.
>> given the 
>> enhancements to CSS likely to be needed to fulfil point 2, is likely to render 
>> extremely poorly in current generation browsers.
> Can you specify point 2?

Not entirely because I am not sufficiently familiar with the details of 
rendering mathematics. I will try to learn something so I can contribute more.

> So far people mentioned radicals and glyph shaping/kerning.

Another obvious issue is stretchy characters like integral signs and brackets. 
Is the CSS model poerful enough to allow for this? If not, the mosel needs to 
improve.

> First issue can be improved and even if it would be impossible to improve there always is
> option to use power notations. Second issue (slanted vs. normal glyphs, kerning, spacing)
> lay outside the scope of markup language, Unicode standard provides set of necessary characters
> (mathematical alphanumerical characters in Plane 1), font designers are responsible for kerning, 


The mathematical alphanumerical characters are worthless. AFAIK there is poor 
support for plane 1 unicode in UAs. No-one has the keys to enter those 
characters so they will instead enter normal characters, find the rendering 
unacceptable and go back to some other technology. It will also break in-browser 
search functions (try searching for a string in an equation in-browser and you 
won't find it because the codepoint won't match). I'm also rather of the opinion 
that having separate codepoints to represent the same glyph but with a different 
style is broken by design.

 > authors are responsible for spacing.

-- 
"You see stars that clear have been dead for years
But the idea just lives on..." -- Bright Eyes