[TYPO3-content-rendering] New and improved css_styled_imgtext

[JoH]

> CSS in general: I am glad that it turns out to work on most browsers.
> And a bit surprised, to be honest. I tried to "keep it simple", maybe
> that was the reason it works.

A minor bug is that there are things like "width:px;" without any value in
the output.
Maybe there is something missing in your width calculator.

> CSS with MacOS-IE: About MacOS-IE I say "ouuuuuuchhh". Meaning: yeah,
> it sucks. I haven't got PearPC working on my PC yet so I cannot
> install or test with MacOS.

But it is possible to create a crossbrowser output that will work in
MacOs-IE too.
We already did something like that and it worked perfectly fine.
Maybe you have to reconsider the CSS concept.

> Stefan said the "INTEXT left", which can
> only be http://www.typo3-anbieter.de/de/csi/#948, "it actually does
> 2cols". Well, if this is really the case, fine, because 2-cols is
> what I wanted to do there! :) In the content object I selected
> "Columns: 2" in this element.

The problem is that the position of this element is too high.
It covers a part of the element above which might be looking nice in this
case but is not the desired result.
Each element has it's own div container and there should be no part of other
elements overlapping this container.

> The "Just Images", which probably is
> this http://www.typo3-anbieter.de/de/csi/more/#953 I cannot explain
> why the images are in one column.

See -> minor bug
Without any values for the width, the floated elements will be larger than
expected.

> CSS in IE: The calculation of width for the whole images to wrap are
> based on a working box-model, which IE is known not to master in
> "quirks" mode.

You could easily solve that problem like this:
Define the width and/or margins in one box while defining padding and/or
borders in another box that has no value for width.

> Equal-Height: Noone has noticed, but "equalheight" in my extention
> renders different than "equalheight" with the table-based solution.
> The original rendering respects the "columns" chosen by the user. In
> my CSS based solution if you choose "equal height", you get as many
> images as you can in one row, all having equal height.

not sure if this is a good solution. At least there should be a
TypoScript-switch to enable your "modified" behaviour that is set to "off"
as a default value to keep backwards compatibility.

> E.g. FORM, etc. Its a huge amount of core, and if you just want to
> change one line in an extention, you will have to XCLASS the cObj,
> duplicate the whole function in question and change the one line. Not
> very future-proof. I would rather have a whole lot more hooks in
> these classes, but in a form that the user can choose the hook to use
> via TypoScript.

Ever heard of this cute little thingie called stdWrap?
In most of the cases you don't need a hook but a simple stdWrap to acchieve
the desired result.
The problem is that in most extensions stdWrap is not fully implemented but
just wrapping things.
So something like this (which in fact is nothing but a "TypoScript based
hook" )

whatever_feature.postUserFunc = blah

or

whatever_feature.preUserFunc = blah

is not working.
Just be sure to implement stdWrap for every single element of your extension
and you've been providing a perfect hook.

> Integration into CSC: I'm ok with integrating this into CSC as a
> "second step", after the extention has been tested and proved itself
> useful by the community.

Well - it is already very useful but needs at least some bugfixing to be
implemented into CSC.

Keep up the good work and let me know if you need some additional input by
PM and/or skype.

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your knob sometimes!)
Dieter Nuhr, German comedian
openBC: http://www.openbc.com/go/invuid/Jo_Hasenau