Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
Is it possible to add some CSS or something such that nLab pages display subsectios of depth 6 ?
See at Sandbox currrently for an example of how a depth-7 headline is not displayed corretly .
HTML (on which XHTML is based) is hard-coded to only allow six levels of nesting: http://www.w3.org/TR/html4/struct/global.html#edef-H1. It would appear that XHTML2 allows more (see http://www.w3.org/TR/xhtml2/mod-structural.html#edef_structural_section) but this is still a draft. I don’t know what HTML5 offers.
Anyway, so for the moment we’re stuck with 6 levels.
(Were I feeling a bit cheeky, I might say that I would have thought 6 levels of sections enough for anyone.)
so for the moment we’re stuck
Okay, thanks for the info.
I might say that
I know.
As I understand it, h1, h2, … h6 are just a historical holdover from HTML - there is nothing magical or special about those tags other than if you lose the custom CSS for a XHTML page it might display somewhat correctly. Their intent can easily be expressed using “class” and such an approach is often considered “cleaner” - e.g. using CSS selectors like div.H00, div.H01, … div.H99. One could also employ a “backwards compatible” approach such as h1.H01, h2.H02, … h6.H06, h6.H07, … h6.H99 or some arbitrary choice like h3.H00, h3.H01. … h3.H99.
Of course such a rational approach is easier if a system is initially designed with it. Retrofitting it into an existing system could be a pain for little seeming gain - in particular you need to check for browser bugs.
I would support Rod's backward-compatible approach. The question is whether we can actually program this. It seems to me that it would have to be done at the level of Instiki.
We could report this to Jacques as a bug. Since <h7> doesn't exist in XHTML 1, producing it is a bug. Then we could suggest producing <h6.h7> instead (and similarly for higher). If that's done, then it's up to us to define the CSS for it. (Although the default h6 CSS wouldn't be a bad start.)
ETA: It's interesting that the TOC works just fine!
Well, it would be easy enough to simulate it using classes and CSS. That wouldn’t need Jacques. (What would need Jacques is if you wanted to use the same ####### notation with the number of hashes being the level of nesting.) The question would be as to how you wanted it displayed.
Ah, thanks. For what it’s worth, I’d be happy with any code that made it display as intended, need not be strings of hashes. Strings of hashes are awkward to distinguish anyway when they get this long.
The question would be as to how you wanted it displayed.
Optimal for my purpose would be an automatic section numbering that produces labels such as “3.2.4.2” etc. Is that possible with CSS? If we had that I wouldn’t need much of a font size distinction or anything else.
BTW, I would like to mention that the right “semantic” solution to this problem is not to have heading level numbers but instead have “section” level numbers - e.g div.S00, div.S01, … , div.S99 and then just have a single section header type, say div.SHead, that should appear just once inside a leveled section near the top. Then one can style level 2 and 3 headers with a selectors like “div.S02>.SHead” and “div.S03>.SHead”. This sort of approach can allow one to click and collapse a section down to just its header.
I would probably make use of this feature to collapse down things like proof sections.
allow one to click and collapse a section down to just its header.
That would be awesome!
This is precisely what I am needing this for: arranging a collection of nLab entries as a single level-wise linear hierarchy of text.
This is necessary for turning large clusters of nLab entries into a coherent body of text that one can hand to people. Something very similar is happening at The Stacks Project.
But if I include one nLab entry at some level into the big document, I want that entry to keep its own subsection hierarchy. Hence if I include for instance an entry at level 3 which itself has subsections of level 4 the net result will have depth 7. That’s where this comes from.
Andrew, so you're saying that we could use something like
+-- {: .h7}
...
=--
and put in our own CSS for that, without bothering Jacques about the bug? This is true, but then it might be a bit of a chore (you would be the best to know how much) to make the TOC still work. Whereas, with the hashes, the TOC works now.
Rod, I'm not sure that I understand what you are suggesting. Perhaps you can put up some dummy markup (either HTML or pseudo-Instiki) of some sections inside sections inside sections?
Looking at the Sandbox, I guess one could class the fact that seven hashes works as a “bug”, although in the grand scheme of things it’s probably not a bug worth fixing - putting in a check on the number of hashes used just adds extra code for no actual benefit since the author would still need to observe that the result wasn’t what they intended. The TOC is generated by the Markdown converter (Maruku) so it works because of this bug.
Rod’s suggestion looks quite similar to the XHTML2 spec: it has <section> ...</section> tags within which you have a <header> ... </header> tag with no number: the nesting of the section tags handles that.
One option would be to get Maruku to issue min(6,number-of-hashes) for the header tags. This would ensure that the headers were valid XHTML. Adding a class .header<number-of-hashes> would then allow for styling.
However, this would not work with Urs’ use-case. Indeed, I don’t see a way to make Urs’ situation work - if I understand it correctly. He wants (as I understand it) to graft one page into another and offset the grafted pages’ headers by a certain amount (depending on the graft point). In terms of headers, we might thus have:
Main Page
# Level 1
## Level 2
### Level 3
#### Level 4
Graft Point
Sub Page
# Level 1
## Level 2
### Level 3
Now, when grafting in, Urs wants (if I have the interpretation right):
Main Page
# Level 1
## Level 2
### Level 3
#### Level 4
Graft Point
##### Level 1 -> Level 5
###### Level 2 -> Level 6
####### Level 3 -> Level 7
I don’t see any way to make the hash syntax work this out. Because when Instiki includes documents, it just pastes them in. So it would see:
Main Page
# Level 1
## Level 2
### Level 3
#### Level 4
Graft Point
# Level 1
## Level 2
### Level 3
and for all it knows, this was the intended outcome (it is completely valid and reasonable).
Rod (and XHTML2) fix this by insisting on everything being nested. So we could define some CSS styles that basically shift all of the header styles down (this is pretty much what Toby says above). This would make the pages render correctly except that the TOC would still show the original structure. Fixing the TOC would mean that it had to take into account more information than just the number of hashes. I doubt this would be a reasonable task.
However, Urs’ goal for this is:
This is necessary for turning large clusters of nLab entries into a coherent body of text that one can hand to people.
which suggests that the end goal is something not necessarily nLab-hosted. In which case, it is not unreasonable to do a bit of post-processing. This would be necessary anyway to make the finished product “look nice” so some script that went through and fixed the TOC and section headings wouldn’t be too difficult to write.
Conceptually it is fairly easy to derive a nested section presentation from one that just has header levels among a linear sequence of text blocks. For example a quite small amount of JavaScript could post-process the current XHTML output to put it in that form.
Here is one way to get Urs style inclusions to work (given I think reasonable guesses on how Instiki works - my syntax for Instiki commands are just to give the flavor not real syntax suggestions).
Let’s say Instiki is modified to be aware of the current section level (i.e the last header level) while linearly processing the (flat) source. Next add a new command like !{sectionLevelOffset 2} That tells it to add the offset to any following section levels. Wrapping “# … ## …” with offsets of +2 and -2 would effectively change that to “### … #### …”.
I’m guessing that a simple model of how Instiki handles inclusion is at the source text level - an initial top-level source text is recursively processed, replacing all !include statements with their source text, to give a flat source text. (maybe with a few minor alterations to included text). Then as a second pass the flat source is linearly processed into internal data structures from which is generated Tex and XHTML.
Let’s say an !{include foo} also wraps that source with !{beginInclude foo} and !{endInclude foo}.
Finally when the whole flat source is processed these !beginInclude and !endIncludes are essentially transformed to a !sectionLevelOffset wrapping of the current section level at the point the !beginInclude is found.
If Instiki does use a source pre-pass to handle inclusions then it would need something like the above to handle Urs style inclusions.
I didn’t dare to hope to that this would work by automatic inclusion. I am prepared to edit by hand. I am doing this anyway. It would just be nice if there were some syntax at all that makes deeper levels work.
Andrew writes:
I guess one could class the fact that seven hashes works as a “bug”, although in the grand scheme of things it’s probably not a bug worth fixing
and then
This would ensure that the headers were valid XHTML.
Well, that's why Jacques might consider it a bug worth fixing: he wants to produce valid XHTML. But I don't propose pointing this out until we know what we want him to make Instiki do instead!
1 to 15 of 15