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

[Franz Koch]

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 ;)

-- 
kind regards,
Franz Koch