Weirdly, it seems[0][1][2], that the layout doesn't do particularly well by Carpalx's keyboard effort estimator[3], as it gets a total effort score of 2.260, compared to 3, 2.098 and 1.842 for Qwerty, Dvorak and Colemak, respectively[4] (lower is better). In contrast, the halmak repo claims[5] an efficiency gain of +134% over Qwerty for halmak, compared to +77% for Dvorak and +84% for Colemak. Since (one would assume) efficiency and effort should be approximately inversely correlated, these results don't square.
I have no idea whether Carpalx's or Halmak's keyboard layout (efficiency|effort) evaluator is more accurate (indicative of real (efficiency|effort)), but the huge disparity between the two is troubling.
(Obviously, Carpalx and Halmak use different optimisation methods — Monte Carlo simulated annealing versus an "evolution algorithm based AI" — and these could well give different results, even with the same scoring method, due to getting stuck in different local maxima etc., but the issue is that the scoring methods themselves give different rankings of fixed keyboard layouts.)
Edit: quickly reading through all of the halmak author's blog posts, it seems that they're aware of the Carpalx project. They describe their (current?) effort model here[6]. It seems heavily data-based, but it's still difficult to determine whether it's "better" than Carpalx's.
They dropped their implementation of MathML in 2013. In the six years since then, they didn't fix it or replace it with a better one.
I'm extremely excited by Igalia's work on MathML and glad that the Google Chrome team had given it their preliminary approval, but in the context of criticising Google for working on the "application web" and ignoring the "document web" (for scientists and others), it doesn't change anything[0]. Google is neither doing the work, nor funding it[1], and their contribution until now has mostly (solely?) been to be open about merging it.
[0] not that you explicitly said that it did...
[1] It's funded by the NISO and the Alfred P. Sloan Foundation.
> Does anybody know where I can/should host a copy?
With torrent or IPFS, perhaps? (Given the CC BY-SA license, this would be completely legal.)
Also, GitHub's behaviour wrt to LFS is really disappointing — the epub file could have been stored normally with git (its size of ~ 3 MB is far less than the hard limit of 100 MB), in which case there would have been no issues of exceeding a data quota...
For comparison, the linked PDF is normally indexed with git, despite weighing at 7.7 MB.
Since LFS is supposed to reduce total bandwidth use for the hoster, GitHub is, in effect, punishing people for reducing GitHub's bandwidth usage...
Actually, the linked PDF is originally[0] by the same author as the EPUB version you linked. However, in the original repository[0] the PDF is managed with LFS, so it's inaccessible...
If, in about:config, you set ui.key.accelKey to 91, then Super-W will close a single tab (and Super-T will open a single tab etc.). This obviously won't work in Chromium, though.
Celestia[0][1] can just about do it. In principle, it can show you what you'd see from any point in space. In practice, it's limited by the data it has (for stars, it uses the Hipparcos Catalogue, which only contains ~ 100,000 stars of the ~ 250 billion that are in the Milky Way) and displays the Milky Way, outside our "immediate" neighbourhood (i.e. several hundred light years), as just a set of amorphous blobs. Hence you can visualise the Milky Way as seen from the edge of the galaxy, but it'll be rather blurry. (It also obviously doesn't include the newly discovered warped shape.)
Edit: For this purpose, I think that this "Chrome Experiment"[2], might be better.
Also see "Gaia Sky"[3] which I haven't tried, but which looks really interesting and may well do what you want.
Depending on what you mean by "in some future update" and "pretty much guaranteed" (given an infinite timespan everything will disappear) I don't think that's true. I've kept my Firefox user.js (my manual about:config changes) under git over the past 3 years[0], and of the 44 options that I customised, 36 are still present and (seem[1] to be) active.
6 of the about:config user_prefs customised add-ons, so they no longer work due to the shift to Webextensions (but I can still make 5 of the customisations via another interface).
1 customised the GCLI, which was removed, and 1 customised Panorama, which was also removed. (However, most of what GCLI did, can be done some other way, and there are a couple of Webextensions faithfully emulating Panorama.)
[0] The file is older, but I added it to git only three years ago. Hence, many of the about:config changes have been "alive" for longer, but I have no record of those that were removed earlier than 3 years ago.
[1] Cursorily glancing through my comments above each entry to make sure that it still does what it was supposed to.
This is an interesting, thought-provoking comment!
> (though the original MathML proponents perhaps did not)
FWIW I'm pretty sure that they did. Arguments to authority are pretty terrible, but if you look at the authors of the MathML 1.0 (earliest) or 3.0 (latest) specs[0][1], and google them, you can see that many of them have backgrounds in science or math and have been active in the LaTeX ecosystem.
> but this [quality of the typesetting] has been mostly underestimated/ignored by those advocating MathML.
I don't see any evidence for this, not among its designers, implementers or even general proponents.
Firefox's output (implemented almost(?) entirely by individual volunteers), for instance, is acknowledged to be still considerably worse than LaTeX output in a pdf, though it is competitive with its web alternatives (superior in some respects, worse in others) — do be sure to install MathML fonts[2] though.
> 5. What the result [...] will be, in the web page's DOM.
Have you seen the tag soup generated (by necessity) with MathJax or KaTeX?
I guess when I say “MathML proponents” I ought to be more careful in my thinking to make a distinction (even if they are often the same people) between those working on MathML as a project, and those advocating for its actual use today under current conditions. I have no problems with the former; I wish them good luck and look forward to trying the result when it's ready. For the latter, I can only say that anyone advocating using MathML today despite its problems (poor layout and browser support) clearly cares about something else more than they do about actually communicating mathematics to humans.
No doubt among the authors of the MathML specs there are people who care about typesetting. Though I'll note that being active in the LaTeX ecosystem is not a guarantee of this: the prime example is the author of LaTeX (Leslie Lamport) himself, who makes a pitch for the LaTeX model around (mostly) not caring about the appearance: https://lamport.azurewebsites.net/pubs/document-production.p... — in contrast with Knuth who devotes the largest (despite smaller font size) chapter of The TeXbook to Fine Points of Mathematics Typing. (A blog post by one of the authors of the MathML spec you linked to: https://blogs.msdn.microsoft.com/murrays/2011/04/30/two-math...) In fact some of the worst mathematical typesetting I've seen is by people who wrote in LaTeX and blindly trusted it to produce the best typesetting, and sometimes even ignored the warnings about overfull/underfull lines.
Looking at the MathML sample page in Firefox (https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Proje...), there are many that are worse and none that is better that TeX's output (which for some reason is given on the page in low-resolution images rather than high-dpi images or SVG) — and in any case if you feel that some are subjectively better, it's still the case that the aesthetic most everyone wants is “like TeX”. And personally I've seen very little by Firefox/MathML people on their layout decisions (if they decided to do things differently from TeX, why?), while with MathJax I've seen that if their output is found not to match TeX's it is treated as a bug report and a fix attempted. What are the some respects in which you say Firefox's output is visually superior to MathJax's? Is there a page demonstrating them?
> Have you seen the tag soup generated (by necessity) with MathJax or KaTeX?
Yes, and it's not pretty. But (1) among the list of things to care about this is the lowest of the low, as it does not affect what is visible to the user, and (2) the tag soup of MathML, though shorter, has still all the XML ugliness so it's not as if it will ever be readable. (In fact looking at the comparison of different input formats https://en.wikipedia.org/w/index.php?title=MathML&oldid=8864... for sufficiently complex equations even the TeX/AsciiMath inputs become unreadable; the well-typeset visual representation may be the only somewhat readable one.)
> For the latter, I can only say that anyone advocating using MathML today despite its problems (poor layout and browser support) clearly cares about something else more than they do about actually communicating mathematics to humans.
Much of the reason people are in favour of providing MathML output is that if nobody did, then the likelihood of Chrome getting MathML support would have been near zero (and the risk of Firefox removing its existing (if imperfect) implementation, high). (A chicken and egg problem.) Since MathML is likely (you may disagree — but you must agree that it's plausible that if a JavaScript solution can do it, a native one can probably do it better) to lead to better equation typesetting on the web, once it's properly implemented, people advocating MathML today can very much care about better communicating maths to humans, in the long run. Also, MathML is not incompatible with MathJax — in fact, since MathJax's internal representation of equations is similar to MathML's, converting from MathML (to SVG/HTML+CSS/whatever) is faster than converting from TeX — so it's not as if providing MathML in the document dooms your readers you to its "ugly" output. (And yes, MathML can be both an input and an output for MathJax...)
> [...] (which for some reason is given on the page in low-resolution images rather than high-dpi images or SVG) [...]
That's because the page was made several years ago, when such images were the norm (look at a Wikipedia page on the Archive from even 2016), and hasn't seen significant updates since, because MathML was feared dead (due to Chrome, at the time, explicitly rejecting support) and volunteer effort dried up. Somebody™ should update this...
> Looking at the MathML sample page in Firefox [...], there are many that are worse and none that is better that TeX's output
For the little that it's worth, IMO five are worse, two are slightly better and the rest just as good as the TeX.
> And personally I've seen very little by Firefox/MathML people on their layout decisions (if they decided to do things differently from TeX, why?), while with MathJax I've seen that if their output is found not to match TeX's it is treated as a bug report and a fix attempted.
Far more people work on MathJax than on MathML — MathJax has a two-member team, plus support from AMS, plus volunteers, while MathML has only had occasional volunteers (see above; not that it was much better previously), so it's not a fair comparison. Also the page comparing TeX with MathML was made by the people in favour of MathML precisely because they care about trying to achieve parity with TeX.
> What are the some respects in which you say Firefox's output is visually superior to MathJax's?
For instance the speed with which the output is rendered. Several second latency for better final appearance might be a bargain you want to take, but it's still a visual trade-off. (You can use server-side MathJax, but then you lose some end-user customisability.)
> the tag soup of MathML, though shorter, has still all the XML ugliness so it's not as if it will ever be readable.
How else would you expose the structure of an equation, to the DOM, than with XML ugliness? It's just important that the XML ugliness makes sense (and MathML's does).
XML is faster and far simpler to parse than TeX. To the extent that you need to (if for whatever reason you don't want to rely on a LaTeX to MathML or Ascii to MathML converter) you can make the quadratic equation MathML slightly more readable, by not using hex entities, but unicode for − and ±, and the named entity for ⁢.[0] Furthermore, you (and I!) are just far more familiar with TeX, which makes the comparison in readability not particularly fair. Finally, much of the invisible, seemingly redundant mark-up, such as ⁢ or ⁡, can help you avoid some of TeX's ambiguities — e.g. is $ f(a+x) $ the function $f$ acting on $(a+x)$ or $f$ multiplying $(a+x)$?[1] If you were to omit this mark-up (and if you're converting from TeX to MathML and don't want your converter to engage in guesswork, you have to) the MathML would be even simpler.
Using the same format for equations as for the rest of the document (i.e. HTML/XML) is advantageous (in addition to the parsing benefits). In particular, you can use the same mechanisms for styling and transforming elements, as you can for the whole document. For instance, you could easily style parts of an equation, provide pop-ups that explain what each symbol means, when you hover over it, or interactively change the equation. (Much of this hasn't actually been done, outside experiments, because only Firefox properly(-ish) supports MathML, so it would have been wasted effort.)
[1] Presentation MathML is still obviously not semantic, but it can be better in this respect than default TeX — there have been proposals for semantic TeX, but none of them have really caught on.
XML and readability are orthogonal concepts in the end. Basic html is easily editable and readable by humans. There is nothing preventing them from making an actually human editable XML markup language for maths. And that is the sad part.
As MathML is not human readable nor editable it’s effectively an opaque image format that can be manipulated from JS side and that scales like vector graphics.
When you write web-pages, do you usually write the raw HTML or do you use something like Markdown or Wikitext and have it converted to HTML? If the latter, then why would having LaTeX as part of the input and MathML as part of the output, be any different?
Also, directly converting TeX to MathML, even client-side, is much easier and faster than MathJax's many-to-many approach (I'm not criticising MathJax — given the constraints, they're doing the best possible job).[0][1][2] (See also the Ascii to MathML converter[3] that has already been mentioned in another comment.)
Most people who write for the web probably do indeed write in something like markdown, which means they probably sprinkle in a bit of HTML for the parts which markdown doesn't natively support. I imagine a lot of blog posts written in markdown contain a few <table> elements, for example. Anyone writing math content for the web using markdown will have to either write the mathml directly, or write the math expressions in another language and manually compile it to mathml which is copy/pasted into the document. Maybe the CMS they happen to use will some day add native support for compiling latex, but that sounds rather unlikely.
Pandoc and Mediawiki have been able to convert embedded LaTeX to MathML, for a while. Once Chromium supports MathML most CMSs will probably start providing suitable converters, and in the meantime MathJax will still work (and better, since MathJax's Native MathML output is faster than its CommonHTML one[0]).
Think of MathML more like SVG. You can write it by hand (and in some cases you should), but in most cases you should use a graphical editor (like inkscape), or a library (like D3).
This is exactly the property that makes it actively worse than TeX notation. It makes equations a second class citizen compared to text because you can’t write them comfortably without external tools. MathML is a failure - because of its ludicrous verbosity. The correct solution may not be TeX notation, but it can’t be this bad a step backwards in usability.
In either case, you can use TeX as your input, and if you do, you have to convert it, client-side or browser-side, into something usable by the browser; it's just that if the browser accepts MathML the rendering is faster and/or more convenient, plus you get other options.
Sorry, my claim was about the two notations: that the TeX one is writable, and the MathML is not.
I’m not claiming that a JavaScript parser and complete renderer for TeX is better than a JavaScript parser that renders via MathML. The second option may indeed be more efficient - but making the browser parse a sensible notation for maths instead of an XML crapfest would be better than either.
I don't see why rendering TeX formulas would be slower than rendering MathML. It should be possible to maintain implementations for both variants with similar performance. MathML's parser should be simpler though, cause it's XML, which already has many efficient parsers.
In addition to the already mentioned performance issue with client-side MathJax, having native MathML makes it conceptually far simpler to do more complex things with equations, both for the end user and for the developer.
For instance, as a user, if you want to scale the equations by some amount or use a different maths font, it's a couple of lines of CSS, using exactly the same method you'd use to make any other changes to the appearance of a web-page. (Yes, you can easily do the former with MathJax, but I don't think the latter is possible user-side).
As a developer, if you'd want to interactively highlight parts of an equation, for educational purposes, it'd be trivial with MathML, but rather hard to do nicely with MathJax (statically coloured elements are possible with MathJax, with the "color.js" extension, but not dynamically coloured ones — and no, swapping out the entire equation to make colour changes is neither nice nor scalable). Alternatively, if you want to embed equations in a diagram or a graph, it's pretty easy with MathML[0][1], but would be difficult otherwise.
Obviously, all of the above is in principle possible with JavaScript implementations, but it's far harder. You might argue that this extra effort is worth the smaller attack surface. IMO, given the importance of maths and science, it isn't.
Also, why do we, say, have the CSS flexbox layout? After all, we could have used javascript to arrange elements into an appropriate table or even just set the x and y positions of all elements...
I have no idea whether Carpalx's or Halmak's keyboard layout (efficiency|effort) evaluator is more accurate (indicative of real (efficiency|effort)), but the huge disparity between the two is troubling.
(Obviously, Carpalx and Halmak use different optimisation methods — Monte Carlo simulated annealing versus an "evolution algorithm based AI" — and these could well give different results, even with the same scoring method, due to getting stuck in different local maxima etc., but the issue is that the scoring methods themselves give different rankings of fixed keyboard layouts.)
Edit: quickly reading through all of the halmak author's blog posts, it seems that they're aware of the Carpalx project. They describe their (current?) effort model here[6]. It seems heavily data-based, but it's still difficult to determine whether it's "better" than Carpalx's.
[0] https://gist.github.com/tdegrunt/80e63f464c9a1c336e0f1d4e6aa...
[1] https://github.com/MadRabbit/halmak/issues/4#issuecomment-44...
[2] I haven't done the analysis myself and can't be sure that it was done correctly
[3] http://mkweb.bcgsc.ca/carpalx/?interpreting_optimization
[4] http://mkweb.bcgsc.ca/carpalx/?keyboard_layouts
[5] https://github.com/MadRabbit/halmak#comparisons
[6] http://nikolay.rocks/2016-10-22-keyboard-analytics