Planet MathML

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.

Latest articles

Sketch Input and Grading in Massive Open Online Courses

Source: www-math@w3.org Mail Archives • Adam Sobieski (adamsobieski@hotmail.com) • February 12, 2016 • Permalink

W3C Math Working Group,





http://odl.mit.edu/news-and-events/events/tools-digital-learning



The ability to sketch graphs or diagrams is an important skill in many STEM fields, but these skills are typically taught using paper-based assessments that are hard to scale and do not offer immediate feedback. Jennifer French and Martin Segado will present a web-based sketch input and automated grading tool for offering such assessments within digital course content and discuss some preliminary results from its use in an introductory MITx calculus MOOC.




Kind regards,


Adam Sobieski


http://www.phoster.com/support/

Re: Arabic operators U+1EEF0 and U+1EEF1

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • February 09, 2016 • Permalink

Thanks. I'm not familiar with these Arabic notations so I can not really
help with the operator properties to apply.

Le 08/02/2016 18:33, David Carlisle a écrit :
>
> OK I've done
>
> https://github.com/w3c/xml-entities/commit/891fe64c7591a75c8f2ad42f9ff0fb93b5b8ef74
>
>
> David

-- 
Frédéric Wang



mathvariant attribute and isolated Arabic mathematical characters

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • February 09, 2016 • Permalink

Dear all,

Unicode contains some "ARABIC MATHEMATICAL" characters in the range
1EE00-1EE1F corresponding to the "isolated" forms in plane 0. The MathML
specification does not explicitly mention these characters and there is
no "isolated" mathvariant value. So it seems that they should just be
ignored for the mathvariant implementation (and this is indeed what
Gecko does). However:

1) In https://www.w3.org/TR/arabic-math/#N10951 it seems that the
initial intention was to make mathvariant="normal" force the isolated
form for Arabic characters.

2) The file unicode.xml from http://www.w3.org/TR/xml-entity-names/
contains some mapping <surrogate mathvariant="isolated">

Could you please clarify if there is some relation between the
mathvariant attribute and these isolated Arabic mathematical characters?

Thanks,

-- 
Frédéric Wang



Re: Clipboard API: remove dangerous formats from mandatory data types

Source: public-webapps@w3.org Mail Archives • Hallvord Reiar Michaelsen Steen (hsteen@mozilla.com) • February 09, 2016 • Permalink

> But copying a fragment of HTML in the wild without reformulating it will
> lead to privacy breach: it would copy references to external content. I
> believe all browsers have an "inlining" method to solve that problem

I'm trying to handle this question on another E-mail thread so please
follow up there :)

>> JSON: nope, there's no such thing as "external inclusion" in JSON, and
>> there never will be.

> You can certainly exchange a Bookmark-list over json (e.g.
> http://kb.mozillazine.org/Bookmarks)... that would be a simple example of
> some JSON whose URLs you should not "GET" without some concerns (e.g.
> localhost servers).

But JSON as such has no concept of "URL" or a "URL" data type. To a
JSON implementation it's just a string, and I don't see any step of a
clipboard roundtrip doing anything magic to figure out what strings
are URLs or trying to process them :).

> Similarly XInclude-enabled XMLs or even other remote-including-XMLs (e.g.
> through DTD) should ask the users, deny, or inline.

Do you think we should not mandate support for writing XML to the
clipboard from JS, then?
Is this also a problem for MathML?

> For the unsafe formats, the warning could say that the UA-implementors
> should only support the flavour if they have a method to make this content
> safe so that local applications (which do not expect untrusted content)
> receive content they can trust when pasting. Methods to make the content
> safe include the following: transcoding a picture, inlining all external
> entities for html, xml, mathml, or rtf).

To make sure we understand each other: what you're saying here is that
if I do this in a JavaScript:

document.oncopy = function(e){
  e.clipboardData.setData('text/html', '<img
src="https://mozilla.org/images/logo.gif">');
  e.preventDefault();
}

the data that actually ends up being written to the clipboard will be

<img src="data:image/gif;base64,[Mozilla's logo data: encoded]">

I think that would be rather surprising behaviour, and would create
some attack scenarios if the attacker can predict the URLs of images
with private data inside them. On pasting they would then be data:
URLs without a concept of origin, the UA would no longer be able to
rely on mechanisms like CORS and/or session data to determine if it's
OK to show the image. If that image would be painted on a CANVAS after
pasting, the image data would now be accessible to JS without
tainting..

Is this really what you propose? :)

> I've just done a small test in Safari on Mac. It allows writing a
> random string to the clipboard and labelling it image/tiff (and
> helpfully adds a "public.tiff" clipboard entry with the same random
> data). There's no transcoding or similar.
>
> Please share the test, this is exactly the kind of things we need around to
> see how crooked one could touch upon.

I was playing around with the code the reporter of
https://bugzilla.mozilla.org/show_bug.cgi?id=860857 submitted - here's
an online version modified to also put image/tiff on the clipboard:
https://jsfiddle.net/gk3vm5L8/1/ (apparently this test was derived
from some Google Docs code).

>> So, the question (for recap) is: would it be OK to let JS write binary
>> data labelled as an image type if the browser was required to
>> transcode it to TIFF or DIB and only update the clipboard if such
>> transcoding succeeded?

> My answer is definitely yes as we should*assume that image transcoders
> should remove the dangers of flawed parsers as they could happen otherwise
> in other situations (e.g. in doing screenshots).

Implementors? Can we rescue clipboardData.items.add(binaryImageData,
'image/jpeg') by mandating transcoding? :)
Is the current Safari Mac behaviour a problem or is it safe enough to spec?
-Hallvord

Re: Clipboard API: remove dangerous formats from mandatory data types

Source: public-webapps@w3.org Mail Archives • Paul Libbrecht (paul@hoplahup.net) • February 08, 2016 • Permalink

(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)

cool!
>> But copying a fragment of HTML in the wild without reformulating it will
>> lead to privacy breach: it would copy references to external content. I
>> believe all browsers have an "inlining" method to solve that problem when
>> pasting from a web-page (I believe "save as web page complete" also does a
>> part of that).
>
> I think the proposed solution may be worse for privacy than the
> original problem: images you would "inline" might have sensitive data
> in them.. AFAIK it's not common to do any image inlining or URL
> mangling when pasting HTML copied from another site, is it?

It's the way it currently works on FF apparently (tested MacOSX 10.11
and Windows 7) and on Safari: all images are converted to data-urls.
I don't really see why it would be worse.
Would sensitive data be something such as the metadata? That could
certainly be stripped by transcoding.
>>> Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully
>>> most parsers would be safe.
>> I think the danger lies beyond parsers.
>> In XML, you would have XInclude which can be used in many tools to include
>> content from outside.
>> I believe I have seen JSON syntaxes that had external references as part of
>> their specs but I can't remember which now.
>> As long these formats are copied as is and parsed blindly the risk of
>> external inclusion remains.
>
> XML: good point.
> JSON: nope, there's no such thing as "external inclusion" in JSON, and
> there never will be.
You can certainly exchange a Bookmark-list over json (e.g.
http://kb.mozillazine.org/Bookmarks)... that would be a simple example
of some JSON whose URLs you should not "GET" without some concerns (e.g.
localhost servers).
Similarly XInclude-enabled XMLs or even other remote-including-XMLs
(e.g. through DTD) should ask the users, deny, or inline.
>>> For the unsafe formats, the warning could say that the UA-implementors
>>> should only support the flavour if they have a method to make this content
>>> safe so that local applications (which do not expect untrusted content)
>>> receive content they can trust when pasting. Methods to make the content
>>> safe include the following: transcoding a picture, inlining all external
>>> entities for html, xml, mathml, or rtf).
>> On Windows I believe images are transcoded to and from DIB - device
>> independent bitmap format anyway. Is there any equivalent graphics
>> interchange format on other platforms? Does mandating such transcoding help
>> guarantee against payloads that might trigger vulnerabilities in target
>> software?
>>
>> All platforms I know of have some sort of transcoding of pictures (in Macs
>> it is PDF as the central format).
>> I think this is a very safe mechanism to rely on.
>
> I've just done a small test in Safari on Mac. It allows writing a
> random string to the clipboard and labelling it image/tiff (and
> helpfully adds a "public.tiff" clipboard entry with the same random
> data). There's no transcoding or similar.
Please share the test, this is exactly the kind of things we need around
to see how crooked one could touch upon.
E.g. MS Office documents nowadays display a "kind" of mistrust so the
user can bless if macros should be run. This kind of mistrust is
probably the future.
However, going as far as refusing any picture you
right-click-copy-picture from a web-browser because it is unsafe is far
from being what the users expect nowadays.
>> I expect it adds a significant hurdle against exploits, but I'd like input
>> from Daniel Cheng and perhaps from people who have worked on image
>> decoders..
>
> I'd still like Daniel Cheng to chime in again if he has time :)
> So, the question (for recap) is: would it be OK to let JS write binary
> data labelled as an image type if the browser was required to
> transcode it to TIFF or DIB and only update the clipboard if such
> transcoding succeeded?
My answer is definitely yes as we should*assume that image transcoders
should remove the dangers of flawed parsers as they could happen
otherwise in other situations (e.g. in doing screenshots).
> (Obviously we also need the reverse mechanism - on paste, if there's
> TIFF or DIB on the clipboard offer JPEG and/or PNG to JS).
yes

Paul

Re: Arabic operators U+1EEF0 and U+1EEF1

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • February 08, 2016 • Permalink

On 08/02/2016 15:37, Frédéric WANG wrote:
> Dear all,
>
> The MathML recommendation refers to
> http://www.unicode.org/charts/PDF/U1EE00.pdf which contains two Arabic
> operators (U+1EEF0 and U+1EEF1). Note that these operators are stretchy.
>
> They are not mentioned on
> https://www.w3.org/Math/draft-spec/appendixc.html. Actually, the
> unicode.xml file from https://www.w3.org/TR/xml-entity-names/ does not
> have any operator-dictionary or unicode-math entry either.
>
> See also:
> https://github.com/wspr/unicode-math/pull/320
> https://github.com/khaledhosny/xits-math/issues/45
> https://bugzilla.mozilla.org/show_bug.cgi?id=1246657
> https://bugs.webkit.org/show_bug.cgi?id=153984
>

OK I've done

https://github.com/w3c/xml-entities/commit/891fe64c7591a75c8f2ad42f9ff0fb93b5b8ef74

David

________________________________


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

Re: Arabic operators U+1EEF0 and U+1EEF1

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • February 08, 2016 • Permalink

On 08/02/2016 15:37, Frédéric WANG wrote:
> Dear all,
>
> The MathML recommendation refers to
> http://www.unicode.org/charts/PDF/U1EE00.pdf which contains two Arabic
> operators (U+1EEF0 and U+1EEF1). Note that these operators are stretchy.
>
> They are not mentioned on
> https://www.w3.org/Math/draft-spec/appendixc.html. Actually, the
> unicode.xml file from https://www.w3.org/TR/xml-entity-names/ does not
> have any operator-dictionary or unicode-math entry either.
>
> See also:
> https://github.com/wspr/unicode-math/pull/320
> https://github.com/khaledhosny/xits-math/issues/45
> https://bugzilla.mozilla.org/show_bug.cgi?id=1246657
> https://bugs.webkit.org/show_bug.cgi?id=153984
>

Thanks for the reminder, I saw Khaled's pull request to unicode-math
last year and remember thinking at the time that unicode.xml would need
updating to match.

I can add the latex name information to match unicode-math and a
operator-dictionary stretchy=true
entry but if any of the other operator-dictionary fields should have
values I'd need some help with what the values should be!

David


________________________________


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

Arabic operators U+1EEF0 and U+1EEF1

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • February 08, 2016 • Permalink

Dear all,

The MathML recommendation refers to
http://www.unicode.org/charts/PDF/U1EE00.pdf which contains two Arabic
operators (U+1EEF0 and U+1EEF1). Note that these operators are stretchy.

They are not mentioned on
https://www.w3.org/Math/draft-spec/appendixc.html. Actually, the
unicode.xml file from https://www.w3.org/TR/xml-entity-names/ does not
have any operator-dictionary or unicode-math entry either.

See also:
https://github.com/wspr/unicode-math/pull/320
https://github.com/khaledhosny/xits-math/issues/45
https://bugzilla.mozilla.org/show_bug.cgi?id=1246657
https://bugs.webkit.org/show_bug.cgi?id=153984

-- 
Frédéric Wang



SimpleTeX4ht

Source: Ask.com News Search for "mathml" • February 04, 2016 • Permalink

ZDNet - Found Feb. 4, 2016
LaTeX files to HTML, XHTML, OpenDocument (.odt which is the native format of OpenOffice.org), MathML, DocBook or Text Encoding Initiative (TEI).
Tech Tip: Moving Files to a Mac From a PC - New York Times
FastFox Text Expander - ZDNet
Moving Files to a Mac From a PC - New York Times
Sequel Pro - ZDNet
Explore All

Huffington Post

Re: Clipboard API: remove dangerous formats from mandatory data types

Source: public-webapps@w3.org Mail Archives • Hallvord Reiar Michaelsen Steen (hsteen@mozilla.com) • February 04, 2016 • Permalink

(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)

On Sat, Aug 29, 2015 at 3:16 PM, Paul Libbrecht <paul@hoplahup.net> wrote:

> But copying a fragment of HTML in the wild without reformulating it will
> lead to privacy breach: it would copy references to external content. I
> believe all browsers have an "inlining" method to solve that problem when
> pasting from a web-page (I believe "save as web page complete" also does a
> part of that).

I think the proposed solution may be worse for privacy than the
original problem: images you would "inline" might have sensitive data
in them.. AFAIK it's not common to do any image inlining or URL
mangling when pasting HTML copied from another site, is it?

>> Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully
>> most parsers would be safe.
>
> I think the danger lies beyond parsers.
> In XML, you would have XInclude which can be used in many tools to include
> content from outside.
> I believe I have seen JSON syntaxes that had external references as part of
> their specs but I can't remember which now.
> As long these formats are copied as is and parsed blindly the risk of
> external inclusion remains.

XML: good point.
JSON: nope, there's no such thing as "external inclusion" in JSON, and
there never will be.

>> For the unsafe formats, the warning could say that the UA-implementors
>> should only support the flavour if they have a method to make this content
>> safe so that local applications (which do not expect untrusted content)
>> receive content they can trust when pasting. Methods to make the content
>> safe include the following: transcoding a picture, inlining all external
>> entities for html, xml, mathml, or rtf).
>
>
> On Windows I believe images are transcoded to and from DIB - device
> independent bitmap format anyway. Is there any equivalent graphics
> interchange format on other platforms? Does mandating such transcoding help
> guarantee against payloads that might trigger vulnerabilities in target
> software?
>
> All platforms I know of have some sort of transcoding of pictures (in Macs
> it is PDF as the central format).
> I think this is a very safe mechanism to rely on.

I've just done a small test in Safari on Mac. It allows writing a
random string to the clipboard and labelling it image/tiff (and
helpfully adds a "public.tiff" clipboard entry with the same random
data). There's no transcoding or similar.

> I expect it adds a significant hurdle against exploits, but I'd like input
> from Daniel Cheng and perhaps from people who have worked on image
> decoders..

I'd still like Daniel Cheng to chime in again if he has time :)
So, the question (for recap) is: would it be OK to let JS write binary
data labelled as an image type if the browser was required to
transcode it to TIFF or DIB and only update the clipboard if such
transcoding succeeded?

(Obviously we also need the reverse mechanism - on paste, if there's
TIFF or DIB on the clipboard offer JPEG and/or PNG to JS).
-Hallvord

HighWire continues as MathJax Supporter

Source: MathJax • February 03, 2016 • Permalink

The HighWire Open Platform provides innovative technology solutions to influential societies, university presses, and independent publishing organizations, assisting in the digital dissemination and readability of some of the most high-impact journals, books, and other scholarly materials on the net.

“Celebrating 20 years of service, HighWire Press, Inc. is excited to once again be a supporter of the initiatives behind the development of MathJax’s open source platform for display of mathematics,” said Christopher Abbott, Director, Content Service, HighWire Press. “The HighWire Open Platform is designed to work well with standards such as MathML. We’re proud to be part of the solution.”

“HighWire has been providing both support and important feedback for our development at MathJax”, comments Peter Krautzberger, MathJax manager. “Dedicated sponsors such as HighWire enable us at MathJax to deliver the most reliable, high-quality solution for math and science on the web.”

We look forward to continuing the collaboration with HighWire and welcome their ongoing support for the MathJax project.

MS SharePoint Server 2016 Support & Enhanced Footnote Handling & ...

Source: Ask.com News Search for "mathml" • February 02, 2016 • Permalink

Programmers' Heaven - Found Feb. 2, 2016
• MathML equations rendering inside shapes implemented • MathML equations vertical positioning improved when rendering • Improved...

OASIS DITA 1.3 Standard Approved for Authoring and Publishing

Source: Ask.com News Search for "mathml" • February 01, 2016 • Permalink

WVNS - Found Feb. 1, 2016
... new features, introduced in DITA 1.3, such as troubleshooting topic type, keyscopes, branch filtering, MathML domain, XML mention domain and...
OASIS DITA 1.3 Standard Approved for Authoring and Publishing - Minyanville
Explore All

OASIS DITA 1.3 Standard Approved for Authoring and Publishing

Source: Ask.com News Search for "mathml" • February 01, 2016 • Permalink

Channel 8 Eyewitness News - Found Feb. 1, 2016
... new features, introduced in DITA 1.3, such as troubleshooting topic type, keyscopes, branch filtering, MathML domain, XML mention domain and...
OASIS DITA 1.3 Standard Approved for Authoring and Publishing - WVNS
OASIS DITA 1.3 Standard Approved for Authoring and Publishing - KHQ Right Now
OASIS DITA 1.3 Standard Approved for Authoring and Publishing - Minyanville
Explore All

MS SharePoint Server 2016 Support & Enhanced Footnote Handling & ...

Source: Ask.com News Search for "mathml" • January 30, 2016 • Permalink

PR.com - Found Jan. 30, 2016
• MathML equations rendering inside shapes implemented • MathML equations vertical positioning improved when rendering • Improved...

Re: Apple's feedback for custom elements

Source: public-webapps@w3.org Mail Archives • Olli Pettay (olli@pettay.fi) • January 24, 2016 • Permalink

Random comments inline (other people from Mozilla may have different opinions)

On 01/24/2016 10:01 AM, Ryosuke Niwa wrote:
>
>
> Hi all,
>
> Here's WebKit team's feedback for custom elements.
>
>
> == Constructor vs createdCallback ==
> We would like to use constructor instead of created callback.
no comments

>
> == Symbol-named properties for lifecycle hooks ==
> After thorough consideration, we no longer think using symbols for callback names is a good idea.  The problem of name conflicts with an existing
> library seems theoretical at best, and library and framework authors shouldn't be using names such as "attributeChanged" for other purposes than as
> for the designated purpose of custom elements API.
>
> In addition, forcing authors write `[Element.attributeChanged]()` instead of `attributeChanged()` in this one API is inconsistent with the rest of Web
> API.
>
Personally I agree.

>
> == Calling attributeChanged for all attributes on creation ==
> We think invoking `attributeChanged` for each attribute during creation will help mitigating the difference between the upgrade case and a direct
> creation inside author script.
>
> https://github.com/w3c/webcomponents/issues/364
>
Fine to me. This is also close to what XTF had. (It had also a pre-callback, willSet/RemoveAttribute [1], but we can live without those at least in v1)


>
> == Lifecycle callback timing ==
> We're fine with end-of-nano-task timing due to the implementation difficulty of going fully sync and async model doesn’t meet author’s expectation.
>
nano-task scheduling sounds good.


>
> == Consistency problem ==
> This is a problem but we think calling constructor before attributes and children are added during parsing is a good enough mitigation strategy.
It is possible that we'll need beginAddingChildren()/doneAddingChildren() for the parsing case later, but not for v1.
I wonder if all the engines can easily have end-of-nanotask right after main-thread part of parser has created the DOM element and before any 
attributes/children are set.
IIRC Gecko should be fine these days.


> == Attached/detached vs. inserted/removed hooks ==
> Elements that define things or get used by other elements should probably do their work when they’re inserted into a document.  e.g. HTMLBaseElement
> needs to modify the base URL of a document when it gets inserted. To support this use case, we need callbacks when an element is inserted into a
> document/shadow-tree and removed from a document/shadow-tree.
>
> Once we have added such insertedIntoDocument/removedFromDocument callbacks, attached/detached seems rather arbitrary and unnecessary as the author can
> easily check the existence of the browsing context via `document.defaultView`.
>
> We would not like to add generic callbacks (inserted/removed) for every insertion and removal due to performance reasons.
>
> https://github.com/w3c/webcomponents/issues/362
I'd prefer getting more consistent parentChainChanged(oldSubtreeRoot, newSubtreeRoot) callback or some such. That wouldn't depend on is-in-document
state. Adding parentChainChanged later if there is already insertedIntoDocument/removedFromDocument would just duplicate some of the behavior.


Something to consider, borrowed from XTF, should custom element implementation tell to browser engine which notifications it is interested in?
That way performance considerations are partially moved from browser engine to the custom element author.


> == Style attribute spamming ==
> Since keeping the old value is inherently expensive, we think we should mitigate this issue by adding an attribute filtering.  We think having this
> callback is important because responding to attribute change was the primary motivation for keeping the end-of-a-nano-task timing for lifecycle callbacks.
>
> https://github.com/w3c/webcomponents/issues/350
attribute filter sounds good. Especially if it is consistent with MutationObserver.


> == childrenChanged callback ==
> Given the consistency problem, it might be good idea to add `childrenChanged` callback to encourage authors to respond to this event instead of
> relying on children being present if we decided to go with non-synchronous construction/upgrading model.
>
> On the other hand, many built-in elements that rely on children such as `textarea` tends to respond to all children at once.  So attaching mutation
> observer and doing the work lazily might be an acceptable workflow.
So would childrenChanged be called after parser has added all the child nodes? Or just at random time, or for each child nodes separately?

This is a case where beginAddingChildren()/doneAddingChildren() would be needed, but for now, childrenChanged is probably ok.


>
>
> == Upgrading order ==
> We should do top-down in both parsing and upgrading since parser needs to do it top-down.
no comments


>
>
>
> == What happens when a custom element is adopted to another document? ==
> Since a given custom element may not exist in a new document, retaining the prototype, etc... from the original document makes sense.  In addition,
> WebKit and Blink already exhibit this behavior so we don’t think it poses a major combat issue.
(can't recall all the details. Would need to re-read the relevant spec bugs.)


>
>
> == Inheritance from subclasses of HTMLElement such as HTMLInputElement ==
> We strongly oppose to adding this feature at least in v1.
>
> https://github.com/w3c/webcomponents/issues/363
Sounds good


>
>
> == Inheritance from SVGElement/MathMLElement ==
> We don't want to allow custom SVG and MathML elements at least in v1.
>
> https://github.com/w3c/webcomponents/issues/363
ditto


>
>
> - R. Niwa
>


-Olli

[1] http://mxr.mozilla.org/seamonkey/source/content/xtf/public/nsIXTFElement.idl#127

The CSS WG published Candidate Recommendations of CSS Fragme…

Source: Ask.com News Search for "mathml" • January 18, 2016 • Permalink

W3C - Found Jan. 18, 2016
Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java.

EditiX

Source: Ask.com News Search for "mathml" • January 15, 2016 • Permalink

ZDNet - Found Jan. 15, 2016
EditiX includes default templates with XML, DTD, XHTML, XSLT, XSD, XML RelaxNG, SVG, MathML and XML FO.
Jaksta Media Recorder - ZDNet
MixPad Multitrack Recorder - ZDNet
Balsamiq Mockups - ZDNet
Mail Archiver X - ZDNet
Explore All

The CSS WG published a Candidate Recommendation of CSS Fragm…

Source: Ask.com News Search for "mathml" • January 14, 2016 • Permalink

W3C - Found Jan. 14, 2016
Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java.

Re: CSS Priorities / character alignment (Was: Meeting Minutes, 2016-01-11)

Source: public-digipub-ig@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • January 13, 2016 • Permalink

I'm not sure if it's interesting or already known but
https://www.w3.org/Math/draft-spec/mathml.html#chapter3_id.3.5.5.10
describes the algorithm specified by the MathML spec for its in-table
alignment markup. Though, as far as I know, no web-based MathML renderer
implements malign groups.

Speaking of that link
https://drafts.csswg.org/css-text-4/#character-alignment; the example's
pseudo-rendering does not correspond to the table markup; it confused
people I had sent it to.

Peter.

On Wed, Jan 13, 2016 at 8:13 AM, Florian Rivoal <florian@rivoal.net> wrote:

>
> > On Jan 13, 2016, at 15:01, Ivan Herman <ivan@w3.org> wrote:
> >
> > Minutes are available here:
> >
> > http://www.w3.org/2016/01/11-dpub-minutes.html
>
> Hi all,
>
> Sorry for missing the meeting, it was a holiday in Japan (but I should
> have sent regrets nonetheless).
>
> I just wanted to briefly react to the discussion about the CSS Priorities
> Document,
> and confirm that there is a meeting of the CSSWG from February 1 to 3,
> that I am going to it, and that I am happy to push for discussions on
> DPUB-IG topics such as character alignment in tables, but also that
> it will be difficult for me to do so if I don't have a corpus of examples,
> especially examples that could inform the discussion about the issues
> raised by Dbaron in the spec (
> https://drafts.csswg.org/css-text-4/#character-alignment).
>
> Please help me help you :)
>
>  - Florian
>

Feeds

Planet MathML features:

If 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.

(feed)This page as an Atom feed

A mechanical calculation machine (with an added W3C logo)

Bert Bos, math activity lead
Copyright © 2008–2015 W3C®

Powered by Planet