[TYPO3-dev] RFC: Change roadmap for 4.5 and 5.0

[Christopher]

On 4/10/06, Michael Scharkow <mscharkow at gmx.net> wrote:
> Christopher wrote:
>
> > I'm honestly bewildered by the claim that it's difficult to switch
> > between xhtml and html in code generation: given that TYPO3, when it
> > outputs markup at all, is not checking for validity or
> > well-formedness, the entire extent of the problem is limited to
> > doctypes, the decision to include--or not--closing tags on 'empty'
> > elements, and differences in attributes (e.g. target and border). If a
> > doctype is set using ' config.doctype = ___ ' then a simple check
> > seems to be all that's needed when outputting closing slashes and
> > attributes. And there are only a few elements where even _this_ would
> > be needed (meta, img, br, base...)
>
> I agree that the problem itself is trivial: You simply check if
> xhtml==true and add a slash, or sth. like that. But if you want this
> feature to be used consistently, you have to abstain from writing any of
> the concerned tags in your views, be it in hardcoded php or some
> template language. Instead, you're forced to write wrappers like
> renderTag('img',$src='foo', $class='bar') which I don't find
> particularly elegant, but some die-hard JAVA users or TS gurus might.

I don't know whether to think a wrapper is elegant or not, but I _do_
think that building an html tag in code every time you want one is an
extremely cumbersome style of coding.

In any case the attributes could be done with a wrapper (there might
be no alternative), but for the tag-closing slashes, presumably you
could simplify things:

echo '<img src="' . $src . '" . $closingTag . '>';

...where $closingTag is the value of some flag (like the TS flag used
to enable / disable the 'border' attribute on images) that can be set
in the BE:

// Assume xhtml if you prefer:
$closingTag = ' /';
// But consider the alternative:
if (xhtml == true) {
  $closingTag = '';
}

A single variable then, could be included into every instance where
and img, meta, base or br is genenerated. I have no real idea if this
could be a performance problem, but since we cache most content
anyway...

> Alternatives would be a) post-processing of output (aargh), b) separate
> templates for HTML and XHMTL (like to different versions of CSC) which
> does not scale very well, c) choosing just one supported HTML version.

(a) is ugly, you're right...
(b) given that this whole discussion is about relatively few elements,
this might not be such a bad idea...I can't quite grasp what you're
thinking of though. Care to elaborate?
(c) is, IMO, just not a good option--espeically given that 1) TYPO3 is
supposed to be capable of outputting non-html (e.g. plaintext, xml,
wml...) content and 2) there is at least the _possibility_ of new
(i.e. non-w3c) varieties of (x)html [1]

> I could not care less about whether to use HTML or XHTML in whatever
> version (unless there are some legal requirements for this, as I vaguely
> remember in Germany's BITV, might be wrong though) as long as we don't
> need to support two incompatible versions.

The problem of supporting multiple versions is _exactly_ the reason
why I think the html needs to come largely or completely _out_ of the
core--or at least be rationalized. We actually have SEVEN current
markup versions now [2], not two--even if you only count xhtml
flavours, there are still THREE variants to contend with...


-Christopher


[1] http://whatwg.org/specs/web-apps/current-work/#html5
[2] http://www.w3.org/QA/2002/04/valid-dtd-list.html