The token dilemma

[Marc Grober]

In looking at using JSXGraph with Moodle, Mauno came across what will continue
to be a problem as usage of various packages converge; the single dollar token
used by asciimathml for latex is also employed by JQuery. We have bounced
around a number of options, from moving to tags to using a new token (perhaps
broken bar). I wanted to see what the collective wisdom here had to offer....

BTW, no google wave invites available yet....

[David Lippman]

If using the dollar sign or backtick is going to cause problems, I
think the logical direction to go is tag classes, like <span
class="AM">, not a new token.

I think the JS already has support for using tag classes built in, if
you call translate with a tag class name, like translate("AM"). Well
ok, no, not really. ProcessNodeR still makes a mess with the
delimiters.

Honestly, if you were going to switch to tag classes instead of using
delimiters, amath, etc., you could ditch a ton of ugly nasty code and
replace it with some really simple code processing the tag contents
directly through AMparseMath. If you are using the AM2 approach of
separate ASCIIMath and LaTeXMath parsers, probably two tag classes
would be appropriate.

-David

>  smime.p7s
> 6KViewDownload

[Marc Grober]

I largely agree David. I have argued a meta tag for invoking a meta
math filter, which then parses token or other tags and passes
appropropriate phrases to required display app as playing with spans
can get messy - but no matter what we do there will be issues for
legacy content - and while I harp on transparency and universality
these changes may take us in the other direction-lol-a secondary
teacher with 150 fractious teens bent on flunking math doesn't have
time to be twiddling ;)

[David Lippman]

Well, it seems there are two options here:
1) branch off ASCIIMathML, creating a new tree that is not backwards
compatible
2) keep all the old code in there, and add a configuration toggle that
lets you specify whether to use "legacy" processing, or tag-based
processing.

I'm not quite sure what you mean by the meta tag.. do you mean have a
meta tag in the head of the document that tells asciimathml how to
process the document?

On Oct 21, 5:11 pm, Marc Grober <marc.gro...@gmail.com> wrote:
> I largely agree David. I have argued a meta tag for invoking a meta  
> math filter, which then  parses token or other tags and passes  
> appropropriate phrases to required display app as playing with spans  
> can get messy - but no matter what we do there will be issues for  
> legacy content - and while I harp on transparency and universality  
> these changes may take us in the other direction-lol-a secondary  
> teacher with 150 fractious teens bent on flunking math doesn't have  
> time to be twiddling ;)
>

[Paulo Soares]

The main problem is that ASCIIMathML is not evolving. It was a nice
solution when javascript was not omnipresent in the web as it is
today. Now, with all its global variables and some peculiar ways to
solve a few problems, it is bound to become a source of conflicts with
other code.

I think that David's suggestion of tag classes is a step back in the
sense that it would increase the difficulty of putting math on the
web. What needs to be replaced is the code that parses the page
contents. Roughly speaking, it currently slurps all the content as a
string and looks for delimited math expressions (ascii or latex). This
is largely inconvenient because it is not aware of the DOM structure.
Instead, the code should scan all text nodes, skip those that are
under some specified node types and parse the rest of them. In this
way, for instance, any jQuery dollar that would appear under a
<script> node would be ignored. This kind of solution can be backwards
compatible while solving problems as the one Marc reported.

--
Paulo Soares

[David Lippman]

Sounds similar to the AMdocumentId that's in the 2.0 version, but a
bit more general.

Makes sense to me. Go for it ;)

BTW, AMprocessNode does do a quick grab of innerHTML just to check if
there is a delimiter anywhere but the real work done in AMprocessNodeR
is all DOM based processing. AMprocessNodeR does a bunch of element
type specific exclusions - shouldn't be to hard to add script nodes
and whatever else you want in there if that is your main concern.

-David