I don't think I'd be wrong in saying that the problem is not the idea of CSS itself, it's the browsers. Internet Explorer 6 in particular is grossly painful because it has poor standards support even when all the other major browsers do not and unfortunately pre-XP users and all those who haven't upgraded to 7 are still using it. If browser support was efficient and world-wide then vBulletin would have already switched, no doubt. They just want to maintain as high a compatibility level as possible. I don't doubt that the switch of phpBB deliberately coincidences with the more-or-less-demise of Internet Explorer 6 and an approach to a reasonable level of global CSS support.
Oh, and I think it looks great. I never thought vBulletin's appearance was particularly strong and while I think their colour scheme is a bit...odd... the overall smoothness is terribly nice. Definitely a happy step away from the "bunch of boxes" appearance.
Not that I'm knocking boxes, I use them a lot.
phpBB goes all CSS / tablefree
Collapse
X
-
I'm really impressed with the new look of phpBB. I think they did a fantastic job. I never expected to see anything like thatLeave a comment:
-
I think we can talk ad nausea about perceived loading speed improvements or whether it makes sense to adhere to standards. But what most if not all today's web designer agree on is that it's a lot easier and efficient to separate design (css) from content (xhtml).
Do you guys know csszengarden.com? Believe it or not, all the designs share the same xhtml code basis and only differ in the style sheets used.
Another interesting post: 55 reasons to design in xhtml/css: http://www.khmerang.com/index.php?p=106
Let me rephrase the original questions of why xhtml/css should be better than tables... why should vBulletin continue to use tables?Leave a comment:
-
Back in the 80s when HTTP became a recognized standard you had HTML 1.0. It was fairly boring. You couldn't format text or wrap it around images. You could use paragraphs and not much else. This worked for Academia and the Military complex because it was cheaper than emailing the documents.
Enter a web browser called "Mosiac". It started opening up things to people outside the Academic circle and the military complex. It became the basis of both Netscape Navigator and Internet Explorer 1.0. But we're getting ahead of ourselves.
In HTML 2.0, the scientists and school researchers wanted more, they wanted tables to present data in their reports. So it was incorporated into the specification by the W3C.
About the same time (1991-1993), the Internet "was born". This is regardless of the fact that it had been around since the mid-60s but I digress. The fact is here that the internet was opened to the common consumer and corporations. They wanted more so background colors, fonts, etc.. were added to the specification giving use HTML 3.0. At this time the only way to control the layout was tables and frames. Frames were supposed to be used for layout but many nascent browsers including Internet Explorer 1 and Netscape Navigator 3 couldn't handle them properly. However they could handle tables unless you stacked them more than 5 or 6 deep (which would crash Navigator). So everyone used tables for layout and ridiculed frames.
Then came the Browser Wars. Internet Explorer went from 1 to 3 practically overnight and then quickly to version 4. Netscape also went to version 4. People designing websites wanted more features in their sites so both Microsoft and Netscape started giving dozens of proprietary tags and pushing some of them into the HTML spec since they both sit on the board. So we get HTML 3.2 and HTML 4.0.
By this time HTML is very bloated and hard to deal with. You have to code two versions of everything to work in the two dominant browsers. Enter XML and CSS.
History lesson over.
With HTML a lot of shortcuts were taken from the original markup parent. You didn't have to close tags, some tags were optional and each browser can determine how to render those tags. This made a mess. For instance the <td> tag is optionally closed when the browser encounters a new <td> according to the specification. Internet Explorer closed it. Netscape Navigator didn't.
XML's or more importantly XHTML's purpose was to get things back to the original tag markup system. Close tags, make sure required attributes are there, etc.. To handle the bloat though, a lot of the new proprietary tags were removed. The XHTML should only have the data you want to display. The browser should get the instructions on how to display it from another source.
That source is CSS. It should contain font information for each element, where it is located on the screen, etc... The problem is that many browsers didn't support it or support it completely so people still used tables for layout, even though they went against the spirit of the specification.
Today's browsers are better at supporting both CSS and XHTML but coding habits from the last 2 decades die hard. Especially when you add in tools like Frontpage, Dreamweaver and Go!Live which add to the problems in their own ways.
Also, isn't the stock vB 3.x already XHTML 1.0 compliant?Leave a comment:
-
Also, isn't the stock vB 3.x already XHTML 1.0 compliant?Leave a comment:
-
I've read that before but "faster" is a perception to most users. I've seen pages with less code take 30 seconds to render on my screen where some large 100K plus pages are done in less than 10 seconds. That is why I said:
Technically, it could be true but it really depends on the coding of the site itself.
Not really trying to argue with you and I see losing tables for layout as the way forward but it isn't a cure-all that everyone always makes it out to be. Maybe in 5 years when CSS-3 is supported more than piecemeal and the actual recommendation exists completely it will be a different story. But we have had RTF and PDF for many years now and they still don't offer the features developers need completely. Design will be an ever evolving technology.Leave a comment:
-
Really depends on the site. Technically, it could be true but it really depends on the coding of the site itself. Most vBulletin sites load faster than ESPN.com, which is "semantically-correct XHTML design". Though ESPN.com probably loads faster than it would if it was a bunch of nested tables. Can't really compare though. Also have to take the browser into account. Some browser engines have problems with nested tables and fast rendering. Others don't. I am sure some have problems with DIV/CSS based rendering.
Check out that article for a nicely-written case study about what would happen if Microsoft.com were correctly coded.
It's a bit dated (it's their old layout), but the ideas presented are still good. It's interesting to note that Microsoft (as well as all its subsidiary sites) have since moved to (roughly) standards-compliant semantic code.Leave a comment:
-
Who exactly decides the 'Proper' way to code a page, Now the css phpbb looks nice I agree but what's with all the fascination with css and why all of a sudden css the right way to code a page.
I thought a page was coded correctly if it looks the way you want it to not because some random egg head tells you it conforms to some strange standard or it uses the latest in coding techniques.
So as I asked earlier who is the person that popped up and said 'Oy no, thats not proper'?
The next step involves properly coding your XHTML content. While it's nice to have your code validate in W3C's XHTML validator, it's more important that you are coding your page in a semantically correct way. For example, you should divide out the different sections of your page using <div> tags (without unnecessarily nesting multiple <div>'s), marking up your paragraphs using <p> tags, using a heading system that uses the <h1>, <h2>, <h3>, etc. tags, and creating numbered or unordered lists where appropriate (for navigation or lists, for example).
Increasingly, an industry "best practice" involves coding not only for your standard Mozilla Firefox/Internet Explorer browser with standard settings, but also for those who are using accessibility enhancements, such as enlarged font sizes, high-contrast display settings, image-less or style-less display settings, and also for limited screen sizes as well.
By separating your content from your layout, it is possible to address all the needs of your users with relatively few changes, if any at all, to your content code.Leave a comment:
-
Really depends on the site. Technically, it could be true but it really depends on the coding of the site itself. Most vBulletin sites load faster than ESPN.com, which is "semantically-correct XHTML design". Though ESPN.com probably loads faster than it would if it was a bunch of nested tables. Can't really compare though. Also have to take the browser into account. Some browser engines have problems with nested tables and fast rendering. Others don't. I am sure some have problems with DIV/CSS based rendering.Leave a comment:
-
-
"I wish vBulletin will move towards a semantically-correct XHTML design."Leave a comment:
-
Leave a comment:
-
Well, tables are used for tabular data such as spreadsheets. Divs (CSS) are meant for layouts. But still, I couldn't care less what coding a page used. As long as the page looks fine.
Some say that CSS loads faster. How is this true?Leave a comment:
-
I thought a page was coded correctly if it looks the way you want it to not because some random egg head tells you it conforms to some strange standard or it uses the latest in coding techniques.
So as I asked earlier who is the person that popped up and said 'Oy no, thats not proper'?Leave a comment:
widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
Leave a comment: