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

## Contact

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.

All times are UTC.

Atom feed

## en-US November 24, 2014 Open Source Insider: Berners-Lee: new HTML5 'open web' milestones

Channel: Ask.com News Search for "mathml"

 Computer Weekly - Found Nov. 24, 2014 • programmatic access to a resolution-dependent bitmap canvas • native support for scalable vector graphics (SVG) and math (MathML);

## UNDNovember 12, 2014 Re: mtable borders etc

Author: | Channel: www-math@w3.org Mail Archives

On 12/11/2014 07:35, Peter Krautzberger wrote:
> RE the CSS part. It's not clear to me that MathML in HTML5 specifies
>  that table specific CSS to apply to mtable.

But whether it's the existing table properties or specific mtable
properties (or just general element css properties) if it is not
specified how CSS applies to mtable (and MathML generally) then that is
a bug in the process, somewhere which we should work to fix.

David

## UNDNovember 12, 2014 Re: mtable borders etc

Author: | Channel: www-math@w3.org Mail Archives

David Carlisle wrote:
> You can do this now of course using menclose or (in systems that support
it) css.

RE the CSS part. It's not clear to me that MathML in HTML5 specifies that
table specific CSS to apply to mtable.

Of course, in reality, many things happen to work in implementations
(Gecko, WebKit, MathJax), no matter the formalities.

I should add that MathJax has to jump through all kinds of hoops to
implement mtable since table (especially cross-browser) just doesn't cut
it. Thus there are limits to "simply" applying generic table CSS. As we are
planning to re-write our mtable implementation, I'm very interested in
getting a clearer picture of the problem space as whole. In an ideal world,
we could base it on HTML tables -- if only there was a little bit of
collaboration between the two.

Peter.

PS:  Well, actually, in an ideal world I would get rid of tables entirely
but that's a completely different discussion.

On Tue, Nov 11, 2014 at 10:34 AM, David Carlisle <davidc@nag.co.uk> wrote:

> On 11/11/2014 08:36, Daniel Marques wrote:
>
>> frame: be able to set top, left, bottom and right borders independently.
>> This does not seem difficult to add to the specification.
>>
>
> No other than adding anything more is difficult when we are still trying
> hard to get people to add what 's there.
>
> You can do this now of course using menclose or (in systems that support
> it) css.
>
> David
>
>
>

## UNDNovember 11, 2014 First CFP CICM 2015

Author: | Channel: www-math@w3.org Mail Archives

Call for Papers

Conference on Intelligent Computer Mathematics
CICM 2015

13-17 July 2015
Washington DC, USA

Digital and computational solutions are becoming the prevalent means for the
generation, communication, processing, storage and curation of mathematical
information. Separate communities have developed to investigate and build
computer based systems for computer algebra, automated deduction, and
mathematical publishing as well as novel user interfaces. While all of these
systems excel in their own right, their integration can lead to synergies
offering significant added value. The Conference on Intelligent Computer
Mathematics (CICM) offers a venue for discussing and developing solutions
to the great challenges posed by the integration of these diverse areas.

CICM has been held annually as a joint meeting since 2008, co-locating
related conferences and workshops to advance work in these
subjects. Previous meetings have been held in Birmingham (UK 2008),
Grand Bend (Canada 2009), Paris (France 2010), Bertinoro (Italy 2011),
Bremen (Germany 2012), Bath (UK 2013), and Coimbra (Portugal 2014).

This is a (short version of the) call for papers for CICM 2015, which
will be held in Washington, D.C., 13-17 July 2015.

The full version of the CFP is available from the conference web page at
http://cicm-conference.org/2015/cicm.php

**********************************************************************
The principal tracks of the conference will be:
**********************************************************************

* Calculemus (Symbolic Computation and Mechanised Reasoning)
Chair: Jacques Carette
* DML (Digital Mathematical Libraries)
Chair: Volker Sorge
* MKM (Mathematical Knowledge Management)
Chair: Cezary Kaliszyk
* Systems and Data
Chair: Florian Rabe

Publicity chair is Serge Autexier. The local arrangements will be
coordinated by the Local Arrangements Chairs, Bruce R. Miller
(National Institute of Standards and Technology, USA) and Abdou
Youssef (The George Washington University, Washington, D.C.), and the
overall programme will be organized by the General Programme Chair,
Manfred Kerber (U. Birmingham, UK).

As in previous years, it is anticipated that there will be a number
co-located workshops, including one to mentor doctoral students giving
presentations. We also solicit for project descriptions and
work-in-progress papers.

**********************************************************************
Important Dates
**********************************************************************

Conference submissions:
Abstract submission deadline:      16 February 2015
Reviews sent to authors:            6 April    2015
Rebuttals due:                      9 April    2015
Notification of acceptance:        13 April    2015
Camera ready copies due:           27 April    2015
Conference:                     13-17 July     2015

Work-in-progress and Doctoral Programme submissions:
(Doctoral: Abstract+CV)             4 May      2015
Notification of acceptance:        25 May      2015
Camera ready copies due:            1 June     2015

More detailed information, e.g. on submission via EasyChair, can be found on
http://cicm-conference.org/2015/cicm.php

--
Serge Autexier, serge.autexier@dfki.de, http://www.dfki.de/~serge/
DFKI Bremen, Cyber-Physical Systems
MZH, Room 3120                             Phone: +49 421 218    59834
Bibliothekstr.1, D-28359 Bremen              Fax: +49 421 218 98 59834
----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
principal office, *not* the address for mail etc.!!!:
management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff
supervisory board: Prof. Hans A. Aukes (chair)
Amtsgericht Kaiserslautern, HRB 2313
----------------------------------------------------------------------

## UNDNovember 11, 2014 Re: mtable borders etc

Author: | Channel: www-math@w3.org Mail Archives

On 11 nov. 2014, at 10:34, David Carlisle <davidc@nag.co.uk> wrote:

>> frame: be able to set top, left, bottom and right borders independently.
>> This does not seem difficult to add to the specification.
>
> No other than adding anything more is difficult when we are still trying hard to get people to add what 's there.
> You can do this now of course using menclose or (in systems that support it) css.

I wonder if our "developer relations" should be boosted to get more evidence of such implementations challenges.

People come to talk here about individual problems with a title and fairly shallow spec pointers.

Maybe putting a "discuss spec" link here and there would help stimulate that and thus let implementors bridge things?

paul

## UNDNovember 11, 2014 Re: mtable borders etc

Author: | Channel: www-math@w3.org Mail Archives

On 11/11/2014 08:36, Daniel Marques wrote:
> frame: be able to set top, left, bottom and right borders independently.
> This does not seem difficult to add to the specification.

No other than adding anything more is difficult when we are still trying
hard to get people to add what 's there.

You can do this now of course using menclose or (in systems that support
it) css.

David

## UNDNovember 11, 2014 Re: mtable borders etc

Author: | Channel: www-math@w3.org Mail Archives

David Carlisle wrote:
> If we were to extend this in an html+mathml context probably we should
> be looking to see some way of specifying how css table cell border
> properties are supposed to work here. CSS styling does basically work
already in firefox as far as I can see, If I take this MDN example
> and adapt it to include mtable

That seems natural to me, too. If tables provided everything mtables need,
things would be much easier. Any chance to start a conversation with other
WGs on that?

Peter.

On Tue, Nov 11, 2014 at 9:36 AM, Daniel Marques <dani@wiris.com> wrote:

> Let me explain what we, as a company, were requested regarding mtable
> frame and borders (rowlines and columnlines).
>
>
>
> frame: be able to set top, left, bottom and right borders independently.
> This does not seem difficult to add to the specification. I would recommend
> it because you currently can specify the inner borders independently via
> rowlines and columnlines.
>
>
>
> borders: requested a “dotted” style. I personally think that this is not
> so important.
>
>
>
> Dani, from WIRIS
>
>
>
> *From:* neil.soiffer@gmail.com [mailto:neil.soiffer@gmail.com] *On Behalf
> Of *Neil Soiffer
> *Sent:* martes, 11 de noviembre de 2014 1:56
> *To:* Peter Krautzberger
> *Cc:* www-math@w3.org
> *Subject:* Re: mtable borders etc
>
>
>
> Did you have a proposal? One easy thing to do in the next version of
> MathML (who knows when that would be) would be to extend the legal values
> to 'doubleline" or "solidsolid" or some such.
>
> In general, this is a losing game because someone may next want dashed
> double lines or dashed lines with arrows on each dash or...  Without the
> programability of TeX, a finite list of the higher use cases is all that
> can be done for MathML (and HTML-based languages in general).
>
> My bigger concern is that adding features raises the bar for implementers
> that are already having trouble implementing features. Having characters
> that stretch for spanning rows/cols in an mtable seems much more important
> and that is unfortunately not widely implemented.
>
>     Neil
>
>
>
> On Mon, Nov 10, 2014 at 2:42 PM, Peter Krautzberger <
> peter.krautzberger@mathjax.org> wrote:
>
> Hi,
>
>
>
> The mtable element is limited in terms of columnlines, rowlines, and
> frame. In particular, this has come up on the MathJax user group
> <https://groups.google.com/forum/#!searchin/mathjax-users/I$20guess$20it$27s$20mostly$20a$20matter$20of$20convenience$2C$20as$20maths$20folks$20are$20usually$20quite$20familiar$20with$20TeX$20but$20not$20so$20with$20HTML.$20%7Csort:relevance/mathjax-users/6vMvWrSCSzA/BH-dfMd5tK4J> a
> few years ago and has resurfaced in a bug report for MediaWiki/Wikipedia
> <https://bugzilla.wikimedia.org/show_bug.cgi?id=73169> a few days ago.
>
>
>
> Perhaps there's something constructive to be done about it?
>
>
>
> Best wishes,
>
> Peter.
>
>
>

## UNDNovember 11, 2014 RE: mtable borders etc

Author: | Channel: www-math@w3.org Mail Archives

Let me explain what we, as a company, were requested regarding mtable frame
and borders (rowlines and columnlines).

frame: be able to set top, left, bottom and right borders independently.
This does not seem difficult to add to the specification. I would recommend
it because you currently can specify the inner borders independently via
rowlines and columnlines.

borders: requested a “dotted” style. I personally think that this is not so
important.

Dani, from WIRIS

*From:* neil.soiffer@gmail.com [mailto:neil.soiffer@gmail.com] *On Behalf
Of *Neil Soiffer
*Sent:* martes, 11 de noviembre de 2014 1:56
*To:* Peter Krautzberger
*Cc:* www-math@w3.org
*Subject:* Re: mtable borders etc

Did you have a proposal? One easy thing to do in the next version of MathML
(who knows when that would be) would be to extend the legal values to
'doubleline" or "solidsolid" or some such.

In general, this is a losing game because someone may next want dashed
double lines or dashed lines with arrows on each dash or...  Without the
programability of TeX, a finite list of the higher use cases is all that
can be done for MathML (and HTML-based languages in general).

My bigger concern is that adding features raises the bar for implementers
that are already having trouble implementing features. Having characters
that stretch for spanning rows/cols in an mtable seems much more important
and that is unfortunately not widely implemented.

Neil

On Mon, Nov 10, 2014 at 2:42 PM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

Hi,

The mtable element is limited in terms of columnlines, rowlines, and frame.
In particular, this has come up on the MathJax user group
<https://groups.google.com/forum/#!searchin/mathjax-users/I$20guess$20it$27s$20mostly$20a$20matter$20of$20convenience$2C$20as$20maths$20folks$20are$20usually$20quite$20familiar$20with$20TeX$20but$20not$20so$20with$20HTML.$20%7Csort:relevance/mathjax-users/6vMvWrSCSzA/BH-dfMd5tK4J>
a
few years ago and has resurfaced in a bug report for MediaWiki/Wikipedia
<https://bugzilla.wikimedia.org/show_bug.cgi?id=73169> a few days ago.

Perhaps there's something constructive to be done about it?

Best wishes,

Peter.

## UNDNovember 11, 2014 Re: mtable borders etc

Author: | Channel: www-math@w3.org Mail Archives

On 10/11/2014 22:42, Peter Krautzberger wrote:
> Hi,
>
> The mtable element is limited in terms of columnlines, rowlines, and
> frame. In particular, this has come up on the MathJax user group
> <https://groups.google.com/forum/#!searchin/mathjax-users/I$20guess$20it$27s$20mostly$20a$20matter$20of$20convenience$2C$20as$20maths$20folks$20are$20usually$20quite$20familiar$20with$20TeX$20but$20not$20so$20with$20HTML.$20%7Csort:relevance/mathjax-users/6vMvWrSCSzA/BH-dfMd5tK4J> a
> few years ago and has resurfaced in a bug report for MediaWiki/Wikipedia
> <https://bugzilla.wikimedia.org/show_bug.cgi?id=73169> a few days ago.
>
> Perhaps there's something constructive to be done about it?
>
> Best wishes,
> Peter.
>

extensions are always possible to propose...

In this case, personally, I'm rather lukewarm, latex allows || mainly
because tabular and array are the same thing, more or less. I'm not sure
there are that many use case for || in math?

However if a double rule is needed you could model the example in the
bug report

|c|c||c|

as

|c|c|@{\hspace{\arrayrulesep}}c@{}|c|

with an empty cell (ie in tex &&) at the relevant cell boundary.

If we were to extend this in an html+mathml context probably we should
be looking to see some way of specifying how css table cell border
ptoperties are supposed to work here. CSS styling does basically work
already in firefox as far as I can see, If I take this MDN example
and adapt it to include mtable

https://developer.mozilla.org/en-US/docs/Web/CSS/border-style

It produces the attached

David
(wearing TeX hacker's hat not Math WG one)

## UNDNovember 11, 2014 Re: mtable borders etc

Author: | Channel: www-math@w3.org Mail Archives

Did you have a proposal? One easy thing to do in the next version of MathML
(who knows when that would be) would be to extend the legal values to
'doubleline" or "solidsolid" or some such.

In general, this is a losing game because someone may next want dashed
double lines or dashed lines with arrows on each dash or...  Without the
programability of TeX, a finite list of the higher use cases is all that
can be done for MathML (and HTML-based languages in general).

My bigger concern is that adding features raises the bar for implementers
that are already having trouble implementing features. Having characters
that stretch for spanning rows/cols in an mtable seems much more important
and that is unfortunately not widely implemented.

Neil

On Mon, Nov 10, 2014 at 2:42 PM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

> Hi,
>
> The mtable element is limited in terms of columnlines, rowlines, and
> frame. In particular, this has come up on the MathJax user group
> <https://groups.google.com/forum/#!searchin/mathjax-users/I$20guess$20it$27s$20mostly$20a$20matter$20of$20convenience$2C$20as$20maths$20folks$20are$20usually$20quite$20familiar$20with$20TeX$20but$20not$20so$20with$20HTML.$20%7Csort:relevance/mathjax-users/6vMvWrSCSzA/BH-dfMd5tK4J> a
> few years ago and has resurfaced in a bug report for MediaWiki/Wikipedia
> <https://bugzilla.wikimedia.org/show_bug.cgi?id=73169> a few days ago.
>
> Perhaps there's something constructive to be done about it?
>
> Best wishes,
> Peter.
>

## UNDNovember 10, 2014 mtable borders etc

Author: | Channel: www-math@w3.org Mail Archives

Hi,

The mtable element is limited in terms of columnlines, rowlines, and frame.
In particular, this has come up on the MathJax user group
<https://groups.google.com/forum/#!searchin/mathjax-users/I$20guess$20it$27s$20mostly$20a$20matter$20of$20convenience$2C$20as$20maths$20folks$20are$20usually$20quite$20familiar$20with$20TeX$20but$20not$20so$20with$20HTML.$20%7Csort:relevance/mathjax-users/6vMvWrSCSzA/BH-dfMd5tK4J>
a
few years ago and has resurfaced in a bug report for MediaWiki/Wikipedia
<https://bugzilla.wikimedia.org/show_bug.cgi?id=73169> a few days ago.

Perhaps there's something constructive to be done about it?

Best wishes,
Peter.

## UND November 06, 2014 Display MathML with Html5-Javascript solution

Author: | Channel: FMath

Hi,

A page with examples for all tags and how to use:
http://www.fmath.info/formula/js/how_to_use.jsp

The list of tags implemented from MathML is here:
http://www.fmath.info/whatIsImplemented.jsp

An example for mroot and msqrt tags (ltr and rtl implementation):

regards
Ionel Alexandru

## UNDNovember 04, 2014 Re: data-* attributes

Author: | Channel: www-math@w3.org Mail Archives

> <mi jats:foo="bar"> is valid to the MathML3 schema (as long
> as jats: namespace is declared somewhere) it's just that you
> don't want to let attributes with colons in their name
> anywhere near an HTML parser, ...

I've never thought that xml-namespaces are of much real
value for xml document instances (as opposed to xml
electronic data instances).

In particular, I've understood the banishment of namespaces
from HTML 5 to represent revulsion toward xml-namespaces of
those who produce documents.

I think it should be possible to structure the world of HTML
so that automatic generators (from various profiles of LaTeX
or DocBook or ...) to HTML5 can switch easily between the
text/html and the application/xhtml+xml serializations.
This would mean, in particular, not really using
xml-namespaces with the latter serialization, but keeping
within a reasonable framework for validation.  Maybe one
could introduce for MathML a value something like html's
"style".  For example, instead of <mi jats:foo="bar">
something like <mi mmdata='ns: jats; foo1: bar1; foo2:
"bar2a bar2b"; foo3: bar3;'> which would, with mmdata added
to the definition of html as an unspecified cdata attribute,
be able to pass html validation.  As with css a separate,
less essential, and perhaps not universal, validator could
check mmdata values.

-- Bill

## en-US November 03, 2014 The MathWorks continues as MathJax Supporter

Author: | Channel: MathJax

The MathWorks continues to support MathJax as a MathJax Supporter.

The MathWorks provides the fundamental tools for research and development in academia and industry. Its leading computing software products, MATLAB and Simulink, help engineers and scientists worldwide to accelerate the pace of discovery, innovation, and development. From industries, such as aerospace and industrial automation, to technical fields, such as financial services and computational biology, to more than 5000 colleges and universities around the world, the tools support teaching and research in a broad range of technical disciplines.

“Through its innovative display engine, MathJax is providing a valuable service to academia and industry,” said Mary Ann Freeman, director of engineering, MATLAB Products, MathWorks. “We are pleased to continue our support of this important initiative, which is focused on bringing the power of mathematics to the web.”

“The continued support of the MathWorks demonstrates its commitment to being a partner to the math science community on the web”, comments Peter Krautzberger, MathJax manager. “The feedback from sponsors like MathWorks is invaluable to ensure that MathJax remains the reliable, high-quality rendering solution it is today.”

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

## UNDNovember 03, 2014 Re: data-* attributes

Author: | Channel: www-math@w3.org Mail Archives

Thanks, David.

> In a pure XML context, attributes in (any) namespace would be the way:

Right. As I wrote in my original posting, the main motivation was doing
something without namespaces.

Peter.

On Mon, Nov 3, 2014 at 3:00 PM, David Carlisle <davidc@nag.co.uk> wrote:

> On 03/11/2014 13:47, Peter Krautzberger wrote:
>
>>
>>  > One reason [...]
>>
>>> isthat HTML moved away from grammar based syntax
>>> (data-* being a good example of something that can't even be
>>>
>> approximated in any of
>>
>>> dtd/RelaxNG or XSD schema).
>>>
>>
>> Right. Still, I'd argue that it is a significant use case. Perhaps there
>> could be note suggesting a best practice for providing information in
>> XML that would be represented as data-* in HTML.
>>
>
> In a pure XML context, attributes in (any) namespace would be the way:
> data- is in some ways an html response to address that without the
> complication of namespaces. MathML even back as far as MathML1 has always
> allowed any attributes in other namespaces (in the prose and as far as
> possible in the grammar) The schemas allow it, DTD has a parameter entity
> that makes it easy to extend an initially empty set of
> namespaced attributes, which is best you can do in DTD.
>
> Trouble is (as you see already in aria: v aria- attributes) documents
> don't always live in purely xml or purely html contexts and "best practice"
> for switching between the two isn't always clear yet.
>
>
>>  MathJax could easily ignore  [...]
>>>
>>
>> FWIW, MathJax wasn't the motivation for my question; this came out of
>> questions regarding JATS. In practice, data-* works just fine; it's just
>> not formally valid.
>>
>
> <mi jats:foo="bar"> is valid to the MathML3 schema (as long as jats:
> namespace is declared somewhere) it's just that you don't want to let
> attributes with colons in their name anywhere near an HTML parser, the
> behaviour is specified but not particularly useful. So by spec the
> implied suggestion is to have
> <mi jats:foo="bar"> in XML and <mi data-jats-foo="bar"> in HTML
> But just allowing the latter in XML would probably make everyone's life
> easier.
>
>
>
>  Peter.
>>
>>  David
>
>

## UNDNovember 03, 2014 Re: data-* attributes

Author: | Channel: www-math@w3.org Mail Archives

On 03/11/2014 13:47, Peter Krautzberger wrote:
>
>  > One reason [...]
>> isthat HTML moved away from grammar based syntax
>>(data-* being a good example of something that can't even be
> approximated in any of
>>dtd/RelaxNG or XSD schema).
>
> Right. Still, I'd argue that it is a significant use case. Perhaps there
> could be note suggesting a best practice for providing information in
> XML that would be represented as data-* in HTML.

In a pure XML context, attributes in (any) namespace would be the way:
data- is in some ways an html response to address that without the
complication of namespaces. MathML even back as far as MathML1 has
always allowed any attributes in other namespaces (in the prose and as
far as possible in the grammar) The schemas allow it, DTD has a
parameter entity that makes it easy to extend an initially empty set of
namespaced attributes, which is best you can do in DTD.

Trouble is (as you see already in aria: v aria- attributes) documents
don't always live in purely xml or purely html contexts and "best
practice" for switching between the two isn't always clear yet.

>
>>MathJax could easily ignore  [...]
>
> FWIW, MathJax wasn't the motivation for my question; this came out of
> questions regarding JATS. In practice, data-* works just fine; it's just
> not formally valid.

<mi jats:foo="bar"> is valid to the MathML3 schema (as long as jats:
namespace is declared somewhere) it's just that you don't want to let
attributes with colons in their name anywhere near an HTML parser, the
behaviour is specified but not particularly useful. So by spec the
implied suggestion is to have
<mi jats:foo="bar"> in XML and <mi data-jats-foo="bar"> in HTML
But just allowing the latter in XML would probably make everyone's life
easier.

> Peter.
>
David

## UNDNovember 03, 2014 Re: data-* attributes

Author: | Channel: www-math@w3.org Mail Archives

> One reason [...]
> is that HTML moved away from grammar based syntax
> (data-* being a good example of something that can't even be approximated
in any of
> dtd/RelaxNG or XSD schema).

Right. Still, I'd argue that it is a significant use case. Perhaps there
could be note suggesting a best practice for providing information in XML
that would be represented as data-* in HTML.

> MathJax could easily ignore  [...]

FWIW, MathJax wasn't the motivation for my question; this came out of questions
regarding JATS. In practice, data-* works just fine; it's just not formally
valid.

Peter.

On Mon, Nov 3, 2014 at 9:19 AM, David Carlisle <davidc@nag.co.uk> wrote:

> On 31/10/2014 10:13, Peter Krautzberger wrote:
>
>> Hi www-math,
>>
>> I've recently noticed that the W3C validator
>> <http://validator.w3.org/check> considers  HTML5 documents with
>> data-* attributes on MathML elements invalid.
>>
>> I'm wondering if this is a bug.
>>
>
> Not in that one (as it's using the xhtml1/mathml2 xml dtd but
>
> the html5/validator.nu based validator
>
> http://validator.w3.org/nu/
>
> also says it's invalid which I think is unfortunate. It's not really a
> bug in the validator though as (mostly) it just says what we tell it to
> say (in the relax NG schema for mathml3 in that case).
>
>>
>> It also made me wonder in how far the MathML spec could adopt data-*
>> in general. The spec suggests
>> <http://www.w3.org/Math/draft-spec/mathml.html#chapter2_
>> interf.unspecified>
>> namespacing for unspecified data. When working in both XML and HTML5
>> contexts this seems less than ideal.
>>
>>
> My personal view is that we don't need to add data- in a "pure
> xml/mathml" context) but that for mathml-in-html we should
> push for as close integration of html/svg/mathml as possible.
> At the DOM level a series of bug reports (and fixes:-) on html have
> largely achieved that with many features such as .innerHTML etc being
> pushed from HTMLElement to Element interface in the DOM so apply to
> MathML and SVG.
>
> At the markup level I think there is more we could do. One reason why we
> never updated the old HTML+MathML+SVG dtd from MathMl2 to MathML3 is
> that HTML moved away from grammar based syntax (data-* being a good
> example of something that can't even be approximated in any of
> dtd/RelaxNG or XSD schema).
>
> But I think we should have a mathml-in-html note that explicitly
> authorises data- and event based attributes such as onclick
> onmouseover etc when used in an HTML context.
>
> MathJax could easily ignore data- not sure how easy it would be to
> make the mouse events work for rendering back ends other than native
> mathml...
>
> Which brings us back to Browser support, as Frédéric just reminded us in
> another thread we perhaps need to push for better native support in more
> browsers before further standardising that support....
>
> David
> (personal response only, none of the above is a working group position)
>
>
>
>
>

## en-US November 03, 2014 HTML5 goes officially live - now you really CAN say goodbye to Java ...

Channel: Ask.com News Search for "mathml"

 Sophos Anti Virus - Found Nov. 3, 2014 ... native support for scalable vector graphics (SVG) and math (MathML); annotations important for East Asian typography (Ruby);

## UNDNovember 03, 2014 Re: data-* attributes

Author: | Channel: www-math@w3.org Mail Archives

On 31/10/2014 10:13, Peter Krautzberger wrote:
> Hi www-math,
>
> I've recently noticed that the W3C validator
> <http://validator.w3.org/check> considers  HTML5 documents with
> data-* attributes on MathML elements invalid.
>
> I'm wondering if this is a bug.

Not in that one (as it's using the xhtml1/mathml2 xml dtd but

the html5/validator.nu based validator

http://validator.w3.org/nu/

also says it's invalid which I think is unfortunate. It's not really a
bug in the validator though as (mostly) it just says what we tell it to
say (in the relax NG schema for mathml3 in that case).
>
> It also made me wonder in how far the MathML spec could adopt data-*
> in general. The spec suggests
> <http://www.w3.org/Math/draft-spec/mathml.html#chapter2_interf.unspecified>
> namespacing for unspecified data. When working in both XML and HTML5
> contexts this seems less than ideal.
>

My personal view is that we don't need to add data- in a "pure
xml/mathml" context) but that for mathml-in-html we should
push for as close integration of html/svg/mathml as possible.
At the DOM level a series of bug reports (and fixes:-) on html have
largely achieved that with many features such as .innerHTML etc being
pushed from HTMLElement to Element interface in the DOM so apply to
MathML and SVG.

At the markup level I think there is more we could do. One reason why we
never updated the old HTML+MathML+SVG dtd from MathMl2 to MathML3 is
that HTML moved away from grammar based syntax (data-* being a good
example of something that can't even be approximated in any of
dtd/RelaxNG or XSD schema).

But I think we should have a mathml-in-html note that explicitly
authorises data- and event based attributes such as onclick
onmouseover etc when used in an HTML context.

MathJax could easily ignore data- not sure how easy it would be to
make the mouse events work for rendering back ends other than native
mathml...

Which brings us back to Browser support, as Frédéric just reminded us in
another thread we perhaps need to push for better native support in more
browsers before further standardising that support....

David
(personal response only, none of the above is a working group position)

## UNDOctober 31, 2014 Re: data-* attributes

Author: | Channel: www-math@w3.org Mail Archives

It’s not just the W3C validator. We found a similar issue with the Design Science MathFlow integration into oxygen XML 15 earlier this year at Pearson School.

We solved the issue by moving the data-* attr. Out of the MathML.

Jean Kaplansky
Senior Director, Solutions Architecture
o: +1.518.496.2967

See our new website<http://www.aptaracorp.com/>

From: Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>>
Date: Friday, October 31, 2014 at 6:13 AM
To: "www-math@w3.org<mailto:www-math@w3.org>" <www-math@w3.org<mailto:www-math@w3.org>>
Subject: data-* attributes
Resent-From: <www-math@w3.org<mailto:www-math@w3.org>>
Resent-Date: Friday, October 31, 2014 at 6:14 AM

Hi www-math,

I've recently noticed that the W3C validator<http://validator.w3.org/check> considers  HTML5 documents with data-* attributes on MathML elements invalid.

I'm wondering if this is a bug.

It also made me wonder in how far the MathML spec could adopt data-* in general. The spec suggests<http://www.w3.org/Math/draft-spec/mathml.html#chapter2_interf.unspecified> namespacing for unspecified data. When working in both XML and HTML5 contexts this seems less than ideal.

Best regards,
Peter.
--

Dr. Peter Krautzberger
MathJax Manager