Re: Polyfill and meeting

FYI:  CSS Flexible Box Layout Module Level 1
<https://www.w3.org/TR/2017/CR-css-flexbox-1-20171019/#align-content-property>
just announced call for implementations. Anything in there of use for
alignment or otherwise? If something is missing, it's getting late in the
game to suggest a missing feature for flex boxes, but with a good
justification, you never know.

    Neil


<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Oct 30, 2017 at 3:09 PM, Daniel Marques <dani@wiris.com> wrote:

> Hi,
>
>
> Just uploaded the examples at https://codepen.io/daniwiris/
> project/editor/ZWbYxB .
>
>
> My first thought was to extend the CSS style vertical-align. But then, I
> changed my mind in favor of the CSS style baseline-shift (
> https://www.w3.org/TR/css-inline-3/#baseline-shift-property). That’s more
> powerful since, for example, it would be possible to combine
> vertical-align="mathematical" with baseline-shift.
>
>
> In any case, I would like to sate the following objectives:
>
>
>    1. To use only html5/css/web-fonts (no JavaScript) to display
>    statically independent-target-device math (but also some physics and
>    chemistry) simple-enough formulas. This means:
>       1. To target a common subset of simple math formulas.
>       2. To be robust to browser and OS change. Firefox, Chrome, Safari,
>       Edge, ... Windows, Mac, Linux, iOs, Android, ...
>       3. To be robust to scale. For example, device pixel ratio in retina
>       display and browser zoom.
>       4. To be robust to font family change within the same type of font
>       (Arial, Helvetica or Lucida Sans). Changing from Arial to Courier New might
>       not work so well.
>       5. To be robust to font size change.
>       6. It is fine to embed fonts for math symbols. Especially stretchy
>       parts, including parts of roots.
>    2. To be enough semanticaly rich for copying, pasting and providing
>    accessibility.
>    3. To be able to recompose a formula if any subpart of such formula is
>    dynamically changed with the help of JavaScript. Because, if you are able
>    to change subparts of a formula, it means that the device is using
>    JavaScript anyway.
>
> Of course, the html5/css/web-fonts representation of a given formula can
> be generated once programmatically. Since it must not depend on the target
> device, it can be generated either in the server or in the browser. Once
> such formula is created, the exactly same html is send to all devices.
> eBooks will be published with static html formulas.
>
>
> After giving many thoughts to the topic I realized that current HTML
> technology has already solved problem 1. Maybe one possible task of the
> MathOnWebPages CG could be to explain how to do it. In a form of paper in a
> conference? In a blog? A new project in Github?
>
>
> For formulas that cannot be achieved with html5/css/web-fonts, let’s use
> SVG. I don’t think it is possible to do all imaginable formulas with either
> LaTeX or MathML. Remember that math are more than just formulas: plots,
> graphs, movies…
>
>
> The second objective is more ambitious. What I suggest is that we need to
> markup the html in order to be able to recover the underlying math
> structure. We are entering in the swampy zone of the semantics. I suggest a
> lightweight semantics style like presentation-MathML on first place and,
> optionally, add an extra layer of heavyweight semantics the way
> content-MathML, Open Math or whatever format is decided.
>
>
> It should be possible to add this layer of semantics also to a SVG image.
>
>
> Dani
>
> On Wed, Oct 25, 2017 at 4:03 PM, Daniel Marques <dani@wiris.com> wrote:
>
>> Hi,
>>
>>
>>
>> First of all, my apologies since I’m not available tomorrow/today for the
>> meeting since I’m travelling to a conference.
>>
>>
>>
>> The good news is that I’ve not been idle and I’ve added two further
>> examples to the polyfill:
>>
>> 1.     Matrix alignment with fences
>> 2.     Grammar analysis (language subject)
>>
>> Unfortunately, I’m travelling and I’m not able to update the examples
>> online. The old version is still available at: https://codepen.io/daniwir
>> is/pen/rGKENd
>>
>>
>>
>> From the current examples, I learnt that the minimum requirements are to
>> be able to align respect to a given child in the following two scenarios:
>>
>> 1.     A vertical flexbox
>> 2.     A table or grid
>>
>> For the table, the alignment is only well defined when the affected row
>> (the children of tables are rows) has all its cells aligned by the
>> baseline, which is already possible to do with the current CSS
>> specification. Things are a little more disgusting because tables contain
>> an extra tbody element…
>>
>>
>>
>> Despite these minimal requirements, I implemented a version of the
>> polyfill that is able to align a flexbox or table according to any of its
>> descendants using a CSS like selector. It is fine to have such
>> functionality but maybe we are overkilling the solution.
>>
>>
>>
>> I used the handy selectionQuery method in JavaScript which seemed an
>> ideal solution until I discovered that selectionQuery never returned the
>> node I expected when multiple nodes satisfied the criteria. For example,
>> “:nth-child(2)” actually means any second child of any successor.
>>
>>
>>
>> Another idea is that probably makes more sense defining the “baseline”
>> than change the “vertical-align”. Thus,
>>
>> Preferred solution:
>>
>>             baseline: “:nth-child(2)”;
>>
>>             vertical-align: “baseline”;
>>
>> Less preferred solution:
>>
>>              vertical-align: “:nth-child(2)”
>>
>>
>>
>> I’ve also experimented with the stretchy solution. I think that it is
>> great but at the same time discovered that the browser does not render in
>> the same form normal text than scaled one (we already saw that in Peter’s
>> demo). This yields, again, that the different parts do not match perfectly.
>> For example, the minus sign had different weight when zoomed horizontally.
>> So the theory that this is a solution for perfect fraction lines is not
>> true. I’m not worried about that. Eventually we could blame the browsers
>> and they might fix it from their side.
>>
>>
>> I'm still with the idea of going to TPAC. But I'm not satisfied with the
>> current polyfill status.
>>
>>
>> Regards,
>>
>>
>> Dani
>>
>>
>>
>
> ------------------------------
> WIRIS and Design Science, makers of MathType, have joined forces!
> Thank you for your patience as we transition from dessci.com to wiris.com.
>