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] Web widgets
Hi Ben, A couple weeks ago I was at XTech and talked with some Opera developers about the possibility of standardizing a method of doing web widgets similar to the current Opera widgets (and somewhat similar to Dashboard widgets). I am planning on implementing a similar widget functionality for mozilla-based browsers and wanted to share a common API that web developers could count on for multiple browsers. I remember at least one other person from Opera who was at XTech who said it sounded like a good idea to consider putting together a common cross-browser web widgets spec. So... I don't know what kind of schedule you're working under for your implementation, but it seems like it would be a good idea to get some focused discussion on this going soon. Perhaps we could set up a separate widgets API (or whatever) mailing list And, FWIW, I planning to be Mountain View June 18-20 for another meeting, so if you thought it'd be worthwhile to have a face-to- face discussion, maybe we can meet (in the evening) on one of those days. --Mike smime.p7s Description: S/MIME cryptographic signature
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] Web widgets
On Thu, 08 Jun 2006 15:41:37 +0700, Michael(tm) Smith [EMAIL PROTECTED] wrote: I remember at least one other person from Opera who was at XTech who said it sounded like a good idea to consider putting together a common cross-browser web widgets spec. So... I don't know what kind of schedule you're working under for your implementation, but it seems like it would be a good idea to get some focused discussion on this going soon. Perhaps we could set up a separate widgets API (or whatever) mailing list The thing that worries me the most about widgets is their main use case. It doesn't seem clear what they are for, and there was some blogging about it in the recent time. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
[whatwg] oninput event - pasting
http://whatwg.org/specs/web-forms/current-work/#the-change
this specification introduces the input event. This event is fired on
a control whenever the value of the control changes due to input from
the user
Does due to input from the user mean that *every*, *direct* action
the user *makes on the control* (that changes its value) causes the
event to fire?
Specifically, if I have this:
textarea oninput=alert('test')/textarea
, and right-click and paste into the textarea or ctrl+v into the
textarea to paste, or select and cut, should the event fire?
I can assume that, the event should fire no matter how the user
changes the value (just as long as it's done directly and not by
invoking a script that changes the value), but I'd like to know for
sure.
Thanks
--
burnout426
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] Simple numbers
- Original Message - From: Mihai Sucan [EMAIL PROTECTED] Subject: Re: [whatwg] Simple numbers | Le Tue, 06 Jun 2006 17:22:11 +0300, Michel Fortin | [EMAIL PROTECTED] a écrit: | | Maybe a number element would be valuable, both inside and outside | formulas, to provide format-neutral machine-readable numeric values: | | n value=123456789.12123 456 789,12/n | | But it surly seems a little overkill to write each numeric value twice. | Duplicating values seems prone to errors. So maybe a number with a | decimal separator attribute would be a better approach: | | n dec=,123 456 789,12/n | | Beside that, it could provide data on other kinds of numbers too: | | n base=16329F 2CA0/n | | Hello! | | I'd look for a solution via CSS. It is not possible today, but I'd say | this would be a welcome addition. | | I like the idea Michel came up with. However, with a few changes. Yes, the | value attribute would be overkill. | | Similar to the way you can define quotes in CSS, I'd wish we could be able | to define number format. | | n base=16329F 2CA0/n | n base=10 dec=.12672611872.7889/n | | and from CSS: | | number-format: base group-char decimal-char; | | number-format: 32 .; | number-format: 2 none ,; | | So, from HTML you define the format in which you provide the number. Then | from CSS you can change the base used for displaying, the chars to be used | for grouping digits and for separating the decimals. | | Both attributes are optional. The dec attribute defines the char used for | separating the decimals (making it easier for the UA to convert the number | to the new number-format set by CSS). | | This way we provide a fall back mecanism for browsers with no support for | nr and the CSS property. CSS 3 Math module would be appropriate for | adding such a property. | | Also, this discussion would probably better fit into www-style mailing | list. Or ... maybe someone is interested in having this added to HTML 5. | There are also other cases when we need special formatting... Thus I think it is better to have something more generic in CSS: text-format: number | currency | date | path-ellipsis | ellipsis This will allow to render content in current format supported by platform/locale. Andrew Fedoniouk. http://terrainformatica.com
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] oninput event - pasting
On Thu, 8 Jun 2006, Shadow2531 wrote:
http://whatwg.org/specs/web-forms/current-work/#the-change
this specification introduces the input event. This event is fired on
a control whenever the value of the control changes due to input from
the user
Does due to input from the user mean that *every*, *direct* action
the user *makes on the control* (that changes its value) causes the
event to fire?
Specifically, if I have this:
textarea oninput=alert('test')/textarea
, and right-click and paste into the textarea or ctrl+v into the
textarea to paste, or select and cut, should the event fire?
Yes.
Another part of the spec mentions that the UA may coallesce multiple
inputs into one input event, so e.g. if you type very fast it might not
fire one input event per character, it might fire one every few hundred
milliseconds instead.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=text accept=
On Wed, 31 May 2006, L. David Baron wrote: I don't see why the same attribute _shouldn't_ be used to determine the type of data to allow, and whether to do spell checking or not. After all, whether to spell-check is directly related to what kind of data it is. This sounds a lot like object, which allowed for tons of features but didn't specify them precisely. Are you planning to specify exactly what the semantics of every MIME type are for all of these features? No, because I don't know what those are, and want to allow for browser vendors to increase their feature set without having to have the spec updated each time. It doesn't seem like this is an area that requires interoperability (who cares if one browser auto-indents and another colours and spell-checks, other than the user of each browser?). And any others people might want? And are there really MIME types that accurately represent the semantics of all the combinations of even just the 4 features you list above that authors will want? If every combination needs a name, what if people want to toggle six different things? This sounds hypothetical. Given that requiring a new flag per feature is not an option (as it would require a central authority to add these features, slowing the introduction of new features and discouraging experimentation), what solution would _you_ propose? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=text accept=
On Friday 2006-06-09 00:42 +, Ian Hickson wrote: On Wed, 31 May 2006, L. David Baron wrote: I don't see why the same attribute _shouldn't_ be used to determine the type of data to allow, and whether to do spell checking or not. After all, whether to spell-check is directly related to what kind of data it is. This sounds a lot like object, which allowed for tons of features but didn't specify them precisely. Are you planning to specify exactly what the semantics of every MIME type are for all of these features? No, because I don't know what those are, and want to allow for browser vendors to increase their feature set without having to have the spec updated each time. It doesn't seem like this is an area that requires interoperability (who cares if one browser auto-indents and another colours and spell-checks, other than the user of each browser?). The original use case, as I understand it, was roughly authors want to disable spell checking on some textareas. Is the reason that they want to disable spellchecking only that the contents are not text/plain? I doubt it. Doing what you propose, especially if it is extended to other features, will just encourage authors to use incorrect MIME types to get particular side-effects in particular user agents. It seems more likely to be that the textarea is expected to contain a particular type of text, such as abbreviations or some form of code. The content is unlikely to have an assigned MIME type. I suppose one could be made up, but that would presumably disable everything a UA did on the basis of the contents, which wouldn't necessarily be appropriate. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpffr0IKPp8K.pgp Description: PGP signature
Re: [whatwg] input type=text accept=
On Thu, 8 Jun 2006, L. David Baron wrote: The original use case, as I understand it, was roughly authors want to disable spell checking on some textareas. That, and enable it on input fields. Similarly, there is a desire to indicate that certain textareas should have spell-checking enabled but with an expanded vocabulary that also allows HTML tags (or that disables the spell-checking, if the UA doesn't know how to do that). Looking forwards, there have also been multiple requests to be able to tell the UA that the contents of the field should be syntax-highlighted according to the rules of various languages (typically HTML or XML, and sometimes various programming languages). Is the reason that they want to disable spellchecking only that the contents are not text/plain? I doubt it. Doing what you propose, especially if it is extended to other features, will just encourage authors to use incorrect MIME types to get particular side-effects in particular user agents. It seems more likely to be that the textarea is expected to contain a particular type of text, such as abbreviations or some form of code. The content is unlikely to have an assigned MIME type. I suppose one could be made up, but that would presumably disable everything a UA did on the basis of the contents, which wouldn't necessarily be appropriate. There is certainly that possibility; indeed one of the use cases I've heard mentioned is disable spell checking because the text field contains a list of e-mail addresses, which has no MIME type. Given that requiring a new flag per feature is not an option (as, as mentioned before, it would require a central authority to add these features, slowing the introduction of new features and discouraging experimentation), what solution would you propose instead? I don't see a better solution. I'm certainly open to better solutions if there are any. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=text accept=
On Friday 2006-06-09 01:17 +, Ian Hickson wrote: Given that requiring a new flag per feature is not an option (as, as mentioned before, it would require a central authority to add these features, slowing the introduction of new features and discouraging experimentation), what solution would you propose instead? I think it is an option, and I don't see why you're so insistent that it isn't. Authors are actually going to want interoperability; to get that, it's required. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpKXHP02UwFo.pgp Description: PGP signature
Re: [whatwg] input type=text accept=
On Thu, 8 Jun 2006, L. David Baron wrote: On Friday 2006-06-09 01:17 +, Ian Hickson wrote: Given that requiring a new flag per feature is not an option (as, as mentioned before, it would require a central authority to add these features, slowing the introduction of new features and discouraging experimentation), what solution would you propose instead? I think it is an option, and I don't see why you're so insistent that it isn't. Authors are actually going to want interoperability; to get that, it's required. I don't think it's an option because: input type=text required maxlength=80 name=subject spellcheck list=subjects value=Hey there inputmode=user startUpper ...or: input type=text required name=formula spellcheck=math inputmode=math highlight=math auto-evaluate ...or: textarea name=source rows=80 spellcheck=off autoindent=C++ highlight=C++ auto-evaluate=off ...gets out of hand very fast. input already has 27 element-specific attributes, plus 5 global attributes, plus 1 deprecated attribute, plus an uncountable number of event handler attributes. Going the road of one-attribute-per-feature would escalate that even faster, especially given that these features don't affect anything other than the way the user interacts with the input field (i.e. they don't affect the actual allowed values, etc). (Also, apparently Mozilla's implementors for this feature have received a request that the feature validate per HTML4's DTD. While I don't consider this a sensible request, and it doesn't affect my opinion of how the feature should be added, it is worth noting that accept= on input elements does current validate per the HTML4 DTD.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=text accept=
Le 8 juin 2006 à 21:17, Ian Hickson a écrit : I don't see a better solution. I'm certainly open to better solutions if there are any. What about input class=spellcheck /? It surely validates with HTML4, and it doesn't get in the way of any other feature. It does not really need to be part of the HTML spec either. I know that according to the current spec, the class attribute should carry no meaning whatsoever. But I ask the question: is this worse than implying that spell checking should be enabled or disabled based on a particular MIME type? The later could break spell checking when introducing new text types, say text/x-markdown, or text/x- mediawiki, for lightweight formatting syntaxes. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
