From: Tim Cross <firstname.lastname@example.org>
Subject: Re: [PATCH] tweaks to ox-html style
Date: Sat, 13 Feb 2021 08:46:52 +1100 [thread overview]
Message-ID: <email@example.com> (raw)
Jens Lechtenboerger <firstname.lastname@example.org> writes:
> On 2021-02-12, Kyle Meyer wrote:
>> TEC writes:
>>> Hi All,
>>> This is just some tweaks to the styling in ox-html that I think may
>>> appeal (and prevent ridiculously long lines on non-small displays, which
>>> are an issue for legibility).
>>> I also took the opportunity to remove the (obsolete) CDATA strings and
>>> make the CSS more consistently formatted. If you don't want this to
>>> get its own commit, please just squash it.
>>> Style changes:
>>> - Restrict max content width, and centre
>>> - tweak styling of source code blocks
>> I'm sure there are plenty of opinionated ox-html users on the list. Is
>> anyone willing to provide feedback on this series? Please don't assume
>> you need commit access to provide reviews.
> Hi there,
> I do not know why the CDATA lines exist. I don’t see a reason to
> keep them (patch 0001), but that might be a lack of understanding on
> my part.
> Patch 0003 is about whitespace fixes.
> Patches 0002, 0004, 0005 change defconst styling. I don’t have a
> strong opinion here. However, if they are changed now, what about
> turning them into defcustoms? Then each of us would be entitled to
> their own opinion ;)
> The docstring for org-html-head-include-default-style says that
> org-html-style-default (a defconst proposed to be changed here)
> should not be changed. Why not?
I think I pretty much agree here. IMO I think all the CSS styling in an
export should be defined with defcustom. CSS has come a long way since
the original HTML exporter was written and I think it is best to put
this power in the hands of the author. I realise some of this CSS
styling can be complex if we want good looking HTML exports and making
it available to be changed by the user could result in an increase in
issues relating to inconsistent or ugly output, but I think provided the
defaults are good, this risk is warranted.
My only question is whether we should continue to modify the current
html exporter or whether it would be better to rename the existing
exporter as xhtml exporter and do a new clean html exporter that is just
html5 and css3 and which does not attempt to be xhtml compliant?
Others have mentioned on the list that they believe it is important to
keep xhtml compatibility. This would satisfy that requirement and at the
same time, enable a new html exporter that can take full advantage of
changes introduced with html5 while keeping the exporter smaller and
cleaner (and easier to maintain).
BTW I think it would be nice if the html export was able to produce/use
a separate CSS file rather than in-line styles. This would make it
easier to drop exported HTML files into existing sites with custom
styles or update the look of exported files without needing to re-export
or manually edit. The complication is with exporting of HTML snippets,
where you probably want in-line styles.
next prev parent reply other threads:[~2021-02-12 22:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 10:46 [PATCH] TEC
2021-01-20 11:00 ` [PATCH] tweaks to ox-html style TEC
2021-02-12 6:16 ` Kyle Meyer
2021-02-12 16:57 ` Jens Lechtenboerger
2021-02-12 17:08 ` Jens Lechtenboerger
2021-02-12 18:22 ` Timothy
2021-02-13 14:43 ` Jens Lechtenboerger
2021-02-12 18:16 ` Timothy
2021-02-12 21:46 ` Tim Cross [this message]
2021-02-13 9:28 ` Eric S Fraga
2021-02-13 13:32 ` Christian Moe
2021-02-14 4:36 ` Timothy
2021-04-28 3:38 ` [PATCH] Bastien
2021-04-28 3:53 ` [PATCH] Timothy
2021-04-28 6:36 ` [PATCH] Bastien
2021-04-28 6:33 ` [PATCH] Bastien
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).