Hi Jacques,
As one of the people who will be using the nLab, I wish to say thanks for all your expert assistance. I am excited to be part of a project which is at the cutting edge of math on the web. To any others listening in: what we do here is important. Jacques’ mathML magic here is part of the data being used by the folks behind Mozila to steer the future of math on the web. So let’s get a good system going!
Urs summarized the difference between the nLab and the n-category cafe as:
You come here to work and go there to chat.
Now the way I see it, if people are going somewhere to work then the ease-of-use of entering math takes on a higher priority (I like the keyboard shortcuts in this regard). I know when I actually want to do some maths, I’m very particular about having the right kind of paper and the right kind of pen!
With this in mind, I have the following questions.
1. I think we badly need to have a “Preview” button when you edit pages… this seems a high priority when one is entering a lot of math.
2. What is the possibility of getting to the point where users can enter their own pre-defined LaTeX macros, definitions, etc.? Can this be handled in the system… even if it means going to javascript? I know there is no concept of a ‘user’ in Instiki at the moment, but perhaps there is some possibility.
Here is a simple system that could work until a more advanced one comes along: just keep a page of site-wide macros, which all the users can edit, eg. containing things like \newcommand\X{\mathcal{X}}. In the edit text for a page, this will appear as \X.
If and when users get added to Instiki, then each user can add their own specific macros, which will get expanded out in the edit text of a page, so as not to cause conflicts. For instance, John Sampson could define his own macro \newcommand\X{\mathfrak{X}}, and then when he types \X on the edit page it will produce a mathfrak{X} in the final HTML. When he edits the page again, he sees \X, but if other users edit the page, they see the expanded macro, i.e. they will see \mathfrak{X}. What do you think?
3. I am very excited by the idea of getting math and SVG to work in a commutative diagrams package. What are your latest ideas on this since you wrote this and this? By the way, I think those diagrams look great… it makes one much more inspired to read a gimungous Urs-style diagram when it comes out nicely like that. This is going to be critical for the nLab.
In order for a command like \mor{ur1}{B}{} to place a label on an arrow, foreignObject would need to be able to compute the size of the box containing its content (in this case, “”) and, that knowledge in hand, compute its own position relative to the arrow it’s labelling.
Is this still a big stumbling block? Is there any light on the horizon? I’m thinking that if worst comes to worst, surely a javascript solution could work. After all, Davide Cervone must have been performing these kinds of calculations with jsMath.
Perhaps you don’t like a javascript solution, because it seems cludgy. I appreciate that, but it might turn out to work nicely… speed problems shouldn’t be an issue, because there won’t be that many commutative diagrams on a page, even at the nLab.
4. I guess part of what I’m asking for above is how easy it will be for users to develop “plug-ins” for Instiki.
Re: nLab
Error 503.