emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tweaks to ox-html style


From: Tim Cross
Subject: Re: [PATCH] tweaks to ox-html style
Date: Sat, 13 Feb 2021 08:46:52 +1100
User-agent: mu4e 1.5.8; emacs 27.1.91

Jens Lechtenboerger <lechten@wi.uni-muenster.de> 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.

--
Tim Cross



reply via email to

[Prev in Thread] Current Thread [Next in Thread]