[-- Attachment #1: Type: text/plain, Size: 877 bytes --] When I export this sample org file: * top-level header ** and here we have #2 The body of the generated html has this content: <div id="content"> <h1 class="title">top-level header</h1> <div id="outline-container-orgd9fc9e6" class="outline-2"> <h2 id="orgd9fc9e6">and here we have #2</h2> </div> </div> I would prefer the html to not have these id or class properties; something like this: <div> <h1>top-level header</h1> <div> <h2>and here we have #2</h2> </div> </div> Actually, I'd rather skip the divs entirely, but that is a separate issue. Could there be a configurable way to disable the creation of these properties? I have searched the mailing list, and have not found anything. Perhaps I've missed something; there are a lot of results for "html class id" or similar searches. Thanks. [-- Attachment #2: Type: text/html, Size: 1174 bytes --]
Hello, I'm not really familiar with the internals of the built-in html exporter but the slimhtml exporter [https://github.com/balddotcat/ox-slimhtml] might be closer to what you're looking for. best regards, András On Sat, 10 Jul 2021 at 09:08, Zachary Kanfer <zkanfer@gmail.com> wrote: > > When I export this sample org file: > > * top-level header > ** and here we have #2 > > The body of the generated html has this content: > > <div id="content"> > <h1 class="title">top-level header</h1> > <div id="outline-container-orgd9fc9e6" class="outline-2"> > <h2 id="orgd9fc9e6">and here we have #2</h2> > </div> > </div> > > I would prefer the html to not have these id or class properties; something like this: > > <div> > <h1>top-level header</h1> > <div> > <h2>and here we have #2</h2> > </div> > </div> > > Actually, I'd rather skip the divs entirely, but that is a separate issue. Could there be a configurable way to disable the creation of these properties? I have searched the mailing list, and have not found anything. Perhaps I've missed something; there are a lot of results for "html class id" or similar searches. Thanks.
[-- Attachment #1: Type: text/plain, Size: 1626 bytes --] That is an interesting exporter. Is it actually part of orgmode? I don't see it in the org repository. I don't want to rely on downloading something from an archived repository that won't get bugfixes. On Sat, Jul 10, 2021 at 3:41 AM András Simonyi <andras.simonyi@gmail.com> wrote: > Hello, > I'm not really familiar with the internals of the built-in html > exporter but the slimhtml exporter > [https://github.com/balddotcat/ox-slimhtml] might be closer to what > you're looking for. > > best regards, > András > > On Sat, 10 Jul 2021 at 09:08, Zachary Kanfer <zkanfer@gmail.com> wrote: > > > > When I export this sample org file: > > > > * top-level header > > ** and here we have #2 > > > > The body of the generated html has this content: > > > > <div id="content"> > > <h1 class="title">top-level header</h1> > > <div id="outline-container-orgd9fc9e6" class="outline-2"> > > <h2 id="orgd9fc9e6">and here we have #2</h2> > > </div> > > </div> > > > > I would prefer the html to not have these id or class properties; > something like this: > > > > <div> > > <h1>top-level header</h1> > > <div> > > <h2>and here we have #2</h2> > > </div> > > </div> > > > > Actually, I'd rather skip the divs entirely, but that is a separate > issue. Could there be a configurable way to disable the creation of these > properties? I have searched the mailing list, and have not found anything. > Perhaps I've missed something; there are a lot of results for "html class > id" or similar searches. Thanks. > [-- Attachment #2: Type: text/html, Size: 2423 bytes --]
Hi Zachary, Zachary Kanfer writes: > That is an interesting exporter. Is it actually part of orgmode? I don't > see it in the org repository. I don't want to rely on downloading something > from an archived repository that won't get bugfixes. Indeed, ox-slimhtml is not part of Org at the moment, but I'm hoping it can be. I'm trying to revive discussion about it on this list, if you'd be interested in following and/or chiming in. -- https://bndl.org
[-- Attachment #1: Type: text/plain, Size: 821 bytes --] Sure, I'm generally interested in making this useful. Weird that it claims to be part of org, but isn't. I do think it would be useful to have a minimalist html exporter in org, whether slimhtml or some other one. The built-in html exporter is rather opinionated. On Sun, Oct 3, 2021, 11:57 AM Amin Bandali <bandali@gnu.org> wrote: > Hi Zachary, > > Zachary Kanfer writes: > > > That is an interesting exporter. Is it actually part of orgmode? I don't > > see it in the org repository. I don't want to rely on downloading > something > > from an archived repository that won't get bugfixes. > > Indeed, ox-slimhtml is not part of Org at the moment, but I'm hoping > it can be. I'm trying to revive discussion about it on this list, > if you'd be interested in following and/or chiming in. > > -- > https://bndl.org > [-- Attachment #2: Type: text/html, Size: 1310 bytes --]
Zachary Kanfer <zkanfer@gmail.com> writes:
> Sure, I'm generally interested in making this useful. Weird that it claims to be part of org, but isn't.
>
> I do think it would be useful to have a minimalist html exporter in org, whether slimhtml or some other one. The built-in html
> exporter is rather opinionated.
>
I tend to agree. Although this would be difficult to achieve now because
of the impact it would have on end users, I think the best architecture
for org would be for ALL exporters to be basic 'no thrills' exporters
and more advanced, opinionated or specialised exporters provided as
external ELPA or NONGNUE ELPA add ons which are not part of the core
architecture. Org maintenance could then just focus on core
functionality and an API which make implementing extensions/add-ons
easier.
I also agree with Bastien that adding a second HTML exporter as part of
the core is likely to lead to confusion and additional maintenance.
Probably what is needed is a new HTML exporter which is capable of doing
what slimhtml does as the default, but includes the additional
functionality already in the exporter which many people are using.
Getting this right is definitely a non-trivial problem.
[-- Attachment #1: Type: text/plain, Size: 642 bytes --] Hi Tim, > Probably what is needed is a new HTML exporter which is capable of doing > what slimhtml does as the default, but includes the additional > functionality already in the exporter which many people are using. I think there may be some promise in the idea of rewriting (large parts of) the current HTML exporter. The way that the web has changed over the last decade I think we can now make some assumptions that can simplify things — for example I think we could safely go HTML5-only. Not something I have time to investigate now, but in a month or two (or three 😛) I might take a look. All the best, Timothy
[-- Attachment #1: Type: text/plain, Size: 878 bytes --] On Mon., Oct. 4, 2021, 2:21 a.m. Timothy, <tecosaur@gmail.com> wrote: > Hi Tim, > > > Probably what is needed is a new HTML exporter which is capable of doing > > what slimhtml does as the default, but includes the additional > > functionality already in the exporter which many people are using. > > I think there may be some promise in the idea of rewriting (large parts > of) the > current HTML exporter. The way that the web has changed over the last > decade I > think we can now make some assumptions that can simplify things — for > example > I think we could safely go HTML5-only > > It seems to me that if the html exporter is being rewritten, we might want to think about ways to make it easier to export some elements as custom components. As their use becomes more and more common, I would reckon this will be a desirable feature. > > [-- Attachment #2: Type: text/html, Size: 1489 bytes --]
Timothy <tecosaur@gmail.com> writes:
> Not something I have time to investigate now, but in a month or two (or
> three 😛) I might take a look.
I am bumping this. Just in case ;)
[-- Attachment #1: Type: text/plain, Size: 406 bytes --] Hi Ihor, >> Not something I have time to investigate now, but in a month or two (or >> three 😛) I might take a look. > > I am bumping this. Just in case ;) This definitely needs a bump, however I think the ETA is still “a few months” with the current projects I’ve got eating my time 😅. Unless somebody might happen to have a cloning pod available… 👀 All the best, Timothy