Re: Summary of MathML call meeting

I'm in agreement with deprecating mglyph. I'm a little less sure about
menclose's msqrt, but without a strong argument in favor of keeping it, am
ok with deprecating it.

I'm not disagreeing with the "deprecated implies not in core", but the
converse "not in core implies deprecated" is not true. My statement about
duplicative elements/attrs was about the discussion of when something *can *be
pulled from core. The msup example was meant to show that *can* is not
*should*.

Probably not worth continuing this line, but just to be clear, we could
define <msup> === <msubsup> <none/> sup </msubsup> and say that
SubSuperscriptGapMin does not apply when only one non-none arg is given.
This would remove four elements from core. In the early days of MathML,
some people used msup, etc., as examples of MathML having too many tags and
hence being too complex. However, I haven't heard you or other implementers
complain about msup, mover, etc., being extra complexity.

@Fred: Thanks for adding to the agenda [1] the deprecation items. Anyone
who feels that the items in [1] should remain in core or at the very least
not be deprecated please provide your reasons in the linked items before
the core meeting on Monday. The group will likely make decisions so
Igalia's implementation can move forward.

Thanks,

    Neil


[1] https://github.com/mathml-refresh/mathml/issues/8 (Topics for 18/3/19
core meeting)

On Fri, Mar 15, 2019 at 12:37 AM Frédéric Wang <fwang@igalia.com> wrote:

> OK, but this general principal is a bit subjective, compared to the one
> "deprecated implies not in core". For example, you mentioned that
> munder/mover are less common, but they are still used a lot in my opinion
> (e.g. $\sum_{i \in I} \overline{a_i}$). You also suggest that we have
> duplication between all these script elements but there are subtle
> differences. For example SubSuperscriptGapMin,
> SuperscriptBottomMaxWithSubscript are taken into account in msubsup layout
> (or displaystyle="false" munderover with largeop base) but not in msub/msup
> layout. Karl Tomlinson (Mozilla) suggested that special treatment for empty
> boxes in msubsup would bring extra complexity (
> https://bugzilla.mozilla.org/show_bug.cgi?id=827713#c36 ).
>
> The two cases I mentioned seem to be at the level "never seen in any Web
> page" but again some people might think differently. mglyph has never been
> implemented in browsers and there is not any plan to do it.
> notation="radical" is implemented in Gecko/WebKit but brings extra
> complexity. Incidentally, these two kinds of argument are also important to
> take into account by this CG IMHO.
>
> In any case, we are not in hurry I'll wait formal approval (or not) next
> Monday before moving on with notation="radical" and <mglyph>.
>
> On 14/03/2019 23:01, Neil Soiffer wrote:
>
> Yes. I believe we agreed that duplicative things that aren't commonly used
> could be removed from core because a polyfill can easily generate them. An
> example of something that can't be removed is <msup> even though it could
> potentially be turned into <msubsup>; the feeling was that was way too
> common and core should handle that. We didn't discuss munder/mover. I think
> these are much less common than msup/msub, but I would think some sort of
> symmetry argument would mean that if msup is in core, mover should be in
> core.
>
>     Neil
>
>
> On Thu, Mar 14, 2019 at 8:55 AM David Carlisle <davidc@nag.co.uk> wrote:
>
>> On 14/03/2019 13:38, Frédéric Wang wrote:
>> > Do I remember correctly that we agreed to remove menclose "radical"
>> > notation and mglyph (currently not in core):
>>
>> I'd have no objection to those not being in core.
>>
>> David
>>
>>
>> *Disclaimer*
>>
>> The Numerical Algorithms Group Ltd is a company registered in England and
>> Wales with company number 1249803. The registered office is: Wilkinson
>> House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy
>> Notice <https://www.nag.co.uk/content/privacy-notice> for information on
>> how we process personal data and for details of how to stop or limit
>> communications from us.
>>
>> This e-mail has been scanned for all viruses and malware, and may have
>> been automatically archived by Mimecast Ltd, an innovator in Software as a
>> Service (SaaS) for business.
>>
>
> --
> Frédéric Wang
>
>