4 ms·

Please read the rest of what Ojan wrote: "In areas where libraries like MathJax are not good enough, we'd love to hear feedback about what APIs we would need to

by fishd 13y ago

Please read the rest of what Ojan wrote: "In areas where libraries like MathJax are not good enough, we'd love to hear feedback about what APIs we would need to expose so that MathJax, et al, can create an awesome MathML implementation." One of our goals is to make it possible to layer technologies as complex as MathML on top of Blink without requiring Blink to ship everything and the kitchen sink. See new technologies like Custom Elements (http://www.w3.org/TR/custom-elements/ http://www.w3.org/TR/custom-elements/), which are part of this story.

jokamoto 13y ago
That approach makes sense for technologies outside of the scope of the HTML5 spec, but for a core element like <math> it seems rather silly to propose external implementation using custom elements (and therefore requiring Javascript availability, which shouldn't be taken for granted).
- vidarh 13y ago
  The engine obviously does support javascript, so an alternative is ensure extensions can "plug in" these custom elements and implement them in JS in a separate sandbox regardless of whether JS is enabled or disabled for the page itself. Less code with direct OS access sounds good to me.
  - jokamoto 13y ago
    But you'd still have to download and install the extension in order to use it (or, as was somewhat glibly proposed in a comment on the bug, Google would need to ship a version of MathJax with Chrome). Anyone without the extension and with JS disabled would still be out of luck. So far as direct OS access, I'm having trouble envisioning a situation in which the layout code for MathML would be any more vulnerable than SVG (or the rest of the layout engine for that matter).
anon1385 13y ago
So why didn't you say that at the time this was being proposed? Now we have yet another part of the standards that people can't actually use because one browser vendor didn't like it for a vague reasons. It undermines the process to go around cheering for HTML5 and then later decide that you don't like it after all.
camus2 13y ago
Didnt XHTML stand for eXtensible HTML ? maybe XHTML was the right way at first place , just saying.
- gizmogwai 13y ago
  XHTML _was_ right. People were just too lazy to close there tags and did not really understood what would the consequences of not having a robust and formal way to extend the language. HTML went the same way other popular languages (e.g.: VB, PHP, Perl), they got broad adoption because the compiler/interpreter/renderer would be too kind in working hard to fix user mistake instead of reporting them. And then, when they tried to fix it, the same user base complain (despite being bitten many times by the language) that it should stay like it is, because it has always been like that. When bad habits became traditions, you are really in a bad position.
  - haberman 13y ago
    No: http://web.archive.org/web/20081211052740/http://diveintomark.org/archives/2004/01/14/thought_experiment http://web.archive.org/web/20081211052740/http://diveintomar... "The client is the wrong place to enforce data integrity. It’s just the wrong place. I hear otherwise intelligent people claim that if everyone did it, it would be okay. No, if everyone did it, it would be even worse. If you want to do it, of course I can’t stop you. But think about who it will hurt."
    - sixbrx 13y ago
      Hard to see how it would have been worse if all browsers had implemented stop-on-error, because then the developer/tester's browser would not have rendered the erronous page. That would mean that the developer/tester would have had to not try the page even once before shipping, if a bad page were to make it to production.
      - haberman 13y ago
        The page only became bad when the blog received a trackback from a different blog with a different character set. At that point the blog software erroneously changed the page's content and made it invalid. It was a software bug, plain and simple. The page was fully valid when the blog author published it. For the developer/tester of Typepad (the blog software) to catch the bug, they would have had to trigger this bug in development/testing before it made it into the wild. While we always hope developers will catch as many bugs as possible, some will always slip through. Strict validation on the client means that even the slightest bug can make the website 100% down/unavailable, even though the browser would be perfectly capable of displaying something that 99% works. Modern web sites are huge amalgamations of dynamically-generated content using umpteen templating technologies and aggregations of data that come from sources that the page's authors do not necessarily control. Guaranteeing that their output will always be valid XHTML is not trivial.

by fishd 13y ago

jokamoto 13y ago

That approach makes sense for technologies outside of the scope of the HTML5 spec, but for a core element like <math> it seems rather silly to propose external implementation using custom elements (and therefore requiring Javascript availability, which shouldn't be taken for granted).

vidarh 13y ago
The engine obviously does support javascript, so an alternative is ensure extensions can "plug in" these custom elements and implement them in JS in a separate sandbox regardless of whether JS is enabled or disabled for the page itself. Less code with direct OS access sounds good to me.
- jokamoto 13y ago
  But you'd still have to download and install the extension in order to use it (or, as was somewhat glibly proposed in a comment on the bug, Google would need to ship a version of MathJax with Chrome). Anyone without the extension and with JS disabled would still be out of luck. So far as direct OS access, I'm having trouble envisioning a situation in which the layout code for MathML would be any more vulnerable than SVG (or the rest of the layout engine for that matter).

anon1385 13y ago

So why didn't you say that at the time this was being proposed? Now we have yet another part of the standards that people can't actually use because one browser vendor didn't like it for a vague reasons. It undermines the process to go around cheering for HTML5 and then later decide that you don't like it after all.

camus2 13y ago

Didnt XHTML stand for eXtensible HTML ? maybe XHTML was the right way at first place , just saying.

gizmogwai 13y ago
XHTML _was_ right. People were just too lazy to close there tags and did not really understood what would the consequences of not having a robust and formal way to extend the language. HTML went the same way other popular languages (e.g.: VB, PHP, Perl), they got broad adoption because the compiler/interpreter/renderer would be too kind in working hard to fix user mistake instead of reporting them. And then, when they tried to fix it, the same user base complain (despite being bitten many times by the language) that it should stay like it is, because it has always been like that. When bad habits became traditions, you are really in a bad position.
- haberman 13y ago
  No: http://web.archive.org/web/20081211052740/http://diveintomark.org/archives/2004/01/14/thought_experiment http://web.archive.org/web/20081211052740/http://diveintomar... "The client is the wrong place to enforce data integrity. It’s just the wrong place. I hear otherwise intelligent people claim that if everyone did it, it would be okay. No, if everyone did it, it would be even worse. If you want to do it, of course I can’t stop you. But think about who it will hurt."
  - sixbrx 13y ago
    Hard to see how it would have been worse if all browsers had implemented stop-on-error, because then the developer/tester's browser would not have rendered the erronous page. That would mean that the developer/tester would have had to not try the page even once before shipping, if a bad page were to make it to production.
    - haberman 13y ago
      The page only became bad when the blog received a trackback from a different blog with a different character set. At that point the blog software erroneously changed the page's content and made it invalid. It was a software bug, plain and simple. The page was fully valid when the blog author published it. For the developer/tester of Typepad (the blog software) to catch the bug, they would have had to trigger this bug in development/testing before it made it into the wild. While we always hope developers will catch as many bugs as possible, some will always slip through. Strict validation on the client means that even the slightest bug can make the website 100% down/unavailable, even though the browser would be perfectly capable of displaying something that 99% works. Modern web sites are huge amalgamations of dynamically-generated content using umpteen templating technologies and aggregations of data that come from sources that the page's authors do not necessarily control. Guaranteeing that their output will always be valid XHTML is not trivial.