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.

Re: [math-on-web] reminder: meeting 2017/06/22

Source: public-mathonwebpages@w3.org Mail Archives • Volker Sorge (volker.sorge@gmail.com) • June 22, 2017 • Permalink

My apologies. I have to go out on short notice. I might catch the end
of the meeting.
Best,
Volker

On 22 June 2017 at 12:24, Peter Krautzberger <peter@krautzource.com> wrote:
> Hi everyone,
>
> Just a reminder that we're meeting today.
>
> The focus topic will be layout, continuing from the last meeting.
>
> Best wishes,
> Peter.


Re: [math-on-web] reminder: meeting 2017/06/22

Source: public-mathonwebpages@w3.org Mail Archives • Leonard Rosenthol (lrosenth@adobe.com) • June 22, 2017 • Permalink

Same (waves down the table to Charles ☺)

From: Charles LaPierre <charlesl@benetech.org>
Date: Thursday, June 22, 2017 at 9:01 AM
To: Peter Krautzberger <peter@krautzource.com>
Cc: "public-mathonwebpages@w3.org" <public-mathonwebpages@w3.org>
Subject: Re: [math-on-web] reminder: meeting 2017/06/22
Resent-From: <public-mathonwebpages@w3.org>
Resent-Date: Thursday, June 22, 2017 at 9:02 AM

Regrets I am at the W3C Publishing Face to Face meetings in New York today.

Thanks
EOM

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

On Jun 22, 2017, at 7:24 AM, Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>> wrote:

Hi everyone,

Just a reminder that we're meeting today.

The focus topic will be layout, continuing from the last meeting.

Best wishes,
Peter.



Re: [math-on-web] reminder: meeting 2017/06/22

Source: public-mathonwebpages@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • June 22, 2017 • Permalink

Regrets I am at the W3C Publishing Face to Face meetings in New York today.

Thanks
EOM

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

On Jun 22, 2017, at 7:24 AM, Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>> wrote:

Hi everyone,

Just a reminder that we're meeting today.

The focus topic will be layout, continuing from the last meeting.

Best wishes,
Peter.


[math-on-web] reminder: meeting 2017/06/22

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • June 22, 2017 • Permalink

Hi everyone,

Just a reminder that we're meeting today.

The focus topic will be layout, continuing from the last meeting.

Best wishes,
Peter.


Math Braille UI

Source: Murray Sargent: Math in Office • MurrayS3 • June 21, 2017 • Permalink

For sighted users, Microsoft Office applications like Word, PowerPoint and OneNote have user interface (UI) cues that reveal math zones, selected text, the insertion point (IP) if no text is selected, and the argument of the innermost math object (fraction, subscript, integral, matrix, …) that contains the IP. Math speech also reveals these properties. These sighted and speech math UI’s enable unambiguous reading and editing of mathematics. Naturally, it’s desirable to reveal these properties in refreshable braille displays as well. This post describes a promising methodology. We represent math using the Nemeth math code since it is the most efficient for the math zones used in modern applications such as Microsoft Word and LaTeX.

First here’s how these features are revealed to sighted users. In all math-enabled Office apps, the innermost math argument containing the IP is lightly shaded and selected text has the same selection background color as text not in math zones. In PowerPoint and OneNote, the math object containing the IP is shaded a bit more lightly than the argument and if the IP isn’t in a math object, the whole math zone has this lighter shading. In Word, the math zone is enclosed in a boundary and the object containing the IP doesn’t have the lighter shading. The user always knows what kind of an argument is involved just by looking at the built-up (Professional) display. This information is also conveyed in math fine-grained speech.

Refreshable braille display

A refreshable braille display typically has a row of 40 or 80 8-dot cells with the dots represented by small rounded pins that are raised by solenoids. The dots are arranged in two columns of four dots. The left column is numbered starting at the top 1, 2, 3, 7 and the right column is numbered starting from the top 4, 5, 6, 8. Like most braille codes, the Nemeth math code uses the dots 1 through 6. This leaves dots 7 and 8 for UI purposes, although dot 7 is occasionally used to indicate upper case. The Nemeth code precedes a letter with the capitalization indicator “⠠” (lone dot 6) to get upper-case letters, e.g., “⠠⠁” for “A” since “⠁” is the braille code for the letter a. So, we don’t use dot 7 to indicate upper case, at least in math zones.

The regular math braille display shows the whole math zone in braille, limited only by the number of display cells. This gives a lot of context to math braille, significantly more than math speech provides, but not as much as screen or paper.

Selection and insertion point (IP)

Typically, selected text appears with both dots 7 and 8. So if “a” is selected, it appears as “⣁”. This approach seems well suited to math expressions as well.

We’re left with needing ways to identify a math zone and the insertion point and to highlight the innermost argument containing the IP if any. Braille displays don’t have multiple shading levels, only two extra dots! They also have hot keys.

The IP needs a cell by itself to stand out. As described in the post Text Insertion Point, the IP is in between two characters in rich text, although for plain text one can get away with thinking of the IP as being on top of the character that actually follows the IP. Built-up (Professional) math text is rich text notably because it has special display constructs, such as stacked fractions, multilevel subscripts and superscripts, integrals, matrices, etc. For this purpose (and perhaps others), dots 7-8 “⣀” comprise a simple, effective IP. Admittedly this is the same as a lone selected space, but it seems to be readily distinguishable since the user usually knows when something is selected versus having an IP and s/he can easily move the IP (or hit the IP-identification hot key coming up) to check if in doubt.

Math-object arguments

To reveal the innermost argument containing the IP, one can turn on dot 8 for the characters in that argument. This is similar to the argument shading used in regular displays. To illustrate this approach, consider the fraction 1/2π, which in built-up form is given by the Nemeth braille string “⠹⠂⠌⠆⠨⠏⠼”. If the IP precedes the 2 in the denominator, the braille display would have “⠹⠂⠌⣀⢆⢨⢏⠼”.

At first the dot 8 in the denominator cells here might be confusing, but it resolves ambiguities as to whether the IP “⣀” is inside or outside of a math object. This isn’t a serious problem with fractions since the fraction start, fraction bar, and fraction end appear as the explicit braille codes ⠹,⠌,⠼, respectively, although it’s always helpful to know when the IP is in a math argument. But consider the quantity a², which is given in Nemeth braille by “⠁⠃⠆”. In Office apps and MathML, superscripts are represented by two arguments, the base and the superscript. If the IP precedes the base, is the IP at the start of the base or at the start of the superscript object? That position is ambiguous without the dot 8 option. With dot 8, you can tell the difference: in “⣀⠁⠃⠆” the IP precedes the superscript object, while in “⣀⢁⠃⠆” the IP is inside the base in front of the “a”. Distinguishing these positions is essential for unambiguous editing of mathematical text.

IP-identification hot key

Dot-8 highlighting reveals when the IP is at the start or end of an argument or somewhere in between. But it doesn’t define what kind of argument. To get this kind of information on a braille display, it’s handy to have an IP-identification hot key that flashes the name of the argument containing the IP (or “math zone” if the IP isn’t inside an argument) onto the braille display. This name needs to be localized to the current user language, while the regular braille for the math zone is globalized by nature. For example in English, depending on where the IP is in a denominator, the hot key displays “start of denominator” (⠎⠞⠁⠗⠞⠀⠕⠋⠀⠙⠑⠝⠕⠍⠊⠝⠁⠞⠕⠗), “end of denominator” or just “denominator”. This is more informative than the corresponding math speech, which only announces the kind of argument when the IP is at the end of an argument, or the kind of math object when the IP is at the start of an object. This difference occurs because fine-grained speech needs to say the character at the IP, whereas the math braille display continuously shows the characters around the IP, limited only by the number of display cells.

It might be worth having options to enable/disable dot-8 highlighting according to user preference. Even without the dot-8 highlighting, the user can resolve ambiguities by hitting the IP-identification hot key so some users might prefer to work with the simpler braille display.

Math zone identification

Lastly, how do you reveal a math zone? If the IP is inside a math-object argument, the presence of dot 8 is a good indicator. As described in the post Braille for Math Zones, math zones start with “⠸⠩” and end with “⠸⠱”. So, the start and end of a math zone are not ambiguous in math braille. In the Microsoft Office math representation, whether the IP at the start of a math zone is inside the math zone or outside is revealed by shading or the Word math-zone border, since the character position is the same for both cases. Ditto for the end of a math zone. I tried setting dot 8 for all cells in a math zone when the IP is in a math zone, but not inside an argument, but it seems too messy. So hopefully the math zone start and end delimiters will suffice; the user can hit the IP-identification hot key to find out whether the IP is in a math zone.

With these uses of dots 7 and 8 and the IP-identification hot key, you can edit virtually all levels of mathematics using a refreshable braille display in an interoperable way with sighted users. Pretty cool, eh?!

Pearson continues as MathJax Supporter

Source: MathJax • June 16, 2017 • Permalink

Pearson continues to support the MathJax project as a MathJax Supporter.

Founded in 1844 as a small building firm in Yorkshire, Pearson is the largest education company in the world today. With Pearson School, Pearson Higher Education and Pearson Professional, Pearson’s focus today lies solely on education.

“Pearson is proud to continue our sponsorship of MathJax. The use of MathJax in our digital assessment and instructional content continues to grow.”, says Wayne Ostler, VP Content Systems and Publishing. “We look forward to continuing our work with the MathJax community to improve MathML rendering and accessibility in our digital products”.

“Thanks to our dedicated sponsors like Pearson, we are able to develop MathJax continuously, keeping it the high-quality and universal rendering solution it is today,” comments Peter Krautzberger, MathJax manager. “Pearson’s support and the input from its staff provide us with productive feedback that helps our development.”

The MathJax team looks forward to the collaboration with Pearson, and welcomes their support for the MathJax project.

Pearson is the world’s leading learning company, with expertise in educational courseware and assessment, and a range of teaching and learning services powered by technology.

Pearson’s mission is to help people make progress through access to better learning. We believe that learning opens up opportunities, creating fulfilling careers and better lives.

MathJax was initiated in 2009 by the American Mathematical Society (AMS), Design Science, and the Society for Industrial and Applied Mathematics (SIAM) with the aim of developing a universal, robust, and easy-to-use solution to display mathematics on the web. MathJax’s open source JavaScript library provides high-quality display on all browsers and platforms without the need for readers to install plugins or fonts. Using MathJax also enables copy&paste of equations and is compatible with accessibility tools for vision and learning disabilities. The MathJax Consortium is supported by numerous sponsors.

[math-on-web] CG meeting minutes, 2017/06/08

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • June 14, 2017 • Permalink

Hi everyone,

Below are the minutes from the CG meeting last week.

Please note the call to action to comment on
https://github.com/w3c/csswg-drafts/issues/1339, especially if you are
building tools.

Best,
Peter.

# [math on web CG] minutes 2017-06-08

* On the fly agenda
* Peter: want to talk about CSS WG thread
* Dani: stretchy characters
* https://w3c.github.io/mathonwebpages/examples/display/html5.html

* Introductions
* Arno: background in software engineering
* wrote graphic calculator for Mac, years ago, worked at Apple, Adobe
* web platform effort at Adobe
* mathlive.io - recent passion project, work in progress
* render and editor
* TeX quality rendering
* easy UI
* Dani: added example for stretchy characters
* Dani: should the browser be the responsible?
* Arno: probably need a math aware font?
* Dani: less worried about the font
* Arno: but as author, you're going to specify a font
* for the stretchy to work correctly, you could scale it
* but usual, you need the various pieces in between the stretchy parts
* just a stretched Courier brace would be horrible
* Dani: to some degree, it works because of font fallbacks
* Arno: would be good if the browser could fallback to a math aware font
* Dani: browser needs to detect dimensions
* Peter: I'd be cautious
* Chrome kicked out MML after conflict surrounding stretchy characters
* opentype math tables might seem like the right standard but in my xp
not enough fonts (perhaps too expensive to make), more problems than
solutions from adopting them
* default fonts on systems is a faint hope
* math tables are font engine, not exposed to CSS
* mathjax historically used the TeX approach of piecing together chars,
* now switched to transforms to stretchy one char, for v3 we are pursuing
an even simpler solution
* Arno: tried something similar but issues with alignment
* Dani: our solution is also very tricky so looking for simpler solution
* Peter: I used to think that perhaps the solution lies in seeing stretchy
as fences => therefore CSS border more natural
* and also menclose notations
* Neil: borders can't do all menclose notations things
* Exactly
* Dani: I like the border situation
* Peter; I actually moved away from that again
* But Dani asked what a potential a way might be to get CSS to do
something rather than nothing to help and borders might be "something"
* Arno: might be a good way to broaden the appeal, to get interest beyond
math layout
* Dani: one problem with border is that you cannot control the style
* e.g., can't control the font
* Peter: I moved away from border because I'd expect to the idea would be
deligated to "wait for Houdini"
* Neil: Houdinin not moving forward?
* Peter: it is but I don't think it's a path to native features, much
like web components isn't turning out that way.

* Peter: on https://github.com/w3c/csswg-drafts/issues/1339
* I plan to respond was waiting for next meeting, I will post some
MathJax feedback
* Neil: is this just baseline or within equations
* [the latter, more complex problem]
* Peter: CALL TO ACTION leave comments from other implementation
* Arno: good idea to relate to wider use case
* CALL TO ACTION would be good to find more example
* Dani: we should use cases of simple mathematics
* Peter: hopefully other math tool implementers chime in
* Arno: obviously, you CAN do it with CSS
* Arno: CSS will need much broader use case


RE: [math-on-web] meeting agenda 2017/06/08

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • June 08, 2017 • Permalink

Added the stretchy examples at

https://w3c.github.io/mathonwebpages/examples/display/html5.html

Dani

*From:* Daniel Marques [mailto:dani@wiris.com]
*Sent:* jueves, 8 de junio de 2017 16:08
*To:* 'Peter Krautzberger'; 'mathonwebCG'
*Subject:* RE: [math-on-web] meeting agenda 2017/06/08

Hi Peter,

I would like to discuss the stretchy layout with HTML. Last meeting Volker
pointed out about some difficulties with HTML 5 because the render engine
had to go backwards and that was something not viable with HTML.

Dani

*From:* Peter Krautzberger [mailto:peter.krautzberger@mathjax.org
<peter.krautzberger@mathjax.org>]
*Sent:* miércoles, 7 de junio de 2017 22:09
*To:* mathonwebCG
*Subject:* [math-on-web] meeting agenda 2017/06/08

Hi everyone,

Just a quick reminder that we're meeting June 8 at 12:00 Eastern time
(GMT-04:00) via appear.in/mathonweb.

Given that we skipped 1.5 meetings, let's leave the agenda open.

Best,

Peter.


RE: [math-on-web] meeting agenda 2017/06/08

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • June 08, 2017 • Permalink

Hi Peter,

I would like to discuss the stretchy layout with HTML. Last meeting Volker
pointed out about some difficulties with HTML 5 because the render engine
had to go backwards and that was something not viable with HTML.

Dani

*From:* Peter Krautzberger [mailto:peter.krautzberger@mathjax.org]
*Sent:* miércoles, 7 de junio de 2017 22:09
*To:* mathonwebCG
*Subject:* [math-on-web] meeting agenda 2017/06/08

Hi everyone,

Just a quick reminder that we're meeting June 8 at 12:00 Eastern time
(GMT-04:00) via appear.in/mathonweb.

Given that we skipped 1.5 meetings, let's leave the agenda open.

Best,

Peter.


[math-on-web] meeting agenda 2017/06/08

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • June 07, 2017 • Permalink

Hi everyone,

Just a quick reminder that we're meeting June 8 at 12:00 Eastern time
(GMT-04:00) via appear.in/mathonweb.

Given that we skipped 1.5 meetings, let's leave the agenda open.

Best,
Peter.


Re: Displaying LaTeX expression as a plain text in MathJax

Source: www-math@w3.org Mail Archives • saf sied (saf_itpro@yahoo.com) • June 02, 2017 • Permalink

I noticed that www-math@w3.org did not copy the link in my previous response. So, I'm hardcoding the link here. Questions was answered here: https://stackoverflow.com/a/44323342/1232087 Thanks.

On Friday, June 2, 2017 10:52 AM, saf sied <saf_itpro@yahoo.com> wrote:

On Thursday, June 1, 2017 11:47 PM, saf sied <saf_itpro@yahoo.com> wrote:

Following html page with MathJax javascript displays LaTeX expression as a plain text: (x^2+1).
Question: How can we modify it to display it as a plain text: $$x^2+1$$
Note: You can copy/paste the following content on a notepad and save it as an .html file to test what I'm after.
$$\text{(x^2+1)}$$
</body><html>



Re: Displaying LaTeX expression as a plain text in MathJax

Source: www-math@w3.org Mail Archives • saf sied (saf_itpro@yahoo.com) • June 02, 2017 • Permalink

Answered here.

On Thursday, June 1, 2017 11:47 PM, saf sied <saf_itpro@yahoo.com> wrote:

Following html page with MathJax javascript displays LaTeX expression as a plain text: (x^2+1).
Question: How can we modify it to display it as a plain text: $$x^2+1$$
Note: You can copy/paste the following content on a notepad and save it as an .html file to test what I'm after.
$$\text{(x^2+1)}$$
</body><html>



Displaying LaTeX expression as a plain text in MathJax

Source: www-math@w3.org Mail Archives • saf sied (saf_itpro@yahoo.com) • June 02, 2017 • Permalink

Following html page with MathJax javascript displays LaTeX expression as a plain text: (x^2+1).
Question: How can we modify it to display it as a plain text: $$x^2+1$$
Note: You can copy/paste the following content on a notepad and save it as an .html file to test what I'm after.
$$\text{(x^2+1)}$$
</body><html>


[CSSWG] Minutes Tokyo F2F Wed 2017-04-19 Part IV: Box Alignment, display:contents, Containment, Interpreting url()s [css-align][css-contain][css-values][css-masking]

Source: www-style@w3.org Mail Archives • fantasai (fantasai.lists@inkedblade.net) • May 27, 2017 • 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.
=========================================

Flexbox & Alignment
-------------------

- Browsers were interested in fixing the partial implementation bugs.

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

- RESOLVED: Make <br> and <wbr> not display with display:contents
- RESOLVED: Strip <button> and treat as normal content
- RESOLVED: display:none the <meter> and <progress> elements when
display:contents is specified
- RESOLVED: display:none for <canvas> <applet> <embed> and
<object> when display:contents is specified
- RESOLVED: SVG elements <g>, <use>, nested <svg>, and <tspan> are
eliminated and their contents are hoisted under
display:contents but all other SVG elements are
display:none'ed
- TabAtkins and fantasai will propose wording to solve Issue 1118:
Should anonymous boxes always inherit through the box tree?

CSS Alignment
-------------

- RESOLVED: Change bottom margin edge to bottom border edge
wrt floor on last baseline of scrollable boxes.

CSS Contain
-----------

- RESOLVED: Size replaced elements as if intrinsic size was zero
and no aspect ratio.
- RESOLVED: Layout containment makes you a fixed-position
containing block for abspos children.
- RESOLVED: Level 2 for single-axis layout containment
- RESOLVED: WONTFIX issue 1043 this level, explain why
(Explanation: https://github.com/w3c/csswg-drafts/issues/1043#issuecomment-295276243)
- RESOLVED: 'display: contents' causes 'contain' values to be
ignored except style containment
- RESOLVED: Update WD of css-contain with edits for issues we
resolved today.

CSS Values / CSS Masking
------------------------

- Tentative resolution: mask-image distinguishes element reference
vs image reference via local vs external reference in url();
final resolution pending dbaron's investigation of Gecko code
[See Friday's resolution for final resolution.]

CSSOM
-----

- RESOLVED: USVString for href attributes on stylesheet and
cssimportrule

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

Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics

Scribe: myles

Flexbox
=======

topic: Partial implementations of space-evenly in grid but not flexbox
github topic: https://github.com/w3c/csswg-drafts/issues/1167

Florian: We need people from blink and WebKit here.
Florian: The "alignment" properties apply to all layout modes.
Florian: The spec describes how to do this, but browsers don't
follow.
iank: Are there bugs?
Florian: These browsers support the keywords on flex box but not
grid.
Florian: You can't use @supports because the browsers do "support"
the value.
Florian: They shouldn't have shipped it.
myles: We will not un-ship it.
TabAtkins: It's easy to fix. We will probably fix it.
myles: We, WebKit, are regretful that we shipped it and want to
fix this.

shane: Are there issues?
Florian: Yes
Florian: You could also just provide a better fallback if you want.
shane: We have an old patch which gets us at least partway there.
We can pick it up.
shane: People are responsive.

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

<TabAtkins> https://drafts.csswg.org/css-display/#unbox-html
TabAtkins: We all agreed that replaced elements and proper form
controls are display none when you set display:contents
on them.
TabAtkins: There are some more HTML elements where it's not clear
how we should treat them.
TabAtkins: ^^^ list.
TabAtkins: Chrome people have opinions.

<br> and <wbr>
--------------

TabAtkins: Next up: <br> and <wbr>
TabAtkins: They are magical today. They should be display:none.
TabAtkins: Our policy is not to make up things without use cases.
We are trying to come up with the most reasonable
outcome.
<general confusion>
fantasai: They should do their thing and ignore display:contents
fantasai: No strong opinion.
TabAtkins: But display:contents always makes the thing go away.
fantasai: But text doesn't go away.
tantek: But this isn't like text content.
<tantek> +1 on TabAtkins proposal
fantasai: But from a CSS author's point of view, it is.
fantasai: Jen Simmons raised the issue that <br> turns into a grid
item and this is bad.
fantasai: People don't think of <br> as an element.
TabAtkins: It's easy to run into trouble if you put raw text into
a flexbox. So we tell authors to put wrappers around
their text.
tantek: Agreed.
<dbaron> That is, Tab was saying you run into the same problem
with <b>bold text</b> if you haven't used a wrapper.

Florian: From an implementation point of view, do <br>s have magic
which is easy to make go away, or is it difficult to make
it display:none
fantasai: It's easy to implement.
astearns: Any objections to just doing display:none?
<none>

RESOLVED: Making <br> and <wbr> not display with display:contents

<button>
--------

TabAtkins: The <button> element.
TabAtkins: UAs are usually okay with rendering buttons just like
spans, so display:contents can do the normal thing here
TabAtkins: but <button> and <input type="button"> are usually
interchangeable.
TabAtkins: But it's probably fine. I don't have a strong opinion.

tantek: <button> and <input type="button"> are pretty different
though.
tantek: We should strip off the tags
fantasai: But it's confusing to an author!
fantasai: Authors' decisions about which to use is arbitrary.
tantek: You should strip the tag because it's actually less
confusing, not more confusing
tantek: because there is inner elements.
fantasai: We don't do that for <object>.
iank: It's like <canvas>.
tantek: But <button> has different fallback behavior.
TabAtkins: We should just strip the <button> wrapper and treat it
as normal content
<tantek> +1 treat button as a normal element

RESOLVED: Strip <button> and treat as normal content

<meter> and <progress>
----------------------

TabAtkins: <meter> and <progress> elements
TabAtkins: I think they are replaced.
TabAtkins: The contents of <meter> and <contents> are not
fallback. Instead, they are just legacy. So we should
display:none them.
TabAtkins: It's the same as <video> because the contents are not
meant to be displayed.
TabAtkins: It's irrelevant.
iank: Internally we represent these as form controls.
TabAtkins: We should treat like form controls.
fantasai: I'd prefer to show the contents but i won't object.

RESOLVED: display:none the <meter> and <progress> elements when
display:contents is specified

<applet> <canvas> <embed>
-------------------------

TabAtkins: 4! <applet> <canvas> <embed> elements
TabAtkins: When they are showing, they are definitely replaced, so
it's well-defined. But! (Especially for <object> and
<applet>) if the thing you're referencing is invalid,
it's meant it show the stuff inside it.
TabAtkins: Is it really replaced? Should we strip the wrapper away?
Florian: <object> has 2 states: 1) it's replaced, or 2) it shows
its contents
Florian: If it's not display:none, it's dangerous to authors.
iank: Usually for <canvas> you put your fallback inside the tag.
iank: It should be display:none.

astearns: The goal of display:contents isn't to hide contents.
iank: Yeah, it'll take the canvas out of the tree and show the
contents.
Florian: But we already resolved on that, maaaaaaan.
All: <object> is kind of different from the others.
Florian: When the content loads, we've decided that display:none
works. But otherwise, ?
tantek: Yeah the load state shouldn't affect stuff.
tantek and fantasai: but you should show the contents in both
cases (whether it loaded or not).
TabAtkins: We have a blanket policy which we can revisit but it is
a good policy.
Florian: Both states should do the same. And they should show
their contents.
TabAtkins: Yes, they should do the same thing. And the normal
state should be display:none and therefore both should
be.

astearns: Let's not discuss the blanket policy.
astearns: I want to go with display:none. Does anyone object?

RESOLVED: display:none for <canvas> <applet> <embed> and <object>
when display:contents is specified

display:contents on SVG elements
--------------------------------
GitHub Topic: https://github.com/w3c/svgwg/issues/305

TabAtkins: SVG does not have a box model. It's defined in terms of
something custom.
TabAtkins: I'd like to describe SVG in terms of a box model.
TabAtkins: So we have no idea what to do.
TabAtkins: SVG currently special cases display:none to say "stuff
doesn't render"
TabAtkins: Option 1: All SVG treats display:contents as
display:none
TabAtkins: but this isn't great because it is valuable here.
TabAtkins: <g> and <use> and nested <svg> can be stripped
fantasai: <tspan> too.
TabAtkins: Everything else should probably be display:none
TabAtkins: fantasai: This is consistent with how it works.

ChrisL: Will people try to use this to implement fallback?
fantasai: What if you display:contents two nested elements, does
TabAtkins: It does cascade, so the innermost text wouldn't render.
TabAtkins: The root SVG should display:none but inner ones not
necessarily.
TabAtkins: If nobody objects, I'll do this.
astearns: Objections?

RESOLVED: SVG elements <g>, <use>, nested <svg>, and <tspan> are
eliminated and their contents are hoisted under
display:contents but all other SVG elements are
display:none'ed

MathML
------

TabAtkins: Everything in MathML should display:none when
display:contents is specified.
TabAtkins: We may just .... not care about MathML.

astearns: Let's take the spec to CR, please!
fantasai: But we have new issues!!!
fantasai: So we can't go to CR.
fantasai: We can fix them up real quick and we'll come back.

Inheritance through 'display: contents'
---------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1118

fantasai: This is a fun test case
fantasai: There are anonymous boxes in the box tree. We defined an
anonymous box in the box tree has initial values except
for the ones which are inherited (from its parent box in
the box tree). But! When we have display:contents, if
the parent of the anonymous box, then the element's
parent is really its grandparent!
TabAtkins: "parent box" is reasonably well-defined now, but with
display:contents, not so much.
<TabAtkins> (Specifically, "parent box" is simple enough, in a
pre-display:contents world, that we don't have to
worry much about the fact that it's weakly defined.
With display:contents, tho, the full box tree starts
being more relevant, and the weak definition is more
troublesome.)
fantasai: What I expect is that we look at the parent box in the
box tree and we look at the element which generated that
box.
fantasai: However, implementations don't look at the box tree,
they look at the parent element and its properties.
fantasai: Sooooooo this is busted.

fantasai: So are these bugs? Or should we update the spec?
TabAtkins: We should do the latter. Inheritance doesn't pay
attention to the box tree. The fact that this uses the
box tree was hand-wavey.
TabAtkins: <gives example>
<section> <div>Foo</div>
</section>
<section> <div><span>Foo</span></div>
</section>
section { color: red;
}
div { color: green; display: contents;
}
TabAtkins: <explains the example>

dbaron: There are 2 different distinctions to make (but one may
not be observable).
dbaron: Gecko recently changed how anonymous boxes inherit (but
only for nested anonymous boxes). Previously, if you have
2 nested ones, one would inherit from the other. Now, all
nested boxes inherit from the closest real element.
Florian: Is there an observable difference?
dbaron: Not to regular users.
xidorn: What about a writing-mode change on an element with
display:contents and text inside it?

astearns: We need to change the spec to match the implementations.
fantasai: If you have an inline element and its the child of a
block, then it's the child of the root inline of that
block. If you remove that inline element, then the
contents of that inline element (the text) becomes a
child of the block's root inline. There's no intervening
box belonging specifically to the text. Now, if we make
that box go away, there's nothing that is holding the
properties that apply to the text other than the root
inline. The root inline's properties apply to the text
because there's nothing between there.
fantasai: If you put an inline in between the text and the root
inline, give it a property, then pull it away with
display:contents, then it's not in the formatting tree.
How is it contributing a color when it's gone?
TabAtkins: Inheritance always follow the element tree.
TabAtkins: Text doesn't have properties, but it does know things
like color.
fantasai: We have to invent this idea of a text frame, and say
that it has properties, and it's an anonymous object
which you can't get rid of.
TabAtkins: We kind of had to do that with selectors already.
TabAtkins: We say that clicking on raw text correctly triggers,
even when there are intervening shadows & etc.
fantasai: It is already a thing, but it doesn't have properties.
Now we are saying that it has its own properties.
TabAtkins: Yes, to achieve what all implementations do and what
makes sense.
TabAtkins: display:contents shouldn't change inheritance.
fantasai: Background color does go away when you take away the
box.
TabAtkins: In the example in the issue, do you think in the first
bit that text should be red?
TabAtkins: Where red is assigned to <section> and green is
assigned to <div>?
fantasai: <reads really hard>
fantasai: I expected div of to take the color of the section, and
div span foo to take the color of the div.
TabAtkins: I disagree.
TabAtkins: I agree with the originator and what implementations do
TabAtkins: We can work through the implementations to make things
well-defined.

astearns: This will be difficult to specify.
fantasai: It requires inventing a new type of box in the inline
layout model which we don't have yet.
TabAtkins: Putting the span in there changes how inheritance
works, which changes what users see, and this is
unreasonable. The present of an element shouldn't make
the color jump over the div.
Florian: The consequences that a non-styled span changes things is
scary.
astearns: Let's table this.

fantasai: If we make a new box, it belongs in the inline layout
module, not this module.
TabAtkins: Let's put all the boxes in display:*
fantasai: But you can't create it with display:*
fantasai & TabAtkins: <tries to figure out which modules this
should go in>

<last baseline alignment discussion part II moved to Minutes Part II>

Selectors
=========
scribe: TabAtkins

Propagation of the :focus pseudo
--------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1240

Florian: This was raised by fantasai a while ago.
Florian: Topical now because Mozilla and Blink are both
implementing :focus-within, which depends on :focus, so
we should make sure we get :focus right.
Florian: We have wording attempting to say that "whatever magic
HTML says to make :active propagate (to labeled controls,
etc), it should apply to :focus too".
Florian: fantasai says this is either useless or contradicting
HTML.
Florian: I think you were saying that the way we phrased it
doesn't make it clear whether we were placing a
requirement on the HTML authors to fix this, or
overriding them and defining it propagates differently.
Florian: Because in HTML :focus and :active do propagate
differently.
Florian: So it's unfortunate if we disagree. Do we yield, or shout
at them?
Florian: I think we wrote it this way because there was a parallel
discussion about whether :focus and :active should
propagate from a form control to its label *and* vice
versa; we at least agree that they should both act the
same.
Florian: And we just filed an issue on HTML to figure out if it
should be bidirectional or not.
Florian: It was bidirectional in IE (not Edge).
Florian: Given that :focus-within is meant to do the same as
:focus, and there's no compat baggage, we should put a
stick in the ground and decide.

[need more time to think about this, we're dropping the topic for now]

css-contain
===========
Scribe: fantasai

Florian: Have a FPWD of css-contain that is well overdue, thus
close to CR.
Florian: Have some issues, let's close them.

contain:size on replaced elements
---------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/382

Florian: If you 'contain: size' on a replaced element, what should
that mean?
dbaron: You get whatever size specified, otherwise zero.

RESOLVED: Size as if intrinsic size was zero and no aspect ratio.

contain:layout wrt abspos/fixedpos containing blocks
----------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/404

TabAtkins: Need to check with Ojan, inclined to accept proposal.
Florian: Can we resolve and check later?
TabAtkins: Proposal is that layout containment makes you a fixed
position containing block for abspos children

RESOLVED: Layout containment makes you a fixed position containing
block for abspos children.

<trackbot> Created ACTION-847

single-dimension layout containment
-----------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1031

Florian: Next one from dbaron...
dbaron: This one is a big issue.
dbaron: One of the things that a bunch of web devs really want is
what they call "container queries"
dbaron: which basically addresses the sub case of teams that
develop widgets or modules that are part of a bigger page.
dbaron: They're developing some markup and script and whatever
that gets included within a bigger page, and it will have
some size.
dbaron: The bigger page might use media queries to e.g. switch
from 3 columns to 2 columns, and widgets gets bigger
though viewport got smaller.
dbaron: If you're implementing the widget, you want to respond to
the size that the widget is, not the size of the viewport.

dbaron: Bunch of ppl want container queries that actually work,
rather than do what ppl do right now which is do layout,
flush, and set styles based on that.
dbaron: Seems to me it should have some relation to containment-
dbaron: that is, ability to do container queries should depend on
some kind of containment so that your insides don't depend
on your outsides which depend on your insides.
dbaron: The next point is that sometimes people want to do
container query on their width, but have an auto height.
dbaron: So, was thinking we want to have layout containment in
only one dimension.
dbaron: Beyond that haven't thought about it, so this is a "please
design me a feature" issue.
dbaron: This seems like a relatively high priority feature because
ppl do this a lot, and do it by doing flush-restyle loops.

Florian: If they're willing to go that far, using 2D size
containment is good, set it and then reset your height
after you do layout.
dbaron: Get ppl doing it for multiple parts of the page, so cycles
multiple times.
fantasai: Why not just have -x -y keywords?
TabAtkins: Hard to define what that means.
eae: Maybe sets wrong expectations, that you wouldn't get same
performance benefits.
TabAtkins: True, but you do get the benefit that when you're using
resize observer you get predictable behavior and not
loops.
Florian: Seems like level 2, esp. we don't have proposal yet.
TabAtkins: This plus resize observer plus custom at-rules, I'm
hoping will allow solving this use case.
TabAtkins: Been my plan for like 2 years.

RESOLVED: Level 2

Freezing/unfreezing size containment
------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1043

Florian: Probably better in 1D context, but still applies to 2D.
Florian: Imagine you have long FB page, infinite scroller, 37
screens down.
Florian: Because everything is dynamic, ppl will update stories
above where you are, which will change your size, which
will make you scroll.
Florian: Things that are off-screen should have their size frozen,
and when they enter the screen you should unfreeze them.
Florian: So want a variant of size containment that only applies
offscreen.
Florian: And then when you scroll in it solves.

plinss: Sounds like a giant hack that should be solved by scroll
anchoring.
iank: FB can also use intersection observer to do this.
Florian: That ends up being just slow enough that they do resizing
on-screen (rather than just off-screen).
Florian: My take is that once we get scroll anchoring a large part
will be solved, combine with fact that you can do manual
freezing if you want.
Florian: But I think this is not something to solve with magic
freezing and unfreezing.
fantasai: I agree with the last statement.

flackr: If you were to drag the scrollbar, we will probably put up
a frame before we run any script in response to the scroll
position, so you will see un-resized content.
Florian: Which is why I'd suggest there was some UI indication
(like graying out) that indicates out-of-date-ness.
Florian: Not as good as magic, but dunno how to make that happen.

Florian: So proposed wontfix.
astearns: Objections?
iank: We should also say that we'll keep use case in mind for
future stuff.
TabAtkins: But right now solution is use JS intersection observer.
Florian: And various upcoming features will make it better (though
not perfect) soon.
astearns: Can someone add a comment summarizing these conclusions?

RESOLVED: WONTFIX this level, explain why

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

Florian: That takes us to zero open issues on css-contain.
Florian: Modulo DoC, go to CR?
ChrisL: Changes section?
Florian: No, should I do that first?
ChrisL: If you can do it in a reasonable time. Just want to avoid
"CR pending edits" which takes 9 months.
tantek: Could update a WD now, and the resolve on CR once you have
DoC.
Florian: Question about DoC...
Florian: Not much happened between FPWD and now, do we need a DoC
covering comments from earlier.
ChrisL: Assumption in the Process is that FPWD is actually the
first *public* working draft.
Florian: Okay, I'll do DoC over old issues.
tantek: Is that needed?
Florian: Need to demonstrate wide review.
ChrisL: We also need to show usual sec/a11y/i18n reviews.
Florian: Will show non-trivial DoC, not necessarily comprehensive
to first ED.

RESOLVED: Update WD of css-contain with edits for issues we
resolved today.

[ Note: This section moved over from Thursday ]

Florian: Issue on combining 'display: contents' and 'contain'.
Florian: My suggestion is no effect for everything except for
style containment.
dbaron: The other way to do it is that containment sometimes
changes display, e.g. can blockify it.
dbaron: Could say that contain property wins
dbaron: and makes your display go away.
fantasai: Making 'display: contents' “goes away” is problematic,
what does it then become?
SimonSapin: What’s the blockification of display:contents?
dbaron: Block?

dbaron: I'm okay with what Florian said.
dbaron: Though I think some ppl might have intuition that
containment should win.
Florian: Seems like an error to me. Do the simple thing.

RESOLVED: 'display: contents' causes 'contain' values to be
ignored except style containment

Scheduling
==========

Vlad: TYPO is willing to consider our preferences in terms of
dates.
Rossen: Latest is that there is a possibility that next TPAC will
be ...
ChrisL: End of October in Lyon is under consideration.
astearns: Given TPAC is late October, should we aim for early
April for spring meeting?

Ambiguities in handling url()
=============================
Github topic: https://github.com/w3c/csswg-drafts/issues/383

<leaverou> relevant TPAC minutes where this was discussed:
https://lists.w3.org/Archives/Public/www-style/2016Nov/0070.html
TabAtkins: Everybody remembers issue from awhile ago -- it's
ambiguous whether an URL with a fragment ID is referencing
an element in the SVG or a pant server /mask whatever
TabAtkins: Everything is bad, and it's been bad since 2012 when
issue was first raised by roc.
TabAtkins: Going forward we wanted to rely on element() vs image()
functions to make it clear
TabAtkins: But still need to figure out what to do with url()
legacy.
TabAtkins: Unclear whether that should be property-specific,
language-specific, something else.
TabAtkins: Looking at TPAC minutes.

TabAtkins: Some proposals:
TabAtkins: 1. Treat ambiguous cases as url reference into an SVG
document, not treat as image and apply :target
TabAtkins: 2. Treat ambiguous cases as url, if it has a fragID
treat as a reference, otherwise treat as an image
TabAtkins: 3. Treat ambiguous cases, load it twice -- first see if
there's an appropriate reference, otherwise go back
and reload as an image
fantasai: 4. Do something different per property

* fantasai agrees with TabAtkins's summary that this is all bad.
plinss: #3 follows Web architectural principles better. Shouldn't
judge URL by its syntax like in #2.
Florian: #1 and #4 also don't violate principle.
plinss: Could be a PNG at the end of a URL. You don't know.
leaverou: Why would an author use a fragID on a PNG?
plinss: To crop a section of the PNG.
plinss: We made image() function to make this unambiguous.
TabAtkins: On the other hand, implementations really don't want to

TabAtkins: Chrome and FF seem to decide on reference vs image
based on whether it's local fragment vs external
reference.
TabAtkins: Could probably just switch on that, and then later
introduce element() vs image() functions.
TabAtkins: Might need more info from birtles.
fantasai: I'm okay with distinguishing based on local vs external
reference.
TabAtkins: No browser currently allows external SVG references.
dbaron: Gecko does in some cases, maybe not in CSS.
leaverou: Should not assume they never allow external SVG
references.
TabAtkins: Yeah, just don't need to consider it wrt web-compat.
jet: We do for clip-path.
dbaron: Most ambiguous case is mask.
dbaron: But I thought we did for clip-path, filter, and mask.

TabAtkins: Mask is the only one that's troublesome atm.
TabAtkins: Everyone else can define per property.
TabAtkins: If a property only takes images, or only takes clip
paths, not ambiguous.
TabAtkins: Didn't want to do per-property decision for ambiguous
cases.
fantasai: Some of these properties that are currently unambiguous,
maybe become ambiguous in the future.
fantasai: So in the future, would be per-property disambiguation.
fantasai: I think fill/stroke has (or will have) ambiguous cases.
fantasai: Fill currently takes a paint server reference, but we're
adding image references, so it will become ambiguous.

TabAtkins: So when you said you handle external mask references,
is that just for mask property that only accepts
external references?
dbaron: We parse the mask property into longhands, so we would do
it on mask-image, because that's where it lives.
TabAtkins: How do you split mask-image into the two different
cases?
TabAtkins: afaict, you did it based on whether local or not.
...
TabAtkins: Right now element() and image() have other features,
which is why were kicked out to L4
leaverou: Element() somewhat impl in Firefox.
TabAtkins: We could, though, define them as subset of the
functionality, i.e. same as url() except without
ambiguity.

leaverou: Option 3 is off the table?
TabAtkins: Yeah, because cost-prohibitive
leaverou: #2 is only a problem cuz web architecture?
plinss: Blatant violation of web architecture
fantasai: What about local ref vs external reff?
plinss: Not so bad.

astearns: Sounds to me that 1 is only viable option
Florian: Well, 1 and 4?
Florian: We will have to define property by property going forward
Florian: We do #1 on currently-ambiguous cases, but will have to
define property by property going forward.
TabAtkins: E.g. fill/stroke previously unambiguous, becoming
ambiguous with new fill-stroke spec.
astearns: So in cases where it could be interpreted as either, it
will be ?

TabAtkins: Alternately could make it local vs external, like
fantasai: For mask-image, what are the possible things we could
actually do?
TabAtkins: Depends on what FF is doing and if compat-required.
TabAtkins: I think local vs external is def how Webkit/Blink does
it, and it's how Gecko used to work.
birtles: Still does.
fantasai: So sounds like we *have* to do mask-image that way.
fantasai: Should we resolve on local vs non-local?
leaverou: Makes sense now because external reference aren't
possible.
fantasai: But we will have unambiguous syntax for that.
leaverou: But by adding a fragID, author made their intent clear.
TabAtkins: No, they didn't, because e.g. might be using svg stacks
where fragID is triggering :target
plinss: Can use a media frag to pull a frame out of an MP4.
leaverou: ok.

<birtles> fwiw the Firefox code I'm looking at is
http://searchfox.org/mozilla-central/rev/214345204f1e7d97abb571b7992b6deedb5ff98f/layout/style/nsCSSDataBlock.cpp#64
which at least indicates we don't trigger an image load
if it's a local reference
<dbaron and birtles investigate Gecko code>
<dbaron> The point where we actually branch between the SVG vs.
image-tiling case is in the function PaintMaskSurface in
nsSVGIntegrationUtils.cpp...
<dbaron> And as far as I can tell that's just a function of
whether a pointer is null, which is null as a function of
whether we managed to find an SVG Mask Element...
<dbaron> the thing that it's testing for null was set up in the

astearns: First proposed resolution is distinguish these cases on
mask-image via local vs external reference
astearns: which matches implementations, as far as we can tell.
astearns: Any objections?
dbaron: I'm not sure if that's actually happening. Things are
fancy here.
dbaron: Not sure if it matters.

RESOLVED: mask-image distinguishes element reference vs image
reference via local vs external reference in url()

TabAtkins: I'm betting we could apply local vs external globally,
on account of local hash bg images are broken right now
anyway, unless your HTML is also a PNG.
leaverou: What about hashes on data URL? If SVG was in a data URL,
and has a hash?
TabAtkins: That's still an external URL as far as loading pipeline
is concerned.
leaverou: I suspect that's something I've used...

astearns: For second instance?
fantasai: Second instance is now, fill-stroke.
astearns: Maybe wait until we have more info?
astearns: e.g. dbaron figuring out gecko code.

xidorn: Person who implemented mask-image says we do check if
target element is mask element after we load the file.
fantasai: Question is, after you check it and it fails the check,
what do you do?
dbaron: I suspect we do two loads.
plinss: Don't want to require impls to all do hardest least
performant thing, but don't want to preclude doing it
correctly.
astearns: Seems we have to leave this one for now.

dbaron: Anyone have a technique for making a file that's both a
valid SVG and a valid PNG?
Florian: I don't but I know who would.
dbaron: Might be able to test SVG as SVG.
Florian: If you need, try p01 on twitter, he makes crazy demos
dbaron: I think we just need an SVG that's a circle and a mask
that's a square.

[comments from after the meeting on this topic]
<dbaron> Here's a test showing that Gecko's distinction is based
on whether it can find the mask element:
<dbaron> The image is here: https://dbaron.org/css/test/2017/
<dbaron> the test links to a mask element that exists, and a
fragment that doesn't exist.
<dbaron> The former users the mask in the mask element and ignores
the mask-size, mask-repeat, etc.; the latter uses the
toplevel SVG as a mask and honors mask-repeat and
<dbaron> so the upper test shows a single circle, and the lower
four rects

CSSOM
=====

SimonSapin: We have href attribute on stylesheet and cssimportrule.
SimonSapin: We should be using USVString, because they are URLs
SimonSapin: Can we resolve to do that?

RESOLVED: USVString for href attributes on stylesheet and
cssimportrule


Re: [MathOnWeb] skip meeting this week?

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • May 24, 2017 • Permalink

Hi everyone,

Given that more people won't be able to make it tomorrow, let's skip this
one.

Best,
Peter.

On May 24, 2017 4:15 PM, "Peter Krautzberger" <
peter.krautzberger@mathjax.org> wrote:

> Hi everyone,
>
> Spinning another thread from Dani's message.
>
> Since tomorrow is a holiday in many countries, perhaps we should skip the
> meeting.
>
> Peter.
>
> On Wed, May 24, 2017 at 2:55 PM, Daniel Marques <dani@wiris.com> wrote:
>
>> Hi,
>>
>>
>>
>> I think that a F2F would be a great step. We need to do some preparation
>> first, of course.
>>
>>
>>
>> BTW this Thursday I’m not available for the meeting.
>>
>>
>>
>> Dani
>>
>>
>>
>>
>>
>> *From:* Charles LaPierre [mailto:charlesl@benetech.org]
>> *Sent:* martes, 23 de mayo de 2017 18:55
>> *To:* Peter Krautzberger
>> *Cc:* mathonwebCG
>> *Subject:* Re: [MathOnWeb] TPAC 2017 - Book flights and hotel NOW if
>> approved to go
>>
>>
>>
>> Sounds like a plan Peter, would be helpful if this does not coincide with
>> the DPUB WG meetings, not sure if the agenda has been set yet, although it
>> looks like there is a Publishing summit on Thursday and Friday that week.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Thanks
>>
>> EOM
>>
>> Charles LaPierre
>> Technical Lead, DIAGRAM and Born Accessible
>> E-mail: charlesl@benetech.org
>> Skype: charles_lapierre
>> Phone: 650-600-3301 <(650)%20600-3301>
>>
>>
>>
>>
>>
>> On May 23, 2017, at 8:43 AM, Peter Krautzberger <
>> peter.krautzberger@mathjax.org> wrote:
>>
>>
>>
>> Hi everyone,
>>
>>
>>
>> TPAC is rapidly getting closer and hotel reservations are now open.
>>
>>
>>
>> We should discuss at the next meeting whether we want to submit for a F2F
>> time there.
>>
>>
>>
>> Best,
>>
>> Peter.
>>
>>
>>
>>
>>
>>
>> The reservation procedure for the TPAC hotel is now available, and the
>> meeting planners are reminding us to book flights and hotel as soon as
>> possible.
>>
>> Non-stop, round-trip fares from Boston to San Francisco, have gone up
>> over 100 USD since 31 March Prices are expected to increase sharply by
>> June/July. The second largest conference in the country is taking place the
>> same week as TPAC in San Francisco: DreamForce '17.  The TPAC hotel
>> typically sells out 6-7 weeks prior to TPAC; we have a limited number of
>> guest rooms. It is likely that the Hyatt will sell out earlier.
>>
>> Non conference, guest room rates for TPAC week at Marriott and Hyatt
>> Burlingame are nearly 600 USD plus taxes per night.
>>
>> Meeting Overview -- https://www.w3.org/2017/11/TPAC/Overview.html
>> Hyatt Reservation Link --
>> https://aws.passkey.com/event/48983943/owner/4566/landing?gt
>> id=e96b0f8312fe5e63725056072d434a8f
>>
>>
>>
>
>


[MathOnWeb] skip meeting this week?

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • May 24, 2017 • Permalink

Hi everyone,

Spinning another thread from Dani's message.

Since tomorrow is a holiday in many countries, perhaps we should skip the
meeting.

Peter.

On Wed, May 24, 2017 at 2:55 PM, Daniel Marques <dani@wiris.com> wrote:

> Hi,
>
>
>
> I think that a F2F would be a great step. We need to do some preparation
> first, of course.
>
>
>
> BTW this Thursday I’m not available for the meeting.
>
>
>
> Dani
>
>
>
>
>
> *From:* Charles LaPierre [mailto:charlesl@benetech.org]
> *Sent:* martes, 23 de mayo de 2017 18:55
> *To:* Peter Krautzberger
> *Cc:* mathonwebCG
> *Subject:* Re: [MathOnWeb] TPAC 2017 - Book flights and hotel NOW if
> approved to go
>
>
>
> Sounds like a plan Peter, would be helpful if this does not coincide with
> the DPUB WG meetings, not sure if the agenda has been set yet, although it
> looks like there is a Publishing summit on Thursday and Friday that week.
>
>
>
>
>
>
>
>
>
> Thanks
>
> EOM
>
> Charles LaPierre
> Technical Lead, DIAGRAM and Born Accessible
> E-mail: charlesl@benetech.org
> Skype: charles_lapierre
> Phone: 650-600-3301 <(650)%20600-3301>
>
>
>
>
>
> On May 23, 2017, at 8:43 AM, Peter Krautzberger <
> peter.krautzberger@mathjax.org> wrote:
>
>
>
> Hi everyone,
>
>
>
> TPAC is rapidly getting closer and hotel reservations are now open.
>
>
>
> We should discuss at the next meeting whether we want to submit for a F2F
> time there.
>
>
>
> Best,
>
> Peter.
>
>
>
>
>
>
> The reservation procedure for the TPAC hotel is now available, and the
> meeting planners are reminding us to book flights and hotel as soon as
> possible.
>
> Non-stop, round-trip fares from Boston to San Francisco, have gone up over
> 100 USD since 31 March Prices are expected to increase sharply by
> June/July. The second largest conference in the country is taking place the
> same week as TPAC in San Francisco: DreamForce '17.  The TPAC hotel
> typically sells out 6-7 weeks prior to TPAC; we have a limited number of
> guest rooms. It is likely that the Hyatt will sell out earlier.
>
> Non conference, guest room rates for TPAC week at Marriott and Hyatt
> Burlingame are nearly 600 USD plus taxes per night.
>
> Meeting Overview -- https://www.w3.org/2017/11/TPAC/Overview.html
> Hyatt Reservation Link --
> https://aws.passkey.com/event/48983943/owner/4566/landing?gtid=
> e96b0f8312fe5e63725056072d434a8f
>
>
>


RE: [MathOnWeb] TPAC 2017 - Book flights and hotel NOW if approved to go

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • May 24, 2017 • Permalink

Hi,

I think that a F2F would be a great step. We need to do some preparation
first, of course.

BTW this Thursday I’m not available for the meeting.

Dani

*From:* Charles LaPierre [mailto:charlesl@benetech.org]
*Sent:* martes, 23 de mayo de 2017 18:55
*To:* Peter Krautzberger
*Cc:* mathonwebCG
*Subject:* Re: [MathOnWeb] TPAC 2017 - Book flights and hotel NOW if
approved to go

Sounds like a plan Peter, would be helpful if this does not coincide with
the DPUB WG meetings, not sure if the agenda has been set yet, although it
looks like there is a Publishing summit on Thursday and Friday that week.

Thanks

EOM

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

On May 23, 2017, at 8:43 AM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

Hi everyone,

TPAC is rapidly getting closer and hotel reservations are now open.

We should discuss at the next meeting whether we want to submit for a F2F
time there.

Best,

Peter.

The reservation procedure for the TPAC hotel is now available, and the
meeting planners are reminding us to book flights and hotel as soon as
possible.

Non-stop, round-trip fares from Boston to San Francisco, have gone up over
100 USD since 31 March Prices are expected to increase sharply by
June/July. The second largest conference in the country is taking place the
same week as TPAC in San Francisco: DreamForce '17.  The TPAC hotel
typically sells out 6-7 weeks prior to TPAC; we have a limited number of
guest rooms. It is likely that the Hyatt will sell out earlier.

Non conference, guest room rates for TPAC week at Marriott and Hyatt
Burlingame are nearly 600 USD plus taxes per night.

Meeting Overview -- https://www.w3.org/2017/11/TPAC/Overview.html
Hyatt Reservation Link --
https://aws.passkey.com/event/48983943/owner/4566/landing?gtid=e96b0f8312fe5e63725056072d434a8f


Re: [MathOnWeb] TPAC 2017 - Book flights and hotel NOW if approved to go

Source: public-mathonwebpages@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • May 23, 2017 • Permalink

Sounds like a plan Peter, would be helpful if this does not coincide with the DPUB WG meetings, not sure if the agenda has been set yet, although it looks like there is a Publishing summit on Thursday and Friday that week.

Thanks
EOM

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

On May 23, 2017, at 8:43 AM, Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>> wrote:

Hi everyone,

TPAC is rapidly getting closer and hotel reservations are now open.

We should discuss at the next meeting whether we want to submit for a F2F time there.

Best,
Peter.

The reservation procedure for the TPAC hotel is now available, and the meeting planners are reminding us to book flights and hotel as soon as possible.

Non-stop, round-trip fares from Boston to San Francisco, have gone up over 100 USD since 31 March Prices are expected to increase sharply by June/July. The second largest conference in the country is taking place the same week as TPAC in San Francisco: DreamForce '17.  The TPAC hotel typically sells out 6-7 weeks prior to TPAC; we have a limited number of guest rooms. It is likely that the Hyatt will sell out earlier.

Non conference, guest room rates for TPAC week at Marriott and Hyatt Burlingame are nearly 600 USD plus taxes per night.

Meeting Overview -- https://www.w3.org/2017/11/TPAC/Overview.html
Hyatt Reservation Link --
https://aws.passkey.com/event/48983943/owner/4566/landing?gtid=e96b0f8312fe5e63725056072d434a8f


[MathOnWeb] TPAC 2017 - Book flights and hotel NOW if approved to go

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • May 23, 2017 • Permalink

Hi everyone,

TPAC is rapidly getting closer and hotel reservations are now open.

We should discuss at the next meeting whether we want to submit for a F2F
time there.

Best,
Peter.

The reservation procedure for the TPAC hotel is now available, and the
meeting planners are reminding us to book flights and hotel as soon as
possible.

Non-stop, round-trip fares from Boston to San Francisco, have gone up over
100 USD since 31 March Prices are expected to increase sharply by
June/July. The second largest conference in the country is taking place the
same week as TPAC in San Francisco: DreamForce '17.  The TPAC hotel
typically sells out 6-7 weeks prior to TPAC; we have a limited number of
guest rooms. It is likely that the Hyatt will sell out earlier.

Non conference, guest room rates for TPAC week at Marriott and Hyatt
Burlingame are nearly 600 USD plus taxes per night.

Meeting Overview -- https://www.w3.org/2017/11/TPAC/Overview.html
Hyatt Reservation Link --
https://aws.passkey.com/event/48983943/owner/4566/landing?gtid=
e96b0f8312fe5e63725056072d434a8f


Re: Minutes 2017/05/11- DRAFT

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • May 15, 2017 • Permalink

Thanks so much, Kyrce!

Best,
Peter.

On Fri, May 12, 2017 at 2:53 PM, Daniel Marques <dani@wiris.com> wrote:

> Thank you very much Kyrce!
>
>
>
> Dani
>
>
>
> *From:* Swenson, Kyrce [mailto:kyrce.swenson@pearson.com]
> *Sent:* jueves, 11 de mayo de 2017 19:19
> *To:* public-mathonwebpages@w3.org
> *Subject:* Minutes 2017/05/11- DRAFT
>
>
>
> *Topic:* Layout
>
> *Attendees: *Peter Krauzberger, Daniel Marques, Jean Kaplansky, Volker
> Sorge, Sam Dooley, Charles LaPierre,  Kyrce Swenson
>
> *Scribe:* Kyrce Swenson
>
>
>
> -----
>
>
>
> *Peter: *What can improve and give feedback on layout requirements so
> that other web standards can be influenced by the WG?
>
>
>
> Collect use cases.
>
>
>
> Some contact already with the CSS working group, Including actual issue
> that MathJAX needs to respond to.
>
>
>
> Link in issue to codepen example to sketch out the basic problem: [1] Two
> dimensional content in inline content. Must be aligned with the baseline.
> In CSS only the top or the bottom can be aligned to the baseline.. No tools
> for something like a simple fraction, etc. This example was trying to
> explain this problem. Current solutions all require manual baseline fixing
> and shifts.
>
>
>
> This takes time and adds complexity. We need a way to tell CSS what should
> be at the baseline level.
>
>
>
> *Dani**: *The limits of the technology are MathJAX and we can use MathML
> directly in FF, and there are solutions from Wiris. Be able to do
> mathematics using only html5 + css. We need to be able to tell the CSS
> people to convince them.
>
>
>
> *Peter: *
>
> there's also KaTeX, MathQuill, and a bunch of hobby projects.
>
>
>
> *Peter* identify use cases that are broader than mathematical. Example:
> aligned SVGs inline because they had some textual content. Wanted to align
> the text not the image  [2]
>
>
>
> Little chance that this will be something only math needs. These
> challenges are interesting in a general sense as well.
>
>
>
> *Volker: *Right now we are talking about vertical growth not ascenders
> and descenders growing. More serious problem: Left to Right layout you have
> to change the layout while you are rendering a stretchy character.  Hard to
> describe but obvious when i see it.
>
>
>
> Fraction as a vertical shift. Potentiallyl two directions. To render a
> line you go from the left to the right. Once the fraction grows then you
> have to go back and start stretching your brackets,  or similar. Not
> supported by CSS.
>
>
>
> *Jean:  *re: CSS and the need to go forward and back... You're talking
> about multiple runs through to create one rendition.
>
>
>
> Browsers don't do this stuff. Formatting engines do.
>
>
>
> I could see mathJax or a web service doing this, but think the browser
> vendors will kick and scream over the request.
>
>
>
> *Volker: * So meaning that there's no reason to have this in the CSS
> spec?  Yes they will but there might be other ways of doing this. How do I
> style my parent element based on whether or not it has a particular child?
>
>
>
> *Jean: *Choose your battles? Do you think you can get vendors on board
> with it in the spec?
>
>
>
> Right. Conditional stuff. But again - its the ability to look forward and
> look back.
>
>
>
> *Volker: *goal to get things in the spec? or figure out what is needed?
>
>
>
> Browsers aren't good at looking forward and look back in declarative
> languages.
>
>
>
> *Peter: *First step to collect what problems we see. But next steps are
> to identify the right pieces to tackle. Might be more sensible to solve
> with SVG group.
>
>
>
> *Dani:  *Better to discuss how to discuss the examples? Wiki?
>
>
>
> *Peter: *just use the github issue tracker with a label -- individual
> issues labeled as layout.
>
>
>
> *Jean: *Thumbs up for a wiki - maybe a github page?
>
> Why not a github wiki page so we can see everything in context?
>
>
>
> *Peter: *does not allow to inject CSS. Not enough control.
>
>
>
> *Dani: *what is the idea to work collaboratively? people just fetch the
> file and edit it?
>
>
>
> *Peter:* just go to edit file and make a pull request? Lots of things
> available via the web interface.
>
>
>
> *Dani: * better to have each of its problems on its own page.
>
>
>
> *Peter: *if we split it on the issue tracker we can actually help people
> give feedback if they think it is a priority to them.  Not expecting
> hundreds of people however.
>
>
>
> *Dani*: at the point that something is written, more people who are
> interested will join.
>
>
>
> [Peter had to leave. ]
>
>
>
> *Dani: *do we want to continue or just speak in two weeks?
>
>
>
> Decision was made to speak in two weeks.  Dani will reformat and send
> examples.
>
>
>
> [1] https://github.com/w3c/csswg-drafts/issues/1339
>
> [2] https://w3c.github.io/mathonwebpages/examples/display/html5.html
>
>
>
> --
>
> *Kyrce Swenson*
>
> Solutions Manager
> C4 Semantic Markup: Tooling & Players
> C5 Structured Authoring: Proofing
>
>
>
> Pearson PLC
>
> 221 River Street, Second Floor
> Hoboken, NJ 07030 USA
>
> VM: +1 (201) 236 5611 <(201)%20236-5611>
> M: +1 (973) 744-0741 <(973)%20744-0741>
> kyrce.swenson@pearson.com
>
>
>
>
>
> [image: Pearson]
>
> [image: Pearson Tagline]
>
>
>
> ᐧ
>


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.