[TYPO3-dev] [Fwd: Re: text/img and img elements with css-class?]

[grac]

hi franz

i understand now probably our misunderstandings or, better, different 
starting points of our discussion.

as i said, i use YAML with templavoila.
which means that among a lot of other things that each browser is fed by 
default fontsize values (in curly brackets, of course):
html * = font-size: 100.01%   and   body = font-size: 75.00%  (meaning 
12px)

from there almost everything that follows is calculable in percent.

also the templavoila template divs and columns are only defined in percent.
therefore to put an image element in a div/column i only need to define 
a class with the respective width in percent of the div's width.

which also means that individual browser font-sizes are overwritten 
unless the user change it again.

as i have understood your reply your way is just the opposite?!

YAML is called a top-to-down layout framework.
which means that the developer doesn't have to deal with all the 
nitty-gritty stuff which makes life of a web-worker so fuzzy.

i hope you understand my intervention  now as a demand for easier 
handling of images in typo3.

typo3 is endlessly configurable (which is sometimes way beyound my 
capacities).
but just this special feature (of being able to give an image a 
CSS-class) is not foreseen or not implemented?!
still can't believe it... :-)

stephan




Franz Koch wrote:
> Hi Stephan,
>
>   
>>>>> Besides of that - scaled images just look ugly in the browser - 
>>>>> that's also why it might not be that popular.        
>>>>>           
>>>> this depends of course on the quality of your original pic.
>>>>     
>>>>         
>>> nope - that depends primarly on the scaling capabilities of the 
>>> browser. Most browsers just use "resample" which means to drop some 
>>> pixels - but those images don't get antialiased. FF3 is antialiasing 
>>> now, but I'm not sure about other browsers.
>>>
>>>   
>>>       
>> ... and here comes another question/problem: why not take the message of 
>> Web2.0 (browsers without up-to-date techniques are excluded from the 
>> claim that a website has to look identical on all browsers) serious?
>>
>> and on the other hand focus the attention on the different width of 
>> viewports? 800x600 viewports become very unpopular, 1200x1000 seem to be 
>> a norm, and not very seldom you see nowadays screens with 2000. it's a 
>> similar process to tv screens: everybody wants to have wide screens.
>> so it's only natural to adapt to these changed demands and construct 
>> elastic websites (including the images; all my original images have a 
>> width of 1200px or 1600px, depending on the place where they have to be 
>> in the layout).
>>     
>
> I didn't say that I'm agains scaling layouts - but I don't see a benefit 
> in scaled images based on the font-size. Scaling with percent seems to 
> be more useful for me.
>
> like:
> tt_content.textpic.20 {
> 	maxWidthInText = 50%
> 	defaultWidthInText = 30%
> }
>
> So you limit the size of the image container to certain percent of the 
> with of the content area. Inside your image container the image itself has:
> a) if it's only one image, 100% width
> b) if there are multiple images, 100%/n - ((n-1)*colSpace%)
>
> the only downside of this is, that you can't have consistent column 
> spaces - except you're assuming a default width in pixels and 
> recalculate the percentage width based on a default pixel grid. But that 
> causes a bit more ugly inline-css-markup for colspacing.
>
> The other problem is, that you can't use a percent for hight values - 
> those would need to fallback to em or something. So calculating really 
> flexible images is a not that easy task (but of course not impossible).
>
>
>   
>>>> see also the YAML blog:
>>>> Flexible Layouts vs. Fixe Layouts -- 5:0 - High Resolution Weblog
>>>>    
>>>> http://www.highresolution.info/weblog/entry/flexible_layouts_vs_fixe_layouts_50/ 
>>>>     
>>>>         
>> what do you think about this article?
>>     
>
> It hasn't convinced me. As I said - I'm all for fluid layouts, but 
> defining everything based on the font-size is something I don't see a 
> real benefit. What bothers me mostly is the question - what happens if 
> someone has a font-size of maybe 32 pt (whereas 16 seems to be some kind 
> of default in browsers). If I define the width of the website in em, it 
> probably will fit the screen from 16 to 22pt (depending on the screen) - 
> but with 32pt the visitor would have to scroll in both directions which 
> I don't like and which is by no means different than using the zoom 
> function from the browser. And bringing the argument that IE6 doesn't 
> support "real" scaling can be ignored in the same way in that you said, 
> that in web2.0 a website doesn't have to look like the same on every 
> (outdated) browser ;)
>
> Defining a maxWidth here would also break the layout - so there would 
> again not be any difference to fluid layouts up to a certain point.
>
> What I would like to have is, that up to a certain font-size only the 
> font itself is scaling and after that the whole website should zoom. 
> That's something I thing that it would be nice to have - but I don't see 
> how this would be possible to do. Some JS-tricks maybe?
>
>   
>> and how about the following, famous article?
>>
>> CSS Layouts: The Fixed. The Fluid. The Elastic. - Beast-Blog.com   
>> http://green-beast.com/blog/?p=199
>>     
>
> I'll give it a try ;)
>
>