Re: Houdini [Was: Minutes of Math on the Web Community Group teleconference of 27 April 2016]

Thanks for the comments and clarifications, Florian adn Liam.

To clarify the minutes. Ivan mentioned Houdini since Jason specifically
mentioned font metrics so that's where the conversation started (supplanted
by the Smashing Mag article).

Re Florian
> 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

I would agree in general. However, from my personal perspective, investing
resources into exploring what the Houdini TF is working on is too much of a
gamble right now.

Like web components, Houdini seems to be ideal for individual, large-scale
production scenarios (e.g. Google Music, GitHub) rather than a path towards
convincing standards/browsers to move a certain approach into a proper CSS
module on the native level. Houdini also locks us into client-side
JavaScript, which is is acceptable/necessary in some situations (editing
comes to mind) but from the perspective of helping math layout on the web
in general, I think it wont' be sufficient (ebooks come to mind).

Don't get me wrong, i would love to have the resources to explore Houdini.
But I find it difficult to communicate Houdini as a viable path for solving
the problems that today's tools are facing. I'd be very happy to be wrong
here.

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

I think this raises an interesting question of the overall approach this
group might take.

Liam lists valid, deep problems but I'm wondering if it's productive to
discuss them. CSS is too far away from bottom-up layout at this point and
existing tools are comfortable taking care of the problem.

Personally, I'd rather try to focus on smaller problems. Take stretchy
characters, for example. I'm not looking for a perfect CSS module that does
all of it, i.e., bottom up layout to get dimensions and then draw an
appropriate stretchy thing.

For the time being, I'm perfectly ok with providing dimensions and creating
something stretchy. I have a feeling it might be more realistic to think
about small improvements to CSS that would make the process just a little
bit easier. For example, right now stretchy constructions lead to large DOM
fragments and brittle layout (aligning all those fragments). I wonder if
such problems might be more general, applying to other uses of CSS layout
(instead of just mathematics); in fact, some of the problems might just be
considered bugs (lots of problems have simply disappeared over the years as
engines got better). Identifying potential improvements that improve CSS
overall while helping math tools might just  have a better chance of
catching the interest of implementers.

Best regards,
Peter.





On Thu, Apr 28, 2016 at 8:59 AM, Liam R. E. Quin <liam@w3.org> wrote:

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