Rule #1: Avoid floats unless absolutely necessary Rule #2: Avoid nested floats...period Rule #3: Side bars get position absolute and have width specified in ems Rule #4: Main content area is given margins (or padding, depending on your needs) equal to the widths of the left and right content (in ems) Rule #5: Make sure the content area is lower (z-index) than the sideboxes Rule #6: Write for Mozilla/Opera/Safari first and port to IE later Rule #7: Use IE7 to help port to IE instead of raw CSS hacks
I've used meyerwebs seashell idea to create a beautiful CSS site for a recent client only to find it broke in either IE6 or IE5.5 depending on which hack I used. After spending an few hours trying to get the design to function I made a hybrid tables/CSS design which took less time in total than trying to fix up the CSS hacks for IE. Maybe I'm just bitter.
I still feel that it takes a lot of extra time to get a CSS layout working properly in moz and IE and time is money.
Okay, fair enough. 102 nuclear reactors (104 licensed, but 2 are cuurently down) provide 21% of all US electricity. That's it. Little more than two per state provides 21% of all electricity to the grid.
Speaking of which, could you please explain to me how Enron would benefit from elevated nuclear power output numbers? Or were you just referring to the general concept of funny numbers?
As for taxpayer "discounts," please cite your sources. I figure it's only fair since you asked me to cite mine.
FYI: When I say "nuclear accidents," I mean "nuclear power station accidents." The Freedom of Information Act applies to civilian power stations and any associated threats to public safety. Save the conspiracy theories for someone else.
To produce enough electricity to power the United States, you would need a little more than the area of Connecticut and Delaware in solar panels (Solar advocate stats, not mine). Only a handful of states could sustain themselves on wind. And if you think one state making most of the power for another is a good idea, I have one word for you: Enron. Hydroelectric never gave anyone thyroid cancer, but it has caused no end of ecological disruption in exchange for insufficient amounts of electricity. Tidal is a bad idea due to the fact that >95% of all life on this planet lives at a coastline; Getting energy from the tides means taking energy from those ecosystems.
Let's take California. Look at the number of hydroelectric. Look at the number of wind. How many nuclear? Hard to tell on that map. Just two. Two. Two nuclear plants supply about 20% of all electricity to the state. Two nuclear plants have had less impact on the environment than all other forms of mass electricity production in the state.
And for the record, it is possible to reduce waste dramatically. This can be done with breeder-burner reactors. My personal favorites are IFR/AFR designs. Breeder-burners process the long-lived waste into shorter-lived isotopes while producing electricity.
Now then, on to your other points one by one:
The residents of Nevada are protesting the inturment of the nations nuclear waste in their backyard.
No, not all residents. There are many who aren't in opposition to the internment of the waste.
Questions for you: Do you believe that the current storage pools are safer than Yucca Mountain? Do you have an answer for the existing waste that doesn't involve Yucca? If a method could be found to greatly reduce the volume and threat of existing nuclear waste, wouldn't you be in favor of it?
Breeder-burners can use the spent fuel currently sitting idle in storage pools as well as weapons material that awaits decommissioning. I am against using Yucca for long-term storage but not for the same reasons as you I think. I think Yucca should be a short-term waystation to get the material out of storage pools until breeder-burners are online. My personal favorite is the IRF/AFR model.
And there's tons of this stuff which is going to be criss-crossing the nation via rail, and truck, terrorist opportunities abound.
And how many accidents have there been? In France where the vast majority of the electricity comes from nuclear power, how many terrorist attacks have succeeded against the rail and trucks that have criss-crossed that nation for decades? What terrorist opportunities? Please enumerate them.
You mentioned hydroelectric. Look back at that energy map of California. What do you think would happen if terrorists attacked those dams, flooding the valleys in front of them, drowning the residents, and washing away homes, businesses, and communities? Or did you think hydroelectric was warm and fuzzy since you can't get thyroid cancer from it?
Nuclear may be safe? But with a loose definition of safe.
Yes, it's a loose definition. That's what large-scale electricity generation entails. No form, not green, not nuclear, not fossil fuel-based is 100% safe when producing large amounts of energy on a municipal level.
And it will never be as safe as the green alternatives.
You're right. It's hard to be safer than an alternative that can't run at the same capacity. 104 nuclear facilities are licensed in the US -- many of them share a physical location. Only 102 of them are actually running. 20% of all US electricity comes from nuclear. How many nuclear accidents have occurred in US history? Now look at the number of injuries and fatalities both of workers and people in
Supposedly it's through CSS and counters. The browsers (except Opera) don't support it though. I take your point though. I guess I never noticed because I never use the feature. Good point.
Hmmm... I have a vision of a script that dynamically converts CSS counter declarations to deprecated markup attributes (which still work in the browsers). Page validates, but ultimately does the right thing. Time. I need more free time!
Yes, but not only was IE Mac v5 more standards-compliant than IE Win 5.x, but its usage is rapidly being superceded by Safari. In both cases, CSS hacks are manageable.
I know what you mean though. IE Mac has caused me quite a few headaches, but they are manageable. The real issue for me is that I make dynamic web sites (data from a database). Changing the markup is a lot harder than changing the CSS. Using CSS hacks doesn't bother me anywhere near as much as using markup or back-end logic hacks. CSS is a separate file. It's a technology end-point. Unlike HTML or server-side logic, there's nothing downstream of CSS. It can safely be considered throw away code. If I have to rewrite CSS because the current state of browsers changes, no big loss. If I have to substantially change the markup, pain ensues because a change in one page view doesn't necessarily mean I remember that another page view has the same problem.
But then again, that's my experience. CSS takes practice, just like tables hacks did eight years ago. At this point, I strongly believe that I can make any layout that's possible with tables and make them with clean, semantic markup and CSS....and I can make it work for >90% of all browsers. For the rest of the browsers, I can simply omit the stylesheet. Netscape 4 gets a plain but readable page, but that's it: graceful degradation. Then again, I test my pages in lynx and links. I code for accessibility and 508 guidelines. I'd test text readers for the blind if I had access to a free one.
After going to CSS, using tables for layout is painful to me. It's the kind of thing that's difficult to explain to folks who haven't abandoned tables yet. It's similar to the feeling some Photoshop artist had when layers were introduced. It was hard to explain and doubly hard to explain why it was such a good idea especially to people who had honed their graphics skills without them. Once you use them for a while though, going without is basically unthinkable.
Which CSS Zen Garden designs are you referring to? I was under the impression that IE compatibility was a requirement.
In addition, there are things that you can use to make IE act like a standards-compliant browser...or at least close enough to make complex layouts a lot easier. One of them that I like is IE7.
What exactly are you looking for in a multi-column layout? Most of the time, I want the side boxes to remain a fixed width while just the content area grows. Otherwise, percentages can work to enforce proportions.
Note: a fixed width does not necessarily have to mean pixels. More often than not, I use "ems" as they allow a layout to stretch as needed to account for varying font sizes both by me and by the remote client browser. Perhaps this can help with your multi-column layout woes.
It doesn't prohibit table layouts. No technology can prohibit misuses. Tables in HTML were never intended for layout. They just ended up being the only way to do certain things at the time. However they were and are a hack.
Using (X)HTML as a semantic markup with a separate styling specification is the attempt at cleaning up these hacks. Table elements are still there, but intended for their original purpose: tabular data not cut up graphics and info boxes.
Yes, people who use WYSIWYG tools don't know the difference. That doesn't mean that those of us who do know the difference should turn a blind eye. We know better. That is the competitive advantage. It'd be a shame to squander it.
You're using a threading web server with PHP, a scripting environment whose underlying libraries are NOT threadsafe, and you are running into random problems.
What a coincidence!
Did you try the prefork MPM or did you just assume Apache was to blame?
Yes, most of them are fixed width -- just like most of the table-based layouts on the web are also fixed width. This is a design choice, not a technical constraint. CSS can do the standard three column layout on all browsers through a variety of methods.
No, it's not the only layout on CSS Zen Garden that does. In fact my favorite, Bonsai Sky is quite flexible in addition to being visually stunning.
Then again, I think that quite a few of the fixed width layouts are great too. So they don't scale out to 1000px wide. In my opinion, some of them don't have to; It doesn't detract from the experience.
But the moral to the story is that every layout on that site is the exact same XHTML markup. The exact same. Only the CSS stylesheet changes. Can your table-based layouts do that when your company decides the web site needs a facelift, or are you hacking and slashing your logic, scripting, and markup to get it done?
Yes, and when you drop slashdot down below a certain threshold, it condenses the content to an unreadable width and puts in an unsightly scrollbar. C'mon. Give me a break. Graceful degradation doesn't mean "expect a desktop browser to view a page at 200px wide." Just about every Windows computer since 1998 has used at least 800x600. Most are much larger. Have you heard? They make 17" monitors now too.
And what about WebTV and cell phones and text browsers, etc. etc. etc.? Where's your table layout? Do your table-based pages scale to under 600 pixels wide gracefully? What about phones that can only show four lines at a time? How well can you navigate your page with lynx? What about printable versions? What do you do with your table-based layouts then? Make whole separate pages? With CSS, it's just another stylesheet. No need for substantial rewrites of logic that made your XHTML for each view nor for site graphic redesigns.
The point of CSS is that you can make a different stylesheet tailored to each client. You'll note that on CSS Zen Garden, all of the different examples are the exact same markup underneath. EXACTLY THE SAME. Some of them even resize below 700 pixels wide. Wow! It's like they separated the content from the layout.
Also check out Mezzoblue, made by the same guy who started the CSS Zen Garden. Go ahead, resize it down below 700 pixels wide. Hmmm... Still looks okay.
And with regard to the DOM, I misunderstood before. I see what is meant now. And... well... DOM affects the default order and layering of things. Even that's not set in stone if you set the position and/or z-index.
Take a look at the rest of the designs on CSS Zen Garden. Look at the sites linked from Mezzoblue. Check out Meyerweb. Welcome to the 21st century. We're waiting on you.
No, these days the common set is HTML 4, CSS 1, and about half of CSS 2 being safe to use.
Also, let's be honest: people say "IE" like it's one browser. IE 6, IE 5.5, IE 5, IE 4, IE 4 for the Mac, IE 5 for the Mac, IE 5.1 for the Mac, and IE 5.2 for the Mac all rendered slightly (and sometimes not so slightly) differently.
Even IE-only sites have had to contend with graceful degradation. Personally, I'm positively ecstatic over standards support today as compared to just three years ago.
HTML 3.2 and tables are dying. The CSS support to avoid their use is available today. Let them die.
Who's to say this new XHTML won't be spoiled the same way? We could say "Use HTML if precise control over layout is needed" but back in the HTML days, we were saying "use PDF if precise control is needed" and we were ignored, and HTML was destroyed so badly that XHTML is now needed to fill the role HTML had to abandon.
Making PDFs required more than a tutorial and a text editor back in HTML days. As for presentational issues, as long as the presentational hacks show up in the CSS and not the markup/content, I'll be satisfied. For this point alone, I am grateful for CSS as a separate language.
PDF on the web also failed because, contrary to popular belief at the time, the requirements for viewing documents on the web was not the same as print publishing. RBG vs. CMYK was the least of worries.
IE 5.5 is workable though. It definitely has some hefty warts, but it's serviceable. IE 5.0 and below contain some show-stoppers. Luckily 5.0 and below have dropped below the 10% level, and they will continue to fall.
If more people drop direct support for them, more web pages will break for these people, and sooner or later they will upgrade or someone else will upgrade for them.
Also note that users of IE4 and IE 5.0 (and 5.5) obviously aren't using Windows Update. Honestly, I say "fuck 'em!" These are the people that have been taken over by worms, are partly responsible for a good portion of the viruses that end up in my inbox everyday, and probably have some much of their bandwidth taken up by those worms/viruses that the web isn't enjoyable for them anymore anyway.
Honestly. Less than ten percent. Worm food. Fuck 'em.
Three words: CSS Zen Garden. Or do you consider those "real basic layouts"?...and they work in IE.
The only reason you think tables are easier is because you already know how to make layouts with tables (and have learned the necessary cross-browser hacks), but you haven't learned CSS to the same extent.
CSS can do anything a table-based layout can do AND can do a few things that tables cannot. And please don't bring in comparisons or DOM/CSS to HTML. The DOM has nothing to do with it unless you're scripting. If you're scripting, then yes, DOM/CSS is worlds better than document.write()/HTML.
Oh yeah... Dreamweaver does XHTML now. So I guess that makes your entire post wrong. A shame that.
As opposed to the divine elegance of nested tables and font tags? Please.
By the way, if you don't like inline CSS, don't inline it. Make it a separate stylesheet file or at least put all declarations in the style element in the document head. Inline CSS is just an indicator of a web coder who's not yet ready to give up on font tags. Let them go!
And you forgot history. Those of us who started writing HTML back in the early days were already technically saavy. The ones who had a real problem with writing HTML didn't really start until WYSIWYGs like Frontpage hit the scene. Today, the number of people who know HTML versus knowing Dreamweaver is quite small. If the tools switched to XHTML, I doubt most users would see the difference, and any standards-based rendering bugs would be indistiguishable from all the other rendering bugs that crop up.
As for simplicity, XHTML (strict) has fewer tags than HTML. In addition, fixing one page with CSS is easier than fixing the equivalent using tables, font, and bold tags. For a multi-page site, it's no contest: CSS wins hands down.
And as for "something that anyone can easily learn and use," nowhere in the HTML spec did it ever say that title tags could go inside the body tag or any of the other inane combinations of incorrectly embedded tags in common usage. (I've seen it happen on more than a few pages.) That isn't HTML. That's a series of hacks on top of hacks that have made development for the web a living hell sometimes for the last ten years.
Want to make something easy? Standardize it so that all browsers have a clear target, document it thoroughly, and make easy-to-understand, step-by-step tutorials and other training materials.
You sound like a youngster to me. Table tags did not work consistently. We, the folks who started making web pages before Internet Explorer 1.0, remember when the table tag was introduced. We remember how default rules for cell padding and spacing were different. And how worked for one browser and not the other. And how tags could be used to stretch table layouts with one browser, but not the other. Yep. Good times. Good times.
And we remember how page margins were not only different, but used completely different body attributes (leftmargin/topmargin vs. marginheight/marginwidth).
CSS on the other hand has its rendering behavior largely set in stone. Perfectly? No, of course not. There has never been a software spec that was perfect. But 95% of the CSS spec is damn clear on how things should render. If a browser renders different from a reference image, the CSS renderer is wrong. This is in striking contrast to the good old days of Netscape versus Microsoft when rendering tables correctly was simply a matter of discovering where the layout bugs cancelled each other out.
As for WebTV, some great things about CSS is (a) graceful degradation and (b) alternate stylesheets depending on the client.
I'll take W3C ideology over your ideology any day.
First off, Apache 2 is stable. PHP -- the underlying libraries, but much the same from a user point of view -- on Apache 2 is not stable. That was another pet peave about the PHP page warning not to use Apache 2 in a production environment. The implication to someone who doesn't know the underlying architecture differences is that Apache 2 is faulty. It is not.
The major feature that draws people to Apache2 is threading. On Windows where most basic libraries are, and must be, threadsafe, Apache2 does actually make sense and it would be good to work out the kinks on that platform.
Has Windows only recently starting relying upon threads? No. Are 3rd party libraries on Windows threadsafe? Pretty much. Do the PHP developers recommend its use with Apache 2 on Windows? No. I recognize that Rasmus has mentioned this, but again Apache 2 has been out for two years, Windows has been out for much longer, and still PHP is "a production environment neither on Unix nor on Windows." They don't say why. No one puts this explanation on PHP's Apache 2 install page.
Why doesn't mod_perl have this dire Apache 2 warning? Doesn't it use the same system libraries on Linux? What do the Perl folks know that the PHP folks don't? Is Perl any less a "glue language" than PHP?
But rather than actually deal with the problem, they avoid it. I say the web page should state clearly that PHP may have problems with non-threadsafe libraries, and if you use Apache2 with mod_php4, support may be limited to documenting your hardware and software configuration. What does this accomplish? You get a better idea of what kills a setup, and you get more info (most important!) about what the underlying problem is.
Someone wake me when Apache 2.0 support stabilizes for production use. Yes, that includes the database drivers and other support libraries. It's been two years since Apache 2.0 went stable. I mean c'mon.
No first person shooting. No Viet-cong. No Desert Eagle. Just a big gun, an angle, a force, and if you're good enough, a hit.
I like to think of it as a wine that's had sufficient time to age. Doubtless, the younger ones will not appreciate this fine wine in favor of a brand new Mickey's "fine malt liquor." Still, I like it.
Slashdot Mirror
Here's how I do it:
Rule #1: Avoid floats unless absolutely necessary
Rule #2: Avoid nested floats...period
Rule #3: Side bars get position absolute and have width specified in ems
Rule #4: Main content area is given margins (or padding, depending on your needs) equal to the widths of the left and right content (in ems)
Rule #5: Make sure the content area is lower (z-index) than the sideboxes
Rule #6: Write for Mozilla/Opera/Safari first and port to IE later
Rule #7: Use IE7 to help port to IE instead of raw CSS hacks
Works for me.
Okay, fair enough. 102 nuclear reactors (104 licensed, but 2 are cuurently down) provide 21% of all US electricity. That's it. Little more than two per state provides 21% of all electricity to the grid.
No, these aren't Enron numbers.
Speaking of which, could you please explain to me how Enron would benefit from elevated nuclear power output numbers? Or were you just referring to the general concept of funny numbers?
As for taxpayer "discounts," please cite your sources. I figure it's only fair since you asked me to cite mine.
FYI: When I say "nuclear accidents," I mean "nuclear power station accidents." The Freedom of Information Act applies to civilian power stations and any associated threats to public safety. Save the conspiracy theories for someone else.
Let's take California. Look at the number of hydroelectric. Look at the number of wind. How many nuclear? Hard to tell on that map. Just two. Two. Two nuclear plants supply about 20% of all electricity to the state. Two nuclear plants have had less impact on the environment than all other forms of mass electricity production in the state.
And for the record, it is possible to reduce waste dramatically. This can be done with breeder-burner reactors. My personal favorites are IFR/AFR designs. Breeder-burners process the long-lived waste into shorter-lived isotopes while producing electricity.
Now then, on to your other points one by one:
No, not all residents. There are many who aren't in opposition to the internment of the waste.
Questions for you: Do you believe that the current storage pools are safer than Yucca Mountain? Do you have an answer for the existing waste that doesn't involve Yucca? If a method could be found to greatly reduce the volume and threat of existing nuclear waste, wouldn't you be in favor of it?
Breeder-burners can use the spent fuel currently sitting idle in storage pools as well as weapons material that awaits decommissioning. I am against using Yucca for long-term storage but not for the same reasons as you I think. I think Yucca should be a short-term waystation to get the material out of storage pools until breeder-burners are online. My personal favorite is the IRF/AFR model.
And how many accidents have there been? In France where the vast majority of the electricity comes from nuclear power, how many terrorist attacks have succeeded against the rail and trucks that have criss-crossed that nation for decades? What terrorist opportunities? Please enumerate them.
You mentioned hydroelectric. Look back at that energy map of California. What do you think would happen if terrorists attacked those dams, flooding the valleys in front of them, drowning the residents, and washing away homes, businesses, and communities? Or did you think hydroelectric was warm and fuzzy since you can't get thyroid cancer from it?
Yes, it's a loose definition. That's what large-scale electricity generation entails. No form, not green, not nuclear, not fossil fuel-based is 100% safe when producing large amounts of energy on a municipal level.
You're right. It's hard to be safer than an alternative that can't run at the same capacity. 104 nuclear facilities are licensed in the US -- many of them share a physical location. Only 102 of them are actually running. 20% of all US electricity comes from nuclear. How many nuclear accidents have occurred in US history? Now look at the number of injuries and fatalities both of workers and people in
"Begging the question" is a argumentative fallacy. It refers to a type of circular argument where the conclusion is used as a premise.
Supposedly it's through CSS and counters. The browsers (except Opera) don't support it though. I take your point though. I guess I never noticed because I never use the feature. Good point.
Hmmm... I have a vision of a script that dynamically converts CSS counter declarations to deprecated markup attributes (which still work in the browsers). Page validates, but ultimately does the right thing. Time. I need more free time!
Yes, but not only was IE Mac v5 more standards-compliant than IE Win 5.x, but its usage is rapidly being superceded by Safari. In both cases, CSS hacks are manageable.
...and I can make it work for >90% of all browsers. For the rest of the browsers, I can simply omit the stylesheet. Netscape 4 gets a plain but readable page, but that's it: graceful degradation. Then again, I test my pages in lynx and links. I code for accessibility and 508 guidelines. I'd test text readers for the blind if I had access to a free one.
I know what you mean though. IE Mac has caused me quite a few headaches, but they are manageable. The real issue for me is that I make dynamic web sites (data from a database). Changing the markup is a lot harder than changing the CSS. Using CSS hacks doesn't bother me anywhere near as much as using markup or back-end logic hacks. CSS is a separate file. It's a technology end-point. Unlike HTML or server-side logic, there's nothing downstream of CSS. It can safely be considered throw away code. If I have to rewrite CSS because the current state of browsers changes, no big loss. If I have to substantially change the markup, pain ensues because a change in one page view doesn't necessarily mean I remember that another page view has the same problem.
But then again, that's my experience. CSS takes practice, just like tables hacks did eight years ago. At this point, I strongly believe that I can make any layout that's possible with tables and make them with clean, semantic markup and CSS.
After going to CSS, using tables for layout is painful to me. It's the kind of thing that's difficult to explain to folks who haven't abandoned tables yet. It's similar to the feeling some Photoshop artist had when layers were introduced. It was hard to explain and doubly hard to explain why it was such a good idea especially to people who had honed their graphics skills without them. Once you use them for a while though, going without is basically unthinkable.
Which CSS Zen Garden designs are you referring to? I was under the impression that IE compatibility was a requirement.
In addition, there are things that you can use to make IE act like a standards-compliant browser...or at least close enough to make complex layouts a lot easier. One of them that I like is IE7.
What exactly are you looking for in a multi-column layout? Most of the time, I want the side boxes to remain a fixed width while just the content area grows. Otherwise, percentages can work to enforce proportions.
Note: a fixed width does not necessarily have to mean pixels. More often than not, I use "ems" as they allow a layout to stretch as needed to account for varying font sizes both by me and by the remote client browser. Perhaps this can help with your multi-column layout woes.
It doesn't prohibit table layouts. No technology can prohibit misuses. Tables in HTML were never intended for layout. They just ended up being the only way to do certain things at the time. However they were and are a hack.
Using (X)HTML as a semantic markup with a separate styling specification is the attempt at cleaning up these hacks. Table elements are still there, but intended for their original purpose: tabular data not cut up graphics and info boxes.
Yes, people who use WYSIWYG tools don't know the difference. That doesn't mean that those of us who do know the difference should turn a blind eye. We know better. That is the competitive advantage. It'd be a shame to squander it.
You're using a threading web server with PHP, a scripting environment whose underlying libraries are NOT threadsafe, and you are running into random problems.
What a coincidence!
Did you try the prefork MPM or did you just assume Apache was to blame?
Yes, most of them are fixed width -- just like most of the table-based layouts on the web are also fixed width. This is a design choice, not a technical constraint. CSS can do the standard three column layout on all browsers through a variety of methods.
No, it's not the only layout on CSS Zen Garden that does. In fact my favorite, Bonsai Sky is quite flexible in addition to being visually stunning.
Then again, I think that quite a few of the fixed width layouts are great too. So they don't scale out to 1000px wide. In my opinion, some of them don't have to; It doesn't detract from the experience.
But the moral to the story is that every layout on that site is the exact same XHTML markup. The exact same. Only the CSS stylesheet changes. Can your table-based layouts do that when your company decides the web site needs a facelift, or are you hacking and slashing your logic, scripting, and markup to get it done?
Yes, and when you drop slashdot down below a certain threshold, it condenses the content to an unreadable width and puts in an unsightly scrollbar. C'mon. Give me a break. Graceful degradation doesn't mean "expect a desktop browser to view a page at 200px wide." Just about every Windows computer since 1998 has used at least 800x600. Most are much larger. Have you heard? They make 17" monitors now too.
And what about WebTV and cell phones and text browsers, etc. etc. etc.? Where's your table layout? Do your table-based pages scale to under 600 pixels wide gracefully? What about phones that can only show four lines at a time? How well can you navigate your page with lynx? What about printable versions? What do you do with your table-based layouts then? Make whole separate pages? With CSS, it's just another stylesheet. No need for substantial rewrites of logic that made your XHTML for each view nor for site graphic redesigns.
The point of CSS is that you can make a different stylesheet tailored to each client. You'll note that on CSS Zen Garden, all of the different examples are the exact same markup underneath. EXACTLY THE SAME. Some of them even resize below 700 pixels wide. Wow! It's like they separated the content from the layout.
Also check out Mezzoblue, made by the same guy who started the CSS Zen Garden. Go ahead, resize it down below 700 pixels wide. Hmmm... Still looks okay.
And with regard to the DOM, I misunderstood before. I see what is meant now. And... well... DOM affects the default order and layering of things. Even that's not set in stone if you set the position and/or z-index.
Take a look at the rest of the designs on CSS Zen Garden. Look at the sites linked from Mezzoblue. Check out Meyerweb. Welcome to the 21st century. We're waiting on you.
No, these days the common set is HTML 4, CSS 1, and about half of CSS 2 being safe to use.
Also, let's be honest: people say "IE" like it's one browser. IE 6, IE 5.5, IE 5, IE 4, IE 4 for the Mac, IE 5 for the Mac, IE 5.1 for the Mac, and IE 5.2 for the Mac all rendered slightly (and sometimes not so slightly) differently.
Even IE-only sites have had to contend with graceful degradation. Personally, I'm positively ecstatic over standards support today as compared to just three years ago.
HTML 3.2 and tables are dying. The CSS support to avoid their use is available today. Let them die.
Sort of... XHTML 1.0 Strict, XHTML 1.1, and XHTML 2.0 do not have presentational elements in the DTD.
In HTML, it's a best practice. In most XHTML, it's a technology.
PDF on the web also failed because, contrary to popular belief at the time, the requirements for viewing documents on the web was not the same as print publishing. RBG vs. CMYK was the least of worries.
IE 5.5 is workable though. It definitely has some hefty warts, but it's serviceable. IE 5.0 and below contain some show-stoppers. Luckily 5.0 and below have dropped below the 10% level, and they will continue to fall.
If more people drop direct support for them, more web pages will break for these people, and sooner or later they will upgrade or someone else will upgrade for them.
Also note that users of IE4 and IE 5.0 (and 5.5) obviously aren't using Windows Update. Honestly, I say "fuck 'em!" These are the people that have been taken over by worms, are partly responsible for a good portion of the viruses that end up in my inbox everyday, and probably have some much of their bandwidth taken up by those worms/viruses that the web isn't enjoyable for them anymore anyway.
Honestly. Less than ten percent. Worm food. Fuck 'em.
Three words: CSS Zen Garden. Or do you consider those "real basic layouts"? ...and they work in IE.
The only reason you think tables are easier is because you already know how to make layouts with tables (and have learned the necessary cross-browser hacks), but you haven't learned CSS to the same extent.
CSS can do anything a table-based layout can do AND can do a few things that tables cannot. And please don't bring in comparisons or DOM/CSS to HTML. The DOM has nothing to do with it unless you're scripting. If you're scripting, then yes, DOM/CSS is worlds better than document.write()/HTML.
Oh yeah... Dreamweaver does XHTML now. So I guess that makes your entire post wrong. A shame that.
As opposed to the divine elegance of nested tables and font tags? Please.
By the way, if you don't like inline CSS, don't inline it. Make it a separate stylesheet file or at least put all declarations in the style element in the document head. Inline CSS is just an indicator of a web coder who's not yet ready to give up on font tags. Let them go!
And you forgot history. Those of us who started writing HTML back in the early days were already technically saavy. The ones who had a real problem with writing HTML didn't really start until WYSIWYGs like Frontpage hit the scene. Today, the number of people who know HTML versus knowing Dreamweaver is quite small. If the tools switched to XHTML, I doubt most users would see the difference, and any standards-based rendering bugs would be indistiguishable from all the other rendering bugs that crop up.
As for simplicity, XHTML (strict) has fewer tags than HTML. In addition, fixing one page with CSS is easier than fixing the equivalent using tables, font, and bold tags. For a multi-page site, it's no contest: CSS wins hands down.
And as for "something that anyone can easily learn and use," nowhere in the HTML spec did it ever say that title tags could go inside the body tag or any of the other inane combinations of incorrectly embedded tags in common usage. (I've seen it happen on more than a few pages.) That isn't HTML. That's a series of hacks on top of hacks that have made development for the web a living hell sometimes for the last ten years.
Want to make something easy? Standardize it so that all browsers have a clear target, document it thoroughly, and make easy-to-understand, step-by-step tutorials and other training materials.
You sound like a youngster to me. Table tags did not work consistently. We, the folks who started making web pages before Internet Explorer 1.0, remember when the table tag was introduced. We remember how default rules for cell padding and spacing were different. And how worked for one browser and not the other. And how tags could be used to stretch table layouts with one browser, but not the other. Yep. Good times. Good times.
And we remember how page margins were not only different, but used completely different body attributes (leftmargin/topmargin vs. marginheight/marginwidth).
CSS on the other hand has its rendering behavior largely set in stone. Perfectly? No, of course not. There has never been a software spec that was perfect. But 95% of the CSS spec is damn clear on how things should render. If a browser renders different from a reference image, the CSS renderer is wrong. This is in striking contrast to the good old days of Netscape versus Microsoft when rendering tables correctly was simply a matter of discovering where the layout bugs cancelled each other out.
As for WebTV, some great things about CSS is (a) graceful degradation and (b) alternate stylesheets depending on the client.
I'll take W3C ideology over your ideology any day.
And apparently the Perl folks can get a working model running with Apache 2 even though they're using the same underlying libraries as PHP. Hmmm...
Has Windows only recently starting relying upon threads? No. Are 3rd party libraries on Windows threadsafe? Pretty much. Do the PHP developers recommend its use with Apache 2 on Windows? No. I recognize that Rasmus has mentioned this, but again Apache 2 has been out for two years, Windows has been out for much longer, and still PHP is "a production environment neither on Unix nor on Windows." They don't say why. No one puts this explanation on PHP's Apache 2 install page.
Why doesn't mod_perl have this dire Apache 2 warning? Doesn't it use the same system libraries on Linux? What do the Perl folks know that the PHP folks don't? Is Perl any less a "glue language" than PHP?
But rather than actually deal with the problem, they avoid it. I say the web page should state clearly that PHP may have problems with non-threadsafe libraries, and if you use Apache2 with mod_php4, support may be limited to documenting your hardware and software configuration. What does this accomplish? You get a better idea of what kills a setup, and you get more info (most important!) about what the underlying problem is.
Not everyone reads the PHP mailing list archives.
Someone wake me when Apache 2.0 support stabilizes for production use. Yes, that includes the database drivers and other support libraries. It's been two years since Apache 2.0 went stable. I mean c'mon.
Oh yeah, namespaces would be nice too.
I used to play Scorched Earth almost every day afterschool for a while in high school on my friend's 386SX. Great fun.
Now there's an Open Source, 3D panning, zooming, rendered version of the venerable game.
No first person shooting. No Viet-cong. No Desert Eagle. Just a big gun, an angle, a force, and if you're good enough, a hit.
I like to think of it as a wine that's had sufficient time to age. Doubtless, the younger ones will not appreciate this fine wine in favor of a brand new Mickey's "fine malt liquor." Still, I like it.