[TYPO3] TS: Supply minW/minH with a value from a register

[Joerg Wagner]

Hi Joey,

thanks for your answer and the thoughts you put into this problem.

> Are these widths and heigts completely variable and taken from a text 
> input
> by the user or are they taken from a fixed list of possible values in a
> selectbox?

They are actually taken from a select box, but the heights have to be 
processed (prioriCalced) before being fed into the corresponding tile props 
and partially the widths have to be wrapped too (adding an 'm' to ensure 
proportional scaling). The latter is true for the calculation of tile 
background images, not for GIFBUILDER objects. The first is needed because 
we provide a symbolic vertical tile sizes in the dropdowns (1,2,3,4,5,..10) 
which is then multiplied with a pixel count and an additional spacing value.

> You are completely right with what you say about modern layout techniques,
> but I really don't see, where these rely on stdWrap fatures for the
> GIFBUILDER.
> Even though I have to admit that I would like to see the whole stdWrap
> concept refactored.

You are basically right.
What I try to is is making the concept as intuitive for the editors as 
possible. This includes, that entering a GIFBUILDER text that is too long 
for the given space won't mess up the design by horizontally extending the 
tiles und thus shifting around all other tiles, but will simply crop the 
part of the text that is too long. But you are right - the user has to 
correct that anyway - but a cropped text tells intuitively what has gone 
wrong, an expanded tile and a hereby possibly messed up tile arrangement 
would probably confuse the user and make the true problem less obvious. See 
topic 3. below why I did not use background images that could be cropped 
using CSS width values.

> 1. maxWidth for GIFBUILDER itself forces the size of the image to a 
> maximum
> width but it has no effect on the length of any object inside this
> GIFBUILDER element.

Correct. GIFBUILDERS maxWidth just crops anything that is beyond a given 
maximum image width (which is in my case = tile width). That is exactly what 
I need (as explained above).

> 2. maxWidth for TEXT objects inside a GIFBUILDER reduces the font size 
> until
> the longest line of a text field fits the overall width of the GIFBUILDER
> element.
> In principle this is cool, but this still leaves a lot of problems, since
> the line might be very long and thus reduced to an unreadable font size.

Correct. That's why I do not use this prop. Our headline fonts have to keep 
their defined standard size for reasons of design.

> 3. usually those GIFBUILDER images should be used as background images for
> <hx>-Tags to make them available in a semantically correct way for
> screenreaders and textbrowsers. These elements are sized using CSS
> regardless of the real size of the image that is used as a background.

I have used <hX> tags, but my GIFBUILDER images are enclosed as <img> tags 
between <hX> and </hX>, and not used as background images for the <hX> tag.
You are right, using them as background images would open the possibility to 
nicely crop the image width by CSS settings, but I there is no possibility 
to set any alt and title attributes for background images, and I don't see 
how I could feed in an alternative text (e.g. for screen readers). Maybe I 
am overlooking an ingenious possibility here to put the plain text between 
the <hX> and </hX> and visually hiding it using CSS, but currently I do not 
see such a solution. Please tell me, whether I am overlooking something 
here.

> Since the problem can't be solved without manual modifications by the
> editors in any case IMHO it is no real blocker if maxWidth can't be 
> assigned
> dynamically.

See my reasons explained above why the fact that the editor has to modify 
the text anyway is not the only factor in the game. Presenting the problem 
in a most speaking way to the editor is part of my usability requirements.

Beside that, I am advocating the general availability of stdWrap properties 
for any data type because there will be many other scenarios where you will 
have to insert a value from a register into a prop or where you will want to 
prioriCalc a given value before using it for a prop (like with the now 
solved minW and maxW props I started this thread with).
The examples I provided here are definitely just the tip of the iceberg. I 
found myself in the situation of longing for a nonexisting stdWrap more than 
10 times during the last week - working on the design I posted here.

Thanks again for your consideration!
--
Jörg Wagner
DigiLog multimedia



"JoH" <info at cybercraft.de> schrieb im Newsbeitrag 
news:mailman.1.1142183327.31419.typo3-english at lists.netfielders.de...
>> 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.
>
> Are these widths and heigts completely variable and taken from a text 
> input
> by the user or are they taken from a fixed list of possible values in a
> selectbox?
> I need to know this to think about a possible solution for your problem.
>
>> 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.
>
> You are completely right with what you say about modern layout techniques,
> but I really don't see, where these rely on stdWrap fatures for the
> GIFBUILDER.
> Even though I have to admit that I would like to see the whole stdWrap
> concept refactored.
>
> Example:
> 1. maxWidth for GIFBUILDER itself forces the size of the image to a 
> maximum
> width but it has no effect on the length of any object inside this
> GIFBUILDER element.
> So this won't help to make the lines of a text field fit this maxWidth!
> 2. maxWidth for TEXT objects inside a GIFBUILDER reduces the font size 
> until
> the longest line of a text field fits the overall width of the GIFBUILDER
> element.
> In principle this is cool, but this still leaves a lot of problems, since
> the line might be very long and thus reduced to an unreadable font size.
> 3. usually those GIFBUILDER images should be used as background images for
> <hx>-Tags to make them available in a semantically correct way for
> screenreaders and textbrowsers. These elements are sized using CSS
> regardless of the real size of the image that is used as a background.
>
> Keeping these 3 facts in mind it would not help anyway having a dynamic
> value for maxWidth available (be it for GIFBUILDER or TEXT), since the
> editors would always be responsible for writing a text that fits the size 
> of
> the available header element in a readable way. As far as I can see there 
> is
> only one font size available in your layout, which means that 2 is no 
> option
> here, making things even worse, since the editors would have to do even 
> more
> trial & error work.
> Since the problem can't be solved without manual modifications by the
> editors in any case IMHO it is no real blocker if maxWidth can't be 
> assigned
> dynamically.
> The rest is just a problem of properly setup CSS sizes, but these don't 
> rely
> on stdWrap anyway.
>
> 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.cybercraft.de
>
>