reserving intent and arg as global attributes

[davidcarlisle]

At the core meeting on 2022-06-27 I took an action to add wording adding intent and arg to Core, with no specified behavior at the current level 1 specification. An initial proposal here.

[NSoiffer]

There is also your "favorite" attr that should be added to the list: alttext.

I feel the point of the reserved list of keywords is two fold:

1. make attrs that were used in the past that don't affect display be legal so that validators don't complain
2. be foreword looking and preemptively get some important MathML 4 attrs into core so validators don't complain.

Besides alttext, I'm not sure what else needs to go in, but I think you may have run up against some others. Maybe not.

[NSoiffer]

You're right about it not being global. Still needs to be reserved though. So the new section you wrote is/was warranted.

Let's wait a day to give others a chance to comment.

[davidcarlisle]

@NSoiffer added alttext The current draft schema has

                   # No specified behavior in Core, see MathML4
		   MathMLintentAttributes,
                   # No specified behavior in Core, see WAI-ARIA
		   MathMLARIAattributes
                       


math.attributes = MathMLPGlobalAttributes,
                  attribute display {"block" | "inline"}?,
                  # No specified behavior in Core, see MathML4
                  attribute alttext {text}?

# sample set, like data- may need preprocessing to allow more
MathMLARIAattributes =
  attribute aria-label {text}?,
  attribute aria-describedby {text}?,
  attribute aria-details {text}?

MathMLintentAttributes =
  attribute intent {text}?,
  attribute arg {xsd:NCName}?

So all now mentioned apart from aria-xxx

The comments about preprocessing are a technical limitation of the schema language you can not allow any attribute of name data-* so the schema just allows data-otherand you need to extend the schema to allow more or pre-filter the input to remove such attributes before validating by some method out of scope for the spec.

[NSoiffer]

If you are adding aria-describedby, you should have aria-labelledby.

Symmetrically, you are missing aria-description. That one is slightly more dubious -- the mdn page says "aria-description is still in W3C Editor's Draft for ARIA 1.3". But since we are forward looking, it make sense to me to include it.

[dginev]

If you are adding aria-describedby, you should have aria-labelledby.

(+1 for that statement)

Meta note: I thought there was discussion to be had whether ARIA attributes should be added and if so which exact ones would apply. For example, I see aria-braillelabel and aria-brailleroledescription aren't mentioned yet, but they could be leveraged in theory.

Similarly, if we are keeping <maction>, there may be legitimate cases of using aria-live (which Neil introduced to me some time back in a brainstorming session).

Maybe the ARIA set is worth a brief discussion and a separate PR? Maybe not, just a thought.

[davidcarlisle]

If we say anything about aria attributes here in Core level 1, I assume we'd treat them like data-* and just say all of aria-* are valid and may have interpretations specified in applicable other specifications.

As noted in the schema comment, RelaxNG can't specify aria-* so it needs an explicit list. I picked the current list back in the mathml-refesh CG work just being the minimum required to validate some examples being discussed at the time. Happy if somone who knows more about aria can specify a better set. Best as an issue against mathml full appendix A or as a PR against mathml-refresh/mathml-schema which is still the source for the schema

[NSoiffer]

The braille aria attributes are problematic for math because there are multiple math code in the US (and elsewhere). Hence, even if you know the language of the document, you don't know the appropriate braille to generate. On the other hand, maybe they get added by JS that has found that answer out by some means. The aria braille attrs have cautions that basically say "don't use these unless you really know what you are doing because using them is wrong in most circumstances".

As for aria-live, that is super useful is some cases, but it doesn't need to be in the MathML. It can be anywhere in the document since it has an id. Although it might be convenient nestling it inside of MathML, there are issues with interacting with display in MathML and also with screen readers not finding it -- I think they treat MathML like a black box, but I don't know that for sure and the answer may depend on the screen reader. Definitely safer to have it outside the MathML.

[bkardell]

I left a few comments on individual bits, but on further reflection I wonder if alttext is different and we should just specify it and call it deprecated or optional or something (or just note that it doesn't actually do something in browsers). The reason being that the only real reason we would include it that I can see is to appease the validator gods (I don't think anyone implements this - do they? even implementing something useful with that implies that you have some kind of support I guess). Thus, we're not going to make it go away or 'undefine' it but it's also just a string and not actually subject to change or even failure/rethink in the same way as the others... Idk, maybe we should add this back to the agenda for next week?

[davidcarlisle]

I don't think anyone implements this - do they?

I understand it's used by existing speech engines that want a complete text replacement for the math, @Steve-Noble (I think) commented before that Pearson make use of this in their e-books. Also while it's not used natively in browsers it is of course available to javascript, currently the full spec draft replaces inline mathml by its alttext if mathml support is not detected (specifically if <msqrt> is not bigger than a <span>) for that use data-something would of course do as well except that alttext has been valid since mathml 1 so a natural place for non-mathml systems to look, even if mathml systems explicitly don't use it.

[bkardell]

I understand it's used by

seems like even further reason that maybe we should actually define that one in the spec and just say that browsers may (but don't) do something with it, though other systems may

[davidcarlisle]

I understand it's used by

seems like even further reason that maybe we should actually define that one in the spec and just say that browsers may (but don't) do something with it, though other systems may

Sounds good to me, I'll adjust the text in this branch later.

[Steve-Noble]

To confirm, Peason used the "alttext" element heavily in assessment content (e.g., state math assessments) to enforce very specific text-to-speech renderings of mathematics to ensure that all students are hearing exactly the same reading of the expression which has been approved by state departments of education. I know that Learnosity (another assessment vendor does this as well), and I suspect that others like ETS and AIR may also, but I don't know for sure. Text-to-Speech vendors like Texthelp support this on their end when students use their TTS apps on an assessment.

[davidcarlisle]

@bkardell hopefully 78d599a addresses your comments and this is good to go...

[fred-wang]

I would try to follow what's done for sections related to maction/mo/semantics: say that elements accept attributes and that MathML Core does not define any behavior specific to these attributes. And put rationale for including these in non-normative notes.

See
https://w3c.github.io/mathml-core/#enlivening-expressions
https://w3c.github.io/mathml-core/#operator-fence-separator-or-accent-mo
https://w3c.github.io/mathml-core/#semantics-and-presentation

[fred-wang]

Can this and other unrelated "fix tags" please be done in a separate PR, so this commit is restricted to only the relevant change?

[davidcarlisle]

It's only a couple and emacs really doesn't want to save invalid files (I already over-rode it in a few places) so I don't think it's preventing review

[fred-wang]

OK, actually I think for this kind of fixes for invalid markup which don't change the content of the spec, you can just go ahead and push the changes without asking a review.

[fred-wang]

Also "MathML Core" generally refers to itself as "this specification".

[davidcarlisle]

Can ths be merged now so we can finalise a CR draft?

[fred-wang]

LGTM from my side.