W3C home > Mailing lists > Public > public-mathonwebpages@w3.org > April 2016

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

From: Peter Krautzberger <peter.krautzberger@mathjax.org>
Date: Thu, 28 Apr 2016 11:57:11 +0200
Message-ID: <CABqxo82aXKVFPXvk0nrT5TC=-p9ZqtR49qde9=QKoRboib8oAg@mail.gmail.com>
To: "public-mathonwebpages@w3.org" <public-mathonwebpages@w3.org>
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.

Best regards,
Peter.


On Thu, Apr 28, 2016 at 11:44 AM, Florian Rivoal <florian@rivoal.net> wrote:

>
> > On Apr 28, 2016, at 17:15, Peter Krautzberger <
> 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
>
>
Received on Thursday, 28 April 2016 09:57:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 28 April 2016 09:57:40 UTC