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

[MathOnWeb] CANCEL meeting April 12

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • April 12, 2018 • Permalink

Hi everyone,

due to many regrets, let's skip the meeting and reconvene on April 26.

Best,
Peter.

[MathOnWeb] reminder: meeting April 12

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • April 11, 2018 • Permalink

Hi everyone,

Just a quick reminder that we're meeting on April 12 at noon Eastern time
at the usual Hangouts URL.

Agenda items below -- feel free to add here or later.

Best,
Peter.

Agenda

* continue the discussion from the last meeting (Arno's JSON proposal,
linked data etc)
* updates from CSS TF

Final Call for Papers: 13th International Workshop on User Interfaces for Theorem Provers (UITP 2018)

Source: www-math@w3.org Mail Archives • Christoph Lüth (christoph.lueth@dfki.de) • April 09, 2018 • Permalink

[Apologies for multiple copies.]
[Deadline coming up: April 15th]

CALL FOR PAPERS:

13th INTERNATIONAL WORKSHOP ON
USER INTERFACES FOR THEOREM PROVERS (UITP 2018)

http://www.informatik.uni-bremen.de/uitp/uitp2018/

July 13th, 2018. Oxford, UK
A FLoC 2018 workshop.

The User Interfaces for Theorem Provers workshop series
(UITP) brings together researchers interested in designing,
developing and evaluating interfaces for interactive proof
systems, such as theorem provers, formal method tools, and
other tools manipulating and presenting mathematical
formulas.

While the reasoning capabilities of interactive proof
systems have increased dramatically over the last years, the
system interfaces have often not enjoyed the same attention
as the proof engines themselves. In many cases, interfaces
remain relatively basic and under-designed.

The User Interfaces for Theorem Provers workshop series
provides a forum for researchers interested in improving
human interaction with proof systems. We welcome
participation and contributions from the theorem proving,
formal methods and tools, and HCI communities, both to
report on experience with existing systems, and to discuss
new directions. Topics covered include, but are not limited
to:

* Application-specific interaction mechanisms or designs for prover
interfaces
* Experiments and evaluation of prover interfaces
* Languages and tools for authoring, exchanging and presenting proof
* Implementation techniques (e.g. web services, custom middleware, DSLs)
* Integration of interfaces and tools to explore and construct proof
* Representation and manipulation of mathematical knowledge or objects
* Visualization of mathematical objects and proof
* System descriptions

SUBMISSION
==========

Submitted papers should describe previously unpublished work
(completed or in progress), and be at least 4 pages and at
most 12 pages. We encourage concise and relevant
papers. Submissions should be in PDF format, and typeset
with the EPTCS LaTeX document class (which can be downloaded
from http://style.eptcs.org/). Submission is via EasyChair
(https://www.easychair.org/conferences/?conf=uitp2018).

All papers will be peer reviewed by members of the programme
committee and selected by the organizers in accordance with
the referee reports.

At least one author/presenter of accepted papers must attend
the workshop and present the work.

IMPORTANT DATES
===============

Submission deadline:     15.04.2018
Acceptance notification: 15.05.2018
Workshop:                13.07.2018

PROCEEDINGS
===========

Authors will have the opportunity to incorporate feedback
and insights gathered during the workshop to improve their
accepted papers before publication in the post-proceedings
in the Electronic Proceedings in Theoretical Computer
Science (EPTCS).

PROGRAMME COMMITTEE
===================

Mateja Jamnik, University of Cambridge, UK (co-Chair)
Christoph Lüth, University of Bremen, Germany (co-Chair)
Serge Autexier, DFKI Bremen, Germany
David Aspinall, University of Edinburgh, UK
Chris Benzmüller, Free University Berlin, Germany
Yves Bertot, INRIA Sophia-Antipolis, France
Maria Paola Bonacina, University of Verona, Italy
Joachim Breitner, University of Pennsylvania, USA
Ross Duncan, University of Strathclyde, UK
Moa Johansson, Chalmers University, Sweden
Zoltán Kovács, RISC, Austria
Mohamed Yousri Mahmoud, University of Ottawa, Canada
Michael Norrish, NICTA, Australia
Andrei Paskevich, LRI, France
Larry Paulson, University of Cambridge, UK
Alison Pease, University of Dundee, UK
Pedro Quaresma, University of Coimbra, Portugal
Gem Stapleton (University of Brighton, UK)
Christian Sternagel, University of Innsbruck, Austria
Enrico Tassi, INRIA Sophia-Antipolis, France
Laurent Théry, INRIA Sophia-Antipolis, France
Makarius Wenzel, Sketis, Germany
Wolfgang Windsteiger, RISC Linz, Austria
Bruno Woltzenlogel Paleo, Technical University Vienna, Austria

CONTACT
=======

uitp2018@easychair.org

This Saturday (7 April 2018) is MathML's 20th anniversary!

Source: W3C Math Home • April 05, 2018 • Permalink

This Saturday (7 April 2018) is MathML's 20th anniversary!

Minutes Telecon 2018-04-04 [css-values] [css-display] [css-grid] [cssom] [css-align] [css-multicol]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • April 05, 2018 • Permalink

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Fonts Level 4
--------------

  - RESOLVED: Publish a new WD of Fonts L4

Values & Units 4
----------------

  - RESOLVED: Extend value definition syntax to handle value ranges
              and possibly other syntactic restrictions, syntax TBD.
              (Issue #355)

CSS Display
-----------

  - RESOLVED: Accept change set
https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3
             (Issue #1643)
  - RESOLVED: Add the appendix
https://drafts.csswg.org/css-display-3/#box-guidelines
              to Display 3 (Issue #1643)
  - RESOLVED: Run-in flow-root blockifies to block and not flow root.
             (Issue #1715)
  - RESOLVED: Treat display:contents as display:none for MathML.
              (Issue #2167)
  - RESOLVED: We define how SVG elements interact with
              display:contents based on SVG defined categories. We
              will add a new issue about what to do with attributes.
              (Issue #2118)
  - RESOLVED: Keep this note (The display property has no effect on an
              element’s semantics: these are defined by the document
              language and are not affected by CSS. Aside from the
              none value, which also affects the aural/speech output
              [CSS-SPEECH-1] and interactivity of an element and its
              descendants, the display property only affects visual
              layout: its purpose is to allow designers freedom to
              change the layout behavior of an element without
              affecting the underlying document semantics.) in Display
              L3 (Issue #2335)
  - RESOLVED: Pending AmeliaBR edits, publish a new WD of Display L3.

CSS Grid
--------

  - RESOLVED: Specify the current behavior in all the browsers except
              Edge. Just don't use repeat() in grid serialization.
              (Issue #2427)

Multi-Col
---------

  - RESOLVED: Remove the UI defined bit and go with 1em for computing
              normal in multi-col. (Issue #2145)

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Apr/0001.html

Present:
  Rachel Andrew
  Tab Atkins
  David Baron (beginning of call)
  Amelia Bellamy-Royds
  Garrett Berg
  Elika Etemad
  Dael Jackson
  Chris Lilley
  Theresa O'Connor
  Manuel Rego
  Melanie Richards
  Florian Rivoal
  Alan Stearns

Regrets:
  Angelo Cano
  Tony Graham
  Vlad Levantovsky
  Peter Linss
  Liam Quin
  François Remy
  Geoffrey Sneddon
  Shane Stephens
  Lea Verou
  Greg Whitworth
  Eric Willigers

Scribe: dael

  astearns: It's 5 after. We have...10 people on the call. Which seems
            pretty light.
  astearns: Maybe we can get through a few things.
  astearns: fantasai mentioned the first item on the agenda is a name
            convention that might should wait until TabAtkins calls in.
  astearns: Anything else anyone would like to add to the agenda?

Fonts Level 4
=============

Publication of Fonts L4
-----------------------

  astearns: I understand this is just a regular WD and we've had FPWD
  fantasai: Yeah.
  astearns: Objections?
  <ChrisL> +1

  RESOLVED: Publish a new WD of Fonts L4

  <fantasai> \^_^/

Values & Units 4
================

Define <positive-integer>, <positive-number>, <positive-length>, etc.
    sub-types
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/355

  AmeliaBR: A couple years ago there was discussion and it got lost in
            bikeshedding syntax. I wanted to at least get a clear
            opinion from the group if the idea is good.
  AmeliaBR: I'd like to see if that when we have properties with
            constraints enforced by the parser, most common is no
            negative values, there is a way to explain that in the
            grammar rather then only prose.
  AmeliaBR: It would be convenient for people impl parsers if the
            grammar covered everything esp now that Houdini is
            exposing the value syntax. Might be time to be more strict
            about value definition language.
  <florian> +1, makes total sense to me
  AmeliaBR: I was hoping to get a resolution that it would be a good
            idea to extend value definition language to cover all
            constraints from the parser.
  <dbaron> "all constraints that can be enforced by the parser" sounds
           like it might be a little much
  AmeliaBR: I had a second question on narrowing down approaches.
  <astearns> +1 from me as well

  <TabAtkins> positive-int, and gez-int and gez-number seem very fine,
             along with gez-length/etc
  <astearns> define gez?
  <TabAtkins> greater-equal-zero
  <TabAtkins> p-integer, nn-integer

  fantasai: I don't think we'll be able to put in all parsing
            restrictions because I remember there are restrictions not
            in the grammar that aren't just about limiting range of
            numbers. We won't get to 100% but it should be possible to
            put range restrictions. If this is author exposed syntax
            that might be important.
  florian: I think we could take somewhere between...in V&U we define
           non-negative ranges and houdini relies on that. If it's not
           the case already in individual specs we have something that
           looks like int but with constraints we define a new type.
           Doesn't have to be shared in V&U. That's not actionable,
           that's how to write. The actionable part I'm all for it.
  astearns: I'm all for having this defined in the grammar and not
            lost in the prose. I don't care what names we use
            particularly.
  fantasai: I'd like the syntax to be reasonably readable and not so
            long that the grammar is hard to read.
            non-negative-integer is really long.
  fantasai: Every time we throw in one or four of these it gets long
            and maybe wraps and it's hard to read. It seems like a
            great idea but I haven't seen a proposal for yes we should
            do it this way. If this is exposed in Houdini we should
            put thought in understandable and usable like we do for
            other property values we define.

  astearns: I think consensus is this is a good direction to take.
            Second question?
  AmeliaBR: My initial idea was new name types but in the discussion
            there was a suggestion of introducing it more as a
            modifying constraint within the type. Syntax that looked
            readable was make it look like a HTML attribute.
  AmeliaBR: It's very nice and readable. Other aspect is it's open
            ended. Could be a benefit, could be a negative. Do people
            like the idea of adding a general way of adding
            constraints or is it something we want to keep to named
            types?
  TabAtkins: I hadn't seen that comment, I'll have to think about that.
  <florian> I am not sure, but I am intrigued
  <TabAtkins> Ah, I suggested p-* and nn-* in the issue. ^_^

  astearns: proposal: we will add more terms tot he grammar to
            describe value ranges and such, but approach is in the air.
  astearns: Objections?
  <fantasai> proposed resolution: Extend value definition syntax to
             handle value ranges and possibly other syntactic
             restrictions, syntax TBD

  RESOLVED: Extend value definition syntax to handle value ranges and
            possibly other syntactic restrictions, syntax TBD.

CSS Display
===========

Defining box ↔ element style correspondence
-------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1643

  <fantasai> https://github.com/w3c/csswg-drafts/issues/1643#issuecomment-374414522
  <fantasai> https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3
  fantasai: We got two issues out of the one filed. First is that it's
            not defined that the things that apply to and element
            apply to a box. We tightened that in this change set ^
  fantasai: That's the first issue.
  florian: Is it a one to one correspondence?
  fantasai: No because some apply to principle box and some to others.
            On a table some are to wrapper box and some to table. So
            we said computed value to the box to which it applies.
  astearns: Quick read from me seems like that change is good.
  astearns: It's really expanding on the sort sentence we had.
  fantasai: Yes.
  astearns: Objections to this change?

  RESOLVED: Accept change set
https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3

  florian: Question, you're saying inherited prop inherit through box
           tree. Does that do strange when some boxes are suppressed?
  fantasai: I don't think so. When they're suppressed they're not in
            the box tree.
  fantasai: I don't know of a case when an element generates two boxes
            where one is the child then the other and there's a
            suppressed box between.
  florian: So children of display:none has no inheritance?
  fantasai: Inheritance happens in the element tree. Before and after
            boxes inherit. Anon boxes inherit. First you do the
            cascade, then inheritance, then you get prop for every
            element in the tree.
  florian: Sentence I'm reacting to is a clarification, not a
           requirement. It's not clear that's what was meant. It
           confused me.
  fantasai: Sentence says [reads]. So I don't know where you'll get a
            problem.
  <fantasai> + In general, <a>inherited properties</a> are assigned to
             the <a>principal box</a>,
  <fantasai> + and then inherit through the box tree
  <fantasai> + to any other boxes generated by the same element.
  florian: If you think enough there's only one explanation and it's
           the sane one.
  astearns: If you can come up with something clearer feel free to
            make a PR.
  florian: This is fine.

Adding appendix of anonymous box construction guidance for spec
    authors
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1643#issuecomment-374414522

  astearns: Second change?
  fantasai: Second it was asking for guidance on box tree
            construction. We added an appendix.
  <fantasai> https://drafts.csswg.org/css-display-3/#box-guidelines
  fantasai: It has four bullet points of things you need to define if
            you're writing a spec that changes boxes.
  astearns: Looks fine to me.
  florian: That's useful.
  astearns: Objections to adding this appendix to display 3?

  RESOLVED: Add the appendix
https://drafts.csswg.org/css-display-3/#box-guidelines
            to Display 3

  fantasai: That's if for this issue. There was a grumble about 2.1
            terminology.

Blockifying 'run-in flow-root' to 'block' (for consistency with
    inline-block)
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1715

  florian: Was an alternative considered? I can't think of one.
  TabAtkins: It's the question in the title. Should it blockify to
             flow-root. It shouldn't.
  TabAtkins: An inline flow root blockifies to an ordinary block. This
             is for legacy reasonings. A run-in flow-root needs to
             blockify somehow. The general rule for run-in they're
             identical to inlines. Thus it should blockify the same as
             inlines.
  TabAtkins: Alternative is if blockifies to flow-root which makes
             sense in abstract, but we'd loose the connection to
             inline.
  florian: Consistency argument wins or theoretical purity.
  astearns: Run in flow root blockifies to block and not flow root.
  astearns: Objections?

  RESOLVED: Run-in flow-root blockifies to block and not flow root.

'display: contents' on MathML
-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2167

  TabAtkins: We have special rules for how display:contents should
             work in SVG. [missed]
  TabAtkins: How to handle display:contents- a few elements treat it
             like HTML, ones with a transparent content model.
             Everything else is treated as display:none because
             children can't be rendered one level up. Looking at
             mathML there are 0 instances where children can be
             rendered in outer context.
  TabAtkins: It would almost never be correct to lift children to
             outer context. There are a few places where it's right
             with only a certain number of children. Best thing I can
             see is make it always display:none on MathML. Firefox
             devs were fine with this.
  <florian> +1

  astearns: Given other times we said display:contents are handled as
            display:none and how well they went over I expect this to
            come up again.
  TabAtkins: If someone can point to a MathML function where it makes
             sense we can change this.
  fantasai: We'll CC MathML WG when we publish a WD
  florian: And we CCed some MathML people along the way.
  astearns: You want to talk to math on the web community group
  astearns: Objections to treating display:contents as display:none
            for MathML?

  RESOLVED: Treat display:contents as display:none for MathML.

'display: contents' on SVG elements
-----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2118

  TabAtkins: We've resolved on which SVG elements respond in which
             ways to display:contents.
  TabAtkins: It was pointed out I made a mistake. That points to a
             larger issue that as SVG evolves the elements that are
             categorized will evolve. Instead of categorizing
             explicitly we should use the element categories that SVG
             defines.
  TabAtkins: AmeliaBR suggested a particular grouping for each one.
             SVG WG did review and said it was fine. I think it's
             fine. If the rest of the group is okay switching to using
             SVG categories we can do that.
  ChrisL: I agree this is best and I like AmeliaBR categories.
  AmeliaBR: Categories are appropriate. They weren't made with this
            use case, but by intersecting existing categories we can
            make it work.

  AmeliaBR: One thing, we haven't designed...would display:contents on
            a text-path override layout defined on an attribute?
  AmeliaBR: t-span and text-path are ones we're saying text content
            works as an unboxing. They both involve layout with
            attributes not CSS properties. I had been assuming that a
            display:contents would mean ignore any layout specific to
            this element, but we should be explicit.
  ChrisL: Agree.
  ChrisL: They're not presentation attributes?
  AmeliaBR: No.
  TabAtkins: I need to finally write up the explanation for how SVG
             rendered into CSS box model. We keep having to do this
             tap dance and we know it uses a reasonable concept of
             boxes. Then it'll all work out.
  AmeliaBR: Can you do that by next week? ^-^ Elsewise a note saying
            it unboxes all layout regardless of syntax.

  florian: Follow up question on attributes. These presentational
           attributes on the element, can some be described as
           inheriting to anonymous box with the text? Or are they all
           clearly to the suppressed box?
  AmeliaBR: Good and complex question.
  TabAtkins: There's no anonymous box around text, it's lifted to
             parent. Anything presentational that's CSS disappears.
             Anything which is just in SVG terms we'll for now put
             something in that says do the same.
  florian: So they just disappear? You bold a font in the style and
           display:contents on the span you get bold text. Do we have
           things like that in SVG where they need to apply to the
           text-run?
  AmeliaBR: The bit where I said it was complex...the layout
            attributes inherit down in a way that doesn't quite match
            CSS because it's per character. But it's similar to
            inheritance.
  florian: It seems to me the thing we're about to resolve on it right
           but a bit incomplete. We need to talk per attribute. Or is
           there a well enough defined thing in SVG.
  AmeliaBR: What's the spec status? Trying to get to CR and don't want
            an open issue?
  TabAtkins: It's not a big issue. We look at each and say if it's an
             inheriting property.
  fantasai: Next step is WD so it doesn't need fix today.
  AmeliaBR: I can try and write up something and perhaps a note about
            an open issue needing more review.

  fantasai: Sounds like we're going to accept the changes. There is a
            followup issue on attributes that should be opened
            separately.
  astearns: Question on the categories. We're going to call out
            categories that are not doing display:none and anything
            not called out is the display:none. If at some point SVG
            defines new things that might have something different
            then display:none we'll have to add it in the future. Is
            that the right approach?
  AmeliaBR: Yeah. Presumably most elements that are new would fit into
            one of these categories. This idea with these category
            names is they should be open ended.
  astearns: So a new thing would be classified as a renderable element
            it would be fixed.
  AmeliaBR: If we defined a new attribute as a renderable element it
            would auto-apply
  ChrisL: It would only be a problem if we needed a new category

  astearns: Prop: We define how SVG elements interact with
            display:contents based on SVG defined categories. We will
            add a new issue about what to do with attributes.
  astearns: Objections?

  RESOLVED: We define how SVG elements interact with display:contents
            based on SVG defined categories. We will add a new issue
            about what to do with attributes.

  <florian> AmeliaBR, do you want to file that new issue? I believe
            you got my point, and you're more likely than me to phrase
            it right.
  <AmeliaBR> florian, yes, I'll do that.

Clarify (non-)effect of 'display' on document semantics and assistive
    technology
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2355

  <fantasai> https://github.com/w3c/csswg-drafts/issues/2355#issuecomment-375084853
  fantasai: This is about adding a note to explain display properties
            doesn't effect semantics. I was asking for WG review of
            the note text. Let me know if there are changes to suggest.
  florian: I agree with the note but I'm surprised it's needed. If I
           understand it's a note because browsers do mess it up.
  fantasai: They acknowledge this is a bug.
  florian: We're not stuck for compat?
  fantasai: Everyone agrees it's a bug, it just hasn't been a priority.
  florian: Good.

  astearns: I guess there is no linkable bit in the spec to this note.
  <astearns> https://drafts.csswg.org/css-display-3/#the-display-properties
  astearns: This section^ This is the section the note is in. But
            there's no way to link to just the note in the bit.
  fantasai: I can give it an anchor.
  astearns: I don't know it's necessary. Just trying to get text into
            the minutes.
  fantasai: It's quoted in the comment
  <fantasai> The display property has no effect on an element’s
             semantics: these are defined by the document language and
             are not affected by CSS. Aside from the none value, which
             also affects the aural/speech output [CSS-SPEECH-1] and
             interactivity of an element and its descendants, the
             display property only affects visual layout: its purpose
             is to allow designers freedom to change the layout
             behavior of an element without affecting the underlying
             document semantics.
  astearns: Any other opinions or concerns about this note?

  astearns: Proposal: keep this note in display L3.
  astearns: Objections?

  RESOLVED: Keep this note in Display L3

Publication
-----------

  fantasai: Once we fold in the edits.
  astearns: Pending AmeliaBR edits, objections to publishing a new WD
            of Display L3?

  RESOLVED: Pending AmeliaBR edits, publish a new WD of Display L3

CSS Grid
========

Disallow repeat() syntax in grid-template-rows/columns resolved values
----------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2427
  Scribe: fantasai

  TabAtkins: So we resolved to serialize out the repeat()s that were
             specified,
  TabAtkins: but actually you can't do that as fantasai points out in
             https://github.com/w3c/csswg-drafts/issues/2427#issuecomment-377357237
  TabAtkins: So we need to choose some different option
  TabAtkins: There are a few possible options
  TabAtkins: First is to reverse previous resolution: don't use
             repeat() in serialization of gCS
  TabAtkins: This is very simple and straightforward
  TabAtkins: downside is it can potentially produce very long values
             for grid-template*
  TabAtkins: if you do something like grid-template-rows:
             repeat(10000, 1px)
  TabAtkins: Second option is to compress any adjacent tracks that
             have the same track size (and line names)
  astearns: Clarification on 2nd option, is that only when specified
            value was repeat() or anytime?
  TabAtkins: Anytime
  TabAtkins: more complicated variants are to track which tracks came
             from a repeat(), and then collapse them if possible
  (These options are summarized in
https://github.com/w3c/csswg-drafts/issues/2427#issuecomment-377357237
)
  TabAtkins: The Igalia folks don't like tracking which things were in
             repeat() originally
  TabAtkins: seems like too much complexity for little gain
  TabAtkins: I think the best thing to do is to not serialize
             repeat(). The only issue is a blow-out of string sizes if
             you have long ones
  TabAtkins: but there is a cap on the number of tracks so it won't be
             too crazy
  florian: I think I'd go with non-collapsing things
  florian: Seems to me that there are a lot of corner cases
  florian: I think I'd go with non-collapsing things as well. As i'm
           looking through there seems to be lots of corner cases. I'm
           not sure they'll all be fine.
  florian: Given there's limited value le's skip the pain.

  Scribe: dael

  florian: Given that you get things like calc that are somewhat the
           same. I'd rather just not go there.
  astearns: Only edge rep is melanierichards. Since Edge is the
            browser that retains repeat() and thought we should. I'd
            like to get an Edge opinion.
  fantasai: frremy says still siding on the don't use repeat() side.
  TabAtkins: Rossen wants repeat() and frremy would rather not.
  astearns: Since frremy commented on the issue my Edge concern is
            satisfied.

  astearns: Other comments on if we should deal with repeats or throw
            them out?
  astearns: Prop: Specify the behavior in all the browsers except
            Edge. Just don't use repeat() in grid serialization

  RESOLVED: Specify the current behavior in all the browsers except
            Edge. Just don't use repeat() in grid serialization.

MultiCol
========

Make "column-gap: normal" to be 1em in multi-column per spec
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2145#issuecomment-377445142

  rachelandrew: In the multi-col spec there's a suggested value of 1em.
  rachelandrew: Everyone is doing 1em so we suggest it's mandatory.
  florian: And this interop includes print formatters. Let's go for it.
  astearns: Proposed is remove the UI defined bit and go with 1em for
            computing normal in multi-col

  RESOLVED: Remove the UI defined bit and go with 1em for computing
            normal in multi-col

  astearns: Thanks everybody for calling in. We'll have the F2F next
            week so please add things to the agenda.
  astearns: Safe travels to everyone coming and talk to you all next
            week.

[csswg] Agenda conf call 04-Apr-2018 APAC Time

Source: www-style@w3.org Mail Archives • Alan Stearns (stearns@adobe.com) • April 03, 2018 • Permalink

Time/Phone/WebEx details available to WG Members in w3c-css-wg.
See https://lists.w3.org/Archives/Member/w3c-css-wg/2017OctDec/0076.html


US Toll Number: +1-617-324-0000

For local times, see: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180404T23


0. Extra agenda items and other digressions

1. [css-values] Define <positive-integer>, <positive-number>, <positive-length>, etc. sub-types
    https://github.com/w3c/csswg-drafts/issues/355


2. [css-display] Defining box ↔ element style correspondence
    Issue: https://github.com/w3c/csswg-drafts/issues/1643

    Changes: https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3


3. [css-display] Adding appendix of anonymous box construction guidance for spec authors
    Issue:   https://github.com/w3c/csswg-drafts/issues/1643#issuecomment-374414522

    Changes: https://github.com/w3c/csswg-drafts/commit/533ac0a31b0262c4a0d09c77e19604666fe35e14

    Spec:    https://drafts.csswg.org/css-display-3/#box-guidelines


4. [css-display] Blockifying 'run-in flow-root' to 'block' (for consistency with inline-block)
    Issue:   https://github.com/w3c/csswg-drafts/issues/1715

    Changes: https://github.com/w3c/csswg-drafts/commit/4a8afc522477d24032665c9ff3ceed9f76aaa6b4


5. [css-display] 'display: contents' on MathML
    Issue:   https://github.com/w3c/csswg-drafts/issues/2167

    (This should also get reviewed by the MathMLWG; we'll send
    over a request for review along with the WD announcement
    after an initial proposal is accepted by the CSSWG.)

6. [css-display] 'display: contents' on SVG elements
    Issue:   https://github.com/w3c/csswg-drafts/issues/2118

    (This should also get reviewed by the SVGWG, but CSSWG + AmeliaBR
    should be good enough until we forward the WD announcement
    with a more formal request for review.)

7. [css-display] Clarify (non-)effect of 'display' on document semantics and assistive technology
    Issue:    https://github.com/w3c/csswg-drafts/issues/2355

    Proposal: https://github.com/w3c/csswg-drafts/issues/2355#issuecomment-375084853

    Looking for a review of the proposed text and any suggestions for improvement.

8. [css-grid][cssom] Disallow repeat() syntax in grid-template-rows/columns resolved values
    https://github.com/w3c/csswg-drafts/issues/2427


9. [css-align][css-multicol] Make "column-gap: normal" to be 1em in multi-column per spec
    https://github.com/w3c/csswg-drafts/issues/2145#issuecomment-377445142


10. [css-fonts-4] @font-family src: should accept a specifier which lists font requirements
    https://github.com/w3c/csswg-drafts/issues/633


11. [css-ui-4] Change the pointer cursor to indicate any interactive element
    https://github.com/w3c/csswg-drafts/issues/1936


Thanks,

Alan

[csswg] Agenda conf call 07-Mar-2018 APAC Time

Source: www-style@w3.org Mail Archives • Alan Stearns (stearns@adobe.com) • April 03, 2018 • Permalink

NOTE: This is an APAC-timed meeting, 4PM Pacific Time

Time/Phone/WebEx details available to WG Members in w3c-css-wg.
See https://lists.w3.org/Archives/Member/w3c-css-wg/2017OctDec/0076.html


US Toll Number: +1-617-324-0000

For local times, see: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180404T23


0. Extra agenda items and other digressions

1. [css-values] Define <positive-integer>, <positive-number>, <positive-length>, etc. sub-types
    https://github.com/w3c/csswg-drafts/issues/355


2. [css-display] Defining box ↔ element style correspondence
    Issue: https://github.com/w3c/csswg-drafts/issues/1643

    Changes: https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3


3. [css-display] Adding appendix of anonymous box construction guidance for spec authors
    Issue:   https://github.com/w3c/csswg-drafts/issues/1643#issuecomment-374414522

    Changes: https://github.com/w3c/csswg-drafts/commit/533ac0a31b0262c4a0d09c77e19604666fe35e14

    Spec:    https://drafts.csswg.org/css-display-3/#box-guidelines


4. [css-display] Blockifying 'run-in flow-root' to 'block' (for consistency with inline-block)
    Issue:   https://github.com/w3c/csswg-drafts/issues/1715

    Changes: https://github.com/w3c/csswg-drafts/commit/4a8afc522477d24032665c9ff3ceed9f76aaa6b4


5. [css-display] 'display: contents' on MathML
    Issue:   https://github.com/w3c/csswg-drafts/issues/2167

    (This should also get reviewed by the MathMLWG; we'll send
    over a request for review along with the WD announcement
    after an initial proposal is accepted by the CSSWG.)

6. [css-display] 'display: contents' on SVG elements
    Issue:   https://github.com/w3c/csswg-drafts/issues/2118

    (This should also get reviewed by the SVGWG, but CSSWG + AmeliaBR
    should be good enough until we forward the WD announcement
    with a more formal request for review.)

7. [css-display] Clarify (non-)effect of 'display' on document semantics and assistive technology
    Issue:    https://github.com/w3c/csswg-drafts/issues/2355

    Proposal: https://github.com/w3c/csswg-drafts/issues/2355#issuecomment-375084853

    Looking for a review of the proposed text and any suggestions for improvement.

8. [css-grid][cssom] Disallow repeat() syntax in grid-template-rows/columns resolved values
    https://github.com/w3c/csswg-drafts/issues/2427


9. [css-align][css-multicol] Make "column-gap: normal" to be 1em in multi-column per spec
    https://github.com/w3c/csswg-drafts/issues/2145#issuecomment-377445142


10. [css-fonts-4] @font-family src: should accept a specifier which lists font requirements
    https://github.com/w3c/csswg-drafts/issues/633


11. [css-ui-4] Change the pointer cursor to indicate any interactive element
    https://github.com/w3c/csswg-drafts/issues/1936


Thanks,

Alan

MathJax v2.7.4 now available

Source: MathJax • April 03, 2018 • Permalink

We are happy to officially release MathJax v2.7.4 today.

This is a bug-fix release. Among the issue fixed in this release are the following:

For details on all bug fixes and enhancements, please see below.

This release should be available on all CDN providers, e.g., https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.4/MathJax.js which you can load it in place of the version you are currently using (or load latest.js instead of Mathjax.js to get the latest version 2.x, whatever it is, but note that this loads asynchronously, so the MathJax global variable may not be available immediately).

Alternatively, you can get a ZIP archive or access the branch on GitHub.

Thanks for your continuing interest in MathJax. We hope that this release makes your MathJax experience even better.

The MathJax Team.


New in MathJax v2.7.4

For more information see also the 2.7.4 milestone.

Representation of Math Accents

Source: Murray Sargent: Math in Office • MurrayS3 • March 31, 2018 • Permalink

The post Math Accents discusses how accent usage in math zones differs from that in ordinary text, notably in the occurrence of multicharacter bases. Even with single character bases, the accents may vary in width while in ordinary text the accent widths are the same for all letters. The present post continues the discussion by describing the large number of accents available for math in Unicode and in Microsoft Office math zones and how they are represented in MathML, RTF, OMML, LaTeX, and UnicodeMath.

Unicode math accents

As noted in Section 3.10 Accent Operators of the UnicodeMath specification, the most common math accents are (along with their TeX names)

These and more accents are described in Section 2.6 Accented Characters and 3.2.7 Combining Marks in Unicode Technical Report #25, Unicode Support For Mathematics. More generally, the Unicode ranges U+0300..U+036F and U+20D0..U+20EF have these and other accents that can be used for math.

The Windows Character Map program shows that the Cambria Math font has all combining marks in the range 0300..036F as well as 20D0..20DF, 20E1, 20E5, 20E6, 20E8..20EA. The range 0300..036F used as math accents in Word looks like

Except for the horizontal overstrikes and the double-character accents shown in red, all these work as math accents in Microsoft Office apps, although many aren’t used in math. In keeping with the Unicode Standard, UnicodeMath represents an accent by its Unicode character, placing the accent immediately after the base character. There’s no need for double-character accents in Microsoft Office math since the corresponding “single” character accents expand to fit their bases as in

In UnicodeMath, this is given by (a+b)~, where ~ can be entered using the TeX control word \tilde. This is simpler than TeX, which uses \widetilde{a+b} for automatically sized tildes rather than \tilde{a+b}.

The combining mark in the range 20D0..20EF that work as accent objects in Office math zones areYou can test accents that don’t have TeX control words by inserting a math zone (type alt+=), type a non-hex letter followed by the Unicode value, alt+x, space. For example, alt+=, z, 36F, alt+x, space gives

Accents in MathML

MathML 1 was released as a W3C recommendation in April 1998 as the first XML language to be recommended by the W3C. At that time, Unicode was just starting to take hold as Microsoft Word 97 and Excel 97 had switched to Unicode. [La]TeX was developed before Unicode 1.0, so it relied on control words. Accordingly, it was common practice in 1998 to use control words or common spacing accents to represent accents instead of the Unicode combining marks even though many accents didn’t have a unified standardized representation. Unicode standardized virtually all math accents by using combining marks. One problem with using the combining marks in file formats is that they, well, combine! So, it may be difficult to see them as separate entities unless you insert a no-break space (U+00A0) or space (U+0020) in front of them. UnicodeMath allows a no-break space to appear between the base and accent since UnicodeMath is used as an input format as well as in files. Only programmers need to look at most file formats (HTML, MathML, OMML, RTF), so a reliable standard is more important for file formats than user-friendly presentation.

MathML 3’s operator dictionary defines most horizontal arrows with the “accent” property. In addition, it defines the following accents

02C6      ˆ              modifier letter circumflex accent

02C7      ˇ              caron

02C9      ˉ              modifier letter macron

02CA     ˊ              modifier letter acute accent

02CB     ˋ              modifier letter grave accent

02CD     ˍ              modifier letter low macron

02D8     ˘              breve

02D9     ˙              dot above

02DA     ˚              ring above

02DC     ˜             small tilde

02DD     ˝             double acute accent

02F7      ˷             modifier letter low tilde

0302        ̂             combining circumflex accent

0311        ̑             combining inverted breve

Presumably the operator dictionary should be extended to include more math combining marks and their equivalents, if they exist, with the spacing diacritics in the range U+02C6..U+02DD.

Here’s the MathML for the math object 𝑎̂.

<mml:mover accent="true">

mm<mml:mi>a</mml:mi>

mm<mml:mo>^</mml:mo>

</mml:mover>

 

Accents in OMML

“Office MathML” OMML is the XML used in Microsoft Office file formats to represent most math. It’s an XML version of the in-memory math object model which differs from MathML. The math accent object 𝑎̂ has the following OMML

<m:acc>
mm<m:accPr>
mmmm<m:chr m:val=" ̂"/>
mmmm<m:ctrlPr/>
mm</m:accPr>
mm<m:e>
mmmm<m:r>
mmmmmm<m:t>𝑎</m:t>
mmmm</m:r>
mm</m:e>
</m:acc>

The Rich Text Format (RTF) represents math zones essentially as OMML written in RTF syntax. Regular RTF uses the \uN notation for Unicode characters not in the current code page. The math accent object 𝑎̂ has the RTF

{\macc{\maccPr{\mctrlPr\i\f0\fs20 }{\mchr \u770? }}{\me\i\u-10187?\u-9138?}}

Unicode RTF is easier to read since characters are written in Unicode

{\macc{\maccPr{\mctrlPr\i\f0\fs20 }{\mchr  ̂}}{\me\i 𝑎}}

But none of these is as simple as the UnicodeMath 𝑎 ̂ ☺.

 

 

 

Re: [math-on-web] CG meeting minutes, 2018/03/30 and 2018/03/15

Source: public-mathonwebpages@w3.org Mail Archives • Arno Gourdol (arno@arno.org) • March 30, 2018 • Permalink

Thanks, Moritz, for the great discussion and for the fascinating work
you've been doing. Great paper, and really interesting idea to decorate
parsed expressions with wikidata info. Also, the Gold Standard data set
you've produced is wonderful.

Incidentally, the Riemann Hypothesis example you mention in your paper
(\zeta (s)=0\Rightarrow \Re  s=\frac12\lor \Im  s=0) does get parsed
correctly in MathLive to MASTON:

{"lhs":{"lhs":{"fn":"Zeta","arg":"s"},"op":"=","rhs":0},"op":"=>","rhs":{
   "lhs":{"lhs":{"fn":"Re","arg":"s"},"op":"=","rhs":{"num":"1/2"}},
 "op":"or",    "rhs":{"lhs":{"fn":"Im","arg":"s"},"op":"=","rhs":0}}}


It would be even better if it was decorated with Wikidata :) and there are
many expressions in the dataset that would not be parsed currently: the
transformation from a presentation representation to MASTON is a work in
progress and your dataset will be immensely useful to achieve a better
quality.

Incidentally, this expression would not parse correctly by following the
operator priority rules specified in
https://www.w3.org/TR/MathML3/appendixc.html since according to this, the
priority of '=' is 260 and '⇒' is 270.

Best,
Arno.


On Thu, Mar 29, 2018 at 6:07 PM, Peter Krautzberger <peter@krautzource.com>
wrote:

> Hi everyone,
>
> Today's minutes as well as the previous (which had been very short so I
> forgot to post them -- sorry).
>
> The next meeting is April 12, noon (Eastern).
>
> Best,
> Peter.
>
>
> # MathOnWeb CG 2018-03-30
>
> * Present: Moritz, Arno, John
> * Regrets: Volker, Dani
>
> * Arno: finding a serializable representation
>   * did it because I needed it, get semantics from formula to eval,
> process etc
>   * looked around for standard representation
>   * not so much visual representation (have others)
>   * thus the post
> * Neil: capturing semantic information in a tree (or else) is a great topic
>   * serialization is not important, comes later
>   * I'd like to focus on the contents of the tree
> * Arno: I agree content is kind but form matters
>   * if you need to work on tree that requires a bunch of libs to process,
> that does not make it easy
>   * something that serializes in a standard way would make it easier for
> libraries, to improve exchange between libraries
> * Neil: great goal but we haven't really achieved it
>   * openmath kind of does that but isn't really usable (outside research
> into the format)
>   * Arno: agreed
>   * parts of openmath community wanted CAS representations that work
> across systems
>     * didn't work because e.g., mathematica and maple disagree on
> implementation
> * Arno: today they exchange on the presentation layer
>   * e.g., Mathematica and Maple exchange TeX/MathML etc
>   * seems like we can do better
>   * Neil: true but you can't capture everything
>   * Arno: exactly. But if we can exchange something that's better than
> nothing
> * Neil: they can do something using MathML etc
>   * ContentMML and openmath are not rich enough
>   * I think you'll have to be careful how you map things out
>   * how far do you want to go
>   * e.g., once you get to branch cuts, systems do it differently and
> things fall apart
>   * Arno: falling apart seems extreme point of view
> * Neil: some cut off point may be possible (e.g., high school)
>   * but people don't seem ready to write
> * Arno: in a symbolic system, they want to enter the information
>   * but if not, then not.
>   * we have a bunch of systems that do things differently, different
> heuristics etc
>   * those systems are multiplying, they are using their output but not
> sharing them at all
> * Arno: e.g., my post mentioned MathJS
>   * converting to their structure worked ok
>   * but most people use a string input, then MathJS does its own parser,
> assumptions about invisible times etc, then computation
>   * so MathJS has to do that work, every other lib does the same.
>   * users can't exchange anything, can't get consistent result
>   * but there's
> * Peter: I mostly deal with conceptual not procedural but this discussion
> reminds me of a related problem in AT
>   * heuristics go haywire a lot without a way for authors to fix them
> * Neil: heuristics are often 99%
>   * semantics would be great but people are not authoring
> * Peter: from a conceptual way, you could fix those with interest
>   * paving cow paths to improve heuristics would be reasonalbe there
>   * not sure about how procedural info could be used that
> * Arno: in TeX you have macros etc
>   * those are similar and could be leverage
> * Peter: I had a discussion about components at a workshop last week
>   * remembering many conversations about templating in (MathML) editors,
> publishers struggling
>   * the web has this of course, not just web components but just regular
> components
> * Moritz: exposing and transferring extra information is hard
>   * example from work with grad students
>   * leveragin external information is important
>   * this example gets you to wikidata
>   * linked data can then take you further
>   * however you're using and storing data, use a common dictionary
>   * wikidata is a good dictionary, good to use, link and modify
>   * http://vmext.wmflabs.org/ASTRenderer
> * Moritz: we also analyzed  MathML convertors that can capture semantics
>   * few that could (somehow) describe content mathml
>   * analyzed them further
>   * this project will continue for a few years (since it's Phd projects)
>   * accepted paper: https://www.overleaf.com/13063311bcsyrtvqrdry#/
> 50123989/
>   * Arno: this looks very interesting
> * Peter: linked data should be a major consideration in any of this, also
> for subject/content metadata
> * Arno: I had only found a few dictionaries
>   * open math, proof wiki
>     * not sure how related
>     * Moritz: not sure; they don't seem connected to any wikibase
> * Moritz: the good thing about wikidata is that there are actually users
>   * this was rather nice compared to other math projects which usually
> have few participants and then the lead left and it died
>   * wikidata has thousands of contirubto
>   * Peter: background on terms?
>   * Moritz: wikidata is displayed via a MediaWiki instance
>     * but wikibase is the data repository that drives wikidata (as a data
> platform)
> * Peter: random question: are SI units represented?
>   * Moritz: yes but it's complicated
>     * e.g., https://www.wikidata.org/wiki/Q11379 for energy
>     * has quality allows you to go past has attribute (which requires
> community vote, you'll have to model that on your end)
>     * with has quality, you can refer to an item which you can add to
> wikidata yourself (anything you can model in a triple store)
> * Peter: just a quick word on the workshop since we're out of time
>   * https://aimath.org/workshops/upcoming/webmath/
>   * many of the CG will be there
>   * AT vendors, a11y experts, publishers, actual mathematicians etc
>   * should give us a lot of input for future work
>
>
> # MathOnWeb 2018-03-15
>
> Present: Arno, Peter
> Regrets: Neil, Dani, Volker
>
> * Arno: working on abstract syntax tree for mathlive
>     * data structure to be parsed and computed on
>   * open question as to in how far I could infer semantics from LaTeX
>   * putting together a spec, hoping for feeback
>   * that might be something interesting for interop
> * Peter: mathquill etc were interested early on
>   * Arno: Kevin had reached out but was skeptical due to the
> expressiveness of LaTeX
>     * I'll post a link to the spec after the meeting
> * Peter: related: heuristics of AT are a mess
>   * I wouldn't even mind if we agreed to them
>   * but that would break a lot of existing content
> * Arno: different fields have different customs, too
>   * Peter: agreed. It seems more likely to handle this via enrichment into
> some broader semantic framework
> * Peter: I was recently looking at MathJax's PreviewHTML output again
>   * it's really quite nice from a pure-CSS perspective
>   * and so easy to tweak the output
> * Arno: I was surprised how much font-independence I got in mathlive
>   * many element styles are constants (e.g., variable margin)
>   * http://mathlive.io/?debug=on shows some of the output
>
>

Operator priority

Source: www-math@w3.org Mail Archives • Arno Gourdol (arno@arno.org) • March 30, 2018 • Permalink

According to the (non-normative) information at
https://www.w3.org/TR/MathML3/appendixc.html, the expression:

    *a* = *b* ⇒ *b* = *c*

should be parsed as

    *a* = (*b* ⇒ *b* = *c*)

since = has a priority of 260 and ⇒ a priority of 270.

Similarly, all the arrows have the same priority, so that

    P → Q ⇎ Q → P

would not parse as

    (P → Q) ⇎ (Q → P)

as one might expect.

What was the rationale behind these priority values?

Best,
Arno.

[math-on-web] CG meeting minutes, 2018/03/30 and 2018/03/15

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • March 30, 2018 • Permalink

Hi everyone,

Today's minutes as well as the previous (which had been very short so I
forgot to post them -- sorry).

The next meeting is April 12, noon (Eastern).

Best,
Peter.


# MathOnWeb CG 2018-03-30

* Present: Moritz, Arno, John
* Regrets: Volker, Dani

* Arno: finding a serializable representation
  * did it because I needed it, get semantics from formula to eval, process
etc
  * looked around for standard representation
  * not so much visual representation (have others)
  * thus the post
* Neil: capturing semantic information in a tree (or else) is a great topic
  * serialization is not important, comes later
  * I'd like to focus on the contents of the tree
* Arno: I agree content is kind but form matters
  * if you need to work on tree that requires a bunch of libs to process,
that does not make it easy
  * something that serializes in a standard way would make it easier for
libraries, to improve exchange between libraries
* Neil: great goal but we haven't really achieved it
  * openmath kind of does that but isn't really usable (outside research
into the format)
  * Arno: agreed
  * parts of openmath community wanted CAS representations that work across
systems
    * didn't work because e.g., mathematica and maple disagree on
implementation
* Arno: today they exchange on the presentation layer
  * e.g., Mathematica and Maple exchange TeX/MathML etc
  * seems like we can do better
  * Neil: true but you can't capture everything
  * Arno: exactly. But if we can exchange something that's better than
nothing
* Neil: they can do something using MathML etc
  * ContentMML and openmath are not rich enough
  * I think you'll have to be careful how you map things out
  * how far do you want to go
  * e.g., once you get to branch cuts, systems do it differently and things
fall apart
  * Arno: falling apart seems extreme point of view
* Neil: some cut off point may be possible (e.g., high school)
  * but people don't seem ready to write
* Arno: in a symbolic system, they want to enter the information
  * but if not, then not.
  * we have a bunch of systems that do things differently, different
heuristics etc
  * those systems are multiplying, they are using their output but not
sharing them at all
* Arno: e.g., my post mentioned MathJS
  * converting to their structure worked ok
  * but most people use a string input, then MathJS does its own parser,
assumptions about invisible times etc, then computation
  * so MathJS has to do that work, every other lib does the same.
  * users can't exchange anything, can't get consistent result
  * but there's
* Peter: I mostly deal with conceptual not procedural but this discussion
reminds me of a related problem in AT
  * heuristics go haywire a lot without a way for authors to fix them
* Neil: heuristics are often 99%
  * semantics would be great but people are not authoring
* Peter: from a conceptual way, you could fix those with interest
  * paving cow paths to improve heuristics would be reasonalbe there
  * not sure about how procedural info could be used that
* Arno: in TeX you have macros etc
  * those are similar and could be leverage
* Peter: I had a discussion about components at a workshop last week
  * remembering many conversations about templating in (MathML) editors,
publishers struggling
  * the web has this of course, not just web components but just regular
components
* Moritz: exposing and transferring extra information is hard
  * example from work with grad students
  * leveragin external information is important
  * this example gets you to wikidata
  * linked data can then take you further
  * however you're using and storing data, use a common dictionary
  * wikidata is a good dictionary, good to use, link and modify
  * http://vmext.wmflabs.org/ASTRenderer
* Moritz: we also analyzed  MathML convertors that can capture semantics
  * few that could (somehow) describe content mathml
  * analyzed them further
  * this project will continue for a few years (since it's Phd projects)
  * accepted paper: https://www.overleaf.com/13063311bcsyrtvqrdry#/50123989/
  * Arno: this looks very interesting
* Peter: linked data should be a major consideration in any of this, also
for subject/content metadata
* Arno: I had only found a few dictionaries
  * open math, proof wiki
    * not sure how related
    * Moritz: not sure; they don't seem connected to any wikibase
* Moritz: the good thing about wikidata is that there are actually users
  * this was rather nice compared to other math projects which usually have
few participants and then the lead left and it died
  * wikidata has thousands of contirubto
  * Peter: background on terms?
  * Moritz: wikidata is displayed via a MediaWiki instance
    * but wikibase is the data repository that drives wikidata (as a data
platform)
* Peter: random question: are SI units represented?
  * Moritz: yes but it's complicated
    * e.g., https://www.wikidata.org/wiki/Q11379 for energy
    * has quality allows you to go past has attribute (which requires
community vote, you'll have to model that on your end)
    * with has quality, you can refer to an item which you can add to
wikidata yourself (anything you can model in a triple store)
* Peter: just a quick word on the workshop since we're out of time
  * https://aimath.org/workshops/upcoming/webmath/
  * many of the CG will be there
  * AT vendors, a11y experts, publishers, actual mathematicians etc
  * should give us a lot of input for future work


# MathOnWeb 2018-03-15

Present: Arno, Peter
Regrets: Neil, Dani, Volker

* Arno: working on abstract syntax tree for mathlive
    * data structure to be parsed and computed on
  * open question as to in how far I could infer semantics from LaTeX
  * putting together a spec, hoping for feeback
  * that might be something interesting for interop
* Peter: mathquill etc were interested early on
  * Arno: Kevin had reached out but was skeptical due to the expressiveness
of LaTeX
    * I'll post a link to the spec after the meeting
* Peter: related: heuristics of AT are a mess
  * I wouldn't even mind if we agreed to them
  * but that would break a lot of existing content
* Arno: different fields have different customs, too
  * Peter: agreed. It seems more likely to handle this via enrichment into
some broader semantic framework
* Peter: I was recently looking at MathJax's PreviewHTML output again
  * it's really quite nice from a pure-CSS perspective
  * and so easy to tweak the output
* Arno: I was surprised how much font-independence I got in mathlive
  * many element styles are constants (e.g., variable margin)
  * http://mathlive.io/?debug=on shows some of the output

Re: [MathOnWeb] reminder: meeting March 29

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • March 30, 2018 • Permalink

Oh! I just saw this. So sorry Charles!

FWIW, there was consensus to look for a more reliable setup for the calls.

Best,
Peter.

2018-03-29 18:13 GMT+02:00 Charles LaPierre <charlesl@benetech.org>:

> sorry everyone,
> I tried to connect to Google Hangouts and it just hangs.  Not sure what is
> going on.
>
> Thanks
> EOM
>
> Charles LaPierre
> Technical Lead, DIAGRAM and Born Accessible
> E-mail: charlesl@benetech.org <charlesl@benetech.org>
> Twitter: @CLaPierreA11Y
> Skype: charles_lapierre
> Phone: 650-600-3301 <(650)%20600-3301>
>
>
>
> On Mar 28, 2018, at 12:18 PM, Peter Krautzberger <peter@krautzource.com>
> wrote:
>
> Hi everyone,
>
> Just a quick reminder that we're meeting on March 29 at noon Eastern time
> at the usual Hangouts URL.
>
> Agenda items below -- feel free to add here or later.
>
> Best,
> Peter.
>
> Agenda
>
> * Arno's JSON proposal
> * updates from CSS TF
> * accessibility workshop in May
>
>
>

Re: [MathOnWeb] reminder: meeting March 29

Source: public-mathonwebpages@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • March 29, 2018 • Permalink

sorry everyone,
I tried to connect to Google Hangouts and it just hangs.  Not sure what is going on.

Thanks
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org<mailto:charlesl@benetech.org>
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301



On Mar 28, 2018, at 12:18 PM, Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>> wrote:

Hi everyone,

Just a quick reminder that we're meeting on March 29 at noon Eastern time at the usual Hangouts URL.

Agenda items below -- feel free to add here or later.

Best,
Peter.

Agenda

* Arno's JSON proposal
* updates from CSS TF
* accessibility workshop in May

Re: A proposal for a computer readable mathematical object notation

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • March 29, 2018 • Permalink

I think this discussion is very valuable since the preferred way today
seems to be to develop an abstract data model and then talk about
serializations; cf. the work in nthe Annotation and POE WGs. From a
semantic point of view, I also consider the problem of expressing
layout+semantics simultaneously as critical, especially in a fashion that
is independent of the rendition.

Neil wrote:
> No one wants to type in an editor and say "this 'x' is a real valued
number" just so that some evaluation down the line knows how it interacts
with some other variable. Indeed, people don't event want to say whether
h(x+y) is function application or multiplication. Computational systems
solve that problem because their syntax defines what is meant. Neither TeX
nor most WYSIWYG editors provide that information in general.

I see two problems with this statement.

On the one hand, where's the data? My experience is that authors very much
do want to express this "x is a real valued number".

On the other hand, why don't they? In my experience, the dominant problem
here is print. Presentation MathML was designed to capture print layout
traditions of equational content; it does this very well but is not suited
to do much beyond that. From what I've gathered from its history, MathML
was also heavily influenced by the needs of the publishing industry (since
its success rests there) and authors working with publishing entities
generally think only of print (since publishers alas still do).
Accordingly, authoring tools generally lack the means to express semantic
information (efficiently).

Most importantly, there is little incentive for expressing more than purely
visual information while authoring for print (mainly, convenience such as
macros or templates). The web changes this on a fundamental level; writing
a component that expresses a thought both visually and rich in semantics is
perfectly feasible and the means of expression for both is vastly expanded.
I'm very interested in anything that helps move towards this.

Peter.

Re: A proposal for a computer readable mathematical object notation

Source: public-mathonwebpages@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • March 29, 2018 • Permalink

Sorry to be so slow to answer, but between travel and a forgotten deadline
to get a paper done, I haven't had time to respond until now... and I only
have time to answer the higher level issues...

To begin with, JSON and XML *should* be equivalent in what they can
represent. I find it surprising that the standard json representation
messes up ordering. Many people including Volker feel this as a mistake (or
at least not useful) and it is easy to find libraries that preserve order
by using arrays instead of objects. Given one of those, it is trivial to
convert MathML to a json format that makes evaluation basically as trivial
as the example Arno showed. The difference is that array indexing is used
instead of keys. If we get past the (IMHO) irrelevant issue of JSON vs XML,
you can move to what the tree should have to represent the expression.
That's where you end up with differences in all the programs that parse
AsciiMath, TeX, MathML, etc -- everyone has a different idea of what info
they want to have in that internal tree. E.g., an editor probably wants to
keep around some positional information where as something that generates
speech would not.

I haven't looked in detail about what info SRE adds, but looking at a
simple example from Volker's site I can see there is a mixture of semantic
and presentation information, along with ids that perhaps allow for
something richer than a tree.

To respond to Han: the problem with most math that is encountered in
documents (including web pages) is that it was entered by the author
without adding semantic information. No one wants to type in an editor and
say "this 'x' is a real valued number" just so that some evaluation down
the line knows how it interacts with some other variable. Indeed, people
don't event want to say whether h(x+y) is function application or
multiplication. Computational systems solve that problem because their
syntax defines what is meant. Neither TeX nor most WYSIWYG editors provide
that information in general. Somehow, humans mostly figure meaning out when
they read an expression. Using various patterns and context, MathPlayer's
speech rules and Volker's work take a few steps in that direction. It's not
easy though and having a library call that everyone could use would be
really useful. But that leads one back to my basic point -- what should be
in the tree that is built?

    Neil


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

On Fri, Mar 23, 2018 at 9:40 PM, Arno Gourdol <arno.gourdol@gmail.com>
wrote:

> Great feedback! Comments below inline.
>
>
> On Mar 22, 2018, at 11:26 AM, Neil Soiffer <soiffer@alum.mit.edu> wrote:
>
> I think the situation you describe about interchange is not anywhere near
>> as bad as you think. Most math programs will except TeX or MathML as input
>> and can do computation with them (at least Mathematica and Maple do so with
>> MathML, and I think also TeX). Part of the reason those programs can do so
>> is because they already have a linear syntax and so inferring a bit of
>> additional information is not that bad.
>>
>
> Indeed. I’m not suggesting that for Mathematica of Maple these are
> problems. Those guys have probably already solved everything! :)
>
> But think of the little guys! Think of the mathematician, the physicist or
> even the high school student who wants to write their own math software on
> the web, using the tools of the web. Let’s say they want to do some
> symbolic manipulation. Perhaps comparing two formulas. Or indexing them and
> searching them. Or implementing some numeric algorithm.
>
> The first step they would have to do would be to transform the input, be
> it MathML, TeX or ASCIIMath, into something that can be computed upon. That
> involves transforming a linear stream of tokens into a structured
> mathematical representation. And indeed today, every single math related
> software library does that. I even do it three times in MathLive (once to
> convert to speech, once to convert to MathML and once to convert to MASTON.
> If I had been smarter, I would have started by converting to MASTON first
> and having a single set of consistent rules on how to interpret the input
> stream).
>
> Not only is there tremendous wasted effort, but the results are
> inconsistent, as different rules are implemented to do the conversion from
> the ambiguous token stream. I believe the ambiguity should be solved once,
> when the formula is created, which seems to be the best time because:
> 1/ the user is available then to clearly communicate their intent
> 2/ the formula will be created once, but consumed many times
>
>
> As an example, there’s a large portion of MathJS which is spent parsing a
> pseudo-MathASCII syntax into something they can actually compute on.
> Wouldn’t it be nice if they could focus on the computing aspect, rather
> than having to implement yet another parser that may or may not have the
> implicit rules you expect (is “2 1/2” 2.5 or 1?).
>
> As for your proposal, I don't see what it adds that "properly" structured
>> MathML doesn't already provide. My properly structured MathML, I mean
>> MathML where the mrows reflect the abstract syntax of the mathematical
>> expression. E.g, for a binary infix operator, the first element in the mrow
>> will be an operand, the second the infix operator, and the third an
>> operand. If the second operator is a relational operator such as '=', then
>> the lhs is the first element and the rhs is the third element. The elements
>> might be leaf nodes such as mi's or complicated expressions inside mrows.
>> MathPlayer does this to infer semantics as does (I think) Volker's Speech
>> Rule Engine.
>>
>
> It seems to me that there’s quite a bit that needs to be clarified about
> what is a “properly” structured MathML. Perhaps there is a specification
> for that somewhere? I assume it would restrict things like
> *<mn>twenty-one</mn>* and* <mn>XXI</mn>*? If such a thing exist, modulo
> the label on the keys of the object, I believe you would indeed probably
> end up with something like MATSON. In that case, just consider it an
> attempt at actually documenting this :)
>
>
> {  "mrow": {    "msup": {      "mi": "ⅇ",      "mrow": {"mi": ["ⅈ","π"],"mo": "⁢"}    },    "mo": "+",    "mn": "1"  },  "mo": "=",  "mn": "0"}
>>
>>
>
> I believe that having a JSON format is really important. XML applications
> may be wonderful, but they are still a major pain to parse. Here’s the
> complete implementation of a four-operation calculator on a MATSON
> structure:
>
> function evaluate(ast) {
> if (!ast) return NaN;
> if (typeof ast === 'number') return ast;
> if (ast.num !== undefined) return evaluate(ast.num);
> if (typeof ast === 'string') {
> if (ast === 'π') return Math.PI;
> return parseFloat(ast);
> }
> if (ast.op === '*') {
> return evaluate(ast.lhs) * evaluate(ast.rhs);
> } else if (ast.op === '/') {
> return evaluate(ast.lhs) / evaluate(ast.rhs);
> } else if (ast.op === '-') {
> return evaluate(ast.lhs) - evaluate(ast.rhs);
> } else if (ast.op === '+') {
> return evaluate(ast.lhs) + evaluate(ast.rhs);
> }
> return NaN;
> }
>
>
> I shudder to think of writing the same thing on a MathML tree, even a
> ‘canonical’ one.
>
> That said, the mapping of MathML to JSON is not completely
> straightforward. MathML has made some choices that work well in a XML
> environment, but are just really difficult to translate in a JSON
> structure. For example, what would be the JSON version of
> *“<mi>x</mi><mo>=</mo><mi>y</mi>*”? You can’t have two identical keys in
> the same object, so it can’t be:
>
> {
>     "mi": "x",
>     "mo": "=",
> "mi": "y"       // second “mi” key! Can’t have that.
> }
>
>
>
> You can’t rely on the order of the keys to figure out what is the lhs and
> the rhs on an operator. So, you need something a bit more structured. I
> think if you work this through, you would indeed land on something close to
> MATSON. I’d be happy to call it “MathML for JSON” if that helps :)
>
>
> Note: although many operators such as '=' are formally binary infix
>> operators, in practice, they are better treated as n-ary operators because
>> they often are used as "a = b = c" or even "a = b <= c = d" and both layout
>> and computation are often easier when all are at the same level.
>>
>
> That is a great point. I’ve been debating this, and had erred on the side
> of keeping things as simple as possible, but I can see that point.
>
> BTW, I can see this working well for associative operations (addition,
> multiplication, maybe equality), but how would this work in the example
> where you have different relational operators?
>
>
> I believe several people have tried at various times to formulate a
>> "canonical MathML" format that includes properly structured mrows, one of
>> the canonical Unicode forms, and fixing up pseudo scripts
>> <https://www.w3.org/TR/MathML3/chapter7.html#chars.pseudo-scripts> among
>> some other things. Note that proper mrow nesting depends upon guessing
>> between function call and multiplication if the author didn't indicate
>> which to use (e.g, in MathML, one should use the invisible operators), so
>> the parsing can be complicated. Of course, parsing alone doesn't provide
>> semantics. I believe that Volker adds some attribute that is equivalent to
>> adding something like a "mathrole" to various elements to specify semantics
>> -- some "obvious", some derived from other context, etc.
>>
>> I think it would be helpful to develop a tool that anyone can incorporate
>> to produce canonical MathML.
>>
>
> Well, maybe this is yet another attempt at defining this canonical MathML,
> in an easy to parse JSON format. I don’t want to reinvent the wheel, so if
> there are things that exist out there, I’d be more than happy to at least
> start from them (maybe I just need to JSON-ify one of those forms).
>
>
> On Mar 23, 2018, at 11:22 AM, Han <laughinghan@gmail.com> wrote:
>
> Do those "Most math programs" actually output this restricted, "properly"
> structured MathML? To me, the value in something like MASTON is not what it
> *adds* over MathML, it's what it *removes*. Volker's Speech Rule Engine
> is a whole project unto itself at least in part because inferring structure
> from MathML that ChromeVox encounters "in the wild" is so hard, no? That's
> also why Content MathML and OpenMath exist, because people have seen the
> need for this information to be part of the data structure and not have to
> be inferred, before. (I would be curious to hear if Arno considered those?)
>
>
> Yes, I did consider Content MathML. But as per above, I really wanted
> something that would be much easier to consume, and for me that meant
> having a JSON-based format. OpenMath seems interesting, but far from
> lightweight, and it’s also an XML application.
>
>
> (Disclaimer: I specced out and built a toy parser for a JSON format for
> display math, analogous to TeX and Presentation MathML but in contrast to
> MASTON and Content MathML and OpenMath, that I called MathSON
> <https://gist.github.com/laughinghan/4350e4438e6cfc951826>. I haven't
> decided if it's any good.)
>
>
> I can see some similarities (convergent evolution!) but also some
> differences. It seems that MathSON would be suitable as an internal data
> structure to represent and manipulate a formula while being edited. For
> example, you still have some string of tokens, while I believe that the
> relationship between tokens (be it multiplication, function application or
> what have you) should be resolved by the producer of the data structure, so
> that the consumers don’t have to ‘guess’. Frankly, I don’t know if the same
> data structure can be used for editing and for semantic representation. In
> particular you would have to deal with the tricky problem of representing
> selection range that cross semantic structures. Dunno, maybe there’s a way
> to bridge that gap… Still would be nice if MathQuill could at least output
> to MATSON :)
>
> Best,
> Arno.
>
>
>
>

Re: A proposal for a computer readable mathematical object notation

Source: public-mathonwebpages@w3.org Mail Archives • Volker Sorge (V.Sorge@cs.bham.ac.uk) • March 28, 2018 • Permalink

Hi,

I am afraid I can't make tomorrow's meeting, I am travelling. So just
some brief points here:

SRE does indeed rewrite MathML into it's internal tree format, which
is somewhat more semantic and can be turned into XML for rule
applications (they use XPath).
I have exposed that format some time ago as JSON, after a request on
github. I have a visualiser for that tree that can be helpful, at
least when tinkering with heuristics. Have a look at
https://zorkow.github.io/semantic-tree-visualiser/visualise.html
For the benefit of this discussion I have added a JSON radio button,
so it can be displayed at the end of the page. You can play around
with your favourite LaTeX or MathML expressions.

I originally used the standard(*) JSON format for XML, that most
libraries will give you, i.e, the one that maps multiple elements with
the same tag to an array, as Arno has used in his example.
[(*) I am not sure if that is really standard, but Google uses it for
most of their APIs. So it is somewhat quasi-standard.]
But since order is important in my case, it did not really cut the
mustard and I started using my own format and parser a while ago. So
the format now serves as a proper linearisation of the internal tree
as well as the XML structure (i.e., type is the tag name). It is a
one-to-one mapping and I can use it to reconstruct the internal
semantic tree structure, barring references to the original MathML.

Best,
Volker



---------------
Dr Volker Sorge
Reader in Scientific Document Analysis
School of Computer Science
University of Birmingham, B15 2TT, UK
www.cs.bham.ac.uk/~vxs
+44-121-414-3746


On 24 March 2018 at 04:40, Arno Gourdol <arno.gourdol@gmail.com> wrote:
> Great feedback! Comments below inline.
>
>
> On Mar 22, 2018, at 11:26 AM, Neil Soiffer <soiffer@alum.mit.edu> wrote:
>>
>> I think the situation you describe about interchange is not anywhere near
>> as bad as you think. Most math programs will except TeX or MathML as input
>> and can do computation with them (at least Mathematica and Maple do so with
>> MathML, and I think also TeX). Part of the reason those programs can do so
>> is because they already have a linear syntax and so inferring a bit of
>> additional information is not that bad.
>
>
> Indeed. I’m not suggesting that for Mathematica of Maple these are problems.
> Those guys have probably already solved everything! :)
>
> But think of the little guys! Think of the mathematician, the physicist or
> even the high school student who wants to write their own math software on
> the web, using the tools of the web. Let’s say they want to do some symbolic
> manipulation. Perhaps comparing two formulas. Or indexing them and searching
> them. Or implementing some numeric algorithm.
>
> The first step they would have to do would be to transform the input, be it
> MathML, TeX or ASCIIMath, into something that can be computed upon. That
> involves transforming a linear stream of tokens into a structured
> mathematical representation. And indeed today, every single math related
> software library does that. I even do it three times in MathLive (once to
> convert to speech, once to convert to MathML and once to convert to MASTON.
> If I had been smarter, I would have started by converting to MASTON first
> and having a single set of consistent rules on how to interpret the input
> stream).
>
> Not only is there tremendous wasted effort, but the results are
> inconsistent, as different rules are implemented to do the conversion from
> the ambiguous token stream. I believe the ambiguity should be solved once,
> when the formula is created, which seems to be the best time because:
> 1/ the user is available then to clearly communicate their intent
> 2/ the formula will be created once, but consumed many times
>
>
> As an example, there’s a large portion of MathJS which is spent parsing a
> pseudo-MathASCII syntax into something they can actually compute on.
> Wouldn’t it be nice if they could focus on the computing aspect, rather than
> having to implement yet another parser that may or may not have the implicit
> rules you expect (is “2 1/2” 2.5 or 1?).
>
>> As for your proposal, I don't see what it adds that "properly" structured
>> MathML doesn't already provide. My properly structured MathML, I mean MathML
>> where the mrows reflect the abstract syntax of the mathematical expression.
>> E.g, for a binary infix operator, the first element in the mrow will be an
>> operand, the second the infix operator, and the third an operand. If the
>> second operator is a relational operator such as '=', then the lhs is the
>> first element and the rhs is the third element. The elements might be leaf
>> nodes such as mi's or complicated expressions inside mrows. MathPlayer does
>> this to infer semantics as does (I think) Volker's Speech Rule Engine.
>
>
> It seems to me that there’s quite a bit that needs to be clarified about
> what is a “properly” structured MathML. Perhaps there is a specification for
> that somewhere? I assume it would restrict things like <mn>twenty-one</mn>
> and <mn>XXI</mn>? If such a thing exist, modulo the label on the keys of the
> object, I believe you would indeed probably end up with something like
> MATSON. In that case, just consider it an attempt at actually documenting
> this :)
>
>
>> {
>>   "mrow": {
>>     "msup": {
>>       "mi": "ⅇ",
>>       "mrow": {"mi": ["ⅈ","π"],"mo": "⁢"}
>>     },
>>     "mo": "+",
>>     "mn": "1"
>>   },
>>   "mo": "=",
>>   "mn": "0"
>> }
>
>
>
> I believe that having a JSON format is really important. XML applications
> may be wonderful, but they are still a major pain to parse. Here’s the
> complete implementation of a four-operation calculator on a MATSON
> structure:
>
> function evaluate(ast) {
> if (!ast) return NaN;
> if (typeof ast === 'number') return ast;
> if (ast.num !== undefined) return evaluate(ast.num);
> if (typeof ast === 'string') {
> if (ast === 'π') return Math.PI;
> return parseFloat(ast);
> }
> if (ast.op === '*') {
> return evaluate(ast.lhs) * evaluate(ast.rhs);
> } else if (ast.op === '/') {
> return evaluate(ast.lhs) / evaluate(ast.rhs);
> } else if (ast.op === '-') {
> return evaluate(ast.lhs) - evaluate(ast.rhs);
> } else if (ast.op === '+') {
> return evaluate(ast.lhs) + evaluate(ast.rhs);
> }
> return NaN;
> }
>
>
> I shudder to think of writing the same thing on a MathML tree, even a
> ‘canonical’ one.
>
> That said, the mapping of MathML to JSON is not completely straightforward.
> MathML has made some choices that work well in a XML environment, but are
> just really difficult to translate in a JSON structure. For example, what
> would be the JSON version of “<mi>x</mi><mo>=</mo><mi>y</mi>”? You can’t
> have two identical keys in the same object, so it can’t be:
>
> {
>     "mi": "x",
>     "mo": "=",
> "mi": "y"       // second “mi” key! Can’t have that.
> }
>
>
>
> You can’t rely on the order of the keys to figure out what is the lhs and
> the rhs on an operator. So, you need something a bit more structured. I
> think if you work this through, you would indeed land on something close to
> MATSON. I’d be happy to call it “MathML for JSON” if that helps :)
>
>
>> Note: although many operators such as '=' are formally binary infix
>> operators, in practice, they are better treated as n-ary operators because
>> they often are used as "a = b = c" or even "a = b <= c = d" and both layout
>> and computation are often easier when all are at the same level.
>
>
> That is a great point. I’ve been debating this, and had erred on the side of
> keeping things as simple as possible, but I can see that point.
>
> BTW, I can see this working well for associative operations (addition,
> multiplication, maybe equality), but how would this work in the example
> where you have different relational operators?
>
>
>> I believe several people have tried at various times to formulate a
>> "canonical MathML" format that includes properly structured mrows, one of
>> the canonical Unicode forms, and fixing up pseudo scripts among some other
>> things. Note that proper mrow nesting depends upon guessing between function
>> call and multiplication if the author didn't indicate which to use (e.g, in
>> MathML, one should use the invisible operators), so the parsing can be
>> complicated. Of course, parsing alone doesn't provide semantics. I believe
>> that Volker adds some attribute that is equivalent to adding something like
>> a "mathrole" to various elements to specify semantics -- some "obvious",
>> some derived from other context, etc.
>>
>> I think it would be helpful to develop a tool that anyone can incorporate
>> to produce canonical MathML.
>
>
> Well, maybe this is yet another attempt at defining this canonical MathML,
> in an easy to parse JSON format. I don’t want to reinvent the wheel, so if
> there are things that exist out there, I’d be more than happy to at least
> start from them (maybe I just need to JSON-ify one of those forms).
>
>
> On Mar 23, 2018, at 11:22 AM, Han <laughinghan@gmail.com> wrote:
>
> Do those "Most math programs" actually output this restricted, "properly"
> structured MathML? To me, the value in something like MASTON is not what it
> adds over MathML, it's what it removes. Volker's Speech Rule Engine is a
> whole project unto itself at least in part because inferring structure from
> MathML that ChromeVox encounters "in the wild" is so hard, no? That's also
> why Content MathML and OpenMath exist, because people have seen the need for
> this information to be part of the data structure and not have to be
> inferred, before. (I would be curious to hear if Arno considered those?)
>
>
> Yes, I did consider Content MathML. But as per above, I really wanted
> something that would be much easier to consume, and for me that meant having
> a JSON-based format. OpenMath seems interesting, but far from lightweight,
> and it’s also an XML application.
>
>
> (Disclaimer: I specced out and built a toy parser for a JSON format for
> display math, analogous to TeX and Presentation MathML but in contrast to
> MASTON and Content MathML and OpenMath, that I called MathSON. I haven't
> decided if it's any good.)
>
>
> I can see some similarities (convergent evolution!) but also some
> differences. It seems that MathSON would be suitable as an internal data
> structure to represent and manipulate a formula while being edited. For
> example, you still have some string of tokens, while I believe that the
> relationship between tokens (be it multiplication, function application or
> what have you) should be resolved by the producer of the data structure, so
> that the consumers don’t have to ‘guess’. Frankly, I don’t know if the same
> data structure can be used for editing and for semantic representation. In
> particular you would have to deal with the tricky problem of representing
> selection range that cross semantic structures. Dunno, maybe there’s a way
> to bridge that gap… Still would be nice if MathQuill could at least output
> to MATSON :)
>
> Best,
> Arno.
>
>
>

[MathOnWeb] reminder: meeting March 29

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • March 28, 2018 • Permalink

Hi everyone,

Just a quick reminder that we're meeting on March 29 at noon Eastern time
at the usual Hangouts URL.

Agenda items below -- feel free to add here or later.

Best,
Peter.

Agenda

* Arno's JSON proposal
* updates from CSS TF
* accessibility workshop in May

Publishing @ W3C goes to ebookcraft

Source: W3C Blog • Tzviya Siegman • March 28, 2018 • Permalink

For many of us who work with ebooks, the highlight of our year is ebookcraft in Toronto. ebookcraft is a two-day conference devoted to ebook production, sponsored by Booknet Canada. The fifth edition was held last week, and it was a veritable who’s who of Publishing @ W3C.

Why do we love ebookcraft? It’s full of “practical tips and forward-thinking inspiration.” It’s impeccably organized, by the wizardly Lauren Stewart and her team. It’s warm and welcoming. There are cookies. More than half the speakers are women. It really is about making beautiful, accessible ebooks. Of course, that requires standards. The ebook world has suffered more than most, with interoperability being a dream rather than a reality. Many of the presenters are involved with standards work at W3C.

The first day of ebookcraft was devoted to workshops, where longer talks and smaller audiences allow for in-depth coverage of various topics. Naomi Kennedy (Penguin Random House) kicked off the day speaking about “Images in Ebooks,” addressing approaches to format, size, and color with the ever-popular Bill the Cat.

Romain Deltour (DAISY) asked his audience “Is Your EPUB Accessible?” I found out that mine was almost there but not quite (and I wrote some of the specs he was featuring, uh-oh!). Romain walked us through concepts such as how information gets from HTML to the user, what assistive technologies are, how to figure out if your content has accessibility support, and how to test your files. Romain is one of the developers behind Ace by DAISY, a command-line program to check EPUBs for accessibility, and he did a demo for us. Ace by DAISY is based on the EPUB Accessibility 1.0 spec.

There was a panel over lunch called “Everybody’s Working on the Weekend,” about volunteerism in digital publishing. The panelists were from Booknet Canada, some of the wonderful planners of the conference. Many of them also devote their time to standards development at Booknet Canada and other organizations. When it was time for audience participation, it was pretty clear that publishing is a world of volunteers. Everyone wants to help, but there’s a serious shortage of time and resources, given busy day jobs. And standards work can be daunting at first—we need to find ways to gently welcome newcomers.

Deborah Kaplan picked up after lunch with ”WAI-ARIA in Practice.” She walked us through ARIA best practices, perhaps most importantly when NOT to use ARIA. She also opened our eyes to the wide world of keyboard navigation and gave us a hefty reading list for learning more.

Peter Krautzberger spoke about MathML: Equation Rendering in ebooks offered an overview of the options available for equational content in EPUB. We looked at equations in SVG and MathML and many options for making them accessible.

Conference organizer Laura Brady participated in a panel with the NNELS (National Network of Equitable Library Services) called “We Tear Apart Your Ebooks.” The panel discussed the NNELS open system for sharing accessible publications. Once a book is in the NNELS system, it can be shared throughout Canada. Authorized users request accessible publications, and the NNELS team works to make them accessible. Laura recently audited several publishers in Canada to assess their level of accessibility (really not that great) and trained them to get much better.

On Day 2, we shifted from workshops to the big room. Who better to kick off the day than Liisa McCloy-Kelley, co-chair of the Publishing Business Group? Liisa’s topic was “Laser Focus: Don’t Get Distracter by that Shiny Object.” Liisa gave us a short tour of the history of ebooks and EPUB (and made sure we knew how to spell it). Publishing, reading, and writing have changed a lot over the years. We all get caught up on “shiny objects” that might catch our attention briefly, but it’s important to explore why you want to do it. Is it because a feature is cool? Is someone asking you to add it? Are you fixing something that’s annoying? Do you have a unique solution? There are many questions to ask that can help you decide whether you should implement a change, and when (and if) you will make the change. There are some issues that the entire industry must address. We need to stop making proprietary formats and embrace standards. Focus on improving image quality as screen quality improves. We should consider the external contexts provided by reading systems, how voice, AR, and VR might affect our content, and be patient.

The highlight of the day was Rachel Comerford’s “epub and chill” talk. Somehow Rachel managed to compare online dating with ebooks. The whole room was chanting “expose your metadata, not yourself.” The rules for dating and ebooks are pretty similar: 1. Remember Your Audience 2. Use Standards 3. Be Transparent 4. Don’t Play Hard to Get. I strongly recommend checking out the video when it becomes available.

Karen Myers (W3C) and I spoke about standards in Publishing@W3C in a talk entitled “Great Expectations—The Sequel.” We offered a brief history of Publishing@W3C and a deep dive into the work happening in the EPUB3 Community Group, the Publishing Business Group, and the Publishing Working Group. We offered a quick tour of the cast of characters that makes up the rest of the W3C. We shared some highlights from groups such as WOFF, WAI, and Verifiable Claims that could be of real interest and value to the the publishing community. We spoke about how to get involved and how to stay current.

Dave Cramer (co-chair of the EPUB 3 CG) and Jiminy Panoz went on an “Excellent CSS Adventure.” You’ll have to watch the video for Dave’s biblical opening. Dave and Jiminy explained the magic of CSS with some great tips, from the power of selectors and the cascade to the mysteries of pseudo-elements and inline layout.

Benjamin Young and I discussed an HTML-First Workflow at Wiley. We spoke briefly of Wiley’s 200+ year history of publishing books and journals. We have recently begun exploring an HTML-first workflow for our journal articles that looks at content apart from metadata. We have focused on layers of material. The content is in HTML. Metadata is in RDFa. Style is acheived with CSS, and internal processing is accomplished using HTML’s data-*. attribute. The Wiley team that is working on this project began with a set of technical requirements with the goal of improving output. It is still a work in progress, but we heard that lots of people are ready to dive into HTML now.

Ben Dugas offered his perspective as an ebook retailer at the End of the Conveyer Belt. Ben works in Content Operations at Kobo. His team looks at all the files that pass through Kobo’s pipeline. To summarize, content creation is hard, spec creation is hard, content QA is hard, and building support is hard. My favorite part of Ben’s presentation was when he pointed out that it takes a little time to get used to standards work, but once they got used to our quirks, they realized they had actual opinions and it was okay to offer them. Ben’s advice is to move on to EPUB 3 (and beyond), use epubcheck and Ace, test across platforms, think about the reader, and not accept the status quo. Sound advice.

If you’re involved in the creation of ebooks, be sure to come to ebookcraft in 2019! In the meantime, you can see what people said about ebookcraft on social media, follow @ebookcraft on Twitter, and eagerly await the videos of this year’s conference.

Many thanks to Dave Cramer for his thoughtful editing of this post.

[csswg] Agenda conf call 28-Mar-2018

Source: www-style@w3.org Mail Archives • Rossen Atanassov (Rossen.Atanassov@microsoft.com) • March 28, 2018 • Permalink

Time/Phone/WebEx details available to WG Members in w3c-css-wg.
See https://lists.w3.org/Archives/Member/w3c-css-wg/2017OctDec/0076.html


US Toll Number: +1-617-324-0000

For local times, see: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180321T16


0. Extra agenda items and other digressions

1. [css-grid][cssom] Disallow repeat() syntax in grid-template-rows/columns resolved values
    https://github.com/w3c/csswg-drafts/issues/2427 

2. [css-overflow] Is the box a scroll container if only one of 'overflow-x' or 'overflow-y' is 'clip'?
    https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-370692229


3. [typed-om] Trim CSSResourceValue and subclasses to opaque objects for this level, punt rest to level 2
    https://github.com/w3c/css-houdini-drafts/issues/716


4. [css-typed-om-1] What does computedStyleMap() do on elements that are in documents with no browsing context?
    https://github.com/w3c/css-houdini-drafts/issues/659


5. [css-images-4] Clear gradient color stops with two locations for shipping
    https://github.com/w3c/csswg-drafts/issues/2439


6. [css-display][css-pseudo] Is ::marker created by display:list-item or does it always exist?
    https://github.com/w3c/csswg-drafts/issues/1793#issuecomment-374421920


7. [css-display] How does block inside inline affect the box tree, exactly?
    https://github.com/w3c/csswg-drafts/issues/1477#issuecomment-374366240


8. [css-values] Define <positive-integer>, <positive-number>, <positive-length>, etc. sub-types
    https://github.com/w3c/csswg-drafts/issues/355


9. [css-display] Defining box ↔ element style correspondence
    Issue: https://github.com/w3c/csswg-drafts/issues/1643

    Changes: https://github.com/w3c/csswg-drafts/commit/b2d484c6ab9c4dbdb8fdca899e2d37d59d6953e3


10. [css-display] Adding appendix of anonymous box construction guidance for spec authors
    Issue:   https://github.com/w3c/csswg-drafts/issues/1643#issuecomment-374414522

    Changes: https://github.com/w3c/csswg-drafts/commit/533ac0a31b0262c4a0d09c77e19604666fe35e14

    Spec:    https://drafts.csswg.org/css-display-3/#box-guidelines


11. [css-display] Blockifying 'run-in flow-root' to 'block' (for consistency with inline-block)
    Issue:   https://github.com/w3c/csswg-drafts/issues/1715

    Changes: https://github.com/w3c/csswg-drafts/commit/4a8afc522477d24032665c9ff3ceed9f76aaa6b4


12. [css-display] 'display: contents' on MathML
    Issue:   https://github.com/w3c/csswg-drafts/issues/2167

    (This should also get reviewed by the MathMLWG; we'll send
    over a request for review along with the WD announcement
    after an initial proposal is accepted by the CSSWG.)

13. [css-display] 'display: contents' on SVG elements
    Issue:   https://github.com/w3c/csswg-drafts/issues/2118

    (This should also get reviewed by the SVGWG, but CSSWG + AmeliaBR
    should be good enough until we forward the WD announcement
    with a more formal request for review.)

14. [css-display] Clarify (non-)effect of 'display' on document semantics and assistive technology
    Issue:    https://github.com/w3c/csswg-drafts/issues/2355

    Proposal: https://github.com/w3c/csswg-drafts/issues/2355#issuecomment-375084853

    Looking for a review of the proposed text and any suggestions for improvement.

Thanks,
Rossen

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