Add automatic layout assignment based on heading levels #194
Conversation
Enable automatic slide layout selection through frontmatter configuration, eliminating the need for manual layout embedding in each slide. Users can now define layout mappings for heading levels (h1-h6) and title slides in YAML frontmatter, allowing structured markdown documents to automatically apply appropriate layouts based on their hierarchical structure. Features: - Frontmatter layout configuration - Automatic layout application for title slide and heading levels H1-H6 - existing JSON comments take precedence over frontmatter settings for explicit control This reduces manual layout specification overhead while ensuring consistent design patterns across large presentations, especially beneficial for structured content like parts, chapters, and sections. Resolves k1LoW#193
| @@ -36,10 +36,46 @@ type MD struct { | |||
| Contents Contents | |||
| } | |||
|
|
|||
| // Layout represents layout configuration for different heading levels and title slide. | |||
| type Layout struct { | |||
| Title string `yaml:"title,omitempty" json:"title,omitempty"` // layout for the first slide (title slide) | |||
There was a problem hiding this comment.
The title is not necessarily on the first page of the slides, so how about first?
| type Layout struct { | ||
| Title string `yaml:"title,omitempty" json:"title,omitempty"` // layout for the first slide (title slide) | ||
| H1 string `yaml:"h1,omitempty" json:"h1,omitempty"` // layout for H1 headings | ||
| H2 string `yaml:"h2,omitempty" json:"h2,omitempty"` // layout for H2 headings |
There was a problem hiding this comment.
I think it means that the primary heading on the page is H2.
I think it would be better to distinguish between this and cases where we want to set the layout for pages with only one H2 heading ( e.g., for a section title page )
- h2Lead
- h2First ( firstH2)
- h2Start ( startH2)
- h2Prime ( ... )
- h2Top( ... )
- h2Main( ... )
- h2AsRoot ( rootH2 )
- fromH2
- mainHeadingH3
- topLevelH2
There was a problem hiding this comment.
It might be worth considering using h2 for this case.
In that case, we should also decide on the field name “only one H2 heading” at the same time.
|
Overall, the simplicity is being lost because there are too many key names and rules to remember. We are on the same page, and we need to focus on simple, typical use cases. The contention here is that we need to agree on what we mean by “simple.” A simple system that covers 80% of use cases is sufficient. Ultimately, we can specify the layout with inline comments on each slide page. (However, I need to be careful not to let this become biased toward use cases that are convenient just for me.) That said, it isn't a good approach to cover too much with key names. What is important tends to be subjective, so there is likely to be heated debate about whether to add more keys, and naming them would also be difficult. There are multiple dimensions to the information structure used to determine the layout, and the number of keys could increase depending on the combination of these dimensions. Based on the discussion so far, we can identify the following dimensions. The number of dimensions may increase further.
As a solution, it is reasonable to maintain simple key names and consider future extensions. For example, you could treat titles and headings as special cases and create some "DSL" for future use, like the following. layout:
first: cover
h1: part
h2: chapter
h3: section
custom: # just a rough draft!
- 'h2 && subtitle_num == 0 && bodies == 0: chapter-top'
- 'h2 && subtitle_num == 2: 2col'
- 'noheading && image: hero-image'To be honest, I don't want to create a DSL. The above DSL is just a rough draft, and it requires rare "language design" skills. Furthermore, we also need to consider the priority of adaptation. In fact, what you are trying to do with key naming is ultimately the same approach as DSL design. Personally, I think the current interface with 'title', 'h1', 'h2' is simple and easy to understand, and I am opposed to starting to think of more complex key names. However, I am aware that this is only a solution that covers almost all of my use cases. |
|
This is a very difficult discussion. Thank you for participating in it. @k1LoW |
|
I would like to put everything up to the list in #193 (comment) into “simple.” In particular, I would like to include items without brackets. I am thinking of creating a feature that can handle the rest (such as the number of subtitles) in the Google Slides theme. On that basis, I would like to discuss the field names |
|
I feel that your "ad-hoc" list is already quite complex. I have realized my point. Arbitrary lists spanning multiple dimensions are dangerous. It leaves room for discussion regarding the future expansion of more keys. By default, it would be better to provide only one dimension setting, as this would avoid further discussions about expansion in that area. In my opinion, the most essential dimension is the heading level, so it would be best to prepare only that setting key. That said, the first page (title, cover, or first) is tricky. This is because it is already being treated specially. Some people may find it odd that the layout settings for h1 do not apply to the first page. It may be sufficient to document that the rules do not apply to the first page and avoid adding a separate key for it. We are getting closer to a consensus on this discussion, so it might be best to discuss it directly. |
Hmm... That's difficult. I'll list what I'm thinking right now.
|
Enable automatic slide layout selection through frontmatter configuration, eliminating the need for manual layout embedding in each slide. Users can now define layout mappings for heading levels (h1-h6) and title slides in YAML frontmatter, allowing structured markdown documents to automatically apply appropriate layouts based on their hierarchical structure.
Features:
This reduces manual layout specification overhead while ensuring consistent design patterns across large presentations, especially beneficial for structured content like parts, chapters, and sections.
Resolves #193