review of implementation of stretchable fences

Hi Arno,

I've renamed the thread for better archivability.

The main difference for MathJax v3 is that the stretchy fences no longer
require length calculations for the stretchy components -- they now simply
stretch to the size of the container.

This means that, for example, element queries could solve the problem
completely -- just switch between the fixed size glyphs and the stretchy
construction via an element query. Of course, element queries are a touchy
subject.

Another idea I've thought for a while would be variable fonts. I'm not a
font expert at all but from exploring what variable fonts implementations
can do today it looks like horizontal stretch might already be feasible.
More creative prototypes like spectral <https://spectral.prototypo.io/>
seem to open up additional ways, including vertical strecth. I'd be
interested in experimenting on this but admittedly lack the font expertise.

Best,
Peter.



2018-01-19 11:21 GMT+01:00 Arno Gourdol <arno@arno.org>:

> Following up as per the discussion at the end of the call yesterday...
>
> In addition to a taskforce/workstream focused on improving CSS for math
> layout, the second taskforce/workstream I suggested is one that would focus
> on machine-readable formats of math for the following purposes:
>
> - software interchange (i.e. being able to copy/paste, send/receive data
> from a service). Imagine a web service that provides computation services,
> perhaps plotting of mathematical function. How would you represent the
> function to plot? What is the JSON equivalent for math?
>
> - other software processing, for example for accessibility (spoken or
> braille representation of math)
>
> There are several existing formats in use for these purposes today,
> including LaTeX and MathML. Could these formats be improved or could they
> be further standardize to better serve these use cases, in combination
> perhaps to improvements to other standards such as ARIA. This would also be
> an opportunity to tackle and clarify the role of MathML for math on the web.
>
>
> To give this more context, the way I envision math on the web in the
> future is as follow:
>
> - the "presentation" of math done with HTML and CSS (with suitable CSS
> enhancements, as there are lacunas today), accompanied with an out of band,
> optional but recommended, machine readable description of the formula
> (similar to the ALT tag of an IMG element). This should require the least
> effort from browser vendors to implement, and have the greater chance of
> broad adoption. I also believe this solution should not require the use of
> scripting. The required CSS/HTML could be generated dynamically on the
> server, or by an authoring tool at authoring time. In the future, a
> solution could be implemented based on web components/Houdini, but it would
> require the same improvements that are needed today to do the display from
> HTML and CSS, since it would essentially move the work that can be done
> today on the server in a locally packaged component.
>
> - interactive math (such as editing) done with HTML, CSS (relying on the
> same enhancements as above) and Javascript. This would seem consistent with
> accepted use of Javascript on the web for interactive/dynamic content.
>
>
> Finally, as a follow up on another point of discussion in the call, I
> looked at the implementation of stretchable fences in mj3. As far as I can
> tell, it uses an implementation very similar to what I'm using in MathLive,
> namely, multiple fonts with symbols of different sizes up to a certain
> point, then constructing the fences by stacking end caps and a stretched
> middle portion. This is fine, and all that logic can be done in Javascript.
> You could argue, I suppose, that an author who wishes to write formulas
> without Javascript could do the same kind of gymnastics, but I still think
> that having stretchable fences that could be described in CSS so that the
> browser's layout engine could do these calculations would be valuable. As
> an illustration, I would argue that writing CSS/HTML by hand to render the
> following is non-trivial, because of the fences:
> \begin{pmatrix}
>     x_{11}&x_{12}&x_{13}&.&.&.&x_{1n}\\
>    x_{21}&x_{22}\\
>    x_{31}&x_{32}\\
>    x_{41}&x_{42}\\
>    x_{51}&x_{52}\\
>    x_{61}&x_{62}\\
>    x_{71}&x_{72}
> \end{pmatrix}
>
>
> I'm not sure on what next step would make sense here. Personally, this is
> not something I need in MathLive, since I have a solution that works just
> fine. I believe this is something that would benefit the greater community
> of math on web authors, and could help achieve the goal I outlined above of
> displaying math content using only CSS and HTML, but I didn't get the sense
> that there was a lot of enthusiasm from this group regarding this.
>
> Best,
> Arno.
>
>
>
>
>
>
> On Wed, Jan 17, 2018 at 9:13 AM, Peter Krautzberger <peter@krautzource.com
> > wrote:
>
>> Hi everyone,
>>
>> We are scheduled to meet on Thursday at 12pm Eastern.
>>
>> Since appear.in is now restricted to 4 participants, it's not useful
>> solution anymore. For now, we'll switch back to Google Hangouts, see [1]
>> below.
>>
>> Best,
>> Peter
>>
>> # Agenda
>>
>> * review call for comments
>> * plan potential task forces for 2018
>>
>> [1] https://hangouts.google.com/hangouts/_/krautzource.com/mathonweb
>>
>
>