From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aankhen Subject: Re: Re: unnumbered subsections in latex export Date: Wed, 6 Apr 2011 03:15:27 +0530 Message-ID: References: <20110322051038.21655c80@kuru.homelinux.net> <80d3lj9wj6.fsf@somewhere.org> <20110322053134.669127e9@kuru.homelinux.net> <8999.1300804510@alphaville.dokosmarshall.org> <20110322160814.227fc53f@bhishma.homelinux.net> <27844.1300836065@alphaville.usa.hp.com> <8162r9hgxm.fsf@gmail.com> <87bp11dk4h.fsf@gnu.org> <3553.1300994702@alphaville.usa.hp.com> <80ipuut70z.fsf@somewhere.org> <80mxk5t340.fsf@somewhere.org> <87wrj8pkgq.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=35811 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q7E4M-0003gS-Am for emacs-orgmode@gnu.org; Tue, 05 Apr 2011 17:45:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q7E4K-0001Ss-PH for emacs-orgmode@gnu.org; Tue, 05 Apr 2011 17:45:50 -0400 Received: from mail-vw0-f41.google.com ([209.85.212.41]:43332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q7E4K-0001Sj-L1 for emacs-orgmode@gnu.org; Tue, 05 Apr 2011 17:45:48 -0400 Received: by vws4 with SMTP id 4so871947vws.0 for ; Tue, 05 Apr 2011 14:45:47 -0700 (PDT) In-Reply-To: <87wrj8pkgq.fsf@ucl.ac.uk> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Org-mode ml , Eric S Fraga On Wed, Apr 6, 2011 at 00:57, Eric S Fraga wrote: > Aankhen writes: > > [...] > >> Thank you for the clarifications. =C2=A0I=E2=80=99m going to talk a bit = more about >> HTML as that=E2=80=99s where I have the most experience. =C2=A0I am in a= greement >> with you when you say that builtin support for acronyms would be >> useful (although I feel it would be good to generalize it to >> abbreviations, if that can also be supported in other backends). =C2=A0W= hen >> you have the following markup: >> >> ,---- >> | HTML is a >> | language for marking up documents. =C2=A0The most current version >> | of HTML is 4.01= . >> | The successor to > | Language">HTML, HTML5, is currently under development. >> `---- >> >> The expansion is invisible by default; it shows up in a tooltip when >> you hover over the text. =C2=A0You can try a live example to see for >> yourself.[1] In this way, the expansion is always there when you need >> it (and you can distinguish between multiple terms sharing the same >> acronym, should the need ever arise), but it takes up no space if you >> don=E2=80=99t. > > There are those of us that, for one reason or another, do *not* use a > mouse or any other graphical pointer. =C2=A0Tooltips do not appear ever i= n > those cases. =C2=A0I would like a solution that does not rely on any > particular graphical interface paradigm, basically! > > Of course, I know that I am in the minority here... but accessibility is > always an important factor and one that should not be ignored, IMO. Yes, I absolutely understand the concern, and I must confess I had overlooked it. I=E2=80=99m not certain how text-based browsers deal with =E2=80=98title=E2=80=99 attributes in general. I see that Lynx, for one, c= an make use of them on links.[1] Unfortunately, I can=E2=80=99t find any material on ot= her text mode browsers. Everything I read points at them mostly ignoring =E2=80=98title=E2=80=99. Ideally, text mode browsers would provide a way t= o get at it, as there is nothing tying the attribute to a graphical interface; in practice, it would seem that they took the easy way out. Understandable, given the rampant abuse of the tag. > >> I would suggest that, were Org to gain support for acronyms and/or >> abbreviations, they be exported in HTML using =E2=80=98abbr=E2=80=99 (= =E2=80=98acronym=E2=80=99 is >> deprecated thanks to HTML5) with the =E2=80=98title=E2=80=99 defined for= each >> occurrence, and with CSS to ensure consistent rendering, along these >> lines: >> >> ,---- >> | abbr { font-variant: small-caps; border-bottom: 1px dashed; cursor: he= lp; } >> `---- > > Does this still rely on tooltips? Yes. This CSS is only meant to standardize the presentation across graphical browsers. It is entirely possible to use CSS to display the expansion, I=E2=80=99m just not sure of the utility (and it relies on the browser not throwing away CSS): ,---- | abbr[title]:after, acronym[title]:after { content: " [" attr(title) "]"; = } `---- It defeats the purpose of the exercise in any case. >> I can see the argument for having a list at the end and linking each >> definition instead. =C2=A0I feel that=E2=80=99s less convenient, however= , as (a) it >> means temporarily losing your place in the document and (b) bunched-up >> anchors at the end of a document are a pain. =C2=A0Of course, >> alternatively, each acronym/abbreviation could be marked up only at >> the first occurrence; that seems like it would be easy to implement as >> a configuration option. > > I would like a combination of both, whenever possible: fully expanded > def'n in the text at the first occurrence and links to the list of > abbreviations/acronyms at the end for subsequent occurrences (modulo the > problems with double-links etc, for which I cannot propose a solution > unfortunately). Taking into consideration the fact that text-based browsers seem to ignore =E2=80=98title=E2=80=99, I can only agree with you. How about somet= hing like this: ,---- |

I=E2=80=99m going to introduce a new TLA (Three-Letter | Acronym). This TLA is a very | special TLA as it comes straight from my | heart. | =E2=8B=AE |

Acronyms & abbreviations

|
|
TLA |
Three-Letter Acronym |
YAAA |
Yet Another Alliterative Acronym |
Dr. |
Doctor |
`---- In case of a nested link, maybe a break in the outer link could solve it: ,---- | Let us read the | HTML[def] | specification together. `---- Not particularly pretty, but it seems to get the job done. Just one option= . At any rate, thanks for pointing this out. Aankhen [1]: http://diveintoaccessibility.org/day_14_adding_titles_to_links.html