<article> rather than <section> in HTML5 output

<article> rather than <section> in HTML5 output

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 862 bytes --]

When compiling from markdown to html5, is there a way to specify some 
blocks to be created as <article> tags rather than <section> tags when 
using --section-divs (or when specifying a fenced div)? 

If this isn't currently possible, would it be challenging to add such a 
feature? Either by specifying a class or other {attribute}, or an option 
setting all headings of a user-specified depth become articles rather than 
sections? 

Connor Jackson

-- 
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/c07ed5ea-b466-4b33-b9dc-9917c2983f7an%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1217 bytes --]

Re: <article> rather than <section> in HTML5 output

[John MacFarlane]

This could be done fairly easily using a filter.
See the documentation on filters and lua filters.

Connor Patrick Jackson <cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> writes:

> When compiling from markdown to html5, is there a way to specify some 
> blocks to be created as <article> tags rather than <section> tags when 
> using --section-divs (or when specifying a fenced div)? 
>
> If this isn't currently possible, would it be challenging to add such a 
> feature? Either by specifying a class or other {attribute}, or an option 
> setting all headings of a user-specified depth become articles rather than 
> sections? 
>
> Connor Jackson
>
> -- 
> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/c07ed5ea-b466-4b33-b9dc-9917c2983f7an%40googlegroups.com.

Re: <article> rather than <section> in HTML5 output

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 2044 bytes --]

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!



On Friday, July 16, 2021 at 7:57:57 PM UTC-7 John MacFarlane wrote:

>
> This could be done fairly easily using a filter.
> See the documentation on filters and lua filters.
>
> Connor Patrick Jackson <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> writes:
>
> > When compiling from markdown to html5, is there a way to specify some 
> > blocks to be created as <article> tags rather than <section> tags when 
> > using --section-divs (or when specifying a fenced div)? 
> >
> > If this isn't currently possible, would it be challenging to add such a 
> > feature? Either by specifying a class or other {attribute}, or an option 
> > setting all headings of a user-specified depth become articles rather 
> than 
> > sections? 
> >
> > Connor Jackson
> >
> > -- 
> > 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...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pandoc-discuss/c07ed5ea-b466-4b33-b9dc-9917c2983f7an%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-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/3ceb7519-ed4b-4118-a214-6c4b63e07c21n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3183 bytes --]

Re: <article> rather than <section> in HTML5 output

[John MacFarlane]

Connor Patrick Jackson <cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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.

Re: <article> rather than <section> in HTML5 output

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 2964 bytes --]

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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/cdcdbebe-d19a-4d8f-96dc-5e03a2977bc2n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3873 bytes --]

Re: <article> rather than <section> in HTML5 output

[John MacFarlane]

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 <cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/cdcdbebe-d19a-4d8f-96dc-5e03a2977bc2n%40googlegroups.com.

Re: <article> rather than <section> in HTML5 output

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 4875 bytes --]

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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > 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-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/39dfd03d-544d-46b1-8492-f517a5b3e652n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6418 bytes --]

Re: <article> rather than <section> in HTML5 output

[John MacFarlane]

You can put something on the issue tracker about this, if you like.

Connor Patrick Jackson <cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> writes:

> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> > 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-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/39dfd03d-544d-46b1-8492-f517a5b3e652n%40googlegroups.com.

Re: <article> rather than <section> in HTML5 output

[BPJ]

[-- Attachment #1: Type: text/plain, Size: 6135 bytes --]

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.

Den tors 22 juli 2021 21:25Connor Patrick Jackson <cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org>
skrev:

> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> > 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-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pandoc-discuss/39dfd03d-544d-46b1-8492-f517a5b3e652n%40googlegroups.com
> <https://groups.google.com/d/msgid/pandoc-discuss/39dfd03d-544d-46b1-8492-f517a5b3e652n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CADAJKhDe9nzpyXzB2pWO%3Dbme-A5TBZEH6xncmnGnEQQ7jB78-Q%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7786 bytes --]

Re: <article> rather than <section> in HTML5 output

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 8306 bytes --]

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: 


   1. 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.
   2. Define an attribute that can be applied to a heading, which would 
   exempt it from having a div constructed around it.
   3. 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).
   4. Incorporate the creation of <article> tags into an AST change that 
   differentiates between <section> and <div>, per this GitHub thread. 
   <https://github.com/jgm/pandoc/issues/5761#issuecomment-548853077>
   
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.
>
> Den tors 22 juli 2021 21:25Connor Patrick Jackson <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 
> skrev:
>
>> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org 
>>> > 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...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pandoc-discuss/39dfd03d-544d-46b1-8492-f517a5b3e652n%40googlegroups.com 
>> <https://groups.google.com/d/msgid/pandoc-discuss/39dfd03d-544d-46b1-8492-f517a5b3e652n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@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.

[-- Attachment #1.2: Type: text/html, Size: 10666 bytes --]

Re: <article> rather than <section> in HTML5 output

[Connor Patrick Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 9424 bytes --]

Also, re: handling attributes: I'm trying to appropriately handle 
user-defined named attributes, and appropriately append "data-" if it is 
not a pre-defined HTML5 attribute name, recreating the behavior of the HTML 
writer. I'm trying to avoid just including a list manually in the filter 
script, since that would need to be monitored for future updates. 

I noticed that pandoc itself does this very thing 
<https://github.com/jgm/pandoc/blob/1f1a30bbf6aa6d1c1dc60ac9d97560346066d02f/src/Text/Pandoc/XML.hs#L167>, 
so at a minimum, I was wondering if it is feasible to reference Pandoc's 
list rather than maintain a separate one in the filter. My guess is no, 
since I doubt it's exposed via the pandoc module in Lua, but I thought I'd 
check, and see if anyone else had other ideas that are better than a 
manually included list. 

On Saturday, July 24, 2021 at 1:08:37 PM UTC-7 Connor Patrick Jackson wrote:

> 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: 
>
>
>    1. 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.
>    2. Define an attribute that can be applied to a heading, which would 
>    exempt it from having a div constructed around it.
>    3. 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).
>    4. Incorporate the creation of <article> tags into an AST change that 
>    differentiates between <section> and <div>, per this GitHub thread. 
>    <https://github.com/jgm/pandoc/issues/5761#issuecomment-548853077>
>    
> 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.
>>
>> Den tors 22 juli 2021 21:25Connor Patrick Jackson <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 
>> skrev:
>>
>>> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> 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...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org 
>>>> > 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...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/pandoc-discuss/39dfd03d-544d-46b1-8492-f517a5b3e652n%40googlegroups.com 
>>> <https://groups.google.com/d/msgid/pandoc-discuss/39dfd03d-544d-46b1-8492-f517a5b3e652n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/96e9557a-31a5-45a3-82f0-8dd233516678n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 12025 bytes --]