#438: MathML Core
Discussions
2019-11-19
Dan: I personally haven't done anything
Alice: Same... schedule breakout? Let's take it offline
Dan: Let me put it on for next week (breakout)
Hadley: I am on board
2020-02-10
(Discussion on mixing layout and semantics, and legacy compat elements)
Alice to comment
2020-03-16
Dan: Brian has answered 7 days ago.
Alice: What Brian is saying the whole idea behind the core concept, if you are going to strip down mathml so that most of the stuff will work, then you end up with mathml core. Plus this is more consistent (CSS cascade etc).
... legacy compat things will still be parsed and worked correctly but implemented by deferring to other mathml core part or css.
... I might suggest a rewording so make it a bit more readable.
Dan: So we can close as satisfied? please work on your documentation
... This is a good response from Brian.
Alice: What is left for us to do might be looking over the spec once more.
Dan: Writing a response
2020-06-22
All: Having a look at Brian's latest coment...
Sangwhan: tricky - leaning towards option 1
Alice: that was my gut instinct as well
Sangwhan: it feels like we don't know the exact usage patterns of an href in a mathml context well enough.
Alice: what would be the downside of option 1?
Sangwhan: people may not like it...
Alice: they can wrap it - put an a-tag around the number.
Sangwhan: option 3 is very unlikely to happen.
Yves: are mathml elements considered as a block or not?
Sangwhan: that's a big meta-question. Are components of mathml text-y or SVG-y ...? not sure it matters.
Yves: if you had a solution of a polynomial equation .. and want to link a whole part of the equation to something... is it possible or not?
Sangwhan: seems logical that you would like to hyperlink parts of an equation ...
Yves: ... and we don't know the constraints put by mathml itself...
Sangwhan: ... or the implementations....
Dan: So option 1 ...
Alice: [reviewing example given here]
Sangwhan: it will be painful in the way you do it there - where each and every variable gets its own annotation.... would have to define multiple text elements...
Alice: looking at the actual mathml... they've added hrefs to everything...
Sangwhan: this is one example but doesn't demonstrate anything that touches on grouped components for example...
Alice: all leaf nodes.
Sangwhan: yes. If you think of how href behaves in the web - it does not work only on bottom level leaf nodes. I don't think this (example) alone defines a representative usage pattern...
Alice: if i put an A around a ... will it mess up the rendering?
Alice: we could say "Our first instinct is that (1) would be the simplest solution and to guide any future investment in (2) or (3) it would be useful to have a better understanding of how people are using hrefs. The last comment gives one example but that example has all the links on the leaf nodes and may not be representative of how people are using links."
Sangwhan: for this case I don't think it's particularly useful...
Alice: not clear the value you get from it...
Alice: I can leave that feedback.
Alice: the stuff that we've deferred they were wondering if we had opinions.. If we can see any obvious "foot guns". If they do want to add custom elements later on and shadow dom have they done anything to make that not possible?
Alice: .. scrolling through integration to web platform section ..
[discussion of ins and outs of shadow-dom]
Alice: they would need to come up with their own safe-list. I agree they did the right thing to punt. Seems like a niche thing.
2020-06-29
Alice: Only remaining issue is what to do with links. Brian gave us 3 options.
- Punt for now
- chose a safe list for href - more in line with the original design of MathML
- add an
maelement similar to link.
... we like option 1 since we don't know what the uses cases really are and that will give us time for arrive at the best solution for the long run.
Brian: My preference as well. Not the CG preference, but certainly mine. Being forward looking this seems to be the best option at hand and too many unknowns. ... There is lots of existing content using links and we need it for backwards compat.
Peter: Existing content is in XML?
Brian: All over the place, but yeah, mostly. MathJax too.
Alice: The MathJax stuff is not super relevant? Because it generates html?
Brian: Yes and SVG too. A lot of folks have XML and all they need to do is change their mapping and regen.
Alice: So in summary, Punt for now seems the best option and the one we all agree on? (summarizes more unknown behaviours - various modality of click etc.)
Tess: The idea behind Html.... was to fire the href on the element.
Peter: If we consider XHTML, any element with an href can become a link.
Alice: How feasible is it to embed HTML?
Brian: You can't
Alice: Because it breaks formatting?
Brian: Yes and it is weird.
Tess: Is that any worse than a tr? The goal isn't to make any arbitrary HTML work inside MathML, but, make MathML as capable as HTML in terms of links at least.
Peter: Any use cases where an entire row is supposed to be a link?
Brian: Yes, not in the same was as a table row in HTML but mrow can be a link.
... If we have a new math-link element in the future, it will make a lot of sense as it will be as useful as HTML and SVG.
Tess: If mrow is supposed to be link-capable, I would expect the same effort will make tr the same, right?
Brian: ack
David: Does option 1 mean there aren't problems for linking individual symbols? And using HTML doesn't interfere with MathML's formatting ??
Brian: No
Alice: Why can't we have links in the middle?
Brian: The parser as it will close everything in the current context.
Peter: ??
Tess: Use case question. I recall from school that, when you have an equation you've never seen before, the teacher used to point out particular parts of the equation - the numerator for example etc. I want such parts to be clickable and usable for such examples.
Brian: Right! This is definitely a use case that we're tracking and want to make possible. Hence the reason for links :)
Brian: What about Sangwhan's comment?
Alice: (summarizes Sangwhan's comment)
Brian: Honestly, don't understand the comment. I will ask for more details.
Peter: Just did some testing and it seems that Firefox is pretty happy with HTML links around mrow.
Peter: So maybe you can just throw as randomly inside MathML?
Brian: Not sure what's up here. Will investigate more.
Rossen: So have we convinced ourselves that we should advice any other option than 1 at this point?
Alice: Perhaps not. We should continue working with the MathML folks and see if that'll work for them.
... (more discussion about Peter's example) Seems to work in Firefox...
Brian: I suppose the question still is - can we try to document what's happening with Firefox and seemingly Safari or go with option 1? FWIW, the CG is interested in the TAG's opinion.
Rossen: Would they be OK with Option 1?
Alice: (missed)
Brian: Sure. The CG will also be interested what the current browsers do and how to transition everyone to a compat state.
David: I'm OK with 1 as long as linking of tokens works reasonably and in interaction with other things...
Brian: For sure.
Alice: David, is the existing FF support of links (href) everywhere, any thoughts?
David: Not sure.
Alice: Later if you decide you want shadow DOM, you will be OK to change?
Brian: Yes.
Peter: HTML5 dropped the ball on namespaces and made the situation confusing. There is no way to gracefully exit/enter between HTML, MathML, SVG. Transitioning between them requires closing everything and only then transition into another space.
Brian: Thank you for all the time spent on the issue. Sounds like there is agreement about use cases and the importance of linking, we just don't want to rush into the specification before we know more?
Alice: Yes, and unshipping such changes in engines will be complex.
Rossen: So recommend option 1?
Tess: Sure, we will summarize and recommend in the issue.
Brian: Having two shipping impls makes it difficult.
Alice: Yes, and unshipping is difficult. Also, we don't lose much by delaying a concrete specification.
... also, it will be important whether implementers are willing to remove the existing behavior of href, or else we'll still have to deal with the disadvantages of it in the future.
Tess: Have we asked if unshipping the current href behavior is something implementers would do?
Brian: Not formally. Happy to go ask around
2020-07-13
Alice: ...the story so far...
Sangwhan: Brian asked me about my question.
Alice: that's like an extra level of complexity I don't think we need to consider.
Sangwhan: something that isn't quite solved but might be useful.. math would suffer from this being not there - especially when moving symbols around...
Hadley: if the benefit of that is any instances of a variable resolve to some instance of the variable... doesn't feel that different from the rest of the web - to do it in a CSSey way or instantiate each time.
Sangwhan: My response to Brian was:
Okay, so imagine a simple equation like this: y = ax + b Where ax links to something. Now twist this a bit: y / a = x + b / a But you want to note that / a, x, and the other /a all link to ax, since the term is there - pointwise links for each of them is doable, but then the semantic group connection is lost. y ^ 2 = ([ax]) ^ 2 + 2[a]b[x] + b ^ 2 or something like this where the [] indicate the group
... I told them I don't want this solved now. But the example they linked was way too simplistic for common use cases for longer equations. Don't care if it's not solved right now. Feels like doing something premature would not be good.
Alice: but what do we do about what's already shipped with hrefs?
Sangwhan: un-ship?
Alice: breaks a bunch of existing content... Brian said towards the end of that call... a lot of people are saying "my code won't work in Chrome then.. oh well". This is supposed to be about creating an interoperable baseline standard.
Dan: We're not the ones controlling the code base. We could issue a recommendation...? We could do what Sangwhan said...
Sangwhan: ...that we already rushed out MathML and that's why interop is hard now. Maybe take it step-by-step and try to do it better this time. It's not interoperable right now. Safari, Chrome and firefox already have three different implementations. Not good.
Dan: Could we favour option 1 because there isn't enough consensus about the right answer? and if you ship anything other than that, make sure people know it's an experimental feature and not part of the spec?
Alice: but it's been shipping for decades. This is the thing, why they had to do this project so carefully. there is all this MathML out there, all edge-case-y and fragile. Do we break all that? What's the cost of that? Can we get the browser vendors that are shipping MathML to buy into unshipping it and breaking all of that content?
...Possibly shadow DOM is the most compelling reason. I linked in my comment to a discussion they were already having. Attaching shadow roots depending on whether there was an href. But that's funky, right? So maybe we should say for future compatibility with shadow DOM, option 1 is a very neutral option, and doesn't lock you into requiring special rules. Option 3 might be one possible future direction once we understand the use cases more fully — but it might be a good idea to revisit the use cases, and see if a more nuanced design can be reached. This does mean a lot of existing MathML won't work in chrome and will stop working in other implementations. That is regrettable, but — it will be trivial to write a little polyfill that at least repairs the functionality for leaf nodes.
Hadley: it feels like we need the working group to figure it out. I'm hearing the wg's work doesn't have buy-in from all the implementers. We could come up with a solution but we aren't the right people.
Alice: Implementers ... existing implementations in webkit and firefox that go back years - implemented in the early days - when blink forked from webkit we removed mathml. Not sure if the implementers already shipping would buy in to unshipping href everywhere. The folks who are saying "i don't like anything that doesn't involve href everywhere" are not implementers. They have content.
Hadley: both of those problems feel to me -
Alice: they've discussed it at length and that's why they asked us.
Hadley: our response should be: this is us operating in a perfect world vacuum but we feel like the implementers, authors and developers ideally should reach consensus. Our job should be to help them set boundaries. Feel this shouldn't be out responsibility.
Alice: what flavour of advice would be appropriate?
Hadley: level you were talking about is fine. Adding a line or 2 about how all of these points of view should come from implementers, browsers, authors, developers.. we are proxying for them. means that we encourage the WG think about bringing these views to the table.
Alice: value of option 1 is that it doesn't require extra work but gives you the capability to add links - and is future proofs; option 3 can be disregarded - can come later as an add on. Option 2 rules out option 1 and makes option 3 moot but it has the value of being backwards compatible.
Hadley: maybe share that feedback.
Dan: I feel like our response should lean towards option 1. And then see what happens in the implementation and content space and revisit.
Hadley: ... close to the way you do things in [html] content ...
Alice: option 2 is the href on every mathml element...
Alice: [on option 1] simplicity, doesn't put you in an awkward position re shadow roots, and it does put you in a position to come up with a more nuanced solution re: sangwhan's point.
Dan: I will come up with a proposed closing comment based on our discussion that we can agree on at the plenary call
OpenedOct 30, 2019
Hello TAG Friends!
I'm requesting a TAG review of:
Further details:
You should also know that...
MathML Core comes from previous TAG review of MathML specs/plans. Among our primary aims is to establish an interoperable and widely agreeable starting point for discussions that have been created by MathML's largely unique history. We've taken very much history, commentary (including TAG's) and challenges into account. We've taken great pains to balance many things: Making this as small as possible, align as directly as possible with the rest of the platform (including DOM and CSS), eliminate unknowns and surprises, apply learnings from actual implementations (firefox, webkit, office and TeX), rigorously specify and remain useful and compatibile, improving the many documents that already exist.
We'd prefer the TAG provide feedback as (please select one):
Security Questionnaire...
What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
Is this specification exposing the minimum amount of information necessary to power the feature?
How does this specification deal with personal information or personally-identifiable information or information derived thereof?
How does this specification deal with sensitive information?
Does this specification introduce new state for an origin that persists across browsing sessions?
What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin?
Does this specification allow an origin access to sensors on a user’s device
What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts. * Nothing
Does this specification enable new script execution/loading mechanisms?
Does this specification allow an origin to access other devices?
Does this specification allow an origin some measure of control over a user agent’s native UI?
What temporary identifiers might this this specification create or expose to the web?
How does this specification distinguish between behavior in first-party and third-party contexts?
How does this specification work in the context of a user agent’s Private Browsing or "incognito" mode?
Does this specification have a "Security Considerations" and "Privacy Considerations" section?
Does this specification allow downgrading default security characteristics?