The
Planet MathML aggregates posts from various blogs that
concern MathML. Although it is hosted by W3C, the content of the
individual entries represent only the opinion of their respective
authors and does not reflect the position of
W3C.
The
Planet MathML aggregates posts from various blogs that
concern MathML. Although it is hosted by W3C, the content of the
individual entries represent only the opinion of their respective
authors and does not reflect the position of
W3C.
For many years Igalia has been committed to and dedicated efforts to the improvement of Web Platform in all open-source Web Engines (Chromium, WebKit, Servo, Gecko) and JavaScript implementations (V8, SpiderMonkey, ChakraCore, JSC). We have been working in the implementation and standardization of some important technologies (CSS Grid/Flexbox, ECMAScript, WebRTC, WebVR, ARIA, MathML, etc). This blog post contains a review of these activities performed during the first half (and a bit more) of 2017.
A few years ago Bloomberg and Igalia started a collaboration to implement a new layout model for the Web Platform. Bloomberg had complex layout requirements and what the Web provided was not enough and caused performance issues. CSS Grid Layout seemed to be the right choice, a feature that would provide such complex designs with more flexibility than the currently available methods.
We’ve been implementing CSS Grid Layout in Blink and WebKit, initially behind some flags as an experimental feature. This year, after some coordination effort to ensure interoperability (talking to the different parties involved like browser vendors, the CSS Working Group and the web authors community), it has been shipped by default in Chrome 58 and Safari 10.1. This is a huge step for the layout on the web, and modern websites will benefit from this new model and enjoy all the features provided by CSS Grid Layout spec.
Since the CSS Grid Layout shared the same alignment properties as the CSS Flexible Box feature, a new spec has been defined to generalize alignment for all the layout models. We started implementing this new spec as part of our work on Grid, being Grid the first layout model supporting it.
Finally, we worked on other minor CSS features in Blink such as caret-color or :focus-within and also several interoperability issues related to Editing and Selection.
MathML is a W3C recommendation to represent mathematical formulae that has been included in many other standards such as ISO/IEC, HTML5, ebook and office formats. There are many tools available to handle it, including various assistive technologies as well as generators from the popular LaTeX typesetting system.
After the improvements we performed in WebKit’s MathML implementation, we have regularly been in contact with Google to see how we can implement MathML in Chromium. Early this year, we had several meetings with Google’s layout team to discuss this in further details. We agreed that MathML is an important feature to consider for users and that the right approach would be to rely on the new LayoutNG model currently being implemented. We created a prototype for a small LayoutNG-based MathML implementation as a proof-of-concept and as a basis for future technical discussions. We are going to follow-up on this after the end of Q3, once Chromium’s layout team has made more progress on LayoutNG.
Servo is Mozilla’s next-generation web content engine based on Rust, a language that guarantees memory safety. Servo relies on a Rust project called WebRender which replaces the typical rasterizer and compositor duo in the web browser stack. WebRender makes extensive use of GPU batching to achieve very exciting performance improvements in common web pages. Mozilla has decided to make WebRender part of the Quantum Render project.
We’ve had the opportunity to collaborate with Mozilla for a few years now, focusing on the graphics stack. Our work has focused on bringing full support for CSS stacking and clipping to WebRender, so that it will be available in both Servo and Gecko. This has involved creating a data structure similar to what WebKit calls the “scroll tree” in WebRender. The scroll tree divides the scene into independently scrolled elements, clipped elements, and various transformation spaces defined by CSS transforms. The tree allows WebRender to handle page interaction independently of page layout, allowing maximum performance and responsiveness.
WebRTC is a collection of communications protocols and APIs that enable real-time communication over peer-to-peer connections. Typical use cases include video conferencing, file transfer, chat, or desktop sharing. Igalia has been working on the WebRTC implementation in WebKit and this development is currently sponsored by Metrological.
This year we have continued the implementation effort in WebKit for the WebKitGTK and WebKit WPE ports, as well as the maintenance of two test servers for WebRTC: Ericsson’s p2p and Google’s apprtc. Finally, a lot of progress has been done to add support for Jitsi using the existing OpenWebRTC backend.
Since OpenWebRTC development is not an active project anymore and given libwebrtc is gaining traction in both Blink and the WebRTC implementation of WebKit for Apple software, we are taking the first steps to replace the original WebRTC implementation in WebKitGTK based on OpenWebRTC, with a new one based on libwebrtc. Hopefully, this way we will share more code between platforms and get more robust support of WebRTC for the end users. GStreamer integration in this new implementation is an issue we will have to study, as it’s not built in libwebrtc. libwebrtc offers many services, but not every WebRTC implementation uses all of them. This seems to be the case for the Apple WebRTC implementation, and it may become our case too if we need tighter integration with GStreamer or hardware decoding.
WebVR is an API that provides support for virtual reality devices in Web engines. Implementation and devices are currently actively developed by browser vendors and it looks like it is going to be a huge thing. Igalia has started to investigate on that topic to see how we can join that effort. This year, we have been in discussions with Mozilla, Google and Apple to see how we could help in the implementation of WebVR on Linux. We decided to start experimenting an implementation within WebKitGTK. We announced our intention on the webkit-dev mailing list and got encouraging feedback from Apple and the WebKit community.
ARIA defines a way to make Web content and Web applications more accessible to people with disabilities. Igalia strengthened its ongoing committment to the W3C: Joanmarie Diggs joined Richard Schwerdtfeger as a co-Chair of the W3C’s ARIA working group, and became editor of the Core Accessibility API Mappings, [Digital Publishing Accessibility API Mappings] (https://w3c.github.io/aria/dpub-aam/dpub-aam.html), and Accessible Name and Description: Computation and API Mappings specifications. Her main focus over the past six months has been to get ARIA 1.1 transitioned to Proposed Recommendation through a combination of implementation and bugfixing in WebKit and Gecko, creation of automated testing tools to verify platform accessibility API exposure in GNU/Linux and macOS, and working with fellow Working Group members to ensure the platform mappings stated in the various “AAM” specs are complete and accurate. We will provide more information about these activities after ARIA 1.1 and the related AAM specs are further along on their respective REC tracks.
The AMP Project has recently sponsored Igalia to improve WebKit’s implementation of the Web platform. We have worked on many issues, the main ones being:
This project aligns with Web Platform Predictability which aims at making the Web more predictable for developers by improving interoperability, ensuring version compatibility and reducing footguns. It has been a good opportunity to collaborate with Google and Apple on improving the Web. You can find further details in this blog post.
Igalia has been involved in design, standardization and implementation of several JavaScript features in collaboration with Bloomberg and Mozilla.
In implementation, Bloomberg has been sponsoring implementation of modern JavaScript features in V8, SpiderMonkey, JSC and ChakraCore, in collaboration with the open source community:
On the design/standardization side, Igalia is active in TC39 and with Bloomberg’s support
In partnership with Mozilla, Igalia has been involved in the specification of various JavaScript standard library features for internationalization, in specification, implementation in V8, code reviews in other JavaScript engines, as well as working with the underlying ICU library.
Igalia has been organizing and hosting the Web Engines Hackfest since 2009. This event under an unconference format has been a great opportunity for Web Engines developers to meet, discuss and work together on the web platform and on web engines in general. We announced the 2017 edition and many developers already confirmed their attendance. We would like to thank our sponsors for supporting this event and we are looking forward to seeing you in October!
Emilio Cobos has completed his coding experience program on implementation of web standards. He has been working in the implementation of “display: contents” in Blink but some work is pending due to unresolved CSS WG issues. He also started the corresponding work in WebKit but implementation is still very partial. It has been a pleasure to mentor a skilled hacker like Emilio and we wish him the best for his future projects!
During this semester we have been glad to welcome new igalians who will help us to pursue Web platform developments:
Igalia has been involved in a wide range of Web Platform technologies going from Javascript and layout engines to accessibility or multimedia features. Efforts have been made in all parts of the process:
Although, some of this work has been sponsored by Google or Mozilla, it is important to highlight how external companies (other than browser vendors) can make good contributions to the Web Platform, playing an important role on its evolution. Alan Stearns already pointed out the responsibility of the Web Plaform users on the evolution of CSS while Rachel Andrew emphasized how any company or web author can effectively contribute to the W3C in many ways.
As mentioned in this blog post, Bloomberg is an important contributor of several open source projects and they’ve been a key player in the development of CSS Grid Layout or Javascript. Similarly, Metrological’s support has been instrumental for the implementation of WebRTC in WebKit. We believe others could follow their examples and we are looking forward to seeing more companies sponsoring Web Platform developments!
Hi everyone, Below are the minutes from the last CG meeting. The next meeting will be on Sep14. We'll continue the discussion around CSS polyfills. Best, Peter. # [math on web CG] minutes 2017-08-31 * Dani, Neil, Peter, Volker * Dani: new stretchy polyfill at https://w3c.github.io/mathonwebpages/examples/display/stretchy1.html * splits up vertical vs horizontal * also probably need to separate serif vs sans-serif, so we should have a custom attribute for that * Neil: not sure how serifs would show up in stretchy chars * Dani: horizontal lines can be thinner, vertical more bold * publishers will want distinction. * ideally, match fonts in terms of thickness * Peter: do you want to go thorough the polyfill? * Dani: prefer for people to take a closer look first * Dani: I'm thinking we should create a collection of such polyfills * Dani: it would be good to have something like a Unicode point for "fraction line" * [discussion about exposing fraction lines to AT] * Peter: in MathJax v3, stretchy will be done purely in CSS, no JS required, just growing with the box * JS still necessary for choosing between the available sizes in a font vs the truly stretchy constructoin * CSS element queries could help solve that. * Neil: can you share? * [screenshare] * Peter: ACTION yes, will have a public sample by next meeting * Peter: of course all approaches have drawbacks * [discussion about CSS approaches to stretchy] * Peter: variable fonts could solve a lot of issues * and even more so things like https://spectral.prototypo.io/ * Peter: Dani can you post to the CSS tracker on vertical-align? * Dani: ACTION yes but want to publish polyfill first * Dani: it would be good to get feedback for stretchy and fraction construction
Hi Everybody, I updated a new proof-of-concept “polyfil” with stretchy square brackets https://w3c.github.io/mathonwebpages/examples/display/stretchy1.html Planning to put all the examples at https://codepen.io See you in a few minutes! Dani *From:* Peter Krautzberger [mailto:peter@krautzource.com] *Sent:* lunes, 28 de agosto de 2017 10:41 *To:* mathonweb *Subject:* [math-on-web] CG meeting minutes, 2017/08/17 Hi everyone, Sorry for the very long delay in posting this. Below are the minutes from the last CG meeting. The next meeting will be on August 31 and we'll be focusing (and deciding) on a TPAC meeting. Best, Peter. # [math on web CG] minutes 2017-08-17 * Daniel: about polyfilling things * first approach done * https://w3c.github.io/mathonwebpages/examples/display/fraction1.html * Peter: only concern about polyfilling is that I can't see a JS math rendering engine using this polyfill because of its complexity * Peter: do you want to post this to the CSSWG thread? * Daniel: let me clean it up first * ACTION: post when ready * TPAC * Peter: not many people at TPAC, those who are seem very busy * Tzviya: if focus is on CSSWG, maybe meet them outside TPAC * 3-4 F2F per year, or just start with call * Daniel: call sounds a good idea * Daniel: if we publish the polyfill and get some feedback, that's great * if I manage to get to TPAC and can talk to folks in person, that would be worth it * ACTION Daniel will try to organize something with CSSWG * ACTION: Peter to write intro email to Alan * once we know more, we will update group * otherwise just spontaneous meeting * Tzviya: get Alan or Rawson today and announce as soon as possible. * [DONE] * Tzivya: where is the group at accessible math * getting lots more request * accessibility object model * now in Chrome * Peter: AOM is very interesting * Peter: but generally it seems the web platform is sufficient, cf. speech-rule-engine, Desmos's accessible editing interface etc * personally I'd recommend simply using alt-text generated by speech-rule-engine to annotate HTML or SVG equation rendering -- anyone can do this. * advanced: adding aria labels on MathML and expose them in HTML or SVG rendering to fix a11y tree * but that's obviously expensive right now though MathJax is doing research to automate that.
The AMP Project and Igalia have recently been collaborating to improve WebKit’s implementation of the Web platform. Both teams are committed to make the Web better and we expect that all developers and users will benefit from this effort. In this blog post, we review some of the bug fixes and features currently being considered:
Frame sandboxing: Implementing sandbox values to allow trusted third-party resources to open unsandboxed popups or restrict unsafe operations of malicious ones.
Frame scrolling on iOS: Trying to move to a
more standard and interoperable approach via iframe elements; addressing
miscellaneous issues with scrollable nodes (e.g. visual artifacts
while scrolling, view not scrolled when using “Find Text”…).
Root scroller: Finding a solution to the old interoperability issue about how to scroll the main frame; considering a new rootScroller API.
Some demo pages for frame sandboxing and scrolling are also available if you wish to test features discussed in this blog post.
AMP is an open-source project to enable websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms. Several interoperability bugs and missing features in WebKit have caused problems to AMP users and to Web developers in general. Although it is possible to add platform-specific workarounds to AMP, the best way to help the Web Platform community is to directly fix these issues in WebKit, so that everybody can benefit from these improvements.
Igalia is a consulting company with a team dedicated to Web Platform developments in all open-source Web Engines (Chromium, WebKit, Servo, Gecko) working in the implementation and standardization of miscellaneous technologies (CSS Grid/flexbox, ECMAScript, WebRTC, WebVR, ARIA, MathML, etc). Given this expertise, the AMP Project sponsored Igalia so that they can lead these developments in WebKit. It is worth noting that this project aligns with the Web Predictability effort supported by both Google and Igalia, which aims at making the Web more predictable for developers. In particular, the following aspects are considered:
Below we provide further description of the WebKit improvements, showing concretely how the above principles are followed.
A sandbox
attribute can be specified on the iframe element in order to enable a set
of restrictions on any content it hosts. These conditions can be
relaxed by specifying a list of values such as allow-scripts (to allow javascript
execution in the frame) or allow-popups (to allow the frame to open
popups). By default, the same restrictions apply to a popup opened
by a sandboxed frame.
However, sometimes this behavior is not wanted. Consider for example the case of an advertisement inside a sandboxed frame. If a popup is opened from this frame then it is likely that a non-sandboxed context is desired on the landing page. In order to handle this use case, a new allow-popups-to-escape-sandbox value has been introduced. The value is now supported in Safari Technology Preview 34.
While performing that work, it was noticed that some WPT tests for the sandbox attribute were still failing. It turns out that WebKit does not really follow the rules to allow navigation. More specifically, navigating a top context is never allowed when such context corresponds to an opened popup. We have made some changes to WebKit so that it behaves more closely to the specification. This is integrated into Safari Technology Preview 35 and you can for example try this W3C test. Note that this test requires to change preferences to allow popups.
It is worth noting that web engines may slightly depart from the specification regarding the previously mentioned rules. In particular, WebKit checks a same-origin condition to be sure that one frame is allowed to navigate another one. WebKit always has contained a special case to ignore this condition when a sandboxed frame with the allow-top-navigation flag tries and navigate its top frame. This feature, sometimes known as “frame busting,” has been used by third-party resources to perform malicious auto-redirecting. As a consequence, Chromium developers proposed to restrict frame busting to the case where the navigation is triggered by a user gesture.
According to
Chromium’s telemetry frame busting without a user gesture is
very rare. But when experimenting with the behavior change
of allow-top-navigation
several regressions were reported. Hence it was instead decided to
introduce the
allow-top-navigation-by-user-activation flag in order to
provide this improved safety context while still preserving
backward compatibility. We implemented this feature in WebKit and
it is now available in
Safari Technology Preview 37.
Finally, another proposed security improvement is to use an
allow-modals
flag to explicitly allow sandboxed frames to display modal dialogs
(with alert, prompt, etc). That is, the default
behavior for sandboxed frames will be to forbid such modal dialogs.
Again, such a change of behavior must be done with care.
Experiments in Chromium showed that the
usage of modal dialogs in sandboxed frames is very low and no
users complained. Hence we implemented that
behavior in WebKit and the feature should arrive in Safari
Technology Preview soon.
Check out the frame sandboxing
demos if if you want to test the new allow-popup-to-escape-sandbox,
allow-top-navigation-without-user-activation
and allow-modals flags.
Apple’s UI choice was to (almost) always “flatten” (expand) frames so that users do not require to scroll them. The rationale for this is that it avoids to be trapped into hierarchy of nested frames. Changing that behavior is likely to cause a big backward compatibility issue on iOS so for now we proposed a less radical solution: Add a heuristic to support the case of “fullscreen” iframes used by the AMP Project. Note that such exceptions already exist in WebKit, e.g. to avoid making offscreen content visible.
We thus added
the following heuristic into WebKit Nightly: do not flatten
out-of-flow iframes (e.g. position:
absolute) that have viewport units (e.g. vw and vh). This includes the case of the
“fullscreen” iframe previously mentioned. For now it is still under
a developer flag so that WebKit developers can control when they
want to enable it. Of course, if this is successful we might
consider more advanced heuristics.
The fact that frames are never
scrollable in iOS is an obvious interoperability issue. As a
workaround, it is possible to emulate such “scrollable nodes”
behavior using overflow:
scroll nodes with the -webkit-overflow-scrolling: touch
property set. This is not really ideal for our Web Predictability
goal as we would like to get rid of browser vendor prefixes. Also,
in practice such workarounds lead to even more problems in AMP as
explained in these
blog
posts. That’s why implementing scrolling of frames is one of
the main goals of this project and significant steps have already
been made in that direction.
The (relatively complex) class hierarchy involved in frame
scrolling is summarized in Figure 2. The frame flattening heuristic
mentioned above is handled in the WebCore::RenderIFrame class (in purple).
The WebCore::ScrollingTreeFrameScrollingNodeIOS
and WebCore::ScrollingTreeOverflowScrollingNodeIOS
classes from the scrolling tree (in blue) are used to scroll,
respectively, the main frame and overflow nodes on iOS. Scrolling
of non-main frames will obviously have some code to share with the
former, but it will also have some parts in common with the latter.
For example, passing an extra UIScrollView layer is needed instead of
relying on the one contained in the WKWebView of the main frame. An
important step is thus to introduce a special class for scrolling
inner frames that would share some logic from the two other classes
and some
refactoring to ensure optimal
code reuse. Similar refactoring has been done for scrolling
node states (in red) to move the
scrolling layer parameter into WebCore::ScrollingStateNode instead
of having separate members for WebCore::ScrollingStateOverflowScrollingNode
and WebCore::ScrollingStateFrameScrollingNode.
The scrolling coordinator classes (in green) are also important,
for example to handle hit testing. At the moment, this is not
really implemented for overflow nodes but it might be important to
have it for scrollable frames. Again, one sees that some logic is
shared for asynchronous scrolling on macOS (WebCore::ScrollingCoordinatorMac) and
iOS (WebCore::ScrollingCoordinatorIOS) in
ancestor classes. Indeed, our effort to make frames scrollable on
iOS is also opening the possibility of asynchronous
scrolling of frames on macOS, something that is currently not
implemented.
Finally, some more work is necessary in the render classes
(purple) to ensure that the layer hierarchies are correctly built.
Patches have been
uploaded and you can view the result on the video of Figure 4.
Notice that this work has not been reviewed yet and there are known
bugs, for example with overlapping elements (hit testing not
implemented) or position:
fixed elements.
Various other scrolling bugs were reported, analyzed and
sometimes fixed by Apple. The switch from overflow nodes to
scrollable iframes is unlikely to address them. For example, the
“Find Text” operation in iOS has advanced features done by the UI
process (highlight, smart magnification) but the scrolling
operation needed only works for the main frame. It looks like
this could be fixed by unifying a bit the scrolling code path with
macOS. There are also several jump and
flickering bugs with position:
fixed nodes. Finally, Apple fixed inconsistent
scrolling inertia used for the main frame and the one used for
inner scrollable nodes by making the former the same as the
latter.
The CSSOM View specification
extends the DOM element with some scrolling properties. That
specification indicates that the element to consider to scroll the
main view is document.body
in quirks mode while it is document.documentElement in no-quirks
mode. This is the behavior that has always been followed by
browsers like Firefox or Interner Explorer. However, WebKit-based
browsers always treat document.body as the root scroller. This
interoperability issue has been a big problem for web developers.
One convenient workaround was to introduce the
document.scrollingElement which returns the element to use for
scrolling the main view (document.body or document.documentElement) and was
recently implemented in
WebKit. Use this test
page to verify whether your browser supports the document.scrollingElement property and
which DOM element is used to scroll the main view in no-quirks
mode.
Nevertheless, this does not solve the issue with existing web
pages. Chromium’s Web Platform Predictability team has made a huge
communication effort with Web authors and developers which has
drastically reduced the use of document.body in no-quirks mode. For
instance, Chromium’s telemetry on Figure 3 indicates that the
percentage of document.body.scrollTop in no-quirks
pages has gone from 18% down to 0.0003% during the past three
years. Hence the Chromium team is now considering
shipping the standard behavior.
document.body.scrollTop
in no-quirks mode over time (Chromium's UseCounter)In WebKit, the issue has been known for a long time and an old attempt to fix it was reverted for causing regressions. For now, we imported the CSSOM View tests and just marked the one related to the scrolling element as failing. An analysis of the situation has been left on WebKit’s bug; Depending on how things evolve on Chromium’s side we could consider the discussion and implementation work in WebKit.
Related to that work, a new API is being proposed to set the root scroller to an arbitrary scrolling element, giving more flexibility to authors of Web applications. Today, this is unfortunately not possible without losing some of the special features of the main view (e.g. on iOS, Safari’s URL bar is hidden when scrolling the main view to maximize the screen space). Such API is currently being experimented in Chromium and we plan to investigate whether this can be implemented in WebKit too.
In the past months, The AMP Project and Igalia have worked on analyzing some interoperability issue and fixing them in WebKit. Many improvements for frame sandboxing are going to be available soon. Significant progress has also been made for frame scrolling on iOS and collaboration continues with Apple reviewers to ensure that the work will be integrated in future versions of WebKit. Improvements to “root scrolling” are also being considered although they are pending on the evolution of the issues on Chromium’s side. All these efforts are expected to be useful for WebKit users and the Web platform in general.
Last but not least, I would like to thank Apple engineers Simon Fraser, Chris Dumez, and Youenn Fablet for their reviews and help, as well as Google and the AMP team for supporting that project.
Hi everyone, Sorry for the very long delay in posting this. Below are the minutes from the last CG meeting. The next meeting will be on August 31 and we'll be focusing (and deciding) on a TPAC meeting. Best, Peter. # [math on web CG] minutes 2017-08-17 * Daniel: about polyfilling things * first approach done * https://w3c.github.io/mathonwebpages/examples/display/fraction1.html * Peter: only concern about polyfilling is that I can't see a JS math rendering engine using this polyfill because of its complexity * Peter: do you want to post this to the CSSWG thread? * Daniel: let me clean it up first * ACTION: post when ready * TPAC * Peter: not many people at TPAC, those who are seem very busy * Tzviya: if focus is on CSSWG, maybe meet them outside TPAC * 3-4 F2F per year, or just start with call * Daniel: call sounds a good idea * Daniel: if we publish the polyfill and get some feedback, that's great * if I manage to get to TPAC and can talk to folks in person, that would be worth it * ACTION Daniel will try to organize something with CSSWG * ACTION: Peter to write intro email to Alan * once we know more, we will update group * otherwise just spontaneous meeting * Tzviya: get Alan or Rawson today and announce as soon as possible. * [DONE] * Tzivya: where is the group at accessible math * getting lots more request * accessibility object model * now in Chrome * Peter: AOM is very interesting * Peter: but generally it seems the web platform is sufficient, cf. speech-rule-engine, Desmos's accessible editing interface etc * personally I'd recommend simply using alt-text generated by speech-rule-engine to annotate HTML or SVG equation rendering -- anyone can do this. * advanced: adding aria labels on MathML and expose them in HTML or SVG rendering to fix a11y tree * but that's obviously expensive right now though MathJax is doing research to automate that.
After a very smooth beta run, we’re happy to officially release MathJax v2.7.2.
This release includes a workaround for a regression in Safari when using combining characters as well as an important update to the MathJax Accessibility Extensions and the underlying speech-rule-engine, greatly improving performance and quality.
For details on all bug fixes, please see below.
This release should be available on all CDN providers, e.g., cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.2/MathJax.js which you can load it in place of the version you are currently using. Alternatively, you can get a ZIP archive or access the branch on GitHub.
Thanks for your continuing interest in MathJax. We hope that this release makes your MathJax experience even better.
The MathJax Team.
useMMLspacing is in effect. #1626 #1786<=> arrow in
mhchem. 1657 #1795getNode() method not descending
into all the children. #1691 #1791\Rule and add
\rule macro. #1666 #1673\shoveleft and
\shoveright. #1701 #1782\text{} in
\cases{}. #1482 #1793aligned/alignedat.
#1690
#1784For more information see also the 2.7.2 milestone.
I tried in chrome https://appear.in/mathonweb and it is not working for me sorry. Thanks EOM Charles LaPierre Technical Lead, DIAGRAM and Born Accessible E-mail: charlesl@benetech.org<mailto:charlesl@benetech.org> Twitter: @CLaPierreA11Y Skype: charles_lapierre Phone: 650-600-3301 On Aug 17, 2017, at 9:08 AM, Siegman, Tzviya - Hoboken <tsiegman@wiley.com<mailto:tsiegman@wiley.com>> wrote: Hi Peter, I tried to call in, but Google Hangouts just hung. Tzviya Siegman Information Standards Lead Wiley 201-748-6884 tsiegman@wiley.com<mailto:tsiegman@wiley.com> From: Peter Krautzberger [mailto:peter@krautzource.com] Sent: Thursday, August 17, 2017 8:56 AM To: mathonweb <public-mathonwebpages@w3.org<mailto:public-mathonwebpages@w3.org>> Subject: Reminder: Meeting today Hi everyone, We are scheduled to meet today, Aug 17, 12pm Eastern time. We'll be focusing (and deciding) on a TPAC meeting. Best, Peter.
Hi Peter, I tried to call in, but Google Hangouts just hung. Tzviya Siegman Information Standards Lead Wiley 201-748-6884 tsiegman@wiley.com<mailto:tsiegman@wiley.com> From: Peter Krautzberger [mailto:peter@krautzource.com] Sent: Thursday, August 17, 2017 8:56 AM To: mathonweb <public-mathonwebpages@w3.org> Subject: Reminder: Meeting today Hi everyone, We are scheduled to meet today, Aug 17, 12pm Eastern time. We'll be focusing (and deciding) on a TPAC meeting. Best, Peter.
Tzviya Siegman Information Standards Lead Wiley 201-748-6884 tsiegman@wiley.com<mailto:tsiegman@wiley.com> From: Peter Krautzberger [mailto:peter@krautzource.com] Sent: Monday, August 07, 2017 6:42 AM To: mathonweb <public-mathonwebpages@w3.org> Subject: [math-on-web] TPAC Poll Hi everyone, As per the last meeting, we would like to do a quick poll regarding TPAC [1]. 1. Will you be at TPAC this year? Yes 2. Will you be in the Bay area around TPAC? yes 3. Would you join a CG meeting at TPAC? It depends on timing and conflicts 4. Would you join a CG meeting outside of TPAC? It depends on timing and conflicts 5. Would you join a CG meeting remotely? It depends on timing and conflicts Please send a quick response (to me or Dani) before the next CG meeting on Aug 17. Best regards, Peter. [1] https://www.w3.org/2017/11/TPAC/Overview.html
Hi everyone, As per the last meeting, we would like to do a quick poll regarding TPAC [1]. 1. Will you be at TPAC this year? 2. Will you be in the Bay area around TPAC? 3. Would you join a CG meeting at TPAC? 4. Would you join a CG meeting outside of TPAC? 5. Would you join a CG meeting remotely? Please send a quick response (to me or Dani) before the next CG meeting on Aug 17. Best regards, Peter. [1] https://www.w3.org/2017/11/TPAC/Overview.html
Hi everyone, Below are the minutes from the CG meeting last week. A bit more condensed than usual. The next meeting will be on August 17 and we'll be focusing (and deciding) on a TPAC meeting. Best, Peter. # [math on web CG] minutes 2017-08-03 * Present: Volker, Charles, Kevin, Peter * Volker: should there be a meeting at TPAC? If so, when? * Peter: I can't be there, I'm afraid * Charles: I'll be there * Volker: whne is it? * https://www.w3.org/2017/11/TPAC/Overview.html, Nov 6-10 * Charles: PWG is meeting 6&7 * 9&10 Publishing summit * Volker: restrictions for CG? * not days but 4 groups per day * Volker: Dani said he'd probably be there * Volker: if there's a meeting with CSS WG * maybe more an ad-hoc * Peter: as Tzviya said, make early plans with CSS, they are very busy * Peter: make another call to action on mailing list? * => ACTION * Charles: maybe ARIA WG as well, to talk about semantics? * Volker: maybe good. E.g., clarifying math role * Volker: ACTION maybe email should be straw poll who will be there anyway * Peter: maybe poll for who's in the area, maybe off-site/schedule meeting is of interes * Charles: q about MathJax: if I have an image and MathML, once MathJax does the mathML, will there be two visuals? * Peter: yes. but you can hook into MathJax to remove the image after rendering * Peter: next meeting topic: maybe my suggestion for stepping back and talking about why each of us is here? * follow up by emails
On Tue, 2017-07-11 at 15:58 +0200, Daniel Marques wrote: > Hi Liam, > > Sorry for my delayed answer but I'm in the middle of closing many > projects. No problem, same here! > > It is great that some people still think that with CSS should be > possible to do mathematics easier. It is probably very improbable to > be able to do all the MathML specification. But, at least, simple > formulas with fractions, roots and matrices, among others, should be > achievable. Yes, for sure. > > You say > > If this CG were to come up with a list of the most urgent things > > together > > with some tests (and patches for browsers?) I can see something > > happening. > > That's for sure a starting point and makes sense working in this > direction. > We can elaborate it more during the following group meetings. Thanks, cool. A "next next step" might be to explore some polyfills. Liam -- Liam Quin, W3C, http://www.w3.org/People/Quin/ Staff contact for Verifiable Claims WG, XQuery WG Web slave for http://www.fromoldbooks.org/
Today we are entering the public beta phase of MathJax v2.7.2, a bug-fix release with over 30 important bug fixes.
This release includes a workaround for a regression in Safari when using combining characters as well as an important update to the MathJax Accessibility Extensions and the underlying speech-rule-engine, greatly improving performance and quality.
For details on all bug fixes, please see below.
The beta should be available on all CDN providers, e..g., cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.2-beta.1/MathJax.js which you can load it in place of the version you are currently using. Alternatively, you can get a ZIP archive or access the branch on GitHub.
Remember that this is still beta software, so if you are not an experienced user, you may want to wait for the official 2.7.2 release. We do not recommend that you use the -beta version for production environments, but do encourage you to test your content with it.
The official release of v2.7.2 should occur within the next few weeks, but we want you to be able to start to test out the v2.7.2 features now. Please report any bugs you find to the issue tracker at https://github.com/mathjax/MathJax/issues.
Thanks for your continuing interest in MathJax. We hope that this release makes your MathJax experience even better.
The MathJax Team.
useMMLspacing is in effect. #1626 #1786<=> arrow in
mhchem. 1657 #1795getNode() method not descending
into all the children. #1691 #1791\Rule and add
\rule macro. #1666 #1673\shoveleft and
\shoveright. #1701 #1782\text{} in
\cases{}. #1482 #1793aligned/alignedat.
#1690
#1784For more information see also the 2.7.2 milestone.
It isn't wrong to put things in the WICG's discourse in the CSS category, but note that relatively few members of the CSSWG ever look there. If you don't feel ready to make a proposal to the CSSWG, this is potentially a good place to keep baking your ideas until you feel ready to present them, but if you do feel ready to talk about them, the CSSWG's github issues[1] or mailing list[2] are much more likely to get CSS people's attention. —Florian [1] https://github.com/w3c/csswg-drafts/issues [2] www-style@w3.org > On Jul 21, 2017, at 20:26, Siegman, Tzviya - Hoboken <tsiegman@wiley.com> wrote: > > That looks good. I recommend adding something to the Web Incubator CG at https://discourse.wicg.io <https://discourse.wicg.io/> in the CSS category. > > Tzviya Siegman > Information Standards Lead > Wiley > 201-748-6884 > tsiegman@wiley.com <mailto:tsiegman@wiley.com> > > From: Daniel Marques [mailto:dani@wiris.com] > Sent: Friday, July 21, 2017 6:18 AM > To: Siegman, Tzviya - Hoboken <tsiegman@wiley.com>; Jean Kaplansky <jeankap@earthlink.net>; Arno Gourdol <arno@arno.org> > Cc: Volker Sorge <volker.sorge@gmail.com>; mathonweb <public-mathonwebpages@w3.org>; Peter Krautzberger <peter@krautzource.com> > Subject: RE: Reminder: Meeting today > > Hi Tzviya, > > Thanks for the information regarding the submissions. > > Just wondering how much in advance… Regarding polyfills, did you mean something likehttps://w3c.github.io/mathonwebpages/examples/display/fraction1.html <https://w3c.github.io/mathonwebpages/examples/display/fraction1.html> (this is work in progress) ? > > Regards, > <> > Dani > > From: Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com <mailto:tsiegman@wiley.com>] > Sent: jueves, 20 de julio de 2017 22:37 > To: Jean Kaplansky; Arno Gourdol > Cc: Volker Sorge; Daniel Marques; mathonweb; Peter Krautzberger > Subject: RE: Reminder: Meeting today > > Hi All, > > Apologies for not being attend. If you have proposals for the CSS WG, you should get them to the group well in advance of TPAC. They usually have a really packed schedule. The way CSS tends to work these days is with submissions of polyfills, not just ideas. > > Tzviya > > Tzviya Siegman > Information Standards Lead > Wiley > 201-748-6884 > tsiegman@wiley.com <mailto:tsiegman@wiley.com> > > From: Jean Kaplansky [mailto:jeankap@earthlink.net <mailto:jeankap@earthlink.net>] > Sent: Thursday, July 20, 2017 4:18 PM > To: Arno Gourdol <arno@arno.org <mailto:arno@arno.org>> > Cc: Volker Sorge <volker.sorge@gmail.com <mailto:volker.sorge@gmail.com>>; Daniel Marques <dani@wiris.com <mailto:dani@wiris.com>>; mathonweb <public-mathonwebpages@w3.org <mailto:public-mathonwebpages@w3.org>>; Peter Krautzberger <peter@krautzource.com <mailto:peter@krautzource.com>> > Subject: Re: Reminder: Meeting today > > Hi, Everyone - > > K-12 publishing in the Western Hemisphere will be eternally grateful if you guys can take up the elementary math use cases with the CSS group too. Long division and Stacked Equations especially. > > I'll keep an eye out for any google doc you guys may start to make sure that these use cases get on the list. > > Thanks for considering. > > Best, > > Jean Kaplansky > Content Architect/Strategist | Technical Account Manager | UI/UX | > Accessibility Analyst | XML, HTML, and CSS Developer | > Instructional Designer > +1.518.930.1068 > jeankap@earthlink.net <mailto:jeankap@earthlink.net> > @jeankaplansky > > On Thu, Jul 20, 2017 at 12:35 PM, Arno Gourdol <arno@arno.org <mailto:arno@arno.org>> wrote: > > Minutes from 20 JULY 2017 Math On Web telcon > Minute taker: Arno. > Dani: would like to discuss with CSS WG about possibility to incorporate new CSS features that would suit out needs for mathematics. > > > > At TPAC, we have the possibility to discuss with CSS WG what we would need to display mathematics without JS. > > > > First we would need the scope of equations we want to support: fractions, matrix, big operators, supsub…? > > > > Second, explain why CSS as it is is not enough to do represent those equations > > > > Third, provide some hint/prototypes of what the solution could look like, perhaps with a Javascript implementation. > > > > We need to do some planing to prepare for this, vacations are coming up for everyone. > > > > Neil: I’m away in August. > > > > Neil: For large operators, would that include stretchy parens? > > > > Dani: yes, probably. > > > > Neil: if we can suggest to the CSS WG some non-math use cases, that will help motivate them > > > > Dani: which math would we want to do? For example, fractions? > > > > Neil: Wouldn’t Peter have a list like that? Has he approached the CSS WG already with some proposals? > > > > Dani: not that I’m aware of. Peter has had some unofficial conversations, perhaps. > > > > Neil/John: square roots would be useful as well. > > > > Neil: are fractions actually a problem? > > > > Dani: sometimes the fraction bar need to be moved up or down, and it needs to be computed depending on the font size. > > > > Arno: we would probably need to have the concept of “math axis” similar to the “baseline” that exist today > > > > Dani: flex box allows vertical alignments, and that helps for fractions and big operators > > > > Neil: sounds like flex box is solving the problem for big operators, then? > > > > Dani: yes, partially. But you need to move the operator to align with the math axis. > > > > John: sounds like we need to work on a list of those cases > > > > Arno: we also need to think of integrals that require limits to be displayed offset from the symbol > > > > John: is there that list somewhere? > > > > Neil: I thought Peter had something, but that may have been a long time ago… > > > > Arno: I’d suggest creating a Google Docs that we could all collaborate on, with the goal of having something ready in time for TPAC. > > > > Dani: I will create the document and share it with the group so we can start collaborating on these ideas. >
That looks good. I recommend adding something to the Web Incubator CG at https://discourse.wicg.io in the CSS category. Tzviya Siegman Information Standards Lead Wiley 201-748-6884 tsiegman@wiley.com<mailto:tsiegman@wiley.com> From: Daniel Marques [mailto:dani@wiris.com] Sent: Friday, July 21, 2017 6:18 AM To: Siegman, Tzviya - Hoboken <tsiegman@wiley.com>; Jean Kaplansky <jeankap@earthlink.net>; Arno Gourdol <arno@arno.org> Cc: Volker Sorge <volker.sorge@gmail.com>; mathonweb <public-mathonwebpages@w3.org>; Peter Krautzberger <peter@krautzource.com> Subject: RE: Reminder: Meeting today Hi Tzviya, Thanks for the information regarding the submissions. Just wondering how much in advance… Regarding polyfills, did you mean something like https://w3c.github.io/mathonwebpages/examples/display/fraction1.html (this is work in progress) ? Regards, Dani From: Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com<mailto:tsiegman@wiley.com>] Sent: jueves, 20 de julio de 2017 22:37 To: Jean Kaplansky; Arno Gourdol Cc: Volker Sorge; Daniel Marques; mathonweb; Peter Krautzberger Subject: RE: Reminder: Meeting today Hi All, Apologies for not being attend. If you have proposals for the CSS WG, you should get them to the group well in advance of TPAC. They usually have a really packed schedule. The way CSS tends to work these days is with submissions of polyfills, not just ideas. Tzviya Tzviya Siegman Information Standards Lead Wiley 201-748-6884 tsiegman@wiley.com<mailto:tsiegman@wiley.com> From: Jean Kaplansky [mailto:jeankap@earthlink.net] Sent: Thursday, July 20, 2017 4:18 PM To: Arno Gourdol <arno@arno.org<mailto:arno@arno.org>> Cc: Volker Sorge <volker.sorge@gmail.com<mailto:volker.sorge@gmail.com>>; Daniel Marques <dani@wiris.com<mailto:dani@wiris.com>>; mathonweb <public-mathonwebpages@w3.org<mailto:public-mathonwebpages@w3.org>>; Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>> Subject: Re: Reminder: Meeting today Hi, Everyone - K-12 publishing in the Western Hemisphere will be eternally grateful if you guys can take up the elementary math use cases with the CSS group too. Long division and Stacked Equations especially. I'll keep an eye out for any google doc you guys may start to make sure that these use cases get on the list. Thanks for considering. Best, Jean Kaplansky Content Architect/Strategist | Technical Account Manager | UI/UX | Accessibility Analyst | XML, HTML, and CSS Developer | Instructional Designer +1.518.930.1068 jeankap@earthlink.net<mailto:jeankap@earthlink.net> @jeankaplansky On Thu, Jul 20, 2017 at 12:35 PM, Arno Gourdol <arno@arno.org<mailto:arno@arno.org>> wrote: Minutes from 20 JULY 2017 Math On Web telcon Minute taker: Arno. Dani: would like to discuss with CSS WG about possibility to incorporate new CSS features that would suit out needs for mathematics. At TPAC, we have the possibility to discuss with CSS WG what we would need to display mathematics without JS. First we would need the scope of equations we want to support: fractions, matrix, big operators, supsub…? Second, explain why CSS as it is is not enough to do represent those equations Third, provide some hint/prototypes of what the solution could look like, perhaps with a Javascript implementation. We need to do some planing to prepare for this, vacations are coming up for everyone. Neil: I’m away in August. Neil: For large operators, would that include stretchy parens? Dani: yes, probably. Neil: if we can suggest to the CSS WG some non-math use cases, that will help motivate them Dani: which math would we want to do? For example, fractions? Neil: Wouldn’t Peter have a list like that? Has he approached the CSS WG already with some proposals? Dani: not that I’m aware of. Peter has had some unofficial conversations, perhaps. Neil/John: square roots would be useful as well. Neil: are fractions actually a problem? Dani: sometimes the fraction bar need to be moved up or down, and it needs to be computed depending on the font size. Arno: we would probably need to have the concept of “math axis” similar to the “baseline” that exist today Dani: flex box allows vertical alignments, and that helps for fractions and big operators Neil: sounds like flex box is solving the problem for big operators, then? Dani: yes, partially. But you need to move the operator to align with the math axis. John: sounds like we need to work on a list of those cases Arno: we also need to think of integrals that require limits to be displayed offset from the symbol John: is there that list somewhere? Neil: I thought Peter had something, but that may have been a long time ago… Arno: I’d suggest creating a Google Docs that we could all collaborate on, with the goal of having something ready in time for TPAC. Dani: I will create the document and share it with the group so we can start collaborating on these ideas.
Hi Arno and others! Thanks for the minutes. I created the document https://docs.google.com/document/d/1VZcmZad-ZU6zC390r4LiQLIcO415bQOhoDVonN7sIsw/edit and I've given access to some of you. Anyone that wants a write access can request it to me and I will give it. Regards, Dani On Thu, Jul 6, 2017 at 7:20 PM, Arno Gourdol <arno@arno.org> wrote: > > Minutes from the meeting today. Any transcription errors are my own. > > Display of math in HTML 5 > > > Peter want to discuss MathML, but not feeling well today and he sends his > apologies. > > > Neil Soiffer: Peter has said that MathML is inadequate on the web. What > are its particular limitations/problems? > > > Volker Sorge: MathML is a fine presentation language. But it’s not > implemented, and probably won’t be fully implemented. It’s not modern > enough. It was trying to do things ten years ago that are now available in > CSS/HTML. What is really *necessary* to render Math that is not available > in HTML/CSS today? Rather than keep asking for an implementation of MathML > that is not happening. > > > Neil: Understood, but custom elements, shadow DOM may be a way to leave > the DOM clean and use CSS for rendering. And it’s been closer to twenty > years, not ten! So, are there things very problematic in MathML that would > never make it in CSS? For example, I’ve always been opposed to <mfence>, > <mstyle>, but what else? > > > <someone>: <mfence>: we all hate it! > > > Neil: Always regretted <mfence>, I’d be happy to see it go. What else are > we talking about? Maybe you don’t believe in Shadow DOM or custom elements, > but if they do happen, it would leave the DOM nice and clean. > > > Volker: do you expect browsers to implement MathML or web apps to make use > of it. Should MathML not be adapted to be more realistic to what browsers > would actually implement? > > > Neil: The problem with MathJax, etc… is that you’re polluting the DOM and > have spans, etc… that don’t represent the content, but just the > presentation. Shadow DOM could help with that. I’d like to see browser > implementation of MathML, but the major thing is to have a clean DOM > instead of a tag soup. I’d like to see MathML implemented with a shadow > DOM, and maybe it would encourage browser vendors to adopt it. > > > Volker: One of my main issues with MathML is that presentation MathML has > some semantic in it, which can be confusing and abused for other things. Is > it really necessary to have a special <mfrac> or special square root, etc.. > rather than something more general to “enclose” elements. > > > Stretching characters is a particular problem to cover. > > > Neil: <menclose> has a square root option, but you’d rather see it > generalized? Not sure how we would deal with n-th root, but there might be > a way. > > > Volker: yeah, and same thing for fractions. In particular for > accessibility, you’d want to control the order: just have a bar and specify > where the numer/denom is in the DOM. > > > Neil: asian languages read fractions the other way around, but they’re > displayed the same way. > > > Volker: you’d want to draw them the same way, but want to traverse them > differently in the DOM. > > > Neil: not sure I see the need for that. If a screen reader wants to read > in a certain way, they can determine what is the right order > > > Arno: but wouldn’t it be difficult without the semantic information for > the screen reader to infer the correct order? > > > Volker: I don’t always want to represent a fraction, so I want to be able > to give it explicit order, kinda like a ‘z-index’, but for reading order. > For example, in logic, when you want to talk about conclusions before > premises, the author may want to specify the correct order. There should be > a better separation between presentation and semantics. > > > Dani: the assistive technology can read the page, can access the DOM, but > the assistive technology shouldn’t have to infer the semantic > > > Volker: yes. With web apps for example, you can implement a pull down menu > for example, however you want. The ARIA attributes will give screen readers > the right info to interpret it correctly. > > > Neil: there is a difference. Screen readers already know about buttons, > etc… but they don’t know about fractions, etc.. > > > Volker: true, but couldn’t you put some descriptions for the things they > don’t know. > > > Neil: they would need to know about some primitives: fractions, > deductions, etc… > > > Volker: what would they need to know about semantics? Couldn’t they just > have some info about order, and what to say? > > > Neil: but that’s language dependent. The order and how to say it in other > languages. In fact, with math speech, there isn’t a single way to say > something. Why force it? > > > Volker: if I’m in an English web page, I don’t expect the screen reader to > tell it to me in German. If there’s English math on it, it should read it > in English, not try to localize it in German. > > > Neil: Once it’s been generated, the language is known, I agree, but there > are still multiple way to speak math notations. Steve Noble went to a > school, but a teacher said “that’s not how I say parenthesis”. And another > teacher in the same school was saying the same thing completely differently > (“open paren” vs. “left paren”, etc…) > > > Volker: shouldn’t the author be in control of that? > > > Neil: the teacher might be reading Wikipedia or Kahn academy, something > they didn’t author. For example, screen readers give control over how much > punctuations are said. > > > Steve Noble: We found that students who are visually impaired needed the > additional language (“begin root”/“end root”) to read while other students > who are dyslexic for example would stumble with that same additional > language. Users that use a Braille Nemeth reader need a different rendering > that Braille users using a different system. > > > Volker: I agree there’s still a lot of work to do on the screen reader > side, but I still don’t see why we need MathML for that. Unfortunately, I > do have the leave the call now. > > > Steve: I see three pillars: > > (1) There are problems with the MathML standard and they should be fixed. > > (2) browsers and other tools need to implement MathML. > > (3) techniques we use in the meantime, like MathJAX, while the other > pillars get resolved on their own timeline > > > Volker: I don’t feel like the second pillar will ever happen, and we > should step back and determine more realistic goals in terms of changes to > CSS/HTML, like stretchy characters. > > > Dani: MathML is also important from the authoring point of view: if you > create a tool to create a formula you need an interoperable way to exchange > machine-readable formulas between tools. > > > Arno: what would be the benefit of MathML over LaTeX for interchange? > > > Neil: the problem with LaTeX is that it’s a programming language, with no > fixed syntax, lots of extensions. Too powerful to be used for exchange > unless you have a full TeX engine. Also MathML is easy to parse, since it’s > XML, easy to get a tree. > > > Arno: have there been discussions of a JSON version of MathML that would > be even easier to parse? > > > Neil: not aware of it, but there are mapping between XML and JSON, so it’s > certainly possible. > > > Dani: didn’t think a lot about what I would change in MathML, but > interoperability between browsers could be better. Simple things like > fractions, stretchy characters is where the difficulties are today, so > changing MathML would not be a priority for me. > > > Neil: Another thing that would be useful could be font info. > > > Arno: Agreed. To do a layout with CSS/HTML you sometimes have to get > measurements of elements, and it’s not always easy to do. You have to use > some workarounds, like creating elements and temporarily inserting them as > invisible elements in the page in order to get their bounding rectangles. > Would be much better to have an API to measure offscreen elements. It would > also be very useful to have access to information such as the math axis and > other math typesetting specific data which are available in some “math” > fonts such as Cambria Math (see https://www.microsoft.com/ > typography/otspec/math.htm). > > > Dani: but some of that info is not proportional to the font size. For > example, a 2pt value at 16pt may need to be 5pt at 32pt. > > > Arno: That’s right, and that’s the information that is included in those > ‘math’ tables that are embedded in ‘math’ fonts, but that information is > not accessible from CSS or Javascript. Same thing if the concept of “math > axis” similar to the concept of “baseline” was understood by CSS. It would > make math layout much easier. That would be really nice to have. Perhaps an > area of further discussion and collaboration with the CSS WG and others? > > > > > > > > > > > >
Hi Tzviya, Thanks for the information regarding the submissions. Just wondering how much in advance… Regarding polyfills, did you mean something like https://w3c.github.io/mathonwebpages/examples/display/fraction1.html (this is work in progress) ? Regards, Dani *From:* Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com] *Sent:* jueves, 20 de julio de 2017 22:37 *To:* Jean Kaplansky; Arno Gourdol *Cc:* Volker Sorge; Daniel Marques; mathonweb; Peter Krautzberger *Subject:* RE: Reminder: Meeting today Hi All, Apologies for not being attend. If you have proposals for the CSS WG, you should get them to the group well in advance of TPAC. They usually have a really packed schedule. The way CSS tends to work these days is with submissions of polyfills, not just ideas. Tzviya *Tzviya Siegman* Information Standards Lead Wiley 201-748-6884 tsiegman@wiley.com *From:* Jean Kaplansky [mailto:jeankap@earthlink.net <jeankap@earthlink.net>] *Sent:* Thursday, July 20, 2017 4:18 PM *To:* Arno Gourdol <arno@arno.org> *Cc:* Volker Sorge <volker.sorge@gmail.com>; Daniel Marques <dani@wiris.com>; mathonweb <public-mathonwebpages@w3.org>; Peter Krautzberger < peter@krautzource.com> *Subject:* Re: Reminder: Meeting today Hi, Everyone - K-12 publishing in the Western Hemisphere will be eternally grateful if you guys can take up the elementary math use cases with the CSS group too. Long division and Stacked Equations especially. I'll keep an eye out for any google doc you guys may start to make sure that these use cases get on the list. Thanks for considering. Best, *Jean Kaplansky* Content Architect/Strategist | Technical Account Manager | UI/UX | Accessibility Analyst | XML, HTML, and CSS Developer | Instructional Designer +1.518.930.1068 jeankap@earthlink.net @jeankaplansky On Thu, Jul 20, 2017 at 12:35 PM, Arno Gourdol <arno@arno.org> wrote: Minutes from 20 JULY 2017 Math On Web telcon Minute taker: Arno. Dani: would like to discuss with CSS WG about possibility to incorporate new CSS features that would suit out needs for mathematics. At TPAC, we have the possibility to discuss with CSS WG what we would need to display mathematics without JS. First we would need the scope of equations we want to support: fractions, matrix, big operators, supsub…? Second, explain why CSS as it is is not enough to do represent those equations Third, provide some hint/prototypes of what the solution could look like, perhaps with a Javascript implementation. We need to do some planing to prepare for this, vacations are coming up for everyone. Neil: I’m away in August. Neil: For large operators, would that include stretchy parens? Dani: yes, probably. Neil: if we can suggest to the CSS WG some non-math use cases, that will help motivate them Dani: which math would we want to do? For example, fractions? Neil: Wouldn’t Peter have a list like that? Has he approached the CSS WG already with some proposals? Dani: not that I’m aware of. Peter has had some unofficial conversations, perhaps. Neil/John: square roots would be useful as well. Neil: are fractions actually a problem? Dani: sometimes the fraction bar need to be moved up or down, and it needs to be computed depending on the font size. Arno: we would probably need to have the concept of “math axis” similar to the “baseline” that exist today Dani: flex box allows vertical alignments, and that helps for fractions and big operators Neil: sounds like flex box is solving the problem for big operators, then? Dani: yes, partially. But you need to move the operator to align with the math axis. John: sounds like we need to work on a list of those cases Arno: we also need to think of integrals that require limits to be displayed offset from the symbol John: is there that list somewhere? Neil: I thought Peter had something, but that may have been a long time ago… Arno: I’d suggest creating a Google Docs that we could all collaborate on, with the goal of having something ready in time for TPAC. Dani: I will create the document and share it with the group so we can start collaborating on these ideas.
Planet MathML features:
David Carlisle Design Science News FMath Getting Math
onto Web Pages Community Group MathJax Murray Sargent: Math in
Office SF.net - ASCIIMathML SF.net - DocBook to LaTeX
Publishing SF.net - MathCast Equation
Editor SF.net - MathStudio SF.net - Open Math Edit SF.net - PyMathML SF.net - SVGMath SF.net - UniWakka SF.net - jsMath SF.net - jscl-meditor SF.net - pMML2SVG Updates | Frédéric Wang W3C Blog W3C Math Home W3C News WebKit public-digipub-ig@w3.org
Mail Archives public-html-a11y@w3.org
Mail Archives public-html@w3.org Mail
Archives public-mathonwebpages@w3.org
Mail Archives public-webapps@w3.org Mail
Archives www-math@w3.org Mail
Archives www-style@w3.org Mail
ArchivesIf you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.
