Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8
    • Fix Version/s: 2.10.1
    • Component/s: Default template
    • Labels:
      None

      Description

      The current tabbed section markup requires a rather complex markup.

      %%tabbedSection
      %%tab-XXX
      ...
      /%
      %%tab-YYY
      ...
      /%
      /%
      

      This is a proposal to simplify the markup.

      Use a standard header starting with a predefined PREFIX to denote a new tab.

      EG

      %%tabbedSection
      !TAB XXX
      ...
      
      !TAB YYY
      ...
      /%
      

        Activity

        Hide
        Janne Jalkanen added a comment -

        I'm not sure whether we want to change the markup at all, as it will break existing installations. Does it have any other advantages?

        Show
        Janne Jalkanen added a comment - I'm not sure whether we want to change the markup at all, as it will break existing installations. Does it have any other advantages?
        Hide
        Janne Jalkanen added a comment -

        Took of 3.0 fix version, as I think this needs abit more discussion before roadmapping.

        Show
        Janne Jalkanen added a comment - Took of 3.0 fix version, as I think this needs abit more discussion before roadmapping.
        Hide
        brushed added a comment -

        The main advantage is that page-tabs get promoted to become page sections.

        • TABs would automatically appear in a Table Of Contents
        • Section-Editing would be more natural allowing to edit a page tab.

        More:
        The current tabbed-Sections are dynamic styles. This means they are considered to be nothing more the visual sugar (GUI level only) This also means the pages can perfectly be accessed and read without rendering the tabbed-sections – only a screen-based experience would be different; the semantics of the page do not change. (BTW, we make already use of the concept – when printing a page, all tabs will be printed sequentially – you can't click on the tabs when reading a paper version

        With the proposal to simplify the markup, the notion of dynamic style still remains: the rendering of Tabs is only visual sugar, not semantics.

        However, a TAB is now being considered as a (semantic) section, always preceded by a !!!head. While today, you could put a start and end of a Tab anywhere in the page content, this would now be limited to a section head. IMHO, this is a more natural behaviour.

        Show
        brushed added a comment - The main advantage is that page-tabs get promoted to become page sections. TABs would automatically appear in a Table Of Contents Section-Editing would be more natural allowing to edit a page tab. More: The current tabbed-Sections are dynamic styles. This means they are considered to be nothing more the visual sugar (GUI level only) This also means the pages can perfectly be accessed and read without rendering the tabbed-sections – only a screen-based experience would be different; the semantics of the page do not change. (BTW, we make already use of the concept – when printing a page, all tabs will be printed sequentially – you can't click on the tabs when reading a paper version With the proposal to simplify the markup, the notion of dynamic style still remains: the rendering of Tabs is only visual sugar, not semantics. However, a TAB is now being considered as a (semantic) section, always preceded by a !!!head. While today, you could put a start and end of a Tab anywhere in the page content, this would now be limited to a section head. IMHO, this is a more natural behaviour.
        Hide
        Janne Jalkanen added a comment -

        But the TOC will look ugly with the "!TAB xxx" approach.

        Another possibility would be to add a new element into the markup. For example,

        &&tabbedSection
        &&section This is the first title
        
        ...
        
        &&section whatever
        

        By making them first-class citizens we could use those then for quite a few different solutions.

        Another possiblity might be to enhance the %% -syntax to support better arguments, for example

        %%tabbedSection
        %%tab Tab Name
        %/
        
        Show
        Janne Jalkanen added a comment - But the TOC will look ugly with the "!TAB xxx" approach. Another possibility would be to add a new element into the markup. For example, &&tabbedSection &&section This is the first title ... &&section whatever By making them first-class citizens we could use those then for quite a few different solutions. Another possiblity might be to enhance the %% -syntax to support better arguments, for example %%tabbedSection %%tab Tab Name %/
        Hide
        brushed added a comment -

        I agree that the "!TAB xxx" looks like an ugly hack.

        Let's keep the %%tabbedSection ... /% unchanged: the semantics are fine, as it just indicates another kind of rendering of the enclosed page content.

        However, what is needed is a way to indicate that some of the !!!Section-headers are 'special'. They should be treated as tabs (tabbed-section), clickable toggles (various accordion styles) etc.

        It actually would be sufficient to indicate a css-class to be attached to a !!!Section-header. The css-class would indicate that this section is a tab.
        This approach would also allow to give specific styles to certain !!!Section-headers.

         
        %%tabbedSection
        
        !!!%%tab First tab title
        
        ! Some embedded section
        
        !!!%%tab Second tab title
        
        /%
        

        This would render as:

         
        <div class="tabbedSection">
        
        <h2 class="tab"> First tab title</h2>
        
        <h4> Some embedded section</h4>
        
        <h2 class="tab"> Second tab title</h2>
        
        </div>
        

        I think the markup looks a bit bloated - but it is logical.

        One more thing ....

        This could become a generic markup extension.
        When you add %% immediately after any other wiki-markup, it would insert css style info into the generated html.
        EG: added style info to table cells, definition lists, ...

        Also following style could be supported:

        !!!%%(<css-style for this header>) Header title 
        

        dirk

        Show
        brushed added a comment - I agree that the "!TAB xxx" looks like an ugly hack. Let's keep the %%tabbedSection ... /% unchanged: the semantics are fine, as it just indicates another kind of rendering of the enclosed page content. However, what is needed is a way to indicate that some of the !!!Section-headers are 'special'. They should be treated as tabs (tabbed-section), clickable toggles (various accordion styles) etc. It actually would be sufficient to indicate a css-class to be attached to a !!!Section-header. The css-class would indicate that this section is a tab. This approach would also allow to give specific styles to certain !!!Section-headers. %%tabbedSection !!!%%tab First tab title ! Some embedded section !!!%%tab Second tab title /% This would render as: <div class="tabbedSection"> <h2 class="tab"> First tab title</h2> <h4> Some embedded section</h4> <h2 class="tab"> Second tab title</h2> </div> I think the markup looks a bit bloated - but it is logical. One more thing .... This could become a generic markup extension. When you add %% immediately after any other wiki-markup, it would insert css style info into the generated html. EG: added style info to table cells, definition lists, ... Also following style could be supported: !!!%%(<css-style for this header>) Header title dirk
        Hide
        brushed added a comment -

        A simplified markup for tabbed-sections has been added to the HADDOCK Template.
        (since 2.10.1.svn.5)
        Instead of putting each tab inside a %%tab-<some title> .. /% container, you can just use regular header lines (!, !!, !!!) to start a new tab. The level of the first encountered header (! or !! or !!!) will be used to match all subsequent tabs.

        %%tabs
        !First tab
        ..
        !Second tab
        ..
        /%
        

        Pros:

        • simplified markup
        • less error-prone to close each and every tab with a /%
        • this markup is also usable for %%pills, %%accordion, %%leftAccordion, %%rightAccordion, %%tabbedAccordion
          Cons:
        • each tab becomes a first class page header. This implies it will appear as part of the Table Of Contents of the page.

        The old %%tabbed-section markup remains supported, in case you would need tabs which should not appear in the TOC.

        Show
        brushed added a comment - A simplified markup for tabbed-sections has been added to the HADDOCK Template. (since 2.10.1.svn.5) Instead of putting each tab inside a %%tab-<some title> .. /% container, you can just use regular header lines (!, !!, !!!) to start a new tab. The level of the first encountered header (! or !! or !!!) will be used to match all subsequent tabs. %%tabs !First tab .. !Second tab .. /% Pros: simplified markup less error-prone to close each and every tab with a /% this markup is also usable for %%pills, %%accordion, %%leftAccordion, %%rightAccordion, %%tabbedAccordion Cons: each tab becomes a first class page header. This implies it will appear as part of the Table Of Contents of the page. The old %%tabbed-section markup remains supported, in case you would need tabs which should not appear in the TOC.
        Hide
        brushed added a comment -

        Ref. HADDOCK Template, v2.10.1.svn.5.
        Simplified markup is available for %%tabs, %%pills, %%tabbedAcoordion, %%accordion, %%leftAccordion, %%rightAccordion.

        Show
        brushed added a comment - Ref. HADDOCK Template, v2.10.1.svn.5. Simplified markup is available for %%tabs, %%pills, %%tabbedAcoordion, %%accordion, %%leftAccordion, %%rightAccordion.

          People

          • Assignee:
            brushed
            Reporter:
            brushed
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development