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

> On 28 Apr 2016, at 11:57, Peter Krautzberger <peter.krautzberger@mathjax.org> wrote:
> 
> Thanks, Florian.
> 
> > There's a path, but it is indirect [...]
> 
> Yes and I would say the same holds for web components. I admit I'd prefer to see this succeed first before investing significant resources into attempting this path.
> 
> >  And if you fail, a somewhat fast js-powered declarative syntax is better than what we would have been able to get without Houdini.
> 
> True. However, as far as I can see such as "Houdini solution" will always require client-side JS, no matter how fast; an JS is often prohibitive.

To be fair, on the publishing side at least, I think there is more and more acceptance for JS in EPUB readers (at least the newer generation). There are large application areas of publishing (e.g., educational publishing) that relies on JS, ie, for most of the readers we may rely on JS.

I.

> 
> Best regards,
> Peter.
> 
> 
> On Thu, Apr 28, 2016 at 11:44 AM, Florian Rivoal <florian@rivoal.net <mailto:florian@rivoal.net>> wrote:
> 
> > On Apr 28, 2016, at 17:15, Peter Krautzberger <peter.krautzberger@mathjax.org <mailto:peter.krautzberger@mathjax.org>> wrote:
> >
> > 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)
> 
> That's true, although Houdini aims to (I don't think that's accomplished yet) to also be usable for smaller scale production using a combination of independently developed houdini-powered extensions.
> 
> > rather than a path towards convincing standards/browsers to move a certain approach into a proper CSS module on the native level.
> 
> There's a path, but it is indirect: You write a CSS spec for a feature that you think would be important for your use case (math). Browsers ignore it, because it's too hard / too niche / not their priority... You implement it in JS using Houdini, allowing people to try it out and give feedback. After a couple of iterations, it's pretty good, and gets some market traction, even if the need for JS makes it more cumbersome than needed. But now you can turn back to browser vendors, show a spec, a proof of concept implementation, and a bunch of users proving that the demand for the feature is real.
> 
> Hopefully then you can convince them it is important to do a native implementation. And if you fail, a somewhat fast js-powered declarative syntax is better than what we would have been able to get without Houdini.
> 
>  - Florian
> 
> 


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704