Make MathML attributes ASCII case-insensitive #178

fred-wang · 2019-12-13T10:55:03Z

This is a follow-up of #22 ; we decided to follow HTML/CSS which treat things as ASCII case-insensitive. Concretely, ftp://ftp.unicode.org/Public/UNIDATA/CaseFolding.txt has this line:

017F; C; 0073; # LATIN SMALL LETTER LONG S

which means that falſe is case-insensitively equal to false. However, it is not ASCII case-insensitively equal to false (only a-z <-> A-Z equivalence are considered in that case).

Currently, the MathML Core spec just says "case-insensitive".

Note: for CSS colors, I reported w3c/csswg-drafts#4599

The text was updated successfully, but these errors were encountered:

fred-wang · 2019-12-16T07:07:26Z

I did a quick check and for the MathML-specific definitions, I only see case-insensitive against strings with ASCII letters and dashes. So the only difference would be for "LATIN SMALL LETTER LONG S", "KELVIN SIGN" and maybe a few "LATIN SMALL LIGATURE" (e.g. double-STruck). Unlikely for "LATIN CAPITAL LETTER I WITH DOT ABOVE" if the Turkish rule is used. See w3c/csswg-drafts#4599 (comment)

NSoiffer · 2019-12-16T07:26:39Z

That's a good catch. I'm pretty sure we all agree that we only mean ASCII case-insensitivity. I suggest we add the following to the spec, which is a slight rewording from the HTML spec:

Many strings in the HTML and CSS syntax (e.g. the names of elements and their attributes) are case-insensitive, but only for ASCII upper alphas and ASCII lower alphas. For convenience, in this specification this is just referred to as "case-insensitive".

I suggest this goes into Appendix G.1: Document Conventions.

fred-wang · 2019-12-16T07:47:10Z

I would prefer to be explicit everywhere and use "ASCII case-insensitive" with a link to https://infra.spec.whatwg.org/#ascii-case-insensitive ; this seems to be what the HTML and CSS specifications do (or how they would be fixed it e.g. w3c/csswg-drafts#4599 (comment)). I'm sure if we just keep case-insensitive as it is now, people will easily not read the appendix. We should also avoid duplicating definition from HTML5 as it was mentioned in another issue.

fred-wang · 2019-12-17T08:28:13Z

Consensus from 2019/12/16: Move to ASCII case-insensitiveness

The mathsize and dir attributes are defined modulo ASCII case-insensitive equivalence and are mapped to CSS font-size and direction properties [1] [2]. Since the CSS keywords are themselves defined modulo ASCII case-insensitive equivalence [3], there is not need to filter out other (Unicode) case-insensitive equivalent keywords (e.g. "ſmall") in the MathML Code, they will be rejected by the CSS parser. This CL replaces DeprecatedEqualIgnoringCase with EqualIgnoringASCIICase and adds tests to ensure that (Unicode) case-insensitive equivalent strings remain disallowed. [1] https://mathml-refresh.github.io/mathml-core/#global-attributes [2] w3c/mathml#178 [3] https://www.w3.org/TR/css-values-4/#keywords Bug: 6606 Bug: 627682 Change-Id: Ice84368c8cc7e8fff9faccb454c23fad87b99d59

fred-wang · 2019-12-17T11:17:15Z

These are the attributes, with the behavior changes that will require tests:

boolean attributes: Behavior change for falSe.
dir: No behavior change.
mathvariant: Behavior change for e.g. double-StrucK
display: Behavior change for blocK.
form: Behavior change for poStfix.
notation: Behavior change for e.g. updiagonalStriKe
frame: Behavior change for e.g. daShed

Other attributes rely on CSS ( https://mathml-refresh.github.io/mathml-core/#types-for-mathml-attribute-values ) so nothing is changed here (although tests can always be added).

See w3c/mathml#178

…20807) The mathsize and dir attributes are defined modulo ASCII case-insensitive equivalence and are mapped to CSS font-size and direction properties [1] [2]. Since the CSS keywords are themselves defined modulo ASCII case-insensitive equivalence [3], there is not need to filter out other (Unicode) case-insensitive equivalent keywords (e.g. "ſmall") in the MathML Code, they will be rejected by the CSS parser. This CL replaces DeprecatedEqualIgnoringCase with EqualIgnoringASCIICase and adds tests to ensure that (Unicode) case-insensitive equivalent strings remain disallowed. [1] https://mathml-refresh.github.io/mathml-core/#global-attributes [2] w3c/mathml#178 [3] https://www.w3.org/TR/css-values-4/#keywords Bug: 6606 Bug: 627682 Change-Id: Ice84368c8cc7e8fff9faccb454c23fad87b99d59

The mathsize and dir attributes are defined modulo ASCII case-insensitive equivalence and are mapped to CSS font-size and direction properties [1] [2]. Since the CSS keywords are themselves defined modulo ASCII case-insensitive equivalence [3], there is not need to filter out other (Unicode) case-insensitive equivalent keywords (e.g. "ſmall") in the MathML Code, they will be rejected by the CSS parser. This CL replaces DeprecatedEqualIgnoringCase with EqualIgnoringASCIICase and adds tests to ensure that (Unicode) case-insensitive equivalent strings remain disallowed. [1] https://mathml-refresh.github.io/mathml-core/#global-attributes [2] w3c/mathml#178 [3] https://www.w3.org/TR/css-values-4/#keywords Bug: 6606 Bug: 627682 Change-Id: Ice84368c8cc7e8fff9faccb454c23fad87b99d59 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1970615 Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Frédéric Wang <fwang@igalia.com> Cr-Commit-Position: refs/heads/master@{#725481}

davidcarlisle · 2019-12-17T12:26:08Z

If we want to keep the relax schema there are two choices either we could say in words that values should be ascii-lowercased before validation or we could make the schema do the case insensitive match.

That would mean for example changing

attribute mathvariant {"normal" | "bold" | "italic" | "bold-italic" | "double-struck" | "bold-fraktur" | "script" | "bold-script" | "fraktur" | "sans-serif" | "bold-sans-serif" | "sans-serif-italic" | "sans-serif-bold-italic" | "monospace" | "initial" | "tailed" | "looped" | "stretched"}?,

to

attribute mathvariant {xsd:string{pattern="[Nn][Oo][Rr][Mm][Aa][Ll]|[Bb][Oo][Ll][Dd]|[Ii][Tt][Aa][Ll][Ii][Cc]|[Bb][Oo][Ll][Dd]-[Ii][Tt][Aa][Ll][Ii][Cc]|[Dd][Oo][Uu][Bb][Ll][Ee]-[Ss][Tt][Rr][Uu][Cc][Kk]|[Bb][Oo][Ll][Dd]-[Ff][Rr][Aa][Kk][Tt][Uu][Rr]|[Ss][Cc][Rr][Ii][Pp][Tt]|[Bb][Oo][Ll][Dd]-[Ss][Cc][Rr][Ii][Pp][Tt]|[Ff][Rr][Aa][Kk][Tt][Uu][Rr]|[Ss][Aa][Nn][Ss]-[Ss][Ee][Rr][Ii][Ff]|[Bb][Oo][Ll][Dd]-[Ss][Aa][Nn][Ss]-[Ss][Ee][Rr][Ii][Ff]|[Ss][Aa][Nn][Ss]-[Ss][Ee][Rr][Ii][Ff]-[Ii][Tt][Aa][Ll][Ii][Cc]|[Ss][Aa][Nn][Ss]-[Ss][Ee][Rr][Ii][Ff]-[Bb][Oo][Ll][Dd]-[Ii][Tt][Aa][Ll][Ii][Cc]|[Mm][Oo][Nn][Oo][Ss][Pp][Aa][Cc][Ee]|[Ii][Nn][Ii][Tt][Ii][Aa][Ll]|[Tt][Aa][Ii][Ll][Ee][Dd]|[Ll][Oo][Oo][Pp][Ee][Dd]|[Ss][Tt][Rr][Ee][Tt][Cc][Hh][Ee][Dd]"}}?,

which works but isn't very human readable or informative.

Since we already need some pre-processing described in words to allow data-foo attributes (or onfoo attributes to be ignored, I'm tempted to suggest we keep the existing string match but could be persuaded otherwise....

fred-wang · 2019-12-17T13:07:38Z

I think this was already the case since #22 ; not sure how important it is for legacy XML applications. I wonder what is done for HTML5 ?

davidcarlisle · 2019-12-17T14:03:43Z

On Tue, 17 Dec 2019 at 13:07, Frédéric Wang ***@***.***> wrote: I think this was already the case since #22 <#22> ; not sure how important it is for legacy XML applications. I wonder what is done for HTML5 ?

The validator.nu html5 validator has a relaxng schema at its core but heavily preprocesses the document with custom code before validating it, so I think pre-processing is fine (and makes the schema a lot easier to read)

…to validate mathsize and dir, a=testonly Automatic update from web-platform-tests [mathml] Use ASCII case-insensitiveness to validate mathsize and dir (#20807) The mathsize and dir attributes are defined modulo ASCII case-insensitive equivalence and are mapped to CSS font-size and direction properties [1] [2]. Since the CSS keywords are themselves defined modulo ASCII case-insensitive equivalence [3], there is not need to filter out other (Unicode) case-insensitive equivalent keywords (e.g. "ſmall") in the MathML Code, they will be rejected by the CSS parser. This CL replaces DeprecatedEqualIgnoringCase with EqualIgnoringASCIICase and adds tests to ensure that (Unicode) case-insensitive equivalent strings remain disallowed. [1] https://mathml-refresh.github.io/mathml-core/#global-attributes [2] w3c/mathml#178 [3] https://www.w3.org/TR/css-values-4/#keywords Bug: 6606 Bug: 627682 Change-Id: Ice84368c8cc7e8fff9faccb454c23fad87b99d59 -- wpt-commits: 0cc6eb16b46a76070b11ce771e4026da2e328a6d wpt-pr: 20807

ByteEater-pl · 2020-02-20T03:39:44Z

legacy XML applications

Could you, please, define this term, @fred-wang? I don't know which XML applications are legacy and which aren't.

fred-wang · 2020-02-20T06:55:48Z

legacy XML applications

Could you, please, define this term, @fred-wang? I don't know which XML applications are legacy and which aren't.

I believe I was talking about XML-based MathML3 implementations.

fred-wang · 2020-05-22T11:22:53Z

Removing "tests" label, we have tests for mathsize and dir. It's not exhaustive, but HTML or CSS don't test exhaustively either...

Also removing core label since the only remaining changes are in mathml full

NSoiffer mentioned this issue Dec 16, 2019

Agenda for Core Meeting #8

Closed

chromium-wpt-export-bot mentioned this issue Dec 17, 2019

[mathml] Use ASCII case-insensitiveness to validate mathsize and dir web-platform-tests/wpt#20807

Merged

fred-wang added a commit to w3c/mathml-core that referenced this issue Dec 17, 2019

Make MathML attributes ASCII case-insensitive

10a7d10

See w3c/mathml#178

fred-wang removed need resolution Issues needing resolution at MathML Refresh CG meeting need specification update Issues requiring specification changes labels Mar 21, 2020

fred-wang added the MathML 4 Issues affecting the MathML 4 specification label May 22, 2020

fred-wang removed MathML Core Issues affecting the MathML Core specification need tests Issues related to writing WPT tests labels May 22, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make MathML attributes ASCII case-insensitive #178

Make MathML attributes ASCII case-insensitive #178

fred-wang commented Dec 13, 2019

fred-wang commented Dec 16, 2019

NSoiffer commented Dec 16, 2019

fred-wang commented Dec 16, 2019

fred-wang commented Dec 17, 2019

fred-wang commented Dec 17, 2019

davidcarlisle commented Dec 17, 2019

fred-wang commented Dec 17, 2019

davidcarlisle commented Dec 17, 2019 via email

ByteEater-pl commented Feb 20, 2020

fred-wang commented Feb 20, 2020

fred-wang commented May 22, 2020

Make MathML attributes ASCII case-insensitive #178

Make MathML attributes ASCII case-insensitive #178

Comments

fred-wang commented Dec 13, 2019

fred-wang commented Dec 16, 2019

NSoiffer commented Dec 16, 2019

fred-wang commented Dec 16, 2019

fred-wang commented Dec 17, 2019

fred-wang commented Dec 17, 2019

davidcarlisle commented Dec 17, 2019

fred-wang commented Dec 17, 2019

davidcarlisle commented Dec 17, 2019 via email

ByteEater-pl commented Feb 20, 2020

fred-wang commented Feb 20, 2020

fred-wang commented May 22, 2020