- From: Frédéric Wang <fwang@igalia.com>
- Date: Mon, 1 Aug 2016 19:26:24 +0200
- To: www-math@w3.org
Le 01/08/2016 à 18:45, David Carlisle a écrit : > > white space is always a problem:-) but I'd be sorry to just drop this > completely, it's a well established feature of math typesetting (in TeX > and elsewhere) that user-whitespace is ignored and the math typesetter > re-adds white space as needed. That said, I agree that the fact that > TeX treats 1+2 like 1 + 2 doesn't necessarily mean that mathml should > treat <mo>+</mo> like <mo> + </mo>. If the trimming could happen during > text/html parsing that would simplify some things. TeX-to-MathML converters trim and collapse the whitespace and that's probably the same for other MathML generators. So that's why I don't see it's needed to be done again by renderers. > Do you mean the attribute values or the attribute names? Values. > >> 4) MathML boolean attributes take value "true" and "false". In HTML5, >> the boolean value is given by the presence/absence of the attribute and >> the only allowed value is the name of the attribute. This allows to get >> more compact syntax like <mo largeop stretchy> instead of <mo >> largeop="true" stretchy="true">. However, Web engines and authoring >> tools will continue to support the true/false syntax anyway, so it's >> probably not worth adding complexity here... > > I don't think allowing stretchy=stretchy as an alternative to > stretch=true would break anything on the XML side of things, and would > potentially, as you say, allow just stretchy in text/html using its > version of the old SGML shorttag feature. You could say more than me > whether that would simplify or complicate things at implementation level. My guess is that it will add more code if we do not remove the current MathML syntax (which I guess we don't want as that will break all existing documents). But maybe it's the nex syntax is not too much to add if it's really something users want. >> >> https://www.w3.org/TR/html5/infrastructure.html#boolean-attributes >> >> 5) As I said in a previous message, the values "small", "normal", "big" >> of mathsize do not exist for CSS font-size. Removing them will simplify >> a bit the parsing code. > > Are these conceptually more difficult than css names like > small,medium,large,x-large? (just asking:-) True, I forgot these keywords. I'll have to read the Gecko/WebKit code to check where these values are resolved. But as I see the lists of keywords are different so we won't be able to use exactly the same code anyway. > >> >> 6) The definition of numbers is also not very accurate in the MathML >> recommendation compared to HTML5. One has to check the RelaxNG schemas >> and the predefined RelaxNG types to know the exact syntax. > > Well hopefully section 2.1.5.1 > https://www.w3.org/Math/draft-spec/mathml.html#chapter2_id.2.1.5.1 > is reasonably exact (but the main point that it's not exactly the same > as HTML5 is of course undeniable) Yes. Note that HTML5 is also very accurate about the parsing steps, so it could be worth just reusing the HTML5 definitions so that web engines implementers don't have to check the differences.
Received on Monday, 1 August 2016 17:39:10 UTC