Well, I just dropped into the next similar restriction:
GIFBUILDER's maxWidth property is of data type "pixels" instead of "pixels /
stdWrap" (while e.g. GIFBUILDER.backColor on the other hand is "GraphicColor / stdWrap"). I need to restrict the length of a GIFBUILDER image to a dynamic value, and there is no way to do that.
The fact that some of the TS object props allow for stdWrap properties and others do not seems to be absolutely arbitrary and it will pose more and more problems as tiled TemplaVoila designs are a quickly spreading concept.
As an example I have attached a screenshot ...
(Kachelung.png - http://bugs.typo3.org/file_download.php?file_id=1211&type=bug )
...of a TV based Typo3 design that completely abandons the concept of column based design in favour of a tile based approach. TV can handle such concepts quite well meanwhile.
In my example all tiles are based on one universal FCE that allows for a very elegant handling of the tiles. It allows to create tiles with different widths and heights, background colors and background images.
But when you try to put this concept to work in Typo3, TS lets you run into one dead end after the other, because it is often not possible to fill in dynamic size and color attributes for various elements that are needed for these tiles.
In times of column based design this was acceptable, as most of the props (widths, heights, colors,...) needed for GIFBUILDER and other objects in the columns had fixed values. But meanwhile this is changing rapidly, as my example demonstrates.
The bottomline is that I humbly ask why not ALL basic TS data types allow to obtain their values from stdWrap props. This would allow for a lot more flexibility with dynamic designs like the one I attached. It would also make the whole TS syntax more consistend (I currently spend a lot of time in TSref just to find out which props allow for which kind of manipulation - there is just no systematic principle to that).
Regarding how small the change was that Peter had to place to make minW and minH stdWrappable, wouldn't it be a good solution to standardize all of the TS data types to allow to be stdWrapped?!?
Or do I overlook any considerations that would limit this approach (like performance issues)?