Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Content Rendering Schemes

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Content Rendering - Team (category ContentRenderingTeam)

The ECT (Extension Coordination Team) and the CRG (Content Rendering Group) are doing a joint effort at the moment to get some new out-of-the-box templates into TYPO3. For this purpose some standard id and class schemes for the HTML output have to be drawn up. That's what's done on this page.


What is this about?

glossary-definition: Content Rendering Schemes (CRS) are a method for standardisation of markup code and classes/IDs for TYPO3 markup.

Content Rendering Schemes should bring together several things :

  • Standard classes for content elements and extension markup
  • different markup code for different occasions (or different taste...)
  • adapting "outer world" ideas like microformats
  • idea of flexible content elements

The Basic Idea

The basic idea of CRS is to have a mechanism for different standard markup and classes for special content (like a data table, a results browser, a calendar entry and so on) - based on existing 'standards' like microformats (http://www.microformats.org/).

There can be different CRS for special purposes like - backwards compatible - strict semantic - maximum stylable - ... - custom

Designers can set a variable to indicate wich CRS they will use. Standard content elements should supply markup for all available CRS. Extension authors can use example markup based on microformats and standard classes to build their templates. Even better, they could call an api to get this markup delivered from the core.

Because there is an opportunity to integrate custom schemes every markup needed is possible.

Benefits

  • no (or less) ideologic discussions about the 'right' markup
  • very flexible for different tasks and future ideas about coding
  • semantic markup as a default
  • easy way to good template code for extension developers
  • higher markup quality on TYPO3 sites
  • skinnable markup (with correspondig CRS)

General thoughts / suggestions

  • general ids/classes should reflect position on page
  • menu ids/classes should try to reflect TS-Objects
  • content ids/classes should reflect content-type they are filled with
  • no underlines, only hyphens in composite class- / id-names
  • lowercase only

Layouts

Within this section we try to provide std ids and classes for multicolumn layouts. As we all know, providing std layouts is a risky business that can often lead to heated discussions or outright flame wars. Classing and id-ing a multicolumn layout is to some degree something everybody does differently, according to one's own preferences and habits. If you find our suggestions below inacceptable for some reason please don't hesitate to tell s your suggestions on the discussion page... All three layouts try to follow the same content rendering scheme but vary in their closeness to pure semantic HTML.

The multicolumn schemes below had the following guidelines in mind:

  • Page segmentation
    • header
    • main
    • footer
  • Content segmentation
    • content-01 + column class
    • content-02 + column class
    • content-03 + column class
  • Functional segmentation (optional)
    • css-signature in the <body> for advanced css-selectors
    • "container" to enclose anything within the body
    • "page" to wrap the whole page with header, main and footer
    • "segment-wrap" if necessary to group one or more segments
    • "floatholder" + "clearfix" for segments that make use of this css functions
    • "clearer" for segment that clears with css


semantic 3 columns, floated

<body id="sitename_id"> <!-- this get's generated by a bodyTagCObject -->

	<div id="header"> ... </div>

	<div id="main">

		  <div id="content-01" class="column"> ... </div>

		  <div id="content-02" class="column"> ... </div>

		  <div id="content-03" class="column"> ... </div>
	</div>

	<div id="footer-wrap">

		<div id="footer"> ... </div>

	</div>

</body>

This lean markup is used in Matthew Levine's "In Search of the Holy Grail" article at ALA. In combination with his easy but very clever usage of CSS this could be a basis for a simple, multicolumn FE output.

advanced 3 columns, floated

<body id="sitename_id"> <!-- this get's generated by a bodyTagCObject -->

	<div id="container">
		
		<div id="header"> ... </div>

		<div id="main">

    			<div id="content-01" class="column"> ... </div> <!-- floated left/right -->

    			<div id="content-wrap"> <!-- floated right/left -->

        			<div id="content-02" class="column"> ... </div> <!-- floated left/right -->

        			<div id="content-03" class="column"> ... </div> <!-- floated right/left -->

    			</div>

		</div>

		<div id="footer"> ... </div>
	</div>
</body>

The original idea comes from Sebastian Schmieg. You may have a look at his tutorial to see how things get floated left/right. Thx to Gregory Remmington for mentioning this layout.

versatile 3 columns, floated

This versatile scheme follows the YAML approach (Yet Another Multicolumn Layout) and includes all possibilities for main and possible subnavis and lots of content columns. It makes clever usage of a <hr> to clear the columns globally - therefore all three columns will always reach the footer.

<body id="sitename_id"> <!-- this get's generated by a bodyTagCObject -->

<div id="container">

	<div id="page" class="floatholder">

    		<div id="header"> ... </div>

    		<div id="hmenu"> ... </div>

    		<div id="main"> <!-- begin of three columns -->

      			<div id="content-01-wrap" class="column"> <!-- left column -->

        			<div id="content-01" class="clearfix"> ... </div>

      			</div>

      			<div id="content-02-wrap" class="column"> <!-- right column -->

        			<div id="content-02" class="clearfix"> ... </div>

      			</div>

     			 <div id="content-03-wrap" class="column"> <!-- middle (main) column -->

        			<div id="content-03" class="clearfix"> ... </div>
        
        			<hr class="clearer" /> <!-- the trick: global CLEAR with (hidden) HR -->

      			</div>

    		</div> <!-- end of three columns -->

    		<div id="footer"> ... </div>

  	</div>
</div>

</body>

This layout is extensively explained at Dirk Jesse's YAML homepage. You can download YAML as a Typo3 Template for free here.

Menus

The scheme for menus generated from TS tries to incorporate three ideas with classes:

  • reflect TS-Objects
  • reflect item states
  • reflect sequence of items

Hierarchy is expressed by nesting level and therefore does'nt need any classes. <a>'s should get no class. If needed, the user can set this with ATagParams anyway. All menus are wrapped in a <div class="hmenu">. This might look a bit superfluous at first but if we define each TSObject that can be generated with TypoScript as a semantic "unit", <div>'s naming the TSObjects begin to make sense. This way any TSObject can be inserted anywhere in the template, keeps it's semantic meaning but at the same time reflects TS usage.

TMENU


<div class="hmenu">

	<ul class="tmenu">

		<li class="first odd act">

			<a>linktext</a>

			<ul class="tmenu">

				<li class="first odd no"><a>linktext</a></li>

				<li class="even cur"><a>linktext</a></li>

				<li class="last odd no"><a>linktext</a></li>
			</ul>	

		</li>

		<li class="even no"><a>linktext</a></li>

		<li class="last odd no"><a>linktext</a></li>

	</ul>
</div>

GMENU

<div class="hmenu">

	<ul class="gmenu">

		<li class="first odd act">

			<a>linktext</a>

			<ul class="gmenu"> ... </ul>	

		</li>

		<li class="even no"><a>linktext</a></li>

		<li class="last odd no"><a>linktext</a></li>

	</ul>
</div>

rootline

<div class="hmenu rootline">

	<ul class="tmenu">

		<li class="first odd no"><a>linktext</a><span class="rootline-divider">divider</span></li>

		<li class="even no"><a>linktext</a><span class="rootline-divider">divider</span></li>

		<li class="last odd cur"><a>linktext</a></li>

	</ul>
</div>

Comments:

This is a good start, but there are definite problems in the preceding markup for TMENU / GMENU:

Superfluous classes

There is never any need in CSS to define the default state of an element with a class or id--especially when the situation is essentially a set of binary opposites. If the intention--as in the markup above--is to style even and odd menu items differently, then consider that even though every menu item must be even or odd, both states are given classes. Surely it would be adequate to provide a class only for exceptions to the default state? This is equally true of the normal 'class="no"' state of menu items. Presumably a menu item that is not either active or current must be normal, and one that is even cannot be odd...

Why are two classes necessary? Using CSS this way just prolongs TYPO3's bad habit of adding classes where none are needed (<p class="bodytext"> ... </p> for example...) If a general rule is needed for how many classes should usually be applied to account for x states or conditions, use (x - 1).

The argument might be made that it's necessary to apply these classes to the items in a menu so that they do not incorrectly inherit the styles applied to list items in general, but this is not true. When needed, descendant selectors can be used to target the list items only in the context of menus.

Superfluous markup

The <div> surrounding the unordered list is entirely unneeded--I can't see any need whatsoever for either the extra markup, or the extra class it provides:

  • The <ul> will always be in some container anyway--in practice, likely a container with an id, allowing for the use of contextual styling with descendant selectors
  • The extra class ('class="hmenu"') adds no useful specificity to the CSS (e.g. if .tmenu always occurs inside an element with the class 'hmenu', there is no difference between using '.hmenu .tmenu' in the CSS and using '.tmenu' The only apparent use for .hmenu is to style the container around the menu; if this is really necessary on a production site, then the developer can add it, but it shouldn't be part of the default rendering).
  • The unordered list is a block-level element just as the div is; it has no inherent styling disadvantages that must be overcome with a block-level wrapper.

Unwarranted Assumptions

It seems as though the markup here is making assumptions about how it should be styled--and this is an all-too-common and frustrating practice in the design of program / CMS output. Default programmatic outputs should be as generic as possible!

Better markup?

The three initial goals can still be met using slightly simpler markup (only TMENU shown):

  • reflect TS-Objects ( can be done without the 'hmenu' div )
  • reflect item states ( can be achieved without .no and .even classes )
  • reflect sequence of items ( can be achieved with .first and .last--though I'm skeptical that even these need to be part of any default set of renderings... )
	<!--
		1. Removed .even class
		2. Removed .no class
		3. Removed <div class="hmenu"> | </div>
	-->

	<ul class="tmenu">

	<li class="first odd act">

		<a>linktext</a>

		<ul class="tmenu">

			<li class="first odd"><a>linktext</a></li>

			<li class="cur"><a>linktext</a></li>

			<li class="last odd"><a>linktext</a></li>

		</ul>	

	</li>

	<li><a>linktext</a></li>

	<li class="last odd"><a>linktext</a></li>

</ul>

Comments on 'better markup'

I cannot see any reason, why it should be necessary to reflect TS-Objects. On a page, you have one or more menues, that might or might not need different styling. You could either number them or find names that reflect the nature of the menu's items, e.g.

  • menu-main
  • menu-sub
  • menu-utilities
  • menu-language
  • menu-breadcrumbs
  • menu-skiplinks

-Uschi

Text

Linear HTML text consists of h1 - h6, p, ul, ol, li, etc. Nothing to do here. What about the header classes from css_styled_content?

Text & Images

Already defined by cron_cssstyledimgtext. Maybe content-rendering group would propose other classnames?

Tables

Forms

Resultlists & Pagebrowsers