[TYPO3-english] Back-end module "pages" still rendered with tables

["Duch (aka. Grégory Duchesnes)"]

I agree with both of you.

Tables are perfectly valid to render tabulated data, but as states Christopher, so called "experts" can disregard a tool only because of a rumor that it doesn't use divs where it "should" be.

The idea behind my post is not about all that. I'm not trying to please any expert, all i'd like to achieve is to make the BE a little bit more flexible in order to make it look a bit more like the FE with a simple CSS.

It is pretty simple on the paper, all it takes is to replace the table whose class is 'typo3-page-cols' by 4 divs (or more depending on TCA) with float:left and a width of 100%/x and add an id such as id="colPos_x"
This way, it doesn't change anything for most people and if someone wants to render the first column on top of the others (displayed like a header for example) he can using a simple additional CSS.

It is IMHO the most simple way since it doesn't need any fancy javascript.



Duch


Le 26 févr. 2010 à 05:37, Christopher Torgalson a écrit :

> On Thu, Feb 25, 2010 at 8:01 PM, Jigal van Hemert <jigal at xs4all.nl> wrote:
> 
> <snip>
> 
>> What should be avoided is using (nested) tables only for layout
>> purposes: to render a border around an object, etc. But even the
>> language view of a page module (each column representing a language) is
>> a logical candidate for a table.
> 
> 
> If you'll re-read my comments, you'll notice I was very careful to
> direct my comments ONLY at tables used for layout purposes. If you
> feel the need to agree with me at such length, I guess that's ok...
> 
> :-)
> 
> 
>>> It's difficult enough to convince people that the CMS universe
>>> includes products other than Drupal and Wordpress, and this isn't
>>> going to help.
>> 
>> If the selection criterium is "does it use tables or div's in the backend"
>> then I doubt that this person or organisation is ready for using TYPO3.
>> Most clients do not spend money on styling the BE; they do want to spend
>> money to have the features they want and to configure the system in a such a
>> way that it fits their work flow. The BE should be functional and must
>> function correctly in the browser(s) which the client uses.
> 
> 
> I neither said nor implied that any decision-maker would decide to use
> or not to use TYPO3 on the basis of whether or not the BE uses layout
> tables. I said it would make wider adoption of TYPO3 more difficult,
> and I stick by that. Maybe I didn't put it simply enough:
> 
> 1. Many people with development experience regard the use of nested
> tables for layout as obsolete
> 2. Some of those people with development experience are involved in
> decision making re: product selection
> 3. Those people, learning about a product using nested layout tables
> *in newly refactored code* are likely to look *less favourably* on
> TYPO3 (especially since outside of Europe and some local markets such
> as Quebec, TYPO3 is not really very well known or understood in the
> first place [notwithstanding the valuable efforts of the various North
> American TYPO3-proselytizers, typo3apprentice.com gets more traffic
> from Europe than all other regions/countries in the world
> combined...])
> 
> So to summarize: it's possible that: slightly suspect code (nested
> layout tables) + unfamiliar product (TYPO3 in many places) + plausible
> alternatives (Drupal e.g.) = a weaker case for the use of TYPO3. It's
> one factor among many, but I think it could have a negative impact
> quite out of proportion to its actual usefulness or necessity in the
> BE.
> 
> 
> -- 
> Christopher Torgalson
> http://www.typo3apprentice.com/
> _______________________________________________
> TYPO3-english mailing list
> TYPO3-english at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english