oh yes, I think it might actually just be sufficient to convert the header object within the <article>, and just leave the other sections as is. Good point re: being careful with reserved characters, since I should do that when constructing the <article> tag as well. It's probably safe for a filter just for my own use, but if I'm going to push it up to the Lua-filters repo I should probably handle it more responsibly. Do you know of a filter that does that well for me to look at?
I'm trying to think about what the right framing is for opening an issue on the issue tracker. I think there are a few possible approaches, increasing in expansiveness and complexity:
- The HTML writer (all writers?) could check whether makeSections has already been run on the entire document, and if so, don't run it again.
- Define an attribute that can be applied to a heading, which would exempt it from having a div constructed around it.
- Allow AST divs (either fenced or automatically created from headers) to be turned into a specified tag, beyond just <section>, or <div>, by specifying an attribute or other method. (This already partially happens because you can turn a fenced div into a section without including a header by assigning it class .section. Not sure if this is intentional or just a side effect, but that behavior could be a good model).
- Incorporate the creation of <article> tags into an AST change that differentiates between <section> and <div>, per this GitHub thread.
I'll add a comment on the thread for #4 regardless, since I think <article> should be incorporated into that long term planning. But if an interim change is appropriate and feasible, I'd be curious what folks think the best approach is.
On Saturday, July 24, 2021 at 10:08:31 AM UTC-7 BP wrote:
I haven't tested this specifically but you ought to be able to convert Header objects into Plain objects with the `<h2>` etc. tags inserted manually as RawInline objects and then also insert all `<section>` tags manually as RawBlock objects. That way Pandoc shouldn't see any Header objects and automatic section creation probably won't happen. The trickiest part is probably to format attribute values manually for the heading tags unless you know that they do not contain any reserved characters.
Alas, thanks for the explanation. I would put a tiny nudge toward eventually making a change to the HTML writer to allow the specification of which tag to use (div/section/article/aside) on a case by case basis (either for fenced divs or those created by --section-divs), but I know that is a nontrivial effort, both to change the writer and develop a syntax. I do think it would be an accessibility benefit, since it provides further structural information about the page to assistive technology, but it's likely not a huge priority.
Maybe this change will be the motivation I need to learn Haskell! Who knows!
On Thursday, July 22, 2021 at 11:41:55 AM UTC-7 John MacFarlane wrote:
Currently the HTML writer *always* runs makeSection. But it
ignores the sections unless --section-divs is used. I can see
how this frustrates your aims here. I think there's probably
a reason we do it this way, but I can't remember it off the
top of my head -- no doubt something in the reader is made
easier by the section-ification, even if --section-divs is
not used -- perhaps table of contents generation.
I don't see a good way round this, unfortunately.
Connor Patrick Jackson <cpja...@berkeley.edu> writes:
> Okay, I have put together a Lua filter to do this that I'm happy with, and
> it makes the correct changes to the data in the AST (everything looks right
> when I print --to native). However, I'm running into an issue when actually
> writing out to HTML. My filter first calls make_sections to create the divs
> from the headers (seemed reasonable so I don't have to recreate the wheel),
> and then goes in, finds the Div blocks with class "article", creates the
> new <article> opening and closing tags, and removes the original Div,
> putting its content between the <article> tags. All is well.
>
> However, when I am writing to HTML, if I don't include --section-divs in
> the call, the resulting HTML doesn't include any of the <section>s for the
> other headers (the ones I didn't convert to articles), even though they
> exist in the AST after being created by make_sections. However, if I do
> call --section-divs, apparently make_sections gets called a second time,
> because the heading I just wrapped with an <article> is now wrapped in
> _another_ <section> tag (the <article> tag remains), despite having removed
> the wrapping Div entirely from around that header. This behavior occurs
> regardless of whether I call --section-divs before or after the filter.
>
> So the --section-divs option is doing more than just calling make_sections,
> and has a larger role in the HTML writer. Thus, I can't exclude it from the
> call.
> On the other hand, if it calls make_sections a second time, and I can't
> control when that happens, it ends up writing invalid markup. So I can't
> include it.
>
> I am officially stuck. I'm not sure if this is proper behavior of
> --section-divs or a bug, but I'm unsure how to work around it in either
> case. Happy to provide an MRE and my Lua filter if it would help, or take
> this over to the Issue Tracker and file a bug report if that's what it is.
>
> On Sunday, July 18, 2021 at 11:45:07 AM UTC-7 John MacFarlane wrote:
>
>> Connor Patrick Jackson <cpja...@berkeley.edu> writes:
>>
>> > Sounds good to me! I've got half of a filter set up to do this, if
>> someone
>> > could just point me in the right direction. Is there a way to hook into
>> the
>> > HTML writer and tell it which tag to use for the div/section? Or would I
>> > have to go the route of just adding the tags manually as RawInline and
>> > removing the Section class? (or some third, better approach that I'm not
>> > seeing because this is the first time I've written a filter)? Thanks!
>>
>> Exactly, you'd have to add the tags manually.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discus...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/cdcdbebe-d19a-4d8f-96dc-5e03a2977bc2n%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discus...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/54d50be7-9ffa-44a3-8a31-9988a60bb831n%40googlegroups.com.