From: Nicolas Goaziou <n.goaziou@gmail.com>
To: "T.F. Torrey" <tftorrey@tftorrey.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Bug: New HTML exporter incorrect attributes
Date: Mon, 25 Feb 2013 14:49:04 +0100 [thread overview]
Message-ID: <87vc9gfqr3.fsf@gmail.com> (raw)
In-Reply-To: <871uc4acid.fsf@lapcat.tftorrey.com> (T. F. Torrey's message of "Mon, 25 Feb 2013 03:55:38 -0700")
tftorrey@tftorrey.com (T.F. Torrey) writes:
>> It would be ATTR_HTML: :class "XXX". I try to unify syntax for
>> attributes with syntax for Babel and AFAICT, `html' is the last back-end
>> to have key="value" syntax.
>
> I see that this does not presently work, and the author listed on
> ox-html.el is not currently active on this list. I hope you are not the
> only one working on this. It would be our great misfortune for you to
> become burned out.
It's not much work once we agree about the real syntax. For example, for
links, there are two ways to replace:
#+ATTR_HTML: width="400px"
The easiest one, is simply to ask for `:options' before:
#+ATTR_HTML: :options "width=\"400px\""
This is heavier but will be consistent with other back-ends. Otherwise,
there is also:
#+ATTR_HTML: :width "400px"
But this requires to have a list of all properties supported. If we take
that route, here is a suggested list of such properties for <a> tag:
- rel
- target
- type
- accesskey
- class
- style
- title
and for <img>
- alt
- height
- width
What do you think about it?
> The HTML exporter should produce valid HTML regardless of the input.
We cannot remove the ability to shoot oneself in the foot. The HTML
back-end cannot be responsible for undefined syntax. Think about:
@@html:<foo>@@
> The Org manual describes ATTR_HTML as a feature that applies to the
> following image or link. It makes no mention of restrictions to
> following content in the paragraph, and neither does it say it will
> apply to all following images or links. The manual could be amended to
> say that ATTR_HTML applies to just the next image or link. To fit the
> current situation, it might say, "In cases where ATTR_HTML is applied to
> an image in a paragraph, following links will not be made invalid." But
> why would anyone be expecting invalid HTML in the first place?
>
> Incidentally, I always thought that simply using another HTML_ATTR would
> handle multiple images or links in the old exporter. In other words,
> this:
>
> #+ATTR_HTML: width="10" alt=" [Cool thing] "
> [[file:cool_thing.jpg]]
> This is a paragraph about cool things.
> #+ATTR_HTML: class="bar"
> Cool thing found here [[http://example.com/][example.com]].
>
> Would become this:
>
> <p>
> <img src="cool_thing.jpg" width="10" alt=" [Cool thing] "/>This is a
> paragraph about cool things. Cool thing found here <a
> href="http://example.com/" class="bar">example.com</a>.
> </p>
>
> I don't remember using that in the old exporter, but I thought it would
> work.
>
> It almost works in the new exporter, but it begins a new paragraph
> before the second #+ATTR_HTML. I'm not sure this is the intended
> behavior, though, because it isn't formatted like other new
> paragraphs.
This is the intended behaviour. Affiliated keywords can only exist at
the beginning of the element they refer to. So, in the previous example,
you start two paragraphs.
> Alternatively, having ATTR_HTML (or something more general) apply to the
> next thing, and having that work within paragraphs, is another
> possibility. However, this may not fit within the limitations of the
> new parser. Plus it's kind of ugly.
The parser won't support it. It goes against the definition of an
affiliated keyword. Moreover, it's merely a hack (what about links in
tables?). And it's ugly, indeed.
> Until there is a "proper" solution, however, could we please modify the
> exporter to apply ATTR_HTML to only the next image or link? I am very
> sure that was the spirit of the old exporter, and it would be nice if I
> could maintain my documents in Org without resorting to (even more)
> hacks.
Done.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2013-02-25 13:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 22:23 Bug: New HTML exporter incorrect attributes T.F. Torrey
2013-02-22 23:18 ` Nicolas Goaziou
2013-02-23 9:43 ` T.F. Torrey
2013-02-23 10:16 ` Nicolas Goaziou
2013-02-24 20:27 ` Samuel Wales
2013-02-25 8:23 ` Nicolas Goaziou
2013-02-25 10:55 ` T.F. Torrey
2013-02-25 13:49 ` Nicolas Goaziou [this message]
2013-02-25 13:57 ` Vincent Beffara
2013-02-25 14:03 ` Nicolas Goaziou
2013-02-25 20:51 ` T.F. Torrey
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=87vc9gfqr3.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=tftorrey@tftorrey.com \
/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).