unique id=-values in aggregated html-exported docs

unique id=-values in aggregated html-exported docs

[Dirk-Jan C. Binnema]

Hi all,

Recently, I've started using org + jekyll for blogging; it works well so far,
but I found a small issue when aggregating multiple org-exported-to-html
entries into one page. The problem is that some of the html-elements have
id=... attributes, which are supposed to be unique in a html document;
however, this fails when aggregating different elements into one. Similar
concern for other supposedly unique items like footnotes.

The id=-thing is mostly annoying because it makes html-tidy complain (and
breaks strict standard compliance), but e,g. the footnote issue could be
annoying in practice (i.e.. jumping to the wrong footnote).

So, one possible solution might be to have a way to make org prefix its
id-values with something truly unique, or even just a random number. Or is
there some other way to solve this?

Thanks in advance,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: unique id=-values in aggregated html-exported docs

[Christian Egli]

Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes:

> I found a small issue when aggregating multiple org-exported-to-html
> entries into one page. The problem is that some of the html-elements have
> id=... attributes, which are supposed to be unique in a html document;
> however, this fails when aggregating different elements into one.

Can you list which html elements are the problem? 

Does it help if you use the BODY-ONLY option (C-h f org-export-as-html)?

HTH
Christian
-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: Re: unique id=-values in aggregated html-exported docs

[Dirk-Jan C. Binnema]

Hi,

>>>>> On Tue, 11 May 2010 11:07:15 +0200, Christian Egli ("CE") wrote:

  CE> Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes:
  >> I found a small issue when aggregating multiple org-exported-to-html
  >> entries into one page. The problem is that some of the html-elements have
  >> id=... attributes, which are supposed to be unique in a html document;
  >> however, this fails when aggregating different elements into one.

  CE> Can you list which html elements are the problem? 
  CE> Does it help if you use the BODY-ONLY option (C-h f org-export-as-html)?

Actually, that's what I'm doing already (through org-publish). The final
(aggegated) result is at:
    http://www.djcbsoftware.nl/changelog/index.html 
I got warned by tidy. I think it wouldn't be too hard easy to fix this by
adding a per-document random cookie to these ids.

BTW, tidy also warned me about missing summary= attributes for tables; is
there some way to add those?

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: Re: unique id=-values in aggregated html-exported docs

[Sebastian Rose]

Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes:
> Hi,
>
>>>>>> On Tue, 11 May 2010 11:07:15 +0200, Christian Egli ("CE") wrote:
>
>   CE> Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes:
>   >> I found a small issue when aggregating multiple org-exported-to-html
>   >> entries into one page. The problem is that some of the html-elements have
>   >> id=... attributes, which are supposed to be unique in a html document;
>   >> however, this fails when aggregating different elements into one.
>
>   CE> Can you list which html elements are the problem? 
>   CE> Does it help if you use the BODY-ONLY option (C-h f org-export-as-html)?
>
> Actually, that's what I'm doing already (through org-publish). The final
> (aggegated) result is at:
>     http://www.djcbsoftware.nl/changelog/index.html 
> I got warned by tidy. I think it wouldn't be too hard easy to fix this by
> adding a per-document random cookie to these ids.

Can you verify, that those are clashing IDs?

I get an error from PHP's DOMDocument, that an ID is already
defined. But it is not.  There's still that old compatibility `name'
attribute left with the same value as the ID attribute. That's all.


I would through out.
The decision to keep it is two years old. And it was point of discussion
even by then.


> BTW, tidy also warned me about missing summary= attributes for tables; is
> there some way to add those?

Yes, summary is required. We all forgot to add it. It's meant to take a
description of the table's content and some browsers use it for
accessability purposes (I guess the summary is read aloud then).

A quick fix would be to just add `summary=""' to the table definition:

   <table summary="" ...>



Tehom, how far is the HTML-exporter-overhaul?


  Sebastian

Re: Re: unique id=-values in aggregated html-exported docs

[Dirk-Jan C. Binnema]

>>>>> On Tue, 11 May 2010 21:11:04 +0200, Sebastian Rose ("SR") wrote:

  SR> Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes:
  >> Hi,
  >> 
  >>>>>>> On Tue, 11 May 2010 11:07:15 +0200, Christian Egli ("CE") wrote:
  >> 
  CE> Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes:
  >> >> I found a small issue when aggregating multiple org-exported-to-html
  >> >> entries into one page. The problem is that some of the html-elements have
  >> >> id=... attributes, which are supposed to be unique in a html document;
  >> >> however, this fails when aggregating different elements into one.
  >> 
  CE> Can you list which html elements are the problem? 
  CE> Does it help if you use the BODY-ONLY option (C-h f org-export-as-html)?
  >> 
  >> Actually, that's what I'm doing already (through org-publish). The final
  >> (aggegated) result is at:
  >> http://www.djcbsoftware.nl/changelog/index.html 
  >> I got warned by tidy. I think it wouldn't be too hard easy to fix this by
  >> adding a per-document random cookie to these ids.

  SR> Can you verify, that those are clashing IDs?

Sure:

--8<---------------cut here---------------start------------->8--
  % cat index.html | grep id=
[....]
  
   <div id="outline-container-1" class="outline-3">
            <h3 id="sec-1">
            <div class="outline-text-3" id="text-1">
          <div id="outline-container-1" class="outline-3">
            <h3 id="sec-1">
            <div class="outline-text-3" id="text-1">
          <div id="outline-container-2" class="outline-3">
            <h3 id="sec-2">
            <div class="outline-text-3" id="text-2">
          <div id="outline-container-1" class="outline-3">
            <h3 id="sec-1">
            <div class="outline-text-3" id="text-1">
          <div id="outline-container-2" class="outline-3">
[...]
--8<---------------cut here---------------end--------------->8---

So, the issue is with aggregating separate exported html blobs into one page;
of course org-mode has no real control over the uniqueness of the ids then.

My idea would be that we could add some per-exported org-file cookie, so the
ids could be something like:

   id="text-456EF-1"
   
Then we shouldn't get these clashes when aggregating them later. It's a bit of
a small imperfection, except when you want to do something with those ids.

There is a somewhat related issue with footnotes (id=footnotes and
href=#fnr.1), that could be a practical problem, i.e.. you might jump to the
wrong footnote.

  >> BTW, tidy also warned me about missing summary= attributes for tables; is
  >> there some way to add those?

  SR> Yes, summary is required. We all forgot to add it. It's meant to take a
  SR> description of the table's content and some browsers use it for
  SR> accessability purposes (I guess the summary is read aloud then).

  SR> A quick fix would be to just add `summary=""' to the table definition:

  SR>    <table summary="" ...>

Well, it's easy to shut up the html-validators (like tidy), but for true
accessibility it'd be nice to set the summary to something meaningful (same
for the alt= attribute of images). Not sure if that is a priority right now,
and I guess it might add some complexity.

Anyway, these are all fairly minor points (for me at least, I don't use the
a11y stuff -- in general I'd like to applaud the excellent work that has been
done in the html-export area, which I enjoy every day.

Best wishes,
Dirk.

[1] http://tidy.sourceforge.net/


-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: Re: unique id=-values in aggregated html-exported docs

[Sebastian Rose]

Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes
>>>>>> On Tue, 11 May 2010 21:11:04 +0200, Sebastian Rose ("SR") wrote:
>
>   SR> Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes:
>   >> Hi,
>   >> 
>   >>>>>>> On Tue, 11 May 2010 11:07:15 +0200, Christian Egli ("CE") wrote:
>   >> 
>   CE> Dirk-Jan C. Binnema <djcb.bulk@gmail.com> writes:
>   >> >> I found a small issue when aggregating multiple org-exported-to-html
>   >> >> entries into one page. The problem is that some of the html-elements have
>   >> >> id=... attributes, which are supposed to be unique in a html document;
>   >> >> however, this fails when aggregating different elements into one.
>   >> 
>   CE> Can you list which html elements are the problem? 
>   CE> Does it help if you use the BODY-ONLY option (C-h f org-export-as-html)?
>   >> 
>   >> Actually, that's what I'm doing already (through org-publish). The final
>   >> (aggegated) result is at:
>   >> http://www.djcbsoftware.nl/changelog/index.html 
>   >> I got warned by tidy. I think it wouldn't be too hard easy to fix this by
>   >> adding a per-document random cookie to these ids.
>
>   SR> Can you verify, that those are clashing IDs?
>
> Sure:
>
>
>   % cat index.html | grep id=
> [....]
>   
>    <div id="outline-container-1" class="outline-3">
>             <h3 id="sec-1">
>             <div class="outline-text-3" id="text-1">
>           <div id="outline-container-1" class="outline-3">
>             <h3 id="sec-1">
>             <div class="outline-text-3" id="text-1">
>           <div id="outline-container-2" class="outline-3">
>             <h3 id="sec-2">
>             <div class="outline-text-3" id="text-2">
>           <div id="outline-container-1" class="outline-3">
>             <h3 id="sec-1">
>             <div class="outline-text-3" id="text-1">
>           <div id="outline-container-2" class="outline-3">
> [...]


Funny - cannot verify that and never saw it. Why are your section
numbers not increased?

Could you please provide a simple testfile?



> So, the issue is with aggregating separate exported html blobs into one page;
> of course org-mode has no real control over the uniqueness of the ids then.
>
> My idea would be that we could add some per-exported org-file cookie, so the
> ids could be something like:
>
>    id="text-456EF-1"


How to refer to a certain section in a stylesheet then?


> Then we shouldn't get these clashes when aggregating them later. It's a bit of
> a small imperfection, except when you want to do something with those ids.
>
> There is a somewhat related issue with footnotes (id=footnotes and
> href=#fnr.1), that could be a practical problem, i.e.. you might jump to the
> wrong footnote.
>
>   >> BTW, tidy also warned me about missing summary= attributes for tables; is
>   >> there some way to add those?
>
>   SR> Yes, summary is required. We all forgot to add it. It's meant to take a
>   SR> description of the table's content and some browsers use it for
>   SR> accessability purposes (I guess the summary is read aloud then).
>
>   SR> A quick fix would be to just add `summary=""' to the table definition:
>
>   SR>    <table summary="" ...>
>
> Well, it's easy to shut up the html-validators (like tidy), but for true
> accessibility it'd be nice to set the summary to something meaningful (same
> for the alt= attribute of images). Not sure if that is a priority right now,
> and I guess it might add some complexity.

Agreed. But Org cannot guess.


> Anyway, these are all fairly minor points (for me at least, I don't use the
> a11y stuff -- in general I'd like to applaud the excellent work that has been
> done in the html-export area, which I enjoy every day.


Regards

  Sebastian

Re: Re: unique id=-values in aggregated html-exported docs

[Dirk-Jan C. Binnema]

Hi,

>>>>> On Wed, 12 May 2010 19:02:42 +0200, Sebastian Rose ("SR") wrote:


  SR> Can you verify, that those are clashing IDs?
  >> 
  >> Sure:
  >> 
  >> 
  >> % cat index.html | grep id=
  >> [....]
  >> 
  >> <div id="outline-container-1" class="outline-3">
  >> <h3 id="sec-1">
  >> <div class="outline-text-3" id="text-1">
  >> <div id="outline-container-1" class="outline-3">

  SR> Funny - cannot verify that and never saw it. Why are your section
  SR> numbers not increased?

  SR> Could you please provide a simple testfile?

Well, the issue is about *aggregated* html files; so
      test1.org => test1.html, and
      test2.org => test2.html
in both test1.html and test2.html, the ids will be unique; the problem occurs
when we aggregate (concatenate) test1.html and test2.html into a big html
file; this is e.g. what happens when creating a blog, and your putting
together the last n posts. Then, the ids in the aggregated document will not
be unique.
  

  >> So, the issue is with aggregating separate exported html blobs into one
  >> page; of course org-mode has no real control over the uniqueness of the
  >> ids then.
  >> 
  >> My idea would be that we could add some per-exported org-file cookie, so
  >> the ids could be something like:
  >> 
  >> id="text-456EF-1"

  SR> How to refer to a certain section in a stylesheet then?

For aggregated documents that does not really work when using ids; instead,
classes are to be used for that. I mean, with aggregated documents there may
be multiple text-1 and (worse) multiple footnotes.

I'm not sure, why would one want to use ids in this case, and not classes?


  SR> A quick fix would be to just add `summary=""' to the table definition:
  >> 
  SR> <table summary="" ...>
  >> 
  >> Well, it's easy to shut up the html-validators (like tidy), but for true
  >> accessibility it'd be nice to set the summary to something meaningful
  >> (same for the alt= attribute of images). Not sure if that is a priority
  >> right now, and I guess it might add some complexity.

  SR> Agreed. But Org cannot guess.

Indeed; I have no idea how hard it would be to add e.g,.

  #+summary: table of foo per capita
(which could also be use for the alt= is in html image export)

org-babel already has #+tblname; maybe that could be extended?
  
Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C