MathML-in-HTML5

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

William F Hammond
Ian Hickson <[hidden email]> writes:

> On Wed, 27 Sep 2006, Roger B. Sidje wrote:
> . . .
>> Implementation-wise, as this inclusion of MathML-in-HTML5 marks the
>> beginning of tag soup, ...
>
> Don't worry, these tags auto-close when a parent tag is closed.

Two points for clarification:

1. There's the old issue, related to dual parsers, of trying to get
Mozilla family user agents to give proper handling of XHTML+MathML
when served through text/html -- following early Amaya practice.  (In
the end the W3C HTML WG refused to support this idea and spawned the
mimetype application/xhtml+xml.)  It seems that formally correct
XHTML+MathML would now gain coverage as text/html under current WhatWG
thinking, at least when XML namespaces are evident only through use of
the xmlns attribute (which would be ignored in tag soup), i.e., no use
of xml namespace prefixing.  Is this correct?

2. Is WhatWG entertaining the idea that off-the-cuff tag soup writers
will generate MathML content that's good enough for Mozilla rendering?

---

In case you don't know:

The W3C Math group has announced that it is beginning to think seriously
about author-level markup for math.

Long term -- say ten years in the future (we've already been at this
for ten years) -- I think author level math additions to the tag soup
vocabulary would work out much better, especially with enhanced CSS
support.

Cheers.

                                    -- Bill

----------------------------------------------------------------------
William F. Hammond                   Dept. of Mathematics & Statistics
518-442-4625                                  The University at Albany
hammond At math.albany.edu                   Albany, NY 12222 (U.S.A.)
http://www.albany.edu/~hammond/                Dept. FAX: 518-442-4731
----------------------------------------------------------------------

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

David Carlisle
In reply to this post by Roger B. Sidje
I don't think I saw Ian's original comment, Just Roger's reply?

 > What I would be proposing for HTML5 is just the following list of
 > elements:
 >
 >    math, mrow, mfrac, msqrt, mroot, mstyle, merror, mpadded, mphantom,
 >    mfenced, menclose, msub, msup, msubsup, munder, mover, munderover,
 >    mmultiscripts, mtable, mlabeledtr, mtr, mtd, maction

You would beed to include the leaf elements (mi mn mo mtext) otherwise
there'll be no characters in the mathml!, also mspace is pretty
important.

But a more general point I think it's dangerous for a spec to be
profiled by _implementations_. The Math WG activity has just been
restarted at W3C and if there is a need to profile MathMl to
presentation MathML (or a subset thereof)  please can it be done _there_
so that there is some chance that mathml authoring tools can be
customised to have options to generate code to match any profiled spec.



> I don't like mlabeledtr very much (I have already expressed my views
> about it to folks of the MathML WG)

Roger, I don't see anything searching for
http://www.w3.org/Search/Mail/Public/search?type-index=www-math&index-type=t&keywords=mlabeledtr&search=Search
I know you've talked to us at conferences etc, but we're all getting old
and if comments aren't on the comment list, then they are likely  to get
forgotten over time.

_Now_ would be a really good time to make such comments as we are in the
process of finalising the requirements for what extar features should
be in MathML3, and what if necessary, features should be deprecated.


I don't remember specific discussions about an  <mtr label="..."> I
would guess there woul dbe some convern about the label being an
attribute rather than an element restricting the possibilities, but
implementation advice on difficulties on teh current schem woul dbe
taken seriously....

Ian wrote about entities
> Yeah... Do we really need those? Some of them seem reasonable to add, but
> 2000 seems like too many for the mnemonic advantage to beat just using
> Unicode codepoints...

I'd say that it's probably not worth including only a few, it would just
lead to confusion. The problem is that much mathml is generated using
tools and those tools may use entities, and if they do that the user
hasn't much control over which are used, and how to fix things to remove
entities that are not supported in the browser. It would be better to
just get the MathML authoring tools to use characters or character refs
directly and tell the user mathml entities are not supported (but html
ones are)

David

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

Ian Hickson
In reply to this post by boards (Bugzilla)
On Wed, 27 Sep 2006, Matt Sicker wrote:
>
> Oh, I've seen this problem before; when people would link to Image
> Shack, part of the URL contained "&image=foo".  Of course, it looked odd
> seeing the "&image" part become the imaginary part character (kinda
> looks like a dragon), but the URL still worked.

Really? If it still worked, that implies that argument was ignored, no?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

Ian Hickson
In reply to this post by William F Hammond
On Wed, 27 Sep 2006, William F Hammond wrote:

>
> 1. There's the old issue, related to dual parsers, of trying to get
> Mozilla family user agents to give proper handling of XHTML+MathML when
> served through text/html -- following early Amaya practice.  (In the end
> the W3C HTML WG refused to support this idea and spawned the mimetype
> application/xhtml+xml.)  It seems that formally correct XHTML+MathML
> would now gain coverage as text/html under current WhatWG thinking, at
> least when XML namespaces are evident only through use of the xmlns
> attribute (which would be ignored in tag soup), i.e., no use of xml
> namespace prefixing.  Is this correct?

I'm confused by your terminology.

MathML using namespaces and XML syntax would not, under the WHATWG
proposals here, be formally correct. XML sent as text/html is never
correct per the "WHATWG thinking".

What is being proposed here is a non-XML syntax, to be formally described
in the HTML5 specification, which, went processed by an HTML5 UA, would
generate a DOM that can then be processed per the MathML2 specification.

Per the WHATWG specifications, the presence of an "xmlns" attribute is
always a conformance error in any content sent as text/html.


> 2. Is WhatWG entertaining the idea that off-the-cuff tag soup writers
> will generate MathML content that's good enough for Mozilla rendering?

The idea being entertained is that off-the-cuff HTML5 authors, and HTML5
editors, would create content which, when processed by an HTML5 UA (such
as Mozilla, in due course), would render as MathML markup would.


> The W3C Math group has announced that it is beginning to think seriously
> about author-level markup for math.
>
> Long term -- say ten years in the future (we've already been at this for
> ten years) -- I think author level math additions to the tag soup
> vocabulary would work out much better, especially with enhanced CSS
> support.

On the very short term, the proposal here is just a proof of concept. On
the medium term (12 months) I was considering specifying more complex
parsing rules for MathML such that the same MathML2-compatible DOM could
be obtained from much smaller markup, e.g. by implying <mo> tags around
operators and <mn> tags around numbers.

HTH,
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

Roger B. Sidje
In reply to this post by David Carlisle
On 28/09/2006 2:44 AM, David Carlisle wrote:

> I don't remember specific discussions about an  <mtr label="..."> I
> would guess there woul dbe some convern about the label being an
> attribute rather than an element restricting the possibilities, but
> implementation advice on difficulties on teh current schem woul dbe
> taken seriously....

Here is an informative thread about it:
http://groups.google.com/group/netscape.public.mozilla.mathml/browse_thread/thread/d77d015a1fffc6fb/5b0eb0cc9724ce72
(not on www-math, though. Maybe I should forward it there?)

It appeared that attributes (like those in <mfenced>) aren't unanimous
either. But having a bloated tag that won't be implemented in the next
several years isn't really helpful.

> Ian wrote about entities
>
>>Yeah... Do we really need those? Some of them seem reasonable to add, but
>>2000 seems like too many for the mnemonic advantage to beat just using
>>Unicode codepoints...
>
> I'd say that it's probably not worth including only a few, it would just
> lead to confusion.

I am actually a fan of entities because they improve readability a fair
bit. I hope Ian won't give up thinking on this issue so quickly...
especially in the context of MathML where strange characters are quite
common.

As to my suggestion that "if [a document] is strict then maybe entities
could be required to have a semi-colon -- which will then avoid the
ambiguities", to which Ian responded that, "That would break back-compat."

We have other cases of broken back-compat. -- where users were told to
use a non-strict DOCTYPE or some other workaround, e.g, line-height of
images.
---
RBS
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

David Carlisle

Roger,
 Thanks for the link on <mtr label="mylabel">,

> It appeared that attributes (like those in <mfenced>) aren't unanimous
> either.

yes mfenced also "suffers" from requiring attributes, but probably one
is more likely to need markup in an equation label than in a stretchy
operator. It's not so uncommon to want superscript * or daggers etc to
highlight special versions of formulae, and mfenced is explictly a
shorthand form so you can always use the mwrow/mo form if you need an
operator that is "decorated" in some way. That would not be the case
here if mlabeledtr were deprecated and an attribute form was the
only version. (Actually it would if the attribute could then be
css-styled using css generated content. Allowing css (or other
mechanism)  auto numbering is I think a highly requested feature for
mathml3.




> (not on www-math, though. Maybe I should forward it there?)
Yes please do. When we are doing a pass for errata or pulling in feature
requests for a new version we can do a more or less exhaustive check of
the official comment list but (even with google's help) doing an
exhaustive check of the entire web's a bit hard:-)


The charter for the current working group

http://www.w3.org/Math/Documents/Charter2006.html

has as one of its headline work items

   Extension of MathML with enhanced support for equation labeling,
   including automatic numbering, general label placement and style, and
   resolution of references.

so getting that specified out in a way that ensures that implementations
can implement it sounds like a good idea, and the timiming is good now
to get new features in this area if that is needed. If WhatWG members
are interested in mathml most of them are w3c members and could join the
WG of course (currently only Opera is represented out of the main
browser vendors) But WG membership isn't really needed we can do the
technical discussion on the public www-math list if that is appropriate.

> I am actually a fan of entities because they improve readability a fair
> bit.

Well as you know I've invested a frightening number of houres maintaining
that entity set (and the draft iso set at www.w3.org/2003/entities,
which is the same thing, really) so I'm also think they are valuable,
although it's a kind of love-hate relationship most of the time:-)

>  I hope Ian won't give up thinking on this issue so quickly...
> especially in the context of MathML where strange characters are quite
> common.

Yes I think the ideal situation is that they all be allowed. My comment
was that subsetting them is likely to be more confusing than helpful.

> As to my suggestion that "if [a document] is strict then maybe entities
> could be required to have a semi-colon -- which will then avoid the
> ambiguities", to which Ian responded that, "That would break back-compat."

Requiring a ; would seem reasonable to me (ie make the lack of a ; make
the & into an implict &amp; rather than be an error as in xml).
That does have a theoretical backward compatibility problem in that
&rightarrow; would be an arrow instead of &amp;rightarrow; but I would
have thought that the occurrences of any such construction outside of
test suites was rather rare.

David
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

Ian Hickson
In reply to this post by Roger B. Sidje
On Thu, 28 Sep 2006, Roger B. Sidje wrote:

> >
> > Ian wrote about entities
> >
> > > Yeah... Do we really need those? Some of them seem reasonable to add, but
> > > 2000 seems like too many for the mnemonic advantage to beat just using
> > > Unicode codepoints...
> >
> > I'd say that it's probably not worth including only a few, it would just
> > lead to confusion.
>
> I am actually a fan of entities because they improve readability a fair
> bit. I hope Ian won't give up thinking on this issue so quickly...
> especially in the context of MathML where strange characters are quite
> common.

I really don't want to start introducing weird rules for parsing entities
(I'm trying to simplify the entity parsing rules, not make them worse). At
least not at this stage. Maybe once we have a proof-of-concept working, it
would make more sense to revisit the issue, but I'd want to do a thorough
scan of the Web to see how common these entities actually are today.


> As to my suggestion that "if [a document] is strict then maybe entities
> could be required to have a semi-colon -- which will then avoid the
> ambiguities", to which Ian responded that, "That would break
> back-compat."
>
> We have other cases of broken back-compat. -- where users were told to
> use a non-strict DOCTYPE or some other workaround, e.g, line-height of
> images.

Yeah. And we can see how well _that_ went. QA nightmare, multiple
overlapping codepaths, obscure bugs, confused authors, contradicting
documentation, etc. Let's not go there again. The whole point of
MathML-in-HTML is to have back-compat work -- if we didn't care about
back-compat, we would just have people use MathML-in-XHTML.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

Roger B. Sidje
In reply to this post by David Carlisle
On 28/09/2006 7:24 PM, David Carlisle wrote:

> Roger,
>  Thanks for the link on <mtr label="mylabel">,
>
>
>>It appeared that attributes (like those in <mfenced>) aren't unanimous
>>either.
>
>
> yes mfenced also "suffers" from requiring attributes, but probably one
> is more likely to need markup in an equation label than in a stretchy
> operator. It's not so uncommon to want superscript * or daggers etc to
> highlight special versions of formulae, and mfenced is explictly a
> shorthand form so you can always use the mwrow/mo form if you need an
> operator that is "decorated" in some way. That would not be the case
> here if mlabeledtr were deprecated and an attribute form was the
> only version. (Actually it would if the attribute could then be
> css-styled using css generated content. Allowing css (or other
> mechanism)  auto numbering is I think a highly requested feature for
> mathml3.

The danger (and problem) with that tag is that it is over-designed to
accommodate the tiny set of special-cases you alluded to, while holding
the 99.99% majority of cases hostage. One could put up with CDATA all
the way, e.g., (6') or (7*), (8&dagger;), (9a), etc -- if a subequation
is really needed. I would think we can put with this and reap the
benefits. A <mtr label="mylabel"> tag that stands a chance, degrades
gracefully, *free* cross-referencing (with href#mylabel -- by just
invoking what the browser already does with <a name="...">), the
counters that you mentioned (which work in Gecko today, BTW), etc.
(Also conceivable, optimistically, is a pseudo-class :label to style the
label text, but we might going ahead of ourselves...)

Seems to me that the concrete benefits that might result outweigh the
feeling against an attribute.

>
>>(not on www-math, though. Maybe I should forward it there?)
>
> Yes please do.

OK.

> Well as you know I've invested a frightening number of houres maintaining
> that entity set (and the draft iso set at www.w3.org/2003/entities,
> which is the same thing, really) so I'm also think they are valuable,
> although it's a kind of love-hate relationship most of the time:-)

Yeah. Let's hope Ian is listening and keeps these entities on his radar...
---
RBS
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

David Carlisle


> Seems to me that the concrete benefits that might result outweigh the
> feeling against an attribute.

Which is why it's good to get real implementation experience into the
language design (or update). Either by implementors joining the WG  or
by doing the technical design on the public www-math list so you and
others can join in (or both).

David


_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: MathML-in-HTML5

White Lynx
In reply to this post by Roger B. Sidje
It would be nice if Mozilla developers could clarify why they decided
to move in this way.

My main concerns are twofolds, first is the fact that converting
currently XML based MathML to text/html tagsoup is not the step in
right direction as MathML community has no text/html legacy content and
there are simply no MathML implementations that support text/html, but
does not support X(HT)ML, while there definitely are XML only MathML
implementations and different XML tools are used by MathML community
and the fact that all MathML content is wellformed be design is
something that did not come for granted, people had to pay price for
this for seven years until finally MSIE/MathPlayer started to recognize
application/xhtml+xml and thus allowed people to deliver the same
XHTML+MathML to MSIE/MathPlayer and Mozilla. So today is the most
inappropriate time to make experiments that may convert XML math
content to tag soup.

Second concern is related to MathML/CSS integration issues, I think I
should not be explaining that for mathematical markup language it is
important to be integrated with the environment in which math formulae
are embedded. In case of web this environment is XML/CSS/DOM (well
there are people that think that universe = text/html, but math markup
simply MUST be highly extesible as requirements  of math community are
diverse and it is not uncommon to combine presentational MathML with
other XML applications, including OpenMath, content MathML, sometimes
SVG and other XML applications).

Currently there is subgroup in W3C Math WG chartered to address
MathML/CSS integration issues so one could use appropriately designed
profile of MathML in XML/CSS framework, that is we are moving towards
markup language that admits default CSS style sheet. This process
requires coordination between Math WG (some changes are required on
MathML side), CSS WG (at least some CSS extensions are needed to ensure
minimal requiremnts of math markup are addressed) and browser
developers that are most exposed to issues that arise from lack of
MathML/CSS integration. Opera is involved in process in hope that in
long term perspective MathML will work smoothly in XML/CSS environment
and many artificial incompatibility issues and unnecessary doubling of
functionality at the price of tons of bugs and underspecified issues
that emerge in componud documents due to incompatibility between
different specs, Microsoft intends to join Math WG that hopefully will
help to coordinate efforts between math markup related activities in
ECMA backuped by Microsoft and at least partly avoid problems with
double standards W3C vs. ECMA in the area, I am sure we would be glad
to see Mozilla onboard either by joining WG or being involved in the
process otherwise in any convenient for you form, as well as developers
of other layout engies including KHTML/WebKit and Prince. However I am
seriously concerned about spontaneous changes that may take MathML
further from XML+CSS framework and I am surprised that initiative for
such a changes is coming from Mozilla foundation. Today is the most
inapproprite time for turning things upside down, but definetely is a
good time to improve coordination between different working groups and
browser developers to resolve actual problems.

Note also that Math WG has subgroups like liason with WhatWG and liason
with CDF chartered to impove coordination between different units and
ensure that MathML works smoothly in compound documents. So there is a
lot of space for moving the process through this channels instead of
making unilateral steps that may damage MathML in long term perspective.

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
12