Forward compatibility and web standards

Hiptop

Submitted by luminosity on April 5, 2003 - 16:12.

Along these lines is the debacle that occured when the hiptop was released — a lot of standards compliant sites didn't work in it while tag soup ones did, due to the hiptop's mishandling of CSS, and in particular using stylesheets with the wrong media type. It'd be great if simply coding to the standards ensured that your website will always work in everything, but realistically we're always going to have some debacle like the hiptop that has to be worked around. The only alternative would be eliminating any competition in the browser field by not allowing any browsers beyond a major one or two to be developed, a ludicrous idea, I'm sure you'll agree.

login or register to post comments

The best way is to use the tag soup smartly

Submitted by prowsej on April 5, 2003 - 23:36.

I have run teh gamut from using tag soup to using pure-CSS and everything in between. I have come to the conclusion that the best option is to smartly use tag soup and table-based layouts along with a database to hold your content that changes often like news. Personally, I used to spend more time getting my CSS to display consistently across borwers than I saved by not using tags and the like. to each his own. Just don't consider standards a crusade, only a time-saver.

login or register to post comments

Then again

Submitted by luminosity on April 6, 2003 - 03:01.

Then again, if you ever want to be able to usefully extract meaning from your mark-up, you're screwed. Absolutely screwed. Not to mention page load times... not that that'd matter if more people would get with the program and use gzip compression.

login or register to post comments

Good call.

Submitted by dshea on April 7, 2003 - 10:47.

I still live in a world of transition. While I can never, ever again support the use of the FONT tag, I definitely think table-base layouts have their place. A very nice argument for scrapping them is that a redesign can be accomplished through a single file. But in real-world use, this is only practical if you have created your main HTML to account for multiple designs. Who does this? Let alone the fact that you're guaranteed to have to replace <IMG> tags.

Now, about forward compatibility. The recent flap about the XHTML 2.0 draft says a lot about this. Things are deprecated to the point that no site built using valid 1.0 will work if I switch doctypes? So what am I gaining by supporting 1.0 now?

Sites from 5 years ago still work in today's browsers (aside from those that took advantage of browser-specific quirks back in the day) so why change coding practices? What works is what matters, isn't it? It is, and it isn't. It is because it is what we're used to. We know the quirks, we can code around them — the path of least resistance. It isn't, because by now we all now how much more elegant a good CSS-based layout can be.

CSS hacks are what's killing the argument. The fact that the default font size for each browser is different and that box models are broken for a large percentage of users is why people used to the four horsemen of the body tag, marginwidth and so forth, don't exactly see the grass as being greener. Can you blame them?

The bottom line is that people use what works. And right now, both work, with their own quirks. Some stay in the past, others are looking to the future. We've started seeing the shift from the one to the other, and this will continue, that's not in question. So the question you have to ask yourself is if you're going to be stuck behind, a relic of the dot-com boom, or if you're going to evolve with the rest of us.

It's been a slow transition. But it's a transition, and we are moving forward.

login or register to post comments

You cannot prove anything about the future...

Submitted by jim.dabell on April 8, 2003 - 14:38.

...but you can identify trends.

Before Netscape 1.2 came out, it was a common, non-standard hack to use multiple title and body elements to get crude animation. Netscape 1.2 came out, and screwed these pages up. Following standards ensured forwards compatibility with Netscape 1.2.

Before Netscape 2.0 came out, missing quotes on the end of an attribute were detected as errors by Netscape 1.x and compensated for. Netscape 2.0 came out; it did not. Large sections of pages disappeared. Following standards ensured forwards compatibility with Netscape 2.0.

Before Netscape 3.0 came out, people were careless with their ampersands, failing to correctly encode them in URLs, for example. These were detected as errors by the current browsers, and compensated for. Netscape 3.0 came out; it did not. Lots of broken links everywhere. Following standards ensured forwards compatibility with Netscape 3.0.

Before Netscape 4.0 came out, people were still careless with character entities, omitting the trailing semicolon (I believe this was a property of many graphical editors, such as Frontpage). This was detected by the current browsers, and compensated for. Netscape 4.0 came out; it did not. Following standards ensured forwards compatibility with Netscape 4.0.

Before Netscape 6.0 came out, people used a variety of non-standard Javascript techniques and layer elements, detecting Internet Explorer, and serving them alternative code. Netscape 6.0 came out, it didn't support the proprietary Netscape-isms of previous releases. Following standards ensured forwards compatibility with Netscape 6.0.

More recent problems include stylesheets served with an incorrect content-type header, and table-layout images being broken up with lots of little gaps.

This list only includes Netscape behaviour, as that is the only list I have to hand. (Thanks to this article). I'm sure similar things apply to other browsers.

There is plenty of evidence that sticking with standard code results in forwards compatibility.

There are really only two important properties of future browsers:

• They are likely to support at least as much of the specifications as the current version
• Nobody can test in them

Thus, my overwhelming desire is to simply treat future browsers as I would any other browser I couldn't test in: code to standards, and when I get a chance to test, fix up what is necessary.

login or register to post comments

wait a minute

Submitted by jrodgers on April 9, 2003 - 12:08.

So let's treat forward compatibility and web standards as two different concepts, to be studied and pursued separately.

Maybe I am missing something but.. if more sites followed standards than more browsers would be standards compliant, no? Yes all sites will be forward compatible because it's in the interest of the browser maker to ensure their browser works on as many sites as possible. Forward compatibility is very different in the software/OS world.. . perfect example is Apple with OS X.

Is that where you are drawing a comparison? I don't see the issue so much with web pages. You make code today, it will work 5 years from now because the newest browser will be at least as capable as yesterdays browser. Is that a reason not to create standards compliant code? txt is about as forward compatible as you can get mind you...

login or register to post comments

Standards are about respect

Submitted by jt2190 on April 14, 2003 - 19:39.

Think of a Web standard as a standard contract between the page author and the browser programmer, one that respects the rights of both parties. The page author agrees to write markup that adheres to the standard, and the browser programmer agrees to display the document acordingingly. The page author doesn't have to tailor markup for any particular browser, and the browser programmer doesn't have to write lots of extra code to handle poor markup. It's win-win.

We also have other contracts we can follow when authoring our pages, which unfortunately deliver most of the benefits to the browser programmer, and few (if any) to the page author. The browser programmer agrees to respect our use of tables for markup and all sorts of fun HTML hacks, yet makes no guarantee that other browsers witll do the same. We get to write lots and lots of extra code, over and over and over again. We get to sniff for different browsers, code around the quirky or broken browser behaviour, waste our time and our money, while the browser programmers write their extra code once, leave the office and take a three-year vacation, perhaps fixing a bug or two every once in a while. Oh, and by the way, that bug fix they just submitted breaks all of the pages you've written (hacked) to date, so you'd better get out there and fix 'em quick!

I'll take Web standards any day.

login or register to post comments

Re: Standards are about respect

Submitted by ppk on April 14, 2003 - 21:52.

Think of a Web standard as a standard contract between the page author and the browser programmer, one that respects the rights of both parties.

Oh, nonsense. This is exactly the sort of viewpoint I'd like to remove entirely from the discussion.

Web standards are just a bunch of rules and tools, to be used when they are useful and to be discarded when they aren't. We could disagree if a certain standard is useful or useless and discuss the matter at great length, but all this emotional stuff around them just confuses the issue and doesn't help anyone in the end.

login or register to post comments

Re: wait a minute

Submitted by ppk on April 15, 2003 - 03:14.

>So let's treat forward compatibility and web standards as two different concepts, to be studied and pursued separately.

Maybe I am missing something but.. if more sites followed standards than more browsers would be standards compliant, no? Yes all sites will be forward compatible because it's in the interest of the browser maker to ensure their browser works on as many sites as possible..

No, I disagree. To ensure that as many sites as possible work in your browser, you have to be backward compatible. And even if all new sites would follow the standards strictly, the browser would still have to be backward compatible because of all the old sites.

Forward compatibility is very different in the software/OS world.. . perfect example is Apple with OS X

Yes, that's true. I'm purely talking about client side coding in websites here. I don't know anything about software development.

Is that where you are drawing a comparison? I don't see the issue so much with web pages. You make code today, it will work 5 years from now because the newest browser will be at least as capable as yesterdays browser. Is that a reason not to create standards compliant code? txt is about as forward compatible as you can get mind you...

It's no reason not to use standards, certainly. However, it does not require you to use standards, either.

login or register to post comments

Re: You cannot prove anything about the future...

Submitted by ppk on April 15, 2003 - 03:16.

...but you can identify trends.

Hmmm.. you quote some nice examples against my theory. I must admit I don't have an answer immediately. I could say that the ancient practices you describe are dirty in the extreme, but some will certainly see non-standard code in the same light.

Well, you gave me plenty to think about.

login or register to post comments

The current standard is a raw deal

Submitted by jt2190 on April 15, 2003 - 05:55.

Web standards are just a bunch of rules and tools, to be used when they are useful and to be discarded when they aren't.

What you're failing to grasp is that there is a standard, whether it's formally defined by the W3C or by a bunch of browsers that happen to dominate the market at the present time. You can never discard this standard. For example, I can author all of my HTML to adhere strictly to HTML 4.01, but since the de facto standard is quite different, I either have to limit myself to a subset of HTML which I know is supported, or accept the fact that some of what I author won't work.

Fine, you say. That's the price you pay for not using the de facto standard.

So many of us do use the de facto standard. We author pages that are much more complicated. We author pages that take longer to download. We implement error-prone browser-sniffers to "fix" our HTML for different browsers. We scramble whenever a new browser is released, because there is no guarantee that our pages will work anymore. We waste hours and hours making sure that our pages work in different browsers. In short, we pay the price.

So what I want to know is, what do the browser programmers provide me in return for spending all of this extra time and effort?

login or register to post comments

Imposed standards vs. evolved standards...

Submitted by djr on April 15, 2003 - 10:06.

What a great article.

Warning: I look at this from a bit of a curmudgeon's viewpoint. Until I discovered C, my favorite programming language was solder.... Up until now I've done mostly tag soup (great descriptive term btw) because there really hasn't been enough consistent support for the standards in the browsers people were using... Also, this is my first message on evolt so please be kind... :-)

Evolved Standards

My read of the history of some of the standards I've known and loved is that they break into two sets. What makes the ANSI C standard so great for example, is that it evolved out of common techniques used among people who were just trying to do their craft. This was fine back in the halcyon days of computing because there was no money in it. Those who were there were there because they loved it. Consensus was built around what worked and what didn't, not around who's face needed saving or which company's customer lock-in plan had the best chance.

Imposed Standards

In the context of browser-based applications, imposed standards are absolutely required because the halcyon days of the World Wide Web ended precisely when Tim Berners-Lee released the browser code. These standards don't have time to evolve in low pressure, so somebody has to take on the Herculean task of actually designing how everything "should" work. As imposed standards go I think the W3C has done an excellent job (remember ISO-OSI).

Better still, the market is working in favor of giving these imposed standards a little "evolution time" since the browser makers struggle to insure their wares are as compatible with existing content as possible. This might lead to a true consensus among those who practice the craft. It will probably be something a bit different than the W3C's nearly perfect effort. Based on what they've already done, I'm guessing they'll be smart enough to roll with it.

djr

P.S. Would an <em> by any other name still smelleth slanted?

<sigh> a bit long... sorry.

login or register to post comments

Re: The current standard is a raw deal

Submitted by ppk on April 15, 2003 - 23:26.

>Web standards are just a bunch of rules and tools, to be used when they are useful and to be discarded when they aren't.

What you're failing to grasp is that there is a standard, whether it's formally defined by the W3C or by a bunch of browsers that happen to dominate the market at the present time.

That's true, but I'm only talking about the official W3C standard here. The theory is that coding to this specific standard will solve all your problems now and in the future. This may be true, but it's not proven.

So what I want to know is, what do the browser programmers provide me in return for spending all of this extra time and effort?

Exposure of your web page to the users of that browser, of course.

login or register to post comments

Some more reactions

Submitted by ppk on April 17, 2003 - 00:12.

I was pleased to note that this article has generated a modest amount of reactions on the Web, even though it probably isn't one of my best.

Generally in favour:
mezzoblue (which is the site of dshea who also commented on this page) and asterisk*.

Doubters include:
Zeldman, Accessify and dandruff.

But there are no hostile reactions (at least, I didn't find them). People are at least willing to consider the idea set forth article, even if they don't agree. And that's the best I can ask for.

login or register to post comments

Standards

Submitted by shifter on April 17, 2003 - 09:23.

Just code to standards so we can all move on. Really, standards are the best way. Look at devedge.netscape for reasons. ESPN saves more bandwidth than you could every imagine. on and on..... They'll solve all your problems. Soon it will be as easy as waking up, wait sleeping.

login or register to post comments

Standards never ensure forward compatability

Submitted by loubrothers on April 17, 2003 - 17:50.

One cannot measure the compatability of code written to today's standards in future browsers - but one can see that coding to the standards of the past - be it de facto standards or W3C standards - can break in current browsers. Witness even the quirks mode of the Gecko engine - code written to standards can break. One cannot ensure compliance with even current browsers by coding to the current standards due to poor implementations or vagaries in the specifications.

But one can create a leaner code with greater maintainability by coding to standards and one can eliminate a great variety of problems now and in the future by coding to standards - however one must be aware of various incompatabilities as they arise becuase browser manufacturers aren't perfect and standards aren't necessarily as precise as they need to be.

Browsers will continue to support tag soup because they can't afford not to - but you'll likely see greater rendering speed in the client for code that does conform to standards. Gecko actually has great speed benefits to those who's code is rendered by the XML engine rather than the HTML engine.

But I'm getting away from the point. One cannot simply code to standards and walk away assuming that all future browsers will support standards - clearly new and different devices don't necessarily support the standards the way we'd like them to (witness HipTop's non-identification of itself as a small screen device for CSS serving purposes). But one can reap great benefits from standards, increased maintainability, and rendering speed among others - but one must be vigilant of the problems created by new browsers and adapt as necessary.

On the web, as is true most other places, there is no absolute answer.

login or register to post comments

It's that simple, is it?

Submitted by dshea on April 17, 2003 - 18:20.

Shifter, I hope you are not serious. It's that sort of fanboy attitude that makes this (actually very important) argument seem like another tech-related holy war. We need standards dogma about as much as we need more fat in our diets. Let's leave the zealotry to the Linux geeks, and be a bit more professional about this issue, okay?

I followed the link in your profile and loaded your resume. It doesn't appear to me that you've actually done a lot of commercial development, aside from a couple of sites here and there. I've lost track of the number of individual projects I've worked on over the course of the past 5 years, but it's probably a few hundred. In my experience, I've learned that you have to cater to the lowest common denominator. I still code for NN4.x. It's required by my employer. Believe me, I've tried to change that, but this is the funny thing about business. If 2 or 3% of a site's users can't use it, then that means you've just lost 2 or 3% of your potential customer base. For sites pulling in tens of thousands of dollars a month, that can add up to a few grand. Which can more than pay for my time testing broken old code in NN4.x. The bottom line says that I must still code for these people.

I'm on your side. I want for us to be able to drop tables and ugly hacks as much as you do, but it's just not always practical. Telling me that standards "will solve all my problems" is just plain naive.

(by the way - after struggling with IE5's broken box model, I'm not inclined to think that going the standards route makes all my problems go away anyway. I just run into new ones. See the danger in making a blanket statement like that?)

login or register to post comments

dshea comment

Submitted by xyzbytes on April 18, 2003 - 10:22.

I agree with dshea, but I also feel that standards are important, not only with browser code but with web code. The point that dshea makes is a good one. I am redesigning 3 web sites right now and one indicator(web site statistic) I look at is what the "our" customers are using for a browser and OS platform. This provides a base for me. We are a non-profit public entity so I must try to adhere to accessibilty standards for screen readers, vision and color issues, etc. Part of my design ethic is to ensure that the pages display or render correctly in browsers down to NN4.X or I.E.5. This means they will load properly but the layout may not look the same. And by the way, our stats indicate that 8% of our users are utitlizing these older browsers. I have the our customers major browsers loaded on my PC for testing and that is as far as I take it. I am going to be using CSS for layout and tables for dynamic database content. I will also be utilizing other technologies(Flash, DHTML,etc) but the pages main structure will still render itself. I also agree that I would not spend hours and hours on hacks and tweaking code to try and conform to all the standards. My boss wouldn't stand for that! No matter what you do there will always be issues. And so it goes......

login or register to post comments

forwards compatibility and non-standard code

Submitted by Seb on May 1, 2003 - 08:06.

Here's something interesting about making presentation forwards-compatible.

You can't.

Forwards-compatibility is a phrase that gets bandied about a lot in the programming world. Generally it's used by marketing departments who want to convince you that what you're working on now will continue to work with the next iteration of their product, so that you have a buffer period before being sucked into the next upgrade cycle. Forwards compatibility only makes sense when the next iteration of a product is made to be backwards-compatible with previous versions of itself.

Forwards compatibility is therefore nothing more than a guess, a hedged bet that can only be gauged in retrospect.

You could make the assumption that creating tag soup markup is safe for a while, because there are a large number of sites that employ it. That's not making something future-proof, that is a basic lack of innovation through inertia, and does nothing to help a situation that has come close to spiralling out of control.

Various organisation have tried to take credit for bringing browser vendors back into line with standards, and are happily declaring a partial victory as more and more vendors produce browsers that come close to meeting standards compliance. In truth, the catalyst for this remarkable change has been XML.

XML is one of the few markup languages that meets the vague definition of forwards compatibility in a manner that is truly independent of the implementation layer.

Wondering where I'm going with this?

Well, HTML as a markup language is moving towards the end of its useful lifetime. Whilst many developers still think in terms of delivering an HTML site to a specific set of browsers, a great deal of efficiency can be found in moving away from implementation and platform specific markup towards total separation of the presentation layer. Forwards compatibility cannot be achieved by simply restricting the web to a small set of browsers' features, it can only be achieved by making the choice of browser irrelevant.

When the browser is no longer a consideration, then your site is no longer constraind by concerns such as "will Microsoft still support my marquee tags in IE7?" You can then develop individual presentation layers for your target platforms with a minimum of effort. As more and more browsers begin to support a larger subset of available presentation standards, then you can begin to consolidate your presentation, but you're not limiting yourself to "IE5/NN4.7 and above as long as they support multiple nested tables".

Forwards compatibility is something you can hope for, but you'll only find out when it's too late, and that could be as soon as then next browser revision.

login or register to post comments

More thoughts

Submitted by jim.dabell on May 1, 2003 - 08:58.

ppk,

No, I disagree. To ensure that as many sites as possible work in your browser, you have to be backward compatible. And even if all new sites would follow the standards strictly, the browser would still have to be backward compatible because of all the old sites.

That's what deprecation is for. The W3C marks elements like <font> as deprecated, authors know not to use them, and a couple of years down the line, browser vendors don't have to support that element and all the nasty workarounds involved with supporting it in the way that authors expect.

Except nobody took notice of the W3C - not developers making HTML-generating tools, not authors of HTML documents, and not the browser vendors. And here we are five years down the line, still having to support this stupid element. Maybe if people took a little more notice of the W3C, the web would be a better place.

I think this is partly why they made the "no guessing at malformed code" rule in XML. People only listen to the W3C when they get shiny new features. The W3C are trying to tie garbage disposal to the new features, because otherwise people are going to carry on writing cruft left right and centre.

btw, I like how you followed up your article with links to other opinions.

djr,

Up until now I've done mostly tag soup (great descriptive term btw) because there really hasn't been enough consistent support for the standards in the browsers people were using...

I can't think of a single instance where tag soup is better supported than valid code*. "Tag soup" originally referred to junk code that didn't form a tree; lately I've been seeing a lot of people use it as a synonym for code they don't like.

What you say about limiting yourself to a subset of the specification for compatibility is true; however this still results in valid code. It doesn't matter if you avoid certain elements or CSS properties, you are still writing valid code.

* Actually, I have just thought of one; shorttag syntax, where you can write <strong>foo</strong> as <strong/foo/ - virtually nobody has even heard of this though.

shifter,

Look at devedge.netscape for reasons. ESPN saves more bandwidth than you could every imagine.

You are confusing authoring against certain specifications with separating content and presentation. I don't know where this idea came from, but loads of people think that simply referencing a CSS file automagically makes your website standards-compliant. It doesn't.

login or register to post comments

More thoughts 2

Submitted by jim.dabell on May 1, 2003 - 09:01.

Trouble with £ when typed in literally, not sure if it's Konqueror misbehaving or evolt.

dshea,

His experience is irrelevent, if you are going to disagree with him, do so by attacking his statements with reason, not by saying "I have more experience than you, so what I say is the Truth(tm)".

Deciding whether or not to go with table layout or css layout is a complex decision, and you can't simply say "well 2% of our visitors won't like it, and that means we'll be losing £x000". What proportion of those people are converted into clients? People with older browsers are probably less comfortable with the web as a group than people with up-to-date browsers - and are therefore probably less likely to be comfortable buying something online.

How much will they not like it? Will it lose all of your sales for this group? Half? None? The way a site looks contributes to its credibility, but how many people would be put off from using your site altogether by this?

What benefits does the new layout bring? If your developers are going to be spending twice the amount of time maintaining the code, you need to weight their salaries (and related costs) against the amount of money you will be losing from the old browser group. What about cost savings in bandwidth? What about the new features you can create with CSS and all that extra developer time? What about the increase in accessibility/usability?

You make it sound like it's a case of developer code aesthetics being valued higher than the revenue that 2% of visitors brings in. That's overly simplistic.

I have thought a bit more about the original article. I have one thing to add - following the specifications is not a guaranteed fix for forwards-compatibility - it's just that your chances are far better. When that is not an option, and you have to convert to a new format, what would you rather work with? Documents that follows an open, published specification, or documents that only mean something in relation to multiple, closed-source applications? Which choice allows for the possibility of a tool automatically updating them correctly?

Or, to change the viewpoint, five years down the line and you are offering your consulting services for updating websites to the new format - aren't you going to charge more money for fixing up the cruft that gives you headaches? So, as a business today, wouldn't you rather save that money by doing things right now (for free)?

login or register to post comments

Never Did Tag Soup

Submitted by avatraxiom on May 9, 2003 - 16:57.

First, I'd like to say that this is a great article.

I am in an interesting position as a web developer, because I learned to write HTML only a short while ago, so I never learned the tag-soup method of coding. I entered a world where modern browsers were developed enough that, with a few small hacks here and there, standards-compliant code actually worked. (And degraded gracefully in older browsers, if written correctly.)

I come from the world of professional code development, writing in langauges like Java or C. I can't imagine having to write in that tag-soup way, with the font tags and the nested tables. What CSS gives me is a logical way of coding, and it gives me the modularity that I need to even begin thinking about coding. If somebody denied me the modularity of CSS, I'd probably sit around and cry for a bit, and then stare wildly at my computer, thinking frantically about how I was going to keep my code sensible and professional without the wonders of standards-compliant CSS.

A lot of people have told me that it's more difficult to code in a standards-compliant way. That it takes more time. Or that the learning curve is too steep. The interesting thing is, it only took me about a month to become proficient at HTML 4.01 Strict, and three months to become a CSS expert. After that short time, I was actually completely shocked to find that I knew more about how CSS behaved than many, many other people. (Most particularly, as far as how it behaves in Mozilla, I'm probably almost a guru.) In comparision, it took most web developers I know years to reach a similar level of proficiency with the tag-soup nested-tables method of coding. Basically, I think that it's because most presentation features are easier to implement (particularly if we're talking about cross-browser implementation) with the correct CSS. (Of course, the wrong CSS only makes this more difficult, leading to a lot of frustration and debate on this issue.)

So I can promise you, from where I sit, that forwards-compatibility, though it's more likely with standards-compliant code, isn't the real reason that I love my Strict DOCTYPE. With standards compliance, my code is easier to implement, simpler, more readable, and modular. In the world of professional application development, almost everybody would agree that these are factors which reduce development time and development costs, while simultaneously improving the shipped product.

It is okay to code in tag-soup, if it works for you and you get paid for it. And if it continues to work in the future, then excellent! I like pages that work and make people happy. There's nothing wrong with that!

But if you can get through the learning curve that standards-compliance requires, then you might find that your job is easier once you come out the other end. I think that's the only reason that I would push standards-compliance. Because I like you, and it would make me happy to make your life easier to live.

-M

login or register to post comments

You don't code tag soup

Submitted by prowsej on May 9, 2003 - 17:09.

You didn't code tag soup, avatraxiom, so I'm not sure that you understand the way a lot of people coded. I still used logical structures when I had a tag soup. I would have a tag like lgt;headingA> that would be read by my server and converted into <font size="2" color="red"><b><i>. Using font tags with the appropriate server-side backup can be just as logical and well-formed as using CSS. The trade-off is between the low bandwidth of CSS and the compatibility of approaches <font> tags and <table> layouts. At least that's my experience.

login or register to post comments

Re: You don't code tag soup

Submitted by avatraxiom on May 9, 2003 - 18:37.

prowsej: Using font tags with the appropriate server-side backup can be just as logical and well-formed as using CSS.

That's an interesting point. In a lot of ways, I also use scripting languages to augment my code, so standards-compliance hasn't changed that, I suppose. After all, it's pretty tough to make a (frameless) page layout appear on every page without some sort of scripting language (even at least [X]SSI).

I suppose the nice thing about the standards-compliance in that area is that it minimizes the amount that we have to create our own standards. In the end, if everybody in the company understands the custom standards that you come up with together, then there isn't a problem, except when it comes to training new employees.

The other nice thing is that when standards are developed by a central body, or by a group with lots of experience, there's some guarantee that they'll be better. It's similar to the libraries supplied with a programming language. Take Java, for instance. It's probably better to use the java.math library than to write your own logarithm functions, just simply because they'll probably spend more time on making it good. Theoretically (although it's possible that our standards work a little differently) the W3C standards are going to end up being nicer than the ones we evolve ourselves. And we don't have to spend any time evolving them. :-)

And, it would be nice to move presentation out of the hands of the sever-side scripting, since I just feel like that's a funny place for it to be.

-M

login or register to post comments

Point taken

Submitted by notabene on May 14, 2003 - 05:47.

OK ppk, you got me thinking...

But there are no hostile reactions (at least, I didn't find them). People are at least willing to consider the idea set forth article, even if they don't agree. And that's the best I can ask for.

Yet I can't see how my coding practices would have to change, according to this point of view. Your point, basically, is just to say "don't mix standards and forward-compatibility", right?

But as Seb and jim.dabell said: standards will help, won't they?

login or register to post comments

too long again...

Submitted by djr on May 14, 2003 - 13:59.

re: "Tag soup" originally referred to junk code that didn't form a tree

Perhaps "tag soup" isn't such a great descriptive term after all :). When I saw it I intuitively thought of the practice of inserting whatever formatter tag is needed right at the point in the document where the text needs formatting. On the other hand, it could be the case that our two views of the term are the same, but you're associating it with the effect it has on a document's structure, while I'm associating it with the practice that gets you that effect. For just plain bad code or markup (like pornography, you know it when you see it), I prefer the term spaghetti.

I'm not really sure what you mean by: Haven't found a single instance of where tag soup was better supported than valid code. To this day I often try to modernize my pages by replacing older tag-on-the-spot methods with CSS constructs, and end up having to back those changes out. This is required sometimes because of NS4.x, and sometimes because one of the newer browsers chokes on it (what is so difficult about height).

. . . . . . .
Flame regarding NS4.x : if they're not going to upgrade support for standards they should stop upgrading it altogether. Many users think that downloading the latest NS4.x upgrade gets them the latest standards support, so they just keep on using it. Extinction is as much a part of the grand scheme as birth.

In theory there is no difference between theory and practice, in practice there is. I'll admit, when a committee actually gets a group of people who's only agenda is doing good standards, it can be magical. This isn't often the case though. Companies who send representatives often have very specific agendas, which are more closely related to the marketing department than the development group. Other times nationalism, and even school spirit gets in the way.

The redesign of the Netscape Devedge site is cool. As someone coming from the "old way", I find it very helpful and inspiring to see sites that are doing the right thing and using well written markup. I like the devedge site because it shows how I can turn my spaghetti into decent markup and still do much of what I want with a page. Btw, sites that boast of being standards compliant while using flash (a single-sourced proprietary technology) to do the basic navigation are counter productive in this regard.

Articles like this are also hard to read.

-djr

login or register to post comments

The Truth About The Standards Mafia Scam

Submitted by daTerminator on July 26, 2003 - 12:01.

the overwhelming majority of big time corporate lawyers agree that these 'standards/accessibility' mafia scammers are totally misinterpreting 'section 508', which is an illegal regulation that exceeds its enabling statute, which has a lot of safe havens and exceptions, and which does not say what these standards/accessibility' mafia scammers say it says.

indeed, NO major govt agency website 'validates':

1. IRS
2. SEC
3. FBI
4. Library of Congress
5. U.S. House of Representatives
6. U.S. Senate
7. U.S. Supreme Court
8. U.S. EEOC

In fact, Microsoft is laughing all the way to the bank:

'The Department of Homeland Security has awarded Microsoft a five-year, $90 million contract to provide desktop and server software. The agreement, which will be managed by Dell Computer, will cover 140,000 desktops.'

it's pretty pathetic that these 'standards/accessibility' mafia scammers are in reality one or more of the following:

1. ex-employees of anti-Microsoft companies who are now jobless because they didn't bring $ to their employers
2. soon-to-be jobless ex-employees of failing anti-Microsoft companies that can't compete and don't bring $ to their shareholders
3. anti-Microsoft losers schilling out lame 'webdesign skills' to 'update' websites that they themselves 'designed' so badly in the first place
4. anti-Microsoft losers schilling out lame 'webdesign' books with spam banner ads on their and their lemming followers' lame looking websites
5. anti-Microsoft losers schilling out lame 'validators' and knowingly and falsely misrepresenting bureaucratic regs
6. anti-Microsoft 'the sky is falling' chicken little losers who can't code and are envious of those of us who can
7. anti-Microsoft 'open sourcers' who say they have more eyes to fix bugs yet who are blind to the fact that the quality of programmers not quantity is what counts, and who, after all these years still can't give away their free buggy browsers because crappy code simply can't compete in the marketplace

'standards/accessibility' mafia scammers 'talk the talk' but when it comes right down to it they really don't care about free choice or free speech, much less the rights of the poor oppressed + downtrodden disabled amongst us. they're just there to force us to waste our precious time + $ -- not for the benefit of handicapped people -- but for downloading/buying their buggy 'browsers'/crappy 'code'/boring 'books'/vacuous 'validators'/etc.

login or register to post comments

Ironic

Submitted by djr on July 26, 2003 - 17:10.

Hi D.T. Don't hold back now. Tell us how you really feel. :-)

login or register to post comments

Total Scam

Submitted by avatraxiom on July 26, 2003 - 17:59.

You must be right.

ANSI C was a scam, too.

Oh, and POSIX, too.

Damn standards.

Also, your list of "who is a standards pusher" excludes Tantek Çelik.

But really, how do you feel? :-) (I do appreciate hearing your opinion, by the way. It's interesting.)

-M

login or register to post comments

L'inegalit&eacute; des &laquo;standards&raquo;

Submitted by pierreluc on July 26, 2003 - 21:42.

Salut! Moi aussi, je crois que les «standards» véhiculent un message haineux, des propos racistes et sexistes, et ne tolèrent pas la diversité

Si toutes les personnes inscrites sur un site parleraient la même langue ou s’habilleraient les même vêtements, nous devenirions plus pauvres.

Grâce à Dieu, cette discrimination et inegalité sont interdites par, inter alia, la législation Française (e.g., loi du 6 janvier 1978) et par les articles 11, 12, 13, 20, 21, 22, 23, et 26 de la Charte des droits fondamentaux de l’Union européenne.

Voici, par exemple, les «validators» du w3c prônant la supériorité d’anglais sur les autres langues — particulièrement le français:

Mes soeurs et mes frères francophones, nous devons écrire les courriels aux autorités compétentes et d’entraîner des poursuites judiciaires au sujet de ces insultes immorales et illégales à nous.

login or register to post comments

Standards are just like java

Submitted by NTakeuchi on July 27, 2003 - 11:12.

First off, doesn’ t evolt know that contrary to its “style guide,” the W3C has deprecated the target attribute and that you now have to use the W3C’s eminently superior and simpler official solution (the XHTML Target Module (a reformulation of HTML as a modular XML application. Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.)) instead?

Oh the hypocrisy! This is just like “At W3C, few practice what they preach,” where “Members of the Web’ s leading standards consortium are leading by fiat, not example.”

Web standards are just like java: “write once, run best in Windows,” as the following excerpts prove beyond reasonable doubt:

The Fidelity Investments web site has only sporadically passed the Mac-friendly test...I presently find it impossible to use Safari to pay bills because the site replies that the dates entered are not valid. This is presumably a Java problem...

Java performance is weak, and many sites that rely on it are unusable with Safari. Finally, graphic performance is less than desired, especially if you adjust font size from the default. Just try viewing ESPN.com with Safari and you’ ll find content obscured by different panels or very difficult to read.

Attempting bank access, at a site using pure Sun Java according to their tech support people, Safari passes the password check, but unceremoniously crashes and departs a second or two later.

I’ ve tried moving to Safari this week but it has been quite frustrating. Large areas of popular sites such as United.com, Travelocity.com, Sunset.com and many, many more simply won’ t work with Safari In some cases it is redirects to new pages that do not work, other times it is various java elements and other times it is trying to do things in a secure environment with an address starting with https:www...

Does anyone see the comedic irony when mac people can’ t access real estate MLS sites or bank websites that use java and are told they need to get a Windows PC instead? Heh heh. Even java programmers admit that java performance on Windows is superior to that on other platforms. Blaming the compiler/interpreter/VM/Bill Gates is just a lame excuse that java sucks.

Minor css “problems,” which are not confined to and rarely — if ever — occur in IE/Win, are just red herrings as they are merely presentation and not content problems. IE/Win may not be perfect, but it displays both content and presentation far more robustly than other browsers. Again, one need only “follow the evidence” that people really don’ t care about some minor css centreing “problem”:

I have to agree with Clint McIntosh’s remarks about IE on the Mac. My wife is a real estate agent, and the MLS database she uses (used by tens of thousands of agents in the U.S.) only works with IE. It does not work with Netscape or iCab.

On June 8th, practically coinciding with Microsoft’ s announcement dropping support for IE for the Mac, the greater Seattle Northwest Multiple Listing Service (NWMLS) released an update to the user interface for the Northwest MLS web site. ... Suddenly we found that none of our Macs could properly function on the system. ... I received the following reply: ‘thanks for contacting NWMLS. The MLS industry is being programmed against the browser that is being used by 94%+ of the world and even greater percentage of real-estate agents, that being Internet Explorer’

My wife is a realtor and the online MLS system she uses is nearly unusable on a Mac (the only saving grace is semi-functionality in IE), and it hurts her business to not be able to search properly while at home.

The bottom line is that if your site fails to work with IE/Win, then you are excluding millions, if not billions, of people, both physically challenged and otherwise. Now that would be a real accessibility problem.

The truth is that the same web “designers” who bitch about “standards” are really projecting what they want, rather than focusing on what users want: the superior standards-compliance of Microsoft IE/Win.

People need to get it in their heads that ultimately the market — not “standards” freaks — will decide. AOL got $750 million from Microsoft and killed netscape. Sun got a mere $20 million, and now java on Windows is dead, C# is the hottest language around, and Sun servers are being killed by cheaper and faster x86 Linux servers, more and more of which will use .NET.

The market doesn’ t care what browsers a bunch of unemployed netscape lusers use. Maybe we’ ll see some protests from the homeless netscape lusers about browsers/standards/css? Now that would definitely be entertaining.

The takeaway: Dude, get a Dell with 100% Microsoft standards compatibility!

login or register to post comments

Re: L'inegalit&eacute; des

Submitted by notabene on July 27, 2003 - 23:30.

Hey Pierre Luc,

I'm not complaining about the French, and I'm not willing to be rude by reminding you that one doesn't say:

Si toutes les personnes inscrites sur un site parleraient la même langue ou s'habilleraient les même vêtements, nous devenirions plus pauvres.

but of course:

Si toutes les personnes inscrites sur un site parlaient la même langue ou s'habillaient avec les mêmes vêtements, nous deviendrions plus pauvres.

It's a matter of badly-applied standards, I'm afraid ;-)

Joke aside, please remember that you're on an english-speaking community site, so respect others by at least providing a translation of your post.. had your email not been hidden I would have spared you the public mention.

login or register to post comments

RE: Standards are just like java

Submitted by Jeff Howden on August 13, 2003 - 09:23.

NTakeuchi,

First off, doesn't evolt know that contrary to its "style guide", the W3C has deprecated the target attribute and that you now have to use the W3C's eminently superior and simpler official solution (the XHTML Target Module (a reformulation of HTML as a modular XML application. Copyright 1998-2001 W3C (MIT, INRIA, Keio), All Rights Reserved.)) instead?

If you'd view the source you'd see that evolt.org is coded to HTML 4.01, not XHTML. Therefore, the target attribute is a perfectly valid attribute for the <a> tag.

Thanks,

.jeff

login or register to post comments

Still deprecated

Submitted by jim.dabell on August 13, 2003 - 09:59.

Jeff,
NTakeuchi is incorrect in that you don't have to use the XHTML Target module (in fact, you can't do so according to spec and have it work in many browsers). However, it is deprecated, in both HTML 4.01 and XHTML 1.0. I'd much rather have "open in new window" die completely, since I know how to open links in a new window for myself, and I often don't want to. However, if they insist on it, something like <a rel="external"... with an appropriate bit of Javascript should do the trick.

login or register to post comments

RE: Still deprecated

Submitted by Jeff Howden on August 13, 2003 - 10:14.

Jim,

"NTakeuchi is incorrect in that you don't have to use the XHTML Target module (in fact, you can't do so according to spec and have it work in many browsers). However, it is deprecated, in both HTML 4.01 and XHTML 1.0...."

The target attribute is not deprecated in HTML 4.01 Have a look for yourself.

Thanks,

.jeff

login or register to post comments

Deprecated is the wrong word

Submitted by jim.dabell on August 13, 2003 - 10:21.

Sorry, my mistake. It's not deprecated, it is in Transitional, but not Strict. Given that Transitional only exists for older documents, and Strict should be used when authoring new content, it amounts to the same thing though.

login or register to post comments

...but hypocrisy is the right word

Submitted by macDude on August 13, 2003 - 14:52.

If you're going to go on about shouting standards then you should use strict and not sitting on the fence transitional, which is like being a religious fundamentalist screaming 'family values' and then finding your daughter a 'little bit pregnant.'

login or register to post comments

Re: ...but hypocrisy is the right word

Submitted by Jeff Howden on August 14, 2003 - 21:26.

Chris,

I can tell by your registration date (ahem, same day as your post) that you haven't been around here very long. As such, you probably aren't aware of how things work around here. We (evolt.org) are not a large corporate entity with tons of paid talent and time on our hands to go crazy keeping things on the cutting edge. Everyone of the people involved in this endeavor are volunteers who have busy lives outside of evolt.org, but still manage to find time to keep giving back here so you can have a place to voice your opinions.

The current design you're looking at now was implemented in December of 2000. I find it hard to believe we've used it for that long. We're actually in the midst of discussions about some major changes to that. Anyway, my point is that based on our audience at the time, it made sense to use HTML 4.01 Transitional. I know it seems like sitting on the fence, but the fact that we publish other authors work, meant that Transitional would still allow us to either validate or come as close to validating as possible. Strict was, well, too strict for what we needed.

So, before you throw around things like "hypocrisy", "sitting on the fence", etc., please take a moment to consider the circumstances.

Thank you,

.jeff

login or register to post comments

Windows CSS + personal site = lame

Submitted by macDude on August 15, 2003 - 13:52.

Only an idiot uses CSS on his personal website to create a "Windows" background. Now that's pretty lame and just sad.

People, quit bitchin and moanin! Make the switch and get Safari 1.0™ NOW!!!!!!!!

login or register to post comments

Mac Zealots + Civil Discussion = Train Wreck

Submitted by DanteCubed on April 30, 2004 - 20:25.

Maybe we can't afford to have both a Windows and Mac box. Only and idiot ruins a decent discussion with garbage like the above. And the ALA forums called ME a troll. I hate the W3C Box Model, and that's the only reason I leave out the DOCTYPE.

login or register to post comments