From: Aankhen <aankhen@gmail.com>
To: Org-mode ml <emacs-orgmode@gnu.org>, Eric S Fraga <e.fraga@ucl.ac.uk>
Subject: Re: Re: unnumbered subsections in latex export
Date: Wed, 6 Apr 2011 03:15:27 +0530 [thread overview]
Message-ID: <BANLkTin04RC8dK2t+2G4SVBzQhU52ATS+g@mail.gmail.com> (raw)
In-Reply-To: <87wrj8pkgq.fsf@ucl.ac.uk>
On Wed, Apr 6, 2011 at 00:57, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> Aankhen <aankhen@gmail.com> writes:
>
> [...]
>
>> Thank you for the clarifications. I’m going to talk a bit more about
>> HTML as that’s where I have the most experience. I am in agreement
>> 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). When
>> you have the following markup:
>>
>> ,----
>> | <acronym title="Hypertext Markup Language">HTML</acronym> is a
>> | language for marking up documents. The most current version
>> | of <acronym title="Hypertext Markup Language">HTML</acronym> is 4.01.
>> | The successor to <acronym title="Hypertext Markup
>> | Language">HTML</acronym>, HTML5, is currently under development.
>> `----
>>
>> The expansion is invisible by default; it shows up in a tooltip when
>> you hover over the text. You 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’t.
>
> There are those of us that, for one reason or another, do *not* use a
> mouse or any other graphical pointer. Tooltips do not appear ever in
> those cases. I 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’m not certain how text-based browsers deal with
‘title’ attributes in general. I see that Lynx, for one, can make use
of them on links.[1] Unfortunately, I can’t find any material on other
text mode browsers. Everything I read points at them mostly ignoring
‘title’. Ideally, text mode browsers would provide a way to 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 ‘abbr’ (‘acronym’ is
>> deprecated thanks to HTML5) with the ‘title’ defined for each
>> occurrence, and with CSS to ensure consistent rendering, along these
>> lines:
>>
>> ,----
>> | abbr { font-variant: small-caps; border-bottom: 1px dashed; cursor: help; }
>> `----
>
> 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’m 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. I feel that’s 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. Of 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 ‘title’, I can only agree with you. How about something like
this:
,----
| <p>I’m going to introduce a new <abbr>TLA</abbr> (Three-Letter
| Acronym). This <a href="#abbr-TLA">TLA</a> is a very
| special <a href="#abbr-TLA">TLA</a> as it comes straight from my
| heart.
| ⋮
| <h2>Acronyms & abbreviations</h2>
| <dl>
| <dt id="abbr-TLA">TLA
| <dd>Three-Letter Acronym
| <dt id="abbr-YAAA">YAAA
| <dd>Yet Another Alliterative Acronym
| <dt id="abbr-Dr">Dr.
| <dd>Doctor
| </dl>
`----
In case of a nested link, maybe a break in the outer link could solve it:
,----
| Let us read <a href="http://www.w3.org/TR/html401/">the
| HTML</a><sup><a href="#abbr-HTML">[def]</a></sup><a
href="http://www.w3.org/TR/html401/">
| specification</a> 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
next prev parent reply other threads:[~2011-04-05 21:45 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-22 12:10 unnumbered subsections in latex export Suvayu Ali
2011-03-22 12:20 ` Sébastien Vauban
2011-03-22 12:31 ` Suvayu Ali
2011-03-22 12:56 ` Sébastien Vauban
2011-03-22 14:26 ` [PATCH] Allow mixed export of numbered and unnumbered sections in LaTeX Lawrence Mitchell
2011-03-22 22:52 ` Suvayu Ali
2011-03-23 14:04 ` [Accepted] " Bastien Guerry
2011-03-23 14:17 ` [PATCH] " Bastien
2011-03-22 14:35 ` Re: unnumbered subsections in latex export Nick Dokos
2011-03-22 23:08 ` Suvayu Ali
2011-03-22 23:21 ` Nick Dokos
2011-03-23 9:38 ` [PATCH] Allow mixed export of numbered and unnumbered sections in HTML Lawrence Mitchell
2011-03-23 14:05 ` [Accepted] " Bastien Guerry
2011-03-23 14:57 ` Nick Dokos
2011-03-23 15:50 ` Suvayu Ali
2011-03-23 14:18 ` Re: unnumbered subsections in latex export Bastien
2011-03-23 15:02 ` Nick Dokos
2011-03-23 16:25 ` Lawrence Mitchell
2011-03-23 16:42 ` Nick Dokos
2011-03-23 18:17 ` Jambunathan K
2011-03-23 19:00 ` Nick Dokos
2011-03-23 19:18 ` Jambunathan K
2011-03-23 16:29 ` Thomas S. Dye
2011-03-23 17:42 ` Jambunathan K
2011-03-24 7:59 ` Bastien
2011-03-24 18:27 ` Achim Gratz
2011-03-24 19:25 ` Nick Dokos
2011-03-25 1:06 ` Suvayu Ali
2011-04-04 14:39 ` Sébastien Vauban
2011-04-04 17:04 ` Nick Dokos
2011-04-04 20:32 ` Aankhen
2011-04-05 10:16 ` Sébastien Vauban
2011-04-05 19:07 ` Aankhen
2011-04-05 19:27 ` Eric S Fraga
2011-04-05 21:25 ` New features for the exporters? Sébastien Vauban
2011-04-05 21:45 ` Aankhen [this message]
2011-04-06 18:49 ` unnumbered subsections in latex export Matt Lundin
2011-04-06 20:19 ` Sébastien Vauban
2011-03-27 11:16 ` Jambunathan K
2011-03-27 11:40 ` Bastien
2011-03-31 21:58 ` Nicolas
2011-04-01 4:34 ` Jambunathan K
2011-04-01 4:41 ` Jambunathan K
2011-04-01 6:29 ` Nick Dokos
2011-04-01 15:41 ` Eric S Fraga
2011-04-04 14:00 ` Matt Lundin
2011-04-04 14:12 ` Jambunathan K
2011-04-04 16:36 ` Matt Lundin
2011-04-04 17:09 ` Nick Dokos
2011-04-01 7:39 ` Jambunathan K
2011-04-01 18:25 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTin04RC8dK2t+2G4SVBzQhU52ATS+g@mail.gmail.com \
--to=aankhen@gmail.com \
--cc=e.fraga@ucl.ac.uk \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).