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.
But it is _very_ much "you got chocolate in my peanut butter" code. Good thing I like chocolate AND peanut butter. :) Jean Kaplansky jeankap@earthlink.net On Fri, Sep 23, 2016 at 5:54 PM, Liam R. E. Quin <liam@w3.org> wrote: > On Fri, 2016-09-23 at 11:03 -0400, Robin Berjon wrote: > [...] > > > > function listPeople (people = [], listType) { > > return ( > > <ul className={listType}> > > { > > people.map(p => <li>{p.name}</li>) > > } > > </ul> > > ); > > } > > This isn't far removed from JSONiq (or even XQuery). > > > >
On 22/09/2016 14:51 , Jos de Jong wrote: > @Robin can you elaborate a bit on your idea? Do you mean that it would > be trivial to translate a math formula into plain JavaScript which then > can be evaluated, or to SVG for rendering? Or both?... Do you have > concrete use cases in mind? The way JSX works is that you can use markup in your code, like this: let foo = <button>ohai!</button>; That's pretty simple to type out, but obviously to make it useful what you get out of it is not a string but a data structure. You can then proceed to manipulating that data structure, injecting it into a DOM, rendering it to string, etc. You can also embed code, variable, etc, inside of it, say: function listPeople (people = [], listType) { return ( <ul className={listType}> { people.map(p => <li>{p.name}</li>) } </ul> ); } To be clear, I am not suggesting that this should be a major constraint on the design. But I think it's worth keeping in mind the ability to have the syntax as something that could be used as a plugin in a JavaScript transpiler (this is not a very strong constraint, basically it mostly needs to be disambiguatable from the surrounding context). What gets returned could be manipulated (eg. you could feed it into a library to execute it) or it could be rendered. It's just a thought :) -- • Robin Berjon - http://berjon.com/ - @robinberjon • http://science.ai/ — intelligent science publishing •
Hi math-on-web CG, Below are the minutes to the F2F at TPAC. Given the late notice, the group was very small and we ended up focusing entirely on accessibility related problems. @Dani I noticed I didn't represent your example from the whiteboard. Can you reconstruct it? Best regards, Peter. # 2016-09-20 math-on-webpages CG, TPAC 2016 * Introductions / Present * Manuel (Igalia): browser implementations, CSSWG * Volker (ProgressiveAccess, U of Birmingham): accessibility interest, math specifically, also working on MathJax * Dani (WIRIS): known for web-based math editor, also handwriting recognition, putting formulas (any which way), also a11y (but more rendering). * Peter (krautzource): works on MathJax, works on publishing workflow chainend * Peter: summarized the activity of the Group * still getting to know each other, working on who can contribute on which areas * not about anything like MathML but interests so far are: practical accessibility, procedural/computational, and incremental layout improvemenets ## topic: accessibility * Dani: starting point: we want to go beyond image+alttext * exploration, alternative renderings etc * if you have MathML you have a tree you can attach to; if you have HTML or SVG, you also have a tree. * Volker: our solution applies an "orthogonal" tree to the visual rendering tree * abstracting away the visual layout * Dani: can we assume a static version of the equation? * Volker: we do that to some degree (embed the data structure that enhances) * have done initial exploration for ARIA structure to expose such information * Dani: do you respect the visual output tree hierarchy? * Volker: try to but sometimes not possible * Dani: do you think it's possible? * Peter: not sure it can be. Human understanding is too complicated; cf. how you visually explore an image/SVG structure. but limitation of the platform is: tree. * Volker: demonstrated some examples from MathJax's accessibility extensions * the data structure is added to the MathML and is preserved in HTML and SVG rendering * while the semantic tree structure is ad-hoc, it seems this wheel has been invented several times (conversations with Murray Sargent, Neil Soiffer etc) * Dani: I like the idea of a tree that is both semantic and visual * can we find something simpler/less powerful but where semantic = visual? * [Peter made unhelpful comment until he realized he misunderstood] * Dani: example: 2+xy * <span role="math"> x+2y</span>? * but AT might read "ecks too whee", so slap on some aria-labels to fix that * maybe you can add "role=variable" etc.? * Peter: cf our DEIMS paper * Volker: should we have a structure that is independent of the actual DOM representation * e.g., commutative diagrams, chemistry etc have circular semantics that cannot be mapped to a tree structure * Dani: the descendants should be the default descendants * Peter: there probably is (should be) a connection to SVG a11y * e.g., an SVG for a clockface should need some circular component * Volker: have not followed SVG a11y TF well enough * asked Chaals, who said you can't do ProgressiveAccess's style chemistry exploration with current SVG a11y TF work * Dani: can we use hmtl trees and references * [Dani's example, needs to be reconstructed] * Peter: like aria-describedby? * Peter: what if the visual tree does not match the semantic tree. * e.g., \overbrace{a+...+a}{n-times} * need to indicate to start at "a" * Dani: pointers handle this * Volker: so like aria-labledby/describedby * Peter: what is in the elements in the second tree? * Dani if referenced, nothing, but more than that * Volker: why do labels and describeby not suffice? * Peter: I suspect ARIA people will not accept a secondary tree. * aria attributes are on the unique tree and, via accessible name calculation, modify the accessible trees (potentially changing / overwriting the original content) * Dani: how much can you modify this way? E.g., order of the tree * Peter: I think you can (vague memory from building menus, specifying children and, I think their order) * Volker: and obviously hacks (Google knowledge cards, taborder, flexbox direction) * Volker: have done test implementations to do both two trees and one. * with a second tree, you might open up using any other formar (chemml) * Peter: this comes very close to custom elements and shadowDOM * ACTIONS: try to schedule meeting with aria folks
Hi Kevin, > With CAS, since the goal is to compute, you have no choice but to type what you mean. Is the goal to come up with a universal CAS language? The goal of this group is to bring practitioners together. While the group itself cannot develop any kind of standard on its own, if enough people want to work on such a thing, the group can provide the breeding ground and help propose a standards effort. Of course, the group can also make practical collaborative agreements among practitioners, especially when things do not fall into the web standards world (cf. common-mark), Best wishes, Peter. On Fri, Sep 23, 2016 at 12:25 AM, Paul Topping <pault@dessci.com> wrote: > All good issues and ones that should be solved before worrying about the > language syntax. > > > > I believe that the math structure should be bound to an interpretation > that may be declared in the structure or held separately. Two mathematical > structures may both contain an alpha but one binds it to some concept, > variable, constant, or value and the other binds it some different one. > When it is desired to calculate with the notation structure, it must be > transformed into some other, computational structure based on the > interpretation to which it is bound. > > > > Of course, problems may occur when it is necessary to map the > computational structure back to a notational structure. These mappings are > not generally one-to-one. This can be a good thing as it is possible to > change a given expression from one notational scheme to another, or one > computational structure to another. But it is a bad thing because there are > multiple representations that have non-trivial mappings between them. > > > > Paul > > > > > > *From:* Kevin Cheung [mailto:KEVINCHEUNG@CUNET.CARLETON.CA] > *Sent:* Thursday, September 22, 2016 3:02 PM > *To:* Paul Topping <pault@dessci.com>; Jos de Jong <wjosdejong@gmail.com>; > Robin Berjon <robin@berjon.com> > > *Cc:* Peter Krautzberger <peter.krautzberger@mathjax.org>; > public-mathonw. <public-mathonwebpages@w3.org> > *Subject:* Re: plain text math notation > > > > It will be nice if there is a math notation language that forces math > writers to mean exactly what they write. (Contrasting to what > mathematicians sometimes do; they use the same LaTex symbols to mean > different things in different contexts.) With CAS, since the goal is to > compute, you have no choice but to type what you mean. Is the goal to come > up with a universal CAS language? If so, how would one go about dealing > with really abstract math? > ------------------------------ > > *From:* Paul Topping <pault@dessci.com> > *Sent:* Thursday, September 22, 2016 3:17:56 PM > *To:* Jos de Jong; Robin Berjon > *Cc:* Peter Krautzberger; public-mathonw. > *Subject:* RE: plain text math notation > > > > The goal of a single math language that describes standard math notation > AND works well for computation and manipulation is a worthwhile and, IMHO, > achievable goal. However, starting at the syntax is not going to work. > Sure, it is fine to express preferences for one language or another but the > place to start is the model that the language expresses. By model, I mean > abstract data structure and its dynamic semantics. > > > > MathML suffered from the too-many-cooks problem as well as not having a > clear set of goals, IMHO. It also suffered from its association with XML > but that’s a whole other story. > > > > I believe starting with the model is the only road to success but it is > perhaps hard to convince people of that. Another advantage that might be > more compelling is that, with well-designed model in hand, it should be > possible to develop multiple syntaxes for expressing it, each useful in a > different scenario: an XML syntax for the XML document world and, perhaps, > for embedding in HTML, a JSON syntax for programmatic generation, > manipulation, and consumption, a “plain-text math notation” for authors to > type directly, etc. > > > > BTW, I am not sure “plain text math notation” is well-defined. In a sense, > all computer languages are plain text and, at the same time, all have a > syntax. I’m guessing what is meant by this is a notation that humans feel > comfortable typing. Computers like regular syntaxes and are not bothered by > extra characters such as angle brackets. Humans like something that doesn’t > require too many keystrokes, hard to reach keys on the keyboard, doesn’t > get scrambled in email, and is easy for humans to read. If this is what is > meant, perhaps “human math language” might work. Just a thought. > > > > Paul Topping > > > > Design Science, Inc. > > "How Science Communicates" > > Makers of MathType, MathFlow, MathPlayer, Equation Editor > > http://www.dessci.com > > > > *From:* Jos de Jong [mailto:wjosdejong@gmail.com <wjosdejong@gmail.com>] > *Sent:* Thursday, September 22, 2016 11:52 AM > *To:* Robin Berjon <robin@berjon.com> > *Cc:* Peter Krautzberger <peter.krautzberger@mathjax.org>; > public-mathonw. <public-mathonwebpages@w3.org> > *Subject:* Re: plain text math notation > > > > @Robin can you elaborate a bit on your idea? Do you mean that it would be > trivial to translate a math formula into plain JavaScript which then can be > evaluated, or to SVG for rendering? Or both?... Do you have concrete use > cases in mind? > > > > Jos > > > > On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com> wrote: > > On 22/09/2016 02:54 , Peter Krautzberger wrote: > > Jos has written up some notes on plain text math notations at [1]. > > This is IMHO a very promising area. I wonder if it may be interesting to > consider making it not too distant from the syntax of (modern) JS so > that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]). > > [0] http://babeljs.io/ > [1] https://facebook.github.io/react/docs/jsx-in-depth.html > > -- > • Robin Berjon - http://berjon.com/ - @robinberjon > • http://science.ai/ — intelligent science publishing > • > > >
All good issues and ones that should be solved before worrying about the language syntax. I believe that the math structure should be bound to an interpretation that may be declared in the structure or held separately. Two mathematical structures may both contain an alpha but one binds it to some concept, variable, constant, or value and the other binds it some different one. When it is desired to calculate with the notation structure, it must be transformed into some other, computational structure based on the interpretation to which it is bound. Of course, problems may occur when it is necessary to map the computational structure back to a notational structure. These mappings are not generally one-to-one. This can be a good thing as it is possible to change a given expression from one notational scheme to another, or one computational structure to another. But it is a bad thing because there are multiple representations that have non-trivial mappings between them. Paul From: Kevin Cheung [mailto:KEVINCHEUNG@CUNET.CARLETON.CA] Sent: Thursday, September 22, 2016 3:02 PM To: Paul Topping <pault@dessci.com>; Jos de Jong <wjosdejong@gmail.com>; Robin Berjon <robin@berjon.com> Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>; public-mathonw. <public-mathonwebpages@w3.org> Subject: Re: plain text math notation It will be nice if there is a math notation language that forces math writers to mean exactly what they write. (Contrasting to what mathematicians sometimes do; they use the same LaTex symbols to mean different things in different contexts.) With CAS, since the goal is to compute, you have no choice but to type what you mean. Is the goal to come up with a universal CAS language? If so, how would one go about dealing with really abstract math? ________________________________ From: Paul Topping <pault@dessci.com<mailto:pault@dessci.com>> Sent: Thursday, September 22, 2016 3:17:56 PM To: Jos de Jong; Robin Berjon Cc: Peter Krautzberger; public-mathonw. Subject: RE: plain text math notation The goal of a single math language that describes standard math notation AND works well for computation and manipulation is a worthwhile and, IMHO, achievable goal. However, starting at the syntax is not going to work. Sure, it is fine to express preferences for one language or another but the place to start is the model that the language expresses. By model, I mean abstract data structure and its dynamic semantics. MathML suffered from the too-many-cooks problem as well as not having a clear set of goals, IMHO. It also suffered from its association with XML but that's a whole other story. I believe starting with the model is the only road to success but it is perhaps hard to convince people of that. Another advantage that might be more compelling is that, with well-designed model in hand, it should be possible to develop multiple syntaxes for expressing it, each useful in a different scenario: an XML syntax for the XML document world and, perhaps, for embedding in HTML, a JSON syntax for programmatic generation, manipulation, and consumption, a "plain-text math notation" for authors to type directly, etc. BTW, I am not sure "plain text math notation" is well-defined. In a sense, all computer languages are plain text and, at the same time, all have a syntax. I'm guessing what is meant by this is a notation that humans feel comfortable typing. Computers like regular syntaxes and are not bothered by extra characters such as angle brackets. Humans like something that doesn't require too many keystrokes, hard to reach keys on the keyboard, doesn't get scrambled in email, and is easy for humans to read. If this is what is meant, perhaps "human math language" might work. Just a thought. Paul Topping Design Science, Inc. "How Science Communicates" Makers of MathType, MathFlow, MathPlayer, Equation Editor http://www.dessci.com From: Jos de Jong [mailto:wjosdejong@gmail.com] Sent: Thursday, September 22, 2016 11:52 AM To: Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> Cc: Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>>; public-mathonw. <public-mathonwebpages@w3.org<mailto:public-mathonwebpages@w3.org>> Subject: Re: plain text math notation @Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind? Jos On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> wrote: On 22/09/2016 02:54 , Peter Krautzberger wrote: > Jos has written up some notes on plain text math notations at [1]. This is IMHO a very promising area. I wonder if it may be interesting to consider making it not too distant from the syntax of (modern) JS so that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]). [0] http://babeljs.io/ [1] https://facebook.github.io/react/docs/jsx-in-depth.html -- * Robin Berjon - http://berjon.com/ - @robinberjon * http://science.ai/ - intelligent science publishing *
It will be nice if there is a math notation language that forces math writers to mean exactly what they write. (Contrasting to what mathematicians sometimes do; they use the same LaTex symbols to mean different things in different contexts.) With CAS, since the goal is to compute, you have no choice but to type what you mean. Is the goal to come up with a universal CAS language? If so, how would one go about dealing with really abstract math? ________________________________ From: Paul Topping <pault@dessci.com> Sent: Thursday, September 22, 2016 3:17:56 PM To: Jos de Jong; Robin Berjon Cc: Peter Krautzberger; public-mathonw. Subject: RE: plain text math notation The goal of a single math language that describes standard math notation AND works well for computation and manipulation is a worthwhile and, IMHO, achievable goal. However, starting at the syntax is not going to work. Sure, it is fine to express preferences for one language or another but the place to start is the model that the language expresses. By model, I mean abstract data structure and its dynamic semantics. MathML suffered from the too-many-cooks problem as well as not having a clear set of goals, IMHO. It also suffered from its association with XML but that's a whole other story. I believe starting with the model is the only road to success but it is perhaps hard to convince people of that. Another advantage that might be more compelling is that, with well-designed model in hand, it should be possible to develop multiple syntaxes for expressing it, each useful in a different scenario: an XML syntax for the XML document world and, perhaps, for embedding in HTML, a JSON syntax for programmatic generation, manipulation, and consumption, a "plain-text math notation" for authors to type directly, etc.. BTW, I am not sure "plain text math notation" is well-defined. In a sense, all computer languages are plain text and, at the same time, all have a syntax. I'm guessing what is meant by this is a notation that humans feel comfortable typing. Computers like regular syntaxes and are not bothered by extra characters such as angle brackets. Humans like something that doesn't require too many keystrokes, hard to reach keys on the keyboard, doesn't get scrambled in email, and is easy for humans to read. If this is what is meant, perhaps "human math language" might work. Just a thought. Paul Topping Design Science, Inc. "How Science Communicates" Makers of MathType, MathFlow, MathPlayer, Equation Editor http://www.dessci.com From: Jos de Jong [mailto:wjosdejong@gmail.com] Sent: Thursday, September 22, 2016 11:52 AM To: Robin Berjon <robin@berjon.com> Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>; public-mathonw. <public-mathonwebpages@w3.org> Subject: Re: plain text math notation @Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind? Jos On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> wrote: On 22/09/2016 02:54 , Peter Krautzberger wrote: > Jos has written up some notes on plain text math notations at [1]. This is IMHO a very promising area. I wonder if it may be interesting to consider making it not too distant from the syntax of (modern) JS so that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]). [0] http://babeljs.io/ [1] https://facebook.github.io/react/docs/jsx-in-depth.html -- * Robin Berjon - http://berjon.com/ - @robinberjon * http://science.ai/ - intelligent science publishing *
The goal of a single math language that describes standard math notation AND works well for computation and manipulation is a worthwhile and, IMHO, achievable goal. However, starting at the syntax is not going to work. Sure, it is fine to express preferences for one language or another but the place to start is the model that the language expresses. By model, I mean abstract data structure and its dynamic semantics. MathML suffered from the too-many-cooks problem as well as not having a clear set of goals, IMHO. It also suffered from its association with XML but that’s a whole other story. I believe starting with the model is the only road to success but it is perhaps hard to convince people of that. Another advantage that might be more compelling is that, with well-designed model in hand, it should be possible to develop multiple syntaxes for expressing it, each useful in a different scenario: an XML syntax for the XML document world and, perhaps, for embedding in HTML, a JSON syntax for programmatic generation, manipulation, and consumption, a “plain-text math notation” for authors to type directly, etc. BTW, I am not sure “plain text math notation” is well-defined. In a sense, all computer languages are plain text and, at the same time, all have a syntax. I’m guessing what is meant by this is a notation that humans feel comfortable typing. Computers like regular syntaxes and are not bothered by extra characters such as angle brackets. Humans like something that doesn’t require too many keystrokes, hard to reach keys on the keyboard, doesn’t get scrambled in email, and is easy for humans to read. If this is what is meant, perhaps “human math language” might work. Just a thought. Paul Topping Design Science, Inc. "How Science Communicates" Makers of MathType, MathFlow, MathPlayer, Equation Editor http://www.dessci.com From: Jos de Jong [mailto:wjosdejong@gmail.com] Sent: Thursday, September 22, 2016 11:52 AM To: Robin Berjon <robin@berjon.com> Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>; public-mathonw. <public-mathonwebpages@w3.org> Subject: Re: plain text math notation @Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind? Jos On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> wrote: On 22/09/2016 02:54 , Peter Krautzberger wrote: > Jos has written up some notes on plain text math notations at [1]. This is IMHO a very promising area. I wonder if it may be interesting to consider making it not too distant from the syntax of (modern) JS so that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]). [0] http://babeljs.io/ [1] https://facebook.github.io/react/docs/jsx-in-depth.html -- • Robin Berjon - http://berjon.com/ - @robinberjon • http://science.ai/ — intelligent science publishing •
@Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind? Jos On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com> wrote: > On 22/09/2016 02:54 , Peter Krautzberger wrote: > > Jos has written up some notes on plain text math notations at [1]. > > This is IMHO a very promising area. I wonder if it may be interesting to > consider making it not too distant from the syntax of (modern) JS so > that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]). > > [0] http://babeljs.io/ > [1] https://facebook.github.io/react/docs/jsx-in-depth.html > > -- > • Robin Berjon - http://berjon.com/ - @robinberjon > • http://science.ai/ — intelligent science publishing > • > >
On 22/09/2016 02:54 , Peter Krautzberger wrote: > Jos has written up some notes on plain text math notations at [1]. This is IMHO a very promising area. I wonder if it may be interesting to consider making it not too distant from the syntax of (modern) JS so that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]). [0] http://babeljs.io/ [1] https://facebook.github.io/react/docs/jsx-in-depth.html -- • Robin Berjon - http://berjon.com/ - @robinberjon • http://science.ai/ — intelligent science publishing •
Hi math-on-web CG, Jos has written up some notes on plain text math notations at [1]. Please check it out ahead of next week's meeting. Best regards, Peter. [1] https://w3c.github.io/mathonwebpages/research/text_based_standards.html
PS We continue to have connection issues. If you want to join and encounter problems, please write a short message. On Tue, Sep 20, 2016 at 3:27 PM, Peter Krautzberger < peter.krautzberger@mathjax.org> wrote: > Hi folks, > > In case anyone has time to join us at TPAC remotely, here is a hangout > you are invited to: > > https://hangouts.google.com/call/5h7rwp7cnbe2fideopwzjfpvmif > > (Sorry for the delay due to network problems). > > There will also be minutes. > > Best regards, > Peter. >
Hi folks, In case anyone has time to join us at TPAC remotely, here is a hangout you are invited to: https://hangouts.google.com/call/5h7rwp7cnbe2fideopwzjfpvmif (Sorry for the delay due to network problems). There will also be minutes. Best regards, Peter.
Safari Technology Preview Release 13 is now available for download for both macOS Sierra betas and OS X El Capitan 10.11.6. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204876–205519.
BufferSource bodies (r205115)contentType header (r205076)text() decode data as UTF–8
(r205188)opaqueredirect responses to have their URL
set to the original URL (r205081)bodyUsed when request
construction fails (r205253)bodyUsed to check for its
body-disturbed state (r205251)structureClone
when teeing a Response stream (r205117)ReadableStream
with the specifications (r205289)data:// URL behavior of XHR to match
specifications (r205113)appendChild() (r205085):defined to re-align with
specification changes (r205416)whenDefined() method on the
CustomElementRegistry (r205315)CustomElementRegistry check for reentrancy
(r205261)for…in head in non-strict
mode (r204895)newPromiseCapabilities to check that the
given argument is a constructor (r205027)toString() to return the correct tag when
called on proxy objects (r205023)<link preload>
(r205269)x, y and
ScrollToOptions arguments for
Element.scroll(), Element.scrollTo(), and
Element.scrollBy() (r205505)location.toString to make it enumerable
(r204953)location.toString in Web Workers to make
it enumerable (r204954)Object.preventExtensions(window) to throw
a TypeError exception (r205404)coords and srcset attribute
parsing with the HTML specification (r205030, r205515)CanvasRenderingContext2D.prototype.resetTransform
(r204878)Object.getOwnPropertyNames()
with the HTML specification (r205409)responseType="blob" (r205268)CSS.escape according to the CSSOM
specification (r204952):enabled and :disabled
selectors to only match elements that can be disabled (r205050)<table> with overflow
content inside <div align="right"> (r205489)crossOrigin attribute (r205134)SecurityError when trying to access
cross-origin Location properties (r205026)Object.defineProperty() and
Object.preventExtensions() to throw an error for a
cross-origin Window or Location object
(r205358,
r205359)Object.setPrototypeOf() to throw an error
and return null when used on a cross-origin
Window or Location object (r205205, r205258)In writing the post Nemeth Braille—the first math linear format, I became increasingly aware that the Unicode Nearly Plain Text Encoding of Mathematics needed a better name than “linear format”. In addition to the Nemeth braille linear format, there are other math linear formats some of which are described in the post Linear Format Notations for Mathematics. One of these, AsciiMath, inspired the name UnicodeMath, which is much more specific than “linear format”. UnicodeMath uses the Unicode math symbol set (see Math property in DerivedCoreProperties.txt), resembles real mathematical notation the most closely of all math linear formats, and handles almost every mathematical notation. Since Unicode characters are global by nature, UnicodeMath doesn’t need localization. [La]TeX and AsciiMath define characters using ASCII control words that are Western-centric, and perhaps need to be localized in nonLatin-based locales.
In addition to being the most readable linear format, UnicodeMath is the most concise. It represents the simple fraction, one half, by the 3 characters “1/2”, whereas typical MathML takes 62 characters (consisting of the <mml:mfrac> entity). This conciseness makes UnicodeMath an attractive format for storing mathematical expressions and equations, as well as for ease of keyboard entry. Another comparison is in the math structures for the Equation Tools tab in the Office ribbon. In Word, the structures are defined in OMML (Office MathML) and built up by Word, while for the other apps, the structures are defined in UnicodeMath and built up by RichEdit. The latter are much faster and the equation data much smaller. A dramatic example is the stacked fraction template (empty numerator over empty denominator). In UnicodeMath, this is given by the single character ‘/’. In OMML, it’s 109 characters! LaTeX is considerably shorter at 9 characters “\frac{}{}”, but is still 9 times longer than UnicodeMath. AsciiMath represents fractions the same way as UnicodeMath, so simple cases are identical. If Greek letters or other characters that require names in AsciiMath are used, UnicodeMath is shorter and more readable.
Another advantage of UnicodeMath over MathML and OMML is that UnicodeMath can be stored anywhere Unicode text is stored. When adding math capabilities to a program, XML formats require redefining the program’s file format and potentially destabilizing backward compatibility, while UnicodeMath does not. If a program is aware of UnicodeMath math zones (see Section 3.20 of UnicodeMath), it can recover the built-up mathematics by passing those zones through the RichEdit UnicodeMath MathBuildUp function. In fact, you can roundtrip RichEdit documents containing math zones through the plain-text editor Notepad: the math zones are preserved!
As its name implies, AsciiMath uses only ASCII characters, although it converts to MathML with access to a much larger character set. AsciiMath is relatively simple to parse and can handle many mathematical constructs. AsciiMath shares some methodology with UnicodeMath, such as eliminating the outer parentheses in fractions like (a+b)/c when converting to built-up format. AsciiMath is designed to work with a MathML renderer, such as MathJax. In Microsoft Office apps, UnicodeMath builds up to the LineServices math internal format, which represented by OMML.
By default, the Office math autocorrect facility contains most [La]TeX math symbol control word definitions such as \beta for β. AsciiMath has a subset of such control words but omits the leading backslash. The user can modify such control words in the Office math autocorrect list or add them explicitly, but it’d probably be worth adding an option to make the leading backslash optional. That would speed up keyboard entry of UnicodeMath via math autocorrect. The RichEdit dll includes the UnicodeMath build up/down facility as well as converters for other math formats, such as MathML and OMML. It would be straightforward to add an option to the RichEdit UnicodeMath facility to accept AsciiMath input in general. Such an option would be handy for people that know AsciiMath.
One C++ oriented autocorrect choice in AsciiMath is that typing != enters ≠. Although I program in C++ almost every day, I think /= is a better choice for entering ≠. For one thing, using != for ≠ complicates typing in an equation like n! = n(n-1)(n-2)…1, which is the main reason we didn’t implement it. But in Office apps this equation can also be entered by typing ! = instead of !=, since math spacing rules insert space between ! and = and the RichEdit UnicodeMath facility automatically deletes a user’s space if typed there (see User Spaces in Math Zones). So, that’s an easy work around for entering an n! equation if one wants to support != for ≠. The RichEdit UnicodeMath facility supports most Unicode negated operators by sequences of / followed by the corresponding unnegated operator as described in the post Negated Operators.
<gripe> Meanwhile the C++ language should recognize ≠, ≤, ≥, and ≡ as aliases for !=, <=, >=, and ==. It seems primitive that C++ doesn’t do so in this Unicode age of computing. At least the C++ editing/debugging environments should have an option to display !=, <=, >=, and == as ≠, ≤, ≥, and ≡. </gripe>
Here’s a table with various formats for the integral
| Format | Representation |
| UnicodeMath | 1/2𝜋 ∫_0^2𝜋▒ⅆ𝜃/(𝑎+𝑏 sin𝜃 )=1/√(𝑎^2−𝑏^2 ) |
| AsciiMath | 1/(2pi) int_0^(2pi) dx/(a+bsin theta)=1/sqrt(a^2-b^2) |
| LaTeX | \frac{1}{2\pi}\int_{0}^{2\pi}\frac{d\theta}{a+b\sin {\theta}}=\frac{1}{\sqrt{a^2-b^2}} |
Note that UnicodeMath binds the integrand to the integral, whereas AsciiMath and LaTeX don’t define the limits of the integrand. The Presentation MathML and OMML for this integral are too long to put into this post.
There is a unicode-math conversion package for Unicode enabled XeTeX and LuaLaTeX. The name UnicodeMath seems sufficiently different from unicode-math that there shouldn’t be any confusion between the two. The unicode-math package supports a variety of math fonts including Cambria Math, Minion Math, Latin Modern Math, TeX Gyre Pagella Math, Asana-Math, Neo-Euler, STIX, and XTIS Math. Did you know there are so many math fonts?
Enjoy the new name UnicodeMath. I am and it already appears near the end of my previous blog post, Nemeth Braille Alphanumerics and Unicode Math Alphanumerics. If you’re interested in the origin of UnicodeMath, read the post How I got into technical WP. The forerunner of UnicodeMath originated back in the early microcomputer days and had only 512 characters consisting of upright ASCII, italics, script, Greek and various mathematical symbols used in theoretical physics. Unicode 1.0 didn’t arrive until 10 years later.
| HTML Goodies - Found Sep. 1,
2016 ... and announced to start developing tools using HTML5. Options to support scalable vector graphics (SVL) and MathML were added to support... |
Today we are entering the public beta phase of MathJax v2.7. MathJax v2.7 is primarily a bug-fix release with over 60 important bug fixes. In addition, this release adds several new features as an opt-in. The following are some of the highlights:
[Contrib] path variable to the URL of
the third party extension repository on the MathJax CDN. This
simplifies loading contributed extensions.For details on all bug fixes, please see below.
The beta is available via our CDN at beta.mathjax.org/mathjax/latest/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.
Please note the following.
If you are using a
combined configuration, please note that we added the the
accessibility menu extension to all combined configuration files.
This extension will always load from cdn.mathjax.org/mathjax/contrib. If you
are hosting your own copy of MathJax and if your users will not be
able to access cdn.mathjax.org, then you should disable
the [Contrib] path by adding
noContrib to the query
string, e.g., MathJax.js?config=...&noContrib to
avoid unnecessary failed requests.
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 release. We do not recommend that you use the 2.7-beta version for production environments, but do encourage you to test your content with it.
If you are linking to http://cdn.mathjax.org/mathjax/latest/MathJax.js, note that at the point of the official release of v2.7, the address will begin to serve MathJax v2.7. You can also continue to use v2.6 by linking to http://cdn.mathjax.org/mathjax/2.6-latest/MathJax.js instead — and you can change to that version at any point (it is available now).
The official release of v2.7 should occur within the next few weeks, but we want you to be able to start to test out the v2.7 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.
MathJax v2.7 is primarily a bug-fix release with over 60 important bug fixes, in particular to the CommonHTML output. In addition, this release adds several new features as an opt-in. The following are some of the highlights.
For a detailed listing please check the release milestone.
role=math by default.xlink references in SVG <use> elements.getNode() to fix processing errors when
line-breaking.createRule().0 remains
0 when rounding to pixels
(plus a bit).\overset or \underset is empty.src
attribute from <mglyph> output.<mglyph> scale image size by
hand.<mover> in <mtd> elements.href
correctly when line breaking.currentColor for <menclose> with no mathcolor.font-family specified.TeX.Environment() to use the
correct end environment.resetEquationNumbers is
always defined.TeXAtom
elements\middle with OPEN and CLOSE TeXAtoms to match TeX spacing\left and \right.array
environments.\require{mhchem} to override
one already loaded.<wbr> in TeX
code.\+SPACE in macro
definitions.trimSpaces() doesn’t
remove tailing space in \+SPACE.\ref properly when
there is a <base>
tag.newsymbol command for adding a new
symbol objectrowlines="" and rowlines=" " like rowlines="none".<mn> produce
U+2212 rather than
U+002D.U+222B
(integral) stretchy.| to variant
form (with descender) and map variant to original form.U+007C and U+2016 for delimiters rather than
U+2223 and U+2225.U+2206 to U+0394 and remove incorrect U+2206 from SVG font files.U+20D7.getJaxForMath() work even
during chunking.[Contrib].padding, margin.display:none.rev= to V= in cache breaking code.Dear math-on-webpages CG, The last-minute nature of this thread makes it difficult to plan beyond our own slot. >From the call, I remember that a few people besides myself are planning or considering to attend TPAC so there's no reason to let our slot go to waste :-) If you are thinking about attending TPAC and would like to attend the CG meeting (Tuesday, 13:30--15:30), could you please send an email to Dani or myself? Best regards, Peter. On Mon, Aug 29, 2016 at 5:55 PM, Peter Krautzberger < peter.krautzberger@mathjax.org> wrote: > Dea DPUB IG and Math-on-Webpages CG, > > The math-on-webpages CG got a meeting slot for TPAC (Tue, 13:30–15:30). > Unfortunately, we didn't know about this until rather recently. > > So in the last CG F2F, people present decided to it would be best to > concentrate on a meeting with the DPUB IG. > > The DPUB IG schedule [1] already lists something for the time but I'm > wondering if we could fit something in anyway? > > Best wishes, > Peter. > > [1] https://www.w3.org/dpub/IG/wiki/Sep_2016_F2F_Logistics_ > and_Details#Tuesday.2C_20_September >
Safari Technology Preview Release 12 is now available for download for both macOS Sierra betas and OS X El Capitan. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204289–204876.
This release of Safari Technology Preview will be the last that will install and run on OS X El Capitan 10.11.4 and 10.11.5. To continue testing or living on the latest enhancements to WebKit, please upgrade to OS X El Capitan 10.11.6 or the macOS Sierra betas.
TypedArray.prototype.slice to
ensure the source and destination have not been detached (r204868)const variables used
in a for-in or for-of loop (r204586)Array.prototype.map
when used with Arrays (r204488)Object.entries and
Object.values from the ES2017 specifications (r204419, r204358)line, column and
sourceURL properties of Error to be
configurable and writable (r204663)Range.surroundContents() with the latest
DOM specification (r204390)HTMLAreaElement.toString()
(r204871)prefix properties of Attr
and Element to be read-only (r204648)<command> to an
HTMLUnknownElement and <basefont>
to an HTMLElement (r204647)prefix, namespaceURI, and
localName attributes from Node to
Attr and Element (r204624)Animatable, AnimationEffect,
KeyframeEffect and Animation interfaces
for Web Animations (r204594)isDefaultNamespace(),
lookupPrefix(), and lookupNamespaceURI()
with the specification (r204536)querySelector() and
querySelectorAll() to always throw a
SyntaxError when failing to parse a selector string
(r204522)embeds, plugins, and
scripts attributes from HTMLDocument to
Document (r204450)compatMode and designMode
properties from HTMLDocument to Document
(r204451,
r204449)getElementsByTagName() to take a qualified
name parameter (r204441)crypto.getRandomValues to Web Workers
(r204481)spring()
timing-function (r204775)MathMLRowElement class for
mrow-like elements (r204779)MathMLAnnotationElement class for the
<annotation> and
<annotation-xml> elements (r204692):host pseudo-class to style elements
in the shadow tree (r204724)ctx.drawImage to clip the source rectangle
if it is outside the source image (r204517)URLParser parsing IPv4 addresses and URLs
without credentials (r204701, r204544)Upgrade-Insecure-Request state
handling between navigations (r204521)Dea DPUB IG and Math-on-Webpages CG, The math-on-webpages CG got a meeting slot for TPAC (Tue, 13:30–15:30). Unfortunately, we didn't know about this until rather recently. So in the last CG F2F, people present decided to it would be best to concentrate on a meeting with the DPUB IG. The DPUB IG schedule [1] already lists something for the time but I'm wondering if we could fit something in anyway? Best wishes, Peter. [1] https://www.w3.org/dpub/IG/wiki/Sep_2016_F2F_Logistics_and_Details#Tuesday.2C_20_September
Planet MathML features:
Ask.com News Search for
"mathml" 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 Web Platform Blog 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.
