Bug #51749
closed
HTML5 fixes for css_styled_content header rendering
0%
Description
Currently there are some issues with the lib.stdheader in HTML5 version:
1) 'hgroup' is depreciated for HTML5. Reason: Non-semantic, each Hx tag should cover a section of information, therefore the use of any double H-tag should be avoided.
2) The date format used doesn't localize well.
English: June 4, 2013
German: Juni 4, 2013 (which is no valid german format)
better use 'strftime = %x', which localizes in any language
(yes, I know that it's possible to override, but the default should be reasonable)
3) The code is bloated without reason. See example code, which saves 100 lines and some microseconds.
Best idea would be to separate HTML5 setup from the regular one. Tags are different, markup is different. Keeping everything in one setup leads to the current chaos.
# Content header:
# This is a html5-only version for Twitter Bootstrap
lib.stdheader >
lib.stdheader = COA
lib.stdheader {
# Determine <Hx> size
1 = LOAD_REGISTER
1.headerType.cObject = TEXT
1.headerType.cObject {
field = header_layout
ifEmpty = {$content.defaultHeaderType}
ifEmpty.override.data = register: defaultHeaderType
}
# This TEXT cObject renders the header content:
# Value is set to the header data, possibly wrapped in link-tags.
# optional subheader is appended to the header/link - if present
# alternate Version for subheader: noTrimWrap = |<br><span class="subheader">|</span>|
10 = TEXT
10 {
field = header
trim = 1
required = 1
htmlSpecialChars = 1
typolink.parameter.field = header_link
append = TEXT
append {
field = subheader
trim = 1
required = 1
htmlSpecialChars = 1
noTrimWrap = | <small>|</small>|
# noTrimWrap = |<br><span class="subheader">|</span>|
}
outerWrap.cObject = COA
outerWrap.cObject {
5 = TEXT
5.noTrimWrap = |<h{register:headerType}| |
5.insertData = 1
# Create class attributes for <Hx> tags
10 = COA
10 {
10 = TEXT
10 {
# Create alignment class for <Hx> tags
field = header_position
required = 1
noTrimWrap = |text-| |
}
# Create "csc-firstHeader" class for <Hx> tags
20 = TEXT
20 {
value = csc-firstHeader
if {
value = 1
equals.data = cObj:parentRecordNumber
}
}
stdWrap {
required = 1
wrap = class="|"
}
}
20 = TEXT
20.value = >|</h{register:headerType}>
20.insertData = 1
}
}
# HTML5 Date
40 = TEXT
40 {
field = date
fieldRequired = date
# June 4, 2013
# strftime = %B %e, %Y This doesn't localize well, the next one does better
strftime = %x
innerWrap.cObject = TEXT
innerWrap.cObject {
field = date
strftime = %Y-%m-%d
wrap = <time datetime="|">
append = |</time>
}
wrap = <p class="csc-header-date">|</p>
}
# Pops the used registers off the stack:
98 = RESTORE_REGISTER
# Post-processing:
stdWrap {
if {
equals.field = header_layout
value = 100
negate = 1
}
fieldRequired = header
dataWrap = <header class="csc-header csc-header-n{cObj:parentRecordNumber}">|</header>
prefixComment = 2 | Header:
editIcons = tt_content : header, [header_layout | header_position], [header_link|date]
editIcons.beforeLastTag = 1
editIcons.iconTitle.data = LLL:EXT:css_styled_content/pi1/locallang.xml:eIcon.header
}
}
Updated by Ernesto Baschny about 11 years ago
- Status changed from New to Accepted
- TYPO3 Version changed from 6.1 to 6.2
Thomas, thanks for thinking about that and sharing!
As of HGROUP: Has been removed already in 6.2 (see #47572).
Patrick (Broens) already had some ideas about a better structure for css_styled_content's output. His approach would be to move more to Fluid, but this was still under discussion.
If we are to provide a replacement template for our default content, we have to keep an eye on the holy cow of "backwards compatibility". It should not break output for upgraders, especially in the 6.2 LTS version.
I can imagine that a new experimental ligthweight HTML5 rendering in the following release.
I agree that the "strftime = %B %e, %Y" for the HTML5 date output is not really helpful. Strange enough the output for the non-HTML5 part is (as you suggested) a %x already (and has been this way for ages). So this tiny improvement is something I would endorse for the 6.2 release. In future try to create individual (smaller) issues for this improvements, it help to prioritize differently different aspects on the same topic.
Please be so kind and help us: http://wiki.typo3.org/CWT
Updated by Patrick Broens about 11 years ago
Hi Thomas,
Ernesto already mentioned the HGROUP has been removed.
When HTML5 was introduced in css_styled_content we had some discussions about splitting up for different doctypes. The whole problem is "backwards compatibility", but also a huge overhead in maintaining these different structures. It's not only about moving the HTML5 part to separate files. If you do so, you also have to take care about XHTML/HTML and other conditions like if a DTD allows frames. It's not easy to split this.
Currently I'm working on a replacement for css_styled_content. The goal is to get rid of most of the TypoScript and use Fluid templates with view helpers. This extension will be based on HTML5 only, because nowadays, and especially in the future, all websites will be build on this specification. A big advantage is you can use your own Fluid templates and view helpers instead of the provided ones (and use another DTD if needed). This does not mean we remove css_styled_content in the near future, it still needs to be around for backwards compatibility. The new extension will be a new and easier way to maintain the output of the content elements of the core. The only downside I see right now is that the performance of Fluid could be worse than with TypoScript, although it currently seems not be the case for all content elements.
I agree with the date format in HTML5. I don't know why I inserted a different format than the format which was already there. Seems to be overlooked in some way. I suggest we make a constant out of this which can be used for both date parts, using '%x' a default. This does not harm if we do it like this.
Updated by Thomas Skierlo about 11 years ago
Hi Ernesto, Hi Patrick,
not touching the holy cow of backward compatibility is a very high goal, and I can understand the reasons for it. On the other hand nearly every major change of TYPO3 within the last 3 years brought braking changes – sometimes even without any real improvement in terms of CMS funtionallity. HTML5 is a breaking change itself. A different set of tags (inluding closing tags), improved semantics and a new level of accessibility – all paired with the next level of css. Keeping this within one file leads to an orgy of time consuming if/CASE constructs (see my example code. It really saved 100 lines).
Backward compatibillity is important when it comes to upgrades. But it is no typical scenario that people move their current website from XHTML to HTML5 during an update. This is nearly impossible because every website uses some custom content which is glued to a certain X/HTML standard. A separation of concerns (“what do you want? Old school XHTML or HTML5”) within setup could lead to two files, that is true. But each of them would be much shorter and more understandable than the current one – and would render in a fracture of time.
When Patrick builds a new (HTML5 only) version based on fluid, he probably had only HTML5 in mind – which I'd call “reasonable thinking”. But this will be an extension, so the default (css_styled_content) must still be working properly.
A couple of weeks ago I've tried to give new life to the totally forsaken core extension “indexed_search” (see #51099, #51113, #51154, #51189). I finally succeeded in using the “experimental” Fluid version. If I measured it right, the rendering process took 6 times longer than the old-school TS setup. I played a lot with Extbase/Fluid during the last years, and, to be honest, I'm still using Fluidtemplate with a huge amount of “lib.something” - just because it really performs.
So. What am I going to do now, in late 2013, if I want TYPO3 to create a “responsive” website suitable for all devices? Switching off the styles from css_styled_content works out of the box with Twitter bootstrap – which is good – but no solution. It still leaves 6 wrapping tags when it comes to the rendering of one single image with a caption. This could and should be reduced to only one. This would break any site where an admin has given a meaning (by own css) to any class currently used. So, if you must be compatible with all the history of css_styled_content, your just cannot reach a goal called “responsiveness”. To get images to be responsive the default styles must be changed heavily (positioning/floats). Each change would break current sites. So TYPO3 is trapped in history – and will never be responsive. See the problem?
In my oppinion the only solution would be a separation of setup. I'm currently working on a Twitter Bootstrap 3 compatible version of csc. I estimate it to save at least 80% of the current lines. But it will be no solution for the official csc, since it will never be compatible with any historic websites.
By the way: The php foundation of csc is excellent. I'm not missing anything. Very visionary design.
Regards,
Thomas
Updated by Mathias Schreiber almost 10 years ago
- Target version set to 7.2 (Frontend)
- Is Regression set to No
Updated by Benni Mack over 9 years ago
- Target version changed from 7.2 (Frontend) to 7.4 (Backend)
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack almost 9 years ago
- Status changed from Accepted to Closed
I think this issue can be closed as we put a lot of efforts into the successor - Fluid Styled Content - which is HTML5 out of the box, and a completely new setup, as requested. If you think this issue should be kept open, let me know.