subject:"Re\: \[blink\-dev\] Intent to Ship\: MathML"

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

2023-07-12 Thread Daniel Bratell


LGTM3

/Daniel

On 2023-07-12 17:26, Yoav Weiss wrote:

LGTM2

On Wed, Jul 12, 2023 at 5:21 PM Mike Taylor  
wrote:


LGTM1 - seems like an obvious interop win.

On 7/12/23 4:31 AM, Frédéric Wang wrote:



Hello,

This is actually an intent to ship (sorry for sending email with
the wrong title).

To summarize a bit conversations, columnspan/rowspan was
something that was requested by web developers and is used in
existing documents. We cannot just say "use CSS instead" as they
are no equivalent properties.

Initially, we wanted to have this in the initial MathML
implementation but things were postponed because we needed to
decide between "make things more compatible with HTML" (i.e.
colspan/rowspan names) or "make things backward compatible with
MathML3" (i.e. columnspan/rowspan names). Given the latter is
already implemented by Firefox/WebKit and used in existing
documents and tools we decided to go with the latter (Mozilla
also positioned negatively about changing the name).



-



Contact emails

fw...@chromium.org


Explainer

None


Specification

https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd


Summary

Implement attributes to specify the number of columns and rows
that a MathML table cell is to span. This is similar to HTML
colspan/rowspan attributes and does not have equivalent CSS
properties.



Blink component

Blink>MathML





TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility



/Gecko/: Shipped/Shipping

(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility)
Mozilla positioned negatively about renaming
https://github.com/mozilla/standards-positions/issues/74

(Note: this should be
https://github.com/mozilla/standards-positions/issues/743)



/WebKit/: Shipped/Shipping

(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility)


/Web developers/: Positive

/Other signals/:


WebView application risks

Does this intent deprecate or change behavior of existing APIs,
such that it has potentially high risk for Android WebView-based
applications?



Debuggability



Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

Yes
Tests are added in
https://chromium-review.googlesource.com/c/chromium/src/+/4061476
However, advanced parsing such as checking the max limits 1000
and 65534 defined in HTML is a bit tedious as MathML does not
have an IDL for tables yet (
https://github.com/w3c/mathml-core/issues/166#issuecomment-1411721093


) so for now they are written as internal tests.


Flag name on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links to
known github issues in the project for the feature specification)
whose resolution may introduce web compat/interop risk (e.g.,
changing to naming or structure of the API in a
non-backward-compatible way).



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5157467960377344


Links to previous Intent discussions

Intent to Experiment:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2603ac64-2367-434f-cee3-42b3d9111639%40igalia.com



This intent message was generated by Chrome Platform Status
.


-- 
Frédéric Wang
-- 
You received this message because you are subscribed to the

Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3ada6e8-03f7-57e6-7b63-9ccf3d9a4440%40igalia.com

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

2023-07-12 Thread Yoav Weiss

LGTM2

On Wed, Jul 12, 2023 at 5:21 PM Mike Taylor  wrote:

> LGTM1 - seems like an obvious interop win.
>
> On 7/12/23 4:31 AM, Frédéric Wang wrote:
>
> Hello,
>
> This is actually an intent to ship (sorry for sending email with the wrong
> title).
>
> To summarize a bit conversations, columnspan/rowspan was something that
> was requested by web developers and is used in existing documents. We
> cannot just say "use CSS instead" as they are no equivalent properties.
>
> Initially, we wanted to have this in the initial MathML implementation but
> things were postponed because we needed to decide between "make things more
> compatible with HTML" (i.e. colspan/rowspan names) or "make things backward
> compatible with MathML3" (i.e. columnspan/rowspan names). Given the latter
> is already implemented by Firefox/WebKit and used in existing documents and
> tools we decided to go with the latter (Mozilla also positioned negatively
> about changing the name).
>
>
> -
>
> Contact emails fw...@chromium.org
>
> Explainer None
>
> Specification
> https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd
>
> Summary
>
> Implement attributes to specify the number of columns and rows that a
> MathML table cell is to span. This is similar to HTML colspan/rowspan
> attributes and does not have equivalent CSS properties.
>
>
> Blink component Blink>MathML
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> *Gecko*: Shipped/Shipping (
> https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility)
> Mozilla positioned negatively about renaming
> https://github.com/mozilla/standards-positions/issues/74
>
> (Note: this should be
> https://github.com/mozilla/standards-positions/issues/743)
>
>
>
> *WebKit*: Shipped/Shipping (
> https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility)
>
>
> *Web developers*: Positive
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
> Debuggability
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes
> Tests are added in
> https://chromium-review.googlesource.com/c/chromium/src/+/4061476
> However, advanced parsing such as checking the max limits 1000 and 65534
> defined in HTML is a bit tedious as MathML does not have an IDL for tables
> yet (
> https://github.com/w3c/mathml-core/issues/166#issuecomment-1411721093
> 
>  )
> so for now they are written as internal tests. Flag name on chrome://flags
>
> Finch feature name
>
> Non-finch justification None
>
> Requires code in //chrome? False
>
> Estimated milestones
> Shipping on desktop 117
> Shipping on Android 117
> Shipping on WebView 117
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5157467960377344
>
> Links to previous Intent discussions Intent to Experiment:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2603ac64-2367-434f-cee3-42b3d9111639%40igalia.com
>
>
> This intent message was generated by Chrome Platform Status
> .
>
>
> --
> Frédéric Wang
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3ada6e8-03f7-57e6-7b63-9ccf3d9a4440%40igalia.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8a331320-cb6b-e102-05f9-d38abcb80a7a%40chromium.org
>

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

2023-07-12 Thread Mike Taylor


LGTM1 - seems like an obvious interop win.

On 7/12/23 4:31 AM, Frédéric Wang wrote:



Hello,

This is actually an intent to ship (sorry for sending email with the 
wrong title).


To summarize a bit conversations, columnspan/rowspan was something 
that was requested by web developers and is used in existing 
documents. We cannot just say "use CSS instead" as they are no 
equivalent properties.


Initially, we wanted to have this in the initial MathML implementation 
but things were postponed because we needed to decide between "make 
things more compatible with HTML" (i.e. colspan/rowspan names) or 
"make things backward compatible with MathML3" (i.e. 
columnspan/rowspan names). Given the latter is already implemented by 
Firefox/WebKit and used in existing documents and tools we decided to 
go with the latter (Mozilla also positioned negatively about changing 
the name).




-



Contact emails

fw...@chromium.org


Explainer

None


Specification

https://w3c.github.io/mathml-core/#entry-in-table-or-matrix-mtd


Summary

Implement attributes to specify the number of columns and rows that a 
MathML table cell is to span. This is similar to HTML colspan/rowspan 
attributes and does not have equivalent CSS properties.




Blink component

Blink>MathML 
MathML> 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility



/Gecko/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 
Mozilla positioned negatively about renaming 
https://github.com/mozilla/standards-positions/issues/74
(Note: this should be 
https://github.com/mozilla/standards-positions/issues/743)



/WebKit/: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mtd#browser_compatibility) 



/Web developers/: Positive

/Other signals/:


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such 
that it has potentially high risk for Android WebView-based applications?




Debuggability



Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

Yes
Tests are added in 
https://chromium-review.googlesource.com/c/chromium/src/+/4061476 
However, advanced parsing such as checking the max limits 1000 and 
65534 defined in HTML is a bit tedious as MathML does not have an IDL 
for tables yet ( 
https://github.com/w3c/mathml-core/issues/166#issuecomment-1411721093 
 
) so for now they are written as internal tests.



Flag name on chrome://flags



Finch feature name



Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 117

Shipping on Android 117

Shipping on WebView 117



Anticipated spec changes

Open questions about a feature may be a source of future web compat or 
interop issues. Please list open issues (e.g. links to known github 
issues in the project for the feature specification) whose resolution 
may introduce web compat/interop risk (e.g., changing to naming or 
structure of the API in a non-backward-compatible way).




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5157467960377344


Links to previous Intent discussions

Intent to Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2603ac64-2367-434f-cee3-42b3d9111639%40igalia.com 




This intent message was generated by Chrome Platform Status 
.



--
Frédéric Wang
--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3ada6e8-03f7-57e6-7b63-9ccf3d9a4440%40igalia.com 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8a331320-cb6b-e102-05f9-d38abcb80a7a%40chromium.org.

Re: [blink-dev] Intent to Ship: MathML

2022-10-25 Thread Frédéric Wang

Thanks. I'll upload a CL for that. BTW, MathML now has a base::Feature flag.

On 24/10/2022 10:05, Yoav Weiss wrote:
I think it makes sense to flip it on now, and turn it off if printing
NG gets reverted.

On Mon, Oct 24, 2022 at 9:14 AM Frédéric Wang wrote:

Hello,

Reading [1], I don't think any distinction between pure blink
features or UI/browser features for "feature freeze". I understand
the only requirement is to have code complete, but probably
turning on the flag after the branch point is fine.

However [2] also mentions "Two weeks prior to the branch point,
avoid committing big and risky changes or enabling non-trivial
features."

So what would be the suggestion of the code owners here, should we
enable MathML before the feature freeze for M109 (October 27)? or
can we wait a bit before the branch point (Nov 10)?

[1]

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/process/release_cycle.md

[2]

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/release_branch_guidance.md

--
Frédéric Wang

--
You received this message because you are subscribed to the Google

Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f814e1f5-93be-bc05-3dd3-71dbdbbf8455%40igalia.com

--
Frédéric Wang

--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/faa87540-70ae-0c36-293c-03bab18794d8%40igalia.com.

Re: [blink-dev] Intent to Ship: MathML

2022-10-24 Thread Yoav Weiss

I think it makes sense to flip it on now, and turn it off if printing NG
gets reverted.

On Mon, Oct 24, 2022 at 9:14 AM Frédéric Wang  wrote:

> Hello,
>
> Reading [1], I don't think any distinction between pure blink features or
> UI/browser features for "feature freeze". I understand the only requirement
> is to have code complete, but probably turning on the flag after the branch
> point is fine.
>
> However [2] also mentions "Two weeks prior to the branch point, avoid
> committing big and risky changes or enabling non-trivial features."
>
> So what would be the suggestion of the code owners here, should we enable
> MathML before the feature freeze for M109 (October 27)? or can we wait a
> bit before the branch point (Nov 10)?
>
> [1]
> https://chromium.googlesource.com/chromium/src/+/HEAD/docs/process/release_cycle.md
>
> [2]
> https://chromium.googlesource.com/chromium/src/+/HEAD/docs/release_branch_guidance.md
>
> --
> Frédéric Wang
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f814e1f5-93be-bc05-3dd3-71dbdbbf8455%40igalia.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUhuD4zPQBSmrcjH7ZJxCdbbVof4bA-nT1JBJ8pDk9-mA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: MathML

2022-10-24 Thread Frédéric Wang


Hello,

Reading [1], I don't think any distinction between pure blink features 
or UI/browser features for "feature freeze". I understand the only 
requirement is to have code complete, but probably turning on the flag 
after the branch point is fine.


However [2] also mentions "Two weeks prior to the branch point, avoid 
committing big and risky changes or enabling non-trivial features."


So what would be the suggestion of the code owners here, should we 
enable MathML before the feature freeze for M109 (October 27)? or can we 
wait a bit before the branch point (Nov 10)?


[1] 
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/process/release_cycle.md


[2] 
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/release_branch_guidance.md


--
Frédéric Wang

--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f814e1f5-93be-bc05-3dd3-71dbdbbf8455%40igalia.com.

Re: [blink-dev] Intent to Ship: MathML

2022-10-14 Thread Chris Harrelson

On Fri, Oct 14, 2022 at 12:26 AM Frédéric Wang  wrote:

> On 14/10/2022 09:17, Manuel Rego Casasnovas wrote:
>
> On 14/10/2022 07:53, Frédéric Wang wrote:
>
> If I understand correctly [3], it is integrated in M108 (branched
> yesterday) and the feature freeze for M109 will be October 27. So we
> have two weeks to decide to enable MathML or not (if an issue with
> LayoutNGPrinting is detected) [4].
>
> I believe "feature freeze" on that page is related to Chromium itself,
> things like UI features and browser features. But not related to Blink
> features, they sometimes get shipped just before the branch point, and
> after the feature freeze date.
>
> Thanks for the clarification. As a minor note, as mentioned in the
> original email there is a small UI change for selecting the preferred math
> font (but it's not a big deal if this one is postponed after the initial
> shipping of MathML):
>
> On 22/06/2022 23:48, Frédéric Wang wrote:
>
> Requires code in //chrome? True (this is only to implement support for
> “font-family: math”, which has a user preference menu for math font, see
> https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy
> ).
>
>
> So we have some extra time to check if LayoutNGPrinting gets some
> trouble or not. And if it sticks we could enable MathML too (maybe
> adding a base feature [*] in case it needs to be disabled later).
>
> Yes, I was thinking about that too. I wonder what API owners think about
> it... Should we introduce a chromium feature now in any case? (for example
> that will be useful to enable the math font UI when MathML is enabled,
> something we can't do right now with only a blink flag).
>

As of a recent policy change, new features need a base::Feature flag
regardless, so that they can be rolled back easily in case of problems.


> --
> Frédéric Wang
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/70ee3d94-7f60-c8dd-ccaf-0968fe36295e%40igalia.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8K1ndxhuuguCFbb61OvxwA-FdEsW0vd%2BRweSoupPyLtQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: MathML

2022-10-14 Thread Frédéric Wang

On 14/10/2022 09:17, Manuel Rego Casasnovas wrote:

On 14/10/2022 07:53, Frédéric Wang wrote:

If I understand correctly [3], it is integrated in M108 (branched
yesterday) and the feature freeze for M109 will be October 27. So we
have two weeks to decide to enable MathML or not (if an issue with
LayoutNGPrinting is detected) [4].

I believe "feature freeze" on that page is related to Chromium itself,
things like UI features and browser features. But not related to Blink
features, they sometimes get shipped just before the branch point, and
after the feature freeze date.
Thanks for the clarification. As a minor note, as mentioned in the
original email there is a small UI change for selecting the preferred
math font (but it's not a big deal if this one is postponed after the
initial shipping of MathML):

On 22/06/2022 23:48, Frédéric Wang wrote:

Requires code in //chrome?

True (this is only to implement support for “font-family: math”, which
has a user preference menu for math font, see
https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy).

So we have some extra time to check if LayoutNGPrinting gets some
trouble or not. And if it sticks we could enable MathML too (maybe
adding a base feature [*] in case it needs to be disabled later).
Yes, I was thinking about that too. I wonder what API owners think about
it... Should we introduce a chromium feature now in any case? (for
example that will be useful to enable the math font UI when MathML is
enabled, something we can't do right now with only a blink flag).

--
Frédéric Wang

Re: [blink-dev] Intent to Ship: MathML

2022-10-14 Thread Manuel Rego Casasnovas

On 14/10/2022 07:53, Frédéric Wang wrote:
> If I understand correctly [3], it is integrated in M108 (branched
> yesterday) and the feature freeze for M109 will be October 27. So we
> have two weeks to decide to enable MathML or not (if an issue with
> LayoutNGPrinting is detected) [4].

I believe "feature freeze" on that page is related to Chromium itself,
things like UI features and browser features. But not related to Blink
features, they sometimes get shipped just before the branch point, and
after the feature freeze date.

So we have some extra time to check if LayoutNGPrinting gets some
trouble or not. And if it sticks we could enable MathML too (maybe
adding a base feature [*] in case it needs to be disabled later).

Cheers,
  Rego

[*]
https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#generate-a-instance-from-a-blink-feature

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ae4de693-d4fd-27bc-06d9-b71e4f9e3348%40igalia.com.

Re: [blink-dev] Intent to Ship: MathML

2022-09-14 Thread Mike Taylor

LGTM3

On 9/14/22 8:37 AM, Yoav Weiss wrote:

LGTM2 with the above plan, assuming printing sticks.

On Wednesday, September 14, 2022 at 5:36:11 PM UTC+2 Chris Harrelson
wrote:

Printing NG looks like it will ship in M108.

LGTM1 to ship MathML in M109 (just in case there is an issue that
causes printing to be reverted).

On Mon, Aug 8, 2022 at 12:25 PM Daniel Herr
wrote:

There are some new css properties included in MathML, correct?
Then one possibility for feature detection could be to provide
developers the ability to use CSS @supports inside print media
stylesheets to determine whether MathML is available in that
context.

@supports (display: math) { /* or other MathML property */
/* not applied in Chromium */
}

@supports (display: math) { /* or other MathML property */
/* applied in Chromium and other browsers */
}

On Friday, July 8, 2022 at 2:54:36 PM UTC-4 Neil Soiffer wrote:

I don't mean to diminish the importance of print -- I'm
old enough that I /occasionally /print things out.
However, the situation now is that neither display nor
print of MathML works natively in Chromium. In turning on
MathML display, 99.99% (or more?) people will be happy to
have fast display of math; some small number of people
won’t be happy when they try to print it out.

For that group and the publishers that put out material
that tests whether MathML is available in the browser,
this would be a regression. It would be interesting to
know if any sites sniff for MathML support, or whether
they simply look at the browser and decide based on their
knowledge of support. I know of at least one site that
does the latter and so they wouldn’t suffer a regression.
Maybe all the sites do this because it is easy and
reliable? Even if there is no regression, please don't put
printing math on the back burner in terms of priorities.

Benjamin mentioned Wikipedia. I can’t speak for what
Wikipedia would do, but as long as they know that printing
is broken in Chromium, any decision to turn on direct
MathML rendering is their call, not Chromium’s. I suspect
given their concern that Wikipedia renders properly almost
everywhere, it will be a long time before they make a
switch. Right now, despite Firefox’s long support for
MathML, they still use SVG with hidden MathML on it.

On the supposition that there are some sites that sniff
for MathML, I think Benjamin’s suggestions are good. I
don’t know how feasible it is to put up a dialog stating
that printing math is not currently supported in Chromium,
but doing that with some suggested workarounds would I
think be a viable alternative until print is supported.
One workaround would be to suggest they download an
extension (that would need to be written) that loads
MathJax into the page in question when clicked. Another
suggestion could be to read the page with Firefox ;-). I’m
sure there are many more clever people on this list than I
am who might have other suggestions for workarounds.

My suggestion is to follow the somewhat worn out but still
very true trope: "don't let perfect be the enemy of the
good". People have been waiting years and years to get
math to display natively in Chromium and now it is ready
to happen. Please try to find a simple stopgap and get
this long awaited feature turned on.

You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org
.

To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc2a4fab-823d-467f-949e-385a150fa5fen%40chromium.org

--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/260d7448-c8cf-4503-99bb-8918bda112bbn%40chromium.org

Re: [blink-dev] Intent to Ship: MathML

2022-09-14 Thread Yoav Weiss

LGTM2 with the above plan, assuming printing sticks.

On Wednesday, September 14, 2022 at 5:36:11 PM UTC+2 Chris Harrelson wrote:

> Printing NG looks like it will ship in M108.
>
> LGTM1 to ship MathML in M109 (just in case there is an issue that causes 
> printing to be reverted).
>
> On Mon, Aug 8, 2022 at 12:25 PM Daniel Herr  
> wrote:
>
>> There are some new css properties included in MathML, correct? Then one 
>> possibility for feature detection could be to provide developers the 
>> ability to use CSS @supports inside print media stylesheets to determine 
>> whether MathML is available in that context.
>>
>> 
>> @supports (display: math) { /* or other MathML property */
>>   /* not applied in Chromium */
>> }
>>
>> 
>> @supports (display: math) { /* or other MathML property */
>>   /* applied in Chromium and other browsers */
>> }
>>
>> On Friday, July 8, 2022 at 2:54:36 PM UTC-4 Neil Soiffer wrote:
>>
>>> I don't mean to diminish the importance of print -- I'm old enough that 
>>> I *occasionally *print things out. However, the situation now is that 
>>> neither display nor print of MathML works natively in Chromium. In turning 
>>> on MathML display, 99.99% (or more?) people will be happy to have fast 
>>> display of math; some small number of people won’t be happy when they try 
>>> to print it out.
>>>
>>> For that group and the publishers that put out material that tests 
>>> whether MathML is available in the browser, this would be a regression. It 
>>> would be interesting to know if any sites sniff for MathML support, or 
>>> whether they simply look at the browser and decide based on their knowledge 
>>> of support. I know of at least one site that does the latter and so they 
>>> wouldn’t suffer a regression. Maybe all the sites do this because it is 
>>> easy and reliable? Even if there is no regression, please don't put 
>>> printing math on the back burner in terms of priorities.
>>>
>>> Benjamin mentioned Wikipedia. I can’t speak for what Wikipedia would do, 
>>> but as long as they know that printing is broken in Chromium, any 
>>> decision to turn on direct MathML rendering is their call, not Chromium’s. 
>>> I suspect given their concern that Wikipedia renders properly almost 
>>> everywhere, it will be a long time before they make a switch. Right now, 
>>> despite Firefox’s long support for MathML, they still use SVG with hidden 
>>> MathML on it.
>>>
>>> On the supposition that there are some sites that sniff for MathML, I 
>>> think Benjamin’s suggestions are good. I don’t know how feasible it is to 
>>> put up a dialog stating that printing math is not currently supported in 
>>> Chromium, but doing that with some suggested workarounds would I think be a 
>>> viable alternative until print is supported. One workaround would be to 
>>> suggest they download an extension (that would need to be written) that 
>>> loads MathJax into the page in question when clicked. Another suggestion 
>>> could be to read the page with Firefox ;-). I’m sure there are many more 
>>> clever people on this list than I am who might have other suggestions for 
>>> workarounds.
>>>
>>> My suggestion is to follow the somewhat worn out but still very true 
>>> trope: "don't let perfect be the enemy of the good". People have been 
>>> waiting years and years to get math to display natively in Chromium and now 
>>> it is ready to happen. Please try to find a simple stopgap and get this 
>>> long awaited feature turned on.
>>>
>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to blink-dev+unsubscr...@chromium.org.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc2a4fab-823d-467f-949e-385a150fa5fen%40chromium.org
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/260d7448-c8cf-4503-99bb-8918bda112bbn%40chromium.org.

Re: [blink-dev] Intent to Ship: MathML

2022-09-14 Thread Chris Harrelson

Printing NG looks like it will ship in M108.

LGTM1 to ship MathML in M109 (just in case there is an issue that causes
printing to be reverted).

On Mon, Aug 8, 2022 at 12:25 PM Daniel Herr 
wrote:

> There are some new css properties included in MathML, correct? Then one
> possibility for feature detection could be to provide developers the
> ability to use CSS @supports inside print media stylesheets to determine
> whether MathML is available in that context.
>
> 
> @supports (display: math) { /* or other MathML property */
>   /* not applied in Chromium */
> }
>
> 
> @supports (display: math) { /* or other MathML property */
>   /* applied in Chromium and other browsers */
> }
>
> On Friday, July 8, 2022 at 2:54:36 PM UTC-4 Neil Soiffer wrote:
>
>> I don't mean to diminish the importance of print -- I'm old enough that I 
>> *occasionally
>> *print things out. However, the situation now is that neither display
>> nor print of MathML works natively in Chromium. In turning on MathML
>> display, 99.99% (or more?) people will be happy to have fast display of
>> math; some small number of people won’t be happy when they try to print it
>> out.
>>
>> For that group and the publishers that put out material that tests
>> whether MathML is available in the browser, this would be a regression. It
>> would be interesting to know if any sites sniff for MathML support, or
>> whether they simply look at the browser and decide based on their knowledge
>> of support. I know of at least one site that does the latter and so they
>> wouldn’t suffer a regression. Maybe all the sites do this because it is
>> easy and reliable? Even if there is no regression, please don't put
>> printing math on the back burner in terms of priorities.
>>
>> Benjamin mentioned Wikipedia. I can’t speak for what Wikipedia would do,
>> but as long as they know that printing is broken in Chromium, any
>> decision to turn on direct MathML rendering is their call, not Chromium’s.
>> I suspect given their concern that Wikipedia renders properly almost
>> everywhere, it will be a long time before they make a switch. Right now,
>> despite Firefox’s long support for MathML, they still use SVG with hidden
>> MathML on it.
>>
>> On the supposition that there are some sites that sniff for MathML, I
>> think Benjamin’s suggestions are good. I don’t know how feasible it is to
>> put up a dialog stating that printing math is not currently supported in
>> Chromium, but doing that with some suggested workarounds would I think be a
>> viable alternative until print is supported. One workaround would be to
>> suggest they download an extension (that would need to be written) that
>> loads MathJax into the page in question when clicked. Another suggestion
>> could be to read the page with Firefox ;-). I’m sure there are many more
>> clever people on this list than I am who might have other suggestions for
>> workarounds.
>>
>> My suggestion is to follow the somewhat worn out but still very true
>> trope: "don't let perfect be the enemy of the good". People have been
>> waiting years and years to get math to display natively in Chromium and now
>> it is ready to happen. Please try to find a simple stopgap and get this
>> long awaited feature turned on.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc2a4fab-823d-467f-949e-385a150fa5fen%40chromium.org
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_TJC2bLMwq9EaJh%2BJ5Ki6fhuAQ-LgLRQErYdSp%3DTg7Eg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: MathML

2022-08-08 Thread Daniel Herr

There are some new css properties included in MathML, correct? Then one 
possibility for feature detection could be to provide developers the 
ability to use CSS @supports inside print media stylesheets to determine 
whether MathML is available in that context.


@supports (display: math) { /* or other MathML property */
  /* not applied in Chromium */
}


@supports (display: math) { /* or other MathML property */
  /* applied in Chromium and other browsers */
}

On Friday, July 8, 2022 at 2:54:36 PM UTC-4 Neil Soiffer wrote:

> I don't mean to diminish the importance of print -- I'm old enough that I 
> *occasionally 
> *print things out. However, the situation now is that neither display nor 
> print of MathML works natively in Chromium. In turning on MathML display, 
> 99.99% (or more?) people will be happy to have fast display of math; some 
> small number of people won’t be happy when they try to print it out.
>
> For that group and the publishers that put out material that tests whether 
> MathML is available in the browser, this would be a regression. It would be 
> interesting to know if any sites sniff for MathML support, or whether they 
> simply look at the browser and decide based on their knowledge of support. 
> I know of at least one site that does the latter and so they wouldn’t 
> suffer a regression. Maybe all the sites do this because it is easy and 
> reliable? Even if there is no regression, please don't put printing math on 
> the back burner in terms of priorities.
>
> Benjamin mentioned Wikipedia. I can’t speak for what Wikipedia would do, 
> but as long as they know that printing is broken in Chromium, any 
> decision to turn on direct MathML rendering is their call, not Chromium’s. 
> I suspect given their concern that Wikipedia renders properly almost 
> everywhere, it will be a long time before they make a switch. Right now, 
> despite Firefox’s long support for MathML, they still use SVG with hidden 
> MathML on it.
>
> On the supposition that there are some sites that sniff for MathML, I 
> think Benjamin’s suggestions are good. I don’t know how feasible it is to 
> put up a dialog stating that printing math is not currently supported in 
> Chromium, but doing that with some suggested workarounds would I think be a 
> viable alternative until print is supported. One workaround would be to 
> suggest they download an extension (that would need to be written) that 
> loads MathJax into the page in question when clicked. Another suggestion 
> could be to read the page with Firefox ;-). I’m sure there are many more 
> clever people on this list than I am who might have other suggestions for 
> workarounds.
>
> My suggestion is to follow the somewhat worn out but still very true 
> trope: "don't let perfect be the enemy of the good". People have been 
> waiting years and years to get math to display natively in Chromium and now 
> it is ready to happen. Please try to find a simple stopgap and get this 
> long awaited feature turned on.
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc2a4fab-823d-467f-949e-385a150fa5fen%40chromium.org.

Re: [blink-dev] Intent to Ship: MathML

2022-07-08 Thread Neil Soiffer

I don't mean to diminish the importance of print -- I'm old enough that I
*occasionally
*print things out. However, the situation now is that neither display nor
print of MathML works natively in Chromium. In turning on MathML display,
99.99% (or more?) people will be happy to have fast display of math; some
small number of people won’t be happy when they try to print it out.

For that group and the publishers that put out material that tests whether
MathML is available in the browser, this would be a regression. It would be
interesting to know if any sites sniff for MathML support, or whether they
simply look at the browser and decide based on their knowledge of support.
I know of at least one site that does the latter and so they wouldn’t
suffer a regression. Maybe all the sites do this because it is easy and
reliable? Even if there is no regression, please don't put printing math on
the back burner in terms of priorities.

Benjamin mentioned Wikipedia. I can’t speak for what Wikipedia would do,
but as long as they know that printing is broken in Chromium, any decision
to turn on direct MathML rendering is their call, not Chromium’s. I suspect
given their concern that Wikipedia renders properly almost everywhere, it
will be a long time before they make a switch. Right now, despite Firefox’s
long support for MathML, they still use SVG with hidden MathML on it.

On the supposition that there are some sites that sniff for MathML, I think
Benjamin’s suggestions are good. I don’t know how feasible it is to put up
a dialog stating that printing math is not currently supported in Chromium,
but doing that with some suggested workarounds would I think be a viable
alternative until print is supported. One workaround would be to suggest
they download an extension (that would need to be written) that loads
MathJax into the page in question when clicked. Another suggestion could be
to read the page with Firefox ;-). I’m sure there are many more clever
people on this list than I am who might have other suggestions for
workarounds.

My suggestion is to follow the somewhat worn out but still very true trope:
"don't let perfect be the enemy of the good". People have been waiting
years and years to get math to display natively in Chromium and now it is
ready to happen. Please try to find a simple stopgap and get this long
awaited feature turned on.

Re: [blink-dev] Intent to Ship: MathML

2022-07-01 Thread Benjamin Aster

Personally, I don't think it's a good idea to ship MathML with missing
printing support at all. Users definitely expect printing mathematical
documents (and saving them as PDFs!) to be working. Many websites use
feature detection (something like `"MathMLElement" in window`) to check if
MathML is supported and use polyfills like MathJax if not. In this case,
the website would then display non-printable MathML formulas, but it would
be better if the website would still use the MathJax polyfill so that
printing would work. For example, Wikipedia might switch to MathML formulas
some time after stable MathML support in Chromium, and users would be quite
confused that if they print the article or save it as a PDF, the formulas
aren't rendered correctly any more.
If you want to ship MathML before printing works anyway, I'd at least love
to the see the following two things temporarily implemented:
- A warning message on the printing dialog, telling the user that printing
mathematical formulas is not yet supported.
- A non-standard way for the developer to feature-detect if printing
MathML is not supported (I'm thinking of something like
`MathMLElement.webkitPrintingUnsupported == true`), so that you could still
use MathJax for websites where users are likely to print them.

Re: [blink-dev] Intent to Ship: MathML

2022-07-01 Thread Frédéric Wang

Just to follow-up on two points raised by Daniel:

On 25/06/2022 14:09, Frédéric Wang wrote:
You mentioned fuzzy testing. Do the fuzzing tools have support for
mathml elements? If not, you should probably add a to-do item to
teach them.

MathML has been there for several years so I do expect (naively?) that
fuzzers have some kind of support already. My understanding is that
fuzzing tools can either generate data or "shuffle" from existing
input. For the latter, we have now a bunch of WPT tests with MathML to
feed the fuzzers and I believe these are particularly interesting to
cover edge cases with CSS, JS, etc. For the former, I thought that was
the case for https://github.com/MozillaSecurity/ or
https://github.com/renatahodovan/ but can't find any up-to-date repo
for MathML currently, so I agree we need to work on that.
So we've been contacting various security people doing browser fuzzing
to make sure their tools handle MathML and are aware of MathML Core.
We've also spent some time focusing more precisely on Chromium-related
fuzzing, basically increasing code coverage of "in-process guided
fuzzing" for low-level font modules and teaching MathML Core grammar to
DOM fuzzers. For details please read
https://bugs.chromium.org/p/chromium/issues/detail?id=1340884

What is the situation for developers that learn about this and want
to start using it? Are there good resources for learning how to write
MathML? I think a feature like this also deserves some attention when
it lands. Maybe that will happen by itself, or maybe someone needs to
initiate it. That info should probably also mention initial
limitations like printing, (multi-column?) and non-Core.

Similarly, MathML has been there for a while so there is already a
bunch of resource available about MathML (e.g. MDN to mention the
obvious one) as wellas editors & converters to generate it, polyfills
to cover browser's limitations, etc but I agree they will probably
need a refresh since (1) we implement a core subset (2) we are moving
to an extensible approach based on web technologies (3) there are
chrome-specific bugs like the printing one.

Also started to update MDN e.g.
https://github.com/mdn/content/pull/17735
https://github.com/mdn/content/pull/17812

Of course, we can probably get help from the MathML community to update it.

--
Frédéric Wang

Re: [blink-dev] Intent to Ship: MathML

2022-06-30 Thread Daniel Bratell

We discussed that option in the API Owner meeting and did not really 
like it. If there are no better alternatives, maybe it would be good 
enough but the typical people to encounter printing problems would 
probably not discover it.


I hope it's possible to find something more obvious so we don't have to 
go that route. Missing printing and the effects that may have on users 
was the only real blocking issue we identified.


/Daniel

On 2022-06-30 11:43, slightlyoff via Chromestatus wrote:
Excited to see this moving forward. Happy to see this ship with 
printing caveats from Mike. For my part, even a console log message 
would suffice.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af1d8605e2a719d2%40google.com 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b18a5181-4524-6843-9d05-6fc8766a0478%40gmail.com.

Re: [blink-dev] Intent to Ship: MathML

2022-06-30 Thread slightlyoff via Chromestatus

Excited to see this moving forward. Happy to see this ship with printing 
caveats from Mike. For my part, even a console log message would suffice.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af1d8605e2a719d2%40google.com.

Re: [blink-dev] Intent to Ship: MathML

2022-06-29 Thread Mike West

I'm excited about shipping MathML. I don't think it's necessary for us to 
wait O(months) for printing to work correctly, but I do think it's critical 
for us to give users who try to print some way of understanding that the 
rendering failure is not their fault. It would be unfortunate if folks go 
through debugging, uninstalling/reinstalling printer drivers, etc. for 
something that we know isn't going to work *a priori*.

I'd be happy LGTMing any reasonable compromise for the short term. A 
variety of approaches could be reasonable: a warning note in the print 
dialog, jamming some "Aw, snap!" rendering into the printed page, a 
pre-printing `alert()` dialog, basically anything our friendly UX experts 
will approve.

-mike

On Tuesday, June 28, 2022 at 11:23:37 PM UTC+2 Brian Kardell wrote:

> [snip]
> > More about compatibility: Do you have any idea (guess really) of how
> > much of existing MathML content will "work" with just MathML Core? Is
> > it 99%, 90%, 50%, 10%?
>
> In addition to what Fred said about counters investigation,  I can add 
> that the MathML Refresh group (that spent about 2 years working toward this 
> and getting it back on a W3C rec track) was very interested in and focused 
> on this question.  We did a bunch of research, and we also asked people 
> with significant pools of MathML already to dig into some of it.   I guess 
> I can assure you that much effort spent toward finding an interoperable 
> subset that can give us a baseline for rendering the vast majority of 
> content that was actually achievable and yielded acceptable results with 
> 0-little effort for authors. 
>
> However,  it is a somewhat tricky question because, what does it mean to 
> "work" can vary (or maybe better, how does it 'fail').  So, for example, L1 
> does not include "math links". This turns out to be kind of trickily nested 
> in a whole bunch of related questions that would take some real additional 
> time to answer. Without answering them, you can still put a regular link 
> inside a token element.  Given that, if. you load up some older MathML that 
> includes links on the token elements, it will render the math, but not the 
> link. The working group decided that this was the right tradeoff, 
> because for many things, that's the most important part and it wasn't 
> getting done at all - so this is a dramatic improvement already. It fails 
> better. However, with L1 we now also have the tools to include, with very 
> little additional author effort just a little bit of transform or js 
> handlers to make 'work' like a link too (for purposes they care about) 
> until we can move beyond that.
>
> So, basically: It's hard to say with authority but the working group 
> itself has been both very cautious and pragmatic here.  They definitely 
> understand that even complete interoperability of L1 can't just make all 
> MathML ever written work.  They focused on making "the vast majority of 
> stuff great" and  making sure things outside that had a decent story too - 
> be that it "failing" in a better way natively or just having a very simple 
> remediation story, etc.
>
>
>
> On Saturday, June 25, 2022 at 8:09:25 AM UTC-4 fw...@igalia.com wrote:
>
>> On 24/06/2022 11:14, Daniel Bratell wrote: 
>> > 
>> > I'm really happy to see this coming along! Awesome work by everyone 
>> > involved! 
>> > 
>> Thanks! 
>> > 
>> > You mentioned fuzzy testing. Do the fuzzing tools have support for 
>> > mathml elements? If not, you should probably add a to-do item to teach 
>> > them. 
>> > 
>> MathML has been there for several years so I do expect (naively?) that 
>> fuzzers have some kind of support already. My understanding is that 
>> fuzzing tools can either generate data or "shuffle" from existing input. 
>> For the latter, we have now a bunch of WPT tests with MathML to feed the 
>> fuzzers and I believe these are particularly interesting to cover edge 
>> cases with CSS, JS, etc. For the former, I thought that was the case for 
>> https://github.com/MozillaSecurity/ or https://github.com/renatahodovan/ 
>> but can't find any up-to-date repo for MathML currently, so I agree we 
>> need to work on that. 
>> > 
>> > What is the situation for developers that learn about this and want to 
>> > start using it? Are there good resources for learning how to write 
>> > MathML? I think a feature like this also deserves some attention when 
>> > it lands. Maybe that will happen by itself, or maybe someone needs to 
>> > initiate it. That info should probably also mention initial 
>> > limitations like printing, (multi-column?) and non-Core. 
>> > 
>> Similarly, MathML has been there for a while so there is already a bunch 
>> of resource available about MathML (e.g. MDN to mention the obvious one) 
>> as wellas editors & converters to generate it, polyfills to cover 
>> browser's limitations, etc but I agree they will probably need a refresh 
>> since (1) we implement a core subset (2) we are moving to an

Re: [blink-dev] Intent to Ship: MathML

2022-06-28 Thread Brian Kardell

[snip]
> More about compatibility: Do you have any idea (guess really) of how
> much of existing MathML content will "work" with just MathML Core? Is
> it 99%, 90%, 50%, 10%?

In addition to what Fred said about counters investigation,  I can add that 
the MathML Refresh group (that spent about 2 years working toward this and 
getting it back on a W3C rec track) was very interested in and focused on 
this question.  We did a bunch of research, and we also asked people with 
significant pools of MathML already to dig into some of it.   I guess I can 
assure you that much effort spent toward finding an interoperable subset 
that can give us a baseline for rendering the vast majority of content that 
was actually achievable and yielded acceptable results with 0-little effort 
for authors. 

However,  it is a somewhat tricky question because, what does it mean to 
"work" can vary (or maybe better, how does it 'fail').  So, for example, L1 
does not include "math links". This turns out to be kind of trickily nested 
in a whole bunch of related questions that would take some real additional 
time to answer. Without answering them, you can still put a regular link 
inside a token element.  Given that, if. you load up some older MathML that 
includes links on the token elements, it will render the math, but not the 
link. The working group decided that this was the right tradeoff, 
because for many things, that's the most important part and it wasn't 
getting done at all - so this is a dramatic improvement already. It fails 
better. However, with L1 we now also have the tools to include, with very 
little additional author effort just a little bit of transform or js 
handlers to make 'work' like a link too (for purposes they care about) 
until we can move beyond that.

So, basically: It's hard to say with authority but the working group itself 
has been both very cautious and pragmatic here.  They definitely understand 
that even complete interoperability of L1 can't just make all MathML ever 
written work.  They focused on making "the vast majority of stuff great" 
and  making sure things outside that had a decent story too - be that it 
"failing" in a better way natively or just having a very simple remediation 
story, etc.

On Saturday, June 25, 2022 at 8:09:25 AM UTC-4 fw...@igalia.com wrote:

> On 24/06/2022 11:14, Daniel Bratell wrote:
> >
> > I'm really happy to see this coming along! Awesome work by everyone 
> > involved!
> >
> Thanks!
> >
> > You mentioned fuzzy testing. Do the fuzzing tools have support for 
> > mathml elements? If not, you should probably add a to-do item to teach 
> > them.
> >
> MathML has been there for several years so I do expect (naively?) that 
> fuzzers have some kind of support already. My understanding is that 
> fuzzing tools can either generate data or "shuffle" from existing input. 
> For the latter, we have now a bunch of WPT tests with MathML to feed the 
> fuzzers and I believe these are particularly interesting to cover edge 
> cases with CSS, JS, etc. For the former, I thought that was the case for 
> https://github.com/MozillaSecurity/ or https://github.com/renatahodovan/ 
> but can't find any up-to-date repo for MathML currently, so I agree we 
> need to work on that.
> >
> > What is the situation for developers that learn about this and want to 
> > start using it? Are there good resources for learning how to write 
> > MathML? I think a feature like this also deserves some attention when 
> > it lands. Maybe that will happen by itself, or maybe someone needs to 
> > initiate it. That info should probably also mention initial 
> > limitations like printing, (multi-column?) and non-Core.
> >
> Similarly, MathML has been there for a while so there is already a bunch 
> of resource available about MathML (e.g. MDN to mention the obvious one) 
> as wellas editors & converters to generate it, polyfills to cover 
> browser's limitations, etc but I agree they will probably need a refresh 
> since (1) we implement a core subset (2) we are moving to an extensible 
> approach based on web technologies (3) there are chrome-specific bugs 
> like the printing one.
>
> > More about compatibility: Do you have any idea (guess really) of how 
> > much of existing MathML content will "work" with just MathML Core? Is 
> > it 99%, 90%, 50%, 10%?
> >
> I'm don't have actual values to provide but my guess (hope?) is that 
> it's between 90-99% of existing MathML content delivered to 
> Firefox/WebKit (note: they implement more than MathML Core but still not 
> the full MathML3 spec either). But if you want something more concrete, 
> regarding features we unshipped from Firefox I have a conversation on 
> Mozilla's matrix channel where we measured counters for deprecated 
> MathML3 features between 2020-08-11 and 2020-09-17. Most of them were 
> returning 0 count and only two of them were returning 1 count... to 
> compare with the counter for pages using MathML which was several

Re: [blink-dev] Intent to Ship: MathML

2022-06-25 Thread Frédéric Wang

On 24/06/2022 11:14, Daniel Bratell wrote:

I'm really happy to see this coming along! Awesome work by everyone
involved!

Thanks!

You mentioned fuzzy testing. Do the fuzzing tools have support for
mathml elements? If not, you should probably add a to-do item to teach
them.

What is the situation for developers that learn about this and want to
start using it? Are there good resources for learning how to write
MathML? I think a feature like this also deserves some attention when
it lands. Maybe that will happen by itself, or maybe someone needs to
initiate it. That info should probably also mention initial
limitations like printing, (multi-column?) and non-Core.

Similarly, MathML has been there for a while so there is already a bunch
of resource available about MathML (e.g. MDN to mention the obvious one)
as wellas editors & converters to generate it, polyfills to cover
browser's limitations, etc but I agree they will probably need a refresh
since (1) we implement a core subset (2) we are moving to an extensible
approach based on web technologies (3) there are chrome-specific bugs
like the printing one.

More about compatibility: Do you have any idea (guess really) of how
much of existing MathML content will "work" with just MathML Core? Is
it 99%, 90%, 50%, 10%?

I'm don't have actual values to provide but my guess (hope?) is that
it's between 90-99% of existing MathML content delivered to
Firefox/WebKit (note: they implement more than MathML Core but still not
the full MathML3 spec either). But if you want something more concrete,
regarding features we unshipped from Firefox I have a conversation on
Mozilla's matrix channel where we measured counters for deprecated
MathML3 features between 2020-08-11 and 2020-09-17. Most of them were
returning 0 count and only two of them were returning 1 count... to
compare with the counter for pages using MathML which was several millions!

--
Frédéric Wang

Re: [blink-dev] Intent to Ship: MathML

2022-06-24 Thread Daniel Bratell

I'm really happy to see this coming along! Awesome work by everyone 
involved!

I do agree that a feature of this size doesn't need to have all quirks 
ironed out before initial shipping. I expect some people to miss 
printing so I hope the gap where it doesn't work won't be too big.

You mentioned fuzzy testing. Do the fuzzing tools have support for 
mathml elements? If not, you should probably add a to-do item to teach them.

What is the situation for developers that learn about this and want to 
start using it? Are there good resources for learning how to write 
MathML? I think a feature like this also deserves some attention when it 
lands. Maybe that will happen by itself, or maybe someone needs to 
initiate it. That info should probably also mention initial limitations 
like printing, (multi-column?) and non-Core.

More about compatibility: Do you have any idea (guess really) of how 
much of existing MathML content will "work" with just MathML Core? Is it 
99%, 90%, 50%, 10%?

/Daniel

On 2022-06-24 07:42, Frédéric Wang wrote:
Thanks Chris. I'm attaching a testcase for contenteditable MathML. 
Indeed, the formula is properly rendered. It can also be edited and 
this will likely lead to "invalid" MathML markup (e.g. fraction ending 
up with only one child) but Firefox and WebKit don't perform integrity 
check either. And I guess it's fine, probably someone should really 
rely on JS to extend the native editor.

Morten was actually only mentioning the case when table is within a 
multicol so probably that excludes the Wikipedia use case (I'm going 
to do more checks there).

Printing would still be an issue.

So yeah, I personally don't think that should block shipping MathML 
but there are remaining issues with legacy layout that we need to be 
aware of.

On 23/06/2022 17:54, Chris Harrelson wrote:
EditingNG has already shipped. Only table fragmentation and printing 
are still to ship, and hopefully they will both be done by the end of 
the year.

On Thu, Jun 23, 2022 at 4:39 AM Frédéric Wang  wrote:

Hi Morten,

Thanks for raising this issue, I forgot to mention it. We
experimented
this in the past and IIRC we found issues with:

- Printing: indeed printing pages with math is likely to happen!
- Multicol: Wikipedia uses that for the "References" section at the
bottom of articles and some pages actually do use math inside!
- SVG: definitely needed for math in graphics. This is no longer an
issue now that foreignObject was implemented in LayoutNG.
- Editing: I'm not sure what's the status of EditingNG but I
believe we
wanted to disable editability on MathML anyway due to complexity for
editing math, which will require some tree fixup. This is better
handled
by other tools.

I don't remember what was the recent status, but we definitely
need to
check again. I believe we have crash tests in WPT and another to
check
correct layout for math-in-svg.

On 23/06/2022 13:06, Morten Stenshorne wrote:
> Exciting times!
>
> Since the layout implementation of MathML is pure NG (i.e. it
has no
> legacy engine counterpart), you should be aware that this is
somewhat
> uncharted territory. We *do* have mechanisms that kick in when
we need
> to fall back to legacy layout (e.g. when printing, or when
there are
> tables inside multicol), and have NG-only content inside (such as
> MathML), but no pure NG features have shipped yet, so we don't
really
> know how well this works on the world wild web.
>
> That said, we're also about to ship container queries, which
has the
> same problem - so you're not alone. I was hoping that we'd be
rid of the
> legacy engine completely before we started shipping pure NG
features,
> because of this risk. I'm not saying that we definitely need to
wait for
> the legacy engine to be completely gone, but you need to be
aware of the
> risk, at least. Maybe clusterfuzz will find something
interesting once
> this feature is switched to "stable". :)
>
> By the way, I just tested, and MathML inside legacy layout
doesn't seem
> to work. I filed
> https://bugs.chromium.org/p/chromium/issues/detail?id=1338882
>
> Frédéric Wang  writes:
>
>> Contact emails
>>
>> fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com
>>
>> Explainer
>>
>>
https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md
>> https://people.igalia.com/fwang/explainer-font-family-math
>>
>> Specification
>>
>> https://mathml-refresh.github.io/mathml-core
>>
>> Design docs
>>
>> https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
>> https://w3c.github.io/mathml-aam
>>

https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
>>

Re: [blink-dev] Intent to Ship: MathML

2022-06-23 Thread Frédéric Wang

Thanks Chris. I'm attaching a testcase for contenteditable MathML. 
Indeed, the formula is properly rendered. It can also be edited and this 
will likely lead to "invalid" MathML markup (e.g. fraction ending up 
with only one child) but Firefox and WebKit don't perform integrity 
check either. And I guess it's fine, probably someone should really rely 
on JS to extend the native editor.


Morten was actually only mentioning the case when table is within a 
multicol so probably that excludes the Wikipedia use case (I'm going to 
do more checks there).


Printing would still be an issue.

So yeah, I personally don't think that should block shipping MathML but 
there are remaining issues with legacy layout that we need to be aware of.


On 23/06/2022 17:54, Chris Harrelson wrote:
EditingNG has already shipped. Only table fragmentation and printing 
are still to ship, and hopefully they will both be done by the end of 
the year.


On Thu, Jun 23, 2022 at 4:39 AM Frédéric Wang  wrote:

Hi Morten,

Thanks for raising this issue, I forgot to mention it. We
experimented
this in the past and IIRC we found issues with:

- Printing: indeed printing pages with math is likely to happen!
- Multicol: Wikipedia uses that for the "References" section at the
bottom of articles and some pages actually do use math inside!
- SVG: definitely needed for math in graphics. This is no longer an
issue now that foreignObject was implemented in LayoutNG.
- Editing: I'm not sure what's the status of EditingNG but I
believe we
wanted to disable editability on MathML anyway due to complexity for
editing math, which will require some tree fixup. This is better
handled
by other tools.

I don't remember what was the recent status, but we definitely
need to
check again. I believe we have crash tests in WPT and another to
check
correct layout for math-in-svg.

On 23/06/2022 13:06, Morten Stenshorne wrote:
> Exciting times!
>
> Since the layout implementation of MathML is pure NG (i.e. it has no
> legacy engine counterpart), you should be aware that this is
somewhat
> uncharted territory. We *do* have mechanisms that kick in when
we need
> to fall back to legacy layout (e.g. when printing, or when there are
> tables inside multicol), and have NG-only content inside (such as
> MathML), but no pure NG features have shipped yet, so we don't
really
> know how well this works on the world wild web.
>
> That said, we're also about to ship container queries, which has the
> same problem - so you're not alone. I was hoping that we'd be
rid of the
> legacy engine completely before we started shipping pure NG
features,
> because of this risk. I'm not saying that we definitely need to
wait for
> the legacy engine to be completely gone, but you need to be
aware of the
> risk, at least. Maybe clusterfuzz will find something
interesting once
> this feature is switched to "stable". :)
>
> By the way, I just tested, and MathML inside legacy layout
doesn't seem
> to work. I filed
> https://bugs.chromium.org/p/chromium/issues/detail?id=1338882
>
> Frédéric Wang  writes:
>
>> Contact emails
>>
>> fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com
>>
>> Explainer
>>
>>
https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md
>> https://people.igalia.com/fwang/explainer-font-family-math
>>
>> Specification
>>
>> https://mathml-refresh.github.io/mathml-core
>>
>> Design docs
>>
>> https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
>> https://w3c.github.io/mathml-aam
>>

https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
>>

https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy
>>
>> Summary
>>
>> Adds native DOM/IDL, accessibility support and CSS-compatible
OpenType-based layout of mathematical formulas. The reference
>> specifications are MathML Core (which describes in extensive
details a fundamental subset of the MathML 3 recommendation),
MathML AAM
>> (which describes mapping to platform accessibility APIs). This
includes the "math" font-family as well as features included in
section "CSS
>> Extensions for Math Layout".
>>
>> Blink component
>>
>> Blink
>>
>> Search tags
>>
>> mathml
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/438
https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> - This is not implementing the complete list of MathML3,
OpenType

Re: [blink-dev] Intent to Ship: MathML

2022-06-23 Thread Chris Harrelson

EditingNG has already shipped. Only table fragmentation and printing are
still to ship, and hopefully they will both be done by the end of the year.

On Thu, Jun 23, 2022 at 4:39 AM Frédéric Wang  wrote:

> Hi Morten,
>
> Thanks for raising this issue, I forgot to mention it. We experimented
> this in the past and IIRC we found issues with:
>
> - Printing: indeed printing pages with math is likely to happen!
> - Multicol: Wikipedia uses that for the "References" section at the
> bottom of articles and some pages actually do use math inside!
> - SVG: definitely needed for math in graphics. This is no longer an
> issue now that foreignObject was implemented in LayoutNG.
> - Editing: I'm not sure what's the status of EditingNG but I believe we
> wanted to disable editability on MathML anyway due to complexity for
> editing math, which will require some tree fixup. This is better handled
> by other tools.
>
> I don't remember what was the recent status, but we definitely need to
> check again. I believe we have crash tests in WPT and another to check
> correct layout for math-in-svg.
>
> On 23/06/2022 13:06, Morten Stenshorne wrote:
> > Exciting times!
> >
> > Since the layout implementation of MathML is pure NG (i.e. it has no
> > legacy engine counterpart), you should be aware that this is somewhat
> > uncharted territory. We *do* have mechanisms that kick in when we need
> > to fall back to legacy layout (e.g. when printing, or when there are
> > tables inside multicol), and have NG-only content inside (such as
> > MathML), but no pure NG features have shipped yet, so we don't really
> > know how well this works on the world wild web.
> >
> > That said, we're also about to ship container queries, which has the
> > same problem - so you're not alone. I was hoping that we'd be rid of the
> > legacy engine completely before we started shipping pure NG features,
> > because of this risk. I'm not saying that we definitely need to wait for
> > the legacy engine to be completely gone, but you need to be aware of the
> > risk, at least. Maybe clusterfuzz will find something interesting once
> > this feature is switched to "stable". :)
> >
> > By the way, I just tested, and MathML inside legacy layout doesn't seem
> > to work. I filed
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1338882
> >
> > Frédéric Wang  writes:
> >
> >> Contact emails
> >>
> >> fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com
> >>
> >> Explainer
> >>
> >>
> https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md
> >> https://people.igalia.com/fwang/explainer-font-family-math
> >>
> >> Specification
> >>
> >> https://mathml-refresh.github.io/mathml-core
> >>
> >> Design docs
> >>
> >> https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
> >> https://w3c.github.io/mathml-aam
> >>
> https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
> >>
> https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy
> >>
> >> Summary
> >>
> >> Adds native DOM/IDL, accessibility support and CSS-compatible
> OpenType-based layout of mathematical formulas. The reference
> >> specifications are MathML Core (which describes in extensive details a
> fundamental subset of the MathML 3 recommendation), MathML AAM
> >> (which describes mapping to platform accessibility APIs). This includes
> the "math" font-family as well as features included in section "CSS
> >> Extensions for Math Layout".
> >>
> >> Blink component
> >>
> >> Blink
> >>
> >> Search tags
> >>
> >> mathml
> >>
> >> TAG review
> >>
> >> https://github.com/w3ctag/design-reviews/issues/438
> https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527
> >>
> >> TAG review status
> >>
> >> Issues addressed
> >>
> >> Risks
> >>
> >> Interoperability and Compatibility
> >>
> >> - This is not implementing the complete list of MathML3, OpenType MATH
> or accessibility features that one can find in other browsers.
> >>
> >> - New enhancements (e.g. clarification regarding CSS interoperability)
> may not be implemented in other browsers yet.
> >>
> >> - MathML Core and MathML AAM are still working drafts.
> >>
> >> Gecko: Shipped/Shipping
> >>
> >> WebKit: Shipped/Shipping
> >>
> >> Web developers: Positive (
> https://twitter.com/search?q=mathml%20chrome=live) Users have recently
> been excited about it,
> >> experimented exiting implementation under a flag and are eager to see
> it shipped soon. It is currently the 5th most starred Blink issue, see
> >>
> https://bugs.chromium.org/p/chromium/issues/list?can=2=component:Blink=-stars=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary
> >>
> >>
> >> Other signals:
> >>
> >> Ergonomics
> >>
> >> In the past, MathML trees were not treated specially at all and this
> was fast ! Now, more work is needed for pages that do math rendering
> >> e.g. accessing data from the MATH table, handling operator dictionary,
> using ink

Re: [blink-dev] Intent to Ship: MathML

2022-06-23 Thread Frédéric Wang

Hi Morten,

Thanks for raising this issue, I forgot to mention it. We experimented
this in the past and IIRC we found issues with:

- Printing: indeed printing pages with math is likely to happen!
- Multicol: Wikipedia uses that for the "References" section at the
bottom of articles and some pages actually do use math inside!
- SVG: definitely needed for math in graphics. This is no longer an
issue now that foreignObject was implemented in LayoutNG.
- Editing: I'm not sure what's the status of EditingNG but I believe we
wanted to disable editability on MathML anyway due to complexity for
editing math, which will require some tree fixup. This is better handled
by other tools.

I don't remember what was the recent status, but we definitely need to
check again. I believe we have crash tests in WPT and another to check
correct layout for math-in-svg.

On 23/06/2022 13:06, Morten Stenshorne wrote:

Exciting times!

Since the layout implementation of MathML is pure NG (i.e. it has no
legacy engine counterpart), you should be aware that this is somewhat
uncharted territory. We *do* have mechanisms that kick in when we need
to fall back to legacy layout (e.g. when printing, or when there are
tables inside multicol), and have NG-only content inside (such as
MathML), but no pure NG features have shipped yet, so we don't really
know how well this works on the world wild web.

That said, we're also about to ship container queries, which has the
same problem - so you're not alone. I was hoping that we'd be rid of the
legacy engine completely before we started shipping pure NG features,
because of this risk. I'm not saying that we definitely need to wait for
the legacy engine to be completely gone, but you need to be aware of the
risk, at least. Maybe clusterfuzz will find something interesting once
this feature is switched to "stable". :)

By the way, I just tested, and MathML inside legacy layout doesn't seem
to work. I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=1338882

Frédéric Wang writes:

Contact emails

fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com

Explainer

https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md
https://people.igalia.com/fwang/explainer-font-family-math

Specification

https://mathml-refresh.github.io/mathml-core

Design docs

https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
https://w3c.github.io/mathml-aam
https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy

Summary

Adds native DOM/IDL, accessibility support and CSS-compatible OpenType-based
layout of mathematical formulas. The reference
specifications are MathML Core (which describes in extensive details a
fundamental subset of the MathML 3 recommendation), MathML AAM
(which describes mapping to platform accessibility APIs). This includes the "math"
font-family as well as features included in section "CSS
Extensions for Math Layout".

Blink component

Blink

Search tags

mathml

TAG review

https://github.com/w3ctag/design-reviews/issues/438
https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

- This is not implementing the complete list of MathML3, OpenType MATH or
accessibility features that one can find in other browsers.

- New enhancements (e.g. clarification regarding CSS interoperability) may not
be implemented in other browsers yet.

- MathML Core and MathML AAM are still working drafts.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Positive (https://twitter.com/search?q=mathml%20chrome=live)
Users have recently been excited about it,
experimented exiting implementation under a flag and are eager to see it
shipped soon. It is currently the 5th most starred Blink issue, see
https://bugs.chromium.org/p/chromium/issues/list?can=2=component:Blink=-stars=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary

Other signals:

Ergonomics

In the past, MathML trees were not treated specially at all and this was fast !
Now, more work is needed for pages that do math rendering
e.g. accessing data from the MATH table, handling operator dictionary, using
ink text bounds, performing low-level shaping of stretchy
operators, loading and applying CSS UA sheet, or exposing an accessibility
tree. However, the only performance report we received so far
was issue #1073760, which was discarded after further analysis. In any case,
performance is definitely better than existing non-native
technologies. Additionally, pages will likely need loading WOFF fonts on
operating systems that don't ship math fonts. Work is in progress
here, see https://frederic-wang.fr/update-on-open-type-math-fonts.html for
recent status.

Activation

- Editing MathML source is difficult but special authoring tools & converters

Re: [blink-dev] Intent to Ship: MathML

2022-06-23 Thread Morten Stenshorne

Exciting times!

Since the layout implementation of MathML is pure NG (i.e. it has no
legacy engine counterpart), you should be aware that this is somewhat
uncharted territory. We *do* have mechanisms that kick in when we need
to fall back to legacy layout (e.g. when printing, or when there are
tables inside multicol), and have NG-only content inside (such as
MathML), but no pure NG features have shipped yet, so we don't really
know how well this works on the world wild web.

That said, we're also about to ship container queries, which has the
same problem - so you're not alone. I was hoping that we'd be rid of the
legacy engine completely before we started shipping pure NG features,
because of this risk. I'm not saying that we definitely need to wait for
the legacy engine to be completely gone, but you need to be aware of the
risk, at least. Maybe clusterfuzz will find something interesting once
this feature is switched to "stable". :)

By the way, I just tested, and MathML inside legacy layout doesn't seem
to work. I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=1338882

Frédéric Wang  writes:

> Contact emails
>
> fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com 
>
> Explainer
>
> https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md 
> https://people.igalia.com/fwang/explainer-font-family-math 
>
> Specification
>
> https://mathml-refresh.github.io/mathml-core 
>
> Design docs
>
> https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math 
> https://w3c.github.io/mathml-aam 
> https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
>  
> https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy
>  
>
> Summary
>
> Adds native DOM/IDL, accessibility support and CSS-compatible OpenType-based 
> layout of mathematical formulas. The reference
> specifications are MathML Core (which describes in extensive details a 
> fundamental subset of the MathML 3 recommendation), MathML AAM
> (which describes mapping to platform accessibility APIs). This includes the 
> "math" font-family as well as features included in section "CSS
> Extensions for Math Layout".
>
> Blink component
>
> Blink 
>
> Search tags
>
> mathml 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/438 
> https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527 
>
> TAG review status
>
> Issues addressed 
>
> Risks
>
> Interoperability and Compatibility
>
> - This is not implementing the complete list of MathML3, OpenType MATH or 
> accessibility features that one can find in other browsers.
>
> - New enhancements (e.g. clarification regarding CSS interoperability) may 
> not be implemented in other browsers yet. 
>
> - MathML Core and MathML AAM are still working drafts. 
>
> Gecko: Shipped/Shipping 
>
> WebKit: Shipped/Shipping 
>
> Web developers: Positive 
> (https://twitter.com/search?q=mathml%20chrome=live) Users have recently 
> been excited about it,
> experimented exiting implementation under a flag and are eager to see it 
> shipped soon. It is currently the 5th most starred Blink issue, see
> https://bugs.chromium.org/p/chromium/issues/list?can=2=component:Blink=-stars=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary
>
>
> Other signals: 
>
> Ergonomics
>
> In the past, MathML trees were not treated specially at all and this was fast 
> ! Now, more work is needed for pages that do math rendering
> e.g. accessing data from the MATH table, handling operator dictionary, using 
> ink text bounds, performing low-level shaping of stretchy
> operators, loading and applying CSS UA sheet, or exposing an accessibility 
> tree. However, the only performance report we received so far
> was issue #1073760, which was discarded after further analysis. In any case, 
> performance is definitely better than existing non-native
> technologies. Additionally, pages will likely need loading WOFF fonts on 
> operating systems that don't ship math fonts. Work is in progress
> here, see https://frederic-wang.fr/update-on-open-type-math-fonts.html for 
> recent status. 
>
> Activation
>
> - Editing MathML source is difficult but special authoring tools & converters 
> do exist.
>
> - Implementation may not be as complete as expected by users but the spec 
> tries to allow extensibility and the Math WG provides polyfills
> at https://github.com/mathml-refresh/mathml-polyfills
>
> - Users may require WOFF fonts to properly render formulas (see above). 
>
> Security
>
> There is a risk due to the new attack surface:
>
> - Relatively large amount of new code.
>
> - Newly exposed APIs.
>
> - Interacting with several parts of the web platform.
>
> However, risks related to violation of layout algorithm are reduced now that 
> the specification clarifies how to perform it in a CSS-compatible
> way. We've fixed 17 issues reported during 2.5 years of development and there 
> are currently 0 open security

Re: [blink-dev] Intent to Ship: MathML

2022-06-22 Thread Chris Harrelson

This is very exciting! A couple of questions below.

On Wed, Jun 22, 2022 at 2:48 PM Frédéric Wang  wrote:

> Contact emails fw...@chromium.org, rb...@chromium.org, bkard...@igalia.com
>
> Explainer
> https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md
> https://people.igalia.com/fwang/explainer-font-family-math
>
> Specification https://mathml-refresh.github.io/mathml-core
>
> Design docs
> https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
> https://w3c.github.io/mathml-aam
>
> https://docs.google.com/document/d/1biGEaWN8ThNTDtAbT1M5GIf6N5uQLWdxh2QhrG9uN5c
>
> https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy
> Summary
>
> Adds native DOM/IDL, accessibility support and CSS-compatible
> OpenType-based layout of mathematical formulas. The reference
> specifications are MathML Core (which describes in extensive details a
> fundamental subset of the MathML 3 recommendation), MathML AAM (which
> describes mapping to platform accessibility APIs). This includes the "math"
> font-family as well as features included in section "CSS Extensions for
> Math Layout".
>
>
> Blink component Blink
> 
>
> Search tags mathml 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/438
> https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527
>
> TAG review status Issues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> - This is not implementing the complete list of MathML3, OpenType MATH or
> accessibility features that one can find in other browsers.
>
> - New enhancements (e.g. clarification regarding CSS interoperability) may
> not be implemented in other browsers yet.
>
> - MathML Core and MathML AAM are still working drafts.
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping
>

They ship MathML, but could you speak to the conformance level with the
Core spec? In cases where there are gaps, are they going to cause
significant web compat issues that will need to be addressed with
implementation improvements to other browser implementations?

Relatedly, is it the case that the Chromium implementation passes all of
the WPT tests and is in complete agreement with the Core spec?


>
>
> *Web developers*: Positive (
> https://twitter.com/search?q=mathml%20chrome=live) Users have recently
> been excited about it, experimented exiting implementation under a flag and
> are eager to see it shipped soon. It is currently the 5th most starred
> Blink issue, see
> https://bugs.chromium.org/p/chromium/issues/list?can=2=component:Blink=-stars=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary
> 
>
> *Other signals*:
>
> Ergonomics
>
> In the past, MathML trees were not treated specially at all and this was
> fast ! Now, more work is needed for pages that do math rendering e.g.
> accessing data from the MATH table, handling operator dictionary, using ink
> text bounds, performing low-level shaping of stretchy operators, loading
> and applying CSS UA sheet, or exposing an accessibility tree. However, the
> only performance report we received so far was issue #1073760, which was
> discarded after further analysis. In any case, performance is definitely
> better than existing non-native technologies. Additionally, pages will
> likely need loading WOFF fonts on operating systems that don't ship math
> fonts. Work is in progress here, see
> https://frederic-wang.fr/update-on-open-type-math-fonts.html for recent
> status.
>
>
> Activation
>
> - Editing MathML source is difficult but special authoring tools &
> converters do exist.
>
> - Implementation may not be as complete as expected by users but the spec
> tries to allow extensibility and the Math WG provides polyfills at
> https://github.com/mathml-refresh/mathml-polyfills
>
> - Users may require WOFF fonts to properly render formulas (see above).
>
>
> Security
>
> There is a risk due to the new attack surface:
>
> - Relatively large amount of new code.
>
> - Newly exposed APIs.
>
> - Interacting with several parts of the web platform.
>
> However, risks related to violation of layout algorithm are reduced now
> that the specification clarifies how to perform it in a CSS-compatible way.
> We've fixed 17 issues reported during 2.5 years of development and there
> are currently 0 open security issues (last report was in March).
>
> Finally, similar security & privacy considerations as existing layout
> specifications apply, see the relevant sections from the MathML Core spec:
> https://w3c.github.io/mathml-core/#security-considerations
> https://w3c.github.io/mathml-core/#privacy-considerations
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such

Re: [blink-dev] Intent to Ship: MathML

2022-06-22 Thread Frédéric Wang

Hello,

My previous email was generated from the information of chromestatus.com
; I’d like to elaborate a bit more about the
situation of MathML in Chromium. In 2019, we published a roadmap [1]
which we basically implemented downstream the same year. As of today, we
consider this roadmap complete upstream, modulo imperfect math layout of
stretchy operators due to the limitation of the current LayoutNG
architecture (the rendering team is aware of that and consensus is that
it’s ok for a first implementation).

In addition, we have been receiving feedback from various people and
tried to adjust our initial roadmap accordingly:

1. Some concerns were shared by some browser vendors, TAG members or
some participants to the “Getting Math onto Web Pages CG” and are
summarized on the official TAG’s feedback [2]. During these recent
years, we’ve collaborated with the MathML and CSS working groups as
well as browser vendors to publish specifications & tests that
address these concerns. This also added many new tasks on the
roadmap (e.g. new CSS properties, MathMLElement IDL, mixing with
CSS/SVG, etc).
2. MathML supporters have also been asking a more complete support for
MathML3 features, raising concerns about backward compatibility.
Apple shares this concern about breaking content from their
applications (e.g. Apple Books) and is generally reluctant to remove
shipped features. Mozilla has been more positive about that and
several patches landed to unship legacy features with low usage. We
decided to solve that disagreement by publishing two specifications:
MathML Core (intended to be implemented in browsers) and a superset
called “MathML Full”. Polyfills for MathML features that are not
part of the core spec have also been written. Incidentally, the
layering/extensibility effort for (1) became instrumental to write
such polyfills.
3. We also received feedback about making MathML accessible, so we
added that in our plan. We implemented parity with Gecko/WebKit for
macOS/NSAccessibility and Linux/ATK. We’ve also been working on a
corresponding MathML AAM specification to standardize existing
support and we wrote (currently internal) tests for that. Other
platforms (Windows, ChromeOS, Android) don’t seem to have any
special way to expose MathML nodes to assistive technologies, so
instead we continue to rely on existing DOM-based approaches.
4. Finally, a lot of users have praised our work, tested existing
support by enabling web platform features, reported bugs and they
keep asking us when this is going to be officially shipped.
Hopefully this intent-to-ship will allow to address that last
feedback :-)

At that time, we believe the implementation is good enough for a first
release. To be fully transparent these are known issues:

* There are bugs to fix or more features users would like to see. We
expect the layering/extensibility approach will make possible to
work around current limitations.
* Not all operating systems come with a pre-installed OpenType MATH
font, which means poor math rendering on such systems by default.
However, Windows has Cambria Math pre-installed and things seem to
improve on the macOS & Android side [3]. The workaround for that is
to use web fonts (on pages or as a web extension).
* There are a few interactions with CSS properties (e.g. width/height,
out-of-flow, etc) that we would like to clarify in the spec and/or
the implementation and ensure we have interoperability tests for
that. These are likely edge cases for MathML authors but can be
important for polyfills.

That’s it, we are looking forward to hearing your feedback !

[1] https://mathml.igalia.com/project/
[2]
https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527

[3] https://frederic-wang.fr/update-on-open-type-math-fonts.html

--
Frédéric Wang

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

Re: [blink-dev] Intent to Ship: MathML columnspan/rowspan attributes on element

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

Re: [blink-dev] Intent to Ship: MathML

28 matches

Site Navigation

Mail list logo

Footer information