CSS: increase spacing before and after <blockquote> #5409

New Issue

hl · 2025-10-17T15:16:52Z

hl commented

2025-10-17 15:16:52 +00:00

example: https://fsfe.org/news/2025/news-20251015-01.en.html

looks like this:

<p></p>

<blockquote>
  “quote”
</blockquote>

<p></p>

https://git.fsfe.org/FSFE/fsfe-website/src/branch/master/fsfe.org/news/2025/news-20251015-01.en.xhtml

@dario

instead, the CSS for the blockquote should be changed, but then all these occurrences need to be changed too

example: https://fsfe.org/news/2025/news-20251015-01.en.html looks like this: ``` <blockquote> “quote” </blockquote> ``` https://git.fsfe.org/FSFE/fsfe-website/src/branch/master/fsfe.org/news/2025/news-20251015-01.en.xhtml @dario instead, the CSS for the blockquote should be changed, but then all these occurrences need to be changed too

delliott commented

2025-10-17 15:21:27 +00:00

Yes, this seems like a problem to be solved in CSS. We have a bad habit of (ab) using HTML features like this, or of using inline CSS for this kind of issue, see #2736.

But this should be solved in the look/ less files.

Yes, this seems like a problem to be solved in CSS. We have a bad habit of (ab) using HTML features like this, or of using inline CSS for this kind of issue, see https://git.fsfe.org/FSFE/fsfe-website/issues/2736. But this should be solved in the look/ less files.

hl commented

2025-10-17 15:33:56 +00:00

ok this is not needed, block quotes have good distancing.

likely some conversion tool produced weird results?

ok this is not needed, block quotes have good distancing. likely some conversion tool produced weird results?

delliott commented

2025-10-17 18:42:29 +00:00

Are the files in question generated using first a libre office doc (.odt), and then converted to HTML?

I wonder if it inserts a  for every newline in the source doc or something.

Or this may just be a case of someone doing it once, and it being copied to every new file. There are many such cases with CSS attributes and similar across the website, especially in the news section.

Are the files in question generated using first a libre office doc (.odt), and then converted to HTML? I wonder if it inserts a `` for every newline in the source doc or something. Or this may just be a case of someone doing it once, and it being copied to every new file. There are many such cases with CSS attributes and similar across the website, especially in the news section.

tobiasd commented

2025-10-21 07:17:14 +00:00

At least in Firefox the empty  seems to be removed/collapsed while rendering. When I remove the two empty paragraphs from the HTML code, the displayed page did not change at all.

At least in Firefox the empty `` seems to be *removed*/collapsed while rendering. When I remove the two empty paragraphs from the HTML code, the displayed page did not change at all.

delliott commented

2025-10-26 13:05:43 +00:00

FIrstly, some more info on empty paragraps in html:

TLDR: empty paragraphs are valid html, but should not be displayed by browsers, and are bad for accessibility.

We could

Do nothing. The weird paragraphs seem to have no visual effect, and so are just weird source code. This is fine, but not ideal.
Add something to the python code to remove empty paragraphs as part of the transformation. This works, but I would consider that it violates the principle of least surprise pretty badly, and will incur a performance cost every build, forever. Not ideal.
Add something to the pre commit checker that fails if they are present, and we must manually remove them. Seems okay to me.
Add a pre commit hook that runs an xsl stylesheet that just removes the empty paragraphs from a file. Could also have a pre commit hook that checks they are no longer present. This would also involve formatting all xhtml files probably. I had avoided this, soas to ensure that it was easy for peole to contribute xhtml files from the webinterface without setting up a local devenv, as we often see.

FIrstly, some more info on empty paragraps in html: - https://stackoverflow.com/questions/14848326/empty-paragraph-tags-should-i-allow-in-html-editor-or-not - https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/p#accessibility TLDR: empty paragraphs are valid html, but should not be displayed by browsers, and are bad for accessibility. We could - Do nothing. The weird paragraphs seem to have no visual effect, and so are just weird source code. This is fine, but not ideal. - Add something to the python code to remove empty paragraphs as part of the transformation. This works, but I would consider that it violates the principle of least surprise pretty badly, and will incur a performance cost every build, forever. Not ideal. - Add something to the pre commit checker that fails if they are present, and we must manually remove them. Seems okay to me. - Add a pre commit hook that runs an xsl stylesheet that just removes the empty paragraphs from a file. Could also have a pre commit hook that checks they are no longer present. This would also involve formatting all xhtml files probably. I had avoided this, soas to ensure that it was easy for peole to contribute xhtml files from the webinterface without setting up a local devenv, as we often see.

delliott referenced this issue

2025-10-26 15:03:53 +00:00

fix/paragraphs #5431

delliott commented

2025-10-26 15:22:30 +00:00

So, I have both check and format pre-commit hooks implemented in #5431 , I like the format hook except xsltproc makes a few changes, seemingly unavoidably, that result in a diff of +79124 -126340

So, I have both check and format pre-commit hooks implemented in https://git.fsfe.org/FSFE/fsfe-website/pulls/5431 , I like the format hook except `xsltproc` makes a few changes, seemingly unavoidably, that result in a diff of `+79124 -126340`

tobiasd referenced this issue from a commit

2025-10-30 12:35:01 +00:00

fix/paragraphs (#5431)

delliott commented

2025-10-31 13:04:02 +00:00

Should this be closed, as we have merged #5431?

Should this be closed, as we have merged https://git.fsfe.org/FSFE/fsfe-website/pulls/5431?

👍 2

tobiasd closed this issue

2025-10-31 13:59:12 +00:00

Sign in to join this conversation.