Closed Bug 445029 (validate-math-pages) Opened 16 years ago Closed 12 years ago

Make several MathML webpages validate (with no errors)

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bugzilla, Unassigned)

References

(
URL
)

Details

Attachments

(8 files, 16 obsolete files)

Fix html, body and banner - V2 [checked in]
33.20 KB, patch
karlt
: review+
Details | Diff | Splinter Review
Fix more XHTML errors [checked in]
13.16 KB, patch
karlt
: review+
Details | Diff | Splinter Review
Use Unix-style carriage returns instead of DOS ones [checked in]
110.55 KB, patch
karlt
: review+
Details | Diff | Splinter Review
Add encoding, use mathvariant and fix more XML errors [checked in]
21.52 KB, patch
karlt
: review+
Details | Diff | Splinter Review
fix transparent background + use "display" instead of "mode" [checked in]
19.68 KB, patch
karlt
: review+
Details | Diff | Splinter Review
Patch start pages (V2) [checked in]
20.95 KB, patch
karlt
: review+
Details | Diff | Splinter Review
Update links to start pages (V2) [checked in]
1.34 KB, patch
karlt
: review+
Details | Diff | Splinter Review
Patch demo/ [checked in]
18.99 KB, patch
karlt
: review+
Details | Diff | Splinter Review
No longer blocks: validate
Blocks: validate
HTML files to take care of within the MathML directory:
http://www.mozilla.org/projects/mathml/screenshots/
http://www.mozilla.org/projects/mathml/demo/tester.html
http://www.mozilla.org/projects/mathml/enable.html

There may be others that I have not uncovered so far. They will be added and dealt with as I stumble on these.

-------------

Whenever possible, I will 
- add intra-directory, intra-project navigation linkages (crumbs navigation); 
- add <link>s for Site Navigation toolbar;
- make webpage more conformant to mozilla.org style and markup guidelines as defined at
http://www.mozilla.org/contribute/writing/guidelines
and at
http://www.mozilla.org/contribute/writing/markup
with better semantic and use of custom classes already available in our m.o. style and markup guidelines, etc.

HTML Tidy 
"HTML Tidy for Windows (vers 18 June 2008), see http://tidy.sourceforge.net/"
will be used for HTML webpages but not for XHTML 1.1 + MathML 2.0 webpages because HTML Tidy can not deal, can not tackle with such sort of webpages for now.
Assignee: nobody → bugzilla
-> me

Expected (target) date, goal for fixing this bug: before January 1st 2009.
Status: NEW → ASSIGNED
To add:

Authoring MathML for Mozilla
http://www.mozilla.org/projects/mathml/authoring.html (88 errors; no doctype decl.; quite embarassing because the webpage clearly says to validate HTML/XHTML)

http://www.mozilla.org/projects/mathml/fonts/
(uses HTML 4.01 transitional)
Summary: Make several MathML xhtml demo webpages validate (with no errors) → Make several MathML webpages validate (with no errors)
Checking in mozilla-org/html/projects/mathml/screenshots/index.html;
/www/mozilla-org/html/projects/mathml/screenshots/index.html,v  <--  index.html
new revision: 1.5; previous revision: 1.4
done

Checking in mozilla-org/html/projects/mathml/enable.html;
/www/mozilla-org/html/projects/mathml/enable.html,v  <--  enable.html
new revision: 1.7; previous revision: 1.6
done

Please remember that validation is not just HTML validation but CSS validation as well.

Checking in mozilla-org/html/projects/mathml/fonts/index.html;
/www/mozilla-org/html/projects/mathml/fonts/index.html,v  <--  index.html
new revision: 1.35; previous revision: 1.34
done

Checking in mozilla-org/html/projects/mathml/demo/tester.html;
/www/mozilla-org/html/projects/mathml/demo/tester.html,v  <--  tester.html
new revision: 1.3; previous revision: 1.2
done

Checking in mozilla-org/html/projects/mathml/authoring.html;
/www/mozilla-org/html/projects/mathml/authoring.html,v  <--  authoring.html
new revision: 1.20; previous revision: 1.19
done

Regarding
http://www.mozilla.org/projects/mathml/demo/tester.html
there ought to be a way to make the whole webpage use a doctype declaring a strict DTD, pass validation with <object> instead of <iframe>...
Product: mozilla.org → Websites
> Expected (target) date, goal for fixing this bug: before January 1st 2009.

I will not be able to meet such scheduled target. If someone else wants to take this bug, go ahead.

Marking as NEW, Assigned to default owner/assignee
Assignee: bugzilla → nobody
Status: ASSIGNED → NEW
I will volunteer into improve the MATHML demo pages and get them to validate.

I need some instructions on how to do so (where to get original pages, format for changes, where and who to submit changes to, etc.)
You can find the source for the web pages in bonsai.  For instance:

http://bonsai-www.mozilla.org/cvslog.cgi?file=mozilla-org/html/projects/mathml/start.xhtml&rev=&root=/www/

For format, I would suggest attaching a patch to this bug that includes your changes:

https://developer.mozilla.org/En/Creating_a_patch

You can then ask someone to review and check in your patches.
(In reply to comment #14)
> You can find the source for the web pages in bonsai.  For instance:
> 
> http://bonsai-www.mozilla.org/cvslog.cgi?file=mozilla-org/html/projects/mathml/start.xhtml&rev=&root=/www/
> 

Following the above link leads and clicking on "start.xhtml" leads to
 
https://doctor.mozilla.org/?file=mozilla-org/html/projects/mathml/start.xhtml

and from here if you click "View Edited"
the page generated is not able to display MATHML.  

I looked but could not find the "MathML Torture Test" page under projects/mathml

I pulled the "MathML torture Test" page out, made the changes, and submitted a patch to bug 448509 .  If the patch I submitted is OK, then I will make patches in a similar manner and fix up some of the MathML demo pages.  Using the doctor.mozilla.org to make changes is very impractical since the "View Edited" ability can not display MathML.  Pulling out the pages and making a diff file based on changes is more practical.
Here is a possible replacement page:

http://eyeasme.com/Joe/MathML/Demo/texvsmml.xhtml

It validates as XHTML, CSS and passes the WAI automatic tests.
https://eyeasme.com/Joe/MathML/MathML_browser_test.html

Here is a page to either replace the MathML Torture Test page or to act as a supplement.  I covered the same material in 15 new tests rather than the old 28 tests.

The equations are shown in 3 forms: 
(all hyperlinked to the code that generated them)

1) an image the TeX presentation
2) an image of the MathML representation using STIX Beta fonts on Firefox 3.5
3) the present browser's representation of the equation using MathML 

This way a person can see how TeX (produces a very good representation of mathematical equations) compares with MathML on Firefox 3.5 using STIX beta fonts, and how these both compare with their present browser's MathML representation.

By hyper-linking to the Tex and MathML code a person recreate the images and modify them as desired.

The page validates as 'XHTML 1.1 plus MathML 2.0', validates as 'CSS level 2.1' and the page passes the WAI automatic tests

Feel free to make any Comments / suggestions / corrections.
> I pulled the "MathML torture Test" page out, made the changes, and submitted a
> patch to bug 448509 .  If the patch I submitted is OK, then I will make patches
> in a similar manner and fix up some of the MathML demo pages.

Joe, do you still plan to work on this bug?
In response to comment #19.

I wrote a "better" MathML testing/torture page at

https://eyeasme.com/Joe/MathML/MathML_browser_test

I would be glad to write a few tutorial pages on using MathML, and
fixing up the page that exist already.  The problem is that 
CSS is still used for the webpages instead of Mercurial.  
Adding images and modifying pages is a pain in the rump using CSS.

I suggest that a wiki be made for the mozilla website.

I simply have no desire to have to download the entire mozilla 
website and bend over backward to add images and make changes to a few 
webpages.  Make updating the website easier (make it a simple wiki) and I will
update the MathML pages.  

Also, I have stopped submitting bug reports since NOTHING has been done on the ones I have submitted.  I realize that people work on what interests them, but even so, at least some effort should go into fixing reported bugs.

See subsection "Bugs/Enhancements" at
https://eyeasme.com/Joe/MathML/MathML_browser_test

If it will help I can pull the pages from the mozilla site and fix them on 
my site and someone else can go through the pain of importing the changes to the Mozilla site.
Re comment #20, there are existing wikis in the community that could be used for this, specifically wiki.mozilla.org or developer.mozilla.org.  I'm not sure how these sites are for MathML, but it's fine to use these if you can.  We can always set up redirects from mozilla.org to point to these pages if they are moved.
Attached image Screenshot (obsolete) — 

    
    

    
  
(In reply to comment #20)

> Also, I have stopped submitting bug reports since NOTHING has been done on the
> ones I have submitted.  I realize that people work on what interests them, but
> even so, at least some effort should go into fixing reported bugs.
> 
> See subsection "Bugs/Enhancements" at
> https://eyeasme.com/Joe/MathML/MathML_browser_test
> 
> If it will help I can pull the pages from the mozilla site and fix them on 
> my site and someone else can go through the pain of importing the changes to
> the Mozilla site.

	Fixing a bug is (unfortunately) not as easy as non-programmers could think and moreover few developers are currently working on MathML support in Mozilla. However the fact that the bugs you reported are not fixed yet does not mean that we are not working on it. See attachment 407262 [details] for a screenshot of your test with a trunk build (+ various patches applied).

> Firefox: Bug 416140 - Underbraces and Overbraces don't stretch properly
> Right and left angle brackets do not stretch 
> Firefox: Bug 491370 - MathML right and left angle brackets do not stretch

The patches from bugs 414277 and 407101 should fix this.

> Operators that have limits (Sums, Products, Integrals) generally look better when their font size is set to larger.

This should actually not be needed, it's bug 518330. Note that in the screenshot, I removed "font-size:larger".

> Integrals by default stretch to cover an equation, but do so with a vertical body rather than one with a slight incline.

Currently, integrals are built by parts with STIX fonts. Once 518330 is fixed, we are probably going to remove the default stretchy=true for integrals and simply draw them larger (as TeX does and MathML 3 is going to suggest).

    
    

    
  
This bug is currently to make MathML pages validate. Actually, it would certainly be great if the MathML project pages are updated. I suggest opening a new bug, so that we can discuss what can be done.

    
    

    
  
In response to Comment #23.  

Thank you for showing me the errors of my thinking.  
I will now continue to file bug reports.  

Perhaps it might be possible that as people make changes on the trunk, that they put comments into the bugs that might be affected by these changes.

    
    

    
  
Just a reminder 

https://eyeasme.com/Joe/MathML/Demo/texvsmml.xhtml
(validates as 'XHTML 1.1 plus MathML 2.0', validates as 'CSS level 2.1'
and the page passes the WAI automatic tests)

is a "better" MathML torture page than the original one at

http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml

but both can be replaced with

https://eyeasme.com/Joe/MathML/MathML_browser_test
(validates as 'XHTML 1.1 plus MathML 2.0', validates as 'CSS level 2.1'
and the page passes the WAI automatic tests)

    
    

    
  
Re comment #26, I can remove the demo on mozilla.org and redirect that link to the better page.  I'm not sure if the goal though is to improve the pages specifically on www.mozilla.org or just to fix these pages wherever they may live.

    
    

    
  
(In reply to comment #27)
> Re comment #26, I can remove the demo on mozilla.org and redirect that link to
> the better page.  I'm not sure if the goal though is to improve the pages
> specifically on www.mozilla.org or just to fix these pages wherever they may
> live.

I think this bug comes from the bug 151557 that aims at making all the page of mozilla.org validate. Currently, the torture test is valid, so the bug is actually only for the pages listed in comment 0. I see the integration of Joe's pages as part of a broader project to update the MathML project pages and not simply make the old ones validate.

    
    

    
  
Re Comment #26.  
It would be better if the pages at mozilla.org were all hosted at mozilla.org, except for those specifically marked as external.

Just replace the old textvsmml.xhtml with the new one
https://eyeasme.com/Joe/MathML/Demo/texvsmml.xhtml
 
and copy Picture_1.png through Picture_ 28.png from 
https://eyeasme.com/Joe/MathML/screenshots/
to
http://www.mozilla.org/projects/mathml/screenshots/

If this a hassle, go ahead and link to the page and I will modify 
any internal links to properly work with the mozilla.org site.

Note: there are two external js files ("entity.js" and "viewmath.js")
that are unneeded by modern Firefox and are included only because they were included in the original torture test.  They don't really do anything anymore, but for continuity were included.  This was to "fix" the page without
"improving" it.   

Feel free to add the page
https://eyeasme.com/Joe/MathML/MathML_browser_test
as an external link, or just remove the torture page entirely and just use this page as a testing/torture page.

    
    

    
  
(In reply to comment #29)

	The old MathML torture test has been used by bug reporters / developers for a long time and is still being used. I would prefer to preserve the MathML code, to be sure that changes of the rendering are really due to changes made in the trunk. I agree to replace with the new version under the condition that, as you say, it is to "fix the page without improving it". However when I look to the code, I see that you made many changes in the MathML code. For instance, you added style="font-size: larger;" to large operators but as I said in comment 23 this is should not be needed. I think it's worth asking Karl's opinion before replacing the page.

	For the "MathML_browser_test", it would certainly be a good idea either to include it in mozilla.org as an additional test page or at least to add a link in the MathML project page. (BTW, thanks for this new MathML test page, it is really useful!)

    
    

    
  
In reply to Comment #30

Yes many changes were made to the page.  

Changing the Doctype is necessary since it was wrong.
(Note: the MathML pages at mozilla.org still use the wrong Doctype) 

Equation 14 uses the letter "i" to represent an imaginary "i" instead of the correct unicode character.  People with accessibility problems, should have the proper character given so that when the page is read to them they can better understand what the equation is.  

Equation 17 uses two single integration characters instead of the proper double integration character, since the double integration character does not "stretch" to a "proper" height when used in this equation.

Here are a few aesthetic changes:

When using an mtable, the table cell (mtd) default vertical padding produces excessive spacing, setting the top and bottom padding to zero "0" fixes this. 
  
Operators that have limits (Sums, Products, Integrals) generally look better when their font size is set to larger.

    
    

    
  
In replay to comment #23.

Mention was made of trunk build plus some patches available to fix several bugs I have reported.  I tried the daily trunk build and the bugs I reported still show.  Any time frame on when the patches will be put into the trunk?

    
    

    
  
(In reply to comment #31)
> Yes many changes were made to the page.  
> 
> Changing the Doctype is necessary since it was wrong.
> (Note: the MathML pages at mozilla.org still use the wrong Doctype) 

	Your patch for bug 448509 has already been accepted. However it seems that Karl prefers to wait that the public version of the W3C validator no longer displays a warning. I personally think it's not so important, since it's just a warning and does not affect the rendering. I'm more worried about the changes made in the <math/>'s.

> 
> Equation 14 uses the letter "i" to represent an imaginary "i" instead of the
> correct unicode character.  People with accessibility problems, should have the
> proper character given so that when the page is read to them they can better
> understand what the equation is.  
> 

	In my opinion, this is good. So are the changes you made for the "dx" in integrals.

> Equation 17 uses two single integration characters instead of the proper double
> integration character, since the double integration character does not
> "stretch" to a "proper" height when used in this equation.

Normally this change should not be needed when 518330 is fixed.

> Operators that have limits (Sums, Products, Integrals) generally look better
> when their font size is set to larger.

Again, this change should not be needed when 518330 is fixed.

In general, my opinion is that the torture test should not be modified to make it good with Firefox but that Firefox's rendering should be improved to make the tests look good. I remember some messages on the Math mailing list, where Neil Soiffer told you not to use workarounds for Firefox when designing your tests. I agree with him, a test should not be made according to the rendering of a browser but should rather be based on what the specs say.

Note: I've no authority on whether to accept your pages or not, I just give my opinion.

    
    

    
  
(In reply to comment #32)
> In replay to comment #23.
> 
> Mention was made of trunk build plus some patches available to fix several bugs
> I have reported.  I tried the daily trunk build and the bugs I reported still
> show.  Any time frame on when the patches will be put into the trunk?

The patches are currently available on the bugs I mentioned (even if the one for bug 414277 is not up-to-date). I don't have any idea when they will be ready to land in trunk but do not expect that it happens soon.

    
    

    
  
Karl, what is your point of view about replacing the MathML torture test by Joe's version and integrating his MathML_browser_test page on mozilla.org?

    
    

    
  
(In reply to comment #35)
> Karl, what is your point of view about replacing the MathML torture test by
> Joe's version.

Frédéric, you make valid points.

Fixes for bugs in the test page are good.
But a test page should not include tweaks for a particular browser.
I'd also like to keep the existing tests.

> and integrating his MathML_browser_test page on mozilla.org?

More examples/tests sounds good.

Adding a new page is probably the best way to include Joe's tests.

BTW, it looks like mozilla.org has switched from CVS to Subversion.
https://wiki.mozilla.org/Mozilla.org/How_to_Work_with_Site

    
    

    
  
I'm curious about U+2146 DOUBLE-STRUCK ITALIC SMALL D "sometimes used for the differential".  Which "sometimes" is that?

I don't recall seeing this often.  Is is used in specific fields, specific localities or what?

Also, STIX renders this upright, which must be a bug in the font, I assume?

The TeX rendering doesn't use this form of d, so I wouldn't want to change the MathML character without good reason.

    
    

    
  
(In reply to comment #37)
> I'm curious about U+2146 DOUBLE-STRUCK ITALIC SMALL D "sometimes used for the
> differential".  Which "sometimes" is that?
> 
> I don't recall seeing this often.  Is is used in specific fields, specific
> localities or what?

I've always thought it was called something like "&differentiald;" and was introduced for accessibility reason in MathML. So the name you give is strange because it indicates the way the "d" must be drawn.

Here is what MathML 2 says:

"MathML also introduces entities like &dd; (U+2146) representing a "differential d", which renders with slightly different spacing in print and can be rendered as "d" or "with respect to" in speech. Unless content tags, or some other mechanism, are used to eliminate the ambiguity, authors should always use these characters here referred to as entities, in order to make their documents more accessible."

I think it is the same for "&exponentialE;", "&imaginaryI;". Note that Amaya draws this character as normal "d", "e" or "i" but Mozilla draws them as "double-struck" characters.

    
    

    
  
From "The Unicode Standard 5.2 Code Charts"
http://unicode.org/charts/PDF/U2100.pdf
"These stylized mathematical symbols are used in some
documents to distinguish special mathematical usages from
ordinary variables."

    
    

    
  
(In reply to comment #39)
> From "The Unicode Standard 5.2 Code Charts"
> http://unicode.org/charts/PDF/U2100.pdf
> "These stylized mathematical symbols are used in some
> documents to distinguish special mathematical usages from
> ordinary variables."

Apparently, when introduced in Unicode Standard, some style properties were added to the original proposition of MathML WG. I think it is better to use these characters when using Math on the Web. However, if one of the purpose of the torture test is to compare the rendering with TeX, then I guess we should use the "normal" characters.

    
    

    
  
(In reply to comment #40)

I need a vocabulary to discuss this, I will be quick and loose with meanings

A character is a symbol that represent a basic building block of a language 
(numbers or letters or even symbols like a smiley face)

A glyph is a specific representation of a character.  

A font is a specific set of glyph representations of characters.  
(each character has a glyph representation)
Font designers spend a HUGE amount of time carefully creating the glyphs that they use.

Generally you want a font that has different glyphs for all the characters.

For example: programmers generally do not like fonts that have the same glyph for the the capital "O" character and the zero character "0".

Unicode is a mapping of a number to most every character known to man, this mapping is called character encoding.  

The great thing about using Unicode character encoding is that even if two characters look the same (share the same glyph), by looking at the character encoding a person can know what character is being represented.

Unicode does NOT have anything to do with the glyphs that represents the characters.

> 
> Apparently, when introduced in Unicode Standard, some style properties were
> added to the original proposition of MathML WG. I think it is better to use
> these characters when using Math on the Web. However, if one of the purpose of
> the torture test is to compare the rendering with TeX, then I guess we should
> use the "normal" characters.

Tex LOOKS great but fails to properly use character coding.  Tex has no imaginary "i" character or exponential "e" character of even an omicron character instead it uses the characters "i", "e", and "o" (the same glyphs are used).    

For accessibility reasons it is NOT OK for the character "i" to be used in place of the character imaginary "i".  

If the glyph that the font uses to represent the character imaginary "i" is not OK with you, then change the glyph used for that character.  Myself I never do this, I trust that the font designers know what they are doing.  I suppose you could use CSS or javascript or create a micro font of just the few character to glyph mapping changes you want and switch to this font when desired.  

By changing the glyph used by the character you can produce any LOOK you want, while those who use screen readers will have the correct character given to them
(i.e. remain accessible).

    
    

    
  
(In reply to comment #41)

> For accessibility reasons it is NOT OK for the character "i" to be used in
> place of the character imaginary "i".  
> 

If the intention of this bug is just to modify the webpages so that they validate (and not "update" them in anyway) then it is OK to use the character "i" to represent imaginary "i".  

Now I ask... is the intention of this bug just to make the pages validate (no other changes made), or should the pages be made to validate and obvious mistakes fixed (wrong doctype used, wrong characters used, characters skipped, bad spacing, use of character names, etc)?  

The torture test is useless for testing Opera's MathML since it uses character names rather than Unicode numerical encodings for non-standard characters.  Amaya would have the same problem as Opera, but it just happens to understand all the character names used in the torture test.  (Ex & int; is used rather than &#x222B;)

Is the intention on the torture test page to imitate as closely as possible the TeX output, or use the Tex output as a representative example of what the MathML should look like?  

P.S. the W3C validator will be fixed to use the correct doctype when next it is updated.

    
    

    
  
(In reply to comment #42)
> Now I ask... is the intention of this bug just to make the pages validate (no
> other changes made),

Yes, that is what is described in comment 0.

> or should the pages be made to validate and obvious
> mistakes fixed

Obvious mistakes should be fixed yes, but those are separate issues to this bug report.

> The torture test is useless for testing Opera's MathML since it uses character
> names rather than Unicode numerical encodings for non-standard characters. 
> Amaya would have the same problem as Opera, but it just happens to understand
> all the character names used in the torture test.  (Ex & int; is used rather
> than &#x222B;)

What does the MathML spec require of renderers re entities?
(I wonder what the point of having entities is if renderers don't need to understand them.)  Or is the wrong dtd being referenced in the pages?
What are "non-standard characters"?
What I really want to know is: what is the core reason why the entities are not recognized by other browsers?

> Is the intention on the torture test page to imitate as closely as possible the
> TeX output, or use the Tex output as a representative example of what the
> MathML should look like?  

It is a comparison of rendering from TeX and from MathML.
As TeX was considered the gold standard of mathematical layout, I assume the author thought that the MathML should look similar to TeX.

> P.S. the W3C validator will be fixed to use the correct doctype when next it is
> updated.

Excellent.

    
    

    
  
(In reply to comment #43)
> (In reply to comment #42)
> > Now I ask... is the intention of this bug just to make the pages validate (no
> > other changes made),
> 
> Yes, that is what is described in comment 0.
> 

OK, I can do this.


> Obvious mistakes should be fixed yes, but those are separate issues to this bug
> report.
> 

> What does the MathML spec require of renderers re entities?
> (I wonder what the point of having entities is if renderers don't need to
> understand them.)  Or is the wrong dtd being referenced in the pages?
> What are "non-standard characters"?
> What I really want to know is: what is the core reason why the entities are not
> recognized by other browsers?
> 

I asked pretty much the same thing to the www-math@w3.org mailing list
See the following link (follow the "MathML browser test page" thread):

http://lists.w3.org/Archives/Public/www-math/2009Jul/

Basically ONLY (lt gt amp quot apos) are safe entity names.


Also see (read the last comment):
http://my.opera.com/mathml/blog/show.dml/1460837#comments

MathML in Opera can only use the five safe entity names.

    
    

    
  
All the pages in comment 0, now validate as:
XHTML 1.1 plus MathML 2.0 (note: the correct DOCTYPE is used)
CSS level 3
passing WAI Priority 1, 2, 3

None of the text in the pages was changed, even though changes
should be made. (The pages are VERY old and contain some wrong
information.)  No spelling or grammar checks were made.

To make validating the pages easier, the references were re-based
using the "base" tag. (Remove this tag when placing into
Mozilla web site.)

The pages are located here:
https://www.eyeasme.com/Joe/MathML/BUG_445029/start.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/start-hebrew.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/start-thai.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/basics.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/mfrac.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/mo.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/mtable.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/mspace.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/mmultiscripts.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/roots.xhtml
https://www.eyeasme.com/Joe/MathML/BUG_445029/extras.xhtml

Some comments:
start.xhtml
   Fixed a violation to WAI rules when Bugzilla hyperlinks had the
   same link text but different targets.

basics.xhtml:
   in the line
   <body bgcolor="#ffffff" oncontextmenu="handlecontext(event)">
   The 'oncontextmenu' is non-standard and does not work.  It was
   removed as a call.  The source code remains if someone wants to
   'fix' it.  It is a BAD idea to fix it, since it overrides the
   default right-click context menu.

   The web page is very old... 'bongo.gif' no longer exists.

   The link for the a^2 + b^2 = c^2 equation no longer exists.

   The opacity features of the 'footer' were fixed.

extras.xhtml
   The write-up on this page is wrong; using the 'title' attribute
   as a tooltip in MathML is non-standard.  The valid way is to use
   the 'tooltip' attribute of the 'maction' tag. Firefox does NOT
   correctly handle the actiontype 'tooltip' of 'maction'. (This is
   an unmarked bug.)  Firefox WILL display a tooltip if the 'title'
   attribute of a tag is set.  Until this unfiled bug in Firefox is
   fixed, the best solution is to use the 'maction' tag and set the
   'title' attribute of the tag via javascript.

Further changes that should be made:
The entity names should be replaced with Unicode numbers (so that
Opera and other MathML browsers that do not understand entity names
can view the pages).

The text needs to be reviewed for factual, spelling, and
grammatical errors.

    
    

    
  
(In reply to comment #45)
> All the pages in comment 0, now validate as:
> XHTML 1.1 plus MathML 2.0 (note: the correct DOCTYPE is used)
> CSS level 3
> passing WAI Priority 1, 2, 3

Thank you for this work Joe! I'll study that when I have time for and give you feedback.

    
    

    
  

      
      
      
      

        Attached file
          
        A script to easily create a patch (obsolete)
        — 
      

    


  
In general, changes to Mozilla's code are made via a patch attached to a bug. I don't know whether this also applies to the case of "mozilla website" module. I wrote a script to create a patch from Joe's changes, but I'm not sure it will currently help to review.

    
    

    
  
Patches for the website are certainly welcome, although it is up to the person who is going to check things in.  

Does anyone on this bug have commit access to the site?  If not, I'm happy to help get access if someone wants to own those pages.

    
    

    
  
(In reply to comment #48)
> Patches for the website are certainly welcome, although it is up to the person
> who is going to check things in.  

Does this mean that contrary to program source code, there is no review process for Website pages? Currently, the patch generated from Joe's changes is of about 25000 lines, with large blocks of code removed/added so it seems difficult to see the changes if someone is going to review it...

    
    

    
  
I think website changes are a little bit more informal that code changes -- regardless though, I think it's up to the person who owns the pages to determine how the changes should be submitted.

    
    

    
  
(In reply to comment #45)
OK, finally I had time to look at this.

> XHTML 1.1 plus MathML 2.0 (note: the correct DOCTYPE is used)
Yes, as I said in comment 33, I think it's better to use this doctype.

> None of the text in the pages was changed, even though changes
> should be made. (The pages are VERY old and contain some wrong
> information.)  No spelling or grammar checks were made.
> Further changes that should be made:
> The entity names should be replaced with Unicode numbers (so that
> Opera and other MathML browsers that do not understand entity names
> can view the pages).
> The text needs to be reviewed for factual, spelling, and
> grammatical errors.

I would also use the new graphic design of www.mozilla.org. However, I suppose all this changes can wait a later update, for the moment all we want for this bug is to make these pages valid.

> To make validating the pages easier, the references were re-based
> using the "base" tag. (Remove this tag when placing into
> Mozilla web site.)

OK, my "patch maker" does not take this into account but if someone need to use it, this could easily be modified to remove the <base/> automatically.

> start.xhtml
>    Fixed a violation to WAI rules when Bugzilla hyperlinks had the
>    same link text but different targets.

I can't see where this change is.

> basics.xhtml:
>    in the line
>    <body bgcolor="#ffffff" oncontextmenu="handlecontext(event)">
>    The 'oncontextmenu' is non-standard and does not work.  It was
>    removed as a call.  The source code remains if someone wants to
>   'fix' it.  It is a BAD idea to fix it, since it overrides the
>    default right-click context menu.
>

Do you know, which feature was supposed to be provided by this menu?

>   The web page is very old... 'bongo.gif' no longer exists.
>

Yes, we could probably find this image in the archives of Seamonkey releases. Otherwise, I suppose we should replace this gif by a new image.

>   The link for the a^2 + b^2 = c^2 equation no longer exists.

Let's replace it by a link not broken, for instance http://en.wikipedia.org/wiki/Cape_Canaveral

>
>   The opacity features of the 'footer' were fixed.

Apparently it was a -moz extension at the time of writing. I believe your change is correct and reflect the author's intention.

> extras.xhtml
>   The write-up on this page is wrong; using the 'title' attribute
>   as a tooltip in MathML is non-standard.  The valid way is to use
>   the 'tooltip' attribute of the 'maction' tag. Firefox does NOT
>   correctly handle the actiontype 'tooltip' of 'maction'. (This is
>   an unmarked bug.)  Firefox WILL display a tooltip if the 'title'
>   attribute of a tag is set.  Until this unfiled bug in Firefox is
>   fixed, the best solution is to use the 'maction' tag and set the
>   'title' attribute of the tag via javascript.

This was discussed on the MathML mailing list and I think you're right (I have not checked your code though). However the goal of this page was to show extras in Mozilla. Maybe we can just use CSS title everywhere for the moment, until a later update to change the content of the page?

------------------------
More comments/questions:

extras.xhtml

	I don't see why we should add lspace="thinmathspace" to the &ApplyFunction;. In general, I would prefer not to change the rendering, unless we have a good reason to do so.	

roots.xhtml, mmultiscripts.xhtml, mspace.xhtml, mtable.xhtml, mo.xhtml, mfrac.xhtml

	In "There is a tracker bug where you can report rendering errors on the demos." it seems that the reformating of the code adds an unexpected space before the dot at the end of this sentence.

mtable.xhtml

	Why do you change the rendering of test 3, 7, 9, 15, 16?
	(BTW, it seems this page has some problems, probably because of the bug of the width in mtable)
	
basics.xhtml

	You replace "mathcolor" by CSS to add color to formulae. However, I think the purpose was to test the MathML style attributes here so It would be better if we can use them (I've not checked the spec).
	
	In the integral of the lizard+bongo example, the "a" is moved. I believe what you've done (using the <semantic/> attribute to insert XHTML) is correct and fixed the position of this bound.
	
	BTW, do you know what was the "continued fraction" supposed to do?
	
start-thai.xhtml, start-hebrew.xhtml

	It seems that the font-style of the page has changed. Do you know what happened?

    
    

    
  
(In reply to comment #50)
> I think website changes are a little bit more informal that code changes --
> regardless though, I think it's up to the person who owns the pages to
> determine how the changes should be submitted.

Who owns the pages?

    
    

    
  
If it's not clear who owns the pages, then it's entirely possible that no one owns them.  Much of the content on www.mozilla.org has been abandoned over the years and new owners have had to be identified.  I suggest discussing ownership among other MathML contributors and picking a new owner if an existing one isn't found.  I can then help the new owner get access to the site so they can make these changes.

    
    

    
  
The MathML project pages are closely related to the MathML code module, which would suggest that I am the owner.  I have commit access to the CVS repository.  I don't know whether I have access to the SVN repository.

Re the changes proposed here:  If they can be put in a reviewable form and Frédéric is happy to review the changes then we'll find a way to commit the changes.

It's a bit much to ask someone to review 25000 lines of changes.
Is there are script that was used to make the changes?
Can the changes be broken up in a way to make reviewing easier?

    
    

    
  
Karl, if you don't have access to the site's SVN repository, let me know and I'll open a bug.  I imagine you do since we copied over all users who had checked in to the site's CVS repository in the last year or so.  

For reference, the repository is at

http://svn.mozilla.org/projects/mozilla.org/trunk/

    
    

    
  

      
      
      
      

        Attached file
          
        A script to easily create a patch (obsolete)
        — 
      

    


  

        Attachment #414285 -
        Attachment is obsolete: true

    
    

    
  
> It's a bit much to ask someone to review 25000 lines of changes.
> Is there are script that was used to make the changes?
> Can the changes be broken up in a way to make reviewing easier?

The script (attachment 415088 [details]) has nothing special: it simply downloads the files from mozilla.org, the files from Joe's website and makes a diff -U8 on them (and I've just added an additional command to filter out the <base/> element discussed above).

I think most changes are code formatting changes that could be removed to reduce the patch size and see more clearly the exact pieces of code changed. In that case, I would be happy to review the patch.

Joe, can you modify your pages so that only *necessary* changes are made? For instance, you need not change indentation/linebreaking (BTW, for the javascript code, the mozilla's style is to use open braces at the end of the line, so you need not move them).

    
    

    
  
(In reply to comment #51)
> (In reply to comment #45)
> OK, finally I had time to look at this.
> 
> > XHTML 1.1 plus MathML 2.0 (note: the correct DOCTYPE is used)
> Yes, as I said in comment 33, I think it's better to use this doctype.
> 

   OK.  Please remember to file the bug report to switch the DOCTYPE back to
the correct DOCTYPE once the next version of the validator is released.

> 
> > start.xhtml
> >    Fixed a violation to WAI rules when Bugzilla hyperlinks had the
> >    same link text but different targets.
> 
> I can't see where this change is.
> 

  The goal was to be close to pixel perfect in reproduction of the original
pages while being XHTML and CSS valid and WAI passing.
  To pass the a WAI test a Zero Width Space &#x200B; was added to a 
hyperlink link text.  You should NOT see the difference. 


> > basics.xhtml:
> >    in the line
> >    <body bgcolor="#ffffff" oncontextmenu="handlecontext(event)">
> >    The 'oncontextmenu' is non-standard and does not work.  It was
> >    removed as a call.  The source code remains if someone wants to
> >   'fix' it.  It is a BAD idea to fix it, since it overrides the
> >    default right-click context menu.
> >
> 
> Do you know, which feature was supposed to be provided by this menu?
>
    Yes, it was suppose to modify the right hand click context menu.  
From the page:
      You can right-click on any math
      fragment of interest throughout this document. The context menu won't
      show up. Rather, the math fragment will zoom, and if you right-click a
      second time, you will see the MathML WYSIWYG markup of the fragment,
      and if you right-click again a third time, the fragment will revert to
      its initial state. This tri-state mode is aimed at limiting conflicts
      with other agents that compete for the mouse.

 
> 
> >   The link for the a^2 + b^2 = c^2 equation no longer exists.
> 
> Let's replace it by a link not broken, for instance
> http://en.wikipedia.org/wiki/Cape_Canaveral
> 

   Done.

> > extras.xhtml
> >   The write-up on this page is wrong; using the 'title' attribute
> >   as a tooltip in MathML is non-standard.  The valid way is to use
> >   the 'tooltip' attribute of the 'maction' tag. Firefox does NOT
> >   correctly handle the actiontype 'tooltip' of 'maction'. (This is
> >   an unmarked bug.)  Firefox WILL display a tooltip if the 'title'
> >   attribute of a tag is set.  Until this unfiled bug in Firefox is
> >   fixed, the best solution is to use the 'maction' tag and set the
> >   'title' attribute of the tag via javascript.
> 
> This was discussed on the MathML mailing list and I think you're right (I have
> not checked your code though). However the goal of this page was to show extras
> in Mozilla. Maybe we can just use CSS title everywhere for the moment, until a
> later update to change the content of the page?
> 

   Please look at this again.  It now validates correctly AND works with
Firefox.  MathML Tags do not have titles, no page that uses titles for MathML
tags will validate.  The solution is to file a bug report with Firefox, and
have Firefox correctly implement the "tooltip" attribute of the "maction" tag.

> ------------------------
> More comments/questions:
> 
> extras.xhtml
> 
>     I don't see why we should add lspace="thinmathspace" to the
> &ApplyFunction;. In general, I would prefer not to change the rendering, unless
> we have a good reason to do so.    
> 

  Yes, pixel perfect recreation of original page.

> roots.xhtml, mmultiscripts.xhtml, mspace.xhtml, mtable.xhtml, mo.xhtml,
> mfrac.xhtml
> 
>     In "There is a tracker bug where you can report rendering errors on the
> demos." it seems that the reformating of the code adds an unexpected space
> before the dot at the end of this sentence.
> 

   Fixed.

> mtable.xhtml
> 
>     Why do you change the rendering of test 3, 7, 9, 15, 16?
>     (BTW, it seems this page has some problems, probably because of the bug of
> the width in mtable)
> 

   3, 7, 16  I see no difference  (please attach images to show the differnces)

   9, 15  The original is not producing the internal lines as it should.  The validated version does.  As to why... I am drawing a blank 
(rendering modes differ?)

> basics.xhtml
> 
>     BTW, do you know what was the "continued fraction" supposed to do?
> 

   To show that MathML can be the text of a button.

> start-thai.xhtml, start-hebrew.xhtml
> 
>     It seems that the font-style of the page has changed. Do you know what
> happened?

  No idea...

    
    

    
  
(In reply to comment #57)
> 
> The script (attachment 415088 [details]) has nothing special: it simply downloads the
> files from mozilla.org, the files from Joe's website and makes a diff -U8 on
> them (and I've just added an additional command to filter out the <base/>
> element discussed above).
> 
> I think most changes are code formatting changes that could be removed to
> reduce the patch size and see more clearly the exact pieces of code changed. In
> that case, I would be happy to review the patch.
> 
> Joe, can you modify your pages so that only *necessary* changes are made? For
> instance, you need not change indentation/linebreaking (BTW, for the javascript
> code, the mozilla's style is to use open braces at the end of the line, so you
> need not move them).

Easy to correct indentation... hard to revert changes once made.
I will attach the 2 line java program I wrote to break code up into
single tags per line and remove excess blank lines.  Emacs will auto-indent lines (just mark the entire file and M-\ )

Coding indentation follows two general styles the open bracket on same line
and the open bracket following line indented.  I am pretty sure Emacs
can be made to indent to either style.

    
    

    
  


  
Small program for stripper multi-tagged lines to one per line

First compile with 
javac Stripper.java

Then run as follows (example to fix "file.xhtml")
Java Stripper file.xhtml

will produce file_mod.xhtml

    
    

    
  
> Easy to correct indentation... hard to revert changes once made.
> I will attach the 2 line java program I wrote to break code up into
> single tags per line and remove excess blank lines.  Emacs will auto-indent
> lines (just mark the entire file and M-\ )

There are still minor changes that hide the important things but at least it seems readable now. I've modified my patch to execute your java program and call emacs in batch mode on the old files. It's a complicated way that does not work perfectly and it would have been simpler without unnecessary formatting. I should have tell you that before but it was not clear in which form the changes were going to be accepted. For future bugs please only modify the necessary part so that review becomes easier.

Now, I can see more precisely the changes. I'll study them more carefully when I have time. But can you just use a "demo/" directory to make things simpler (for my script and for the produced patch)?

    
    

    
  
(In reply to comment #61)
> > Easy to correct indentation... hard to revert changes once made.
> > I will attach the 2 line java program I wrote to break code up into
> > single tags per line and remove excess blank lines.  Emacs will auto-indent
> > lines (just mark the entire file and M-\ )
> 
> There are still minor changes that hide the important things but at least it
> seems readable now. I've modified my patch to execute your java program and
> call emacs in batch mode on the old files. It's a complicated way that does not
> work perfectly and it would have been simpler without unnecessary formatting. I
> should have tell you that before but it was not clear in which form the changes
> were going to be accepted. For future bugs please only modify the necessary
> part so that review becomes easier.
> 

... I am finishing a long day of work... So rather than be grumpy I will
attempt some humor...  No offense is given... please take none

---------------Begin 
Where the original people who wrote these pages Demigods of computing? 
because you are acting like every space and word they wrote is sacred,
We are not rewriting the Torah here.

Review....  
You are looking at a markup language, the webpage either looks right or not. 
 
It looks the same as it did before (with a few very minor differences)) 
AND it validates. (added bonus now code is better indented and spaced)  
Do a quick check for dirty words/images and nefarious code (none are there)

Review is done.

The only new code added was in extras.xhtml to programmatically add the "title"
attributes to allow Firefox to display tooltips in MathML.  This is about 6
lines of javascript in a function called "SetTitles".

> Now, I can see more precisely the changes. I'll study them more carefully when
> I have time. But can you just use a "demo/" directory to make things simpler
> (for my script and for the produced patch)?

Bring the pages up in a browser... choose "Save Page As" ... put wherever you like.  
---------------End

    
    

    
  
(In reply to comment #62)
> ... I am finishing a long day of work... So rather than be grumpy I will
> attempt some humor...  No offense is given... please take none

Frédéric is trying to be very accomodating.
There is no need for your remarks.

> Where the original people who wrote these pages Demigods of computing? 
> because you are acting like every space and word they wrote is sacred,
> We are not rewriting the Torah here.

Other people have authored these pages.
There is no need to rearrange their works into one person's favorite format.

One of the purposes of revision control systems is to make it possible to work
out when and why the page was written as it is.  If every person to touch the
page reformats to their preferred format, it makes this very difficult.

BTW, often enough whitespace between tags is significant.

> Review....  
> You are looking at a markup language, the webpage either looks right or not. 
> 
> It looks the same as it did before (with a few very minor differences)) 
> AND it validates. (added bonus now code is better indented and spaced)  
> Do a quick check for dirty words/images and nefarious code (none are there)
> 
> Review is done.

Apologies for missing the humour here.
There is more to an xml document than how it is rendered.
This is not how review is done.

> The only new code added was in extras.xhtml to programmatically add the "title"
> attributes to allow Firefox to display tooltips in MathML.  This is about 6
> lines of javascript in a function called "SetTitles".

It sounds like it is going to be easier for someone to make the important
changes that you have described in this bug report again, rather than try to
find the important changes in the reformatted documents.

That is what I think needs to happen here.

    
    

    
  
(In reply to comment #63)

> Frédéric is trying to be very accomodating.
> There is no need for your remarks.
> 

  Apologies given.  
I'll keep my day job instead of quitting and becoming a comedian.

>
> It sounds like it is going to be easier for someone to make the important
> changes that you have described in this bug report again, rather than try to
> find the important changes in the reformatted documents.
> 
> That is what I think needs to happen here.

It would be far faster for me to do it.  

Here is a completed page:  

https://www.eyeasme.com/Joe/MathML/BUG_445029/demo/basics.xhtml

is this page OK?  If so I'll use it as a template and complete the rest.

    
    

    
  

      
      
      
      

        Attached file
          
        A script to easily create a patch (obsolete)
        — 
      

    


  

        Attachment #415088 -
        Attachment is obsolete: true

    
    

    
  
Joe, my intention is to help you, not to prevent your work being integrated into Mozilla's repository. We previously knew neither the current owner of the MathML pages nor how the changes were going to be accepted, so you should consider as a chance that someone is showing interest in your work now. Also, remember that your first patch in bug 448509 would have probably been lost if I had not given you a hint on the review process. Apparently, you did not read all carefully at this time, so please have a look again:

https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch#Addressing_Review_Comments

I attached the patch that I generated yesterday which should reflect the set of your changes. It would certainly be faster if someone else extracts the important changes from it and just apply them to the old pages. However, I would prefer you do it yourself, first because it's part of Mozilla's philosophy but also because I hope you could get familiar with Mozilla's process and help us to update/maintain the MathML project pages later (I may be wrong, but I believed that it was also your intention?). If you still agree to work on it, then please start again from the www.mozilla.org pages and use attachment 416100 [details] [diff] [review] to remember what changes you made. Keep only important parts: ignore unnecessary whitespace and coding style (opening brace) changes, don't remove the &mathml; entity (if it is not needed to validate) etc Thanks by advance.

PS: if you are able to run bash scripts then you'll certainly appreciate to use attachment 416098 [details] and attachment 416099 [details]. Automated processing is definitely a convenient feature of computer science ;-)

    
    

    
  
(In reply to comment #68)

> If you still agree to
> work on it, then please start again from the www.mozilla.org pages and use
> attachment 416100 [details] [diff] [review] to remember what changes you made. Keep only important parts:
>

OK, I can do this.

    
    

    
  
Sorry, but I can NOT do this. 

With the new year, other things have come up and I have less time then than I thought.

I have made a few additional changes to a few of the pages on comment #45.
(minor changes to get rid of a few WAI warnings , and a few other small
things)  
All the pages are validated 
XHTML 1.1 plus MathML 2.0 (note: the correct DOCTYPE is used)
CSS level 3
passing WAI Priority 1, 2, 3

    
    

    
  
(In reply to comment #70)
> Sorry, but I can NOT do this. 
> 
> With the new year, other things have come up and I have less time then than I
> thought.

OK, no problem. We've already a starting point if someone wants to continue the work.

    
    

    
  
The W3C HTML validator at http://validator.w3.org/
has been updated to properly accept the DOCTYPE system
identifier for MathML as:
http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd

It use to incorrectly accept the system identifier as:
http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd

All the pages I did in Comment 45 have the correct
system identifier.

It would be a good idea if the "Authoring MathML for Mozilla" page at:
http://www.mozilla.org/projects/mathml/authoring.html
were to be corrected to show the correct DOCTYPE declarations.

    
    

    
  
Good job.

Now that the structure of the pages have the correct DOCTYPE, it is a good idea to change the content of the pages to reflect the new DOCTYPE.  

For example the page 
http://www.mozilla.org/projects/mathml/authoring.html 
still suggests using the old DOCTYPE.

    
    

    
  
Oh, thanks.  I had only checked the *.xhtml files.
http://viewvc.svn.mozilla.org/vc?view=revision&revision=63978

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Fix html, body and banner (obsolete)
        — 
          — Splinter Review
      

    


  
Just a partial fix:
- rewrite the banner with <div/>'s (this should fix most of the errors)
- replace attribute "bgcolor" by "style" in <body/>
- remove attribute "lang" in <html/>

        Attachment #433039 -
        Flags: review?(karlt)

    
    

    
  
I was helping get the W3C validator working better with HTML5, perhaps some 
of the work done there could help this bug.

I copied all the pages referenced in the original comment to this bug to
'https://eyeasme.com/Joe/MathML/HTML5/'
and made TWO COPIES of each file.
(ex: start.xhtml and start.html, basics.xhtml and basics.html, etc.)

The files that end in '.xhtml' ALL validate at
'http://validator.w3.org/'
as XHTML 1.1 plus MathML 2.0

I was finally able to get pixel perfect recreation by noticing that I 
had forgotten to update the cellpadding and cellspacing attributes of a table
tag to the CSS equivalents.  I fixed a lot of code spacing problems and a few 
entity name problems.

The files that end in '.html'
were HTML5-ized and checked for validity at
'http://qa-dev.w3.org:8888/'
(this is the beta W3C HTML validator)

I think all these files should validate as HTML5, since
the same files validate as 'XHTML 1.1 plus MathML 2.0'
(with very minor differences in the files to allow for
differences in the document types)

(I did NOT fix the factual or grammatical errors on the pages)

The results for HTML5 validation are:
https://eyeasme.com/Joe/MathML/HTML5/start.html
    OK

https://eyeasme.com/Joe/MathML/HTML5/start-hebrew.html
    OK

https://eyeasme.com/Joe/MathML/HTML5/start-thai.html
    OK

https://eyeasme.com/Joe/MathML/HTML5/basics.html
    problems with 'mtable' and the 'align' attribute
    problems with 'maction' and the 'selection' attribute
    problems with 'mfrac' and the 'numalign' attribute
    Major problems with the 'sematics' tag

https://eyeasme.com/Joe/MathML/HTML5/mfrac.html
    problems with 'mi' and the 'mathcolor' attribute

https://eyeasme.com/Joe/MathML/HTML5/mo.html
    OK

https://eyeasme.com/Joe/MathML/HTML5/mtable.html
    problems with 'mtable' and the 'align' attribute

https://eyeasme.com/Joe/MathML/HTML5/mspace.html
    OK

https://eyeasme.com/Joe/MathML/HTML5/mmultiscripts.xhtml
    OK

https://eyeasme.com/Joe/MathML/HTML5/roots.xhtml
    problems with 'mi' and the 'mathcolor' attribute
    problems with 'mo' and the 'mathcolor' attribute

https://eyeasme.com/Joe/MathML/HTML5/extras.xhtml
    Major problems with the 'sematics' tag

In reference to Comment #51
The font style change for start-hebrew.xhtml is due to the line 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="he" xmlns:xml="http://www.w3.org/XML/1998/namespace" lang="he">
changing to
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="he">

The font style change for start-thai.xhtml are due to the line
html xmlns="http://www.w3.org/1999/xhtml" xml:lang="th" lang="th">
changing to
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="th">

    
    

    
  
Small copy error, the last two files in Comment #77 aboput HTML5 validation should end in '.html' not '.xhtml'

https://eyeasme.com/Joe/MathML/HTML5/mmultiscripts.html
and
https://eyeasme.com/Joe/MathML/HTML5/roots.html

Note that Firefox has problems with HTML5 pages, even with validated HTML5 pages.
For example mspaces.html screws up &Sum;

    
    

    
  
Thank you Joe. I think your work will have more chance to be integrated if you follow the standard process i.e. creating a patch and getting it reviewed. I believe I should not have tried to help you with these scripts to catch your changes. It will definitely be more beneficial for you to learn how to use programs such that svn, diff etc (normally installed by default on Mac?) and much more convenient for people to follow your work.

BTW, I've a patch for viewsource/zoom functionality (attachment 437269 [details] [diff] [review]) and another for attributes of html/body & the banner (attachment 433039 [details] [diff] [review]).

    
    

    
  
(In reply to comment #80)

> BTW, I've a patch for viewsource/zoom functionality (attachment 437269 [details] [diff] [review]) and
> another for attributes of html/body & the banner (attachment 433039 [details] [diff] [review]).

Cool stuff you did there.  If I return to this bug, I will incorporate your 
changes.


I got all these files to validate as HTML5, see Comment #77.
https://eyeasme.com/Joe/MathML/HTML5/start.html
https://eyeasme.com/Joe/MathML/HTML5/start-hebrew.html
https://eyeasme.com/Joe/MathML/HTML5/start-thai.html
https://eyeasme.com/Joe/MathML/HTML5/basics.html
https://eyeasme.com/Joe/MathML/HTML5/mfrac.html
https://eyeasme.com/Joe/MathML/HTML5/mo.html
https://eyeasme.com/Joe/MathML/HTML5/mtable.html
https://eyeasme.com/Joe/MathML/HTML5/mspace.html
https://eyeasme.com/Joe/MathML/HTML5/mmultiscripts.html
https://eyeasme.com/Joe/MathML/HTML5/roots.html
https://eyeasme.com/Joe/MathML/HTML5/extras.html

I used the validator at 
http://qa-dev.w3.org:8888/

Note:
https://eyeasme.com/Joe/MathML/HTML5/basics.xhtml
https://eyeasme.com/Joe/MathML/HTML5/extras.xhtml
validate as XHTML 1.1 plus MathML 2.0
at
http://validator.w3.org/
but that is because the validator is wrong.

It might be constructive to read the thread
"HTML5 with MathML has problem with numerical attrubute values"
at
http://lists.w3.org/Archives/Public/www-validator/2010May/
starting 'Thursday, 20 May 2010'
There are several issues discussed with HTML5 and MathML 
concerning the validator and the MathML specification.

    
    

    
  
(In reply to comment #81)

> It might be constructive to read the thread
> "HTML5 with MathML has problem with numerical attrubute values"
> at
> http://lists.w3.org/Archives/Public/www-validator/2010May/
> starting 'Thursday, 20 May 2010'
> There are several issues discussed with HTML5 and MathML 
> concerning the validator and the MathML specification.

Note that the conversation continues into June 
http://lists.w3.org/Archives/Public/www-validator/2010Jun/
as
"Re: HTML5 with MathML has problem with numerical attrubute values"
and mutates to
"HTML OK in <mtext> but not in <annotation-xml>, etc. [was: HTML5 with MathML has problem with numerical attrubute values]"
No longer blocks: update-mathml-doc

    
    

    
  
Comment on attachment 433039 [details] [diff] [review]
Fix html, body and banner

Recommendations seem to be to use lang as well as xml:lang.
http://www.w3.org/TR/xhtml-media-types/#compatGuidelines

Was there a reason to remove lang?

From Comment 77, it sounds like at least some versions of Gecko are not
picking up xml:lang.

The other changes look good to me, thanks.

    
    

    
  


  
The W3C validator says that "there is no attribute lang". I don't know why removing it changes the rendering.
I give a version that keeps these attributes.

        Attachment #433039 -
        Attachment is obsolete: true

        Attachment #467546 -
        Flags: review?(karlt)

        Attachment #433039 -
        Flags: review?(karlt)

    
    

    
  
Comment on attachment 467546 [details] [diff] [review]
Fix html, body and banner - V2 [checked in]

Thanks, Frédéric.  Let's leave lang for now, at least until we understand better.

        Attachment #467546 -
        Flags: review?(karlt) → review+
Depends on: 593263

    
    

    
  
Comment on attachment 467546 [details] [diff] [review]
Fix html, body and banner - V2 [checked in]

http://viewvc.svn.mozilla.org/vc?view=revision&revision=73771

        Attachment #467546 -
        Attachment description: Fix html, body and banner - V2 → Fix html, body and banner - V2 [checked in]

    
    

    
  
(In reply to comment #87)
> Note that "This page is typeset according to XHTML, the reformulated way to go
> for the web." contains 5 errors. Given that HTML5 provides a modern non-XML
> alternative, we can maybe just remove this footer?

Yes, sounds good.

        Attachment #482308 -
        Flags: review?(karlt) → review+

    
    

    
  
The last patch should fix all XML errors when we have the MathML3 DTD, except for the "extra" technologies (inclusion of XHTML inside MathML).
Depends on: 234485

    
    

    
  
Comment on attachment 482497 [details] [diff] [review]
Use Unix-style carriage returns instead of DOS ones [checked in]

I didn't check all the lines, but sounds great, thanks.

        Attachment #482497 -
        Flags: review?(karlt) → review+

        Attachment #482498 -
        Flags: review?(karlt) → review+

    
    

    
  


  
This patch fixes the problems with "-moz-opacity". I think that the only remaining CSS errors are with the -moz-math-* (bug 557481).

        Attachment #483241 -
        Flags: review?(karlt)

    
    

    
  


  

        Attachment #483241 -
        Attachment is obsolete: true

        Attachment #483242 -
        Flags: review?(karlt)

        Attachment #483241 -
        Flags: review?(karlt)

    
    

    
  
Comment on attachment 482308 [details] [diff] [review]
Fix more XHTML errors [checked in]

http://viewvc.svn.mozilla.org/vc?view=revision&revision=77046

        Attachment #482308 -
        Attachment description: Fix more XHTML errors → Fix more XHTML errors [checked in]

    
    

    
  
Comment on attachment 482497 [details] [diff] [review]
Use Unix-style carriage returns instead of DOS ones [checked in]

http://viewvc.svn.mozilla.org/vc?view=revision&revision=77048

        Attachment #482497 -
        Attachment description: Use Unix-style carriage returns instead of DOS ones → Use Unix-style carriage returns instead of DOS ones [checked in]

    
    

    
  
Comment on attachment 482498 [details] [diff] [review]
Add encoding, use mathvariant and fix more XML errors [checked in]

http://viewvc.svn.mozilla.org/vc?view=revision&revision=77050

        Attachment #482498 -
        Attachment description: Add encoding, use mathvariant and fix more XML errors. → Add encoding, use mathvariant and fix more XML errors [checked in]

    
    

    
  
Comment on attachment 483242 [details] [diff] [review]
fix transparent background + use "display" instead of "mode" [checked in]

http://viewvc.svn.mozilla.org/vc?view=revision&revision=77052

        Attachment #483242 -
        Attachment description: fix transparent background + use "display" instead of "mode" → fix transparent background + use "display" instead of "mode" [checked in]

        Attachment #483242 -
        Flags: review?(karlt) → review+
Alias: validate-math-pages

    
    

    
  
Remaining errors:

http://www.mozilla.org/projects/mathml/start-thai.xhtml (1 Error)
http://www.mozilla.org/projects/mathml/start-hebrew.xhtml (1 Error)
http://www.mozilla.org/projects/mathml/start.xhtml (1 Error)

==> no attribute "lang". Depends on bug 234485.

http://www.mozilla.org/projects/mathml/demo/mspace.xhtml (1 Error)

==> changes in MathML3 (displaystyle on <math/>)

http://www.mozilla.org/projects/mathml/demo/extras.xhtml (12 Errors)

==> no attribute "title" on MathML elements
==> HTML in MathML undefined

http://www.mozilla.org/projects/mathml/demo/basics.xhtml (17 Errors)

==> changes in MathML3
==> HTML in MathML undefined

I think that most errors can be fixed by using the xHTML5 doctype instead.

    
    

    
  
(In reply to Frédéric Wang from comment #100)
> I think that most errors can be fixed by using the xHTML5 doctype instead.

It seems that the entity names are no longer recognized in that case... we should maybe use numeric entity reference (in a way similar to the examples in the MathML3 REC) ?

    
    

    
  
I don't have a good understanding of exactly what using an XHTML5 doctype would mean.

I wonder whether using (non-XML) HTML5 might be a possible solution?

(I expect that would recognize the standard entities, but I won't object to using numeric entity references if that is what is necessary.)

    
    

    
  

      
      
      
      

        Attached file
          
        Example html5 (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        Example xhtml5 (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        Example html5 (obsolete)
        — 
      

    


  

        Attachment #567537 -
        Attachment is obsolete: true

    
    

    
  
(In reply to Karl Tomlinson (:karlt) from comment #102)
> I don't have a good understanding of exactly what using an XHTML5 doctype
> would mean.
> 
> I wonder whether using (non-XML) HTML5 might be a possible solution?
> 
> (I expect that would recognize the standard entities, but I won't object to
> using numeric entity references if that is what is necessary.)

By XHTML5 doctype I only mean keeping the XHTML format and using "<!doctype html>" (see the attachments). It seems that you are right that entities are recognized in non-XML HTML5. I don't know why they are not in XHTML5.

    
    

    
  

      
      
      
      

        Attached file
          
        start pages HTML5 (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch start pages (obsolete)
        — 
          — Splinter Review
      

    


  
Here is a conversion of the start pages to HTML5. For some reason, I can't validate the thai and hebrew pages, without choosing the option to force utf-8 encoding.

        Attachment #569399 -
        Flags: feedback?(karlt)

        Attachment #569399 -
        Flags: feedback?(karlt) → feedback+

    
    

    
  
> For some reason, I can't
> validate the thai and hebrew pages, without choosing the option to force
> utf-8 encoding.

Do you think we can take these changes now, ignoring this issue with page encoding?

        Attachment #569399 -
        Flags: review?(karlt)

    
    

    
  
Comment on attachment 569399 [details] [diff] [review]
Patch start pages

The "Changing encoding at this point would need non-streamable behavior" error seams to be related to the content-type not being specified in the first 1024 bytes.
(It is a few bytes over.)

Apparently "The authoring conformance requirements for character encoding declarations limit them to only appearing in the first 1024 bytes. User agents are therefore encouraged to use the preparse algorithm below (part of these steps) on the first 1024 bytes, but not to stall beyond that."
http://www.w3.org/TR/html5/parsing.html#determining-the-character-encoding

So I guess the license comment should be moved to after the first meta tag.

        Attachment #569399 -
        Flags: review?(karlt) → review-

    
    

    
  


  

        Attachment #569397 -
        Attachment is obsolete: true

        Attachment #569399 -
        Attachment is obsolete: true

        Attachment #572080 -
        Flags: review?(karlt)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Update links to start pages (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #407262 -
        Attachment is obsolete: true

        Attachment #415782 -
        Attachment is obsolete: true

        Attachment #416098 -
        Attachment is obsolete: true

        Attachment #416099 -
        Attachment is obsolete: true

        Attachment #416100 -
        Attachment is obsolete: true

        Attachment #572082 -
        Flags: review?(karlt)

        Attachment #567538 -
        Attachment is obsolete: true

        Attachment #567540 -
        Attachment is obsolete: true

    
    

    
  
I tried to validate the remaining pages by moving to HTML5. That works fine for mspace.xhtml.

For basics.xhtml, the only remaining problem is how to use HTML in MathML. I tried to use Joe Java's suggestion i.e. including the code

<semantics>
  <annotation-xml encoding="application/xhtml+xml">
  ...
  </annotation-xml>
</semantics>

inside MathML markup. This works because we only display the first element of the <semantics> element. However that's not really how <semantics> is supposed to be used... The validator says that a MathML element is missing (the one supposed to be annotated), so that leaves one error per use of HTML in MathML.

For extras.xhtml, there is also the problem that the title attribute does not exist on MathML elements. We could use maction@tooltip instead, but it's not implemented yet.

We can maybe finish what is possible to validate here and open separate bugs for

1) validating inclusion of HTML in MathML
2) using tooltip in MathML
3) Possibly, convert other demo pages into HTML5

Note that HTML in MathML and title on MathML elements are described in the pages as extra technologies not defined in the MathML spec, so I guess that should not prevent us to close this bug.

        Attachment #572080 -
        Flags: review?(karlt) → review+

    
    

    
  
Comment on attachment 572082 [details] [diff] [review]
Update links to start pages

There are also links between the start pages that should be updated.

It would probably be best to set up some redirects, because other sites likely link here.

        Attachment #572082 -
        Flags: review?(karlt) → review+

    
    

    
  


  

        Attachment #572585 -
        Flags: review?(karlt)

        Attachment #572584 -
        Flags: review?(karlt)

        Attachment #572080 -
        Attachment is obsolete: true

        Attachment #572080 -
        Attachment is obsolete: false

        Attachment #572082 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch redirections (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #572585 -
        Flags: review?(karlt) → review+

        Attachment #572584 -
        Flags: review?(karlt) → review+

        Attachment #572605 -
        Flags: review?(dboswell)

    
    

    
  
Redirects are now being handled by the mozilla.org/firefox infrastructure and James Long is the person to review any redirect patches.

    
  

        Attachment #572605 -
        Flags: review?(dboswell) → review?(jlong)

    
    

    
  
Some patches on this bug have been waiting review for the redirect patch for a while, but now it seems that trunk/projects/mathml/ is removed. Can someone indicate what happened?

    
    

    
  
Can we just commit the patches for MathML pages now? And ask people in charge of bug 724682 to take care of the redirections?

    
    

    
  
I updated the links between start pages and checked in these.
http://viewvc.svn.mozilla.org/vc?view=revision&revision=101971

        Attachment #572080 -
        Attachment description: Patch start pages (V2) → Patch start pages (V2) [checked in]

        Attachment #572584 -
        Attachment description: Update links to start pages (V2) → Update links to start pages (V2) [checked in]

        Attachment #572585 -
        Attachment description: Patch demo/ → Patch demo/ [checked in]

    
    

    
  
(In reply to Karl Tomlinson (:karlt) from comment #121)
> I updated the links between start pages and checked in these.
> http://viewvc.svn.mozilla.org/vc?view=revision&revision=101971

OK, thank you Karl.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED

        Attachment #572605 -
        Attachment is obsolete: true

        Attachment #572605 -
        Flags: review?(jlong)

    
    

    
  
(In reply to Karl Tomlinson (:karlt) from comment #121)
> I updated the links between start pages and checked in these.
> http://viewvc.svn.mozilla.org/vc?view=revision&revision=101971

Those pages should also be renamed since they have been converted into HTML5:

+Redirect permanent /projects/mathml/demo/mspace.xhtml /projects/mathml/demo/mspace.html
+Redirect permanent /projects/mathml/demo/basics.xhtml /projects/mathml/demo/basics.html
+Redirect permanent /projects/mathml/demo/extras.xhtml /projects/mathml/demo/extras.html

    
    

    
  
Oh, sorry I forgot to move them.  Thanks for pointing that out.  I wonder whether there's a better way to import patches into svn.
http://viewvc.svn.mozilla.org/vc?view=revision&revision=101976

    
    

    
  
mmmh, HTML5 does not seem to like self-closing tags in some situations (I'm testing with Firefox 10). I'm pretty sure it worked when I tested locally... I'll continue the work in bug 728725...
Depends on: 730729
Depends on: 731876
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: