On 2014-03-18 15:41, Rasmus wrote:
Rick Frankel <r...@rickster.com> writes: On 2014-03-17 23:31, Rasmus wrote:
A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline.
So, using this definition, in html5, the wrappers should be =sections= to the same level as the toc heading level specified for the document, and =divs= after.[1] So you want it to be section until h:N? That should be easy. 1. The default should stay the same as it is now -- the string "div" As you prefer. But, after reviewing the spec (see above vis. =section= and =article=), i would submit that a better patch would be to implement [1] above -- remove the defcustom (i only added to support using a different default wrapper element in html5), and use =section= and =div= based on toc level when html5-fancy is true. As far as i can tell from the spec, =article= would almost never be correct for the average org doc. Here's a relevant quote from the spec: OK. That certainly makes it easier. But should it not then be a cons or an alist specifying which container to use when the headline level is above or below h:N and deepening on whether html5-fancy is used?
Not really necessary. It's overly complex with no obvious advantage. I guess the right question to ask is (it may have been mentioned much earlier in the thread) -- what problem does the patch solve?
Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element. So blogs, technical docs and similar? I can see people using Org such things? Or do W3-people thinkg of something different when they say it is "syndicatable"
Yes, a a blog is the prototypical example -- but only the index page, where multiple articles are concatenated into a single page. Most likely, an org document implementing this would have the =article=s (indvidual blog posts) at level 1, and sections below. In the most common use, the =article= would probably be the outer wrapper around the entire body section of the output, and would be set as the "content" wrapper in =org-html-divs=. BTW, the html5 version of =org-html-divs= would be: #+BEGIN_SRC emacs-lisp '((preamble "header" "preamble") (content "article" "content") (postamble "footer" "postamble")) #+END_SRC
I think the best way to implement this would be letting the user specify it with the =HTML_CONTAINER= property already implemented. As this seems very much in keeping with the spec, i will implement this change when i have some time in the next couple of weeks if i don't hear any strong arguments against. I can change my patch to this behavior if you want. Though I think it's pretty strong to hardcode values, as one would might have reasons to change it in say an ox-publish project.
Using =PROPERTIES= on org heading is not really hardcoding. It's the "org-way" of associating things with document sections/headings. To recap, I don't really see a compelling reason to specify a hierarchy of wrappers specific to html5-fancy output. After reviewing the spec, i do see the value in wrapping org document sections in =section= tags per the rules in [1] above (from previous email). rick