Is there any hope we will one day get a semantic base from hugo, meaning some understanding of the pages in case html is produced ?
So that for instance, I could tell it to change all paragraph with a given class into an “aside” element, or enclose all elements between two heading of the same number (or the second being lower) and the same level on the DOM tree within a section, all kinds of things that would be simple if Hugo could really understand what a paragraph, or heading, or whatever is.
Because more than once, we’re limited by the markdown renderer, and forced to add the correct semantics with shortocdes to enact fairly systematic changes, that could be done automatically with a tool knowing semantics.
The semantics are down to the author, as they should be. There’s no tool I know of that will magically produce the correct html for any given situation, because it nearly always comes down to ‘It depends.’.
Given you example, wanting to arbitarily contain some paragraphs within an aside, my question would be why? Why would you want to do that?? You already can do that of course, but there’s no facility for that in Markdown; for very good reason.
Why would I want to use clearly appropriate semantics that html has had for a long time, when markdown is too limited ?
I don’t see the good reasons you speak of.
@Tom_Durand Let’s look at your example: the aside element. This element is (often) used in/as a sidebar. A sidebar is typically a layout item. This is handled by a layout file in Hugo, which is not markdown, but plain HTML. This layout file provides the aside element. The text INSIDE the aside element is content and is/can be managed by markdown. This is the design of Hugo and it makes sense to me. The final webpage (with the aside element) is generated by multiple markdown files: one for the aside and one for the main content. This also makes sense to me. I wonder how you see this.
Agreed, except aside isn’t always part of the layout. It can just float in the text to add information not directly in the flow of the text.
The
<aside>element represents a part of a document whose content is only indirectly related to the main content of the document. Asides are frequently present in the form of sidebars or caption boxes.
The insertion of many other useful (semantic) elements would be simplified too, if the program could just “react” to a certain class or custom attribute, and shove a <embed>, <address> or whatever else anywhere in the text, instead of a paragraph.
It would shorten the syntax for calling shortcodes considerably.
But it’s actually a different proposal than my initial one, a simpler and better… right ?
You can do that by writing this:
{{< aside >}}Your aside content{{< /aside >}}
{{< address >}}Your address{{< /address >}}
And alternatively you could write:
<aside>Your aside content</aside>
<address>Your address</address>
So… either a shortcode or HTML (as HTML is valid Markdown). MUCH more information can be found in this excellent SO question/answer: Inserting raw HTML into Markdown - Stack Overflow
1 Like
We have CSS for that. Using grid and flex, you can pretty much put every element wherever you want it now. And in the case of address, the semantics is very much in the element itself, anyway. Not in its position on the page. embed doesn’t have any semantics, afaik.
1 Like
Ah ? What do you mean ? Seems like an overstatement. You can’t just choose to insert an iframe from the end of the dom tree, to now 20% top 40% left of the document and stay in flow (so without absolute positioning). What you describe would require javascript. I wish it didn’t !
So cool, the inside of html tags were parsed like the rest and show up in the Table of Content ! Unlike with shortcodes ! Ok, that removes an issue I had. And that’s about as quick to write as it can get. Point taken.
1 Like
Right, you can’t manipulate the DOM tree without JavaScript. But using grid and flex, you can display elements wherever you want easily. Not sure what “stay in flow” means. Fixed positioning might do what you want. Perhaps.
It will superimpose on everything. stay in flow means not cover the rest. That would require DOM manipulation. Do you have exemple where I could write, say, an iframe at the end of the page, and nit would display near the start and the left of the page but displace what would be there instead of covering it ?
Markdown was designed to provide only a very limited subset of html elements required for publishing text.
If you want more than Markdown can provide, use html.
1 Like
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.