Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration finite foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf sheaves simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).

Atrium > Mathematics, Physics & Philosophy: formatting of theorem, proof, remarks

Bottom of Page

1 to 34 of 34

  1.  
    • CommentRowNumber1.
    • CommentAuthorUrs
    • CommentTimeJul 29th 2009

    I may be hallucinating, but i am wondering if the formatting by which theorem-, proof- remark-environments are being displayed has changed.

    In fact, currently it seems that none of these environments is having any visible effect whatsoever.

    I may be mixed up. Also, I keep working on the nLab with somewhat outdated software equipment, so there may be effects there in general but not on my side.

    But generally: I would like that all these environments are being displayed in a clearly visible and distinguishable format. Preferably with a little bit of indenting. For theorems and props and lemmas in some italicized font. It would be good if the end of a remark environment were clearly visible. Otherwise there is little purpose in using that environment.

    And notably: it would be great if proofs were ended by some common endofproof sign. I prefer a box.

    Does anyone know how to implement these wishes? Probably using the css functionality?

    • CommentRowNumber2.
    • CommentAuthorUrs
    • CommentTimeJul 29th 2009

    Darn, I take that back about the theorem and proof environments. It does display italics and endofproof symbols allright if one doesn't use outdated browsers.

    • CommentRowNumber3.
    • CommentAuthorTobyBartels
    • CommentTimeJul 29th 2009

    Yes, you need Javascript. Which I actually don't like, but as long as we need Javascript to edit … I'm using these too.

    What do you think about an end-of-proof box at the end of remarks? I should be able to put that in.

    • CommentRowNumber4.
    • CommentAuthorAndrew Stacey
    • CommentTimeJul 29th 2009

    There are some things that can be done with pure CSS. Take a look at the Frolicher spaces page for some ideas. I put the definitions, theorems, etc in boxes and indented the proofs. There are lots of other possibilities before invoking javascript.

    To get a good idea of just what is possible with CSS take a look at the CSS Zen Garden. There's just one page there but with lots of different CSS files and you can switch between them to see how much is configurable with mere CSS.

    It would be nice to do a bit of a make-over on the n-lab. I feel that we really need to exploit the fact that we're on the web. But also I guess it's more important to have good content than just display it nicely.

    • CommentRowNumber5.
    • CommentAuthorUrs
    • CommentTimeJul 29th 2009

    On my private web I am having trouble with numbered theorems. When I try to refer via \ref{bigdeal} to a theorem labeled bigdeal it seems what I get after hitting submit is the display of "\ref" then grayish "bigdeal" with a clickable question mark trying to make me create a new entry titled "bigdeal" and then the closing "}" .

    Does anyone have an idea?

    • CommentRowNumber6.
    • CommentAuthorUrs
    • CommentTimeJul 29th 2009

    So suppose I wanted to tweak the appearance of theorem-environments or similar, say on my personal web, via css. What can I do?

    I should say maybe that my general impetus here is that I am feeling we'd need more formatting structure on nLab pages. Somehow long nLab pages tend to look like a huge chunk of material without good structure. Even if they use remark/theorem/etc environments a lot.

    A related feature that is badly missing: automatic tables of contents on each page, as Wikipedia has it.

    • CommentRowNumber7.
    • CommentAuthorTobyBartels
    • CommentTimeJul 29th 2009

    I don't know what's happening on your private web, but one unavoiodable bug with the theorem numbering and labelling system is that you must label every numbered item. (Well, it's OK if you label none of them, or even label the first ones and not the last ones, but you can't pick and choose.) I forget how, but intermittent labelling will mess up the cross-referencing; perhaps that's what's happening here.

    • CommentRowNumber8.
    • CommentAuthorTobyBartels
    • CommentTimeJul 29th 2009

    I don't find the theorem environments very structuring, actually. The only structure that I see, when I casually look over an article, is that provided by the headers. It might be nice to have more variation in style between different levels of headers (again like Wikipedia).

    • CommentRowNumber9.
    • CommentAuthorUrs
    • CommentTimeJul 29th 2009
    This comment is invalid XHTML+MathML+SVG; displaying source. <div> <blockquote> I don't find the theorem environments very structuring, actually. </blockquote> <p>Exactly, that's what I am saying: it would be good if we could change them so that they become more structuring.</p> <p>What can I do to achieve this?</p> </div>
    • CommentRowNumber10.
    • CommentAuthorTobyBartels
    • CommentTimeJul 29th 2009

    If you have someting specific in mind, then I might be able to help you write the CSS for it.

    Personally, I don't like texts structured by definition/theorem/remark, so I really don't have any good ideas for how to design styles for such a structure. (And I would not like them to interfere with pages that are structured differently.)

    • CommentRowNumber11.
    • CommentAuthorAndrew Stacey
    • CommentTimeJul 30th 2009

    Urs wrote:

    On my private web I am having trouble with numbered theorems. When I try to refer via \ref{bigdeal} to a theorem labeled bigdeal it seems what I get after hitting submit is the display of "\ref" then grayish "bigdeal" with a clickable question mark trying to make me create a new entry titled "bigdeal" and then the closing "}" .

    Can you give a link to the page where this is happening?

    • CommentRowNumber12.
    • CommentAuthorAndrew Stacey
    • CommentTimeJul 30th 2009

    I agree that we could do a lot with regard to design. We should use the fact that this is on the web to make it different to a printed page. Having one long page full of definition-theorem-proof is a bit dreary.

    Over at Frolicher space then I've tried to tweak the basic design a little by putting definitions in boxes and indenting proofs, but while I think it's a bit better than the standard layout on the n-lab I don't think that it qualifies as a good design.

    Presentation is important. Content is primary, but presentation comes a pretty close second. My basic problem is that I have no picture of what a good layout would be. Maybe we need to hire a graphic designer!

    • CommentRowNumber13.
    • CommentAuthorUrs
    • CommentTimeJul 30th 2009

    Andrew,

    let me try to reproduce the problem I had, because currently it's no longer presentable since I removed all numbering that caused problems for me.

    Concerning the design question: yes, that's exactly how I am feeling, too. I feel a desire to get better formatted pages, but I am not really sure myself how that should work. That's why I am also not sure how exactly to reply to Toby's last comment.

    Maybe it helps to start with concentrating on this specific problem:

    on my private web there was some long bit of text. Then Jim stasheff came along and suggested that I mark one paragraph of it as "Remark" so that the reader would get an indication that that particular paragraph might possibly be skipped on first reading.

    So I added a remark.environment from the theorem-proff etc environments lists to enclose that paragraph. But then notice that the formatting result was exactly null.

    • CommentRowNumber14.
    • CommentAuthorMike Shulman
    • CommentTimeAug 29th 2009

    I second the suggestion of more variation in style between different headers. Maybe we could also make top-level headers in a smaller font; right now they look too big and ugly to me.

    • CommentRowNumber15.
    • CommentAuthorTobyBartels
    • CommentTimeAug 29th 2009

    I try to use ## as the biggest header (same as Wikipedia, as it happens). The title up top is already an <h1> anyway, so it really seems more correct if the next header is <h2>. To some extent, this fixed the big-and-ugly problem.

    • CommentRowNumber16.
    • CommentAuthorMike Shulman
    • CommentTimeAug 30th 2009

    Yeah, I often do that too. (-: But not everyone does. And regardless, it would also be nice to be able to tell the difference between ## and ### more easily.

    • CommentRowNumber17.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 31st 2009

    Maybe we should do a mathematical version of the CSS Zen Garden. Choose a page that has a good selection of headers, theorems, proofs, definitions, and the like (or devise one specially) and then play around with the CSS to see if we can find something that looks a little better than the "standard" one.

    • CommentRowNumber18.
    • CommentAuthorUrs
    • CommentTimeAug 31st 2009

    Concerning markup for headlines:

    I am among those who tries to consistently markup top-level paragraphs with a single #.

    I agree that the way this is formatted by the software is suboptimal. but I'd think the conclusion to be drawn from this should not be that we start the first paragraph with double ##.

    I think we should use the features as intended. If it doesn't come out right, we should try to fix the way the software works instead of starting to use funny workarounds. Can't this be done easily by tweaking the CSS features (maybe no, i amjust asking).

    As Michael notes, there are more problems, such as that the difference between the formatting of ## headline ## and ### headline ### and #### headline #### is hard to spot and hence doesn't serve its purpose properly.

    But this means first of all that using double ## instead of single # tries to work around one problem only to run into the next.

    The only good solution here is that eventually we find a way to change the way the software goes about formatting of headlines.

    Ideally, I'd think. an nth order headline should not only have an easily distinguishable (and nice) font, but also explicitly start with something like "II.3.a)" or whatever, maybe using indention, something that makes it crystal clear to the reader at which level he or she is reading.

    And even more ideally, the software would automatically produce a clickable table of contents.

    I have to admit that I can't really tell how likely it is that anyone finds a fix for this. But using hacks that wrok against the intended markup system makes me nervous. For instance it will make the source code that we produce less easily portable to other wikis.

    • CommentRowNumber19.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 31st 2009

    I don't know about the table of contents (though I agree it sounds a good idea in principle), but certainly the headers are distinguishable by CSS. The problem with using the top level headers in the main document (that is, using #) is that the code produced is an h1 which is the same as the page name. However, the h1 corresponding to the page name gets an id tag ("pageName") which means that it can be selectively styled using CSS. Thus by using CSS we can apply one style to the h1 showing the page name and another to the h1s in the page. That way, we can actually make the ones in the page look as if they were h2s, for example. CSS is the answer!

    As for section numbering, I'd imagine that Jacques' hack for theorem numbering could be adapted to that. Looking at a typical page source, I see that there's a certain amount of numbering going on already. I'd need to understand how the whole lot works a little better to be able to say whether it was difficult or not, but I'm strongly betting on "possible".

    • CommentRowNumber20.
    • CommentAuthorTobyBartels
    • CommentTimeAug 31st 2009

    The reason that I start with ## is strictly semantic; it is because there is already an <h1> on the page, so the next subordinate header should be <h2>. (I don't change what others have written, as long as it's consistent and I'm not redesigning the whole page.) Being less big and ugly is only a bonus.

    Other than that, I agree with everything in Urs's comment (18). In particular, all of the various other concerns about the style of the headers can and should be fixed by improved CSS.

    Incidentally, MediaWiki does automatic section numbering, not just in its TOCs but also throughout the text; it's just turned off by default for some reason.

    • CommentRowNumber21.
    • CommentAuthorMike Shulman
    • CommentTimeAug 31st 2009

    Perhaps we should take the point of view that an <h1 id="pageName"> is semantically an "h0"? I do think it would be better in principle to follow what is clearly intended by the Markdown syntax, namely that # is used for top-level headers in the text being written (the page name being outside of this text and thus at a higher level), and fix the big-and-ugly problem with css.

    • CommentRowNumber22.
    • CommentAuthorTobyBartels
    • CommentTimeAug 31st 2009

    We can take that point of view, but HTML does not. (Not that it's a big deal, since people generally read HTML+CSS, not HTML.)

    • CommentRowNumber23.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 31st 2009

    I think that anyone who's reading the nLab in pure HTML has enough problems already that we can safely say that if they can overcome those then they're not going to be bothered by the difference between h1 and h2! I guess one of the reasons for CSS is that the HTML spec is too limited and that h1 in one part of the page is not the same as h1 elsewhere. One place where this might be true (haven't checked it) is with text-only browsers (lynx, for example) and I don't know what they do with CSS. We probably ought to think a little about non-standard (i.e. non-Firefox!) access and how accessible we are.

    Other than that, I agree with what Mike and Urs said. I think that we should have a go with the CSS and see what looks good, then if there is anything more that needs doing we can fiddle with the filters, but I suspect that actually we'll be able to do it all with CSS.

    • CommentRowNumber24.
    • CommentAuthorMike Shulman
    • CommentTimeSep 1st 2009

    Well, since we use MathML extensively, that already limits our accessibility noticeably, probably more than CSS does. Are there any text-based browsers that support MathML? I've been told that IE supports MathML if you install a plugin, but I haven't actually tried it -- from a practical point of view that would probably be the next most important browser to support after Firefox.

    • CommentRowNumber25.
    • CommentAuthorTobyBartels
    • CommentTimeSep 1st 2009

    Are there any text-based browsers that support MathML?

    Yes, links (not lynx).

    • CommentRowNumber26.
    • CommentAuthorTobyBartels
    • CommentTimeSep 1st 2009

    (Example: \Delta _ x : x \to x \otimes x became D x:x->x(x)x.)

    • CommentRowNumber27.
    • CommentAuthorMike Shulman
    • CommentTimeSep 2nd 2009

    I suppose "support" has to be used somewhat loosely in this context. For many people (certainly for me) it would probably be easier to read the raw itex than that. (-:

    • CommentRowNumber28.
    • CommentAuthorUrs
    • CommentTimeSep 2nd 2009

    Concerning IE:

    yes, it is quick and easy and free to install the "MathPlayer" plugin. That works very well with IE.

    We should maybe add a highlighted notice to our welcome page with something like "If you don't see the mathematical typesetting on the $n$Lab at all or not in a pretty-printed fashion, you may have to download a plugin or use another browser alltogether. See here for details".

    Well, since i said it, I sould do it. I'll do so now.

    • CommentRowNumber29.
    • CommentAuthorAndrew Stacey
    • CommentTimeSep 2nd 2009

    yes, it is quick and easy and free to install the "MathPlayer" plugin. That works very well with IE.

    Not on my system it isn't! Apparently, you need administrative privileges to install it which I don't have on one of the windows systems I have access to. The other (on which I do have sufficient privileges) can't connect to my university wireless network so I can't download it, and if I transfer it across it wouldn't help as I couldn't see any pages!

    • CommentRowNumber30.
    • CommentAuthorUrs
    • CommentTimeSep 2nd 2009

    Okay. Well, you are probably not using IE in the first place, are you?

    • CommentRowNumber31.
    • CommentAuthorAndrew Stacey
    • CommentTimeSep 2nd 2009

    No, but after Zoran's problem mentioned on the lab I thought it might not be a bad idea if I at least had a look to see what it looks like in IE. I'm also using Instiki for the course I'm teaching here and some of the students may be using IE. However, all my attempts were futile.

    Smug? Me? Nah.

    • CommentRowNumber32.
    • CommentAuthorMike Shulman
    • CommentTimeSep 2nd 2009

    Ooh, that bothers me. I was hoping to use instiki for a course I'm going to be teaching this year. (So I'd be interested in hearing about your experiences sometime, perhaps over email.) I presume that you also need Administrator privileges to install Firefox, so anyone on a Windows machine without Admin privileges and only IE installed is out of luck. I guess one could try to configure instiki to use BlahTeX instead of MathML (now I'm thinking about course websites, not the nlab).

    • CommentRowNumber33.
    • CommentAuthorUrs
    • CommentTimeSep 2nd 2009

    I used instiki for this course here.

    The students said they found the wiki pages helpful.

    I never thought of warning the IE users among them, admittedly, but I also never got a complaint on non-readable entries, so I figure they all used non-evil browsers :-)

    • CommentRowNumber34.
    • CommentAuthorTobyBartels
    • CommentTimeSep 2nd 2009

    My advice: Check to see what's installed on the machines that the school makes avialable to students. If Firefox is there, then tell them to use that if IE gives them problems.

1 to 34 of 34

  1.