emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Bug: HTML export ignoring CUSTOM_ID properties


From: Rasmus
Subject: Re: [O] Bug: HTML export ignoring CUSTOM_ID properties
Date: Sat, 18 Apr 2015 15:57:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Hi,

address@hidden (T.F. Torrey) writes:

>>> With the latest from Git master, the HTML export ignores CUSTOM_ID
>>> properties for subtrees.  I've seen list traffic that the names of the
>>> export ID's are being changed, but this is not intentional, right?
>>
>> It doesn't ignore it, but it is translate to a generic anchor as
>> needed.
>
> Isn't translating it to a generic anchor the same as ignoring it?
> Without a CUSTOM_ID you get a generic anchor.  With a CUSTOM_ID you get
> a generic anchor.

You click it and it still works.  It's not ignored.  Within the syntax it
does the right thing.

> Because I know (knew) the id of the section about Clinton, I could link
> to my page from another document outside Org with a link to
> presidents.html#clinton.

Presumably you could use presidents.org::#clinton still.


> Notice how my CUSTOM_ID's are no longer ID's at all.  And simply adding
> "text-" to my CUSTOM_ID's is not an answer.  For one thing, CUSTOM_ID
> exports should not change on the breeze of developer whims.  For
> another, the ID should be attached to the heading, not the body of the
> text; otherwise, a person following the link would have no idea if it
> went to the Clinton section or not.
>
> Note that this also breaks any CSS styling for the section with the
> CUSTOM_ID (which I also use).  If I used a CUSTOM_ID because wanted a
> swanky background for the heading saying "Bill Clinton", the current
> export not only doesn't use that ID, it doesn't encompass the heading
> with his name in.

I have a half-baked patch that restores the old behavior, but I have to
think a bit more about it, and I won't have time today.  Nicolas might
also see it in the coming days.  E.g. ox-latex has org-latex--label.  The
question is whether there should be a solution in ox or whether each
backend should have org-BACKEND--label.

>> Thus, I think it is a bug, unless there is a better way to allow
>> per-section css. I will look at this later unless somebody beets me to it.
>
> Given the lack of outcry, I may be the only one using CUSTOM_ID's for
> HTML export.  However, if usage is widespread enough and accidental
> duplicates are a problem enough that this needs to be addressed,
> wouldn't it be better for the exporter to simply report duplicate ID's
> as they are found?

It was changed this week.

> Finally, given that this doesn't appear to work at all in any form of
> its intended usage, how did this even get committed to master?  Sure,
> code in master may have bugs, but this is more than a bug; this is
> unusable code that breaks code that worked.  Shouldn't it be developed
> on a feature branch or in someone's private repo until it actually
> works?

Master is where we develop things.  Nicolas made the change and he's off
this week.  Feel free to use Org 8.2.

> Unless there is a quick fix that restores external (non-Org-generated)
> links to sections with CUSTOM_ID's, please revert these changes until
> the development reaches a usable state.

Won't happen.

—Rasmus

-- 
I hear there's rumors on the, uh, Internets. . .



reply via email to

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