- 1 Blueprint: CSS-Unification
- 1.1 Target Versions/Milestones
- 1.2 Goals / Motivation
- 1.3 Concept
- 1.3.1 1) Distinguish between CSS classes used for styling, CSS classes for JS selections, and information about a record.
- 1.3.2 2) Use a common namespace for CSS names
- 1.3.3 3) Explain the object, not the functionality or the information that will be attached to it
- 1.3.4 4) Only use CSS classes where applicable
- 1.3.5 5) Use multiple classes to define more concrete implementations
- 1.3.6 6) Use hyphens as seperation between generic CSS classes and their more specific counterparts
- 1.3.7 7) Use data attributes to store information, never use CSS classes for that
- 1.4 Implementation Details
- 1.5 Risks
- 1.6 Issues and reviews
- 1.7 Dependencies upon other Blueprints
- 1.8 External links for clarification of technologies
|Proposal||Provide guidelines for having the same CSS classes for common uses throughout the TYPO3 CMS Backend, and a plan on how to introduce newly namespaced CSS classes|
|Status||Draft, Discussion, Voting Phase, Accepted, Declined, Withdrawn|
|Current Progress||Unknown, Started, Good Progress, Bad Progress, Stalled, Review Needed|
|Topic for Gerrit||CSS|
Started during TYPO3 CMS 6.2+ development
Goals / Motivation
The idea is to unify the HTML output and styling information within the TYPO3 backend. This makes it easy in the future to easily modify the TYPO3 Backend in a clean and straightforward way.
There are certain ground rules that need to be followed by each CSS directive:
1) Distinguish between CSS classes used for styling, CSS classes for JS selections, and information about a record.
- As IDs are only allowed once per page, and with a dynamic page one never knows if an ID is already in use, that's why the TYPO3 Backend prohibits IDs for CSS information.
- Only use CSS classes where needed, rather use proper HTML5 elements to define certain parts of a page (<header> / <footer> and not ) and proper cascading for CSS classes
- IDs and CSS classes need to be distinguishable where they are used, either for JS use, CSS use. Don't combine them in one.
- All CSS classes are written in lowercase, all data attributes as well
2) Use a common namespace for CSS names
- t3- for all styling-related HTML elements
As the TYPO3 Backend incorporates many other frameworks (maybe via extensions), it is clearly defined whether a CSS class is introduced and used by TYPO3 or not.
3) Explain the object, not the functionality or the information that will be attached to it
Example: A default table (that actually displays tabular data)
Example: An information box that shows a warning
4) Only use CSS classes where applicable
5) Use multiple classes to define more concrete implementations
Usually, an HTML element has a base CSS class, then can be defined what additional features / information the HTML element holds.
6) Use hyphens as seperation between generic CSS classes and their more specific counterparts
<form class"t3-form t3-form-filterable">
7) Use data attributes to store information, never use CSS classes for that
<form class"t3-form t3-form-filterable t3js-dataform" data-table="tt_content" data-uid="123">
- It needs to be decided whether to use SASS or LESS in order to have more consistent code.
- Also, a guideline needs to be shown what available classes are there in order to use them properly.
- Currently, the backend CSS is split into structure and visual. As this separation does not make a lot of sense now.
- Define good standards for common use cases (see and identify all screens of the Backend, PDF made by the usability team)
Breaking of Extensions that ship with a backend module that use current CSS classes of the TYPO3 Backend.
Issues and reviews
Dependencies upon other Blueprints