Slashdot Mirror
Web Designer's Reference
The reasons are clear and compelling: The World Wide Web Consortium, which promulgates Web design standards, has decreed HTML as obsolete. Newer, more compliant browsers, will in time not support the older tags and code; the new standards facilitate much better use by the disabled of screen readers and non-graphic browsers. Not least, the newer code makes writing and revising code easier and more efficient, as well as more capable.
These are certainly good reasons for Web designers to move to the new code. Nevertheless, surveys show that most Web pages are not compliant and that thousands of designers continue to use deprecated code. I confess that I am one of them -- after a number of years learning and getting used to HTML, the need to learn new and more code is onerous. The inertia of habit is a factor, I'm sure.
For those Web designers like me, Mr. Grannell's book is a welcome addition to the literature because it systematically deals with the topics under discussion. In its coverage of XHTML, CSS, Javascript, and complementary coding (like PHP), it provides a nice framework guiding "old dogs" like me into standards-compliant code. Not only does it provide some historical perspectives on these codes, it compares the old with the new in regard to all of the important elements of Web design.
The author is an experienced Web designer and operates a design and writing agency. He also writes articles for a number of computer magazines.
Grannell's goals are to teach cutting-edge, efficient coding, and how to master standards-compliant XHTML 1.0 and CSS 2.1. There are a dozen chapters. He breaks down the elements of Web design into modular components so that one can focus on each element separately, like page structure, content structure, layout, navigation, text control, user feedback, and multimedia. Relevant technologies are explained in context of producing a typical Website.
If one finally decides to move forward, as many suggest, this is a very good volume by which to get your start. For new designers, this is a nice primer to learn what is expected, in an overall sense, of good, advanced Web design.
This is a well-produced book with clear writing, comprehensive approach, dozens of practical examples, and downloadable files with the code examples used in the book. The author writes in a logical sequence much like an engineer would. It is a heavy textbook-like read, only lightly sprinkled with style and personality. It should appeal primarily to novice designers, but has enough advanced information to satisfy an experienced designer who is looking for that fresh start.
And in fact, the structure of the book facilitates the "fresh-start" idea. It starts with a Web design overview, giving an experienced user's tips on what software to use to write code, what browsers to design for, how to build pages from the very top to the bottom. (XHTML, unlike HTML, requires a preliminary document-type definition (DTD) to validate. Only after the introductory section does the first HTML tag appear.)
Like others writing in this area, Grannell firmly advocates designing for standards compliance, usability, accessibility, and last and least, visual design. Marketing Department people may choke on that priority list, but there is no inherent conflict between function and aesthetics; Grannell simply does not spend a lot of time on the aesthetics.
The middle chapters concentrate on modular construction of pages -- the XHTML introduction, the structural elements like text blocks and images, the logical structure of the links and navigation flow, and finally, the stylizing with CSS. Comparisons between pages styled with HTML vs. CSS compellingly demonstrate the benefits and advantages of CSS. There will be no going back once you've decided to upgrade your technical approach.
Basic CSS concepts are explained and illustrated with code samples and screenshots. Grannell describes how to use CSS for text control, navigation, and layouts. There is a broad section on frames and another on forms and interactive components.
The last chapter covers testing and tweaking including how to create a 7-item browser test suite. Strategies overcoming browser quirks are discussed throughout the book. There is detailed technical information, especially in regard to the XHTML introductory section of the page, which I have not seen elsewhere.
There are three welcome reference appendices at the end covering XHTML tags and attributes, Web color coding, and a very comprehensive entities chart noting currencies, European characters, math symbols and more.
Much of this material is covered elsewhere in the growing set of publications about standards-compliant code. This book has the virtue of having a useful overall perspective on Web design and acts as a framework for new designers and converting designers to renew and upgrade their technical approaches.
You can purchase Web Designers' Reference: An Integrated Approach to Web Design with XHTML and CSS from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
That's a long title. It's upwards of five words. We need to stop this trend before we get crap that's fourteen words and requires a pamplet hanging off the spine of the book to print in full. New Books:Old Books Diet Cherry Vanilla Lime Dr. Pepper:Dr. Pepper
Bring back the BLINK tag!
-- jimmycarter
Look around the web, and see all the complicated PHP scripts and ASP pages serving as frontends to database of choice, to serve up what's essentially static information.
Plain HTML is quite often the most efficient solution, to produce, host and maintain.
All aboard the hype train! We'll fill the dotcom bubble back up, one asshat at a time!
I don't need no instructions to know how to rock!!!!
Haha, a web design book being reviewed on Slashdot. Oh, the ironing is delicious.
This begs the question: "Whose implementation does this book emphasize/teach?"
... to launch my CSS3 compliant site.
I setup my cron to push the site live in 2007.
Obviously a troll.
Have you no eyes, man?
Guy asked me for a quarter for a cup of coffee. So I bit him.
For ANY web designer who has at least some experience with html/css, this is the single most difficult aspect of web design. That is, getting the page to work in all the popular browsers takes the most time and really has no logic to it. What I would like to see is a book that skips all the fluff that we've seen before and goes straight to browser bugs. If they can be avoided in the first pass at making a web site it makes perfecting the final presentation all that much easier.
Quid festinatio swallonis est aetherfuga inonusti?
Africus aut Europaeus?
Newer, more compliant browsers, will in time not support the older tags and code;
Yeah that's a great idea. Lets just stop supporting a simple markup and make it impossible to view all the legacy HTML in existence. While we're at it let's force everyone to change to a newer, more complicated standard, even if they have no need for it.
Now I'm all for using CSS and XHTML, but that is because it makes things easier to maintain for me. Calling for browsers to stop supporting HTML, however, is taking it about three steps too far.
Ah, the irony of a review of a web standards book being posted on Slashdot, which still uses the FONT tag.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
XHTML brings some nice and obvious changes to HTML (such as single tags for new paragraphs), but at the same time, I don't understand why "strong" is better than "b" for bold, or "em" is better than "i" for italics. IMHO, less typing is better, even if most people now use some sort of graphical editor like Dreamweaver.
Taking guns away from the 99% gives the 1% 100% of the power.
So if that is the case, then why the heck doesn't more people do it? I mean, if we assume that people learn to code webpages from books, why do they buy the old shitty books and code their pages with godawful font-tags and something that closely resembles MS-Word-HTML?
With that said, XHTML and CSS is love.
If the developers of Netscape Navigator had this fanatical devotion to the W3C that seems to be popular lately, we wouldn't have tables, scripts, or any kind of styles (neither nor CSS). None of that was in the standard (HTML 2.0) at the time.
I don't understand why designers and technologians keep preaching XHTML. It's at best a kludge. Until you start serving XHTML documents with the correct mimetype (application/xhtml+xml I believe) XHTML provides no benefits over plain old HTML (provided you stick to the spec). Until then, User Agents will continue to accept whatever crap you throw at them, and since you're not using real XML you won't see any errors (except for the rendering).
I coordially invite someone to give me one reason why XHTML (in its current form, served as text/html or text/xml) is better than HTML 4.0 strict? Is closing my link and meta tags really that life-changing?
For at least the past couple of days, all blurbs posted below (i.e. before) a book review blurb on the front page are all italicized. I guess there's an open i tag that is never closed. Maybe Slashcode maintainers should pick this book up.
Macromedia, Adobe and gang have to push things forward to keep getting us to buy product right. Is HTML now "designed obsolescence"?
& page=1 [csszengarden.com] (Click "select a design to see the style changes). But again I see that as new candy that doesn't really solve problems that neither I nor my viewers are having. [/rant]
No
Jakob Nielson and the gang have pushed us to really boring text based browsing that is a chore to read, and not worth a casual flipping. Why should *I* care if my website is Modem/text based browsing compliant? Sure if I had a research website I can see the point, but my website is a video hosting portal http://videos.streetfire.net/ [streetfire.net] so I doubt the 40,000 folks coming to my site every day care about text based browsing or low-bandwidth options, since the end media is video.
FWIW though I chose 3.0 HTML because it's easier to integrate the 13 ASCX objects into my single ASPX page than if I kept styling separate with XHTML.
Now that if course is just me and maybe I'm bothered by people saying my site is obsolete. I admit there are a lot of neat things you can do with XHTML http://www.csszengarden.com/?cssfile=/152/152.css
PS I used the BR tag too, because I still think the P tag is lame.
-Adam HTML guy since 1994.
Grannell firmly advocates designing for standards compliance, usability, accessibility, and last and least, visual design.
If people keep using HTML, browers will continue to support it. Designing for standards compliance is great, but a crappy website that loads on any standards compiant browser is a lot less useful than a beautiful, usable website that loads on the major brosers like Firefox, IE, Opera and Safari.
Ever heard someone complain about an ugly website that's hard to navigate? we've all done it.
Ever heard anyone complain that standard HTML didn't look the same on all broswers? Not too often I bet.
And standards compliance is great, but with 1) IE having a 90% market share, and 2) IE not being standards compliant, doesn't that mean that most internet users aren't using a standards compliant browser?
Look I don't come around to your house and explain which hole you should stick Mr. Johnson into.
And why is that? So people can screen scrap easier because you're content is xml parsable?
I lived by those rules not long ago; tableless design, css driven, no client side javascript events in the html (but put there by an initialization function), classnames never revealing structure information, separating structure classes with lay-out classes in different css, xhtml 1.1, etc.
Where did it get me? Not sure but sticking to all those rules sure costed me much more time then needed. And what for, because browers require that a page validates in a few years? Forget it, not in a decade, not in two.
Advice, stick to clean html that makes sense, think of your customers, think of your bandwith and don't let that w3c run your web development.
Although I haven't read the book this review is about. I recently purchased another book titled Web Standards Solutions: The Markup and Style Handbook by Dan Cederholm and found it very good for beginner's to XHTML and CSS. Even my wife, who's never dabbled in web design before is enjoying it. Also, quite a few of the chapter's in Dan Cederholm's book appear on his website if you want to get a feel for his writing style.
Whoever told you that Firefox was "100% compliant" was selling something.
Firefox whiffs some CSS2.1 rules among other things.
there's more than one way to do me.
XHTML 1.0 became a W3C Recommendation on 26 January 2000, meaning it has been around almost as long now as HTML was when it came out! (Well, at least, almost as long as HTML had been in popular use when XHTML came out).
The only excuse for not using XHTML today is laziness and ineducation on the part of designers and those educating them. The same reasons most web sites don't validate as proper HTML. Sadly, "just good enough" is the rule of the day.
Excuse me? All I'm saying what is wrong with the current HTML? What exactly needs to be upgraded?
Avarus animus nullo satiatur lucro.
Having said that, using PHP and other dynamic mechanisms to "code around" browser bugs, by implanting "patched" tags or using alternative mechanisms where something is seriously broken, is definitely the most practical solution.
You can use Apache SSI's to detect the browser and then #include the appropriate page, but that is extremely expensive on maintenance. It is much more practical to embed markers wherever you might need to deviate from the "correct" HTML and simply use a script to search & replace.
For those pages that genuinely do have dynamic content, you can have a background engine generate static pages every so often, which you then serve, avoiding a continuous rebuild. However, you run the risk of race conditions, where you try to serve a page that is part-way through a rebuild. The result will be the display of a broken page, which is definitely a Bad Idea.
Really, the "correct" design is to use a mix of approaches. Use static methods for static content, use dynamic methods for dynamic content, use pre-built pages where downloads are more frequent than updates. Hammers are great for nails, but you wouldn't use them in place of a saw or a screwdriver.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
remember what happened last time the good folks over at netscape and microsoft thought the w3c spec was incorrect, or lacking in some manner?
screwy dhtml and authors having to code in all sorts of browser-detection tricks...
Many things are wrong with current HTML. Well, ok, not CURRENT HTML (4.01) but everything before that.
Since XHTML is just a reformulation of HTML 4.01 into XML, and XHTML 1.1 is just a modularization of XHTML, technically nothhing is wrong with HTML as it exists today. But what about how it exiists tomorrow?
XHTML allows for the easy expansion of the language. Right now, DOCTYPES are the only way to define what version of HTML you're using, which makes it an all or nothing proposition. What if you want to use HTML + SUPERCOOLHTML-Extended? XHTML 1.1 allows you to basically define your own syntax, and more importantly allow the standards body to do so easily).
This way you only have to use as much of the standard as you want to, and if there are two competing standards you can actually choose which one (or ones) to use in a way that the browsers can understand.
Now, i'll grant you that for the typical "my cat fluffy" site, they don't give a rip. HTML 4.01 is just fine. But did you know that HTML 4.01 strict doesn't have font tags? It doesn't have the target attribute on links. It doesn't have a lot of stuff you're used to that are going away.
It's best to get used to XHTML now, HTML won't be improved, but XHTML will.
If you need web hosting, you could do worse than here
did someone forget the tag?
I did a page layout on eBay for an older retired friend who makes wooden toys. I used the normal .css file and div tags -- it looked like crap and was unusable. I had to go back to the drawing board and use tables! (Tables, nested in tables to get the same layout)
Most of the internet might be ready for bleeding edge stuff, but don't toss away your plain 'ole vanilla flavored HTML just yet.
Newt-dog
My Doctor prescribed daily nasal saline irrigation, hehe
Call me an old dawg, but I've been doing webpages since 1994 and the only worthwhile change to HTML was CSS. So I don't see a need for the standard to be advanced any more. No driving need. Keep in mind that needs are driven by the website visitor, not by you the designer. So if your visitors needs FRAMES and BLINK tags then good luck with XHTML, becuase your visitors don't give a rip about "advancing the standard" unless it fits their needs.
What I'd like to see is a Quick Reference book that covers most web stuff: HTML, PHP, ASP, JavaScript, CSS, etc. It doesn't have to teach it, just be one quick ref for it all.
Coder's Stone: The programming language quick ref for iPad
That said:
Garbage. The amount of code necessary to support basic HTML is so tiny amidst the vast beasts major broswers have become that there's no reason to dispense with it. And why use anything else when straight, primative HTML is still the most effective tool for conveying simple information?Crow T. Trollbot
Personally I think HTML is beautifully simple. My own site uses vanilla grade HTML,a little JavaScript and some basic CSS. That is sufficient. I'm not running an online storefront or something. I have shown extremely computer illiterate people to write their own HTML pages - and one is running 4 busineses from his own website now for 7 years, with no more handholding from me.
All this PHP, ASP, Today's 3-letter buzzword is mostly HYPE, so "web developers" can stay aloof and whine for more $$ every budget cycle. We need faster, bigger servers to cough up all this bloat, newer browsers to sift through all this crap and spew it up to the user's screen in some useable form. Many of these pages render badly, wrong, or not at all. Countless ones refuse to print or print so f*-ed up it makes the information they offer completely useless.
Yes, K.I.S.S. and yet we do need 'new' technologies and ideas for the web. I painfully recall dooing CGI in Perl 4 on my hands and knees. There are now such nice tools available!! But their abuse and misuse is widespread.
And standards compliance is great, but with 1) IE having a 90% market share, and 2) IE not being standards compliant, doesn't that mean that most internet users aren't using a standards compliant browser?
And this is why monopolies are bad. When you have 90% market share, _you_ are the standard. Cry as your competitors might about your browser not following w3c spec, content-producers will be forced to code their pages for your browser and competition will eventually have to adopt your way of rendering.
We might think it a blessing in disguise that IE was horribly insecure, otherwise Firefox would never have had the chance to break the IE monoculture.
That's kind of like saying "I've never used 4 wheel drive beside off roads. My car pretty much has everything I need." -Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
I learnt html4 and basic CSS as was current back then.
Moving several client sites to xhtml strict in 2000 was totally painless. Let's face it. the majority of so-called web designers haven't got a clue about markup.
More books like this please, the majority still need whacking around the head with them a few more times.
There are plenty of other reasons.
Like 90% of the pages out there don't need it.
99.99% of mine don't. All I need is my trusty hammer and screwdriver, and you're trying to insist I use a fully automatic, 50 calibre nailgun and a 3HP power drill with screwdriver attachment.
You tell 'em, Mr. HTML 4.01 Transitional!
This guy is obviously a jerk.
How can you mod him insightful and live with yourself?
Bah.
I'll not post as myself because I don't want to get spammed like last time I made a comment against him.
:) Boy, some DW fanboy really doesn't like me...
Truth is, I think CSS is limited still. Give me better selectors like the CSS3 spec and that'll catch my attention. Until then, XHTML strict I'm not interested in...
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
OK, so that's a good book, but how about good websites for XHTML + CSS authoring? Preferrably with DOM 1+2 documentation too, more accessible than the raw specs at W3C?
:-/
I've looked around a bit for this, for a browser neutral site and not something riddled with stuff related to IE extensions.
Is W3Schools among the most thorough? It's at least one spanning several web technologies, but not so sure about the depth of it...
I find it hard to just search for these things on Google as then you're greeted with dozens of sites of highly varying quality.
Do the Mozilla Foundation provide a good resource nowadays for XHTML/CSS/DOM/Javascript development for the Mozilla platform? Last time I checked it seemed to clearly be a work in progress.
Actually, Microsoft has a pretty good web development resource content-wise on MSDN, and something I'm looking for. But one can of course imagine how aimed for IE it is. The documentation barely even *renders* correctly on other browsers >:-(
Beware: In C++, your friends can see your privates!
I would add that there isn't a lot of imperative from a business standpoint to stop supporting deprecated tags (and syntax)
People want their browsers to be able to view as many websites as possible, if the average user finds that the browser they are using doesn't render certain sites they like, they're not going to care that it's because the site isn't standards compliant. they're going to say "This browser sucks!"
I code websites all the time and I appreciate a standard as much or more than anyone else, I just think it's unrealistic to think that XHTML will replace HTML, it will just become a better version of it.
that was an amazingly lame attempt at a troll.
I'm still waiting for a non-obese browser to come along that supports these standards so I will have a complete user base available to make use of them. Until then, I'm stuck with generating plain old HTML. Oh, and in case you were tempted to suggest Firefox, don't bother; it's still too big and too slow for 100% deployment. How about one that doesn't grow beyond 100 MB?
now we need to go OSS in diesel cars
Then let us know.
I'm assuming that the missing out of the closing italic tag was deliberate?
The only damn story on web standards for a long time and lo and behold, in the exact same article, they leave a tag open giving the rest of the page - minus the headings - a noticable slant to the right.
Can we have the next web standards story in bold please?
One reason more people don't use XHTML and CSS is that it is a pain in the ass. There is no decent alternative to good, old , and
trying to arrange everything on the page in a certain way with floats is much harder than just using a table. A well-designed language makes it easy to do the things that people commonly want to do. As long as XHTML/CSS remains deficient in this way it will not be widely adopted.
If we ever do reach the point where browsers cease supporting old tags, someone will write a program to autoconvert pages to the new format. By then we may have a better alternative to XHTML/CSS.
because plain XHTML is just as good.
I am the Alpha and the Omega-3
Just curious, after reading the fine article, then doing a little research and reading a couple chapters of the w3c documents I wonder that anyone would change to xhtml for the sake of canonical righteousness.
Seems to me there are reasons to do xhtml... I DO like the idea of well formed objects, especially things like web pages... at least if it's well formed you've eliminated one source of nasty little bugs creeping into sites, especially sites creating pages dynamically.
But, for sites already rolled out and wrung out in public forums this seems prissy. And problematic. Consider:
I've done an informal look-around, and found some popular and quite famous (hmmmm, a particular site comes to mind...
So, academically maybe a good direction to consider, but the predictions of html going away to be supplanted by xhtml is premature, and I predict something that in our internet lifetimes will never happen.
In the long-term view, presentational HTML will (hopfully) drop off the part of the web caring for good looks, and browsers will subsequently start dropping workarounds and presentational tags that make the old sites look as intended. (Note: Most old sites will remain usable; only the looks will detoriate over time...)
All my comments get moderated +-0, spotless.
> Designing for standards compliance is great, but a crappy website that loads on any standards compiant browser is a lot less useful than a beautiful, usable website that loads on the major brosers like Firefox, IE, Opera and Safari.
How about designing standards-compliant pages that are beatiful and usable, and load in all major browsers plus all the simpler ones?... (Once learned how to do it, it's much easier than presentational HTML anyways.)
All my comments get moderated +-0, spotless.
You can do the equivalent of a font tag with a span tag. You can even replace b tags with span tags using a font-weight: bold; (assuming you want the style only and not the meaning...)
I really don't see why HTML is still used. Browsers could get smaller and faster if they could assume all websites are XHTML! Essentially browsers would be XML parsers that apply style sheets to the markup. In fact, why not just improve XSL instead of CSS.
Point is, XHTML 1.0 is here to stay. I don't expect most people to adopt XHTML 1.1 or newer CSS versions anytime soon. For one, we have to wait on Microsoft. Where do we want to go today? Standards!!!!!!
MidnightBSD: The BSD for Everyone
Selectors like "input[type=password]:hover"? There are lots of wonderful ways we as designers could use the complex CSS selectors specified in the CSS 2.1 spec if only a certain browser made by Microsoft supported them...
Also you can use all the goodness of CSS1, 2.1 and 3 with HTML 4.01 so there's still no need for you to switch to XHTML :)
There's mischief and malarkies but no queers or yids or darkies within this bastard's carnival, this vicious cabaret.
Can't have "ordinary people" text editing a web page. Not enough money in that! What's next "ordinary people" sharing information! Do away with the three tags - html head body - at once. Replace them with 500 pages of *must read this* before you do anything. Yeah that's the ticket. More profit for all us friendly computer companies. Get rid of text files, text readers and simple editors while we are at it. Too damn simple and easy to figure out. A browser should be a full 3D, animated resolution and color depth independent publishing engine. That'll stop those peons from communicating! Corporate profits are on the way back baby!
A good overview about W3C-compliance of IE6, Firefox and Opera 8:
http://nanobox.chipx86.com/browser_support.php
Personally, I am sick of IE6 sucking big times and just develope W3C compliant HTML. No sweat in Opera and Firefox. For Internet Explorer, I just enable Dean Edwards IE7 enhancement. Yes, the website does get dependent on Javascript for IE, but it does cut enormously on my developement time, as I am not forced to use the minimal CSS1 support IE has as common denominator.
Personally I think HTML is beautifully simple. My own site uses vanilla grade HTML,a little JavaScript and some basic CSS. That is sufficient. I'm not running an online storefront or something. I have shown extremely computer illiterate people to write their own HTML pages - and one is running 4 busineses from his own website now for 7 years, with no more handholding from me.
All this PHP, ASP, Today's 3-letter buzzword is mostly HYPE, so "web developers" can stay aloof and whine for more $$ every budget cycle. We need faster, bigger servers to cough up all this bloat, newer browsers to sift through all this crap and spew it up to the user's screen in some useable form. Many of these pages render badly, wrong, or not at all. Countless ones refuse to print or print so f*-ed up it makes the information they offer completely useless.
I don't know about you but I know, er used to know, quite a few people who have have some sort of handicap or disability, I have a big one myself, and using "vanilla grade HTML,a little JavaScript and some basic CSS" without a lot of spagetti code just doesn't work. Now I'm not saying all these acronyms make things neccessarily easier and more usable but used properly they can.
Falcon FalconShould there be a Law?
Although many tools like xsltproc can, in fact, handle good ol' broken HTML, using XHTML makes server side processing easier. I've built a light-weight CMS a few times by simply having a bunch of simple XHTML files which are processed into more fancy XHTML by some XSLT stylesheets that are invoked through make/xsltproc. These stylesheets can read some metadata from a sitemap.xml file and then it's just a matter of publishing the fancy XHTML (with ever-changing cruft like logo's and complex menu structures) using weex.
Also, mixing namespaces can be a very powerfull tool within a CMS. After all, most published websites of more than 5 pages are the result of a process that is more often than not quite complex. Everything that makes complex processing easier, is a win to me.
Morality is usually taught by the immoral.
XHTML is a good idea but have you noticed how verbose and complicated it's gotten?
d ">
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dt
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head profile="http://www.w3.org/2000/08/w3c-synd/#">
versus:
<html lang="en-US">
<head>
The US Army: promoting democracy through unquestioned obedience
Me, I write in XML. Any kind of XML I want. Any XML structure that best fits the type of document I'm working on. I've got XSLT to transform it into {really old HTML; HTML 4.0 strict; XHTML + CSS; whatever the boss wants tomorrow}.
Does adding that XSLT translation layer have to cost a lot? C'mon, we're programmers -- it really doesn't have to be a big deal unless it has to. For example, if you've got basically static pages, then you can just use make to automatically regenerate the .html page when its .xml source changes.
If you think you're separating content from presentation via CSS, you should try your hand at Plain Old XML for content, with XSLT to insulate you utterly/completely/totally from the presentation. (OK, I confess: tables still tend to be tables, and I have no shame about naming my tags table/tr/td when the custom equivalent really introduces no particular new semantic value.)
So long as hoes like me design and make dynamic sites to sell huge volumes of useless crap to the hordes of computer illiterate people with a disposable income, web sites will need to display information and data using the lowest common denominator.
--See Dick and Jane run
Get your tagline off my lawn.
Yes, and XHTML doesn't have quirksmode either, so there is one less thing to worry about.
Unclosed head, unclosed body, and the blink tag.
Firefox shouldn't render that - it should just spontaneously combust =/
"Browser support" equates to this default CSS:
:-)
b {
font-weight: bold;
}
I think <b> is safe!
You cretin.
You are too retarded to understand this stuff.
Screw pie-in-the-sky, ivory tower pedagoguery. "The way it should be done" and "the way it gets done in the least amount of time with acceptable results" are rarely the same. You want standards people will follow? Bring those two positions much closer together.
I peek at these books and agonize whether I should invest the hours in them to learn all the standards and back-implement them on old pages or use them in new ones... for about 15 minutes. Where style sheets make things easier for me (text formatting), I'm all over them. But where they don't... F 'em.
When all the browser makers distribute viruses that disable all their old browsers and force people to upgrade to fully standards-compliant ones, I'll consider going 100% compliant. Until then, I'll do what makes life simplest for me while keeping my pages accessible to 95%+ of the market.
Start a happiness pandemic
Don't use the <b> tag; use <strong> instead. The difference is that <strong> puts emphasis on the meaning rather than the display. But for all practical purposes they'll be rendered the same in all browsers.
That wasn't so hard, was it now?
You're really not supposed to use presentational class names, though, (in this case, .blinktag). That was the whole point of depreciating presentational HTML in the first place. Class names should really be based on sematics of the document structure.
I can't wait for someone to make a standard out of it!
First of all, this is not a troll. I read the review and thought about buying the book, so i surfed at +4 trying to find more reviews of the book, or even better, comments like "wait, this book is better, bla bla". But I only found trolls about why XHTML or XML or HTML4.01 or whatever is the *best* solution, and some useless posts about why PHP is better than ASP. Then i surfed at -1, and read all the freaking comments! And I CANT FIND ANYTHING RELATED TO THE REVIEW!!! All the wasted time.. all the offtopic flamebait etc etc I had to read. So, can SOMEONE please write a useful comment? Is this book actually good? Are there better books out there for teaching good XHTML+CSS2 to someone that has some experience on html?
Because it's "primative" (sp) ??
That is when screen readers start making use of the semantic information in the "strong" element. Right now a lot of the semantic markup is wasted. But, you have designed your web site for the future.
Standards Schmandards
(and here's the best part...)
Newer, more compliant browsers, will in time not support the older tags and code
If this comes to pass in the next 10 years, I'm probably not the only one who's going to be really upset.
Only recently, I added the DOCTYPE definition to all my nearly 400 web pages. It looks like this:
Many of these pages were written years ago, some as far back as 10 years. HTML was simple, and as long as you didn't make excessive use of the netscape only tags (like tables), everything was fine.
Somewhere along the way, it was announced all pages should begin with a
tag. This was supposed to make things extensible, somehow.They changed their minds. Now its DOCTYPE. Ok, fine. I modified hundreds of pages and ran they all through a script to validate them all... and fixed lots of minor little things.
But damnit, this whole DOCTYPE definition and html validation is for some reason. And in my world view, it's so that I can know my markup fully conforms to the standards and not browser specific features or bugs. Why bother? Sure, being platform neutral is nice. But the real benefit to an author like me is so that I know the pages will continue to work with little or no maintainence into the distant future. Well, html-wise. Content updates are another matter.
If HTML 4.01 transitional stops being supported by browsers in the next 10 years, and especially if the standards-pushing folks have anything to do with it's accelerated obsolescence.... aside from cursing and swearing, it'll utterly destroy and trust and confidence I may have in the standards process.
So that's basically my little rant. If standards are going to mean anything, and we've all (or mostly) gone to the trouble to put these damn DOCTYPE specs on every single page supposedly so different standards can co-exist... anyone pushing some "new" standard who wants my buy-in better not do anything to diminish the value of all the time and work I've invested in previously published standards.
It's a matter of trust and confidence. Why would I trust in the stability of w3c new standards if support for html 4.01 away?
PJRC: Electronic Projects, 8051 Microcontroller Tools
As long as IE/Windows is the dominant browser and chooses to ignore the standards, the standards are irrelevant. If I can design a page that is totally out of standards compliance which looks great to 80% of the people online and funny but functional to the other 20%, I'm ignoring the standards.
I just wish I could use li:first-child:before (using both pseudo-class and pseudo-element) instead of having to use an annoying hack (like giving an explicit class or id to first child list items)
No one is saying XML doesnt have a future, but the honest truth is that html is at the heart of most pages be doled out in companies across the globe large and small. Its proven it works. XML in its current form is a bit like java. A bit overhyped and more complex for its own good.
Not that web desing and slashdot should go together. The push for XHTML isnt about web design or nice commercial looking layout, its more about programming standards since html is so forgiving. Its a display languiage chill. Forcing XHTML actually degrades the concept of web design. Tables are still king for precise layout. I've run across too many hardcore sites using all CSS, layers etc for layout, and you folks have no idea how many times users view your pages with overlapped edges, etc.
HTML is so non-semantic anyway, it really doesn't matter. Bring on the age of custom schema!
there's more than one way to do me.
One thing is for sure. If the subject is standards, then you won't find this book on anyone's desk at M.S.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
"It is stupid to re-create, on the fly, essentially identical information that probably won't look right on many browsers anyway. It would make more sense to put that time and effort into getting the page to work well than in getting it to use the latest technology."
According to the Greasemonkey story, we can let you all fiddle things into place.
always serve BAH.html
always re-generate NEW.html
when done regenerating,
rename NEW.html to BAH.html,
it's an atomic operation,
there is no race condition
http://dub.washington.edu/denim/
"DENIM is a system that helps web site designers in the early stages of design. DENIM supports sketching input, allows design at different refinement levels, and unifies the levels through zooming."
...when someone's finally going to implement the tag.
I don't see what XHTML offers me that HTML4+CSS doesn't. I've been "separating code from content" from the day I could dismiss the font tag, I don't see what XHTML offers to a non-programmer (I don't think using markup==programming and I know I'm not good at anything that requires more thinking than that...).
I think, therefore I am...I think.
Instead of writing programs embedded into HTML, we should use libraries that wrap HTML inside them. Therefore, any changes in the HTML standard would mostly concern the lower layers of the architecture.
Consider JSP applications, for example. The Java code is embedded into the JSP script along with HTML that is compiled by the JSP server into a Java class. This approach is wrong, for many reasons:
A much better way to do web development would be to have a web GUI library that, instead of generating widgets, it generates HTML. For example, A Swing-like set of components that follow the model-view-controller pattern. When a form is submitted, the framework automatically updates the GUI objects, which in turn automatically fill the model, and thus other views and controllers are notified.
The above architecture also allows for one person to design the page (the designer), then another person to fill the page with data (the programmer), without each person knowning anything of the other's line of work: the designer designs each page, then each page is compiled to Java GUI component classes, then the programmer comes in and connects the view with the model (for example, Hibernate).
The above is pretty much valid for ASP, PHP and other architectures.
Web applications are just like any other application, with the only difference that the GUI is passive and handled from a remote source. HTML is a remote GUI description language, and it should be wrapped up in native language constructs.
>>Newer, more compliant browsers, will in time not support the older tags and code
HTML is still a clearly-defined standard. Lots of manuals are on old install CDs; lots of pages, documentation, and other information is archived on CDs in everyone's drawers and shelves. HTML can't just be dropped like it never mattered.
I am repeatedly disturbed by the attitude that backward compatibility is unimportant, or useless, or wasteful. Much of our technical civilization is built with the assumption that things continue to work, and we expect them to work even after long periods - how many people actually checked their air conditioners this spring before just turning them on?
Would anyone accept a statement like "My new calculator program won't work on checking your statements from three years ago, because those are old numbers"? Or "You can't speak Latin, Greek, or Hebrew on this new cellphone, because those are ancient languages"? Isn't that the kind of complaint Slashdotters always make about M$ office programs changing document and spreadsheet formats?
New versions of computer languages should compile old programs. New browsers should display old documents. Old stuff may run (or be processed) less efficiently, but it should do what it used to do.
It will take me half of the time plus I won't have to care about compatibility. I know it will work in any browser.
I use right now CSS with tables. ID and class stuff in the CSS and only 4 years old CSS tag. Maybe that's called HTML 4.01 transitionnal. I don't care as long as I can guarantee to the client that it will look the same in any browser on the markets.
I still cannot understand what is so wrong with
tags. Why should I write
?
doesn't give you the same flexibility. Everybody knows that.
Even for stupid things like
when you play with CSS only, the dot of
won't be at the same place (vertically) on Explorer, Safari or Firefox. Who cares? When your biggest clients are communication agencies stupid things like this matter to them most than the code behind. I spent an entire hour trying to fix that damn detail.
Then you have to define different stylesheets for each browser. You know it will be a pain to maintain even if your are using a CMS like typo3.
It sounds like the same pain we had to support Netscape and Internet Explorer.
If you don't want to have a junior marketeer complaining about details all the day because he has an outdated explorer on his even older desktop PC, then you use the most simple and bullet-proof tool you have in your pocket.
Interportability? They simply have to grab the content from the database, filter some basic HTML tags if there is any and that's all.
Call me a dinosaur I don't care. I will finish my job before the XHTML fanatic. I won't have to explain what this kaballistic code mean to a marketeer, why it doesn't work and I will have more time to play with my kids.
W3C folks don't live in the real world.
I would prefer seeing them promoting PNG compatibility than new HTML formats. PNG is needed, a new HTML format isn't.
Or what about plug-ins. A large part of the content over the web is handled by propriarty format such as WMV, FLASH and so on. When you have to publish video clips, you have to handle at least three different formats to guarantee that 80% of surfers will be able to see it. Even scarier some Real player or Quicktime aren't properly installed on some PC or will pop-up advertisings(quicktime and its paid version, Real and its own network).
The HTML war is over. The new war is in the multimedia. Olivier
In designing programming languages two things are key: simplicity and power. HTML lives up to that standard. A total amateur can within a day make quite nice pages.
Unfortunately all those modern standards do not live up to those basic requirements. They are much to complicated. Just make a basic page with some XHTML, CSS and javascript and you have three different incompatible languages. The standards world would need a dictator to finally force a harmonisation between those three.
Or take the DIV. This is an incomprehensible abstraction that is impossible to explain to the simple homepage hacker. There is a much more comprehensible alternative: the TABLE. But the language purists dislike it so much that they didn't even bother to make the two compatible.
The modern standards remind me of object oriented programming. It took may years of hype before you could expose its limitations without being ridiculed.
-Eric
SJW: Someone who has run out of real oppression, and has to fake it.
It's sad, but true at least from my experience.
For he today that sheds his blood with me shall be my brother.
Plain HTML is quite often the most efficient solution, to produce, host and maintain.
Am I the only one so far who noticed that those two paragraphs have absolutely nothing in common? You can write dynamic HTML or static XHTML+CSS - the underlying technology has exactly zero to do with the resulting page description.
You might as well claim to hate PDFs because some are made on PowerPCs but Jeeps are more purple.
Dewey, what part of this looks like authorities should be involved?
If the solution to a simple but inelegant system (plain old HTML tables) is to switch to a more complex, ugly, inelegant system (CSS kludges that exploit parser bugs), I think I'll stick to the simpler, more practical system for now, thanks.
Please consider making an automatic monthly recurring donation to the EFF
I include page lint/verifcation tags (instead of just links to the specs) in my standard page footer across a number of sites I run. This lets me easily check to see if my XHTML and CSS2 is compliant as I browse along. Which isn't to say my pages are perfect, but that I consider it an important and complimentary part of a web browsing experience.
We shouldn't just build a web to be used, but one to be extended... that means show others how we do it so they can join in.
first google result: http://www.jakpsatweb.cz/css/css-vertical-center-s olution.html
1. IE mac is a joke, if MS doesn't feel the need to support it, I certainly don't.
2. The HTML in the CSS result remains the same should you redesign the site at a future date, the HTML in the table result will change. This matters if a) you have a large site and/or b) you use a CMS to spit out HTML.
Did anyone else notice that we have this guy's name wrong? It's Craig. Not Graig.
I div is a logical structure, it doesn't have a known display. ie, it can be placed anywhere on the page, and anywhere in relation to other divs.
I could float that div and put it in the top right of the page.
A td is by defintion a table cell (tabular data), which has an implied structure. Breaking that structure to present a table as something not like a table is the wrong thing to do, especially since you're so concerned about browser compatability.
Try using a screen reader on you websites and then come back to me.
Every time XHTML/CSS comes up in a forum like this, there's a lot of railing about how it just complicates thing when HTML does the job just fine.
Well, see, that's just it. HTML doesn't so much do the job just fine. Yes, XHTML and CSS is a bit more complex than basic HTML, but it's not that bad and a good editor makes short work of remembering the syntax. HTML can make a web page very easily. But it can't make a *good* web page easily. The number of hoops one has to jump through to make an old-style HTML page degrade gracefully into accessible browsers, or even look roughly similar between browsers - has led to pages filled with the single-pixel-gif-trick and tables-nested-within-tables -- you get pages where the majority of the markup and even some of the page content has nothing to do with what the page is actually about.
XHTML is a good thing in the same way that strongly-typed languages are - if you don't keep track of everything correctly, it's not going to work at all. Your tags have to make sense - and if they do, you're no longer relying on the hope that whoever wrote the browser took your specifc exception into account. Heck, just adding the XHTML doctype convinces IE6 to play nice with a lot of standards it previously ignored, which is in itself a small triumph
Good-old HTML isn't going away, so those of you decrying the death of the democratic internet can stop worrying. Where XHTML/CSS is really handy isn't for the guy making a Buffy Fansite, it's for the organizations that need to create and maintain complex or wide-impacting web presences, or for the people developing web-based applications. XHTML helps make short work of accesibility issues, it leads to smaller pages (esp since stylesheets cache) so bandwidth is conserved, it abstracts the presentation layer (allowing designers to design and programmers to program without each getting in the other's way - a huge problem with a lot of web applications), the code is pretty easy to read (if you do it right, XHTML content makes logical structural sense and isn't cluttered with tags to move that paragraph to the left 25 pixels etc). What it comes down to is more efficient maintenance and wider support, which saves anyone trying to do a large implementation a lot of time and money.
(and really, XHTML isn't *that* hard. It's at least consistant, unlike a lot of the HTML tags bunged on after version 1...but that's a different argument)
----
"I used to listen to Null Device before they sold out."