Adding a class to the auto-inserted <br> elements

Adding a class to the auto-inserted <br> elements

[Daniel Radetsky]

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

So I was exporting an Org doc to html the other day, and I was trying to
follow this guide to make the list elements appear as a comma-separated list

https://markheath.net/post/css-comma-separated-list

It didn't work, and I discovered this was because Org adds a <br> element
to the <li> element if the <li> element is created from an Org headline
element. The easiest way to fix this and allow the aforementioned guide to
work is by ensuring that all those <br> elements have `display: none` set
via CSS. To make this easier and/or reduce the risk of accidentally
removing other elements, we can add a class name to those <br>'s the way we
do to other elements.

I have included an example change. This is just the simplest possible
solution. Obviously if someone thinks a more complicated/featureful
solution is required, we can do more stuff.

--dmr

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

[-- Attachment #2: 0001-lisp-ox-html.el-Add-class-to-auto-inserted-br-tag.patch --]
[-- Type: text/x-patch, Size: 1044 bytes --]

From e35e1468c087ea09bbf9a2d6991401d2c5bbac39 Mon Sep 17 00:00:00 2001
From: Daniel Radetsky <dradetsky@gmail.com>
Date: Sun, 25 Aug 2024 16:11:15 -0700
Subject: [PATCH] lisp/ox-html.el: Add class to auto inserted br tag

Adds .org-heading-li-br to the br inserted at the end of li if the li is
exported from a headline. This allows the user to match those specific
elements with css selectors to style/disable them.
---
 lisp/ox-html.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 95b154dc5..3e2894c98 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2967,7 +2967,7 @@ symbols `on', `off', or `trans'.   INFO is the info plist."
 			   (symbol-name checkbox)) ""))
 	(checkbox (concat (org-html-checkbox checkbox info)
 			  (and checkbox " ")))
-	(br (org-html-close-tag "br" nil info))
+	(br (org-html-close-tag "br" "class=\"org-heading-li-br\"" info))
 	(extra-newline (if (and (org-string-nw-p contents) headline) "\n" "")))
     (concat
      (pcase type
-- 
2.45.2

Re: Adding a class to the auto-inserted <br> elements

[Ihor Radchenko]

Daniel Radetsky <dradetsky@gmail.com> writes:

> So I was exporting an Org doc to html the other day, and I was trying to
> follow this guide to make the list elements appear as a comma-separated list
>
> https://markheath.net/post/css-comma-separated-list
>
> It didn't work, and I discovered this was because Org adds a <br> element
> to the <li> element if the <li> element is created from an Org headline
> element.

But there is nothing wrong on Org side per se, right? The fact that some
specific suggestion from the internet did not work for a specific
HTML that happened to be created by Org mode, does not mean that we need
to fix Org mode. Unless the change you suggest may benefit many Org
users, of course.

> ... The easiest way to fix this and allow the aforementioned guide to
> work is by ensuring that all those <br> elements have `display: none` set
> via CSS. To make this easier and/or reduce the risk of accidentally
> removing other elements, we can add a class name to those <br>'s the way we
> do to other elements.

What would be the benefit of doing this beyond fixing your personal use case?
For other Org users.

Also, you can always use p > a CSS selector. What's wrong with that?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Adding a class to the auto-inserted <br> elements

[Daniel Radetsky]

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

> But there is nothing wrong on Org side per se, right?

I don't think so. The fact that ox-html inserts a <br> there with no way
for me as the user to disable this, in my view, bad. It's not a totally
unreasonable default, but it shouldn't be required.

> The fact that some specific suggestion...

This is an example of "motivation"; a specific concrete use-case that
actually came for the user to demonstrate that the issue is not merely
theoretical.

> What would be the benefit of doing this beyond fixing your personal use
case?

Other users might also have the same use case. Either the specific thing
I'm trying to do, or just a need to generate <li> elements from headlines
without auto-inserting <br> elements for any other purpose.

> Also, you can always use p > a CSS selector. What's wrong with that?

As a user, I would like to be able to apply a css selector to the elements
in question

0. With extremely high confidence that I am selecting _only_ the specific
<br> elements which org is auto-inserting in this case

1. Without having to do much understanding of the way org generates html
exports, or much thinking in general.

It did turn out that in the case of my specific document (which was pretty
simple), the selector `ul.org-ul li br` did in fact select only those
elements. But was this guaranteed? Even for arbitrarily complex documents?
Maybe, but proving this requires way more thinking than makes sense to me.
Much easier to just tag those elements with a class. Especially since we
already add classes like `.org-ul`.


On Sun, Sep 1, 2024 at 9:30 AM Ihor Radchenko <yantar92@posteo.net> wrote:

> Daniel Radetsky <dradetsky@gmail.com> writes:
>
> > So I was exporting an Org doc to html the other day, and I was trying to
> > follow this guide to make the list elements appear as a comma-separated
> list
> >
> > https://markheath.net/post/css-comma-separated-list
> >
> > It didn't work, and I discovered this was because Org adds a <br> element
> > to the <li> element if the <li> element is created from an Org headline
> > element.
>
> But there is nothing wrong on Org side per se, right? The fact that some
> specific suggestion from the internet did not work for a specific
> HTML that happened to be created by Org mode, does not mean that we need
> to fix Org mode. Unless the change you suggest may benefit many Org
> users, of course.
>
> > ... The easiest way to fix this and allow the aforementioned guide to
> > work is by ensuring that all those <br> elements have `display: none` set
> > via CSS. To make this easier and/or reduce the risk of accidentally
> > removing other elements, we can add a class name to those <br>'s the way
> we
> > do to other elements.
>
> What would be the benefit of doing this beyond fixing your personal use
> case?
> For other Org users.
>
> Also, you can always use p > a CSS selector. What's wrong with that?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>

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

Re: Adding a class to the auto-inserted <br> elements

[Suhail Singh]

Daniel Radetsky <dradetsky@gmail.com> writes:

> As a user, I would like to be able to apply a css selector to the elements
> in question
>
> 0. With extremely high confidence that I am selecting _only_ the specific
> <br> elements which org is auto-inserting in this case
>
> 1. Without having to do much understanding of the way org generates html
> exports, or much thinking in general.

Agreed.

-- 
Suhail

[POLL] Mark all the tags in HTML export with unique class (was: Adding a class to the auto-inserted <br> elements)

[Ihor Radchenko]

We are discussing the way Org formats HTML tags in HTML export.
Some of the tags added by Org are simply bare tags, like <br /> below.

<li><a id=".."></a>Low-level heading<br />

The suggestion is to add a unique class to each tag produced by Org HTML
export, so that CSS rules can precisely target various tags.

For example, Org can produce <br> tag in multiple contexts:

1. when exporting explicit line break \\
2. when exporting a heading as list item, to avoid merging the heading
   and its text
3. to separate title/subtitle
4. to separate inlinetask headline from its contents
etc...

We may export each <br> (or any other tag) as <br class="tag context">

Pros: Easier to write CSS selectors and possibly to post-process the
      generated HTML

Cons: HTML will become less readable

WDYT?

Daniel Radetsky <dradetsky@gmail.com> writes:

>> The fact that some specific suggestion...
>
> This is an example of "motivation"; a specific concrete use-case that
> actually came for the user to demonstrate that the issue is not merely
> theoretical.
> ... <multiple other arguments>

Ok. I see your motivation.
However, it does not make any sense to change _only_ one single specific
case where we insert <br> tag.
If we follow your argument, we should do it for every single tag that
ox-html inserts.

I am personally neutral to having such a change.
However, we discussed a somewhat similar proposal in the past wrt LaTeX
export and some users were concerned about reduced readability of the
produced .tex documents. See
https://list.orgmode.org/orgmode/87a65vitbz.fsf_-_@posteo.net/
So, I'd like to hear from other Org users first, because deciding
whether we want to add the feature you are asking for.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Mark all the tags in HTML export with unique class (was: Adding a class to the auto-inserted <br> elements)

[Ihor Radchenko]

Ihor Radchenko <yantar92@posteo.net> writes:

> We are discussing the way Org formats HTML tags in HTML export.
> Some of the tags added by Org are simply bare tags, like <br /> below.
>
> <li><a id=".."></a>Low-level heading<br />
>
> The suggestion is to add a unique class to each tag produced by Org HTML
> export, so that CSS rules can precisely target various tags.

We have been waiting for 2 months, but nobody seems to be interested
enough in the topic to participate.

Closing the poll.
Closed.

So, it has to be my call.

I suggest the following:

1. Create a function similar to `org-html-close-tag', but accepting
   attributes as an alist.
2. Introduce a custom option controlling which tags should be
   assigned classes 
3. Change all the users of `org-html-close-tag' and places that directly
   produce HTML tags to use the new function

By default, nothing should change. But I will not object an alternative
default that will assign classes everywhere.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Adding a class to the auto-inserted <br> elements

[Ihor Radchenko]

>> But there is nothing wrong on Org side per se, right?
>
> I don't think so. The fact that ox-html inserts a <br> there with no way
> for me as the user to disable this, in my view, bad. It's not a totally
> unreasonable default, but it shouldn't be required.

It makes sure that we do not put the heading and its contents on the
same line. IMHO, it does not make sense to disable this.

If you want to discuss <br> after low-level headings that are exported
as lists, feel free to branch out a new thread, changing subject line
appropriately.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>