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] input type=text accept=
Quoting L. David Baron [EMAIL PROTECTED]: On Friday 2006-06-09 01:49 +, Ian Hickson wrote: I don't think it's an option because: [...] ...gets out of hand very fast. It may be out of hand (although I don't think it is), but it's much easier for authors and implementors to understand, and much more likely to be interoperably implemented, than what you're proposing. I tend to agree. If you just give some media type it's very unclear what the particular side effects of such a media type would be. Also, it's unclear what text/html would mean for things like syntax highlighting that are mentioned here given that you mostly edit a snippet of it and not a whole document. For spell checking you might want to provide an external dictionary file, because you think the UA might not support the language you accept input in or you're using some really special terms not commonly used. -- Anne van Kesteren http://annevankesteren.nl/
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] input type=text accept=
Anne van Kesteren wrote: If you just give some media type it's very unclear what the particular side effects of such a media type would be. No more unclear that the potential side effects of |class|, given the existence of microformats. Also, it's unclear what text/html would mean for things like syntax highlighting that are mentioned here given that you mostly edit a snippet of it and not a whole document. Hmm. We may need a fragment MIME type or something similar, like x-fragment/html. I don't see what baring that has on syntax highlighting, though. The MIME type would, however, be confusing with regards to possibly triggering a WYSIWYG editing feature. My suggestion would be that input type=text and textarea always be for text-based editing regardless of the MIME type, but this shouldn't prevent the use of type-specific macros and syntax highlighting. For spell checking you might want to provide an external dictionary file, because you think the UA might not support the language you accept input in or you're using some really special terms not commonly used. While the idea of supplying additional works for spell checking would be nice (especially in forums that deal with specific topics that tend to have their own vocabulary), I don't see the utility of enforcing the use of a specific language via a vocabulary list. If you really want to enforce the use of a language, I would think the |lang| attribute makes more sense. Using a list of vocabulary words would just be a pointless hack since you can't reasonably expect the UA to prevent submission based on spelling. If submission was suppressed, the first time you'd use a person's name in a text field, the submission would be blocked until you removed it.
Re: [whatwg] input type=text accept=
Michel Fortin wrote: 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. This is nothing more than storing boolean attribute values as classes. It's essentially a validation hack. 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. MIME types allow for things other than spell checking, like syntax highlighting and UI for tag insertion. For those purposes, a MIME type would actually be quite useful. I'd agree that it's a poor fit for spell checking, but considering there have already been suggestions for specifying the dictionary file to be used for spell checking, I suspect a simple true/false approach to spell check support may be too limited.
Re: [whatwg] input type=text accept=
Quoting Matthew Raymond [EMAIL PROTECTED]: If you just give some media type it's very unclear what the particular side effects of such a media type would be. No more unclear that the potential side effects of |class|, given the existence of microformats. As I understand Ian is what you do with a media type up the the implementation. From what I heard microformats have some formal definition on what is expected when you see a particular class name while a particular URI is inside the profile attribute of the head element. I'm not really sure why you're making this comparison either. [...] I don't see what baring that has on syntax highlighting, though. Highlighting omissions or errors for example... [...] I don't see the utility of enforcing the use of a specific language via a vocabulary list. It's not about enforcing or preventing submission at all. It's about aiding users. As far as I understand that's what the inline spell checking is for. -- Anne van Kesteren http://annevankesteren.nl/
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
