Inserts fuuny  joke about tables here.

I've actually more and more been considering transparent pngs instead  
of tables. I figure. If I call the image. Strictly_valid_css3.png it  
will be fine

heh sorry I thought u could us a little joke this makes me depressed.  
I did something similar with scripting js and 200 lines of code. My  
mockup used a table. And was 12 lines. And was more valid.

I think after 10,000 lines of hacks I'm going to stop pretending that  
many times the fasest and clean, valid code involves a table with CSS.  
I really feel like our whole community has been told that it's evil.  
So we write another 10,000 lines and 12 specific browser sheets  
instead of using the one Valid element support by browsers and  
rendered faster than othe tags. I'm nnot saying my lAyouts will be  
full of tables but I've decide to stop being proud of the fact and  
tellin clients if course it's tableless!!! And instead start telling  
them "he yes I used a table" with css and a table center works.


I guess I'm just all wondering how many hours and years of our lives  
we spent at a computer screen. I know in 20 years the do everything  
with css is going to bother me.  Wasted life and for what? If tables  
fit a situation we should use them. Am I crazy for saying this here? I  
want a revolution! A group of rebels who use tables responsibly,  
Daring to say 200 lines and hours when a situation requires it.

We're all getting to old for this. I'm sorry for this but what do  
other people feel. I was up last night a 4am enjoying the css hacking.  
And then I looked over at my sleeping wife and realized. I could have  
done the hack with a table... It made me think maybe we like the  
challege if that's the case we better hope IE always sucks and web  
standards are allways messy.  Otherwise we might just end up being UI  
artists instead of magic wizards with power.

Happy Mothers day ! Cheers!

Sent from my iPhon

On May 10, 2009, at 8:49 PM, Philippe Wittenbergh <e...@l-c-n.com>  
wrote:

>
> On May 11, 2009, at 11:17 AM, Michael Leibson wrote:
>
>> ...
>> While building two more
>> pages for that site -- www.thinkingmusic.ca/analyses/coltrane,
>> and www.thinkingmusic.ca/analyses (the much smaller page of the
>> two), I’ve begun to implement some of your recommendations.
>>
>> One of these was to allow
>> containers’ heights to be deterimined by their contents, rather t 
>> han
>> by a
>> given, fixed amount.   I’ve now tried to
>> do that, by giving my absolutely positioned divs positions for left,
>> top, and
>> right, but leaving their bottoms as “auto”.
>>
>> To get all containers to
>> ‘conclude’ at the same point, at the bottom of the page, I’ve  
>> given
>> their
>> bottom-most elements the margin-bottom measurements required to do
>> that.  However, I’m getting unexpected results that
>> I don’t understand:
>>
>> 1) Firefox, Safari, Opera
>> and IE each interprets the measurements between successive link-
>> containing ul’s
>> (within the page’s #left div) differently, which means that that  
>> div
>> only
>> concludes at the same point as its neighbouring div in Firefox
>> (within which I
>> designed the page), and no other browser.  Instead of all divs
>> ending at the same place at the bottom of the page,
>> I get a ragged end-of-page.
>
> If it helps, On my Mac, Firefox 3 and 3.5b4, Safari 4b, Opera 10b all
> display a 'ragged end-of-page'. Safari and Firefox display the same,
> in Opera 10 the difference in height is less pronounced.
>
> The total height of those 2 columns will also depend on the line-
> height, and how browsers interpret the 'normal' keyword - you don't
> specify any line-height as far as I a can tell.
> Specifying a line-height will normalise things a little, but you might
> still be at the mercy of differences in rounding of values to the
> nearest pixel between browsers.
>
>
>> 2) In Firefox, zooming all
>> elements gives the #left div greater or lesser height than its
>> neighbouring
>> div, depending on the degree of zoom.
>
> Text zoom or page zoom ?  With page zoom, there is little difference.
> With text-zoom, the columns will on grow based on the text content.
> The margins in your left column will not change the same way, as they
> are specified in pixels.
>
>> Are these differences the
>> result of my own errors, or normal browser behaviour?
>>
>> If the result of browser
>> behaviour, I’d rather just find a way to ensure that all divs
>> conclude at the
>> same point (and leave the minor differences alone), rather than write
>> re-calibrated measurements for each browser.  Is there a way to do
>> this?
>
> Google 'faux columns', or try one of the following techniques:
> http://www.positioniseverything.net/articles/onetruelayout/
> http://www.satzansatz.de/cssd/companions.html
>
> Personally, I'd go with a 'ragged end-of-page' by design :-)
>
>
> PS - the little images in your #left column contain a colour profile.
> This causes a (severe) colour mismatch in browsers that support colour
> management for images (Safari, Firefox 3.5b). The embedded colour
> profile is the one coming from Photoshop when saving for web.
> I use pngcrush to strip it out.
>
> Philippe
> ---
> Philippe Wittenbergh
> http://l-c-n.com/
>
>
>
>
>
> ______________________________________________________________________
> css-discuss [cs...@lists.css-discuss.org]
> http://www.css-discuss.org/mailman/listinfo/css-d
> List wiki/FAQ -- http://css-discuss.incutio.com/
> List policies -- http://css-discuss.org/policies.html
> Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
______________________________________________________________________
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Reply via email to