Re: [O] Attributes on HTML tables?
Eric- Rick Frankel r...@rickster.com writes: I would argue that to set the element type fro the outer (outline-container) div or the inner (outline-text) div, a property setting would make more sense. I can see using a (headline level) :HTML_CONTAINER property to set the container on a given headline (which i think i will impliment as it is very low impact), and perhaps either an :HTML_CHILD_CONTAINER or :HTML_TEXT_CONTAINER to specify the wrapper on the inner section. I have pushed to master the abilty to set the :HTML_CONTAINER property on any headline and have that value override the default (:html-container for level 1 headines, div for the rest). Note that this is not an inherited property so only affect the headline it is specified on, not it's children. rick
Re: [O] Attributes on HTML tables?
Hi Rick, Rick Frankel r...@rickster.com writes: However, you will need to change the html-table-tag to not use attributes, and remove the xml declaration (which is a warning and not an error in html5) (Note that `org-html-table-tag' has been deleted, you need to check `org-html-table-default-attributes' instead.) The HTML5 validation is good news and your example is great. Would be nice to have this in worg/org-faq.org! Thanks, -- Bastien
Re: [O] Attributes on HTML tables?
Rick Frankel r...@rickster.com writes:
On Sat, Apr 13, 2013 at 01:31:17PM +0800, Eric Abrahamsen wrote:
Eric Abrahamsen e...@ericabrahamsen.net writes:
François Pinard pin...@iro.umontreal.ca writes:
Bastien b...@gnu.org writes:
Eric Abrahamsen e...@ericabrahamsen.net writes:
The first step is probably to research the differences between xhtml and
html 5.
Well, I would even skip this step and just hack something usable.
I sort of fudged on the below. The upside is that it should be pretty
forgiving now: you can set all kinds of strings as your :html-doctype,
and it will do a reasonably good job of guessing how to handle it.
Barring actual bugs or poor design decisions, what's left to do is:
1. Make sure that inlined script and style chunks are escaped correctly,
I seem to remember reading that the commenting/escaping syntax for these
chunks varies according to html flavor.
2. I'd like to add the possibility to put an arbitrary :html-container
#+BEGIN_SRC emacs-lisp
#+TITLE: HTML 5 Test
#+DATE: {{{modification-time(%Y-%m-%d)}}}
#+HTML_DOCTYPE: html5
#+BIND: org-html-divs ((preamble header preamble) (content section
content) (postamble footer postamble))
* Org HTML5 Test
#+ATTR_HTML: :options html-container article
note that you just just set #+HTML_CONTAINER: article in the head of the
file if you want all the containers to be articles.
That would be pretty drastic, though -- it would wrap article around a
whole bunch of stuff that shouldn't be an article! I think ultimately
the HTML exporter should grow a slightly more flexible system for
wrapping document sections in containers, but this patch definitely
shouldn't get hung up on that.
+(defconst org-html-doctype-alist
+ '((html4 . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\)
+(html4-strict . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\
+\http://www.w3.org/TR/html4/strict.dtd\;)
+(xhtml . !DOCTYPE HTML PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\
+\http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;)
+(html5 . !DOCTYPE HTML))
I believe that should be (note the lowercase html):
(xhtml . !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\
+\http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;)
(html5 . !DOCTYPE html)
See http://www.w3schools.com/tags/tag_doctype.asp for a fairly
complete list of valid doctypes.
Cool, thanks for the reference. If the approach of this patch seems
generally acceptable I'll try to add most of the commonly-used doctypes
in there. I'm waffling on XHTML5, though -- from what I can tell it's a
spec everyone sort of thought ought to be in there, but no one is
actually using.
E
Re: [O] Attributes on HTML tables?
On Sun, Apr 14, 2013 at 06:13:40PM +0800, Eric Abrahamsen wrote: Rick Frankel r...@rickster.com writes: On Sat, Apr 13, 2013 at 01:31:17PM +0800, Eric Abrahamsen wrote: * Org HTML5 Test #+ATTR_HTML: :options html-container article - a :: foo - b :: bar note that you just just set #+HTML_CONTAINER: article in the head of the file if you want all the containers to be articles. That would be pretty drastic, though -- it would wrap article around a whole bunch of stuff that shouldn't be an article! I think ultimately the HTML exporter should grow a slightly more flexible system for wrapping document sections in containers, but this patch definitely shouldn't get hung up on that. It specifies the element for the top-level container---by default, something like: div id=outline-container-sec-1 class=outline-2 In the case of e.g., a blog or slideshow, article is an appropriate top-level wrapper lelement. Regardless, I'm not sure which object you are expecting the #+ATTR_HTML to apply to in the example above. Here's the html the above section generates: #+BEGIN_HTML div id=outline-container-sec-5 class=outline-2 h2 id=sec-5span class=section-number-25/span A definiton list/h2 div class=outline-text-2 id=text-5 dl class=org-dl dt a /dtddfoo /dd dt b /dtddbar /dd /dl /div /div Where the 'outline-text-2' div is actually around the entire body of the section, not just the definition list (there is no explicit wrapper around the definition list). I would argue that to set the element type fro the outer (outline-container) div or the inner (outline-text) div, a property setting would make more sense. I can see using a (headline level) :HTML_CONTAINER property to set the container on a given headline (which i think i will impliment as it is very low impact), and perhaps either an :HTML_CHILD_CONTAINER or :HTML_TEXT_CONTAINER to specify the wrapper on the inner section. rick
Re: [O] Attributes on HTML tables?
On Fri, Apr 12, 2013 at 10:06:21AM +0800, Eric Abrahamsen wrote:
François Pinard pin...@iro.umontreal.ca writes:
Christian Moe m...@christianmoe.com writes:
While on this subject! :-)
Could Org allow the output of HTML5 rather than XHTML, under the control
of some option? I've read that some frameworks really expect HTML5 to
work properly, such an option might ease inter-operation between
exported Org and such frameworks.
I'm curious about this possibility as well -- how much work would it be?
Sorry, late to the thread, i've been laid up. Anyway, the xhtml output
from ox-html _should_ be
mostly valid html5 (valid xhtml 1.0 in general should be valid html5).
However, you will need to change the html-table-tag to not use
attributes, and remove the xml declaration
(which is a warning and not an error in html5)
Here's a sample org file (which changes the divs to be more html5ish
as well, not necessary)
which validates as HTML5: (btw, i've remove the scripts and
default-styles just to make the
html output smaller, the file will validate even with them in the
output).
rick
- % -
#+TITLE: HTML 5 Test
#+DATE: {{{modification-time(%Y-%m-%d)}}}
#+HTML_DOCTYPE: !DOCTYPE html
#+BIND: org-html-xml-declaration
#+BIND: org-html-head-include-default-style nil
#+BIND: org-html-table-tag table
#+BIND: org-html-scripts
#+BIND: org-html-divs ((preamble header preamble) (content
section content) (postamble footer postamble))
* Org HTML5 Test
ok?
* How about a table
| col1 | col2 |
|--+--|
| a|1 |
| b|2 |
* And a list
- a
- b
- c
* A definiton list
- a :: foo
- b :: bar
Re: [O] Attributes on HTML tables?
On Sat, Apr 13, 2013 at 01:31:17PM +0800, Eric Abrahamsen wrote:
Eric Abrahamsen e...@ericabrahamsen.net writes:
François Pinard pin...@iro.umontreal.ca writes:
Bastien b...@gnu.org writes:
Eric Abrahamsen e...@ericabrahamsen.net writes:
The first step is probably to research the differences between xhtml and
html 5.
Well, I would even skip this step and just hack something usable.
I sort of fudged on the below. The upside is that it should be pretty
forgiving now: you can set all kinds of strings as your :html-doctype,
and it will do a reasonably good job of guessing how to handle it.
Barring actual bugs or poor design decisions, what's left to do is:
1. Make sure that inlined script and style chunks are escaped correctly,
I seem to remember reading that the commenting/escaping syntax for these
chunks varies according to html flavor.
2. I'd like to add the possibility to put an arbitrary :html-container
#+BEGIN_SRC emacs-lisp
#+TITLE: HTML 5 Test
#+DATE: {{{modification-time(%Y-%m-%d)}}}
#+HTML_DOCTYPE: html5
#+BIND: org-html-divs ((preamble header preamble) (content section
content) (postamble footer postamble))
* Org HTML5 Test
#+ATTR_HTML: :options html-container article
note that you just just set #+HTML_CONTAINER: article in the head of the
file if you want all the containers to be articles.
+(defconst org-html-doctype-alist
+ '((html4 . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\)
+(html4-strict . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\
+\http://www.w3.org/TR/html4/strict.dtd\;)
+(xhtml . !DOCTYPE HTML PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\
+\http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;)
+(html5 . !DOCTYPE HTML))
I believe that should be (note the lowercase html):
(xhtml . !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\
+\http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;)
(html5 . !DOCTYPE html)
See http://www.w3schools.com/tags/tag_doctype.asp for a fairly
complete list of valid doctypes.
rick
Re: [O] Attributes on HTML tables?
Eric Abrahamsen e...@ericabrahamsen.net writes: The first step is probably to research the differences between xhtml and html 5. Well, I would even skip this step and just hack something usable. -- Bastien
Re: [O] Attributes on HTML tables?
Bastien b...@gnu.org writes: Eric Abrahamsen e...@ericabrahamsen.net writes: The first step is probably to research the differences between xhtml and html 5. Well, I would even skip this step and just hack something usable. There are validators out there, that could help us staying on track, whatever the track :-). François
Re: [O] Attributes on HTML tables?
François Pinard pin...@iro.umontreal.ca writes: Bastien b...@gnu.org writes: Eric Abrahamsen e...@ericabrahamsen.net writes: The first step is probably to research the differences between xhtml and html 5. Well, I would even skip this step and just hack something usable. Okay, I've got a nearly-working patch for this, but I'm falling down hard on the defcustom. Here's what I thought to do: #+BEGIN_SRC emacs-lisp (defconst org-html-doctype-alist '((html4 . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\) (html4-strict . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\ \http://www.w3.org/TR/html4/strict.dtd\;) (xhtml . !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\ \http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;) (html5 . !DOCTYPE HTML)) An alist mapping (x)html flavors to specific doctypes.) (defcustom org-html-doctype 'xhtml Document type definition to use for exported HTML files. Can be set with the in-buffer HTML_DOCTYPE property or for publishing, with :html-doctype. :group 'org-export-html :version 24.4 :package-version '(Org . 8.0) :type 'i-dont-know-how-to-work-this) #+END_SRC The end result I'm after is: the user can either set org-html-doctype to a symbol from among the cars org-html-doctype-alist, or he/she can set it directly to the doctype string. I don't know how to represent that in a defcustom. And of course, if anyone has any better approaches, then speak now or... speak later. Eric
Re: [O] Attributes on HTML tables?
Eric Abrahamsen e...@ericabrahamsen.net writes:
François Pinard pin...@iro.umontreal.ca writes:
Bastien b...@gnu.org writes:
Eric Abrahamsen e...@ericabrahamsen.net writes:
The first step is probably to research the differences between xhtml and
html 5.
Well, I would even skip this step and just hack something usable.
I sort of fudged on the below. The upside is that it should be pretty
forgiving now: you can set all kinds of strings as your :html-doctype,
and it will do a reasonably good job of guessing how to handle it.
Barring actual bugs or poor design decisions, what's left to do is:
1. Make sure that inlined script and style chunks are escaped correctly,
I seem to remember reading that the commenting/escaping syntax for these
chunks varies according to html flavor.
2. I'd like to add the possibility to put an arbitrary :html-container
attribute on HTML elements, so that things that would have been wrapped
in divs can be wrapped in article, section, nav, and so on and
so forth.
Rick Frankel kindly provided a test file for this, which I've modified
below:
#+BEGIN_SRC emacs-lisp
#+TITLE: HTML 5 Test
#+DATE: {{{modification-time(%Y-%m-%d)}}}
#+HTML_DOCTYPE: html5
#+BIND: org-html-divs ((preamble header preamble) (content section
content) (postamble footer postamble))
* Org HTML5 Test
ok? This should be a paragraph with a \\
line break in it. I think
* How about a table
| col1 | col2 |
|--+--|
| a|1 |
| b|2 |
Tables can't have attributes in HTML5.
* And a list
- a
- b
- c
* And an image
[[file:1356810947473.jpg]]
* A definiton list
#+ATTR_HTML: :options html-container article
- a :: foo
- b :: bar
#+END_SRC
Please break! I'll provide a properly-written patch when we've sorted it out.
E
From 296bbf0f74d0c3d49259e146597a174e7c14fda9 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen e...@ericabrahamsen.net
Date: Sat, 13 Apr 2013 13:22:14 +0800
Subject: [PATCH] First stab at exporting to various flavors of HTML.
---
lisp/ox-html.el | 151 +++-
1 file changed, 96 insertions(+), 55 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 0ad3dc3..af80707 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -142,6 +142,15 @@
(defvar org-html--pre/postamble-class status
CSS class used for pre/postamble)
+(defconst org-html-doctype-alist
+ '((html4 . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\)
+(html4-strict . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\
+\http://www.w3.org/TR/html4/strict.dtd\;)
+(xhtml . !DOCTYPE HTML PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\
+\http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;)
+(html5 . !DOCTYPE HTML))
+ An alist mapping (x)html flavors to specific doctypes.)
+
(defconst org-html-special-string-regexps
'((- . #x00ad;) ; shy
(---\\([^-]\\) . #x2014;\\1) ; mdash
@@ -747,7 +756,9 @@ in all modes you want. Then, use the command
'(:border 2 :cellspacing 0 :cellpadding 6 :rules groups :frame hsides)
Default attributes and values which will be used in table tags.
This is a plist where attributes are symbols, starting with
-colons, and values are strings.
+colons, and values are strings.
+
+When exporting to HTML5, these values will be disregarded.
:group 'org-export-html
:version 24.4
:package-version '(Org . 8.0)
@@ -855,7 +866,9 @@ CSS classes, then this prefix can be very useful.
The extension for exported HTML files.
%s will be replaced with the charset of the exported file.
This may be a string, or an alist with export extensions
-and corresponding declarations.
+and corresponding declarations.
+
+This declaration only applies when exporting to XHTML.
:group 'org-export-html
:type '(choice
(string :tag Single declaration)
@@ -871,15 +884,14 @@ Use utf-8 as the default value.
:package-version '(Org . 8.0)
:type 'coding-system)
-(defcustom org-html-doctype
- !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\ \http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;
+(defcustom org-html-doctype xhtml
Document type definition to use for exported HTML files.
Can be set with the in-buffer HTML_DOCTYPE property or for
publishing, with :html-doctype.
:group 'org-export-html
:version 24.4
:package-version '(Org . 8.0)
- :type 'string)
+ :type 'string)
(defcustom org-html-container-element div
HTML element to use for wrapping top level sections.
@@ -1034,7 +1046,7 @@ precedence over this variable.
'((en p class=\author\Author: %a (%e)/p
p class=\date\Date: %d/p
p class=\creator\%c/p
-p class=\xhtml-validation\%v/p))
+p class=\validation\%v/p))
Alist of languages and format strings for the HTML postamble.
The first element of each list is the language code, as used for
@@ -1059,7 +1071,7 @@ like that: \%%\.
:value-type (string :tag Format string)))
(defcustom org-html-validation-link
- a href=\http://validator.w3.org/check?uri=referer\;Validate XHTML
Re: [O] Attributes on HTML tables?
Nicolas Goaziou writes: Caveat: `org-html-table-tag' is now named `org-html-table-default-attributes' and expect a plist as its value. Also, a nil value will remove the property from the attributes. Could you test it and confirm this is now behaving in a desirable way? Hi, I've run some tests and confirm it works as I'd like it to. Thanks, I really like this and I hope others like the plist syntax as well. Late thought, sorry: If we can have this plist syntax as a general rule, perhaps we should nevertheless keep the :options tag just as a fallback, to ease the transition for users with a lot of legacy attr_html lines? It's easier and less catastrophe-prone to do a quick search/replace from : ^#\+attr_html: to : #+attr_html: :options than it is to automatically replace verbatim attribute code with plists, especially if there are all sorts of html irregularities in there. Yours, Christian PS. Though if everything is nice and conforming to xhtml, one should be able to batch convert files from verbatim html attributes to plist syntax with something like the following -- USE AT OWN RISK, NO WARRANTY IMPLIED: : perl -i.bak -pe 's/([a-z]+)=([\\'])(.*?)\2/:\1 \2/g if /^#\+attr_html/i' *.org
Re: [O] Attributes on HTML tables?
Hello, Christian Moe m...@christianmoe.com writes: Nicolas Goaziou writes: Caveat: `org-html-table-tag' is now named `org-html-table-default-attributes' and expect a plist as its value. Also, a nil value will remove the property from the attributes. Could you test it and confirm this is now behaving in a desirable way? I've run some tests and confirm it works as I'd like it to. Thanks, I really like this and I hope others like the plist syntax as well. Great. Thank you again. Late thought, sorry: If we can have this plist syntax as a general rule, perhaps we should nevertheless keep the :options tag just as a fallback, to ease the transition for users with a lot of legacy attr_html lines? It's easier and less catastrophe-prone to do a quick search/replace from : ^#\+attr_html: to : #+attr_html: :options than it is to automatically replace verbatim attribute code with plists, especially if there are all sorts of html irregularities in there. I prefer not to mix the two methods as it would be fragile (e.g. what happens if an attribute is defined both outside and inside the :options keyword?). PS. Though if everything is nice and conforming to xhtml, one should be able to batch convert files from verbatim html attributes to plist syntax with something like the following -- USE AT OWN RISK, NO WARRANTY IMPLIED: : perl -i.bak -pe 's/([a-z]+)=([\\'])(.*?)\2/:\1 \2/g if /^#\+attr_html/i' *.org Would you mind adding it to Worg section about the migration to Org 8.0? It would be quite useful. Regards, -- Nicolas Goaziou
Re: [O] Attributes on HTML tables?
Nicolas Goaziou writes: I prefer not to mix the two methods as it would be fragile (e.g. what happens if an attribute is defined both outside and inside the :options keyword?). Perhaps not much. As I reported (the reason :options wasn't working), in Firefox the second definition of the attribute is simply quietly ignored. But if you prefer to keep it clean, I'm fine with that. to batch convert files from verbatim html attributes to plist syntax with something like the following -- USE AT OWN RISK, NO WARRANTY IMPLIED: : perl -i.bak -pe 's/([a-z]+)=([\\'])(.*?)\2/:\1 \2/g if /^#\+attr_html/i' *.org Oops, in that message I accidentally copy-pasted a WRONG version. Hopefully didn't work at all, or it would mess things up. Sorry. This seems to work well: : perl -i.bak -pe s/([a-z]+)=(\|')(.*?)\2/:\1 \3/g if /^#\+attr_html/i filename.org Would you mind adding it to Worg section about the migration to Org 8.0? It would be quite useful. Will do. Yours, Christian
Re: [O] Attributes on HTML tables?
Hi, Nicolas Goaziou n.goaz...@gmail.com writes: than it is to automatically replace verbatim attribute code with plists, especially if there are all sorts of html irregularities in there. I prefer not to mix the two methods as it would be fragile (e.g. what happens if an attribute is defined both outside and inside the :options keyword?). Sorry, catching up in this thread -- my understanding was that :options was *always* available as a fallback, even with other attributes set before it. Am I wrong? If an attribute is both outside and inside the :options keywords, the outside version should take over. -- Bastien
Re: [O] Attributes on HTML tables?
Hello, Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: than it is to automatically replace verbatim attribute code with plists, especially if there are all sorts of html irregularities in there. I prefer not to mix the two methods as it would be fragile (e.g. what happens if an attribute is defined both outside and inside the :options keyword?). Sorry, catching up in this thread -- my understanding was that :options was *always* available as a fallback, even with other attributes set before it. Am I wrong? :options is more or less required in LaTeX export. Other keywords may go in different locations (optional arguments, mandatory arguments) so the back-end has to understand the keywords provided. It also means there will always be keywords it won't understand (i.e. which are not hardcoded). The :options bucket is a good place for them. On the other hand, I think we don't need it in HTML export. All attributes go in the same place, so the backend just transforms the plist into a string. Since it doesn't need to know about what it transforms, the bucket becomes useless, maybe confusing. Regards, -- Nicolas Goaziou
Re: [O] Attributes on HTML tables?
François Pinard pin...@iro.umontreal.ca writes: Christian Moe m...@christianmoe.com writes: XHTML is also fussy about quoting attribute values, and about escaping special characters as HTML entities, including the ampersand (), and including inside attribute values. I'm guessing the exporter already does the right thing here. Org can of course take care of XTHML fussiness, there is likely no problem there. While on this subject! :-) Could Org allow the output of HTML5 rather than XHTML, under the control of some option? I've read that some frameworks really expect HTML5 to work properly, such an option might ease inter-operation between exported Org and such frameworks. I'm curious about this possibility as well -- how much work would it be? E
Re: [O] Attributes on HTML tables?
Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: I'm curious about this possibility as well -- how much work would it be? The easiest way to know is to start working on it ;) Try creating a derived back-end from 'html one and see. ox-s5.el and ox-deck.el might be useful to read, they are derived from the 'html back-end already. HTH, PS: Maybe some adjustments could be done later do on ox-html.el so that it's easier to derive new back-ends from it... but we're not there yet. -- Bastien
Re: [O] Attributes on HTML tables?
Bastien b...@gnu.org writes: Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: I'm curious about this possibility as well -- how much work would it be? The easiest way to know is to start working on it ;) I was afraid that was the answer! Try creating a derived back-end from 'html one and see. ox-s5.el and ox-deck.el might be useful to read, they are derived from the 'html back-end already. HTH, PS: Maybe some adjustments could be done later do on ox-html.el so that it's easier to derive new back-ends from it... but we're not there yet. The first step is probably to research the differences between xhtml and html 5. In a perfect world we'd be able to export to html 4, html 5, and whatever flavor of xhtml is still current. Bleagh! E
Re: [O] Attributes on HTML tables?
Christian Moe m...@christianmoe.com writes: XHTML is also fussy about quoting attribute values, and about escaping special characters as HTML entities, including the ampersand (), and including inside attribute values. I'm guessing the exporter already does the right thing here. Org can of course take care of XTHML fussiness, there is likely no problem there. While on this subject! :-) Could Org allow the output of HTML5 rather than XHTML, under the control of some option? I've read that some frameworks really expect HTML5 to work properly, such an option might ease inter-operation between exported Org and such frameworks. François
Re: [O] Attributes on HTML tables?
Hello, Christian Moe m...@christianmoe.com writes: If I understand the question correctly, I think the union is the correct answer, with provided attributes overwriting defaults for the same attributes. In the example we started with, the defaults would create table border=2 cellspacing=0 cellpadding=6 rules=groups frame=hsides If the user specifies #+attr_html: :border 2 :rules all :frame border :title My table I would expect the result table border=2 cellspacing=0 cellpadding=6 rules=all frame=border title=My table Thank you for all the information. I have pushed a patch along these lines. Caveat: `org-html-table-tag' is now named `org-html-table-default-attributes' and expect a plist as its value. Also, a nil value will remove the property from the attributes. Could you test it and confirm this is now behaving in a desirable way? Regards, -- Nicolas Goaziou
Re: [O] Attributes on HTML tables?
Nicolas Goaziou writes: Does every possible attribute follow attribute=value pattern? Aren't there single keywords? In XHTML it does, and there aren't. In HTML you can use some minimized attributes, but in XHTML they have their own names as values, e.g. nowrap=nowrap. If they are that regular, we can indeed walk the plist like a list and change (:key1 val1 :key2 val2 ...) into key1=val1 key2=val2 ...and let the user worry about getting them right. That's my suggestion, FWIW. If there are irregular keywords, the export back-end needs to know about them. XML doesn't do `irregular'. :) XHTML is also fussy about quoting attribute values, and about escaping special characters as HTML entities, including the ampersand (), and including inside attribute values. I'm guessing the exporter already does the right thing here. Since values may legitimately contain double quotes, one thing the back-end *does* need to know about is to put those in single quotes: :title This is a pop-up text title='This is a pop-up text' Also, if attributes are provided, I assume defaults should be ignored altogether. Or do we need to create the union between default values and provided attributes? If I understand the question correctly, I think the union is the correct answer, with provided attributes overwriting defaults for the same attributes. In the example we started with, the defaults would create table border=2 cellspacing=0 cellpadding=6 rules=groups frame=hsides If the user specifies #+attr_html: :border 2 :rules all :frame border :title My table I would expect the result table border=2 cellspacing=0 cellpadding=6 rules=all frame=border title=My table You may want a second opinion on all this -- I'm no (X)HTML guru and I've never written an exporter. But it seems to me the pure plist form would less confusing to the user than a split syntax, and easier to maintain, as well. Yours, Christian
Re: [O] Attributes on HTML tables?
Hi François, François Pinard pin...@iro.umontreal.ca writes: #+CAPTION: This is a table with lines around and between cells #+ATTR_HTML: border=2 rules=all frame=border You need to use :options now: #+CAPTION: This is a table with lines around and between cells #+ATTR_HTML: :options border=2 rules=all frame=border We are in the process of documenting this. -- Bastien
Re: [O] Attributes on HTML tables?
Bastien writes: You need to use :options now: #+CAPTION: This is a table with lines around and between cells #+ATTR_HTML: :options border=2 rules=all frame=border Oddly, this doesn't work for me at the moment. I'm running release_8.0-pre-344-g882454, pulled this morning. (It /could/ be just me; I seem to have some unresolved installation issues.) When I export, both the defaults /and/ the options are applied, resulting in duplicated attributes, like this: table border=2 cellspacing=0 cellpadding=6 rules=groups frame=hsides border=2 rules=all frame=border and on Firefox, at least, the values defined the second time are ignored. The documentation currently up on Worg (http://orgmode.org/worg/org-8.0.html#sec-8-3), which seems to say we should now use plists for HTML attributes. But that currently doesn't work for me either. Sorry if you've heard this before, but this doesn't make sense to me as a new syntax: #+ATTR_HTML: :options attribute=value It's not just more verbose than the old way, it's redundant to say both attr and options, since all it does is set attributes. Yours, Christian
Re: [O] Attributes on HTML tables?
Hello, Christian Moe m...@christianmoe.com writes: Bastien writes: You need to use :options now: #+CAPTION: This is a table with lines around and between cells #+ATTR_HTML: :options border=2 rules=all frame=border Oddly, this doesn't work for me at the moment. I'm running release_8.0-pre-344-g882454, pulled this morning. (It /could/ be just me; I seem to have some unresolved installation issues.) When I export, both the defaults /and/ the options are applied, resulting in duplicated attributes, like this: table border=2 cellspacing=0 cellpadding=6 rules=groups frame=hsides border=2 rules=all frame=border This is a bug. The documentation currently up on Worg (http://orgmode.org/worg/org-8.0.html#sec-8-3), which seems to say we should now use plists for HTML attributes. But that currently doesn't work for me either. Sorry if you've heard this before, but this doesn't make sense to me as a new syntax: #+ATTR_HTML: :options attribute=value It's not just more verbose than the old way, it's redundant to say both attr and options, since all it does is set attributes. Actually, that's not the spirit. The idea is to define some widely used attributes that will be written directly like: #+attr_html: :border 0 :width 400 Then, :options attribute is used as a bucket for every other attribute, since we cannot support all of them. Unfortunately, no attribute is current recognized in table HTML transcoder. It needs to be improved. If Someone provides a list of such attributes, I can implement it. Regards, -- Nicolas Goaziou
Re: [O] Attributes on HTML tables?
Nicolas Goaziou writes: When I export, both the defaults /and/ the options are applied, resulting in duplicated attributes, like this: table border=2 cellspacing=0 cellpadding=6 rules=groups frame=hsides border=2 rules=all frame=border This is a bug. Ah, good (from my perspective, anyway, I was getting concerned about my setup). The idea is to define some widely used attributes that will be written directly like: #+attr_html: :border 0 :width 400 Then, :options attribute is used as a bucket for every other attribute, since we cannot support all of them. I'm sorry, you've probably explained this many times before and I should go read the archives. But what is it that nees to be supported, and why couldn't you just pass through *whatever* :attribute value pair the user puts in attr_html? I really like the switch to plist style, but I think the combination with :options and literal syntax is confusing. Unfortunately, no attribute is current recognized in table HTML transcoder. It needs to be improved. If Someone provides a list of such attributes, I can implement it. I'd be happy to, but I need to understand the above. On what basis should attributes be selected for either plist style or the :options bucket, and what does the exporter need to know about them in order to support them? Yours, Christian
Re: [O] Attributes on HTML tables?
Christian Moe m...@christianmoe.com writes: But what is it that nees to be supported, and why couldn't you just pass through *whatever* :attribute value pair the user puts in attr_html? Does every possible attribute follow attribute=value pattern? Aren't there single keywords? If they are that regular, we can indeed walk the plist like a list and change (:key1 val1 :key2 val2 ...) into key1=val1 key2=val2 If there are irregular keywords, the export back-end needs to know about them. Also, if attributes are provided, I assume defaults should be ignored altogether. Or do we need to create the union between default values and provided attributes? Regards, -- Nicolas Goaziou
