Fog Creek Software
Discussion Board




.NET vs. Web Standards

Here are my (brief) thoughts. What are yours?

http://www.xyncro.com/opinion07092002.html

Andrew Cherry
Saturday, September 07, 2002

Hey Andrew,

I'm not trying to knock you, but I'm wondering if you do web development? I know if you come from a good programming enviroment the mess html is in can be a bit of a shock, thats what I'm thinking...?

Things work differently in different environments, that is just the reality of today. Different pages for different browsers, versions, os's and devices are very common. One of your biggest headaches as a web developer is to know the bugs and limitations of each. But even without bugs, you end up doing things differently.

Dreamweaver (what I use) will also will target different browsers if that helps...

Robin Debreuil
Saturday, September 07, 2002

I do come from a web development background - originally ColdFusion, as well as some JSP stuff. I'm also a CS Grad, so i've seen programming both structured and unstructerd in various places.

My point is not really about the "state" of the code, i'm quite used to that with almost all large web systems, merely that it seems Microsoft is once again ignoring web standards - and noit ebing too upfront about it either!

Andrew Cherry
Saturday, September 07, 2002

Oh - and i'm a Dreamweaver MX user too - which has made big strides forward...

it's just the fact that the ethos seems so wrong, if you agree with the direction that people like WaSP and the w3c advocate...

Andrew Cherry
Saturday, September 07, 2002

Andrew, having not worked with .NET I tend to agree with your sentiments. I remember sitting in a .NET seminar and having the speaker explain how .NET detected the client's browser and generated the appropriate code. I almost jumped in my chair and "shot the messenger".

I've got my hands dirty with a lot of front-end web issues and I really don't have a great deal of faith in the .NET solution - it seems to be trying to deal with the problem from the wrong perspective.

A significant part of the problem is the ignorance of standards (there has been a lot of feedback from a recent Jeffrey Zeldman article on the topic of web standards - see http://www.zeldman.com/daily/0802d.html#freedomfromfear for more info). Many developers working in the web space don't really seem to understand HTML, even more troubling many web designers don't seem to understand HTML which I believe is just plain wrong.

This is caused in part by the "legacy" of other media which everyone is familiar with. People focus on developing the look as they would in print with a tool like Quark and hope they reach some structure as a consequence of this. But HTML is a language for marking up the structure of the page and the tool is generating HTML. Dreamweaver seems to de-emphasise structure and I think that's a problem.

Web design (and good software design) should be about starting with a solid structure and adding layers on top of that. I wish Dreamweaver (etc) would emphasise this approach although I conceed that providing the tool support to do this would be no small feat. Meanwhile I'll use HomeSite or TextPad.

So, I think Microsoft's solution to this problem is a poor solution. They are addressing the problem by allowing developers to remain ignorant of what they are really doing and I hope that the WaSP in its effort to target tool makers also includes developers of IDEs like VS.NET as well as traditional design tools like Dreamweaver and GoLive.

Walter Rumsby
Saturday, September 07, 2002

Well I agree with both of your setiments, that it would be great if everything was nice and standard, but it can't be unless you stick to making certain types of dcouments.

"Web design (and good software design) should be about starting with a solid structure and adding layers on top of that."

Of course that is true, but does it make sense to use a solid *text document structure* to make software? How about to present marketing information? How about for a web application? A supermarket? A tv program?  'A solid structure' makes it wound like you have a choice of what underlying structure you wish to use with html, but in fact you mean 'THE solid structure'. I think the reason web standards are so abused is they are assuming everyone in the world wants to make a document, which clearly isn't the case. There is an argument that the web should be for text based documents only, gladly it is still a reasonably free world though.

I'm curious if you guys use the same html for low bandwith small screen html devices? If you look in the .net mobile tools you'll find that they too target individual devices. Once you get multiple platforms with significant differences, they best you can do is either generic generic, or target an abstraction and generate code for each platform, hand optimizing for the sweet spots. Unless you know of a third way...

Robin Debreuil
Sunday, September 08, 2002

HTML will hopefully become history pretty soon, and be replaced by CSS and XML. The chaos will then subside.

Eric DeBois
Sunday, September 08, 2002

"Well I agree with both of your setiments, that it would be great if everything was nice and standard, but it can't be unless you stick to making certain types of documents."

Why is that the case? Looking at the examples you give

* a web application
* a supermarket
* a tv program

These designs all have a structure to them.

A web application needs a set of controls to trigger actions, possibly a "help" section, etc. A supermarket needs to provide ways of browsing a catalogue, purchasing items, etc and might provide a function to compare prices/features between products. A tv program (what are you doing using the web as a tv?) needs at least a view port in which to show the show.

Note I'm assuming that you're discussing the examples within the context of the web and the range of available (and to be available) web clients. I realise in the above that I am sometimes talking about functions and not user interface features, but these functions suggest UI features. As another example consider a DHTML game, you'd have a main viewport for the action, score information, maybe the title of the game, a list of keyboard commands (eg. "keypad 4" moves left), etc.

None of this talks about the colours used, the typeface used, the width of the elements, etc - instead the focus is on the structural elements (I think I mislead you when I talked about "solid" structure, my aim was to really say that you need to consider the relationship of the elements on their screen and their purpose(s) before you start considering the appearance of these elements - and this is what designers do, at least subconsciously).

HTML is made up predominantly of tags for structuring documents (lists, code excerpts, blockquotes), but you can use these tags for other uses, you're not restricted to documents. I worked on a document management system that provided a DHTML Windows Explorer-style user interface which included elements such as menu bars, context menus, list views, list items etc all constructed from HTML. You can do it!

The example of designing for small screen devices is interesting.  If you follow a set of guidelines for considering other devices (eg. like the ones at http://diveintoaccessibility.org/ *) your HTML should be structured in such a way that it is more easily viewed on a wide range of devices. You can use a div-based columnar design instead of a table based one and the content should adjust, etc. Design for this consciously, not as a by product of some "evil wizard" (actually, by designing for accessibility, you get the widest possible audience as a by product).

That's more difficult, but no one said that this was going to be easy - the webs' beauty, it's incredible flexibility, also makes it extremely complex.

Standards-based layouts are generally low bandwidth by nature - just structural HTML + CSS. Have a look at this page on my personal site: http://members.optusnet.com.au/~wrumsby/usability/ - it's 12.5k (and it also links to two very good sites demonstrating CSS). Admittedly it's fairly simple and it is a document, but I suspect that it scales down to handheld browsers and in desktop browsers it is nicely formatted (part of the reason it's so simple is that I'm no designer), using significantly less HTML than non-standard approaches - and I closed all my P tags, LI tags, etc.

Well, I have rambled on for quite a bit, but I hope that anyone reading is a bit more convinced of the viability of standards. Anything IS possible with a bit of forethought and an awareness of the limitations. There is a GREAT deal of misconception about what they can and can't do, far too much to cover in a thread. Have a look at

http://www.alistapart.com/
http://www.zeldman.com/
http://www.webstandards.org/
http://www.meyerweb.com/eric/css/edge/
http://devedge.netscape.com/central/css/
http://msdn.microsoft.com/

As a starting point and you'll find a lot of interesting and amazing stuff being done by a lot of people. Anyone generating HTML should look over the HTML 4 standard http://www.w3.org/TR/html401/ and read about elements and attributes just for "revision". When XML "replaces" HTML it will replace it with XHTML which isn't really too far away from HTML - if you could understand the source of my page then you're understanding XHTML (and you're thinking "This is just HTML").


* Joel, you should see if there's a chance the author could include CityDesk in his list of tools.

Walter Rumsby
Sunday, September 08, 2002

Walter, you appear to share my feelings entirely! I'm very unhappy that I can't make VS.NET produce standards compliant, accessible code. I have to use this tool. There's not really any suitable competition. I really hope that it changes for the better, and soon.

I'm glad to see that my concerns are shared by some coders. I'd begun to lose heart after reading the replies to this article: http://www.angrycoder.com/article.aspx?cid=1&y=2002&m=9&d=5 - some of the stupid browser bashing and missing the point hasn't changed for years. 

Andrew Cherry
Sunday, September 08, 2002

"Note I'm assuming that you're discussing the examples within the context of the web and the range of available (and to be available) web clients. "

No! I'm talking about the range of web clients that people are using. Subtle difference, but upgrade your browser or wait till next year isn't an option. Probably that is what you meant, but just to be sure : ). So that means that you may or may not choose to support NS4.7 or IE on a Mac. But you are aware of them.

"...but these functions suggest UI features. As another example consider a DHTML game, you'd have a main viewport for the action, score information, maybe the title of the game, a list of keyboard commands (eg. "keypad 4" moves left), etc. "

Yes, we are often talking about a user interface. Html is a rotten base for a user interface because it it page based, and user interfaces tend not to be. You can avoid this somewhat by using script, but then as you know the DOMs aren't identical, so you better be browser sniffing at least. You can separate all you functionality into javascript classes, and have the interface just target your code's interface, but you still need to accommodate the different dom's at one point.

But you still have a rotten metaphor for a UI. Yes its lousy for TV type applications too - we spent a lot of time producing content for entertainment portals, real networks stuff, and some webTV. The browsers and their structured text base aren't your friend there, which is why almost all media players use there own program now. The ones that don't, as you know, browser sniff and pump different info based on the results.

Let's consider a dhtml game then - you do need a viewport, but what will this viewport be? It will probably be an ax object in IE win, and an embedded object in NS. So what if this object needs to know something like the default font size setting, or communicate (via the browser) with the server? Well that kind of thing gets way different, even with different version of NS, or IE on different platforms. Oh, and lets not forget the binary transfer bugs in Opera. That is before you even get to differences in your plugin with versions and OS's. Eventually you end up with a separated group of logic, and  either a page that sniffs and skips code, or separate pages (which I think is cleaner if you are sure you are getting the right browser/os/device info).

"you need to consider the relationship of the elements on their screen and their purpose(s) before you start considering the appearance of these elements"

Sure, but even before that you need to consider the limitations of html, and how you are going to have to fit your project into a page metaphor, or sniff for target platforms, unless you are just doing something that naturally fits that already.

"I worked on a document management system that provided a DHTML Windows Explorer-style user interface which included elements such as menu bars, context menus, list views, list items etc all constructed from HTML. You can do it!"

You can, but my point isn't that you can't - it is that it isn't a good base, nor does it work as well as you would like for many tasks on the web (such as the above), and you have to browser sniff for most non html tasks. Did you have any browser detection in the above? Kudo's to you if you didn't - in that case I'd love to see it, and if it doesn't refresh the page everytime you click a folder I promise I'll look into it seriously, and thank you even. Could be that it works now, wouldn't that be great!

"If you follow a set of guidelines for considering other devices (eg. like the ones at http://diveintoaccessibility.org/ *) your HTML should be structured in such a way that it is more easily viewed on a wide range of devices."

There are other issues to consider though. For example the cost of downloading a 10k image or even a large page of text for say an IMode user in Japan. Some devices have four lines of text, some have full color 300+ px screens. You can really limit what you put on your www page and go with the lowest common denominator (eg: no images), or you can target your most popular platforms and fail gracefully on the rest.

"That's more difficult, but no one said that this was going to be easy - the webs' beauty, it's incredible flexibility, also makes it extremely complex."

It is complex because 90% of the time its being used for things it wasn't meant to be used for, and the standards are very fuzzy if even defined, in those areas. And there are too many possible viewer scenarios for it to be as universal as it tries to be imo.

"Standards-based layouts are generally low bandwidth by nature - just structural HTML + CSS. Have a look at this page on my personal site: http://members.optusnet.com.au/~wrumsby/usability/ - it's 12.5k "

Well first a nice thing to say - beautiful looking page, you should be a designer if you aren't. Personally that is how I like a web page that just presents text information.

But now a dig (forgive me!), but that is exactly my point. If that is all you are presenting, you should do it just like that. But that isn't an example of a non document page. In fact if that was how everyone was going to present content, why would you even need dreamweaver etc? I wouldn't waste $300 if that is all I had to make, so why try to get them to conform to that kind of thing?

Often I find the biggest proponents of standards tend to spend thier time building pages much like that - structured text, links, sometimes a jpg. They see html as a vehicle for presenting html, which makes sense of course. However those of us that have to present stuff other than structured text (read 'commercial') have no realistic option today other than using html as well. So rather than try to get us to make pages like that (it will never happen because it doesn't solve our problems), why not push for web standards for things like gui's, applications, media etc, and get us off your turf? I assume it will happen soon enough anyway, but it may be a .Net based solution (because they have a very good one) if there isn't a better alternative that comes along. The time to offer alternatives is now, not after someone else's standards take over (as was done with the web).

Anyhoo, I can spout too eh? : )

Cheers,
Robin

Robin Debreuil
Monday, September 09, 2002

Ah Robin,

Yes yes you can.

// --------

Firstly, some initial notes on the DHTML app. When I started work on it, early 1999, we had a requirement to support Netscape 4 and Internet Explorer 4. I stumbled across DynLayer, which has evolved into DynAPI http://dynapi.sourceforge.net/dynapi/

I haven't looked at the recent versions of the API, but the version we saw then provided the inspiration for what we developed. We wrote a function/class that did the sniffing ( if ( document.layers ) then it's Netscape 4, if ( document.all ) then it's IE). Then we wrote one or two more functions/classes that used the sniff to work out which API to call under the hood when we called a generic wrapper class. These wrappers did basic things like positioning, modifying content, setting dimensions, toggling visibility etc. From there we build menus, folder icons, file icons, etc with our own DynLayer-esque objects. The browser differences were really sweetly encapsulated out of harms way (barring the odd Netscape 4 nightmare).

The nice thing about the sniffer is that it detected the browser capabilities via JavaScript, ie. "do you expose this object?", and that kind of client side sniffing is a lot nicer than the server side sniffing which seems to try to parse the browser ID string.

Sadly the company developing the product is no more and the product itself is no more (dot com bomb + poor marketing of the product), but we were very proud of what we achieved at the time - we'd see similar products at trade shows and delight in watching the vendors squirm when we asked to see it run in Netscape 4.

These days you can rely on IE and Mozilla for DOM1 support. Sure IE provides some nice convenience methods/properties like innerText, but it also supports swapping, adding, deleteing nodes DOM-style. Given that you could combine support for DOM browsers with version 4 browsers, and I guess that's what the current DynAPI does.

It DOES/DID refresh when you opened files. But because the HTML was lightweigh this was quick. Trying to build BIG lists doesn't work because JavaScript engines don't seem to be as highly optimised as HTML rendering engines. I worked on a project that tried to create a HUGE hierarchical list and it wasn't really practical. But...

// --------

...something which you raise several times is how lousy HTML is for non page-based applications. I totally agree! Different media types having their own players is totally acceptable - the web browser should be the text/html, text/css, text/javascript "browser" and something else should handle richer media (and W3 are developing standards like SVG and SMIL for vector graphics and multimedia).

I don't see this as a problem, I see the problem lying with the attempts to tv-ify/radio-ify/toaster-ify web pages. My perception of the web as a medium is that it is really good for:

- interactive communication (this kind of forum, email)
- non-broadcast style communication

It's kind of the opposite of tv, print, radio, but because we/marketing folks/publishers are familar with those media we/they try to make the web more like those media rather than understand them (and the whole abuse of the term "interactive" really irks me - "look a push button: it's interactive!" - yet it's not building understanding and adding value to the content the way this conversation is [perhaps] to Joel's site, it's not changing based on my input in any really valueable way).

Many sites/site owners would do well to question why they have a web presence and think about how they can provide a different view on what their company does online, as opposed to trying to replicate their offline presence.

Newspapers and magazines are much more pleasant to read in printed form than online. Video online is practically impossible for those without broadband.

Sites that focus on issues/topics not covered in traditional media tend to be the well received precisely because their content is not available in a more usable form (drum'n bass arena has one best music business site in the UK at least once in recent years - not bad for an "underground" form of dance music; Australian heavy metal store metalshop.com.au does well, I believe, precisely because there are few outlets for metalheads on radio or tv).

Along the same lines, supposedly Amazon's sales for books and CDs are the inverse of traditional stores (traditional book stores sell predominately Bryce Courtney-style best sellers, traditional CD stores sell predominately new releases - Amazon sells larger volumes of back catalogue CDs and specialist books).

The web is different, embrace that difference!

// --------

What I really like about the W3 standards from a developer perspective is how well they relate to one another.

Know the DOM? Then you know the API for manipulating web pages with JavaScript AND the API for manipulating XML documents (in Java, C#, whatever language too!).

Know XML? Then you know how to markup SVG content.

Know CSS? Then you understand why HTML should contain structural elements only, not presentational elements.

Etc.

// --------

I guess what it comes down to is that perhaps you and I look at the web in a different way. You clearly have a very good knowledge of the web, building for it and issues with browser. That's great, I wish there were more people like you (and of course like me) working in the web because you are able to provide an informed opinion about implementation issues and how well different approaches work. 

Back to work now.

Walter Rumsby
Monday, September 09, 2002

Don't forget that you can write your own server controls that will output the HTML that YOU write. Your complaints seem to stem from a dislike of the prepackaged server controls that come with the framework.

Don't like it? Do it yourself.

That doesn't mean that I'm not a little disappointed by some of the simple things that they overlooked, let alone some of the major faux pas in their HTML...

J.P. Rhea
Tuesday, September 10, 2002

This argument seems to be mostly hearsay at the moment.

I'm using .NET, so if it produces non-complient HTML, I want to know about it, but I don't want to hear rumour and generalisms, I want to know specifically what it's doing wrong.

Why is it wrong with producing different code for different browsers? If it will let me produce clunky old code that works on NS4, while at the same time producing nice shiney DOM/CSS2 code for modern browsers, then I would be very happy.

I think we need to get away from having to have precise control over every tag that's sent to the browser, much like the pixel-mongers and flash-weavers must give up trying to take total control of every pixel on the page.

Don't get me wrong, I want my site to comply with standards, but I think allowing the web server to transparently generate code for older browsers is a good goal.

James

James Shields
Tuesday, September 10, 2002

With regard to serving multiple pages, i'll admit that there's a question of personal taste - to me it seems kludgy, to others it seems an obvious solution. I could argue for hours, but there wouldn't be much point. However - you say it's hearsay - OK. Concrete example. When you use a Web Control, the javascript code that's tied to it at runtime uses a non-standard tag declaration. Should be type=text/javascript (something like that), but it's not. Simple. But they got it wrong, seemingly.

There are many other points, and while I can accept (just) the mentality of producing non-standard code for old browsers, i'm not happy that it won't/can't for new ones. Especially as it detects Netscape 6+ as downLevel - eg. same as Netscape 4. So it gives it font tags, etc.

I could go on. But I won't. On another note - yes I could write my own server side controls. But surely they could have made the default ones work properly? I don't WANT to have to write a standards compliant button control! I want the one I paid for to work properly (by w3 definition!).

Andrew Cherry
Tuesday, September 10, 2002

The problem is that it doesn't send compliant code to the most compliant browsers out there that aren't called "Internet Explorer" - this is not FUD/hearsay, it's an issue Microsoft have conceeded and are going to resolve in 1.1.

There has been a standards approved way to tell your browser how to render things for a long time - using a DOCTYPE. The .NET technique is addressing the problem from the wrong end - are they going to have to add each different browser for every language on every platform? They might as well have a server control that keeps the name of every person, and constantly update their name and phone numbers too - it's an equally futile exercise.

Furthermore, the .NET technique is encouraging developers not to understand what they are doing, in the same way RAD tools encourge developers not to seperate their code cleanly.

If you're producing a DOM-based page no amount of .NET-style degrading "gracefully" will help your Netscape 4 users. If you're using CSS2 then you should be using HTML properly (ie. to define page structure) and Netscape 4 will be fine with that. 

So what's the point of the .NET server controls? From what I saw these controls try to make the web a pixel perfect medium - the code I've seen generated creates inline styles (not XHTML compliant; adding unnecessary weight to the page) full of rules for positioning. So ultimately they are trying to achieve something that is not standards compliant and not worth achieving/not possible.

WEB IS NOT PRINT! Can everyone please admit that? Anyone who disagrees please write your comments on your monitor with ball point pen and get them to me.

Maybe this highlights a difference between the .NET camp and the Java camp. It seems Sun is devoting its efforts to creating a set of standards and best practices that a range of vendors can implement, while Microsoft is devoting it's efforts to labour-reducing features. Unfortunately some of the MS efforts (ADO, these server side controls) come with gotchas that make maintenance and delivery harder to achieve. This highlights a strength of Java's community process where different parties can influence the standards Sun delivers.

Walter Rumsby
Tuesday, September 10, 2002

.NET (and especially web controls) are a way for the VB developers to create internal corporate apps that look like VB apps.

Why? Becuase it's what the users/clients want!

As much as I love the web, there are some issues with I'd love to see fixed. I hate being constantly asked:
- why can't I have an editable drop-down (i.e. combo-box)?
- why can't I have an editable grid in the web page? AND be able to resize the columns? AND why does the column headers move off the page when I scroll down the page?
- why does the page have to constantly refresh?
- (too many to list here)

If you're going to make a public site with .NET, I would assume the website designers are not using web controls. They are making the html in test editors and the programmers fill in the functionality.

The real purpose of .NET wb controls is for the corp. developers that have a few weeks to pump out an intranet tool that can be rapidly assembled as VB. Therefore they can mandate an IE only standard, etc.

As much as I like standards, HTML is a lost cause. As long as IE is forgiving and it has 95% of the market, it is not worth the investment.

I'm more interested in the standards behind Web Services. Why? There are contless products that support web services and standards are needed if there is to be interoperability.

AEB
Tuesday, September 10, 2002

"WEB IS NOT PRINT! Can everyone please admit that?"

It cerainly isn't, but there seems to be a large market that would want some of the conveniences of print, such as more predictable look, to come to the web. Why should this not be delivered?

"It seems Sun is devoting its efforts to creating a set of standards and best practices that a range of vendors can implement, while Microsoft is devoting it's efforts to labour-reducing features. "

Let me think realy hard. What do I want?
"Standards" declared by one company listening to a few "friends of the family" other companies, so that they can sell me more stuff, but that require more of my time and effort?
Or one company delivering stuff they want to sell me, influenced by listening to the customers, that saves me time and effort ... ?

hmm ... difficult ...

Just me (Sir to you)
Wednesday, September 11, 2002

Lots of good points here!

I totally agree that the Web is not print. In all the .NET web forms I've designed so far, the first thing I've done is switched from "grid layout" to "flow layout", which makes it behave like a web page again.

I agree it would be better if .NET put more emphasis on CSS style sheets and less on the style attribute. Although it does generate a default style sheet for you, I haven't found any way to bind it to a web form other than editing the HTML source.

Somebody mentioned that some of the problems will be corrected in 1.1, and this is one thing I see as a huge potential benefit of the web controls approach. If you use them, and new browser versions come along supporting new standards (HTML5 or XHTML2?), then all you have to do is keep your .NET framework up to date to support all the latest browsers and standards.

This, of course, assumes Microsoft will listen to users comments and adhere to standards. Contrary to popular belief, they do sometimes do this (though perhaps not often enough).

I don't think .NET is quite ready for real world web sites, but it has a lot of useful functionality I'm looking forward to when it is. I like the way the design and the program are seperated from each other (though I'm aware this has been available in Java for years).

Personally I use .NET for internal corporate applications, where standards aren't a huge issue, but rollout is. In the bad old days of VB6 we'd have to roll out apps to hundreds of users in different cities and sometimes different countries. Then, a couple of months later someone would install an application with a different version of a DLL and we'd have an angry user complaining that our app didn't work anymore.

At least with .NET I no longer live in DLL hell!

James

James Shields
Wednesday, September 11, 2002

Nothing gets a web designers panties in a bunch like non standard html. You could always write your own http handlers in .net to pump out the specific html you choose. Or you could keep on preachin brother! I prefer the later.

trollbooth
Wednesday, September 11, 2002

*  Recent Topics

*  Fog Creek Home