[TYPO3-hci] Kickoff: TYPO3 4.1 (suggestions)

[Tapio Markula]

Christopher kirjoitti:
> Tapio Markula wrote:
>> Robert Markula kirjoitti:
>>
>>> 3. If possible, do away with layout-tables. Ok, accessibility can be 
>>> achieved with layout tables, and pure CSS-based layout tends to bring 
>>> problems with browser-compatibility and needs ugly hacks. 
>>
>> yes - I don't rely on float -property - it might cause unexpected
>>
> 
> 'Ugly hacks' are only very seldom necessary, and 'float' is very stable 
> on all modern browsers. There is only really one major weirdness about 
> IE's implementation of float and that's that it encloses the child 
> elements of floats (it's not supposed to).
> 
> The so-called 'float bugs' in IE are irritating, but they are not only 
> caused by problems with how IE renders floats. A better term for them 
> would be 'haslayout' bugs, and they are very often fixable with one line 
> in an IE-only stylesheet. '#selector { zoom:1; }' often works, for 
> example. The various 'haslayout' bugs in IE are generally quite 
> predictable, and not usually difficult to squash.
> 
> Having said that, there may very well be places in the BE where tables 
> are not technically the best /markup/ (i.e. in the sense of metadata), 
> but may be the best implementation we can come up with in the short 
> term. I'd like to see the layout tables gone, but if it's not practical 
> to get 'em all, we can still zap some of them.
> 
> Another thing to remember is that in the BE we can potentially drop 
> support for particularly troublesome UAs although since the most 
> troublesome one out there is the IE 5-6 family, I guess we're stuck with 
> the worst offenders no matter what we do :-)
> 
> In any case, I would /love/ to see the backend's markup and 
> skinnability/templatability improve. My particular strength is with 
> writing markup and CSS, so I'd like to offer to consult on the BE's 
> markup and styles; what I don't know is how best to achieve that. I 
> could, for example, take sections out of the existing BE and rewrite 
> them in a leaner, more modern way, but I don't know if that process will 
> fit into any concurrent re-coding of the application logic. I suppose 
> introducing templating for the BE is out of the question at this point?
> 
> I guess we'd also need to decide how (if) the in-markup javascript 
> attributes will stay in place. It'd be nice to see both the scripts and 
> the event handlers move into external files, but I have no idea if this 
> is practical or not.
> 
> The point is, I'm willing to write markup and styles for the BE either 
> as standalone sample pages if that would be helpful, or to write markup 
> on-demand for developers working in the BE php/js code.
> 
> Is anybody else interested in trying to update the BE?
> 
> -Christopher

I sold a customer TemplaVoila with better source code.
I didn't do all changes, but made it proper skinnable.
The customer payed me that change. You should ask him,
if he would give it free for development.

I did that earlier for the standard page module
but that is collection of functionalities from several plugins
* my own
* kb_nescefe
* gb_dragndrop

gb_dragndrop is in many respects fine but it has some problems.

Both should have some new classes and they would need deleting some
direct style attributes.