[sorry, also posted to public-digipub-ig@w3.org by mistake though also relevant there]
Although some on this list may cringe at this suggestion, Houdini sounds like a web standards way to implement what we lost in Internet Explorer. IE used to support COM plugins that implemented what Microsoft called Element Behaviors. my company’s MathPlayer was such a plugin. Basically, the browser called into the MathPlayer object to ask how much space it needed on the page. MathPlayer then queried things like the “ambient” font and size at the location of the object, read MathML from the DOM, formatted the math, and reported back how much space was needed. After IE formatted the page, it called the MathPlayer object to render itself. Of course, MathPlayer is programmed in C++, not JavaScript, and all the interfaces were IE-specific, not web standards. And, of course, Houdini will do much more than this.
Regardless of what people think of Microsoft and IE, this basic model was a good one. If Houdini allows us to do something similar but in a web standard way, it would be a big win, IMHO. The concern over JavaScript slowness will be eliminated by a combination of:
- WebAssembly (https://webassembly.github.io/) which will allow a fast-running subset of JS to be downloaded in binary form. There’s no reason such code can’t run as fast as native C++.
- Making sure that low-level, slow-running operations required for JS code to do math formatting properly are implemented by browsers in a standard way. As I understand it, MathJax is slowed by the need to play DOM games to measure certain things that the browser could much more easily and quickly calculate.
I like the idea of both (a) a top-down approach of making sure Houdini has what is needed for math (and music, …) and (b) a bottom-up approach to make sure browsers have facilities that allow math formatting (and accessibility, etc.) to be done quickly and easily.
Paul
> -----Original Message-----
> From: Paul Topping
> Sent: Thursday, April 28, 2016 9:24 AM
> To: Liam R. E. Quin <liam@w3.org>; Florian Rivoal <florian@rivoal.net>
> Cc: public-mathonwebpages@w3.org
> Subject: RE: Houdini [Was: Minutes of Math on the Web Community Group
> teleconference of 27 April 2016]
>
> I can certainly understand the reluctance to embrace such interactions. One
> would have to be very careful not to allow infinite loops where one
> component adjusts to changes in another, causing adjustments again in the
> first, and so on.
>
> -----Original Message-----
> From: Liam R. E. Quin [mailto:liam@w3.org]
> Sent: Thursday, April 28, 2016 12:00 AM
> To: Florian Rivoal <florian@rivoal.net>; Paul Topping <pault@dessci.com>
> Cc: public-mathonwebpages@w3.org
> Subject: Re: Houdini [Was: Minutes of Math on the Web Community Group
> teleconference of 27 April 2016]
>
> On Thu, 2016-04-28 at 15:30 +0900, Florian Rivoal wrote:
> > >
> > With regards to Houdini, I think a valuable thing to do for this CG
> > would be to look at the APIs being proposed in Houdini
>
> +1
>
> An important thing needed for mathematics (and tables) is the ability to
> inherit properties downwards (no problem in CSS) and sizes back upwards;
> the ability to break boxes - e.g. when an equation doesn't fit on a line - and
> to align between equations, e.g. multiple displayed equations with the =
> signs ligning up vertically, which also affects breaking.
>
> Right now the Houdini drafts place some limits on interactions, partly
> because the browser developers are afraid of opening up code to scripting
> that might not be robust against being used in unexpected ways.
>
> Liam
>
> --
> Liam R. E. Quin <liam@w3.org>
> The World Wide Web Consortium (W3C)