- From: Peter Krautzberger <peter@krautzource.com>
- Date: Thu, 25 Jan 2018 18:31:27 +0100
- To: Arno Gourdol <arno@arno.org>
- Cc: mathonweb <public-mathonwebpages@w3.org>
- Message-ID: <CABOtQmERiy7LXrEy5sZ_MJ8ErUL67+sM3t1wTL7r33rqAOKSCg@mail.gmail.com>
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 >> > >
Received on Thursday, 25 January 2018 17:32:15 UTC