[JavaScript] xyTex Math notation Parse

[GooS]

XyTeX - Math Notation Parser
v0.42
By: xy-cube AKA GooS

I want feedback from people using any browser.

Anyways, it parses some code and outputs better math notation based on some rules. If you find something that needs adding, drop a comment.
It has some problems works relatively well.

Here's it is: xyTex test page

Working in Opera, Chrome, FireFox, Internet Explorer, Safari each with its own flaws and to different degrees

• FireFox - Tested in v 3.6.x
• Opera - Tested in v 10.x
• IE - Tested in v 8.x
• Chrome - Tested in v 10.x
• Safari - Tested in v 5.x

(If your experience varies in any of these browsers, make sure you have the latest version!)

Has about the same amount of minor flaws in FireFox, Chrome, Safari and Internet Explorer, Opera is... it's.. read in updates..

Might also be problems with font ("MS Serif", "New York", "serif") as not all have support for all characters used.
Swapped

Currently working on:

1. Separation of operation statement into integration, differentiation, operation (for summation/product/coproduct) and limitation, to set up more specific CSS rules, walks hand in hand with below.
2. Rewoking CSS for a more standardized cross-browser experience, might make it work with older browsers
3. Notation Fixes
4. Chunk Updates
5. General Performance Fixes

Known problems that haven't been solved ( no need to "report" ):

• [X]Vertical division notation within a radicals scope
• [X]Double ending square brackets in vertical division notation

Updates:
(From when posted)

• Swapped font series to "MS Serif", "New York", "serif"
• Added source only document, no clutter of explanations, this document completes validation perfectly (Link on module site).
• Added CSS Reset
• Fixed CSS reset to only work with xyTex elements
• Added image for contour integral as the font one looked awful
• Further Optimization to CSS
• [X] IE problem seems to be that getElementById doesn't work for non-default elements (the xytex elements I use), fixed by using the
  "HTML5 IE Fix", adding a document.createElement('xytex'); in the header. However, it still can't seem to handle it's properties as the other browsers
  can, resulting in the defaulted UnknownxyTex.
• [X] IE doesnt use a property named contentText for the hull of the content in an element, it uses innerText, so changed that and it actually
  parsed, now theres only one problem, the styling is sooooo f*cked up!
• Though that wasn't really IE's fault, stupid me for not setting a DOCTYPE, with xhtml1 strict IE bulked up presented me with a much better
  notation, only problem I can find is with integrals and vertical division notation.
• Swapped from custom tags (obeying magentix) and changed to div tags with lang="xytex", making first IE update and "HTML5 Fix" obsolete
• [X] Now working (Reads/Parses/Outputs) in Chrome, IE and Opera aswell, though still flaws in, mainly, CSS for the output.
• Now looks -Good- in Chrome, IE and FireFox, Opera (is a misfit I don't want to play with, wtf is moving elements around when marking them? o.=) but better than before in opera aswell.
• [X]Vertical-align, especially in Chrome FIXED (with above)
• Safari Fixes added, works real well in latest safari, cept for that it can't find a serif character for coproduct and substitutes a sans-serif, minor flaw
• v0.42 Reworked CSS structure for Operation[] and div[], making it much more cross-browser friendly, vertical-align fix still required for Chrome and Summation/Product/Coproduct still needs work in all other browsers, even so I still see it as a step forward.
  

See source for CSS and Script

Post anything you may have to say about it, critisism very welcome!

//== GooS

 

[tooltiperror]

... I hope this makes it to Webmaster Resources upon completion :thup:

Anyways, as for the actual code, I don't think I have the expertise to comment on it.

Edit: Wow, beautiful interface.

 

[Magentix]

Try using a CSS reset like YUI's, HTML 5 boilerplate's or Eric Meyer's to see if that fixes your problem.
Different browsers, different defaults...

 

[GooS]

Thx tooltiperror

@magentix

Reset made no difference, however added it as it may be usefull later on.

What I know about the cross-browser problems is:

Chrome: vertical-align problem, does not handle as opera and firefox.
Opera: Not vertical align as first thought, some size/float/wrapping problem
IE: JavaScript Problem and will probably have CSS problems once that's been solved.

Edit: IE problem seems to be that getElementById doesn't work for non-default elements (the xytex elements I use), fixed by using the
"HTML5 IE Fix", adding a document.createElement('xytex'); in the header. However, it still can't seem to handle it's properties as the other browsers
can, resulting in the defaulted UnknownxyTex.

Edit2: IE doesnt use a property named contentText for the hull of the content in an element, it uses innerText, so changed that and it actually
parsed, now theres only one problem, the styling is sooooo f*cked up!

Edit3: Though that wasn't really IE's fault, stupid me for not setting a DOCTYPE, with xhtml1 strict IE bulked up presented me with a much better
notation, only problem I can find is with integrals and vertical division notation.

 

[GetTriggerUnit-]

This is very nice. Good work!
The implementation is easy and it's user friendly. I hope you can get it cross browser!

Some benchmarking on it's effect on pages would be nice, does it slows the page loading a lot?

EDIT: Forgot to add: You might want to optimize your code! http://code.google.com/intl/fr-CA/closure/compiler/. jQuery's min version is made using that compiler or at least one that is similar.

 

[GooS]

Thank you,

The implementation is easy and it's user friendly. I hope you can get it cross browser!

You said it, I bring it, I'm on a serious roll!

Internet Explorer v 8.x Strict - FIXED (Minor Operation Vertical Alignment Flaw)
FireFox - (Minor Operation Vertical Alignment Flaw)
Opera v 10.x - FIXED (Minor Flaws (Actually seems to be in Operas rendering, check it out and you will see what I'm talking about), A font problem where coproduct is displayed as larger than the other browsers)
Chrome - The one with the most faults in currently, it just doesn't seem to appreciate % vertical-aligns.

Current best displayed is actually IE,, who would've guessed.

Just an easy minor benchmark with some initial values:

	                                        |      Document       |      Fully Loaded       |
	                Load    1st B   R*       Time 	Req 	B In 	Time 	Req	Bytes In

No Parsing: 

First View 	        0.946s 	0.528s 	0.953s 	0.946s 	3 	8 KB 	0.918s 	3 	8 KB
Repeat View       	0.746s 	0.389s 	0.754s 	0.746s 	3 	0 KB 	0.719s 	3 	0 KB

Parsing:

First View    	       1.133s 	0.386s 	0.704s 	1.133s 	3 	15 KB 	1.447s 	4 	19 KB
Repeat View  	       0.979s 	0.376s 	0.696s 	0.979s 	3 	0 KB 	1.283s 	4 	1 KB

R* = Starting Render
B In = Bytes In

(Gonna make a javascript only bechmark later)

Edit:

EDIT: Forgot to add: You might want to optimize your code! http://code.google.com/intl/fr-CA/closure/compiler/. jQuery's min version is made using that compiler or at least one that is similar.

I will minimize it myself once a viable version is ready, absolutely need to work out some performance stuff first, such as the chunk array handler.

//==GooS

 

[Magentix]

Surprised to see that you both did not set a DOCTYPE -and- yet did know about the HTML5 tag-fix.

P.S.: Using custom elements is always a no-no IMO. Just use whatever real tag you'd otherwise use. You can't invent your own tags and then complain that browsers don't handle it all that well

 

[GetTriggerUnit-]

I am using Opera and it seems like there's only a few signs that do not work properly (as demonstrated in the picture below).
Red bad, Green good.

Spoiler

Could it be an "hardcoded" issue?

 

[GooS]

Surprised to see that you both did not set a DOCTYPE -and- yet did know about the HTML5 tag-fix.

P.S.: Using custom elements is always a no-no IMO. Just use whatever real tag you'd otherwise use. You can't invent your own tags and then complain that browsers don't handle it all that well

Me to, that what happens when I get to exited about the script and completely ignore HTML, yeah it probably/definetely isn't a good thing adding custom elements which is why, as state on the page, I will add a scripted creation at some time in the close future.

Unless people wants it in tags, then tell me which tag I should use, that most people dont have a problem with me manipulating, or I could do some specific to the ID, hmm, need to think about it.

I am using Opera and it seems like there's only a few signs that do not work properly (as demonstrated in the picture below).
Red bad, Green good.

Your opera doesn't render the same way as mine I have no problem with the integrals but the rest seem the same, note though that the coproduct isn't working correctly, there's a "from" value blocked out by the sign.

If I had to guess I'd say it's an CSS issue, me manipulating vertical positions without heights that may create overlaps.

 

[UndeadDragon]

Very nice. I can't fault the code from my browse through it :thup:

 

[GetTriggerUnit-]

Unless people wants it in tags, then tell me which tag I should use, that most people dont have a problem with me manipulating, or I could do some specific to the ID, hmm, need to think about it.

What about using class? Like <div class="xytex">
document.getElementsByClassName('xytext');
That would work for sure with IE8.

 

[GooS]

Thx undead dragon

What about using class? Like <div class="xytex">
document.getElementsByClassName('xytext');
That would work for sure with IE8.

Sure that would be an option, currently (locally) using <div lang="xytex" id="whatever">texcode</div>, produces no validation errors, and well, looks kinda neat

(Though the site as is produces tons of errors in validation though to me not caring about the html atm, maybe I should)

Updated/Uploaded new fixes; though they don't change any/something? appearance wise.

UPDATED: Now looks -Good- in Chrome, IE and FireFox, Opera (is a misfit I don't want to play with, wtf is moving elements around when marking them? o.=) but better than before in opera aswell.

Updated: Safari Fixes added, works real well in latest safari, cept for that it can't find a serif character for coproduct and substitutes a sans-serif, minor flaw

 

[GetTriggerUnit-]

Ok I checked again and here's the rendering, it seems pretty neat.

 

[GooS]

Sweet, thx, the current bug of vertical distortion after operations is something I'm currently orking on and will be fixed as of next update by separation of operations that shouldn't be the same.

 

[Magentix]

Once you're finished, you should also try to simplify your CSS.
It will make it more maintainable and looks more professional.

.operation.property.hilimit{
	font-size: 11pt;
	position: absolute;
	top: -6px;
	left: 16px;
	height: auto;
}
.operation.property.lolimit{
	font-size: 11pt;
	position: absolute;
	top: 30px;
	left: 10px;
	height: auto;
}

Could be any of these:

.limit{
	font-size: 11pt;
	position: absolute;
	height: auto;
}
.hi{
	top: -6px;
	left: 16px;
}
.lo{
	top: 30px;
	left: 10px;
}

/* generates <div class="limit lo"> and  <div class="limit hi"> */
/* generally 'better' as this type of class structuring allows for very OOCSS */
/* if you think it's unsafe to bind .hi and .lo in general, you could bind to .limit.lo and .limit.hi */

.hilimit, .lolimit{
	font-size: 11pt;
	position: absolute;
	height: auto;
}
.hilimit{
	top: -6px;
	left: 16px;
}
.lolimit{
	top: 30px;
	left: 10px;
}
/* generates <div class="lolimit"> and <div class="hilimit"> */

 

[GooS]

Once you're finished, you should also try to simplify your CSS.
It will make it more maintainable and looks more professional.

Idd I will, actually it already has been somewhat more simplified in v 0.43 (NY Uploaded), with the "Separation of operation statement into integration, differentiation, operation (for summation/product/coproduct) and limitation, to set up more specific CSS rules, walks hand in hand with below." I'm currently working on.

Thanks for noticing and supplying the answer aswell

However I do want them to, ehm, require operation as some selectors may be general enough to collide with other website ones. <- Might rework that one