Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: I know that. But special parsing rules, just as new CSS properties, need changes to happen in the browser. If someone is going to improve the browser, it'd be much better to improve the presentational layer with a few reusable CSS rules than to add a collection of specific- case parser rules changing the DOM for presentational reasons. Probably it is better to improve presentational layer, but what we have today took about ten years, waiting ten years more until CSS will be improved to address math needs and implemented in browsers is too much. I'd also add that better support for combining diacritics in Unicode, designed to stack over each other, would be great for maths too. They already are expected to stack over each other. And that's why I was asking for better support, not design Yes support for combining diacritical marks would be nice. 2. This isn't going to work correctly when the subscripts and superscripts are complex (e.g. fractions). In your proposal, they'll fail to stack and will go one after another. What should happen is that they should still be one above another, just occupying more vertical space. You're right, that's a pretty valid criticism that I haven't thought about. But if I bring back my third point suggesting new values for vertical-align based on the preceding character's or element's height, we could arrange the meaning of such values as to make vertical overlap impossible. Adding CSS extensions makes sense, but I fear it could take infinite time, therefore it is better to keep markup within XML/CSS2.1 framework so we could start using it today and then gradually improve situations on CSS side. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Alexey Feldgendler wrote:
border-character isn't going to work. When scaled non-proportionally,
characters get ugly, with horizontal elements getting thick. The { and }
characters will suffer the most from this. TeX applies custom logic to
stretchy braces, and I think we shouldn't try to make ANY character
stretch automatically.
Agree. SVG inserted using generate content or maybe image borders would
work better. Something can be achived with ordinary borders and border radius
too.
This isn't going to work correctly when the subscripts and superscripts
are complex (e.g. fractions). In your proposal, they'll fail to stack and
will go one after another. What should happen is that they should still be
one above another, just occupying more vertical space.
Correct positioning of indices is a little bit tricky. I am not against CSS
extensions, but I think that on first stage markup should not rely on CSS
extesions
as it is unclear if and when they will be introduced and implemented. So today
CSS extensions will no help much. Look at XHTML Ruby module, it has CSS3
counter part
but if you want to render Ruby in browsers you have to use different markup
with CSS2.1
rather then existing Ruby markup with CSS3. On the other hand to control all
aspects
of Ruby formatting in a simple convenient way CSS3 Ruby module makes more sense
then CSS2.1.
No doubt it was possible to introduce Ruby markup that would basically work
with CSS2.1
and for quality formatting would require some CSS3, however it was not done.
Result is no Ruby on web (Once we wrote UserJS for Ruby and tried to test how
it works
on real web. We found only one page with Ruby and even that page was served as
text/html
where Ruby is not allowed by specs). Thus CSS3 extensions are useful, but they
are useful
in long term perspective only while for short term we have to ensure
compatibility
with what we will actually have in near future (~ CSS2.1), without ensuring
this CSS3
extensions are unlikely to be implemented (why to implement them if there is no
markup
that would benefit from CSS3 math module).
--
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com
Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: Le 20 juin 2006 à 6:53, Robert O'Callahan a écrit : I would also like to see a complete description of the CSS extensions required for real high-quality rendering. I can't claim this is complete, but two ideas come to my mind right now: [4 suggestions] Also, as far as I know (and maybe I am just ignorant), there is no way to deal with wrapping of mathematics e.g. f(x) = ax^4 + bx^3 + cx^2 + dx + e should wrap to the right of the equals sign as far as possible (i.e. up until the point the screen is too narrow) like: f(x) = ax^4 + bx^3 + cx^2 + dx + e I'm also not sure there exists a simple mechanism to get multiple lines of mathematics to line up on a specified point like: He + He - Be + gamma Be + He - C* C* - C + gamma - clearly one could hand tweak this on a case by case basis but it's not ideal. In addition to those, I'm pretty sure there are also significant character spacing issues if you're looking for TeX-quality rendering. -- You see stars that clear have been dead for years But the idea just lives on... -- Bright Eyes
Re: [whatwg] Mathematics in HTML5
Le 22 juin 2006 à 3:52, White Lynx a écrit : Adding CSS extensions makes sense, but I fear it could take infinite time, therefore it is better to keep markup within XML/CSS2.1 framework so we could start using it today and then gradually improve situations on CSS side. It will surely take some time. But we also have two open-source and widely-used html/xml/css rendering libraries, so, if there is enough interest, and if the changes are easy to implement, someone could add the CSS extensions to the libraries and the browsers that use them. I took a look at the WebKit source for the first time this morning and I think I found exactly how I could implement the CSS features I've talked about. Maybe I should give it a try. What I fear is that if HTML standardize an inelegant syntax based on presentation it may come bite us later on if/when CSS has improved. Beside, stretchy parenthesis/braces/chevrons/roots don't seem to be in the reach of CSS 2.1 anyway, you'll still have to wait new styling improvements for these pretty essential parts, it could be long too. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Juan R. Gonzalez-Alvarez wrote: I assume that authors agree. Therefore, now is matter for developers, they have the last word. Basically there is nothing in proposal that could be difficult to implement, morover on first stage XHTML with fallback style sheets can work without any kind of native support. So implementation costs, that in any case are much lower then alterenatives, are unlikely to be an obstackle. Look at proposal once again: 1. formula, dformula, dformgrp - just containers, no problems. 2. sub, sup - already exist nothing to add 3. stack - requires support for inline-blocks. No problems in MSIE, Opera, Prince. Safari and Mozilla will have to fix bug affecting inline-blocks. 4. fraction, num, den - the same as stack. 5. over, obase, top, overbrace - the same as stack 6. under, ubase, bottom, underbrace - if content of ubase is restricted to PCDATA then the same as stack, otherwise either inline-tables (work in Opera, Prince, require small bug fix in Safari) or inline-blocks and CSS3 inline-block-align properties are needed. So in case inline-tables will be considered unrealistic elements still can be retained provided that content of ubase is restricted to PCDATA, in future this constraint can be easily eliminated. 7. opgrp, op, uli, llim, limits - the same as stack 8. radical, radix, radicand - requires inline-tables. Element is safe to omit as equivalent fuctionality is available in power notations. So in case inline-tables will be considered unrealistic element may be omitted. 9. sqrt - requires inline-blocks, maybe image borders, or SVG backrgound image. Element is safe to omit as equivalent fuctionality is available in power notations. 10. fence, fenced, marker, submark - the same as stack. Support for image borders or SVG backrgound images would be useful. 11. matrix, det, choose, cases, case, row, entry, cell, value, scope - formally it requires inline-tables, but necessary functionality exists in all browsers in a form of (X)HTML table with display set to inline, inline-table or -moz-inline-box. Thus proposal can be naturally split into three ones. I. Full proposal II. 1,2,3,4,5,6 with restricted content of ubase, 7, 10, 11 (Juan's proposal) III. 1, 2, 4 (Michel's proposal) All of them are realistic and should not be difficult to implement. If WHAT WG does not want to standardize first proposal as markup for mathematics in HTML5, then options II and III exist. Regarding presentation quality issues, please once again note that markup focuses on structure, we don't ask anyone to register proposal as participant of Miss Finland 2006. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Le 21 juin 2006 à 7:16, White Lynx a écrit : 1. formula, dformula, dformgrp - just containers, no problems. 2. sub, sup - already exist nothing to add 3. stack - requires support for inline-blocks. No problems in MSIE, Opera, Prince. Safari and Mozilla will have to fix bug affecting inline-blocks. 4. fraction, num, den - the same as stack. I. Full proposal II. 1,2,3,4,5,6 with restricted content of ubase, 7, 10, 11 (Juan's proposal) III. 1, 2, 4 (Michel's proposal) My proposal was fractions, and *only* fractions. I never included formulas in it. I think that any kind of formula element would be a little silly if we are to only offer fractions to authors. I'm not really opposed to formula per se, I think however that dformula and dformgrp are superflous. So, using your list, my proposal was really 2 and 4, and nothing else. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: 4. In the same reasoning, it would be great if there was a way adjacent elements could share the same horizontal space, like sup and sub when they are next to each other: Csup1/supsub2/sub To avoid changes on CSS side in current proposal this is achived via special HTML parsing rules that treat adjacent indices as stacked. sup1/supsub2/sub = stacksup1/supsub2/sub/stack Parsing rules does not apply to XHTML version however. I'd also add that better support for combining diacritics in Unicode, designed to stack over each other, would be great for maths too. They already are expected to stack over each other. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: My proposal was fractions, and *only* fractions. This rises question how to mark formulae produced by combining expressions with fractions and indices. At least one element for this purpose would be necessary. Even DocBook and TEI that does not have their own math markup, have containers for math formulae. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
On Wed, 21 Jun 2006 21:48:25 +0700, Michel Fortin
[EMAIL PROTECTED] wrote:
1. Some border-character property, which would work mostly like CSS
3's border-image, but would put a stretchable character in the border.
The browser would be in charge of stretching. border-image with SVG
could be an adequate substitute for some characters, but I'm not sure it
would be so great with braces or arrows.
border-character isn't going to work. When scaled non-proportionally,
characters get ugly, with horizontal elements getting thick. The { and }
characters will suffer the most from this. TeX applies custom logic to
stretchy braces, and I think we shouldn't try to make ANY character
stretch automatically.
4. In the same reasoning, it would be great if there was a way adjacent
elements could share the same horizontal space, like sup and sub
when they are next to each other:
Csup1/supsub2/sub
I'm thinking of something which I would call inline-float (for
the lack of a better name), which would make two or more elements
with that property collapse into the same horizontal space when
they are following directly each other and are not overlapping
vertically.
1. They would also need to be aligned either to left or right (to
accomodate prefixes to chemical symbols).
2. This isn't going to work correctly when the subscripts and superscripts
are complex (e.g. fractions). In your proposal, they'll fail to stack and
will go one after another. What should happen is that they should still be
one above another, just occupying more vertical space.
--
Alexey Feldgendler [EMAIL PROTECTED]
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Mathematics in HTML5
Le 21 juin 2006 à 13:29, Alexey Feldgendler a écrit :
On Wed, 21 Jun 2006 21:48:25 +0700, Michel Fortin
[EMAIL PROTECTED] wrote:
1. Some border-character property, which would work mostly like
CSS 3's border-image, but would put a stretchable character in the
border. The browser would be in charge of stretching. border-
image with SVG could be an adequate substitute for some
characters, but I'm not sure it would be so great with braces or
arrows.
border-character isn't going to work. When scaled non-
proportionally, characters get ugly, with horizontal elements
getting thick. The { and } characters will suffer the most from
this. TeX applies custom logic to stretchy braces, and I think we
shouldn't try to make ANY character stretch automatically.
Well, my idea was that the stretching logic would be character- and
implementation- specific. A nice browser would stretch braces using
its own elegant way, while an ugly browser could use linear
stretching or no stretching at all.
4. In the same reasoning, it would be great if there was a way
adjacent
elements could share the same horizontal space, like sup
and sub
when they are next to each other:
Csup1/supsub2/sub
I'm thinking of something which I would call inline-float (for
the lack of a better name), which would make two or more
elements
with that property collapse into the same horizontal space when
they are following directly each other and are not overlapping
vertically.
1. They would also need to be aligned either to left or right (to
accomodate prefixes to chemical symbols).
The way I was thinking about it, you would have: inline-float:
left, inline-float: right and inline-float: center to align
horizontally the element's box inside the collapsed area.
2. This isn't going to work correctly when the subscripts and
superscripts are complex (e.g. fractions). In your proposal,
they'll fail to stack and will go one after another. What should
happen is that they should still be one above another, just
occupying more vertical space.
You're right, that's a pretty valid criticism that I haven't thought
about. But if I bring back my third point suggesting new values for
vertical-align based on the preceding character's or element's
height, we could arrange the meaning of such values as to make
vertical overlap impossible.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Le 21 juin 2006 à 12:00, White Lynx a écrit : Michel Fortin wrote: 4. In the same reasoning, it would be great if there was a way adjacent elements could share the same horizontal space, like sup and sub when they are next to each other: Csup1/supsub2/sub To avoid changes on CSS side in current proposal this is achived via special HTML parsing rules that treat adjacent indices as stacked. sup1/supsub2/sub = stacksup1/supsub2/sub/stack I know that. But special parsing rules, just as new CSS properties, need changes to happen in the browser. If someone is going to improve the browser, it'd be much better to improve the presentational layer with a few reusable CSS rules than to add a collection of specific- case parser rules changing the DOM for presentational reasons. I'd also add that better support for combining diacritics in Unicode, designed to stack over each other, would be great for maths too. They already are expected to stack over each other. And that's why I was asking for better support, not design, in the sentence above. I mentioned they were meant to stack in case someone missed that from one of the previous 195 messages of that very long thread, but I admit it could have been formulated better. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: Bugs will need to be fixed with many CSS engines, Withdrawing proposal does not mean that this bugs need not to be fixed. They has to be fixed in any case. and even then the current markup proposal isn't something I'd call pretty even for simpler structures (fencedfence1/fence/fenced Standalone fence without markers is just fencecontent/fence. Markup fencedfence1/fence/fenced is invalid. or radicalradix/ radixradicand2/radicand/radical for example). As it was mentioned in one of previous messages there will be separate element for square roots sqrt2/sqrt This makes the markup a little counter intuitive and will probably prevent a consensus. Note also that in long term perspective HTML parsing rules are expected to cut down verbosity further. I think there is still a lot to be done and discussed and maybe the WhatWG mailing list isn't the best place for that at this point. Isn't this discussion delaying other important things in the spec? In this case why not to remove Comments are very welcome, please send them to [EMAIL PROTECTED] Thank you from WD (according to subject discussion is realted to HTML5). Something that's definitely missing for elementary algebra is a construct capable of representing a fraction. So I propose that HTML 5 adds fractions, and only fractions. It would be step in right directions. Markup for fractions is something that is safe to include in HTML, it is bullet proof concept, no changes in this markup nor any problems with this kind of markup are expected. I think there is a good consensus on how to markup a fraction. Yes. The same markup is used in ISO 12083, AAP Math DTD and most of other DTDs that I have seen, modulo naming conventions this markup is: fraction numnumerator/num dennumerator/den /fraction /* The only people who managed to reinvent wheel and make it square are those who proposed HTML3 Maths and MathML */ I believe fractions can also be somewhat useful outside the realm of mathematical formulas. And a fraction construct would encourage implementors to fix their inline-block and vertical alignment CSS bugs, opening the door to more CSS-based mathematical markup in the future. Very well. So at least add ISO 12083 fractions construction to HTML, it works in MSIE 6, Opera 9, Prince 5 http://www.geocities.com/chavchan/frac/fractions.xml With one small bug fix it will work in Safari and PDFReactor, with more complex but still one bug fix it will work in Mozilla too (Gecko bug is expected to be fixed in near future). Fractions work in XSL FO too, for instance Antenna XSL Formatter 4 can handle them using fo:inline-container. I'm retaining only the part that can work with the least effort, Overscripts can work with even less efforts. Math containers like formula and dformula require practically no efforts at all. the part with a simple undisputed markup, the part which I expect every author and user will understand for what it means and which has the biggest relevance inside and outside of the field of mathematics. Ok. Maybe more can be added to HTML in the future, In fact much more can be added even today. but if only one thing about math is to be added to HTML 5, it obviously has to be the fraction. Ok. But add at least one container (better two, one inline and one block level) for math formulae, like this is done in Docbook, TEI, NIH Pubblishing DTD and many other DTDs. I guess one argument against this is that it will constitue an incomplete mathematical markup. Still it is better then nothing and this will allow us to continue process in future as markup for fractions remains and will remain the same for ages. Let's keep things simple and just improve what we already have. I still think that more can be done. But since there is no political will to do more, let's make first step today and continue the process tomorrow. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Ian Hickson wrote: There is nothing to read between my lines. I am being as honest and candid as possible. There is no conspiracy here. I have given you the exact reasoning I have used, I have suggested how you can move forward. I am being quite sincere. Very well. In this case please make one small step to show that WHATWG HTML is open to scientific content and add just four elements to HTML5 (feel free to use different element names if nesessary): formula, fraction, num, den. It will not take much time and will work even in MSIE: http://www.geocities.com/chavchan/frac/fractions.xml If this step will be made we will assume that WHATWG is ready for constructive dialog, if however we will hear arguments like automated splitting of long fractions across lines (never seen something like that even in TeX) is not supported therefore markup for fractions is useless or something similar then I think discussing issue with WHATWG further does not make any sense. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
On Tue, 20 Jun 2006 14:43:23 +0700, White Lynx [EMAIL PROTECTED] wrote: Very well. In this case please make one small step to show that WHATWG HTML is open to scientific content and add just four elements to HTML5 (feel free to use different element names if nesessary): formula, fraction, num, den. It will not take much time and will work even in MSIE: http://www.geocities.com/chavchan/frac/fractions.xml How should formula be used? There has been some discussion about it. If this step will be made we will assume that WHATWG is ready for constructive dialog, if however we will hear arguments like automated splitting of long fractions across lines (never seen something like that even in TeX) is not supported therefore markup for fractions is useless or something similar then I think discussing issue with WHATWG further does not make any sense. I've never said that splitting of long fractions is a requirement. That was just my answer to the question: What is excellent typography? Of course, if someday CSS becomes powerful enough to do such splitting, it will become possible without any change of markup. This is similar to features like hyphenation for paragraph formatting: if it gets implemented, the author won't need to change the p markup. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: Something that's definitely missing for elementary algebra is a construct capable of representing a fraction. So I propose that HTML 5 adds fractions, and only fractions. Yes please, that would be a great start. It is quite cheap and a reasonable way to get a certain amount of user feedback.
Re: [whatwg] Mathematics in HTML5
Robert O'Callahan wrote: From my point of view, a fraction element that can be implemented using inline-block in the UA style sheet seems like a reasonable thing to support in HTML5, since it's basically no effort and is a small increment over existing sup etc. Thus fractions work in MSIE, Opera, Prince. One of Mozilla developers admits that including fractions in HTML5 makes sense. Seems like no problems on browsers side. Include them in HTML5 and at least school level mathematics will get its place on web. This is small step but it is still important as torturing people that need to include simple formulae in web page with complex machinery involving XHTML, namespaces, MathML that requires extra plugins in most of browsers, sometimes XSLT or JS, from the very beginning makes web very distructive for math and not only math folks. So small step in right direction makes sense. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Alexey Feldgendler wrote: How should formula be used? There has been some discussion about it. In case when everything is reduced to fractions and simple indices, it can be optional. But having such an element is still important for those who want to mark formulae explictly. I've never said that splitting of long fractions is a requirement. That was just my answer to the question: What is excellent typography? Yes, but later typography related arguments were used by others against math proposal. I assume there is some kind of consensus on fractions. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
On Tue, 20 Jun 2006 18:47:42 +0700, White Lynx [EMAIL PROTECTED] wrote: How should formula be used? There has been some discussion about it. In case when everything is reduced to fractions and simple indices, it can be optional. But having such an element is still important for those who want to mark formulae explictly. Then why include it now? It can be added later. On the other hand, an element for out-of-line formulae would be nice. At least it wouldn't be a no-op element (that is, an element which doesn't change the appearance of the document unless specially styled). Practice shows that noone uses no-op elements consistently anyway. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Mathematics in HTML5
Ian Hickson wrote: On Mon, 19 Jun 2006 [EMAIL PROTECTED] wrote: 1) It has been proven that via Standard CSS 2.1 not designed for math one can render math better than browsers with native support (as Firefox 1.0) and infinitely better than MSIE, Safari, and Opera (rendering natively zero mathml). I don't think so. In my experience Mozilla renders maths in a way much superior to the CSS approach. I'm also not convinced that the CSS approach is good enough for people to use instead of GIFs. People want things to be pretty, that's why people abuse HTML for layout purposes Well, as said I will add some snapshots in canonical science today and people could decide that approach they prefer. Moreover, I have asked in many times what technical limitation of CSS does that rendering of mathematics cannot be true. Here one would separate George specific CSS techniques from CSS rendering. Or in other words, what part of rendering Mathematics on the web could not be implemented via a CSS layout engine? so much. There's no point providing a solution that people won't use -- so before we add it to the spec, we have to be sure it will be used. Of course, I agree! But adding it to the draft of the spec could be a good step for receiving feedback from community. If they reject that part of the draf then mathematical markup would be eliminated from the final spec. If many voices claim for a minimal cheap mathematical markup without rely on abominable MathML then success would be guarantee. In this list I have heard more pro voices. Maybe statistic can be applied to the rest of community. This philosophy was not applied to the rest of HTML5 spec, no? Yes. Canvas was only added once Apple proved it was implementable and popular, and had documented it. Popular in the web? I think that it has been proven that CSS approach to Mathematics is implementable and is well documented (note that is not need for special parsing modes, mstyle extensions or DOM extensions). Is popular? Well, I entered [math CSS] in Google and returns several pages with different techniques, approaches. Apparently people is interested in rendering of mathematics via CSS. I know most of people think that MathML is the only approach to mathematical rendering. Therefore, interest could be greater when that online myth broken. I have also been trained that Mozilla developers have add CSS mathematical extensions to the browser, e.g. -moz-math-rowline CSS rule, but I do not know anymore. Drag and drop was added based on both IE and Safari implementing a compatible API that is used on the Web, and that is widely documented. Contrary to MathML, the CSS approach reuse available well-documented drag and drop. Most of the new elements -- footer, nav, header, menu, etc -- were based on a survey of over one BILLION documents to see what authors were using/needing. Typping [math online] on Google returns some 10^6 of webpages. Typping [mathematics online math] returns some 10^6 more. Typping [need math -online] returns some 10^6 more. Now add scientific and engineering communities. I think one obtain something close to 10^7 documents. Whereas I am not claiming that math was more popular than menu I still think that math is a primary need on the web. The event and personal information sections are waiting on feedback and experience from the Microformats community. HTML5-Math could wait on feedback and experience from the CSS-Math community. The parsing model is based on extensive reverse-engineering of the four most widely used browsers; the browsers used in the study themselves were picked based on extensive research. HTML5-Math is based in standard approaches availables in any modern browser. control. The list goes on. But i) HTML5-Math reuse available code and standards before reinvent the wheel (MathML way) ii) HTML5-Math is based in ISO-12083 (broadly researched and implemented in SGML world) with minimal changes for adapting it to web. iii) Your own approach with special parsing model is not based in extensive research (at least at my best current knowledge). Yet, in the real world, we have to worry about such things. I said not the contrary (in fact one of my points against MathML was that it is very expensive), just that you calculation appears strange to me because the CSS approach is more cheap. At least other guy reacted in a similar way to you looking-strange calculation of costs. My intent is that they would be the same mrow, but I admit I haven't explained my proposal fully. This is mostly because I am not convinced that MathML itself is good enough either. Additional reason for the research in alternatives. I could understand that people want delay this for a more comlete discussion and maybe HTML-Math could be implemented in a hypotetical HTML6 (this could be discussed) or in an alternative XML approach somewhat as OpenMath is already a better option to content MathML 2.0-.
Re: [whatwg] Mathematics in HTML5
On Tue, 20 Jun 2006 19:20:28 +0700, White Lynx [EMAIL PROTECTED] wrote: How should formula be used? There has been some discussion about it. In case when everything is reduced to fractions and simple indices, it can be optional. But having such an element is still important for those who want to mark formulae explictly. Then why include it now? It can be added later. And what to do until then? Use emaxsup2/sup + bx + c = 0/em or span class=mathaxsup2/sup + bx + c = 0/span how to mark math formula? Don't tell us to use microformats. Ok, I've looked through some archived mail in this list, and I'm convinced that we need formula. At least it wouldn't be a no-op element (that is, an element which doesn't change the appearance of the document unless specially styled). In the same manner you can remove html and head, they are no-op elements. formula element is important from structural point of view. If I was reinventing HTML from scratch now, I would drop HEAD and BODY and leave just the HTML element. But we have backward compatibility preventing us from doing this, of course. And, just like I said, a lot of pages misuse HEAD and BODY just because omitting them or messing them up doesn't break the page display. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Mathematics in HTML5
Le 20 juin 2006 à 3:40, White Lynx a écrit : Yes. The same markup is used in ISO 12083, AAP Math DTD and most of other DTDs that I have seen, modulo naming conventions this markup is: fraction numnumerator/num dennumerator/den /fraction That was what I had in mind. I used to prefer frac over fraction, but I'm not sure anymore, both would work with me. I believe fractions can also be somewhat useful outside the realm of mathematical formulas. And a fraction construct would encourage implementors to fix their inline-block and vertical alignment CSS bugs, opening the door to more CSS-based mathematical markup in the future. Very well. So at least add ISO 12083 fractions construction to HTML, it works in MSIE 6, Opera 9, Prince 5 http://www.geocities.com/chavchan/frac/fractions.xml With one small bug fix it will work in Safari and PDFReactor, with more complex but still one bug fix it will work in Mozilla too (Gecko bug is expected to be fixed in near future). Fractions work in XSL FO too, for instance Antenna XSL Formatter 4 can handle them using fo:inline-container. ... and, by using custom stylesheets for these browsers, it can also work reasonably well in current versions of Gecko and Safari, both with unperfect but not-too-bad vertical alignement. The whole fraction would be vertically centered instead of having its bar aligned relative to the text baseline, which would give mostly the same result unless the numerator and the denominator have different heights. The only issue is how to feed them with a separate stylesheet... Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Henri Sivonen wrote: On Jun 20, 2006, at 10:42, White Lynx wrote: Henri Sivonen wrote: There are only stretchy brackets. No stretchy parentheses or braces in sight. Did you check fences part at http://www.geocities.com/chavchan/css/ annotated.css I didn't. I checked the sample documents, and I didn't see any stretchy parentheses or braces. Also, the stretchy square root hack is just ugly. May I ask how this issue is related to MARKUP proposal? I wasn't commenting on markup. I was commenting on the claim that you had solved the problem of math rendering using CSS. You have not. Fractions are only used in display math, etc. No. They can be used inline and can be nested anywhere. Check DTD. I was referring to what *is done* in the samples. This is no coincidence, because CSS doesn't do stretchy math characters. Moreover, general-purpose text rendering subsystems and fonts usually don't do stretchy characters which is why math renderers typically special-case these with font-specific knowledge. Once again, how his issue is related to MARKUP proposal? The markup has to be rendered. On the Web, this means specifying the rendering via CSS or making the rendering engine do special-case stuff when CSS is not sufficient. Clearly, CSS today is insufficient for rendering math. (It doesn't do stretchy characters, for example.) It was already explained why it is a bad idea to expect CSS to change to accommodate your markup: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-June/ 006551.html http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-June/ 006588.html Do you would review your posts twice before submit. You would also split CSS rendering of HTML5-Math proposal *from* specific CSS approaches to render math people has done. Try to this *simple* but cool approach to render math via CSS [http://goessner.net/articles/wiky/WikyBox.html] The approach can be improved in many ways, for example, the vertical-align:middle do not work for num and den of different sizes (solved in most recent George CSS stylesheet). Further data and comments on the rest of your message already available on the archives of the list. That leaves special-casing. The special-casing for MathML is already implemented in Gecko and Trident+MathPlayer. The special-casing for your markup isn't. Further data and comments already available on the list. Examples on why MathML does not work and render math incorrectly (but CSS not) will be posted in canonical science today in brief. I also will update a game. I will submit pair samples of same mathematics: one of them using MathML and other using CSS rendering, asking to people to find what is ;-) It will be amazing to verify if in the real world MathML quality rendering is so infinitely superior to a pure CSS 2.1 approach (i.e. *can be improved* via CSS math extension) as has beeen claimed here. I will take examples from real sites using MathML today. There is not need for repeating more has been said except maybe than Goessner is working with Firefox 1.5, Internet Explorer 6, and Opera 8.5. That is more that MathML has achieved after of 3 specs and many propaganda in media. Juan R. Center for CANONICAL |SCIENCE)
Re: [whatwg] Mathematics in HTML5
On Jun 20, 2006, at 15:26, [EMAIL PROTECTED] wrote: However, it look better that via native MathML support browsers (without downloading and installing special fonts). Comparing anything to a MathML implementation without giving the MathML impl the fonts it needs is totally bogus. Yes, the font special-casing is uncool. See http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-May/ 006467.html for how to help fix it in the non-stretchy case. In the stretchy case, tight coupling with particular fonts will be required in the foreseeable future. Whereas George approach will work for any font you desire you It doesn't work. The result is ugly! We are supposed to marvel the clothes, but the emperor is naked. Developers prefer another couple of CSS rules rather than begin from zero with a unfriendly spec (MathML). Developers? Gecko is already well past zero with MathML. Addition of general purpose features is defined in CSS 2.1 and may be addressed by brosers *in any case*. Last MSIE browser has incremented its native support for CSS 2.1 whereas continues ignoring MathML. The inline-block CSS bug in Firefox is scheduled and will be fixed in a future version. http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-June/ 006551.html http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-June/ 006588.html specially in next Tim Bray semantic web, I think you confuse Tim Bray and Tim B-L. Since XSL-FO I don't understand why you keep bringing up XSL-FO. I assure you that bringing up XSL-FO in almost every message doesn't help you make your case. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Mathematics in HTML5
Robert O'Callahan wrote:
I'll speak up as one of the Mozilla layout developers, but speaking only
for myself.
Since we already have a MathML implementation --- which works fairly
well in my experience ---
Do you mean structurally invalid, inacessible, not searchable, and
sometimes incorrectly rendered math that one find even at academic sites
using MathML? Do you mean the in-house **modification** of MathML Elsevier
is using but still serving graphics on the web?
Or do you mean that due to specificies of MathML ugly design, Mozilla
layout engine is unable to fully implement MathML formatting semantics?
You may know this point better than me. I am not sure but apparently the
solution to this will be a complete rewritting of the Gecko engine from
zero, that is true?
Or by fairly well do you mean an average theorem in the HELM library
takes up 20 minutes to render on a high-end machine? The own Mozillas
MathML author has studied this point in detail and traced the problem to
the own MathML layout engine in Gecko.
Also I think (correct me if wrong) that you are talking from a pure
developer view (without many experience in authoring of complicated MathML
docs). In theory, MathML would be able to render something so simple as
{ds}^2. In practice both Distler (Mussing ultra-technological blog) and
Living reviews on relativity online journal (HERMES project) still are
unable to do something so simple as visual rendering of {ds}^2 how I have
pointed many times (aural rendering and accesibility of code is purely
inexistent).
A few days ago, Distler received notification about my open criticism
about one of his multiple incorrect encodings of mathematics on the web
and he changed the code just a few days ago, but now the visual rendering
is poor that using old HTML 3 code.
The point is that there exist very important holes and mistakes in the
MathML specification, and waiting spreading on the web or magical
implementations of the spec. in all browsers does not eliminate the holes
and mistakes.
We are trying to eliminate those problems from the web. In fact anyone
using HTML5 will be able to encode and render {ds}^2. Mussings (claimed to
be the technologically most advanced blog of the planet) is unable to so
simple taks even using: MathML 2.0 + XHTML 1.1 + special DTD + native
browsers + special MIME + special fonts + special plugin + special IteX
dialect.
I think it makes more sense from our point of
view to fix/improve MathML than to deal with new CSS extensions to get
decent rendering.
MathML 2.0 did some presentational features of MathML 1 deprecated. MathML
3.0 probably will do some of current presentational features of MathML 2.0
deprecated. The CSS Math extensions are scheduled by both MathML and CSS
IG and would be implemented in browsers in any case. Therefore, the
fixing/improving of p-MathML looks (in my opinion) as a waste of time.
Moreover, p-MathML violates basic guidelines of web-desing, somewhat as
XSL-FO or SVG do. Mozilla has publicy expressed its interest in adding CSS
extensions for a **semantic** implementation of most of SVG. Those
extensions for vectorial graphics could be reused for rendering math (e.g.
roots): somewhat as today we can render mathematics using SVG without need
for native p-MathML, including stuff that p-MathML cannot render:
geometry, commutative diagrams, chemistry...
MathML's purported incompatibilities with DOM and CSS
are not serious from an implementor's point of view, at least no worse
than lots of other CSS-unfriendly content we have to deal with. I hope
that the fonts issue gets better when comprehensive STIX fonts are
freely available online and we can automatically download them whenever
they're needed.
Mozilla philosophy of adding everything (even incompatible layers) in a
big elephant monolithic module is not popular in other browsers (e.g.
Opera). Therefore...
Is it true that future STIX fonts will need of a significant rewriting of
the MathML formatting engine of Mozilla? Will be we need new versions of
the browser for new font families?
stronger case for inclusion. I would also like to see a complete
description of the CSS extensions required for real high-quality
rendering.
Why do not ask to CSS-MathML module people or even to your own Mozilla
colleagues for the already implemented -moz-math CSS extensions?
From my point of view, a fraction element that can be implemented
using
inline-block in the UA style sheet seems like a reasonable thing to
support in HTML5, since it's basically no effort and is a small
increment over existing sup etc.
What one great notice!!!
What do you opine of my suggestion for addition also sub-sup and
under-over constructs to the basic spec?
Both sub-sup and under-over constructs are _basically_ fractions without
the line. Once fractions are implemented in UA, I would wait minimal
efforts for the implementation of sub-sup and under-over.
We could leave away roots (can be still displayed
Re: [whatwg] Mathematics in HTML5
White Lynx wrote: The difference between fractions and the rest of proposal is that markup for fractions is the same across many DTDs and it is hard to imagine something different (only W3C can). Thus markup for fractions is more or less unique. In the rest of proposal uniqueness it is not so obvious, but basically it is still there. I mean, once you cheaply implement the generic construct content-tag tag1/tag1 tag2/tag2 /content-tag for fractions in HTML5 as appears that all of us here achieve consensus (including one from Mozilla Team) the implementation of the *same* construct for sup-sub and under-over is trivial since only real changes are on the stylesheet rules (e.g. no line for tag1 etc.), and could be done if developers and authors agree. I would find it good. I assume that authors agree. Therefore, now is matter for developers, they have the last word. Michel Fortin wrote: ... and, by using custom stylesheets for these browsers, it can also work reasonably well in current versions of Gecko and Safari, both with unperfect but not-too-bad vertical alignement. The whole fraction would be vertically centered instead of having its bar aligned relative to the text baseline, which would give mostly the same result unless the numerator and the denominator have different heights. The only issue is how to feed them with a separate stylesheet... and even with so one tiny implementation, rendering could be improved easily. For instance using a % vertical align rule firefox 1.0 is able to render fractions also with denominators of arbitrary size including nested fractions as that in the MathML test suite. Henri Sivonen wrote: On Jun 20, 2006, at 15:26, [EMAIL PROTECTED] wrote: However, it look better that via native MathML support browsers (without downloading and installing special fonts). Comparing anything to a MathML implementation without giving the MathML impl the fonts it needs is totally bogus. Then you are not reading this mailing list during last weeks since rendering problems remain even using special fonts in Mozilla. Whereas George approach will work for any font you desire you It doesn't work. The result is ugly! We are supposed to marvel the clothes, but the emperor is naked. No. Many people is displaying math without MathML and find it *nice*. Ugly is a subjective word. Moreover, wait a few days until I can update canonical science today and participate in the game. If CSS approach looks so ugly you would be able to differentiate formulas constructed via CSS and via MathML, no? Developers prefer another couple of CSS rules rather than begin from zero with a unfriendly spec (MathML). Developers? Gecko is already well past zero with MathML. A Mozilla guy has expressed interest in this approach. Developers from MSIE and Opera may prefer (I suspect) another couple of CSS rules rather than begin from zero with a unfriendly spec (MathML). specially in next Tim Bray semantic web, I think you confuse Tim Bray and Tim B-L. Yes I did, even if Tim Bray is also evagelizing about RDF and all that stuff. P.S: XSL-FO ;-) Juan R. Center for CANONICAL |SCIENCE)
Re: [whatwg] Mathematics in HTML5
On Sun, 18 Jun 2006, White Lynx wrote: Ian Hickson wrote: Certainly. The question is how. There have been several proposals. My recommendation to those who think it is possible to re-use CSS to get an acceptable level of Math support would be to go through the Microformats process to prove the case. What is the difference between writing style sheet for microformat and writing style sheet for XML based markup? There is no difference. Sorry, I wasn't clear. I meant going the Microformats *process*, not necessarily writing style sheet for microformat. It can be based on XML if that is what the Microformats process shows is best. The point is to show the maturity of your proposal before it is put into HTML, because of the next point: It doesn't make sense to bless a dozen new tags (or more) to be in the HTML namespace (and thus with us for all time!) Do you pay any fee for registered element names? ;) Yes. It takes a couple of engineers to implement a new tag, typically, and probably on average takes them about a week (forty hours). (Some tags take months and many engineers, some take minutes for one engineer.) It takes about a week also for a QA person to write tests for a new element, then another week or two over the next few years to handle bugs in that element (again, on average). Let's say a hundred hours. Documentation probably takes about three days (twenty four hours). So that's an average time of 204 man-hours per browser. There are at least ten browsers in active development, probably more. So that's 2040 hours. It takes about ten to twenty hours for a spec editor to write the spec, plus an hour for people to review it. Let's be pessimistic and say that a hundred people review the spec (for something like HTML, it's probably in the thousands really). That's a total time of about 115 man-hours for the spec. It probably takes a dozen people about an hour each to report on the new element, plus about another dozen people about an hour to write a tutorial for the feature, assuming it's a simple feature. 24 man-hours. Finally, it takes Web developers a few minutes to read about the tag and see if they care or not. Assuming that they don't care (if they do, it'll take them much longer), it probably takes an average of one minute per developer to read the spec or article about the feature. Let's assume that sixty thousand developers look at the feature. That's 1000 man-hours. Assuming that the people involved value their time at an average of $10 per hour, that's 3179 man-hours at $10 each, so $31,790 per element name. These are of course back-of-the-envelope calculations. But hopefully my point is clear: we have to be confident that a tag name is worth it before adding it to the spec. Is lack of mathematical markup in HTML good enough for mathematicians and scientists? Apparently, GIF images for equations are good enough, yes, otherwise people wouldn't be using HTML for mathematical subjects, which they are. Naturally, I agree that things could be better -- and indeed a number of solutions have been developed to address this (at huge cost to the industry, I should point out). It is not clear to me that your draft proposal is better than these existing solutions, and it isn't clear to me that it is a good idea to throw out those solutions. Stretchy glyphs are one example. You can do basic maths with CSS, sure. It's the high-end typography that's the problem. Yes, but [...] I was asked for examples of what your proposal couldn't do. I was just providing examples. I'm glad you agree that your solution can't do everything that MathML (for instance) can do. Given that canvas has been implemented in IE6, I have no worries that an HTML-based Math markup language based on MathML (and creating a MathML DOM) could be implemented in IE6 as well, if someone wanted to do so. Thus no one wanted to do so? We haven't specced out such a solution yet. I was just pointing out that the solution of putting MathML into HTML5 was not incompatible with the requirements of HTML5 working in IE6. However, integrating MathML into text/html would make this imminently possible, since it would allow one to write a text/html-to-XML converter that actually took HTML5 markup with Maths, and turned it into native XHTML with MathML, etc. If this is called gradual transition then in the same manner you can gradually switch from LaTeX, ISO 12083 amnd anything else to XHTML. Just write convertor. The difference is that HTML5-with-MathML and XHTML5-with-MathML would have the identical same DOM, same rendering, same everything. Only the serialisation is different. It actually would be true MathML, just with a (slightly) different syntax. A LaTeX-to-XHTML convertor would not have that property. In any case this is a straw man; as I pointed out, it is no longer clear that the requirement in question stands. In
Re: [whatwg] Mathematics in HTML5
On Mon, 19 Jun 2006 14:20:25 +0700, Ian Hickson [EMAIL PROTECTED] wrote: Assuming that the people involved value their time at an average of $10 per hour, that's 3179 man-hours at $10 each, so $31,790 per element name. Just wanted to point out: your calculations don't scale when a batch of new element names are added at one time. Many of the components in your calculations will occur only once. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Mathematics in HTML5
On 17 Jun 2006, at 2:15PM, White Lynx wrote: Oistein E. Andersen wrote: The current proposal does not seem to include the following elements of ISO-12083: - fence with arbitrary delimiters (possibly not a good idea) Probably it is better to list number of delimiters explicitly like in LaTeX. Yes, probably. - labelled arrows [...] 'over' and 'under' elements can be used to put label above or below the arrow (also it will not stretch arrow). Do you mean that ISO-12083 labelled arrows are not supposed to stretch? - spacing (intended to be handled without explicit mark-up) How? Sorry, I meant without introducing new _elements_. -- Ãistein E. Andersen
Re: [whatwg] Mathematics in HTML5
Oistein E. Andersen wrote: - labelled arrows [...] 'over' and 'under' elements can be used to put label above or below the arrow (also it will not stretch arrow). Do you mean that ISO-12083 labelled arrows are not supposed to stretch? They are supposed to stretch, this is part of more general (hard to reproduce in CSS) stretching mechanism provided via id, sizeid attributes. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Anne van Kesteren wrote:
Quoting [EMAIL PROTECTED]:
Since MathML does not fit into the WHATWG philosophy, I would
aknowledge information about your own solution to the problem of
mathematical markup on the web.
Oh please, cut the crap. Did you miss the message from Ian saying how
it could integrate?
If by integrate you mean integrate, then yes I did miss it. Please
could you cite it for I can learn from.
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-June/006518.html
has most of the details. It's dicussed in related messages from him as
well. Not too hard to find if you look in the archives...
(I was referring to your usage of fit when saying integrate...)
On that case you would be able to find why I cannot agree with Ian proposal.
--- Resume ---
1) One recovers all difficulties and errors of MathML desing.
2) One recovers a CSS, DOM, and even XML unfriendly markup language.
3) The main official guidelines of the WHATWG are violated.
4) Ian specific proposal is MathML incompatible and probably would add a
exponential difficulty to realistic implementation in browsers than
original MathML has been. Just for illustration let me do some
annotations:
What when 1 is not mn1/mn?
What about 0xFFEF, MCMLXIX, and twenty one? are parsed to numbers or not?
What when + or = are not operators?
How would mrowd x/mrow be parsed? And mrowdx/mrow and mrowD
x/mrow?
How is the problem of entities solved?
How is 3,14 parsed? And 3 , 14? And 3, 14?
How is supposed that we encode \dot{q} in Ian proposal?
How is parsed the string maps to?
msqrt- 1/msqrt
and
msqrtmrow- 1/mrow/msqrt
are to be treated as equivalent or no?
- 1 and -1 are equivalent or no?
What about mrowa b/mrow and mrowa mib/mi/mrow? And
mrowamib/mi/mrow?
How would one deal with T vs. nbsp;T?
Ian said Maybe we could imply one of [#x2062;] between pairs of terms in
mrows that don't have any mos. Then would mrowL rho;/mrow work
as mrowL #x2062; rho;/mrow?
and mrow 5 /mrow? Equivalent to mn5/mn or to mrowmn5/mn/mrow?
Anne van Kesteren wrote:
Quoting White Lynx [EMAIL PROTECTED]:
Web application technologies SHOULD BE BASED ON technologies
authors are familiar with,
including HTML, CSS, DOM, AND JAVASCRIPT
As it would work with that, it's not really a problem.
Basic Web application features SHOULD BE IMPLEMENTABLE using
behaviors, scripting, and style sheets IN IE6 TODAY
I guess that's possible.
No if choosing MathML or HTML-MathML (special parsing mode) for the spec.
Microsoft rejected native support for MathML even if initially they
claimed that were interested in native support of, at least,
presentational markup. I find logical that they will reject HTML-MathML
also.
The core features of an XML vocabulary should require the use of
elements from ONLY ONE NAMESPACE.
Is math really a core feature?
That could be debated. My own reply is affirmative. Some countries
consider that language (aka HTML text) and math (aka HTML math) are two
basic stuff may be learned in the classroom even until 16 old.
You can also count number of times mathematical equations, generic
graphics, sound, and text are used in Wikipedia enciclopedia. You can
notice that mathematics is a very popular stuff in the educative articles.
I think that core order would be text, graphics, math. Text is well-served
by HTML text, graphics are already covered by canvas, math would be next
step.
IT IS VERY IMPORTANT that authors BE ABLE TO MOVE FROM AN HTML
ENVIRONMENT TO A CLEAN COMPOUND DOCUMENT ENVIRONMENT (typically first
simply bymoving to XHTML) IN A GRADUAL FASHION.
That seems to be what Ian is proposing (for math), more or less.
I disagree!
csup2/sup --- msupc 2/msup --- msupmic/mimn 2/mn/msup.
is not a gradual migration path, is it?
George and others proposal (and variations discussed)
csup2/sup --- csup2/sup
is cheap, WHATWG fully compliant, and introduces a gradual migration path
for _both_ developers and authors.
Juan R.
Center for CANONICAL |SCIENCE)
Re: [whatwg] Mathematics in HTML5
James Graham wrote: That's a really particular use case which is hardly representative of the web as a whole. As sad as it is, 99.9% of authors have no use for maths (otherwise all these problems would have been solved long ago). Maths is certainly less of a core feature for most authors than vector graphics and WHATWG aren't trying to re-implement SVG despite the fact that it too has no obvious IE6 compatibility story, poor CSS integration and various other problems. I doubt of veracity of your percentage. Any reference? And your arguments sound contradictory. Have you noted that w3c attempted to develop mathematical markup already in the HTML3 draft, that was a lot of time before SVG or any other vectorial graphics approach. And do not forget the duality SVG === Canvas MathML === HTML5-Math Nowhere in the WHATWG document does it say that they're going to try and fix everything. Strictly speaking it does not say the contrary, and does not say one would reuse MathML. You have to choose your battles and, personally, I agree with the idea that, if the proponents of CSS-based maths want to work in the structure of the WHATWG, they should demonstrate the feasibility of their approach using a microformat. Given the constraints under which they have chosen to operate it should be possible to do this without any difficulties. The microformat based approach has several advantages too, e.g. instant implementation in existing HTML4 UAs (a new markup language would require changes to the parser). This should allow the language to evolve as it encounters real-world needs so, if and when it is formally standardized, it will be a better product than typically results from an standardization-before-implementation approach. Many times it was said that there is not need for microformats. If microformats are so good why the need for HTML5? [http://www.xml.com/lpt/a/2006/04/26/microformats-grddl-rdfa-nvdl.html] [http://www.xml.com/lpt/a/2005/10/19/microformats-and-web-2.0.html] Why a calendar control, address card, and all that stuff in HTML5? Why do not just reusing available microformats on standard HTML4 or XHTML1 without new added elements? You argue that language can contain initial errors so one would be forced to evolutionate the language when was applied to real problems. Of course! But this is true in any case! Precisely, XHTML2 introduces certain backward incompatibility because errors done in the past, somewhat as XML 1.1 introduces also. MathML is backward incompatible with original HTML 3 Math draft. If the points about errors matters would not the full HTML5 be implemented in an experimental fashion until was completely fine-tunned after of years of usage. What about canvas, why was so early implemented in browsers without years of experimental usage on the web? I can see some people considering lack of strong support for textual content in canvas one of the big flaws of the spec. About your comment on changes in parsers, well, I thought that anyone in this list was warned that HTML5 will need of changes in parsers!! Any case the changes introduced by George proposal are minimal when compared with changes of a text/html version of p-MathML or of Ians proposal. Juan R. Center for CANONICAL |SCIENCE)
Re: [whatwg] Mathematics in HTML5
Ian Hickson wrote: On Mon, 12 Jun 2006 [EMAIL PROTECTED] wrote: WHATWG doesn't have a position on this -- different contributors have different opinions, and no clear consensus is being reached as far as I can tell. It has been taken one! The draft of the specification recommends the usage of MathML for mathematics. Hm, good point. This wasn't particularly intentional. Fixed. Ok, people would freely choose languages in function of strengs and weakness. XML-MAIDEN, MathML, OpenMath, and others would compete in an equal footing (my experience is many people think that MathML is the _only_ approach to mathematical markup). MathML violates the official possition because is not based in reusing backward compatibility with HTML + CSS + DOM. MathML works fine with DOM, and it would be just as possible to convert MathML to SVG as it would to convert anything else to SVG (as you suggest below). Others do not agree on works fine. I personally see MathML-DOM like a DOM correction to the errors done in MathML markup (somewhat as MathML1-style was a correction to the mistake of ignoring available CSS language; error has been partially solved in MathML 2.0). Take the case of somewhat as fracnuma/numdenb/den/frac and subformH/subformsupT/sup (and variants). Both encodings are DOM compliant and can be accessed and manipulated via the standard DOM methods browsers already incorporate. Take now MathML versions: mfracmia/mimib/mi/mfrac and msupmiH/mimiT/mi/msup. Those encodings are not DOM friendly, obligating to introduce special MathML-DOM for accessing, for instance, to the base (H) of the script structure. However, I can access to H using the *same* standard DOM methods I am using for accessing any other HTML or XHTML markup e.g. the experimental pop-up navigation menu on the still experimental canonicalscience site- when I use the alternative encoding is being discussed here. I am not a specialist on DOM implementations, but I know that MathML-DOM model introduces special problems to browsers developers due to the extension mechanism chosen (by inheritance). Problems are *avoided* using a markup as that proposed by George and others which needs of no special DOM. As claimed many times in several places in the internet: w3c MathML WG reinvented the wheel and did it square. Moreover, still 2/3 of above summation hold. Posibility for conversion to SVG does p-MathML completely unnecesary (but not for c-MathML or HTML5-Math). In that case, I doubt that p-MathML was supported anymore in future. It appears to me a closed road. iii) I am reading many people interested in native support for mathematics in HTML5. Certainly. The question is how. There have been several proposals. My recommendation to those who think it is possible to re-use CSS to get an acceptable level of Math support would be to go through the Microformats process to prove the case. See my comments on why not microformats and the two links revieving microformats. It doesn't make sense to bless a dozen new tags (or more) to be in the HTML namespace (and thus with us for all time!) without first proving that yes, that approach is good enough for mathematicians and scientists. And what better way do you know that providing a mathematical markup on the final WHATWG draft? Mathematicians and scientists and rest of people using math (enginneers, students, physicians...) could read the draft and accept or reject it. You would only waste a bit of time writing and adding one or two new sections to the current draft of the spec. Some people here has done a public plea for mathematical markup using (at least the most part of) George original proposal. They did not a plea for development of a microformat. However, i do not remember of some example that was correctly encoded in p-MathML with current tools and correctly rendered via browsers cannot be encoded via George CSS approach. Stretchy glyphs are one example. You can do basic maths with CSS, sure. It's the high-end typography that's the problem. Sorry, but I cannot agree. In real practice, I do not know of a single example of MathML you can find at NAG, at Distler blog on string theory, at journals of math or on Living reviews on relativity (between others) containing mathematics cannot be rendered via CSS. And I would not call basic math to that on Living reviews on relativity or Distler MUSINGS. It is more, I am updating a serie of snapshots obtained with my Firefox browser when rendering MathML and the browsers fails in several cases with strectchy glyphs. Yes, some examples are passed when dowloading and installing special fonts, but that is not a sane practice. However, I know many examples of formulae (in physical and mathematical sites) are encoded via MathML 2.0 and both structure and the visual renderings are poor than using CSS (even if special CM and math fonts are installed in the machine): differentials, integrals, basic chemical
Re: [whatwg] Mathematics in HTML5
James Graham wrote: Except that XML will not work with HTML4. XML = SVG therefore Except that SVG will not work with HTML4. [http://www.carto.net/papers/svg/samples/svg_html.shtml] [http://www.december.com/html/tech/svg.html] [http://www.december.com/html/demo/hellosvg.html] One of the big difficulties with MathML is that XML is /too hard/ for authors. That's why WHATWG has spent so much effort designing a backwards-compatible HTML parsing algorithm with predefined error handling - because authors cannot migrate to XML based solutions. That is not the main reason of lack of popularity of MathML. Forcing authoring of MathML in HTML will continue with current unpleasant situation for mathematical and scientific content. However it matters for usability, readability and authoring purposes. Indeed. If you require documents to be well formed XML authors will not use your technology. How authors could avoid well-formed MathML fragments when authoring from HTML? Would none be valid code in HTML5 or still XML rules matter and authors will be write none/ with independence of host language? So sending us to microformats.org is basically saying that it is not worth to allocate separate element names for maths. At this point I would certainly agree with that sentiment, at least at present. I would certainly change my mind in the future, if you could demonstrate high quality typesetting of mathematics with a range broad enough to satisfy professional mathematicians. This is odd. 1) It has been proven that via Standard CSS 2.1 not designed for math one can render math better than browsers with native support (as Firefox 1.0) and infinitely better than MSIE, Safari, and Opera (rendering natively zero mathml). 2) Mathematics is not a niche exclusive for professional mathematicians. That is reason of the lack of popularity of TeX and amstex. In chemistry, most part of the comunity does not use TeX or LaTeX, and even physical chemists usually do not work with TeX for typesseting of mathematical formulae. Most of scientists in biology, geology, environmental sciences, enginnering, feel confortable with MSWord typesseting. 3) HTML was designed for high-quality typesetting of nothing: text, math, chemistry, graphics, etc. The web is not about high quality typesetting is about electronic communication and dinamical content. MathML and OpenMath were not designed for high-quality typesetting. Not even XML or SGML were designed for high-quality typesetting (XSL-FO even is not designed for that). Usual practice in MathML for instance is previous transformation to TeX before printing. That's not a convincing case for putting everything in HTML5 today - it's much easier to pick up new ideas later once they have some proven success than it is to drop stillborn markup which was believed to be good at the time but failed to solve real world problems. A microformat for HTML 4 (and even your own XML dialect in its own namespace for XHTML) seem like the ideal solution as it allows you to develop a standard but does not add dozens elements from an unproven technology to HTML 5. This philosophy was not applied to the rest of HTML5 spec, no? Ian Hickson wrote: On Sun, 18 Jun 2006, White Lynx wrote: Do you pay any fee for registered element names? ;) Yes. It takes a couple of engineers to implement a new tag, typically, and probably on average takes them about a week (forty hours). (Some tags take months and many engineers, some take minutes for one engineer.) It takes about a week also for a QA person to write tests for a new element, then another week or two over the next few years to handle bugs in that element (again, on average). Let's say a hundred hours. Documentation probably takes about three days (twenty four hours). So that's an average time of 204 man-hours per browser. There are at least ten browsers in active development, probably more. So that's 2040 hours. It takes about ten to twenty hours for a spec editor to write the spec, plus an hour for people to review it. Let's be pessimistic and say that a hundred people review the spec (for something like HTML, it's probably in the thousands really). That's a total time of about 115 man-hours for the spec. It probably takes a dozen people about an hour each to report on the new element, plus about another dozen people about an hour to write a tutorial for the feature, assuming it's a simple feature. 24 man-hours. Finally, it takes Web developers a few minutes to read about the tag and see if they care or not. Assuming that they don't care (if they do, it'll take them much longer), it probably takes an average of one minute per developer to read the spec or article about the feature. Let's assume that sixty thousand developers look at the feature. That's 1000 man-hours. Assuming that the people involved value their time at an average of $10 per hour, that's 3179 man-hours at $10
Re: [whatwg] Mathematics in HTML5
**What is the goal?**
If I understand James and Ians statements correctly, the play is that
either one provides a perfect markup in less than 12 tags can offer us
dinamical pages with TeX quality for liquid layouts and generic web fonts
(even TeX cannot), was implemented in browsers with zero changes in the
parser =:-0 and was accepted and broadly used by community before was even
introduced in the draft of the spec OR one would implement THE
alternative.
The alternative is p-MathML 2 markup which is DOM unfriendly, CSS and
XSL-FO unfriendly, and even XML or HTML unfriendly:
tag1tag2ccc/tag2/tag1 and tag2ccc/tag2 are not equivalent in
XML or HTML but can be in MathML.
The alternative introduces dozens of presentational markup elements
violating basic web guidelines. The alternative is incomplete and needs of
another several thousand of dozens of tags (c-MathML 2 and OpenMath
extensions) specially if accesibility is a target (and it is by law in
some countries).
The alternative needs of additional DOM and style specific extensions
since available CSS, XSL-FO, and DOM do not fit (really MathML does not
fit in the rest of the web).
The alternative is spreading ugly, structurally incorrect, and inaccesible
code on the web. Take the case of Distler Mussings blog, after several
attempts and a recent correction based in my review now it changed the
way {ds}^2 is encoded, but still the structure and the visual rendering
are wrong: e.g. ds is rendered in italic with small space between d and s
whereas the same ds -but in {ds}^2- is rendered without space and in roman
font.
Yes, the visual rendering of the alternative is, in many ocasions, poor:
certain nested fractions, matrices, and array structures, tensors, some
subsup constructs, predefined MathML entities. Moreover, due to
difficulties for authoring MathML code one can see incorrect renderings on
many MathML code generated by usual MathML tools: HERMES, IteX, ORCCA
translator, MathCast, ASCIIMath, and others. Some of equations contained
in canonicalscience site were corrected by hand after being generated by
popular MathML tools. I would do more fine-tuning of some equations still
remaining incorrect rendering in current version of the site but I decided
stop that nonsense since MathML is not way. I will update lot of examples
(extracted from academic sites where good visual quality is one of first
requisites) in canonical science today blog in near future.
The alternative (the spec) does not specify how one would encode something
so simple as \dot{q} and there was some intense debate about that topic
this year in the w3c MathML list with three main postures: all-Unicode
(minoritary), all-MathML (only Bruce), Unicode+MathML (mayoritary and
probably introduced in next MathML spec). Yes, you read ok, after 10 years
the first w3c attempt to encode mathematics on the web, we were discussing
how a trivial \dot{q} would be encoded just some months ago!!! Mathematica
5.2 visual rendering of the MathML code generated by IteX for \dot{q} was
poor that if hand-drawing by a 5 years babe!!! See MathML list for
details, links, and fragments of code.
The alternative needs of so many efforts on the browsers side that
browsers are ignoring it and even the own w3c editor/browser has a partial
support of p-MathML (c-MathML is ignored by Amaya).
The alternative (using more tags) is not able to encode script structures
could be encoded in ISO-12083 markup model (developed before). Moreover,
the number of tags increases exponentially in MathML for each new script
structures were added in future specs. because of the base interference
problem of MathML incorrect design.
The alternative adds both new parsing and WS rules to those of XML and HTML.
The alternative is formally deficient and it is not rare to see tools
exploiting holes in the w3c specification for generating tricky (nonsense)
code: e.g. msupmrow/mn37/mn/msupmiX/mi when the correct code
is
mmultiscriptsmiX/mimprescripts/mn37/mnnone//mmultiscripts.
Moreover, Ians specific proposal introduces still more additional
(backward incompatible) parsing rules.
And the specific problems with Gecko MathML support: non-incremental
rendering...
I do not see requirements imposed to mathematical markup are being imposed
to MathML not in others parts of the spec: calendars, canvas. Is not the
gauge a bit unbalanced?
**Usage of weak arguments agains MathML alternative**
In this list I have heard.
- CSS approach cannot compete with MathML rendering quality
But I can provide examples of contrary! In fact, I will do in canonical
science today including snapshots of different formulae obtained from real
sites.
- People ask for MathML in HTML5.
People in this list asked for HTML-Math proposal and I think that almost
all participants in this list expressed some disapointment with MathML.
- People is not using MathML because cannot be used in HTML. That is, lack
of interest in MathML is mainly traced to XHTML trouble.
Re: [whatwg] Mathematics in HTML5
James Graham wrote: Is math really a core feature? Yes, absolutely .. the upcoming microlearning / nanolearning units inevitably need math. That's a really particular use case which is hardly representative of the web as a whole. As sad as it is, 99.9% of authors have no use for maths (otherwise all these problems would have been solved long ago). I wouldn't reduce the people from all schools and universities worldwide to only 0.1%. But obviously I have to accept the view -- or better the fact -- that today's web is much more commercial than scientific or educational. Maths is certainly less of a core feature for most authors than vector graphics and WHATWG aren't trying to re-implement SVG despite the fact that it too has no obvious IE6 compatibility story, poor CSS integration and various other problems. I wish, that WHATWG would have a similar motivation to offer lightweight math capabilities parallel to MathML, as they were motivated to support vector graphics via the canvas element parallel to SVG. Nowhere in the WHATWG document does it say that they're going to try and fix everything. Maybe .. You have to choose your battles and, personally, I agree with the idea that, if the proponents of CSS-based maths want to work in the structure of the WHATWG, they should demonstrate the feasibility of their approach using a microformat. Given the constraints under which they have chosen to operate it should be possible to do this without any difficulties. The microformat based approach has several advantages too, e.g. instant implementation in existing HTML4 UAs (a new markup language would require changes to the parser). This should allow the language to evolve as it encounters real-world needs so, if and when it is formally standardized, it will be a better product than typically results from an standardization-before-implementation approach. Assuming the microformat solution will work -- and that it will work is already proven by George's implementation -- why should there be a reason then in one, two, three years to substitute the well working microformats with a new set of math related elements?
Re: [whatwg] Mathematics in HTML5
Quoting Stefan Gössner [EMAIL PROTECTED]: I wish, that WHATWG would have a similar motivation to offer lightweight math capabilities parallel to MathML, as they were motivated to support vector graphics via the canvas element parallel to SVG. OMG. Have you even read what canvas is about? :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Mathematics in HTML5
On Sat, 17 Jun 2006, White Lynx wrote: Basic Web application features SHOULD BE IMPLEMENTABLE using behaviors, scripting, and style sheets IN IE6 TODAY Given that canvas has been implemented in IE6, I have no worries that an HTML-based Math markup language based on MathML (and creating a MathML DOM) could be implemented in IE6 as well, if someone wanted to do so. The core features of an XML vocabulary should require the use of elements from ONLY ONE NAMESPACE. The proposal was to not have namespaces at all (and indeed, not even use XML), so this seems co vered. IT IS VERY IMPORTANT that authors BE ABLE TO MOVE FROM AN HTML ENVIRONMENT TO A CLEAN COMPOUND DOCUMENT ENVIRONMENT (typically first simply by moving to XHTML) IN A GRADUAL FASHION. This was written when my opinion was still that we should be moving to XHTML. I'm not actually sure we want to do that at all these days; most Web developers seem to agree (there's almost no XHTML on the Web). However, integrating MathML into text/html would make this imminently possible, since it would allow one to write a text/html-to-XML converter that actually took HTML5 markup with Maths, and turned it into native XHTML with MathML, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Mathematics in HTML5
On Sat, 17 Jun 2006, James Graham wrote: That's a really particular use case which is hardly representative of the web as a whole. As sad as it is, 99.9% of authors have no use for maths (otherwise all these problems would have been solved long ago). Maths is certainly less of a core feature for most authors than vector graphics and WHATWG aren't trying to re-implement SVG despite the fact that it too has no obvious IE6 compatibility story, poor CSS integration and various other problems. Nowhere in the WHATWG document does it say that they're going to try and fix everything. You have to choose your battles and, personally, I agree with the idea that, if the proponents of CSS-based maths want to work in the structure of the WHATWG, they should demonstrate the feasibility of their approach using a microformat. Given the constraints under which they have chosen to operate it should be possible to do this without any difficulties. The microformat based approach has several advantages too, e.g. instant implementation in existing HTML4 UAs (a new markup language would require changes to the parser). This should allow the language to evolve as it encounters real-world needs so, if and when it is formally standardized, it will be a better product than typically results from an standardization-before-implementation approach. As usual, James has managed to express himself much better than I can. I completely agree with what he writes above. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Mathematics in HTML5
Quoting White Lynx [EMAIL PROTECTED]: Certainly. The question is how. There have been several proposals. My recommendation to those who think it is possible to re-use CSS to get an acceptable level of Math support would be to go through the Microformats process to prove the case. What is the difference between writing style sheet for microformat and writing style sheet for XML based markup? There is no difference. Perhaps you should read up on Microformats. It's not really about writing a style sheet for a bunch of classes associated with elements. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Mathematics in HTML5
Anne van Kesteren wrote: Certainly. The question is how. There have been several proposals. My recommendation to those who think it is possible to re-use CSS to get an acceptable level of Math support would be to go through the Microformats process to prove the case. What is the difference between writing style sheet for microformat and writing style sheet for XML based markup? There is no difference. Perhaps you should read up on Microformats. I don't think so. For me XHTML + XML makes more sense then HTML overloaded with (or overspecified through) microformats. It's not really about writing a style sheet for a bunch of classes associated with elements. I meant for the purpose to prove the case there is no difference what one will use (microformat or XML). -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
White Lynx wrote: James Graham wrote: You have to choose your battles and, personally, I agree with the idea that, if the proponents of CSS-based maths want to work in the structure of the WHATWG, they should demonstrate the feasibility of their approach using a microformat. Given the constraints under which they have chosen to operate it should be possible to do this without any difficulties. As I already said several times, when it comes to rendering maths with CSS, there are no real difference between HTML based microformat and XML application. Except that XML will not work with HTML4. One of the big difficulties with MathML is that XML is /too hard/ for authors. That's why WHATWG has spent so much effort designing a backwards-compatible HTML parsing algorithm with predefined error handling - because authors cannot migrate to XML based solutions. Whether fraction will be marked as span class=fractionspan class=numnumerator/spanspan class=dendenominator/span/span or fractionnumnumerator/numdendenominator/den/fraction does not matter for the purpose of further rendering with CSS. Which is why the microformat approach will work. However it matters for usability, readability and authoring purposes. Indeed. If you require documents to be well formed XML authors will not use your technology. Of course there is no difficulty in producing a tool that takes an XML tree as input and outputs a microformats-style HTML4 tree with the same meaning, if you believe that this will be easier for authors. So sending us to microformats.org is basically saying that it is not worth to allocate separate element names for maths. At this point I would certainly agree with that sentiment, at least at present. I would certainly change my mind in the future, if you could demonstrate high quality typesetting of mathematics with a range broad enough to satisfy professional mathematicians. This should allow the language to evolve as it encounters real-world needs so, if and when it is formally standardized, it will be a better product than typically results from an standardization-before-implementation approach. We prefer parallel process, so what we propose to standardize today can be consistently rendered today in browsers, later when it will be realistic to add more features they will be gradually added. That's not a convincing case for putting everything in HTML5 today - it's much easier to pick up new ideas later once they have some proven success than it is to drop stillborn markup which was believed to be good at the time but failed to solve real world problems. A microformat for HTML 4 (and even your own XML dialect in its own namespace for XHTML) seem like the ideal solution as it allows you to develop a standard but does not add dozens elements from an unproven technology to HTML 5.
Re: [whatwg] Mathematics in HTML5
James Graham wrote: You have to choose your battles and, personally, I agree with the idea that, if the proponents of CSS-based maths want to work in the structure of the WHATWG, they should demonstrate the feasibility of their approach using a microformat. Given the constraints under which they have chosen to operate it should be possible to do this without any difficulties. As I already said several times, when it comes to rendering maths with CSS, there are no real difference between HTML based microformat and XML application. Whether fraction will be marked as span class=fractionspan class=numnumerator/spanspan class=dendenominator/span/span or fractionnumnumerator/numdendenominator/den/fraction does not matter for the purpose of further rendering with CSS. However it matters for usability, readability and authoring purposes. So sending us to microformats.org is basically saying that it is not worth to allocate separate element names for maths. The microformat based approach has several advantages too, e.g. instant implementation in existing HTML4 UAs (a new markup language would require changes to the parser). We don't have much problems on parser side. All existing UAs that have strong CSS support, have XML support too. This should allow the language to evolve as it encounters real-world needs so, if and when it is formally standardized, it will be a better product than typically results from an standardization-before-implementation approach. We prefer parallel process, so what we propose to standardize today can be consistently rendered today in browsers, later when it will be realistic to add more features they will be gradually added. We need standardization that stimulates implementations and recognizes right of math community to have presence on web, not standardization for the sake of standardization. Nor we need separate getto which is not integrated with the rest of web standards. Isolating mathematical markup from the rest of standards was wrong step that brought many problems to MathML community. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Ian Hickson wrote: Certainly. The question is how. There have been several proposals. My recommendation to those who think it is possible to re-use CSS to get an acceptable level of Math support would be to go through the Microformats process to prove the case. What is the difference between writing style sheet for microformat and writing style sheet for XML based markup? There is no difference. It doesn't make sense to bless a dozen new tags (or more) to be in the HTML namespace (and thus with us for all time!) Do you pay any fee for registered element names? ;) without first proving that yes, that approach is good enough for mathematicians and scientists. Is lack of mathematical markup in HTML good enough for mathematicians and scientists? After many years there is no consensus in math community on issues whether ISO 12083 is good enough, whether MathML is good enough, whether LaTeX is good enough for web, whether SGML/DSSSL approach was good enough etc. Stretchy glyphs are one example. You can do basic maths with CSS, sure. It's the high-end typography that's the problem. Yes, but when p element was included in HTML no one claimed that it is useless or wrong just beacuse browsers did not support (and do not support today) hyphenation. Structural markup is not responsible for typographical issues. We use HTML without automated hyphenation, vertical text, ruby, combining diacritical marks, advanced text justification, multicolumn printing, automated page numbering, automated resolution of cross references and many other for some subtle and for some people important typographical features. What if before standardizing HTML one would wait until all this issues would be perfectly addressed? We would have no HTML at all. Inspite of the lack of typographical quality HTML played important role in organizing data and providing structural markup, without this we would have just bunch of PDF files instead of current web. Situation on math part is very similar, some people claim that markup is useless because some subtle typographical feature is missing (again, markup is not responsible for formatting quality), we have no structural markup, scientific web is turned into bunch of PDF, PS, DJVU, DVI and other format that miss structural level, data is not organized. Note that the proposal to have Math in HTML in a way that can be rendered using CSS is also a kind of presentational Math and not a pure-semantic Math, so arguing that we shouldn't use p-MathML because it isn't semantic would not be consistent with arguing we should be purely CSS-compatible. Agree. Current proposal (like ISO 12083, AAP Math DTD, LaTeX) just captures basic structure of math formulae in the way suitable for further formatting, processing etc. It is about organizing and structuring formulae rather then encoding meaning which is separate task that would be handled through content oriented attributes (approptriate semantic vocabulary will be developed separately from current proposal, as it is complex issue that is orthogonal to current markup and is not relevan for rendering mathematics in browsers). Given that canvas has been implemented in IE6, I have no worries that an HTML-based Math markup language based on MathML (and creating a MathML DOM) could be implemented in IE6 as well, if someone wanted to do so. Thus no one wanted to do so? IT IS VERY IMPORTANT that authors BE ABLE TO MOVE FROM AN HTML ENVIRONMENT TO A CLEAN COMPOUND DOCUMENT ENVIRONMENT (typically first simply by moving to XHTML) IN A GRADUAL FASHION. This was written when my opinion was still that we should be moving to XHTML. I'm not actually sure we want to do that at all these days; most Web developers seem to agree (there's almost no XHTML on the Web). However, integrating MathML into text/html would make this imminently possible, since it would allow one to write a text/html-to-XML converter that actually took HTML5 markup with Maths, and turned it into native XHTML with MathML, etc. If this is called gradual transition then in the same manner you can gradually switch from LaTeX, ISO 12083 amnd anything else to XHTML. Just write convertor. That's a really particular use case which is hardly representative of the web as a whole. As sad as it is, 99.9% of authors have no use for maths (otherwise all these problems would have been solved long ago). Maths is certainly less of a core feature for most authors than vector graphics and WHATWG aren't trying to re-implement SVG despite the fact that it too has no obvious IE6 compatibility story, poor CSS integration and various other problems. Nowhere in the WHATWG document does it say that they're going to try and fix everything. You have to choose your battles and, personally, I agree with the idea that, if the proponents of CSS-based maths want to work in the structure of the WHATWG, they
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: Yes, sub/sup will behave like HTML sub/sup with offsets being based on font size like it is currently done in HTML implementations, while llim/ulim and marker/submark will have offsets based on size of their base (operator, fence, matrix etc.) not font size like in case of HTML sub/sup elements. Am I right to say than an exponent made with sup following a fence of a undefined height cannot be aligned correctly vertically? Yes, sup/sub will work like in HTML. This behavior is not perfect in case of resizable operators, fences, matrices and vectors however in this cases operator limits (llim/ulim) and fence markers (marker/submark) provide necessary functionality. Could the same thing be said when sup is preceded by a matrix? Yes, fence markers (marker/submark) will be aligned near top or bottom edge of matrix's fence, while sub/sup will be backward compatible with HTML and will apply to PCDATA base only, like in HTML. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
James Graham wrote: So how does it fit in the scope of fundamental principles upon which the WHAT working group intends to operate? http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html I don't see anything contradictory there Web application technologies SHOULD BE BASED ON technologies authors are familiar with, including HTML, CSS, DOM, AND JAVASCRIPT Basic Web application features SHOULD BE IMPLEMENTABLE using behaviors, scripting, and style sheets IN IE6 TODAY Any solution that CANNOT BE USED with the current high-market-share user agent WITHOUT THE NEED FOR BINARY PLUG-INS is highly unlikely to be successful The core features of an XML vocabulary should require the use of elements from ONLY ONE NAMESPACE. IT IS VERY IMPORTANT that authors BE ABLE TO MOVE FROM AN HTML ENVIRONMENT TO A CLEAN COMPOUND DOCUMENT ENVIRONMENT (typically first simply by moving to XHTML) IN A GRADUAL FASHION. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
On 16 Jun 2006, at 2:27PM, White Lynx wrote: Oistein E. Andersen wrote: The proposal states that op should be used to mark resizable operators, but this presumably does not mean that the size of such operators is actually intended to change. It is intended to be larger. Yes, but the size is not intended to vary as a function of what follow the operator, is it? Since delimiters are not supposed to change meaning (matrix is matrix) issue is left up to style sheets. But if necessary appropriate attributes may be added to indicate delimiters explicitly, as you suggested. [matrix, det, vector = generalised matrix?] This returns us to concept of ISO 12083 arrays. It makes sense, I just thought that more specific markup would be viable, but if necessary we can return to arrays. Column vectors and perhaps even binomial coefficients can be regarded as a special kind of matrices; still, it is not necessarily a bad idea to provide specific mark-up for these. My main concern is that we should not make arbitrary limitations. Sometimes, different vector-like entities are actually distinguished by their delimiters, as are e.g. a matrix, a determinant and a matrix norm. Some of ISO-12083 constructs that can not be encoded in MathML either. Some of which probably should be added to MathML, but that is another issue. font-family:[cursive] seems like a natural fallback mechanism for script. Ok. But are Fraktur and caligraphic fonts actually marked as such? How browser will identify them? As far as I know, no standard mechanism exists to indicate font classification. It is up to the browser to find (or let the user choose) appropriate fonts to use for general font-families like serif and cursive. I tend to believe that a few `unsupported' constructions should be included anyway if this is necessary in order to cover ISO-12083 (or whatever standard [...] might be chosen). I would prefer not to include them explicitly. For example ISO-12083 allows any character as delimiter but of course not any charcater makes sense and not any characters is stretched by ISO 12083 implementations. That is a good point. Without any restrictions, the only possible complete implementation would probably be one that deforms the characters used as delimiters in order that they fit into a rectangular shape of a pre-defined ratio. And if we limit the choice, the problem is to avoid `unnecessary' limitations. The current proposal does not seem to include the following elements of ISO-12083: - overline and undrline [sic] (could be useful - feasible in CSS?) - fence with arbitrary delimiters (possibly not a good idea) - box (unnecessary?) - labelled arrows subform (what is this?) - spacing (intended to be handled without explicit mark-up) - character transformation _elements_ (fonts intended to be handled via Unicode or CSS) A few other constructs have been omitted or modified, but without loss of expressive power, e.g. post is probably better encoded as fence with one empty delimiter as this allows the correct size to be found. Is anything else missing? How well does presentational MathML cover ISO-12083? -- Andersen
Re: [whatwg] Mathematics in HTML5
Le 17 juin 2006 à 7:01, White Lynx a écrit :
Yes, sup/sub will work like in HTML. This behavior is not perfect
in case
of resizable operators, fences, matrices and vectors however in
this cases operator limits (llim/ulim) and fence markers (marker/
submark) provide necessary functionality.
That's what I thought. I'm not sure I like the idea of expressing
exponents using either sup or ulim depending on what's preceding
it. So I thought I could suggest something else.
The goal of fence is to have resizable fence delimiters around an
expression. What makes fence so difficult to implement (hence the
abstract fenced element) is that it must support any arbitrary
height. But even with the help of fenced a big problem remains:
with current CSS capabilities, it is difficult to display arbitrary
sized parenthesis or braces, or anything requiring more than what can
be implemented using CSS borders.
I think all of this can be solved with one tiny change of paradigm.
Instead of having fence decide itself of its size (which doesn't
work with all kind of delimiters anyway), we could let the author
decide of the delemiter's size around fence. If we had a size
attribute, or something like that, with a list of predefined sizes
for for fence, authors could choose the appropriate size according
to the content. Different CSS rules could decide what to do for each
size:
fence size=medium.../fence
fence[size=medium]::before {
content: url(open-medium-parenthesis.png);
}
fence[size=medium]::after {
content: url(close-medium-parenthesis.png);
}
And, to return to my first point, elements following fence (like
sup) could be aligned according to the fence's size:
fence size=medium.../fencesup2/sup
fence[size=medium] + sup {
vertical-align: 5em;
}
Fence markers could be implemented in a similar way, and then you
would no longer need a fenced element.
All this remains to be tested. I'm not sure it will work that well
with text zoom for instance. But it could simplify the markup as well
as it would solve the resizable delimiters problem. I know it's not
ideal, but it could be a workable solution for current browsers. The
manual sizing restriction could be waived one day if CSS capabilities
improve.
It doesn't solve the thing for matrix though.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Oistein E. Andersen wrote: The proposal states that op should be used to mark resizable operators, but this presumably does not mean that the size of such operators is actually intended to change. It is intended to be larger. Yes, but the size is not intended to vary as a function of what follow the operator, is it? I would prefer to leave this issue up to style sheets, both kinds of behaviour make sense, so it is the matter of taste. Since delimiters are not supposed to change meaning (matrix is matrix) issue is left up to style sheets. But if necessary appropriate attributes may be added to indicate delimiters explicitly, as you suggested. [matrix, det, vector = generalised matrix?] This returns us to concept of ISO 12083 arrays. It makes sense, I just thought that more specific markup would be viable, but if necessary we can return to arrays. Column vectors and perhaps even binomial coefficients can be regarded as a special kind of matrices; still, it is not necessarily a bad idea to provide specific mark-up for these. My main concern is that we should not make arbitrary limitations. Sometimes, different vector-like entities are actually distinguished by their delimiters, as are e.g. a matrix, a determinant and a matrix norm. What if we will keep cases and choose elements as they are and will group matrices, determinats, vectors and similar stuff in one element like matrix or array with some attributes specifying fence styles, like you proposed. I tend to believe that a few `unsupported' constructions should be included anyway if this is necessary in order to cover ISO-12083 (or whatever standard [...] might be chosen). I would prefer not to include them explicitly. For example ISO-12083 allows any character as delimiter but of course not any charcater makes sense and not any characters is stretched by ISO 12083 implementations. That is a good point. Without any restrictions, the only possible complete implementation would probably be one that deforms the characters used as delimiters in order that they fit into a rectangular shape of a pre-defined ratio. And if we limit the choice, the problem is to avoid `unnecessary' limitations. Elsevier Math DTD limited choice to number of predefined values, in LaTeX number of stretchy delimiters is also finite, so listing them explicitly makes sense. The current proposal does not seem to include the following elements of ISO-12083: - overline and undrline [sic] (could be useful - feasible in CSS?) Right, they have to be included, originally I expected to rely on appropriate HTML elements, but we lack overline in HTML so it has to be added to math proposal. - fence with arbitrary delimiters (possibly not a good idea) Probably it is better to list number of delimiters explicitly like in LaTeX. - box (unnecessary?) It can be added, if necessary. Functionality can be provided via CSS in any case, with or without box element. - labelled arrows subform (what is this?) 'over' and 'under' elements can be used to put label above or below the arrow (also it will not stretch arrow). 'subform' is general purpose container like HTML 'span' used to group math expressions. - spacing (intended to be handled without explicit mark-up) How? - character transformation _elements_ (fonts intended to be handled via Unicode or CSS) 'i', 'b', 'tt' are in HTML, the rest can be achived via CSS. A few other constructs have been omitted or modified, but without loss of expressive power, e.g. post is probably better encoded as fence with one empty delimiter as this allows the correct size to be found. Yes, post was merged with fence in one element. Is anything else missing? 1. Secondary alignment (mark, markref) 2. Smart resizing of subexpressions with id, sizeid attributes 3. Embellishments model is not fully reproduced 4. Overlapping under/over lines (they are rarely used and mostly can be reproduced by using several under/over lines piecewise). How well does presentational MathML cover ISO-12083? Shortages are similar to those listed above. The following things from ISO 12083 are not fully reproduced in MathML 1. Secondary alignment (mark, markref) In MathML there are attributes like malignmark that are used for alignment within mtable and are not sufficient to reproduce ISO 12083 functionality. 2. Smart resizing of subexpressions with id, sizeid attributes This functionality is not available in MathML 3. Embellishments model is not fully reproduced Thing like subformBase/subformtopover/topbottomunder/bottomsupsuper/supsubsub/sub can not be correctly expressed in MathML. In particular msubsupmunderovermiBase/mimiunder/mimiover/mi/munderovermisub/mimisuper/mi/msubsup is rather subformsubformBase/subformtopover/topbottomunder/bottom/subformsupsuper/supsubsub/sub while
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote:
Yes, sup/sub will work like in HTML. This behavior is not perfect
in case
of resizable operators, fences, matrices and vectors however in
this cases operator limits (llim/ulim) and fence markers (marker/
submark) provide necessary functionality.
That's what I thought. I'm not sure I like the idea of expressing
exponents using either sup or ulim depending on what's preceding
it.
Nor do I. I would prefer ISO 12083 model, but it does not work with CSS.
I think all of this can be solved with one tiny change of paradigm.
Instead of having fence decide itself of its size (which doesn't
work with all kind of delimiters anyway), we could let the author
decide of the delemiter's size around fence. If we had a size
attribute, or something like that, with a list of predefined sizes
for for fence, authors could choose the appropriate size according
to the content.
It makes sense. One can add extra attribute to proposal.
And, to return to my first point, elements following fence (like
sup) could be aligned according to the fence's size:
fence size=medium.../fencesup2/sup
fence[size=medium] + sup {
vertical-align: 5em;
}
Fence markers could be implemented in a similar way, and then you
would no longer need a fenced element.
Adjacent sibling selector will match other things too.
Compare fence size=mediumBase/fencesup2/sup
and fence size=mediumContent/fenceBasesup2/sup.
Therefore you still need extra container like 'fenced'.
It doesn't solve the thing for matrix though.
Yep.
--
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com
Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Anne van Kesteren wrote: Web application technologies SHOULD BE BASED ON technologies authors are familiar with, including HTML, CSS, DOM, AND JAVASCRIPT As it would work with that, it's not really a problem. How it will work with CSS? New parsing rules at least does not improve anything and in reality take maths further from XML+CSS. Basic Web application features SHOULD BE IMPLEMENTABLE using behaviors, scripting, and style sheets IN IE6 TODAY I guess that's possible. Put style sheet, script or whatever you keep in mind on the table. The core features of an XML vocabulary should require the use of elements from ONLY ONE NAMESPACE. Is math really a core feature? Yes. Does it matter if we keep compatibility with existing (deployed) formats in mind? If you introduce extra parsing rules then you break compatibility with existing (mis)deployed format. IT IS VERY IMPORTANT that authors BE ABLE TO MOVE FROM AN HTML ENVIRONMENT TO A CLEAN COMPOUND DOCUMENT ENVIRONMENT (typically first simply by moving to XHTML) IN A GRADUAL FASHION. That seems to be what Ian is proposing (for math), more or less. MathML support is binary, either it is supported natively or you see complete mess in browser. Ian's proposal does not change its nature. What we propopse is gradual transition, with fallback mechanisms that provide basic functinality in existing browsers. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Anne van Kesteren wrote: The core features of an XML vocabulary should require the use of elements from ONLY ONE NAMESPACE. Is math really a core feature? Yes, absolutely .. the upcoming microlearning / nanolearning units inevitably need math.
Re: [whatwg] Mathematics in HTML5
Stefan Gössner wrote: Anne van Kesteren wrote: The core features of an XML vocabulary should require the use of elements from ONLY ONE NAMESPACE. Is math really a core feature? Yes, absolutely .. the upcoming microlearning / nanolearning units inevitably need math. That's a really particular use case which is hardly representative of the web as a whole. As sad as it is, 99.9% of authors have no use for maths (otherwise all these problems would have been solved long ago). Maths is certainly less of a core feature for most authors than vector graphics and WHATWG aren't trying to re-implement SVG despite the fact that it too has no obvious IE6 compatibility story, poor CSS integration and various other problems. Nowhere in the WHATWG document does it say that they're going to try and fix everything. You have to choose your battles and, personally, I agree with the idea that, if the proponents of CSS-based maths want to work in the structure of the WHATWG, they should demonstrate the feasibility of their approach using a microformat. Given the constraints under which they have chosen to operate it should be possible to do this without any difficulties. The microformat based approach has several advantages too, e.g. instant implementation in existing HTML4 UAs (a new markup language would require changes to the parser). This should allow the language to evolve as it encounters real-world needs so, if and when it is formally standardized, it will be a better product than typically results from an standardization-before-implementation approach.
Re: [whatwg] Mathematics in HTML5
Anne van Kesteren wrote: Quoting [EMAIL PROTECTED]: Since MathML does not fit into the WHATWG philosophy, I would aknowledge information about your own solution to the problem of mathematical markup on the web. Oh please, cut the crap. Did you miss the message from Ian saying how it could integrate? If by integrate you mean integrate, then yes I did miss it. Please could you cite it for I can learn from. If by integrate you mean another... well I have heard contradictory things from Ian, therefore, I am not sure, really. Juan R. Center for CANONICAL |SCIENCE)
Re: [whatwg] Mathematics in HTML5
Since MathML does not fit into the WHATWG philosophy, I would aknowledge information about your own solution to the problem of mathematical markup on the web. Oh please, cut the crap. Did you miss the message from Ian saying how it could integrate? If by integrate you mean integrate, then yes I did miss it. Please could you cite it for I can learn from. http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-June/006518.html has most of the details. It's dicussed in related messages from him as well. Not too hard to find if you look in the archives... (I was referring to your usage of fit when saying integrate...) So how does it fit in the scope of fundamental principles upon which the WHAT working group intends to operate? http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
White Lynx wrote: So how does it fit in the scope of fundamental principles upon which the WHAT working group intends to operate? http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html I don't see anything contradictory there (and in any case I'm not sure the document you point to is considered normative e.g. it mentions a byline element which does not appear in current drafts of the HTML5 spec). -- You see stars that clear have been dead for years But the idea just lives on... -- Bright Eyes
Re: [whatwg] Mathematics in HTML5
Le 16 juin 2006 à 9:27, White Lynx a écrit : Yes, sub/sup will behave like HTML sub/sup with offsets being based on font size like it is currently done in HTML implementations, while llim/ulim and marker/submark will have offsets based on size of their base (operator, fence, matrix etc.) not font size like in case of HTML sub/sup elements. Am I right to say than an exponent made with sup following a fence of a undefined height cannot be aligned correctly vertically? Could the same thing be said when sup is preceded by a matrix? Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
James Graham wrote: No it is not. You have demonstrated that CSS can do a mediocre job at simple mathematics. This is not an unimpressive achievement but neither does it suggest that general maths layout based purely on CSS is possible without substantial modifications to CSS itself. Please define mediocre job at simple mathematics and substantial modifications to CSS itself. It would be interesting too your evaluation of the job that p-MathML can do in practice (e.g. IteX outputs on Firefox, MSIE, Safari, and Opera) and comparison of realistic mathematical markup can be done with p-MathML cannot be done in HTML5. By realistic, I mean can be achieved in practice, with current tools and browsers. Since MathML does not fit into the WHATWG philosophy, I would aknowledge information about your own solution to the problem of mathematical markup on the web. Juan R. Center for CANONICAL |SCIENCE)
Re: [whatwg] Mathematics in HTML5
Quoting [EMAIL PROTECTED]: Since MathML does not fit into the WHATWG philosophy, I would aknowledge information about your own solution to the problem of mathematical markup on the web. Oh please, cut the crap. Did you miss the message from Ian saying how it could integrate? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Mathematics in HTML5
Oistein E. Andersen wrote: As a first step, I have tried to transform the TeX code used on Wikipedia (http://en.wikipedia.org/wiki/Help:Formula) into HTML5. This raises some issues, see http://xn--istein-9xa.com/HTML5/WikiTeX.pdf for all the details. I have tried to follow the current proposal, but I have probably misinterpreted a few things. Do correct me! Nice summary. Sorry for late reply, I was travelling. Quotes from Wikipedia TeX in HTML5 http://xn--istein-9xa.com/HTML5/WikiTeX.pdf 2.5 Big operators Remark: Is the following the intended use of under/over and opgrp? Yes. In fact I would be more appropriate to use the same markup for both and control rendering (under/over vs. sub/sup) via style sheets, but since it is impossible to have reasonable markup that admits both presentations (due to limited capabilities of CSS2.1) the only option is to allow both possibilities. Remark: The current proposal requires at least two rows and at least two columns. This makesitimpossibletodefineacolumnmatrixasamatrix(thevectorconstructisprobably meant to handle these), and completely impossible to define a row matrix This requirement can be safely removed, there are no XML or CSS motivated restrictions in this area. Remark: Presumably, the det element is intended to replace matrix here, but the ra- tionale seems unclear. Two kinds of brackets are not su?cient anyway, so the distinction would be purely semantical. Yes, destinction is purely semantical. fence left=solid right=solid matrixrowcellvarx/varcellvary/var rowcellvarz/varcellvarv/var/matrix/fence This will draw second fence around matrix (apart of that which already is part of matrix). If it is necessary to hardcode matrix fence styles in DTD then it would be more appropriate to add couple of attributes to matrix element, like you already proposed: Remark: Matrices tend to be surrounded by brackets of some sort. If technically feasible, it would therefore be convenient to indicate the left and right attributes directly on the matrix element. matrix left=solid right=solidrowcellvarx/varcellvary/var rowcellvarz/varcellvarv/var/matrix matrix fences will be considered as intrinsic part of matrix and will not requre extra fence element. cases varn/var/2,scopeif varn/varis even 3varn/var + 1,scopeif varn/varis odd/cases Should be cases casevarn/var/2,scopeif varn/varis even case3varn/var + 1,scopeif varn/varis odd /cases Remark: Should the scope node be optional? Maybe. Do you have some concrete examples in mind? 3.4 Other constructs ... vectorentryvara/varvarb/varentryvarc/var/vector Remark: Do we really want to mark up this as a vector? Note that vector includes fences. So what you need will probably require extra markup. ... Remark: Should we rather suggest an HTML table here? Either HTML table (in this case table should be allowed inside inline elements) or maybe separate element with inline-table functionality (table is probably better as some things like colspan, rowspan attributes can not be reproduced via XML+CSS). In fact it would be nice to more semantic markup here, but since it is hard to make such a markup comprehensive then maybe it is better to allow tables. The current proposal suggests the introduction of text-transform rules to facilitate the input of MAS characters and make HTML5 usable whilst plane 1 is still not fully imple- mented in browsers. This approach would seem to require 13 rules, and not only 3. The problem with some of them (script, bold script, Fraktur, bold Fraktur, double-struck symbols) is that there is no natural fallback for browsers that does not support plane 1. Others (sans-serif , sans-serif bold , sans-serif slanted, sans-serif bold slanted) can be added. Should they be added as a separate properties, or we should redefine current properties to behave appropriately when combined with font-family:sans-serif; (both make sense)? A font-family for Fraktur should probably be added to CSS anyway, as it would be useful not only for mathematics. Makes sense. On the other hand unlike generic font-families like serif, sans-serif and monospace Fraktur is used for limited number of Unicode characters. Also I am not sure whether Fraktur fonts are marked as such. Remark: The current attributes on the fence element do not permit constructions like ]0, 1/2] Such a constructions can be added to proposal if necessary. Problem: These delimiters /*ed. mainly arrows*/ do not seem to be supported in current proposition. The problem is related to fallback CSS rendering. Remark: Explicit indication of delimiter size not supported One can add values like medium, large, x-large, xx-large to current proposal. Personally I like ISO 12083 sizeid attribute that sets size of fence equal to size of subexpression with id specified by sizeid attribute. It does not work however in
Re: [whatwg] Mathematics in HTML5
Oistein E. Andersen wrote: This issue [font selection] belong to presentational layer and has to be addressed on CSS side (there are no problems on XSL and/or DSSSL side as one can make appropriate transformations). I am not so sure about that. In fact I am not sure either. The difference between bold, italic and script can be just as important as the distinction between base, superscript and subscript. Explicit mark-up is provided in ISO-12083, MathML and TeX, among others, and mathemtical characters (which we would like to use, but cannot -- yet?) have been added to Unicode because of their semantical importance. If the removal of class attributes is supposed to preserve meaning, then it does not seem right to use this very attribute to encode different math alphabets. Yes, one can add special attribute for this purpose. Do you have any concrete propopsal? [classes:] vector or Hilbert-vector [or] ket. I would leave [the choice] to authors until that a generic semantic markup was achieved, proved to be consistent and powerful and then used by authors. With all the different concepts and notational conventions that exist in different scientific fields and mathematical disciplines, no such thing as a generic semantic mark-up is likely to appear any time soon. I tend to believe that you agree. Agree. However those who are interested in generic semantic mark-up will have access to semantic layer of current proposal via set of predefined attributes (currently role and mprofile, extra attributes may be added after consultations with people invloved in projects like OpenMath, CanonML etc.) -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
White Lynx wrote: If this demonstrates that it really is possible to create viable math markup in HTML and have it completely styled in CSS then that would be a good step This step is already made, No it is not. You have demonstrated that CSS can do a mediocre job at simple mathematics. This is not an unimpressive achievement but neither does it suggest that general maths layout based purely on CSS is possible without substantial modifications to CSS itself. -- You see stars that clear have been dead for years But the idea just lives on... -- Bright Eyes
Re: [whatwg] Mathematics in HTML5
?istein E. Andersen wrote: Conversion to MathML is obviously more difficult because the base has to be found and encoded explicitly. Still, I do _not_ say that conversion from TeX to HTML5 will be trivial in all cases. Then we agree. As stated a the beginning of discussion by some, TeX backward compatibility will be maintained so many as was possible. [classes:] vector or Hilbert-vector [or] ket. I would leave [the choice] to authors until that a generic semantic markup was achieved, proved to be consistent and powerful and then used by authors. With all the different concepts and notational conventions that exist in different scientific fields and mathematical disciplines, no such thing as a generic semantic mark-up is likely to appear any time soon. I tend to believe that you agree. I wait to see content markups spreading in a near future, but I think that semantic markup is a dead horse (as AI was decades ago). Still semantic web is main vision of Tim Bray last years (the WHATWG takes a pragmatic approach trying to solve everyday problems). The combination of author-defined classes and CSS styling obviously makes sense in many ways. Still, I am a bit reluctant when it comes to encoding the right font using the class attribute. Perhaps a profile would make it acceptable, as suggested by Michel Fortin. Maybe. Also tag is not usual in French texts. I am afraid I do not understand what you mean. Oops! I did mean tan. Juan R. Center for CANONICAL |SCIENCE)
Re: [whatwg] Mathematics in HTML5
On 10 Jun 2006, at 10:1AM, White Lynx wrote: Oistein E. Andersen wrote: traditional French typographical conventions for mathematics require lowercase variables in italic, but uppercase ones in roman. Do we need extra values like text-transform:french-italic; and french-bold-italic; that would transform lowecase Latin and Greek characters to appropriate slanted mathematical alphanumerical characters and uppercase ones to normal mathematical alphanumerical characters? See [1] (in French) for some examples of French-style mathematics. The problem is more complex, however. French typography traditionally use upright Greek letters ([2] acknowledges this); TeX uses italic lowercase Greek, but upright uppercase Greek by default; today, mathematicians' preferences on this issue diverge. Moreover, the mathematical characters in Unicode cover not only Latin and Greek letters, but also digits. To handle this properly, we would need separate transformation rules for each of the following five sets: uppercase Latin, lowercase Latin, uppercase Greek, lowercase Greek, digits. I currently tend to think that we should rather let the transformation rules apply to all these characters, and simply not use them when they are not needed. By the way, nothing like `mathematical alphanumerical characters' seems to be defined in Unicode, so no transformation should be needed for those. [1] http://omega.enstb.org/yannis/pdf/article-gut99.pdf [2] ftp://tug.ctan.org/pub/tex-archive/fonts/fourier-GUT/doc/latex/fourier/fourier-doc-en.pdf roman as a default is Ok as a first approximation. Roman as default is OK given that italic variables can be marked up easily. (Many mathematicians will obviously reject roman variables.) I think we agree on this point. Script, fraktur and double-struck letters are available as separate Unicode characters, so font-family may not be the best solution for these scripts. A tiny subset is available in the Letterlike Symbols block, but most of them are not. The full set is located in the Mathematical Alphanumeric Symbols block in plane 1, so the problem is exactly the same for these as for italic or bold mathematical characters. Each approach has its problems. Anyway, the specification should probably not try to avoid the issue of font selection. This issue [font selection] belong to presentational layer and has to be addressed on CSS side (there are no problems on XSL and/or DSSSL side as one can make appropriate transformations). I am not so sure about that. The difference between bold, italic and script can be just as important as the distinction between base, superscript and subscript. Explicit mark-up is provided in ISO-12083, MathML and TeX, among others, and mathemtical characters (which we would like to use, but cannot -- yet?) have been added to Unicode because of their semantical importance. If the removal of class attributes is supposed to preserve meaning, then it does not seem right to use this very attribute to encode different math alphabets. -- Andersen
Re: [whatwg] Mathematics in HTML5
On Sat, 10 Jun 2006, White Lynx wrote: Agree. Once conceptual issues will be resolved and WHATWG will clarify its position regarding math markup, we can return to naming conventions and if majority prefer brief element names, ISO 12083 element names will be replaced with shorter ones. WHATWG doesn't have a position on this -- different contributors have different opinions, and no clear consensus is being reached as far as I can tell. Personally I think the best way of demonstrating that no browser-native support is required would be for someone to develop a specification for mathematics markup using the microformats.org principles. If this demonstrates that it really is possible to create viable math markup in HTML and have it completely styled in CSS then that would be a good step forward. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Mathematics in HTML5
[EMAIL PROTECTED] this may be difficult to achieve in practice, because TeX conversors reading TeX sources are unable to provide correct MathML markup for prescripts. Conversion to MathML is obviously more difficult because the base has to be found and encoded explicitly. Still, I do _not_ say that conversion from TeX to HTML5 will be trivial in all cases. [classes:] vector or Hilbert-vector [or] ket. I would leave [the choice] to authors until that a generic semantic markup was achieved, proved to be consistent and powerful and then used by authors. With all the different concepts and notational conventions that exist in different scientific fields and mathematical disciplines, no such thing as a generic semantic mark-up is likely to appear any time soon. I tend to believe that you agree. Font styles would be specified via CSS styles. span class=bold is not defined in HTML text, the font bold property is defined in CSS and you can call it via a CSS rule applied to a class you can define. For example Spanish authors could prefer span class=negrita The combination of author-defined classes and CSS styling obviously makes sense in many ways. Still, I am a bit reluctant when it comes to encoding the right font using the class attribute. Perhaps a profile would make it acceptable, as suggested by Michel Fortin. Also tag is not usual in French texts. I am afraid I do not understand what you mean. -- Andersen
Re: [whatwg] Mathematics in HTML5
Oistein E. Andersen wrote:
each mark-up element must be kept as short as possible.
Some people argue that short element names being misleading and not
intuitive does not actually improve readability, some people like short
element
names as they are more convenient for authoring.
The importance of this convenience should not be underestimated.
After all, we are discussing a hand-authored format (albeit not exclusively
so).
Agree. Once conceptual issues will be resolved and WHATWG will clarify its
position
regarding math markup, we can return to naming conventions and if majority
prefer
brief element names, ISO 12083 element names will be replaced with shorter ones.
Make font selection simple and natural
See Kerning and shape of the glyphs section of current proposal,
it mentions possible CSS extensions, that however are not part of this
proposal
If roman is chosen as default type, all (ordinary) variables will need
mark-up.
Would italic be preferable, and would it be conceivable to make italic the
default for Latin and Greek
characters later on when these CSS extensions might become available?
If so, then everything in roman type must also be marked up to make the code
future proof.
I think roman will be default and once CSS extensions will be available one can
change behaviour via author style sheet (not browser default, for backward
compatibility reasons)
formula, dformula {text-transform:math-italic;}
Is variable mark-up supposed to be compulsory anyway?
I think no.
As an aside, traditional French typographical conventions for mathematics
require lowercase variables
in italic, but uppercase ones in roman.
Interesting detail. Do we need extra values like text-transform:french-italic;
and french-bold-italic;
that would transform lowecase Latin and Greek characters to appropriate slanted
mathematical
alphanumerical characters and uppercase ones to normal mathematical
alphanumerical characters?
What i meant was to use root3of125/root as a shorthand notation for
something
like rootorder3/orderof125/of/root, in which case only
the actual element names differ from the current proposal.
We can revise naming conventrions later. One more problems with roots,
mentioned by Michael Day
in offlist discussion, is that XHTML markup is too awkward. If in HTML radix
and radicand
are optional so in square roots one can omit both
radical81/radical =
radicalradix/radixradicand81/radicand/radical
but in XHTML markup we prefer to avoid any special parsing rules, so in XHTML
radical81/radical !=
radicalradix/radicand81/radicand/radical
The only thing that we can do within XML+CSS framework is to introduce extra
element for
square roots like:
sqrt81/sqrt = radicalradix/radicand81/radicand/radical
I do not think that automatic mixing of roman and italic would be a good
idea at the browser side if one search a rapid cheap implementation fully
compatible with current standards.
That is probably quite right.
Yes, roman as a default is Ok as a first approximation.
Later extra line in author' s style sheet could provide TeX like styling:
formula, dformula {text-transform:math-italic;}
Such a script would certainly not fit everyone's needs and desires.
It could be potentially useful to many, but the language should be such that
hand-authoring be practical -- otherwise, the perfect integration with HTML
will be lost.
Script that sniffs content of all text nodes tends to run slowly. XSLT does
this job faster (but does not work with HTML).
In any case it would be nice to have simple solution like CSS text-transform.
Boldface does not necessarily mean vector, and vectors are not always printed
in bold
type. Presumably, you mean that classes like `vector' need not be defined in
the
specification, that the choice is up to the author, and that a custom CSS
style-sheet can
be used to define the font. (This would require CSS font-families for Fraktur
and double-
struck/blackboard bold.)
Script, fraktur and double-struck letters are available as separate Unicode
characters, so font-family
may not be the best solution for these scripts. In ISO 12083 they were
available as a separate character entities, not elements.
Each approach has its problems. Anyway, the specification should probably not
try to avoid
the issue of font selection.
This issue belong to presentational layer and has to be addressed on CSS side
(there are no problems on XSL and/or DSSSL side as one can make appropriate
transformations).
--
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com
Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
?istein E. Andersen wrote:
root3of125/root was already proposed in HTML Math of 1994 and
rejected because technical issues. Also rejected in ISO12083 math of
1995.
What i meant was to use root3of125/root as a shorthand notation
for something like rootorder3/orderof125/of/root, in which
case only the actual element names differ from the current proposal.
Now understand you, yes it could be like you say or like George say. In
the original HTML 3 Math, the of was the full markup, not a shorthand
and introduced many difficulties doing it. I would recommend the
discussion about names for latter. Now it is more important decide
elements, names and content and parsing modes.
After we could discuss if we prefer root or frac or fraction, etc.
If we would reuse names of TeX or of ISO-12083, etc.
3) Assure compatibility with a reasonable subset of TeX
absence of a model for prescripts is one of most important flaws in
TeX, therefore do not wait that a TeX input can be magically
transformed into HTML 5.
Obviously, it will not be possible to transform any TeX code into HTML
5.
Something like ${}^aB$ could be transformed into an HTML 5 prescript
given the correct rules, but then something like ${}^{342}_4X$ would of
course look different in TeX (probably incorrect) and HTML 5.
Yes, the problems with mathematicians is that many think that TeX is
perfect because offers good typeseting on a piece of paper, but TeX fails
on electronic documents and the web.
Here either you would use some intelligence at the conversor as you claim
[*], either thought to mathematicians that correct markup is using the
HTML5 explicit tag for prescripts or using an modified TeX as that
proposed by George, which already include prescript.
Look that interesting idea George had
http://my.opera.com/White%20Lynx/blog/show.dml/256124
Presubscript:\inf{sub}Base
Instead usual TeX {}_{sub}Base
TeX code for prescripts is tricky and rudely critqued by MathML, TeX or
ISO12083 people.
Similar for presuperscripts
[*] However, this may be difficult to achieve in practice, because TeX
conversors reading TeX sources are unable to provide correct MathML markup
for prescripts.
Many Tex/LaTeX/IteX conversors transform {}_{sub}Base to
msubmrow/misub/mimsubmiBase/mi
which is a complete aberration.
1) There exist a special markup for prescripts in MathML: mprescripts
2) Above MathML code is structurally invalid.
3) Above MathML code is not acesible. Would be incorrectly spoken by an
aural rendered.
4) sometimes visual rendering can be incorrect, because size and position
of subindex is being computed with empty element mrow/ as base and the
real base Base is ignored.
HTML is more verbose than TeX but is less erratic.
That is a fair point.
I think that people can perfectly use
var class=vectorF/var
instead
\mathbf{F}
if you dislike the class attribute, then try something like
varbF/b/var
A few issues still remain to be solved, though:
Boldface does not necessarily mean vector, and vectors are not always
printed in bold type.
I agree!
Presumably, you mean that classes like 'vector'
need not be defined in the specification, that the choice is up to the
author, and that a custom CSS style-sheet can be used to define the
font. (This would require CSS font-families for Fraktur and
double-struck/blackboard bold.)
Yes, because I think that design of a good semantic markup is something
that still has been not achieved even after a decade of effort from the
OpenMath community. If I add semantic content as vector, I would add
others classes also: vector is generic mathematical linear elementary
vector in usual mathematical sense? Covariant? Maybe defined in
tridimensional space, is a vector in a Hilbert space or in a Liouville
space?
Some authors would call vector or Hilbert-vector others would call
ket. Somewhat as I define my own classes in HTML and next use CSS rules
for presentation. I would leave that to authors until that a generic
semantic markup was achieved, proved to be consistent and powerful and
then used by authors.
Font styles would be specified via CSS styles. In fact I suspect that
current specific MathML 2 attributes will be deprecated in a future and
introduced in the scheduled future CSS MathML module, but we can begin now
with the correct usage of CSS.
This approach would entail introducing semantic or quasi-semantic
mark-up to encode an important part of a formula's visual appearance.
Obviously, LaTeX commands like \mathcal and \mathbb indicate no
semantics, so the only sensible solution would be to transform this into
something like var class=cal and var class=bb. If this is going
to happen, the classes should probably be defined in the specification.
I do not think so, somewhat as span class=bold is not defined in HTML
text, the font bold property is defined in CSS and you can call it via a
CSS rule applied to a class you can define. For example Spanish authors
could prefer span
Re: [whatwg] Mathematics in HTML5
Le 10 juin 2006 à 5:01, White Lynx a écrit :
I do not think that automatic mixing of roman and italic would be
a good
idea at the browser side if one search a rapid cheap
implementation fully
compatible with current standards.
That is probably quite right.
Yes, roman as a default is Ok as a first approximation.
Later extra line in author' s style sheet could provide TeX like
styling:
formula, dformula {text-transform:math-italic;}
Hum, what do you expect text-transform: math-italic to do? If you
want it to change every alphabetic character to the math italic
equivalent, how do you avoid transforming sin, cos, ln, mod,
to italic? You'll need at least one new element, maybe more, to
distinguish these cases, and then you'll still need to use var to
style non-scalar variables correctly.
This whole roman-letter-is-a-variable also makes the semantics quite
strange: in the whole document you can find variables using the var
element while inside formulas you must also look for roman characters
inside text nodes but outside special non-variable elements. I
don't think this concept fits HTML quite well.
I'm not advocating against math-italic, which can be useful to
display variables correctly, just against implicit variable-making
inside formulas. If math-italic is implemented, you'll still be able
to use it like above, but I don't think that should be the
recommended method of marking up formulas.
I think the idea of a script which would add variable markup
automatically according to some rules is the best way to avoid extra
manual markup without compromising presentation and/or semantics.
This way different people will be able to create different tools
adapted to their specific needs.
Script that sniffs content of all text nodes tends to run slowly.
XSLT does this job faster (but does not work with HTML).
In any case it would be nice to have simple solution like CSS text-
transform.
Such a script could be implemented server-side, or be used by the
author at the editor level, just like many HTML editors today have
commands to make authoring easier.
Script, fraktur and double-struck letters are available as separate
Unicode characters, so font-family may not be the best solution for
these scripts. In ISO 12083 they were available as a separate
character entities, not elements.
Adding character entities to HTML is really an option I believe. But
small scripts (javascript or server-side) or an HTML editor could
provide ways to insert relevant Unicode characters easily.
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: Well, now that I think of it, there will be some problems with any pure CSS implementation (for current browsers at least, but maybe with CSS3 too). Aligning fraction separators correctly with the base line when num and den do not have the same height for instance: I don't see a way to fine-tune that without JavaScript. It is not a problem at all (also it took some time to figure out whether CSS can render arbitrary complex fractions). In CSS2.1 there are two different ways to render fractions (one of them even works in MSIE) similar approach exists in XSL FO See http://www.geocities.com/chavchan/css/annotated.css for details. Generally speaking everything that we propose can be consistently rendered with CSS2.1. This is the main point of proposal. About styling ruby: for the needs of mathematics, I think in the absence of proper ruby CSS support, styling them as inline-table would be suffisent. But, just like fractions, it would need JavaScript to do the baseline adjustment. Just like in case of fractions, no script-tease is necessary. CSS2.1 can hadndle them without any problems. Once again see http://www.geocities.com/chavchan/css/annotated.css for details. There are minor problems on XSL FO side however, but that is not really important for browsers. But I would argue that my sum syntax, while requiring some JavaScript for proper display, use a more natural way of expressing things than yours. Once it requires JavaScript, there is no point in using XML, you can use LaTeX like input and render it using JS+CSS or XSLT+CSS, like in case of jsMath or XSL-TeX. The upper limits comes before the lower one, obviously to be able to put it at the right place with CSS. But usually, while speaking, or even just thinking, we put the lower limit first: from k equals zero to n, or something like that. Yes, current order is CSS motivated. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Ian Hickson wrote: I am not at all convinced that it makes any sense to rely on CSS to render mathematics. CSS simply doesn't have the expressive power to obtain acceptably good mathematical typography, and adding features to CSS to obtain this level of expressiveness would require a huge specification with such a small target domain than nobody would implement it. This are just words without any background. Current markup proposal can be consistently rendered using CSS2.1. If someone does not like shape of some particular glyph, or radical is not beatiful enough, or size of brackets is slightly larger or smaller then someone wants it to be, it is not the problem of markup. It is temporary problem (and for some not even a problem) that can be gradually addressed without too much noise and without getting level of expressiveness that would require a huge specification. Even if this problems will be never addressed we still will have markup language that provides basic functionality. Even if for somec strange reason CSS will suddenly dissapear (hard to imagine) we still have option to provide basic functionality via other style langauges (DSSSL, XSL). I've received feedback from members of the MathML community to the effect of I wish I could use MathML, but I don't want to use XHTML (i.e., MathML doesn't work in HTML). MathML do work in HTML (originally MSIE with MathPlayer plugin did not support XHTML at all). In Mozilla you can embed MathML in HTML using your favourite data URIs. You tend to over appreciate difference between HTML and XHTML, there is no real difference that could affect usage of MathML. If CSS can do this today, then you don't need any extensions to HTML. I would highly recommend persuing this in the microformats.org space, using the microformats development principles, and publishing a stylesheet that then renders the given microformat as high-quality mathematics. Similar markup exists as XML application http://xml-maiden.com In this way it can work independently from HTML and XHTML. However including math markup in (X)HTML would be useful in terms of usability (no need to use namespaces, reduced verbosity as users can omit optional elements, better integration with HTML etc.). I did not start this discussion and don't expect much from it, but since there is opportunity to solve problem of emdedding mathematical formulae in web pages and it practically costs nothing to developers I think it would be reasonable to use this opportunity. In my opinion, CSS alone is not even remotely close to enough to render mathematics well. I would love to be proved wrong, however. Generally speaking visiting pages like http://www.geocities.com/chavchan/21/torture.xml http://www.geocities.com/chavchan/21/stress.xml with Opera 9 or anything else that has sufficient CSS2.1 support should be enough to prove that CSS can render math formulae. Those who don't have appropriate browser can view PDF generated by CSS formatter (Prince 5) from XML source http://www.geocities.com/chavchan/21/stress.pdf I doubt you need more complex formulae, but if you need be assured current style sheet will still render them consistently. Of course you can still complain that some particular glyph is not beautiful enough and therefore whole story is useless waste of time. Note however no one tried to block HTML because blue undelined links were not beautiful enough, or visited links were too purple. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
I would highly appreciate a lightweight, pragamatic solution for doing math on the web in a convenient way. This solution could parallel MathML the same way as Canvas parallels SVG. And that does not necessarily mean, it should be javascript or Latex based -- though it might be. Personally I like a minimal vocabulary, which allows declarative math markup and integrates well with HTML. The proposal from George, refined by Michel currently being discussed here, is definitely a good start. Even if it ends only in a 80% solution, it presumeably will have only 20% implementation cost -- compared to MathML -- if at all. And these 80% would be more, than the target audience in engineering and economics really needs. As an example for successfully creating pure HTML+CSS based math formulas using the great concept of XML-Maiden see here for an example, http://goessner.net/learn/tm/exercises/exm/2005-07-06-II/ which was authored by students using a Wiki/Latex style markup. So a proof of concept to convert Latex style markup to HTML+CSS *and back* exists and works very well. http://goessner.net/articles/wiky/ Math in HTML5 would help a lot and might lead to even better tools, widgets or whatever. Stefan Goessner --- [EMAIL PROTECTED] http://goessner.net
Re: [whatwg] Mathematics in HTML5
James Graham wrote: [EMAIL PROTECTED] wrote: James Graham wrote: I could go on but at least in academic fields, LaTeX is either the only format accepted for publication or the preferred format. In mathematics, and theoretical physics sure, in rest of science? I doubt. In chemistry, LaTeX is not preferred for example. Not just in theoretical physics, but in all varieties of physics that I have ever encountered. Nor, as far as I can tell, is th widespread use of LaTeX just limited to the mathematics and physics communities. It is also, for example, one of four accepted submission formats of the Royal Society of Chemistry (Word, Wordperfect, RFT, (LaTeX), the only format accepted by Electronic Notes in Theoretical Computer Science and the only acceptable format for IEEE Transactions On Wireless Communication. In general, Googling for these examples, I was unable to find a single print journal which accepted electronic submissions but did not accept LaTeX as a format. Indeed, it is the _only_ hand-authored format accepted by the journals I encountered on my brief search, except for one online-only robotics journal which published in HTML and accepted submissions in HTML. Even in that case, the submissions page is quick to suggest a LaTeX to HTML workflow, implying that engineers are another group who often work with LaTeX, a speculation lent credence by http://www.eng.cam.ac.uk/help/tpl/textprocessing/ which contains an extensive set of notes for engineers on using LaTeX and begins TeX is a powerful text processing language and is the required format for some periodicals now). Of course using Google to turn up a few journals hardly makes for a good sample and you can no doubt provide counter-examples but it is extremely disingenuous to suggest that only pure mathematicians and a small subset of physicists commonly use LaTeX - it is clearly in very widespread use wherever mathematical communication is required. You said at least in academic fields, LaTeX is either the only format accepted for publication or the preferred format. I replied In mathematics, and theoretical physics sure, in rest of science? I doubt. In chemistry, LaTeX is not preferred for example. LaTeX is *not* the prefered format outside of mathematics and theoretical physics. I have colaborated and published works with chemists, oceanographers, and physicists working in nonlinear phenomena and chaos. None of them usually used TeX-LaTeX. My rusian colleague A. Shagaev has published articles of electrochemistry in electronic journals publishing in HTML. I know some chemists and many of them never worked in TeX-LaTeX. In Overview of the Manuscript Submission Process in the Journal of Physical Chemistry (ACS) you can see that prefered format is not LaTeX. LaTeX is *not* the preferred format for submissions in Physical Review journals (Letters and A, B, C, D, and E versions). That TeX-LaTeX is not sufficient for the web is also recogined even by TeX gurus as David Carlisle [1]. [1] Fragment of discussion from panel TeX and Math on the Web. Published in TUGboat, Volume 20 (1999), No. 3Proceedings of the 1999 Annual Meeting. Emphasis below in mine. blockquote Timothy Murphy and Michael Doob predicted that most mathematicians will stick with TeX, no matter what; mathematics is a separate world, which TeX serves very well. These comments provoked a spate of on-the-other-hand remarks: Carlisle: TeX users need to get onto the Web somehow. Patrick Ion: Engineers at Boeing (for example) use math too, and they need to read and write it. Fulling: We cant reach our students if they encounter mathematics only in an environment that is alien to them. McArthur observed that TeX has surprising difficulty in dealing with elementary school math. Ogawa summarized the task before: Both rendering and document creation are crucial needs, and both will be hard sells as the small TeX community struggles to integrate itself into the XML/MathML world. /blockquote small TeX community ... to integrate itself... Ah. That would be called doing one thing and doing it well. I've heard that it's commonly believed to be a good design principle. In this case, the problem I would like to solve is how do we typeset mathematics on the internet so that people actually use the technology rather than ignoring it into oblivion? We've already determined that LaTeX solves the same problem offline so it seems like a reasonable place to start when addressing the question for online publishing. TeX-LaTeX is good to mathematical typesseting in paper. TeX is not good enough for the web. That is reason that TeX-LaTeX was not reused for ISO-12083 not for MathML. Also Mathematica, Maple, AAP, EuroMath, OpenMath, and others rejected TeX-LaTeX systems. I'm not a TeX-person, merely a LaTeX user and, in the context of this discussion, my pro-LaTeX stance is merely a practical one; Precisely people
Re: [whatwg] Mathematics on HTML5
On Jun 8, 2006, at 01:18, Ian Hickson wrote: On Thu, 8 Jun 2006, Henri Sivonen wrote: If we made MathML work in HTML, possibly with rules that make the syntax easier (by implying tags as I suggested earlier) The implied stuff seems scary. I was hoping for no more tag inference beyond HTML 4 legacy. Oh? Why? Because it requires more special work and, therefore, requires a buy- in from parser writers and opens up more opportunities for bugs. If MathML is generated anyway (by TeX4ht, itex2mml, Mathematica, MathType, OpenOffice.org, etc.) and the DOM is complicated anyway, it doesn't make much sense to introduce new special cases in the serialization. Also, it would make sense to research if it is feasible to be markup- compatible (even if not DOM-compatible) with IE+MathPlayer on the text/html side. So making MathML+XHTML work in text/html would be a good thing, then? (That's basically what I'm proposing here.) In 2001, when this was on the table, you and I both wanted to go with XML media types instead of text/html. Perhaps it is, indeed, time to revise the stance here if Roger Sidje suggested it. (On the other hand, holding math hostage has slowly shown signs of causing IE +MathPlayer change their behavior but the IE release cycle is really slow.) If the WHAT WG defines a way for serializing MathML as text/html, I think it should be (at least for conforming cases) a pure alternative infoset serialization for a subset of possible infosets (dirty words, I know) as opposed to just being something similar but subtly different. That is, I think conforming documents should be losslessly reserializable as XML *1.0* and the DOM nodes for the math stuff should report the uncolonified element name in lower case as localName and the MathML namespace URI as namespaceURI. (I guess tagName should do what is most compatible with MathPlayer.) Finally, Mozilla's HTML parser and content sink are a mess. For sanity and interop, it would be good to get those reimplemented per spec rather than having new MathML stuff thrown into the current mess. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Mathematics in HTML5
Quoting Henri Sivonen [EMAIL PROTECTED]: I did, however, see * White Lynx disapproving of MathML and pushing his own stuff * Moose eventually conceding that MathML cannot be rendered using CSS alone. (No surprise there.) * Jonny Axelsson and Hixie alluding to Opera not having a business case for MathML (at this time). And all on non-normative forums or non-normative articles. (Opera has no official position regarding MathML, fwiw.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Mathematics in HTML5
Juan wrote: I think that markup would be more easy possible with posibility of ampliation, such that better authors could do a better job but average users could easily obtain results in a cheap and rapid way. That's something very desirable, I think, as it follows the general spirit of HTML. I would disacourage any semantic markup and a focus only in structure (markup) and presentation (CSS with XSL-FO as second choice). In that case something like frac numb/num den2/den /frac is structural. Good observation. Semantics convey meaning, structure is about organisation. The example above convey the same meaning as b/2, b÷2, or b divided by 2, but it is *organized* as a fraction. It seems most of HTML focus on the structure, not semantics. Paragraphs, headers, blockquotes, tables, lists, and now sections and asides, are more about organisation than meaning. Others elements in HTML -- q, var, kbd -- are more on the semantic side. It seems to me that the semantic elements are the least common in usage, but I don't have any statistics to support that. I would not encourage usage of a type attribute. A simple class would be sufficient and then we can reuse available CSS and HTML engines. The implementation of full semantics in browsers would be very, very complex and nobody has proved that using type=“matrix” or type=“vector” the semantics can be unambiguosly encoded. I agree completely. My suggestion of a type attribute had mostly the same purpose as class, and now I see no reason we should duplicate class. Combine class with a profile with head profile=... and you can give a semantic meaning to formulas through a microformat. It's a lot better than predefined semantics with some added fuzzy author semantics. So I agree we should focus on ways to express the structures found in formulas and not the semantics, which should be left to mathematicians and scientists in their respective fields. For any array structure –matrix, vector, determinant or any other- why do not simply reuse available HTML elements: table, td... instead proposing new ones mr, md doing the same? CSS rules could use different selectors body table: CSS rules for text tables body formula table: CSS rules for text tables I'm not sure about this. Tables have been overused before (for presentation) and it could be dangerous now to say to authors to use tables as matrices. That, and the fact that the word table already has some meaning, contains a caption and has the concept of header cell, makes me feel uncomfortable with this. My idea was to use matrix as a generic element name for both matrices, vectors, determinants, as well as anything else that may fit. Maybe array could be a better, more generic, name for that. fences could be done as fence left=round right=squareexpression/fence But isn't this presentational instead of structural? Why not use fence class=parenthesis.../fence with the proper CSS for presentation? I suppose one reason may lie in the non-obviousness of implementing different kinds of fences styles in CSS. The usage of external containers as integral, sum, product, was done in previous versions of MathML code but abandoned in recent proposals. While I was the one who came some days ago suggesting the integral syntax you quoted, I somewhat concluded yesterday it was not worth it, because it does not fit the written language, nor LaTeX for that matter. So I suppose we now agree on that. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Henri Sivonen wrote: My point was that math rendering tends to be addressed by a guy with a mission rather than companies if the companies decide, on business grounds, to prioritize their todo lists differently. For example, TeX and Gecko-MathML were both created using the guy with a mission model. But TeX solved problems. And was rapidly embraced by organizations and mathematicians. MathML is not solving problems it addressed, and mathematicians and others are ignoring it. For IBM it is about complementarities big time. When IBM funds the development of software that doesn't generate a direct revenue stream for them, they calculate that such software being inexpensively available boosts the demand for what Global Services sells. So to get IBM to pay for MathML support in browsers, you need a convincing case that the expense would be more than covered by the new business enabled for Global Services. (Also, IBM is big enough to experiment with stuff like techexplorer without betting the whole shop.) The IBM TeXML was not very popular because I think was unatractive for both TeX users and XML users. IBM TeX rendering browser suffered from technical problems, lack of unification with web, baseline problems, and others. For Design Science it is about complementing their priced products as well. Without MathML support in browsers, there'd be no use for the WebEQ and the Web side of MathType. Hence, Design Science distributes MathPlayer for $0. Ok, but they are waiting magical implementation in browsers of MathML and heavy spreading on both on and off-line of MathML. If a working HTML math was prepared, it could be implemented in browsers with minimal efforts. They could easily adapt its current tools to the new mathematical markup and begin to obtain benefits, instead waiting for a miracle from the MathML part. Precisely a guy from Desing Science was interested in changes to current mathematical markup for doing it CSS friendly for a rapid implementation in browsers. MathML support--content MathML support in particular--would be complementary to Wolfram's products. Actually, a piece of critical code that enabled MathML on Mac in Gecko was contributed by a Wolfram employee. (I don't know whether he did it on his own time or on company time.) So why isn't Wolfram taking care of getting content MathML support implemented in browsers with round-trippability with Mathematica? I don't know. Perhaps they feel it is not their responsibility. Perhaps they have estimated that Mathematica sales wouldn't get enough of a boost because of it to justify the cost. Or maybe you are -as in the rest of your message- forgotten that MathML was incorrectly designed. Some comments from a Wolfram Research guy + Like presentation MathML tags, content MathML tags are not good at elementary school math Human authorable MathML was one of the goals listed in the MathML charter. Many people felt human authorablility was one of the reasons HTML was so successful. Ultimately, the MathML committee couldnt reach agreement on a input syntax content MathML was not as well thought out as Presentation MathML. As evidence of this, MathML2 has many content fixes (deprecates fn and reln), and adds some tags that were glaring omissions (eg, lcm/). Content MathML is not really designed for computation. MathML purposely does not contain an evaluate token. What a MathML application should do when it receives the following is not defined apply sin/ applydivide/ cn type=constant pi; /cn cn4/cn /apply /apply Content MathML is closer to the intent of XML than Presentation MathML [but here some people is arguing for an implementation of latter however] Style sheets or other means of rendering decide on what it should look like in much the same way as style sheets are used to decide the font size, font, indentation, and alignment of a title or section heading. [Remember that George approach is based in standard Style Sheets] CSS is the main stylistic engine of Web browsers today. It defines a set of stylistic changes that all Web#8722;based renderers are supposed to support. The MathML Working Group is working on getting some of the things used for presentation MathML into CSS so that stylistic settings can be used to render math. [here some people want just the inverse, nothing of CSS compliance and full usage of presentational MathML even if they are not correctly working] [Functions for completeness] If an evaluate tag is added, then the semantics would probably be vaguely defined just as what MathML means today to different systems is vaguely defined. More precise specification raises all sorts of issues that probably are not easily supported by current systems. + vaguely defined, not defined, content MathML was not as well thought maybe are some of reason Wolfram does not waste time (and money) with content MathML
Re: [whatwg] Mathematics in HTML5
On 8 Jun 2006, at 10:3AM, White Lynx wrote: Oistein E. Andersen wrote: each mark-up element must be kept as short as possible. Some people argue that short element names being misleading and not intuitive does not actually improve readability, some people like short element names as they are more convenient for authoring. The importance of this convenience should not be underestimated. After all, we are discussing a hand-authored format (albeit not exclusively so). Indeed, preferences vary between individuals. Even so, most people would probably accept (or even prefer) a shorter element name as long as it remains meaningful and/or is coherent with overall HTML style/conventions and/or re-uses well-known terms. I would never insist on e.g. r2/r instead of radical2/radical, but no good argument against root2/root has been presented yet. Words like radical, radix and radicand might even be quite unfamiliar to many of those who might potentially want to use something as trivial as a square root. Assure compatibility with a reasonable subset of TeX Can anyone specify what steps should be made to assure this compatibility, I will try to give some feedback on this. Make font selection simple and natural See Kerning and shape of the glyphs section of current proposal, it mentions possible CSS extensions, that however are not part of this proposal If roman is chosen as default type, all (ordinary) variables will need mark-up. Would italic be preferable, and would it be conceivable to make italic the default for Latin and Greek characters later on when these CSS extensions might become available? If so, then everything in roman type must also be marked up to make the code future proof. Is variable mark-up supposed to be compulsory anyway? As an aside, traditional French typographical conventions for mathematics require lowercase variables in italic, but uppercase ones in roman. More on fonts later. -- Andersen
Re: [whatwg] Mathematics in HTML5
On 9 Jun 2006, at 11:0AM, [EMAIL PROTECTED] wrote:
Ãistein E. Andersen wrote:
2) Fight verbosity
m, [...] frac2den3/frac and root3of125/root [are] clearly
better suited than formula, fraction2denominator3/fraction and
radical3radicand125/radical.
However frac2den3/frac is an shorthand for the full markup,
because structures of kind {2 \over 3} are even to be avoided in TeX.
root3of125/root was already proposed in HTML Math of 1994 and
rejected because technical issues. Also rejected in ISO12083 math of 1995.
What i meant was to use root3of125/root as a shorthand notation for
something like rootorder3/orderof125/of/root, in which case only
the actual element names differ from the current proposal.
3) Assure compatibility with a reasonable subset of TeX
absence of a model for prescripts is one of most important flaws in TeX,
therefore do not wait that a TeX input can be magically transformed into HTML
5.
Obviously, it will not be possible to transform any TeX code into HTML 5.
Something like ${}^aB$ could be transformed into an HTML 5 prescript given the
correct rules, but then something like ${}^{342}_4X$ would of course look
different in TeX (probably incorrect) and HTML 5.
4) Make font selection simple and natural
There is many options. In HTML roman font is default and one just markes
variables as when one uses i for italic font. In Elsevier DTD for math,
italic was the default and roman was marked via tag.
Very well, but then a choice must be made.
I do not think that automatic mixing of roman and italic would be a good
idea at the browser side if one search a rapid cheap implementation fully
compatible with current standards.
That is probably quite right.
However, this would be not a problem for authors, because one could
implement a small js in a week that authors could use in their computers
asisting them to authoring math.
Such a script would certainly not fit everyone's needs and desires. It could be
potentially useful to many, but the language should be such that hand-authoring
be practical -- otherwise, the perfect integration with HTML will be lost.
How are non-italic variables supposed to be handled? Using attributes,
like var class=italic, var class=bold, var
class=blackletter, var class=roman, etc. may be part of the
solution, even though it would be quite verbose.
HTML is more verbose than TeX but is less erratic.
That is a fair point.
I think that people can perfectly use
var class=vectorF/var
instead
\mathbf{F}
if you dislike the class attribute, then try something like
varbF/b/var
A few issues still remain to be solved, though:
Boldface does not necessarily mean vector, and vectors are not always printed
in bold type. Presumably, you mean that classes like `vector' need not be
defined in the specification, that the choice is up to the author, and that a
custom CSS style-sheet can be used to define the font. (This would require CSS
font-families for Fraktur and double-struck/blackboard bold.)
This approach would entail introducing semantic or quasi-semantic mark-up to
encode an important part of a formula's visual appearance. Obviously, LaTeX
commands like \mathcal and \mathbb indicate no semantics, so the only sensible
solution would be to transform this into something like var class=cal and
var class=bb. If this is going to happen, the classes should probably be
defined in the specification.
The re-use of b and i makes sense in a way, but these two tags do not
suffice to access all the different fonts. (Unicode report [1] lists 14
alphabets: roman, italic, script, Fraktur, sans-serif upright, sans-serif
slanted; bold versions of all these; double-struck and monospace.)
[1] http://www.unicode.org/reports/tr25/
It is not clear that bi (or ib) would be a good choice for bold italic
variable names, as it would lead to encoding e.g. ia /bb/b/i (could be
a vector b scaled by a factor a), whereas something more like iai
bib/bi would be wanted. Another possibility would be to use something like
var ia/var var b ib/var.
Each approach has its problems. Anyway, the specification should probably not
try to avoid the issue of font selection.
--
Andersen
Re: [whatwg] Mathematics in HTML5
Anne van Kesteren wrote: but just putting this in the specification as well and requiring UAs to support it by default seems too much to ask, imho Maybe, but taking into account that WHATWG does not want to establish several levels of compliance, what can we do? I see at least three things in the specification that are in need of improvement. (1) There need to be more examples. I guess this is true for most specifications out there... It is not specification yet, at the moment we just want to know whether proposal like this is accaptable for WHATWG and to collect some preliminary feedback from community. (2) The intend of the HTML parsing rules is there, but they are not implementable. For example, according to the specification: fraction17den125/fraction ... comes out as: fraction num17/num den125/den /fraction ... now where did that whitespace come from? Issue with white space is just typo and will be fixed. Note however that parsing rules does not fully follow SGML conventions, because as far as I know WHATWG does not consider HTML5 to be SGML based markup, if however compatibility with SGML is still required please let us know and parsing rules will be changed accordingly (for usability reasons we prefer to keep current rules). (3) Error handling. What happens when I nest elements where they not belong etc. Does that affect parsing? It is important issue, I think parsing should not be affected. Normative error handling mechanism could be a problem, it can be provided but is unlikely to be followed by implementations, and thus will be useless. We'll return to issue later today and with some examples. Or for content models like matrix element or vector element followed by either marker or submark what happens when I actually write down a submark followed by marker followed by matrix? I guess these issues are mostly relevant for parsing (styling is pretty clear once that's defined), but it should be clear what the semantics are in such cases as well. Introducing too complex parsing rules will spoil our efforts to keep markup easy to implement. Note in particular that in XHTML version we don't want to introduce any special parsing rules at all. Current proposal does not require special parser for XHTML, breaking this rule would reduce chances of markup to be implemented. In HTML we can provide some special parsing and error handling rules, but not too much otherwise we risk to make markup difficult to implement for the sake of no actual functionality. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Anne van Kesteren wrote: I've already sort of proposed to add Ruby to HTML. Simple Ruby is already supported by Internet Explorer in HTML (I think the XHTML module was based on that implementation) and it makes sense to have it for certain foreign (to me at least) use cases. Unfortunately Ruby does not address our needs. One problem is implementation: it is not suitable for rendering with CSS2.1 while CSS3 Ruby module is unlikely to be implemneted in near future. Another problem is that nesting of Ruby inside Ruby is not allowed, this gives rise to nesting limitations that affect some mathematical formulae. One more small detail is that Ruby, unless base is always simple like (#PCDATA), can not be processed by XSL formatters either (it this respect current proposal is also not perfect). -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Alexey Feldgendler wrote: Why have f at all? When I'm writing about varx/var, why should I write fvarx/var/f? What would be the difference? I think a formula element is only needed for what is called display equations -- they are rendered out of line, usually centered, and sometimes numbered. That way, inline math would require no special element at all -- just write math in the middle of a sentence, and it should work. On the other hand, when math is put inside a formula, it's displayed on a line by itself, centered, numbered etc. And, by the way, one can actually have just plain text inside a formula, such as some statement in prose that needs to be centered and numbered like other formulae. It matters from both structural (marks formula explicitly) and presentational point of view (consider line breaks inside formulae, text justification algorithms that should not affect math formulae, different fonts that user may want to use for text and maths, possible CSS extensions like text-transformation:math-italic; etc.). -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Michel Fortin wrote: Use integral and bounds for integrals. integral bounds sub0/sub sup100sup /bounds 3varx/var dvarx/var /integral There are at least 30 different operators that would require similar markup, following this line one will have to introduce separate elements for all of them. Summary 16 new math-specific elements: * frac, num, and den * radical, radix, and radicand * matrix, mr, and md * fence * bounds * integral, sum, product * limit * formula What is the point is restricting scope of markup in this manner. Do you think that some of the features in current proposal that are omitted here are not realistic? If so why? 5 ruby annotation elements: * ruby * rbc, rtc * rb, rt, rp Ruby in its current form is not the best solution for mathematics. 3 reused HTML elements: * var * sup, sub I think all of these new elements can be styled decently with CSS. Excluding Ruby (and partly markup for sums, products and similar stuff). -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Dan Brickley wrote: It would also be both considerate and sensible (if anyone does want to undertake such a task) to talk to the MathML folks first. So far we are addressing problems that were invented and deployed by MathML folks. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
White Lynx wrote: Dan Brickley wrote: It would also be both considerate and sensible (if anyone does want to undertake such a task) to talk to the MathML folks first. So far we are addressing problems that were invented and deployed by MathML folks. But you are, apparently, assuming that the problems with MathML are a result of ignorance on the part of the people working on the spec. Perhaps there is a reason they invented a language that did not build on the CSS layout primitives e.g. because those layout primitives are not sutiable for mathematics (similar to the reason that XUL, though CSS-based employs a large number of specific CSS extensions to work in a sane way). You have demonstrated that CSS can provide the first 80% (or whatever) of what's required for laying out maths - but there seems to be no way forward to address the last 20%.
Re: [whatwg] Mathematics in HTML5
Oistein E. Andersen wrote: As Henri Sivonen put it: «[I]t is futile to insist on semantics that you can't pull out of LaTeX as it is normally authored.» I would like to use a slightly different wording: It is futile to insist on encoding anything that does not change the appearance of a formula as it is written on a blackboard or printed in a book. Completely agree, semantic should not be fragile. If it does not naturally reflect structure of math formulae then it likely to be abused. This is one of the resons why ISO 12083 follows visual structure of mathematical formulae and why current proposal follows similar line, with more specific semantics being transfered to optional content layer that is designed to be orthogonal to main structural markup and carries additional content information that may be necessary to provide quality rendering in case of non-visual media types including braille and speech or may be useful for computer algebra system that may need extra content information to recognize logical structure of mathematical formulae. No semantics is clearly better than wrong semantics Completely agree. Reliable information about general structure of formulae is better then detailed but wrong ultrasemantic markup. More importantly, the amount of mark-up needed to encode a line of mathematics is enormous compared to what is necessary for a line of running text. Consequently, each mark-up element must be kept as short as possible. We are ready to change element naming conventiones if WHATWG will agree and feedback will indicate that short notations are preferable. I have no strong preferences. Some people argue that short element names being misleading and not intuitive does not actually improve readability, some people like short element names as they are more convenient for authoring. Assure compatibility with a reasonable subset of TeX Can anyone specify what steps should be made to assure this compatibility, so far we see general wishes without any details on what in current proposal is considered to be LaTeX incompatible and how the problem can be resolved without spoiling other merits of markup such as compatibility with CSS. Make font selection simple and natural This point does not seem to have attracted quite the attention it deserves yet. TeX seems to have got things right on this point by making italic the default for letters and roman the default for numbers. Is this approach completely unfeasible within the HTML/CSS framework? See Kerning and shape of the glyphs section of current proposal, it mentions possible CSS extensions, that however are not part of this proposal and should be probably discused on www-style list. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics on HTML5
On Thu, 08 Jun 2006 07:58:40 +0700, Øistein E. Andersen [EMAIL PROTECTED] wrote: Correct splitting of continuous fractions seems like a similar non-problem. If a fraction is really overly long, then the author should probably split it manually. There are certain rules for correct splitting of fractions. Unlike hyphenation, the author doesn't have to define every possible splitting point -- these can be found automatically. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Mathematics in HTML5
On Thu, 08 Jun 2006 14:24:36 +0700, White Lynx [EMAIL PROTECTED] wrote: Why have f at all? When I'm writing about varx/var, why should I write fvarx/var/f? What would be the difference? I think a formula element is only needed for what is called display equations -- they are rendered out of line, usually centered, and sometimes numbered. That way, inline math would require no special element at all -- just write math in the middle of a sentence, and it should work. On the other hand, when math is put inside a formula, it's displayed on a line by itself, centered, numbered etc. And, by the way, one can actually have just plain text inside a formula, such as some statement in prose that needs to be centered and numbered like other formulae. It matters from both structural (marks formula explicitly) and presentational point of view (consider line breaks inside formulae, text justification algorithms that should not affect math formulae, different fonts that user may want to use for text and maths, possible CSS extensions like text-transformation:math-italic; etc.). What exactly is a formula? For example, I write that 2+2=4 means that the expression 2+2 equals to 4. What is a formula in the paragraph above, and what is not? One would most certainly agree that 2+2=4 is a formula (it's a complete equation). Likewise, most people will tell you that 4 is not a formula and needs not be marked as such -- or else any number inside prose should have been marked up. What about 2+2? Where exactly lies the separation between a formula and non-formula? I admit that the same problem exists in TeX: one could write 4 or $4$. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Mathematics in HTML5
Alexey Feldgendler wrote: What exactly is a formula? If you ask this question from the point of view of browser developer or browser itself, then the answer is simple formula2 + 2 = 4/formula is formula, while 2 + 2 = 4 is plain text. If you ask it from the point of view of mathematician or philosopher then it is rather rythorical question. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
On Thu, 08 Jun 2006 20:38:39 +0700, White Lynx [EMAIL PROTECTED] wrote: What exactly is a formula? If you ask this question from the point of view of browser developer or browser itself, then the answer is simple formula2 + 2 = 4/formula is formula, while 2 + 2 = 4 is plain text. If you ask it from the point of view of mathematician or philosopher then it is rather rythorical question. I'm asking this from the point of view of a document author. When should an author use a formula and when is plain text enough? -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] Mathematics in HTML5
Alexey Feldgendler wrote: What exactly is a formula? If you ask this question from the point of view of browser developer or browser itself, then the answer is simple formula2 + 2 = 4/formula is formula, while 2 + 2 = 4 is plain text. If you ask it from the point of view of mathematician or philosopher then it is rather rythorical question. I'm asking this from the point of view of a document author. When should an author use a formula and when is plain text enough? I think it should be up to author, if (s|h)e is happy with plain text notations then it is Ok to use them, if however explicit math markup is desired then formula2 + 2 = 4/formula is the way to go. However personally I don't like the idea of mixing different notations in one document. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics in HTML5
Some people has prompted to reuse LaTeX. People who want reuse LaTeX can do it, in the same way that one can reuse existing jsMath. However, mixing of two different languages is usually considered to be a bad practice. For example x 5 is okay in TeX but prohibited in XML. A = 3$ amp; B = 5% is valid XML but is not in TeX, etcetera. Moreover to problems with entities and reserved characters, (unicode vs. 7-bit encoding) and other related difficulties; there are technical points forcing to reject which as has been done during last decades by *all* markup or computer language except TeX-like ones, of course. The fact TeX/LaTeX is not suitable for web did that the LaTeX guru D. Carlisle was interested in mathematical language and joined to the w3c. Carlisle knows very well LaTeX and extensions he has done. He could solve your doubts better I can. There has been multiple attempts to extend or adapt TeX to the web (extended TeX approaches, TeXML...), all attempts failed by one or other reason. There has been also attempts to display math in the web using web browsers natively understanding TeX source (e.g. IBM launched one of this kind) but also failed by technical motives. I have not time for recopilating all information in the topic of why not TeX/LaTeX. However, I can cite some recent links of interest http://www.w3.org/Arena/tour/math1.html http://www.mathmlcentral.com/history.html http://my.opera.com/White%20Lynx/blog/show.dml/256124 http://www.w3.org/Math/mathml-faq.html It would be also noted that next LaTeX will change for adapat to the SGML/XML world. For example current research work for future LaTeX3 promise us a new syntax for further SGML world compatibility and will incorporate novel feature such as native support for the SGML concepts of entity, attribute and short reference. The new LaTeX3 will incorporate style-sheet concepts such as those we used today with HTML. I also would note others limitations of TeX and related systems apparently ignored at this mailing list. Jonathan Fine adds: blockquote Plain TeX, LaTeX and ConTeXT all use the familiar `backslash and braces' input syntax. This can cause problems, because it is not rigorous. Translation to HTML for example, requires that the source document be parsed. But LATEX for example is in general the only program that can successfully parse LATEX documents. This tends to result in (La)TEX living in a world of its own, isolated from the world of desktop publishing and word processing. For some communities of users, such as mathematicians, this may not be a hardship. /blockquote But is a hardship for rest of the world and reason that Active TeX was proposed. In fact, LaTeX is much more complex that kind of approach is being proposed here. Rahtz described LaTeX as blockquote hugely powerful, but chaotic, and on the verge of becoming unmanageable. /blockquote When people is talking of LaTeX here I suspect them are talking only of some basic LaTeX constructs as \frac, \vec, and others. I would be glad if anyone explains here how a root beta of k can be encoded in LaTeX and next fine-tuned e.g. moving index 2 units to the left and 4 units up or how would we encode the hat of large base as ABCD or the four dotting of Q or what are TeX/LaTeX constructs for Sum; H 0im or a X and X b Mihai Sucan wrote: I'd be interested of your Canon (Markup Language). Thanks! M is for Meta, because the language is also a formal language :-) Please copy anything of interest and report me errors or best ways to do things. I would like to see a specification of CanonML and working examples with an experimental implementation. Your site provides only talk about CanonML. Is it too early to ask for this? If you have some, send it over to my (private email). CanonML is in an early research stage. There is not formal specification still because is a research in progress. The canonical science blog includes history of the program and an outline of current ideas. More recent post update previous postings. The research has proved to be more variable I wait in a principle. I initially copied many aspects from available TeX, SGML/XML, content MathML, and OpenMath, but after changed by better options. Recently I have eliminated the concpet of entities (which I have discored is also an idea proposed by some XML gurus as Tim Bray). Variablity of research may be understood since I am trying to offer more power than SGML/XML maintaining the full language more easy than TeX/LaTeX and that is really very difficult. However I wait to finalize the work in a few weeks and just prepare first formal specification for debate. Ok I will send you. Math WebSearch - A semantic search engine http://search.mathweb.org/ http://kwarc.eecs.iu-bremen.de/software/mmlsearch/ I'm not sure if searching math is entirely a myth. This is a recent guided research project done by a student of Dr. Kohlhase. I was referring to MathML.
Re: [whatwg] Mathematics on HTML5
Ian Hickson wrote: I would say MathML is not widely used because MathML doesn't work in HTML, personally. I do not know from where this idea get up. SVG is relatively popular and implemented in many browsers, but the same browsers implementing SVG are rejecting MathML. They are rejecting because difficulties for implementation, not because HTML lack of. The original mathematical work from the w3c was mathematical markup FOR HTML. It was drafted so early as in HTML 3 epoque and strongly rejected by community. Unfortunately subsequent first draft of MathML, MathML 1.x and recent MathML 2.0 all habe been rejected by technicla motives rather than HTML-relationship. In fact, I do not know a single criticism to MathML emphasizing the point you state. All public criticism are to design options and technical details independent of host language. If we made MathML work in HTML, possibly with rules that make the syntax easier (by implying tags as I suggested earlier), Curiously, I suggested similar approach in my previous CanonMath language [http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html] one could write something like CanonMath a+bfraction/2 /CanonMath [http://lists.w3.org/Archives/Public/www-math/2006Mar/0027.html] next was converted to full presentation MathML 2.0, but it was strongly rejected by MathML authors, see Carlisle reply for instance [http://lists.w3.org/Archives/Public/www-math/2006Mar/0028.html] Moreover, your proposal would be rejected by most authors and developers (today rejecting MathML) because obtain all difficulties and limitations of current MathML (between them incompatibllity with DOM, CSS, XSL-FO.) More the rejection from w3c MathML guys that do not want to see a mixture of textual strings with MathML own elements. then that might well change, especially given that one UA already has extensive and high-quality support for MathML. I imagine that you mean Firefox browser with native MathML. Well I would not call that extensive and high-quality support for MathML. I would say, partial incompletete support of less than one half the official specification. Content MathML is not supported, only presentation MathML; of presentation MathML not all tags are supported; of all tags supported not all are working. You can begin from the most simple teste of the MathML official test suite and can see that MathML suport is weak in browser (I use Firefox 1.0) and even most simplest test are either not correctly rendered or not at all (compare with sample GIFS). http://www.w3.org/Math/testsuite/testsuite/General/Math/math3.xml http://www.w3.org/Math/testsuite/testsuite/General/Math/mathAdisplay1.xml http://www.w3.org/Math/testsuite/testsuite/General/GenAttribs/style1.xml http://www.w3.org/Math/testsuite/testsuite/General/GenAttribs/style2.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miAtoken5.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miScolorscope7.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miSfonts8.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miSfontsize9.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miSmathsize17.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miStoken10.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mn/mn3.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mn/mnAcolorname5.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mn/mnAtoken6.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mo/moAlargeop12.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mo/moAminmax14.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mo/moAmovable15.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mrow/mrowBinferred2.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mfrac/mfracAbevelled16.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mfenced/mfencedAdelims6.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mfenced/mfencedBfences7.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/msubsup/msubsup1.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/munder/munder1.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/munder/munder2.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/mmultiscripts/mmultiscripts2.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TablesAndMatrices/mtable/mtable1.xml http://www.w3.org/Math/testsuite/testsuite/Presentation/TablesAndMatrices/mtable/mtableAwidth1.xml
Re: [whatwg] Mathematics in HTML5
Henri Sivonen wrote: I think it is an economic problem rather than a technical problem. Yes, this may be reason that a single man was able to do math in a browser via XML-MAIDEN project in a few months, whereas dozens of others and even entire communities cannot do it even after of 10 years. Money may be also the reason of fiasco of IBM TeX approach to the web and of Wolfram fiasco to the web via Wolfram draft (remember?). George alone may be more rich that IBM, Desing Science, Wolfram Research, and others joined. It follows that I don't think the slow adoption is *necessarily* evidence of technical flaws. Then you know nothing of the history of math on the web. I would recommend you begin to revise history from the very beginning: HTML 3 Math, the first draft from the w3c. Attemtp to search why was completely rejected. The part of population that is interested in mathematical typesetting is very small in proportion to the population as a whole. As I understood it at the time, that's why Netscape wasn't interested in devoting developer time to MathML. I don't know how decision making works at different browser companies, but I would hazard a guess that from the point of view of Opera, Apple and Microsoft, the business case for MathML is rather lousy compared to e.g. SVG, which is known to have spec problems as well, which conflicts with CSS and which also doesn't work in text/html. Well, always that anyone say me that math is for some little ones I always reply then why MSWord has an equation editor? Curiously history says contrary. History says that Microsoft was interested in providing native MathML support for MSIE and initially joined to MathML WG but due to technical problems they after rejected native support and just added some improvements to MSIE for suporting of third parties plugins. Mozilla has attempted to support MathML and even most simple tests fail. Opera developers were interested in mathematics but not in MathML because thecnical weakness of latter (see comments from developers in the links I provided), etc. I was interested in a full support for MathML in The Center for CANONICAL |SCIENCE) but I abandoned the project by thecnical issues (technical errors and weakness of MathML). Content MathML is not supported because problems again and even very recently it has been proved that something so simple as integral sin x from 0 to x is not correctly encoded in MathML due to an incorrect desing. Then people wannot waste time and money with never-working-thecnologies. Because in the end you obtain an expensive technology that is poor that old cheap ones. Hmm. Freaky economic problems are nowadays solved with Google money. :-P Have you asked them about support of MathML? I did! FWIW, I completely agree with James Graham that automatic conversion from LaTeX is *the* top-of-the-list requirement for any kind of Web math. Remember that MathML has not achieved that still. That already puts MathML ahead of anything else that WHAT WG could come up with. I think that you simply do not know you are talking here. If the WHAT WG really intends to address math, I think it would make sense to start by interviewing Roger Sidje, Jacques Distler, Eitan M. Gurari and Robert Miner to find out what they think are the problems that need to be solved (if any). Robert Miner knows very well the limitations of MathML. Robert Miner has recognized in public that MathML design is not so good because has political issues in the w3c committe. A pair of months ago he also publicly become interest in that would be changed in future MathML 3.0 for doing it CSS friendly and suitable for easy implementation in browsers. George offered him the short list of changes. Jacques Distler have attempted to offer mathematics in his blog using *presentaional* MathML 2.0. He has largely failed and provides us incorrect semantics, wrong structure, innaccesible and not searchable code, and incorrect rendering of mathematics during years. Moreover, he uses a very ugly approach based in a plugin for a IteX dialect is rather limited. For a small number of examples of very wrong (nonsensical) code Distler is serving to the internet can see my [http://canonicalscience.blogspot.com/2006/04/scientific-language-canonml-is.html] Some of incorrect formulas the was encoding via MathML 2.0 were better encoded in several geocities HTML pages by undergrad students. In fact, I curiously said that the element of line for 5D spaces could be better encoded using old but effective HTML code SPANds/SPANSUP2/SUP and Distler incorrectly thouhg that this was the way he would change the mathML code of his inefficient blog. In fact just a pair of days ago the change the code of element of line of (see above link for details) [http://golem.ph.utexas.edu/~distler/blog/archives/000635.html] to current msupmids/mimn2/mn/msup that is a copy of my above HTML code. Unfortunately the code he generates now
Re: [whatwg] Mathematics in HTML5
Le 7 juin 2006 à 20:28, Ian Hickson a écrit : For something as big as Mathematics, we want to simply re-use an existing language, not invent a new one. Inventing a new language for encoding content with as wide a problem-space as mathematics would require months, as well as the time of domain experts, etc. Defining everything unambiguously is what would take long. If someone wants to define unambiguously everything in a formula, I'd suggest he use MathML, or something else if MathML cannot do the job properly. But most people don't need machine-readable formulas: they need to comunicate mathematics to other *people*. If you take a look at how HTML handles prose, you find that it doesn't try to determine what is a sentence, what is a noun, or what is a verb. But it provides what we need the most: paragraphs, headers, lists, emphasis, etc. I think it should be the same for math content. In my view, HTML should only provide the most needed building blocks for mathematical representation and let authors define semantics beyond the specifications as required. The idea behind the type attribute on var, matrix, and fence in my draft proposal, which could also be extended to other elements, is to allow author-defined semantics to be bound to them, semantics which can then be used as hooks for style sheets. Default styles could exist for predefined semantics (var type=vector could put a little arrow over the variable for instance) while authors could create new types and styles for their own purposes when needed. For now, I think creating an inventory of formulas showcasing everything we want to support would be a good first step toward creating, refining, and adopting a formal mathematical markup solution, as well as creating implementations. So I think I'll look into that. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
Le 8 juin 2006 à 4:24, White Lynx a écrit : Michel Fortin wrote: Use integral and bounds for integrals. integral bounds sub0/sub sup100sup /bounds 3varx/var dvarx/var /integral There are at least 30 different operators that would require similar markup, following this line one will have to introduce separate elements for all of them. Well, not necessarily. We could just use a more generic name with a type=integral, type=sum, or type=product attribute. In fact I think it'd be better with an attribute because it allows the construct to be easily extended in the future. What would be useful is a list of these 30 or more operators, and usage cases, to figure out a markup that fits with all of them. Summary 16 new math-specific elements: * frac, num, and den * radical, radix, and radicand * matrix, mr, and md * fence * bounds * integral, sum, product * limit * formula What is the point is restricting scope of markup in this manner. Do you think that some of the features in current proposal that are omitted here are not realistic? If so why? I didn't mean to restrict the scope. This wasn't a final proposal; I was simply expressing an idea which is still up to be enhanced and extended. But keeping an eye on how many elements we add to HTML is something important I think. There is already some improvements and issues I can think of for this syntax: * A way to disambiguate integrals over regions, since the region ought to be shown below the integral and not beside like with intervals. * func as a way to have functions in italic without calling them variables or using i. Could be used in a programming context too. * Maybe limit should be replaced by lim, as lim is the text that gets displayed. Or operatior type=lim in a compatible way with other operators. * I'm not fond of my syntax for bounded fences. Maybe something like that would be better (and more decent to style): (I omitted some var elements for more clarity) bounded fencesin varx/var/fence boundssub0/subsup1/sup/bounds /bounded bounded fencex + 1/fence boundssub0/subsup1/sup/bounds /bounded It looks a little like your syntax White, with fenced replaced by bounded and used only when bounds are defined. * I'd like less verbose radicals. But I'm not sure how well that could be styled (it's up to experiment): radix2n + 1/radixradicalx/radical ... the idea is that it should work even when radix is not present. * It occurs to me that having an exponent denoted by sup just after a big fence may not be easy to style at the right height either unless we have an enclosing box. 5 ruby annotation elements: * ruby * rbc, rtc * rb, rt, rp Ruby in its current form is not the best solution for mathematics. You're right about the nesting argument. I didn't thought of that. 3 reused HTML elements: * var * sup, sub I think all of these new elements can be styled decently with CSS. Excluding Ruby (and partly markup for sums, products and similar stuff). Well, now that I think of it, there will be some problems with any pure CSS implementation (for current browsers at least, but maybe with CSS3 too). Aligning fraction separators correctly with the base line when num and den do not have the same height for instance: I don't see a way to fine-tune that without JavaScript. About styling ruby: for the needs of mathematics, I think in the absence of proper ruby CSS support, styling them as inline-table would be suffisent. But, just like fractions, it would need JavaScript to do the baseline adjustment. About sums and products: you're right on that. Without JavaScript to correct the horizontal alignment, bounds are not going to be pretty (I just tried). It's true for integrals, and bounded fence too. But I would argue that my sum syntax, while requiring some JavaScript for proper display, use a more natural way of expressing things than yours. Look at this summation for example: opgrp ∑ ulimn llimk=0 /opgrp 1+k The upper limits comes before the lower one, obviously to be able to put it at the right place with CSS. But usually, while speaking, or even just thinking, we put the lower limit first: from k equals zero to n, or something like that. This makes this syntax easier and more natural to write and read: sum bounds subk=0/sub supn/sup /bounds 1+k /sum Moreover, as things are in proper order, it makes it a lot easier to give a proper aural or linear representation of the formula. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Mathematics in HTML5
On Thu, 8 Jun 2006, James Graham wrote: White Lynx wrote: Dan Brickley wrote: It would also be both considerate and sensible (if anyone does want to undertake such a task) to talk to the MathML folks first. So far we are addressing problems that were invented and deployed by MathML folks. But you are, apparently, assuming that the problems with MathML are a result of ignorance on the part of the people working on the spec. Perhaps there is a reason they invented a language that did not build on the CSS layout primitives e.g. because those layout primitives are not sutiable for mathematics (similar to the reason that XUL, though CSS-based employs a large number of specific CSS extensions to work in a sane way). You have demonstrated that CSS can provide the first 80% (or whatever) of what's required for laying out maths - but there seems to be no way forward to address the last 20%. I strongly agree with this. It is something I've been saying for (literally) years. I am not at all convinced that it makes any sense to rely on CSS to render mathematics. CSS simply doesn't have the expressive power to obtain acceptably good mathematical typography, and adding features to CSS to obtain this level of expressiveness would require a huge specification with such a small target domain than nobody would implement it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Mathematics in HTML5
James Graham wrote: They have to use LaTeX to prepare documents for publication, it is the only language they know for typesetting mathematics and, in general, the web is not their major target medium. However, for current markup proposal, web is major target medium, which means that if markup will not be suitable for rendering in web browsers then proposal is pointless. LaTeX generated websites tend to be html representations of lecture notes or papers that are primarily designed for consumption in paper or PDF formats. So the html version only exists at all because it is relatively little effort to produce it in addition to the main publication format. When that is not the case, there will simply be no html version provided. This is partly true. However we can't do much here. Complexity of task of tranforming LaTeX to XML+CSS depends only on LaTeX, XML and CSS, if it is complex it is complex regardless current proposal, if it is easy then it is easy regardless our efforts. Current proposal is intended to mirror existing niche in XML+CSS framework and provide approprietely documented markup suitable for usage on web. Choosing completely different approach would require browsers to implement something that goes far beyound existing capabilities of their rendering engines and current scope of web standards, and would turn proposal into yet another long and sad story of mythical mathematical markup born to save the earth, but being blocked by evil browser developers failed to fullfil its mission. My point throughout is that if you want people to use the language then backwards compatibility is key. Backward compatibility will be provided exactly as defined in the position paper submitted by Opera and Mozilla that represents the fundamental principles upon which the WHAT working group intends to operate: BACKWARDS COMPATIBILITY, CLEAR MIGRATION PATH Web application technologies should be based on technologies authors are familiar with, including HTML, CSS, DOM, and JavaScript. Basic Web application features should be implementable using behaviors, scripting, and style sheets in IE6 today so that authors have a clear migration path. Any solution that cannot be used with the current high-market-share user agent without the need for binary plug-ins is highly unlikely to be successful. I seem to have to keep repeating this point that compatibility with existing technology is important. Very well, our points of view are very close. The existing technology in the field of mathematical authoring is LaTeX. Think about existing technology for web delivery of scientific content. This is the area where all the problems come from. So, if one wanted to make life easy for LaTeX authors who envisioned targeting the web, one could provide a package that would add some mapping onto the more semantic constructs of the target language. This is absolutely realistic, and seems to be the only way to reduce loss of valuable data during conversion from LaTeX based authoring format to HTML based web delivery format (still suitable for direct authoring). I see no point in wasting time designing a document markup language that will be roundly ignored by ~100% of the people creating content. Keep in mind that apart of authoring current proposal has to take into account other issues including web delivery. If authoring is the end of story, then paper and pen are more then sufficient. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: [whatwg] Mathematics on HTML5
[ Sorry for the delayed reply guys, being quite busy for a week and I have to do some catching up on this thread. ] Le Thu, 01 Jun 2006 19:22:50 +0300, [EMAIL PROTECTED] a écrit: Michel Fortin wrote: One thing I know however is that the next time I'll have to put an equation on a web page, I won't go looking for a MathML editor just to be able to generate the markup, convert the page to XHTML served as application/xhtml+xml (so that it works with MathML) and ask my users to install the required plugin or web browser just to see my equation. I'll use an image: it'll be a lot simpler. Not so simple if you need add maintenance, search, storage, printing, and accessibility items to the list of requirements. True. James Graham wrote: In this situation, I imagine most scientists will simply write LaTeX and use a tool to produce the output format that they desire. I doubt because LaTeX has not the sufficient capabilities for a full web design. Why not? I looked into jsMath and I actually like it. I'd wish browsers would implement that. WHATWG could add just one tag: math type=mime/type src=file math content /math That would work much like script does, or ... browsers could use the advantages of object. I believe the latter would be best suited, since it provides fallback capabilities. As you said, as James said, and as far as I know, LaTeX is the most used language for mathematical scientific documents. The fact the content in the object (the mathematical formulas) can't be styled via CSS, nor modified via JS+DOM, is by far a lesser problem than not having any support at all for any mathematical language. If jsMath can achieve nice results via DOM manipulation for rendering LaTeX code, why wouldn't be a browser capable of doing that? It should actually be even more powerful, faster and capable of implementing even what the guy wasn't able to. Look at the test page - some of the rendering is awful (the radical signs in particular stand out here). The approach was designed to be minimalist. Of course it can be improved. Moreover, radicals (looking better than in Firefox with native MathML support) could be best rendered via future CSS embellishments for math. The rendering George achieved is not that bad, and certainly it's not awful. And, despite being sold as a simpler solution than a MathML implementation, it works in about 1% of UAs (by number of users) compared to 95% that have a story for native or plugin-based MathML. Original approach works in many rendering engines including off-line engines as Prince. The approach has been recently generalized to work also with several XSL-FO formatters (MathML does not fit in FO approach). Current problems are in current implementation of CSS standards rather than problems with George approach. For example, it is needed good support for inline CSS blocks. Firefox has a bug on that. The same bugs affected Opera 8 and Prince 4, but were solved. [...] I have to agree with Juan on this. The fact those scientific documents are rendered properly in about 2% of UAs (by number of users) is not a problem at all, since it all relies on the CSS implementation in the other UAs. This problem is bound to be solved in future releases of any UA. As Juan said: Firefox will have a fix. Internet Explorer is an atypicial (might I add a tragical) example, not worth going into details. Mihai Sucan wrote: Another different take: If LaTeX is considered to be the best available language for writing mathematical scientific documents, and the best for printing too... why not have user agents implement it? It is not THE best. It is very good (but boring) at mathematical typesetting but is not good enough for web and reason was rejected for several mathematical markups (ISO 12083, EuroMath, MathML, OpenMath, XML-MAIDEN...). Why isn't LaTeX good enough for the web? If we wouldn't have CSS and someone, today, would come up with a CSS-like proposal we'd trash it since it's not good enough? Please define good enough for the web. I see LaTeX as was CSS 10 years ago: - no implementation - very different syntax (not SGML/XML based) - no DOM integration But LaTeX has important advantages: - it is proven to be very good for publishing scientific documents - it has many open-source implementations As you can see, I am for reusing existing technologies and formats, not for adding yet another one. The guys from Opera Software and Mozilla Corporation could just say no to everybody and just go ahead and implement support for LaTeX as object. That would really make all authors of scientific documents very happy. Thing is, CSS implementation required big changes and was a different approach. LaTeX is just like implementing support for a new image format. I'd be interested of your Canon (Markup Language). Thanks! M is for Meta, because the language is also a formal language :-)
Re: [whatwg] Mathematics on HTML5
Le Thu, 01 Jun 2006 21:25:49 +0300, James Graham [EMAIL PROTECTED] a écrit: But authors _will_not_ learn anything other than LaTeX. Authors will learn something else _if_ that's proven to be better. Yes, it's true authors don't generally jump on whatever comes new (that's the reason MathML is not as widely used as LaTeX). -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] Mathematics in HTML5
Le 5 juin 2006 à 9:51, White Lynx a écrit : Sketch of the proposal is available, comments are welcome. At this stage prose is far from being polished, but I hope it is readable. Ok, so let's comment. First I'd say I like the path you've taken. I like the fact that you make it easy to author formulas directly in HTML. One thing I dislike however is the distinction you makes between the formula and the dformula elements, which I'd think is confusing. Sometimes, formulas are alone on their line but still in the middle of a sentence. That formula should have display: block with CSS but still be considered as an inline element form the HTML point of view (so it can be put in a paragraph). At other times, formulas are inserted outside paragraphs, as an HTML block. I think it would be better to have only one formula element which would be a structured inline-level element[1]. [1]: http://www.whatwg.org/specs/web-apps/current-work/#structured I would also use f instead of formula (as Juan used in one of his example), because it's shorter and fits well with many other wildly used container elements: p, h1-h6, ol, ul, li, dl, dt, and dd. And I'm somewhat skeptical of the usage you plan for the formula group element. Is there a case where placing formulas one after the other would be inappropriate? Fractions: seems all fine to me. Maybe we could use frac instead of fraction (just like we have div, ins, del, em), but it's not all that important. Nothing to say about radicals: it's well put. Under scripts and under braces, over scripts and over braces: Is it useful to have distinct ubase and obase? And the whole concept reminds of the Ruby Annotation module of XHTML 1.1 [2] and Ruby in CSS 3 [3]. Maybe some parts of that model could be reused. Maybe we could even add Ruby (or a derivative of it) to HTML 5 and use it in formulas and elsewhere. [2]: http://www.w3.org/TR/ruby/ [3]: http://www.w3.org/TR/css3-ruby/ More comments to come... Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
