Replies: 1 comment 5 replies
-
w3schools states: And: Hence the user can add additional Note: The hard-coded
Yes.
Done. Other items mentioned in HTML_TEMPLATE.md:
See Titles and Subtitles Semantics: Issues and Proposals #102
That was a bug, fixed already.
It's reserved for displaying a sub-TOC when HTML chunking is supported in a future version.
The first PMLC versions actually used Javascript. This was later replaced by |
Beta Was this translation helpful? Give feedback.
-
Ok, it's not illegal, but is it desirable?
Sure, but that's extra work in terms of CSS (extra classes or IDs), otherwise the styles would be applied to both headers/footers, e.g. resulting in added margins, borders, etc. for the hardcoded empty and unused header and footer.
Exactly, and this is a deterrent for anyone who would like to create a stylesheet, since (without any documentation on this) the question begs whether they might be soon used by PML, thus interfering with a custom template and stylesheets. The safe assumption here is that were added for a reason, and to expect that in the future they will be activated.
Mhhh. Usually there's no need for a sub-TOC in such cases, you just show the top level headings of all chunks, and the full expanded TOC of the current document, or sometimes the full TOC is always shown, covering all levels, so the reader can jump to any section (and search the TOC) from anywhere within the book. It would be much more useful if that aside became the target of an additional custom template, allowing users to inject whatever they like in it (banners, links, etc.).
I understand this, but honestly I never saw a TOC created using definition lists. IMO circumventing JavaScript and resorting to definition lists just to retain foldable entries without the burden of a small JS script (which could be embedded in the page source) is not viable. Furthermore, it's a violation of semantics, since a dedicated reader (e.g. for the visually impaired) or some meta-crawler application might treat the TOC entries as if they were definitions (which they are not). HTML5 begs for correct semantics, and IMO PML should oblige to them. Not to mention that having awkward TOC formatting only complicates adapting existing CSS themes to PML. Some practices which were tolerated in the days of HTML4 are no longer considered acceptable with HTML5, like using tables for formatting purposes (which, BTW, I noticed PML does to handle footnotes). These are among the very first things that publishers will look into when discovering PML for the first time, along with publishing standards compliance of the syntax, and how it's rendered. For this reason, I think that before starting to publicize PML on a large scale it's important to fix the current state of HTML and CSS templating — no new features, but improving and documenting the existing ones. |
Beta Was this translation helpful? Give feedback.
-
Yes, but HTML allows several headers/footers, and classes/IDs allow to apply different styles to different headers/footers. If we remove the currently reserved (but unused) header/footer (which have a dedicated class to distinguish them), then we risk to break user-defined templates later if we add them again.
Yes, exactly.
I've seen several modern webpages doing this, and I think that it makes sense in case of big documents with deeply nested sections, rendered as HTML chunks. You have the main TOC on the left side, and the sub-TOC of the currently displayed chunk on the right side.
HTML 5 states:
Does this mean that PML violates the specs if a
IMO JS should be avoided as far as possible in the context of HTML for PML documents.
Yes, footnotes are displayed wit HTML |
Beta Was this translation helpful? Give feedback.
-
I might argue that the clause here is that the element being dealt with qualifies as being "additional details," whereas to me a Table of Contents seems more like a table (as the name indicates) or (better) a list — in paper editions, ToC are formatted as tables, but in HTML document they are formatted as lists, the difference being that the former usually includes a series of Still, one thing is being "right" (as in the light of the HTML spec), another is to decide to go against the grain of all practical usages and standards. If you're OK with the fact that no CSS framework will work out of the box with PML documents, than that's fine. Personally, I'm not so enthusiastic, and this was one of the issues which was hindering my experimentation with custom Sass/CSS templates, since every single CSS template and framework that I've found expected the ToC to be a list, and would have required considerable refactoring in order to work with PML documents (which ultimately resulted in the project becoming stale). |
Beta Was this translation helpful? Give feedback.
-
Even Asciidoctor eventually dropped using tables for formatting footnotes (after users had been complaining for years). Their reason for doing so was rooted in the original template (Foundation), which dated back to the pre- Why you consider a footnotes block as being a table remains a mystery to me, even more so why there might be the need for an additional column. You only need to pick a pile of books from different time periods (let's say from the 60s, 80s, and current) to notice that the need to format footnotes as if they were inside a table came about with the introduction of word processors, and that in print there wasn't a real need to do so — treating them like paragraphs was fine, the fact that they started with a number was enough to distinguish where a new footnotes was beginning, and an added styling to the number (bold or italic) could improve visual discovery. I'm not saying that digital publishing was wrong in exploiting indentation to render footnotes more discoverable, I'm just saying that they are not a table in nature (nor a list, for that matter), although it might be practical to treat them as such in HTML, for formatting purposes, but semantically they are neither (they are footnotes, and I wish HTML5 was a decent enough standard to acknowledge them for what they are, since they are ubiquitous in documents). Having footnotes as a table isn't going to work well with most CSS frameworks though, were tables are always expected to be tables in the classic sense (borders and all), and formatting must rely on dedicated tags (divs, flexbox, etc.) — again, an issue of PML going against the grain of what are considered good practices in the field. |
Beta Was this translation helpful? Give feedback.
-
That was not my intention. As mentioned already, the first PML versions used lists and Javascript for foldable TOCs. Then lists were replaced by
If the change to
In that case a better solution would propably be to use a CSS grid layout. |
Beta Was this translation helpful? Give feedback.
-
Currently PML supports custom templates, but these are not really covered by the PML documentation, and I've also noticed some practical problems with the current templates.
On this topic, see my
HTML_TEMPLATE.mddocument, which I had written in Nov. 2022 while exploring custom CSS at the PML Playground project.The main problem I see is that the
<header>and<footer>sections are unusable, and their contents can't be controlled via custom templates, since these tags falls outside of the user templates boundaries. If the user where to add a custom<header>or<footer>section in his template files, the final document would contain duplicate<header>and<footer>sections.In the
HTML_TEMPLATE.mddocument I also mention other issues with the current templating system, and thoughts on how it might be improved.Since this feature is already in place, IMO we should capitalize on it by:
Beta Was this translation helpful? Give feedback.
All reactions