From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/28899 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Connor Patrick Jackson Newsgroups: gmane.text.pandoc Subject: Re:
rather than
in HTML5 output Date: Thu, 22 Jul 2021 12:24:54 -0700 (PDT) Message-ID: <39dfd03d-544d-46b1-8492-f517a5b3e652n@googlegroups.com> References: <3ceb7519-ed4b-4118-a214-6c4b63e07c21n@googlegroups.com> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_212_2108083469.1626981894213" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21391"; mail-complaints-to="usenet@ciao.gmane.io" To: pandoc-discuss Original-X-From: pandoc-discuss+bncBDVNJU66TMLRBB4M46DQMGQE2VDD7ZY-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Thu Jul 22 21:24:58 2021 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane-mx.org Original-Received: from mail-oo1-f63.google.com ([209.85.161.63]) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m6eJV-0005JG-By for gtp-pandoc-discuss@m.gmane-mx.org; Thu, 22 Jul 2021 21:24:57 +0200 Original-Received: by mail-oo1-f63.google.com with SMTP id r4-20020a4ab5040000b02902446eb55473sf2469302ooo.20 for ; Thu, 22 Jul 2021 12:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=ZrNcmpTAeDMumFaZ6LJBAVoIYNuU5tUUicCwSQ31hwU=; b=Nv705rQUQ5pES5pu6xPTe3m8yNUMwXtJblifBHQe3nvNoMvyoNzc/2igRXVCBSXeGI dI0sCEWbbR0/1BpZe1ATbqMyqAV790CKcaMNHLkbrmdod0QDP0iHUj1GK1MBZSrG2lJO TNfZeuZBIDzqrnOZxOhlaDFtl1W8vAmg7m9tgEJBYwCIoc0ytataSfh8eSmM+Nlyyjxd Awy7GFQ71BkFNZMUGlMBfhMRHOgaAPHz+5OGrbTThIDGa86TUbxUQiAh6BOyckCAFYSz 2g+TIk8mpscM+VstnNMmW9i6C+cbj5vKNV/dlCd08tvd9cAJHlxzciASrZuynwlNGBCB Srdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berkeley-edu.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=ZrNcmpTAeDMumFaZ6LJBAVoIYNuU5tUUicCwSQ31hwU=; b=1rZgkVLckz6Zv0s9L7ObHEKdTbg5GFOtCSqTyN99MdaszPfbEitfMaG+wex0i/Ugyj Pmc85QgY49y5Pj8R4+WHncbvcF+6Km0kktUaDWaJYLen0BN47I7pQR9itcu2Frbg8iVN ltx8wVD7WBun34oPmPXVO2oAK2pyP6iR5A5l/vn278jEuha/d8uKaDTHi1E7Eb/2Ic2u xoQ8vrf+Mk5iW2peRn9jPq7LnCLZVrYrxc7/PSbGN0yv5cnwlAMMJGpvUPb+NH1tDuRu dyy6HGeU5H4Ky1gZwgWA5UGX3DyWqv8/wuq6QvsrMYG5Ghxpt9ej62wP8Lu17jVtEdfL qUew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=sender:x-gm-message-state:date:from:to:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=ZrNcmpTAeDMumFaZ6LJBAVoIYNuU5tUUicCwSQ31hwU=; b=qcYYVBxnOuMNuNB5gnmPmWFDZAkOd0W1k6ytkhR0Sy6YGeAsaeyz9q3fLRR1Ol3oAq KEOO66ZaurGMtuSBZDhU1boVa94dLZd/dr13RbvfAH8QQGnwzT/u6h6AzJIiDXXrIjJs 2bqPhIutlbqSjy4oP4ohlPLweAY1X503is6Vr8vrP+xysQCwN+Vk0uaitowrRIWt+Taq J+MYO4Pf5PkHO25wtFknsouA2J0JRY/q3hlmR5hJe53c6uD4EvhMUHzqh39kKqc86cWj BYFqvRdaG8GUKpG/MBEJXFLLJs2xdQUaUYteshvHNlhF4h1VtaLWhWxHUuonzIHdP3Bp n4/g== Original-Sender: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org X-Gm-Message-State: AOAM530JWSCaa3j5+GeZGeiaCtHOPlfBGNJFiTFWOtRwnqitaKC9Hwtw hBmBPYoePR3tZDY0cv4t300= X-Google-Smtp-Source: ABdhPJxUiSPSwB0AgsBmyK2gcu9PSWe2R7b6QzGc08xY0HrL720EHwc5gjkiFIp0wK/5u2pUamioyg== X-Received: by 2002:a9d:6ac4:: with SMTP id m4mr897998otq.203.1626981896407; Thu, 22 Jul 2021 12:24:56 -0700 (PDT) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 2002:a05:6830:1642:: with SMTP id h2ls2091457otr.5.gmail; Thu, 22 Jul 2021 12:24:55 -0700 (PDT) X-Received: by 2002:a9d:7985:: with SMTP id h5mr906624otm.283.1626981894853; Thu, 22 Jul 2021 12:24:54 -0700 (PDT) In-Reply-To: X-Original-Sender: cpjackson-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Xref: news.gmane.io gmane.text.pandoc:28899 Archived-At: ------=_Part_212_2108083469.1626981894213 Content-Type: multipart/alternative; boundary="----=_Part_213_1588760938.1626981894213" ------=_Part_213_1588760938.1626981894213 Content-Type: text/plain; charset="UTF-8" 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 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
opening and closing tags, and removes the original Div, > > putting its content between the
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
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
is now wrapped in > > _another_
tag (the
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 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. ------=_Part_213_1588760938.1626981894213 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alas, thanks for the explanation. I would put a tiny nudge toward eventuall= y making a change to the HTML writer to allow the specification of which ta= g to use (div/section/article/aside) on a case by case basis (either for fe= nced divs or those created by --section-divs), but I know that is a nontriv= ial effort, both to change the writer and develop a syntax. I do think it w= ould be an accessibility benefit, since it provides further structural info= rmation about the page to assistive technology, but it's likely not a huge = priority.

Maybe this change will be the motivation I nee= d 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 <c= pja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> writes:

> Okay, I have put together a Lua filter to do this that I'm hap= py with, and=20
> it makes the correct changes to the data in the AST (everything lo= oks right=20
> when I print --to native). However, I'm running into an issue = when actually=20
> writing out to HTML. My filter first calls make_sections to create= the divs=20
> from the headers (seemed reasonable so I don't have to recreat= e the wheel),=20
> and then goes in, finds the Div blocks with class "article&qu= ot;, creates the=20
> new <article> opening and closing tags, and removes the orig= inal Div,=20
> putting its content between the <article> tags. All is well.
>
> However, when I am writing to HTML, if I don't include --secti= on-divs in=20
> the call, the resulting HTML doesn't include any of the <se= ction>s for the=20
> other headers (the ones I didn't convert to articles), even th= ough they=20
> exist in the AST after being created by make_sections. However, if= I do=20
> call --section-divs, apparently make_sections gets called a second= time,=20
> because the heading I just wrapped with an <article> is now = wrapped in=20
> _another_ <section> tag (the <article> tag remains), d= espite having removed=20
> the wrapping Div entirely from around that header. This behavior o= ccurs=20
> regardless of whether I call --section-divs before or after the fi= lter.=20
>
> So the --section-divs option is doing more than just calling make_= sections,=20
> and has a larger role in the HTML writer. Thus, I can't exclud= e it from the=20
> call.=20
> On the other hand, if it calls make_sections a second time, and I = can't=20
> control when that happens, it ends up writing invalid markup. So I= can't=20
> include it.=20
>
> I am officially stuck. I'm not sure if this is proper behavior= of=20
> --section-divs or a bug, but I'm unsure how to work around it = in either=20
> case. Happy to provide an MRE and my Lua filter if it would help, = or take=20
> this over to the Issue Tracker and file a bug report if that's= what it is.=20
>
> On Sunday, July 18, 2021 at 11:45:07 AM UTC-7 John MacFarlane wrot= e:
>
>> Connor Patrick Jackson <cpja...-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> writes:
>>
>> > Sounds good to me! I've got half of a filter set up t= o do this, if=20
>> someone=20
>> > could just point me in the right direction. Is there a wa= y to hook into=20
>> the=20
>> > HTML writer and tell it which tag to use for the div/sect= ion? Or would I=20
>> > have to go the route of just adding the tags manually as = RawInline and=20
>> > removing the Section class? (or some third, better approa= ch that I'm not=20
>> > seeing because this is the first time I've written a = filter)? Thanks!
>>
>> Exactly, you'd have to add the tags manually.
>>
>>
>
> --=20
> 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/cdcd= bebe-d19a-4d8f-96dc-5e03a2977bc2n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pand= oc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@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.
------=_Part_213_1588760938.1626981894213-- ------=_Part_212_2108083469.1626981894213--