The Apple iPad and it’s war against Flash led me to learn about and be optimistic for HTML5, which creates a new non proprietary web video standard. But when I went to see what other cool things it was going to do I was shocked:
basefont, big, center, font, s, strike, tt, u
What? CSS is a nice and powerful thing, but it’s just not a replacement for simple tags. It’s kind of like requiring an entire Windows OS when all you need is a calculator. I’m gonna go crazy if I want to make a simple table and have to add a million lines off CSS just to get a table header to center, or cross a word out. Wow.
They also entirely got rid of frames because
But… it doesn’t specify what will replace their function. I guess frames got a bad rap. I kind of liked them. It was nice to be able to have a TOC in one frame and content in another frame without having to replicate the TOC on each page.
I guess CSS or dHTML will replace everything. Sorry, but as cool as they are, there needs to be a simpler tag based system or else the learning curve for HTML, not to mention the strain on fingers from excessive coding to do ridiculously stupid things, will be a major pain in the ass…
big, s, strike and tt have been deprecated or discouraged for over 10 years, and they’ve had semantic counterparts for ages: the various <hX> tags, <del> and <code>. Same goes for <b>: <strong> and <i>: <em>.
th { text-align: center }
is much more efficient than putting a <center> tag inside every th, even if you specify a css class. You can use <del> to cross out a word.
Frames are a separate issue, they’re both problematic and useful. In any case, they’ve been put back in the HTML 5 draft last year, and they’re still there in the lastest draft, so I’m assuming you’re relying on outdated material for this claim.
There’s two things going on, relying on css and ditching frames, and they both have to do with the expansion of non-traditional browsers.
First, the point of relying on css is to separate the content-display code from the page-structure code. So the you write the basic structure code on the one page and then the different browsers (web phone, tv browsers, etc) can handle it depending on the hardware they have available.
By putting the content-display code separately, the web page can be made to display using different .css files depending on which browser is showing it. So a site might have a .css file to use a three column layout if it detects a regular version of firefox, or a one column layout if detects mobile safari, for example.
Frames are being deprecated because frames play hell with non-traditional browsers. They’re useful, yes, but these days they can be replicated using .css instead, and again, .css is better suited to the flexibility of modern browser usage.
Flexibility is really the goal, I think. The best websites have always been flexible for different browsers and monitor settings. Modern reliance on .css allows for a better fit on the widest range of browser possibilities.
I wouldn’t worry about it so much. The ways browsers go, I don’t even expect most of the new constructions in CSS 2 to be generally instituted by most browsers until I have great grandkids.
Once upon a time, there was never going to be another version of HTML - what happened there?
I’m not sad to see frames go - they seemed great when they were new, but they don’t work very well with modern browsing habits (not just modern browsers, but the way in which people consume web content. A website with frames can’t be easily bookmarked, probably won’t work with the ‘back’ button, will probably have trouble launching an internal link in a new tab or window, won’t work on many compact mobile browsers anyway and may not be fully accessible to some users with sight or other impairment (and that list is just off the top of my head).
It doesn’t mean frames will fail to work in any imminent version of any particular browser, however - most browsers still try their best to render code even if it is foreign to the declared type and version of the page - and some of them render some tags that never have been official parts of the language - so frames might be discontinued, but they won’t stop working straight away.
These and other things are getting tossed out because they aren’t semantic – they deal specifically with how the content of the page is meant to be displayed. It used to be that HTML was just the only tool you had, and you used it to specify an unholy mashup of content and presentation. These days it’s understood that keeping content and layout separate is a very good thing, as it improves flexibility, accessibility, and maintainability. Suppose you want to change a font used for various elements in your design? If you were using <font> tags, you need to go through and fix every last one yourself. Or you could use CSS and change a single line in a stylesheet.
The tags in a HTML document should only specify the content: the meaning and structure of the document. Stylesheets should be used to indicate how that content will be presented on various media. This makes everyone happier and prevents up to 40,000 puppy cancers every year.
CSS has been grossly over-hyped and was poorly thought out to begin with. There is just so much in the specs that is counter-intuitive or seemingly arbitrary, that it is no wonder that browser compatibility is still an issue.
And, yes, I understand the concept of separating presentation and content, but sometimes I just want to slap a tag into the HTML and be on my way.
Yes on the “poorly thought out” part. The things it does get right work very well, though.
Nobody’s stopping you except for the removal of some tags that really do have both good CSS alternatives and (most of them, anyway) more useful replacements.
HTML5 - which is only marginally to do with styling unless you really still think that <font> tags are a good idea - also introduces or standardizes a couple of very useful new technologies such as <canvas> and <video> and a few more descriptive tags (which again you are free to style as you like) such as <time>.
All in all it’s much more inclusive and conservative than the earlier XHTML proposals, which isn’t surprising since most of the ideas came from actual browser manufacturers at the WhatWG.
Tags that are deprecated can’t be counted on to be supported by browsers, so, yeah, that sort of stops me.
I dunno. I’ve been in programming for 20 years and I can’t remember working with a technology as clumsy and time wasting as CSS since developing in COBOL on a mainframe.
Seems to me that it is all part of a push to de-democratize the web and get the amateur content providers off. Old style HTML was easy to learn and forgiving of errors. CSS (at least if you want to do anything with it you couldn’t do more easily with HTML anyway) and XHTML (how does HTML 5 relate to XHTML, incidentally?), not so much. Eventually only expensive professionals with years of training will be able to make web pages.
Because I don’t believe it in the slightest. HTML 5 by the way is NOT XHTML, has the same type of forgiveness of errors, only this time it’s actually codified what to do in the common cases, and it adds many more useful tags than it removes. It also is identified by a simple first line and anything that doesn’t match that will probably be rendered just like HTML 4 TRANSITIONAL is rendered right now.
About the HTML 5 proposals, check out http://www.whatwg.org/ - this whole HTML 5 thing came about because pretty much everyone was getting disillusioned with the W3C work on XHTML 2. Now XHTML 2 was a proposal that was impossible to implement by amateurs, but HTML 5 is a natural expansion and description of the already existing HTML implementations.
That’s using inline tags - the big win for CSS is really when you want to use BIG RED text in multiple places on your site, then you define the style in a separate CSS file and in the pages, you only need write:
<span class=“ShoutyText”>Your Shouty Text Here</span>
Then if some busybody in Corporate Standards decides the Shouty Text on all the web pages needs to be bigger, or a different colour or font, there’s only one place to make changes - in the class definition in the CSS file.
Edited to add: If you just want to change the formatting of one piece of text on one page, then doing it with CSS is a pain, but IMO, it should hurt, because dabbing little bits of different and assorted style all over the place is, in general, bad web design.
I completely disagree. I’ve been working with more than a few clients who don’t really want all the big bells and whistles. They don’t need database content, they don’t need a CMS. They just want a simple way to advertise their business. It hasn’t made me rich yet, but it has paid for my college tuition. Most of the sites I’ve done could be done in straight HTML. I use HTML/CSS so all of the pages in my sites have a consistent look throughout. And, as had been said, if you need to make changes throughout the site, it’s easier to change a single CSS line than change every instance of a tag in every page in the site.
And while CSS may seem like a roadblock to “table based” web designers, it is actually easier to use the more you use it. Like anything else, it just takes a period of acclimation to get used to using it.
But the important thing to remember is that there is no one set way to do your web sites. The way to do it is the way that is appropriate for the site. I’ve seen sites that use all table based layouts and while they may be pretty much static, they work.
Besides, the site I usually use to see browser statistics is down right, but the last time I checked a huge chunk of users are still using IE6! So your average user still has a long way to catch up as far as the newer implementations go.
No. And from now on, I will pray to the loving God every night that I never will.
While that is true, I don’t see it as a very compelling defense of CSS. We’re no t talking about rocket science here. CSS at its core is about laying out text and graphics on a screen. Extended functionality is important, and I understand that, but if you can’t get a tool to do its essential job effortlessly, then you have a problem. With the amount of time I have spent with CSS it should be second nature to me, but it’s not. I still struggle with it from start to finish.
I realize that this is Great Debates and not The Pit but it’s hard for me to restrain my contempt for CSS. I probably need to work on that.
By the way, I should probably make it clear that I don’t have a problem with the **concept **of CSS (separating content from presentation), it’s the **implementation **that stinks up the whole room.
Ditto this. Whenever I’ve tried using CSS I feel like it’s some bastard step child of javascript. And while I agree that separating content from presentation is important, sometimes ‘the medium is the message’ as they say. While technically strikethrough or underlining is a font effect, I think of them more as something about the content when I use them. Getting rid of them is kind of like replacing all punctuation with code signifying the purpose of the particular punctuation…
I completely agree. CSS is a great idea in principle, but the implementation sucks so hard it’s difficult to even imagine. Lots of fairly simple design goals are actually impossible to implement unless you augment your document structure with a bevy of non-semantic <div> elements.
And it seems that CSS’s “design by committee” approach strongly favors fixing those problems with an unending series of special-purpose hacks instead of addressing them at a basic level. For example, in CSS2, if you want to give an element multiple background images, you’re out of luck. Can’t do it. You have to stack it inside several pointless divs if you want to achieve that effect. In the drafts of the CSS3 standard, last I checked, this was “fixed” – by allowing you to specify up to nine background images for one element. What the fuck? What if I need more than nine? What if I need complex compounds that their nine attachment options don’t cover?
