Convert to more semantic HTML5. about dokuwiki HOT 11 OPEN

(A open pull request, that implement some navigations tags in the navigation: #497 )

from dokuwiki.

IMO there's a few too many section elements in your example; the sections with class levelbody should not be there. A section must at least always have a nested header element otherwise it would appear without a header in the document outline.

Getting this right is in html markup is tricky, getting it right in wiki markup is even trickier.

see also http://html5doctor.com/the-section-element/

from dokuwiki.

Ah, yes, that one should probably be a div, not a section; good catch. The updated snippet is below.

The purpose of this ticket is really to see how much interest there is in updating this to more closely align with the HTML 4 or 5 outline models. At a glance it seems like it would be a lot of work and would substantially change existing HTML structure, so I wanted to gauge interest before attempting such a large task; I wouldn't want to go through the work just to have the PR declined.

<section id="s1.0">
  <h1 class="sectionedit1" id="level_1_heading">Level 1 Heading</h1>
  <div class="level1 levelbody">
    <p>Level 1 content</p>
  </div>
  <section id="s1.1">
    <h2 class="sectionedit2" id="level_2_heading">Level 2 Heading</h2>
    <div class="level2 levelbody">
     <p>Level 2 content</p>
    </div>
  </section>
</section>

from dokuwiki.

Generally there's interest. However we tend to be careful with changes to avoid breaking existing templates too much. Tip: several smaller PRs instead of one huge one will make evaluating the changes easier and improves chances for quick merging.

Maybe @selfthinker can chime in with a opinion here?

from dokuwiki.

Maybe I should make Doku_Renderer_html5 and do all the work there? That way people would be able to switch between XHTML and HTML 5. It would lessen the BC impact, definitely.

from dokuwiki.

On further review it seems that inc/parser/handler.php would have to be modified or extended as it is the one who calls header before section_open. What do you think would be the best way to deal with this?

from dokuwiki.

Nesting the section divs in a way to include each section heading was something I requested in the very beginning (back in 2004) and a few years ago again (maybe 2012?). At both points @splitbrain said that's not possible due to the way our parser works. The best person to ask again is probably @Chris--S?

You wrote

this project could majorly benefit from some of the new semantics and elements from HTML5

In what way exactly would we "majorly" benefit?

IMHO, there are three things to consider:

1. DokuWiki should stay doctype-agnostic, i.e. each template should keep deciding which version of HTML it uses. If we added HTML5-specific elements, some templates would "break". If we'd like to add anything like this into the core, I'd suggest to make it configurable (best via template).
2. Although I very much like most aspects of HTML5, I don't see the benefit of many new elements. As far as I understood, e.g. <main> is semantically the very same as <div role="main">, so I don't see the reason of preferring one over the other. Most screenreaders don't support it (yet) and for most browsers there is no visual or behavioural change (yet).
3. Older browsers don't support the new elements, specifically IE8 and below. Potential fixes are all done via JavaScript, so depending on how you'd use the elements, you would potentially always break DokuWiki for some users. As we officially still support IE8, that would be a reason for me to not do it until IE8 users are significantly low.

from dokuwiki.

After some further code reviews I've come to the conclusion that DokuWiki probably needs a render and handler redesign to accommodate this change. This feature alone is not worth the bugs it would likely create. If we have other reasons to redo the renderer and handler portions then perhaps we could undertake the effort.

Also, I wasn't very clear in my original comment: I'd really like a more-strict adherence to the HTML 4 or 5 outline model more than anything; this eases the CSS requirements immensely to get the actual document to format and read like an outline would. I think that HTML5 elements such as time, section, and nav would be nice but not nearly as helpful as nested sections with the headers pushed inside the section.

from dokuwiki.

On 25 Mar 2014, at 19:53, Anika Henke [email protected] wrote:

Nesting the section divs in a way to include each section heading was something I requested in the very beginning (back in 2004) and a few years ago again (maybe 2012?). At both points @splitbrain said that's not possible due to the way our parser works. The best person to ask again is probably @Chris--S?

The header … section organisation is baked into both the handler & section editing.

Its not so much that nested sections aren't possible, but that the changes required are much more involved than just reorganising the html. Imho, there could be some advantages in changing to nested sections but it would be a big-bang set of changes, not something you could introduce gradually.

@HakanS & @michitux might also like to comment, I have a feeling nested sections would make aspects of the include plugin much simpler, but may cause compatibility issues with more than a few current plugins.

With regards an html5 renderer. as a starting point there is no harm in creating an html5 renderer plugin and having installable templates which are dependent on (or prefer) using that renderer.

• Chris

from dokuwiki.

With regards an html5 renderer. as a starting point there is no harm in creating an html5 renderer plugin and having installable templates which are dependent on (or prefer) using that renderer.

If that could also "fix" the section rendering, I'd say that's a very good solution. That way people can choose and no templates or plugins break. If that proves to be successful we could consider adding it to the core after a while or even swapping it completely with the current renderer.

from dokuwiki.

I'm not sure what you mean by "fix" in that context, but since its not changing the handler or section editing, it would be very difficult to have a render plugin implement nested sections.

from dokuwiki.