Sanchez said: «The original Koch article was about separating behavior from structure and style — a desirable W3C objective if I ever heard one.»
Koch’s point sounds desirable – and may be is. But what’s the diff between behaviour and style? Much done through JavaScript manipulations can be done with CSS. So why call it ‘behaviour’ when it uses JavaScript instead of CSS?
Personally I don’t know if custom DTDs and namespaces make sense when you could just use an XML document with a proper schema or relaxNG and go nuts on your attributes elements. This would also allow you to create proper sections of the document rather than relying on H1-H6 to introduce but not encompass your sections.
An XSL transformation can spit out the proper xHTML, a JavaScript with the right validation and instruct the backend how to work out the fallback validation should JavaScript not be available.
Putting our own inventions on the backend will also make it safer – if I can see all required information in the markup I have a chance to spoof them a lot easier.
By the way – Interesting spot for a typo:
“It does, however, remind us of a very important point: validation only one step in checking the correctness of”
Correctness is achieved by adding andother “is” after validation :-)
CSS cannot create and remove elements from the document. That is what the DOM is for.
Visual changes are not the same as changes in the structure. JavaScript also allows you to test a lot more than CSS even with the CSS3 selectors allows you to. How would you validate a form entry in CSS? This is what behaviour is about.
There are some examples around, I gather, of elements created through pseudo-elements and generated content. And for CSS3 selectors you yourself note similarity. More advanced, but still much of the same.
View it like that should have implications for how to continue. New content [new CDATA] for e.g. the style attribute would then be quite logical: new css attributes instead of new (X)HTML attributes. E.g. style=”-jsrequired:‘true’;”. Valid XHTML but invalid CSS, until the new CSS attributes are accepted. Is that so bad? Eventually you could create a /* behaviour */ section in your stylesheet.
This is a bit off topic, but given any apparent confusion of CSS with behavior, perhaps ALA should look into publishing an article on why :hover is a bad idea (or not) in CSS. A lot of people complain that IE doesn’t support :hover for anything but a link but shouldn’t we be looking at javascript for that anyway? What does the W3C have to say about this? (I’ll admit, I haven’t looked)
Copy & paste the code below to embed this comment.
Brian LePore
While I agree with most of your post, the use of ::before and ::after, as well as the (poorly supported) content attribute do allow for the creation and modification of simple elements (anything complicated will likely break cross-browser compatibility). Opera’s content attribute is faily powerful and I believe Opera is closest to achieving CSS counters (if not alrady achieved) thanks to it.
That said, yes, DOM manipulation is much more reliable, as all browsers have their respective problems with CSS generated content (for example, I stayed up until 2:30 last night trying—and failing—to figure out problems with ::before and ::after in Opera. I used them to generate content in my default Style Sheet, and in another Style Sheet that is only loaded when JavaScript is available they were set to display: none;, but Opera would not remove these elements).
One person solving a real world problem and then exposing it to the world is good. 15 people solving the real world problem exposing it to the world is confusing. The W3C is only cautioning you that Custom DTD’s might make your page validate but won’t necessarily make you page readable by your targeted audience. If a useable implementation already exists then use it. If one doesn’t then yes build one. Custom DTD’s are not a panacea though. That’s why standards are important. It increases the chances that your document will be readable by the widest range of client platforms.
«Behaviour» seems to be simply another word for «script» — or is it a particular way of using the scripts?
Anyway, Koch got his inspiration from the way CSS stylesheets work. And to use «script selectors», seems very much in line with the thinking behind CSS stylesheets.
To introduce new markup attributes —even introducing more than one such markup «behaviour» attribute instead of having just one «behaviour» attribute with many content (CDATA) options— in my mind is not in line with the thinking behind CSS stylesheets.
That is how I evaluate Koch’s article against the background fo W3’s article.
The fact of the matter is that support for arbitrary attributes is totally supported by (X)HTML – in the sense that all browsers have supported it since the DOM was introduced.
The fact that the standards have NO clear way of recognising this is a huge shortcoming. My own solution is simply to ignore those validation errors; this is hardly ideal, particularly when we are trying to promote our CMS as standards compliant.
It’s not clear to me why creating custom attributes for scripting is bad. They are just hooks to simplify JavaScript scripts. Web browser rendering engines don’t need to do anything with them since only the scripts will pay any attention to them.
I think :hover is fine. It’s being used to change styles when an event occurs. The lines are blurred between presentation and behavior anyway since JavaScript can make modifications to CSS through the style and styleSheets objects.
P.S. The quote from the HTML 4.01 Specs is here <http://www.w3.org/TR/1998/REC-html40-19980424/appendix/notes.html>.
The line between presentation and behaviour can be blurred, if you choose to do so. The whole point about the “is :hover bad?” line of arugment is that they shouldn’t be.
i.e., don’t use javascript to modify the style attribute / styleSheets object. Use javascript to manipulate className instead. Doing this will prevent the line from being blurred.
Regarding hover, however, this isn’t a case of CSS implementing behaviour, so much as the browser coming with some behaviours built in. As such, :hover isn’t
I mean, ultimately you’re going to have li:hover or li.hover, which aren’t substantially different.
I want the “target” attribute back so I don’t have to fuss with javascript to open new windows.
I also want the “wrap” attribute in textarea tags because it defines how to do line-wrapping and there are at least 3 ways the browsers deal with it!
Copy & paste the code below to embed this comment.
Anon
(i) respect the work of the w3c, yet wish that we’d gain a little ambition and a greater vision of what together we sellers/users/actual custodians can deliver the world.
Tags and attributes are nothing if not identity attached to various well defined semantics, but clearly it is a schoolboy error to forget that identity exists, and needs to exist, seperate from defined semantics. Arbitrary attribute, prefixed with O_, ie. O_required=“1” would solve they’re philosophical interoperability wobbles. We thousands demand you fix the spec by tomorrow.
Go on then.
I have nails and walls and a hammer. You are the masters of my windows and doors. Tell me I can’t bang these in! Tell me I can’t hang my picture!
Anon stomps off grumbling with a murderous look in his eyes.
Just a few words about the obvious confusion between behaviour and presentation.
It is wrong to say that CSS=presentation and JS=behaviour. Both CSS and JS are tools to make the browser do what you want. Behaviour and presentation are concepts.
It is true that CSS is intended to define presentation, and that JS is most suited for behaviour. Does that mean, though, that everything else is anathema? Am I not allowed to introduce a little style through JS?
The important part is separation, not language binding. If I make a behaviour.js and a presentation.js, I have properly separated the two concepts. I probably have also done a lot of unnecessary work, such as trying to monitor changes to the class attribute so that changes from the behaviour side will reflect in the visible page.
In other words, you should use CSS for presentation because it is better at it than JS. Similarly, you should use JS for behaviour because it is better at it.
There was, for example, a W3C effort called XML Events. (I believe the effort has stopped due to lack of interest.) It allowed binding of events by using XML tags instead of some script language. Was that wrong? Isn’t it said that markup is for structure?
No. The main document is for structure. Putting XML Events tags into the main file would have been wrong, because it would have mingled structure and behaviour. Using, for example, XInclude to separate the XML Events stuff would have been fine.
Another example: SVG. Web sites could look extremely cool if we used SVG for their layout. With the advent of native SVG support in Mozilla and Opera, this even becomes possible. Is it a good idea, though?
Sure, why not? Just because SVG is an XML language doesn’t mean it can’t be used for presentation. The problem is once again in that the naive approach would be to mix SVG elements into the main XHTML document. Mixing of structure and presentation. Bad.
The key in this case would be to use a technology such as XBL to separate the SVG out of the structure. And we’re fine once again.
All this has very little to do with the article in question. The article is about when to and when not to create a custom DTD.
I think the point of the article is that Peter-Paul Koch’s idea of custom attributes is good, but creating a DTD just to make them validate is not. The point is that, due to the document no longer being HTML (not even invalid HTML), the downsides outweigh the questionable benefit of correct validation.
Use your custom attributes. (As long as they don’t go into the behavioural area – in that case, bind from the JS side.) Just make sure that these attributes do not collide with possible future HTML attibutes: give them unique prefixes, or if you’re using XHTML, put them into their own namespace. Let that namespace refer to your own site, so that nobody is tempted to copy it. In recognition of Appendix C, make the namespace prefix reasonably unique as well, so that HTML parsers won’t get confused.
Your document may no longer validate. But it is understood by everything but validating XML parsers. And quite frankly, these are not of much concern in the reality of the web.
Copy & paste the code below to embed this comment.
J. Snell
What this article tells me is that the W3C are scared that people will not use the ability to create custom DTDs properly, and thus put up big neon “this is bad” signs.
Custom DTDs in the real world are like guns. If they are used carefully and responsibly then they present no threat, but when used without thought they have the potential to do a lot of damage.
If you are going to create custom attributes, then think about what will happen to the user’s experience in user agents where the custom attributes won’t work. A good example of this would be JavaScript validation attributes in browsers that don’t support JavaScript. Will the absence of support prevent use of your site? If it doesn’t then go ahead and use those custom attributes.
If absence of support breaks the site then you’d better rethink what you are doing.
Now, if you’ve used custom attributes then you’d better tell the browser you are doing so and what it can expect to see. This is the purpose of DTDs after all, to tell programs reading our document what it can expect to find there in terms of structure. This includes both validation programs and browsers, even if the popular ones don’t actually bother to look at it.
Of course the document won’t strictly be a 100% W3C standard XHTML document, but if you construct the DTD correctly it will still, for all intents and purposes, still be XHTML. Don’t just use random prefixes for your attributes, put them in a seperate XML namespace title appropriately. Your company name would be a good namespace. This seperates your additions cleanly from XHTML with no threat of conflicting with anything and has more meaning to it than random prefixes.
If a lot of people are using the same attributes which have exactly the same meaning, then it would be wise to use the same namespace (but still seperate from the XHTML namespace) as it would identify to supporting user agents that they can expect the same thing from all these uses of the attribute.
Ultimately the way forward is treat extensions to W3C standards like treading on egg shells. It can be done safely, but only if you are very careful not to break anything. ;-)
Copy & paste the code below to embed this comment.
Antti Tuppurainen
What people seem to keep missing is that behavior means a change of the information immediately available to the user, while style means the presentation of all information. Style should not affect the way the information is perceived, only give an aesthetically pleasing surrounding for it.
As an example, a hover button with a different-colored background is not behavior, but style—no matter whether you do it with CSS or JavaScript. A drop-down menu with options is behavior, as it presents more information than the original view.
Someone is going to ask “Well, smartypants, where’s the line between content and behavior then?”
The line is that behavior controls the displayed content i.e. information. In the most degraded form (as in no css, js, etc for web pages) of the media, all content that can be made available through behavior should be shown.
(Disclaimer: These are all my own thoughts and strictly IMO, but if you feel like giving constructive criticism, feel free.)
This is preposterous… XML means eXtensible Markup language. As in you should extend it and create new vocabularies accroding to it’s syntax rules to fit your business need. To suggest that we should not use XML to do the things XML was created for just doesn’t make sense.
Copy & paste the code below to embed this comment.
HomelessMechanic
Great! let us be thankful for XHTML’s modular design, oh the wisdom, and add a module describing a flag attribute using our own DTD. It’s not-trivial, we are told.
Not-trivial, repeat that. And then hear the truth. “It’s not trivial either because we’ve obfuscated it, or because there isn’t a teacher/writer/actualuser amongst us”.
“But at least its jobs for the boys for a few years yet.”
Practical accessible reading material on the subject appears not to exist. Give up now and save yourself some time. Some messiah will come along with the subject on a stick one day, maybe. You lucky lazy jobless web mechanics.
The use of language belies the w3c as technocratic elitists more inclined to ponder their own cleverness than encapsulating XHTMLs logic for anyone with more than one thing to do.
Of course it’s astonishingly simple when you know how, but don’t worry your pretty little heads about it.
Copy & paste the code below to embed this comment.
Anthony Armendariz
ALA Writers,
I have read this web site religiously since the late 90’s and I am a believer and follower of web standards. As I do understand some of the lingo and jargon in this article, some of it is just alien to me, and thus i open and quickly close the document. How techy does an article really need to be. Content is key, and if you want to really educate people, start talking to them in a manner that a broad range of people can understand, and not just us code geeks.
Sure this site is a great resource, but is it really at its full potential?? I reccomend comparing the time a user spends on a page that is easy to understand vs. pages like this. I am sure there is some drastic results.
Thanks,
Anthony Armendariz
Partner/Creative Director
Design Dialogue
Houston, TX
34 Reader Comments
Back to the ArticleLeif Halvard Silli
Sanchez said: «The original Koch article was about separating behavior from structure and style — a desirable W3C objective if I ever heard one.»
Koch’s point sounds desirable – and may be is. But what’s the diff between behaviour and style? Much done through JavaScript manipulations can be done with CSS. So why call it ‘behaviour’ when it uses JavaScript instead of CSS?
Chris
Personally I don’t know if custom DTDs and namespaces make sense when you could just use an XML document with a proper schema or relaxNG and go nuts on your attributes elements. This would also allow you to create proper sections of the document rather than relying on H1-H6 to introduce but not encompass your sections.
An XSL transformation can spit out the proper xHTML, a JavaScript with the right validation and instruct the backend how to work out the fallback validation should JavaScript not be available.
Putting our own inventions on the backend will also make it safer – if I can see all required information in the markup I have a chance to spoof them a lot easier.
By the way – Interesting spot for a typo:
“It does, however, remind us of a very important point: validation only one step in checking the correctness of”
Correctness is achieved by adding andother “is” after validation :-)
Chris
another of course, not andother
Chris
CSS cannot create and remove elements from the document. That is what the DOM is for.
Visual changes are not the same as changes in the structure. JavaScript also allows you to test a lot more than CSS even with the CSS3 selectors allows you to. How would you validate a form entry in CSS? This is what behaviour is about.
Leif Halvard Silli
There are some examples around, I gather, of elements created through pseudo-elements and generated content. And for CSS3 selectors you yourself note similarity. More advanced, but still much of the same.
View it like that should have implications for how to continue. New content [new CDATA] for e.g. the style attribute would then be quite logical: new css attributes instead of new (X)HTML attributes. E.g. style=”-jsrequired:‘true’;”. Valid XHTML but invalid CSS, until the new CSS attributes are accepted. Is that so bad? Eventually you could create a /* behaviour */ section in your stylesheet.
jim
This is a bit off topic, but given any apparent confusion of CSS with behavior, perhaps ALA should look into publishing an article on why :hover is a bad idea (or not) in CSS. A lot of people complain that IE doesn’t support :hover for anything but a link but shouldn’t we be looking at javascript for that anyway? What does the W3C have to say about this? (I’ll admit, I haven’t looked)
Brian LePore
While I agree with most of your post, the use of ::before and ::after, as well as the (poorly supported) content attribute do allow for the creation and modification of simple elements (anything complicated will likely break cross-browser compatibility). Opera’s content attribute is faily powerful and I believe Opera is closest to achieving CSS counters (if not alrady achieved) thanks to it.
That said, yes, DOM manipulation is much more reliable, as all browsers have their respective problems with CSS generated content (for example, I stayed up until 2:30 last night trying—and failing—to figure out problems with ::before and ::after in Opera. I used them to generate content in my default Style Sheet, and in another Style Sheet that is only loaded when JavaScript is available they were set to display: none;, but Opera would not remove these elements).
Or am I missing something here?
Zaphar
One person solving a real world problem and then exposing it to the world is good. 15 people solving the real world problem exposing it to the world is confusing. The W3C is only cautioning you that Custom DTD’s might make your page validate but won’t necessarily make you page readable by your targeted audience. If a useable implementation already exists then use it. If one doesn’t then yes build one. Custom DTD’s are not a panacea though. That’s why standards are important. It increases the chances that your document will be readable by the widest range of client platforms.
Leif Halvard Silli
«Behaviour» seems to be simply another word for «script» — or is it a particular way of using the scripts?
Anyway, Koch got his inspiration from the way CSS stylesheets work. And to use «script selectors», seems very much in line with the thinking behind CSS stylesheets.
To introduce new markup attributes —even introducing more than one such markup «behaviour» attribute instead of having just one «behaviour» attribute with many content (CDATA) options— in my mind is not in line with the thinking behind CSS stylesheets.
That is how I evaluate Koch’s article against the background fo W3’s article.
Sam
The fact of the matter is that support for arbitrary attributes is totally supported by (X)HTML – in the sense that all browsers have supported it since the DOM was introduced.
The fact that the standards have NO clear way of recognising this is a huge shortcoming. My own solution is simply to ignore those validation errors; this is hardly ideal, particularly when we are trying to promote our CMS as standards compliant.
Kravvitz
It’s not clear to me why creating custom attributes for scripting is bad. They are just hooks to simplify JavaScript scripts. Web browser rendering engines don’t need to do anything with them since only the scripts will pay any attention to them.
I think :hover is fine. It’s being used to change styles when an event occurs. The lines are blurred between presentation and behavior anyway since JavaScript can make modifications to CSS through the style and styleSheets objects.
P.S. The quote from the HTML 4.01 Specs is here <http://www.w3.org/TR/1998/REC-html40-19980424/appendix/notes.html>.
Sam
The line between presentation and behaviour can be blurred, if you choose to do so. The whole point about the “is :hover bad?” line of arugment is that they shouldn’t be.
i.e., don’t use javascript to modify the style attribute / styleSheets object. Use javascript to manipulate className instead. Doing this will prevent the line from being blurred.
Regarding hover, however, this isn’t a case of CSS implementing behaviour, so much as the browser coming with some behaviours built in. As such, :hover isn’t
I mean, ultimately you’re going to have li:hover or li.hover, which aren’t substantially different.
Of course, IE6 support is still important :P
IMarvinTPA
I want the “target” attribute back so I don’t have to fuss with javascript to open new windows.
I also want the “wrap” attribute in textarea tags because it defines how to do line-wrapping and there are at least 3 ways the browsers deal with it!
IMarv
Chris
They are all in there.
Jody Stockley
I’m so happy to see ALA back with a new article. Keep ‘em coming!
Anon
(i) respect the work of the w3c, yet wish that we’d gain a little ambition and a greater vision of what together we sellers/users/actual custodians can deliver the world.
Tags and attributes are nothing if not identity attached to various well defined semantics, but clearly it is a schoolboy error to forget that identity exists, and needs to exist, seperate from defined semantics. Arbitrary attribute, prefixed with O_, ie. O_required=“1” would solve they’re philosophical interoperability wobbles. We thousands demand you fix the spec by tomorrow.
Go on then.
I have nails and walls and a hammer. You are the masters of my windows and doors. Tell me I can’t bang these in! Tell me I can’t hang my picture!
Anon stomps off grumbling with a murderous look in his eyes.
Anon
Their just in it to lie with the i’s
Sebastian Redl
Just a few words about the obvious confusion between behaviour and presentation.
It is wrong to say that CSS=presentation and JS=behaviour. Both CSS and JS are tools to make the browser do what you want. Behaviour and presentation are concepts.
It is true that CSS is intended to define presentation, and that JS is most suited for behaviour. Does that mean, though, that everything else is anathema? Am I not allowed to introduce a little style through JS?
The important part is separation, not language binding. If I make a behaviour.js and a presentation.js, I have properly separated the two concepts. I probably have also done a lot of unnecessary work, such as trying to monitor changes to the class attribute so that changes from the behaviour side will reflect in the visible page.
In other words, you should use CSS for presentation because it is better at it than JS. Similarly, you should use JS for behaviour because it is better at it.
There was, for example, a W3C effort called XML Events. (I believe the effort has stopped due to lack of interest.) It allowed binding of events by using XML tags instead of some script language. Was that wrong? Isn’t it said that markup is for structure?
No. The main document is for structure. Putting XML Events tags into the main file would have been wrong, because it would have mingled structure and behaviour. Using, for example, XInclude to separate the XML Events stuff would have been fine.
Another example: SVG. Web sites could look extremely cool if we used SVG for their layout. With the advent of native SVG support in Mozilla and Opera, this even becomes possible. Is it a good idea, though?
Sure, why not? Just because SVG is an XML language doesn’t mean it can’t be used for presentation. The problem is once again in that the naive approach would be to mix SVG elements into the main XHTML document. Mixing of structure and presentation. Bad.
The key in this case would be to use a technology such as XBL to separate the SVG out of the structure. And we’re fine once again.
All this has very little to do with the article in question. The article is about when to and when not to create a custom DTD.
I think the point of the article is that Peter-Paul Koch’s idea of custom attributes is good, but creating a DTD just to make them validate is not. The point is that, due to the document no longer being HTML (not even invalid HTML), the downsides outweigh the questionable benefit of correct validation.
Use your custom attributes. (As long as they don’t go into the behavioural area – in that case, bind from the JS side.) Just make sure that these attributes do not collide with possible future HTML attibutes: give them unique prefixes, or if you’re using XHTML, put them into their own namespace. Let that namespace refer to your own site, so that nobody is tempted to copy it. In recognition of Appendix C, make the namespace prefix reasonably unique as well, so that HTML parsers won’t get confused.
Your document may no longer validate. But it is understood by everything but validating XML parsers. And quite frankly, these are not of much concern in the reality of the web.
J. Snell
What this article tells me is that the W3C are scared that people will not use the ability to create custom DTDs properly, and thus put up big neon “this is bad” signs.
Custom DTDs in the real world are like guns. If they are used carefully and responsibly then they present no threat, but when used without thought they have the potential to do a lot of damage.
If you are going to create custom attributes, then think about what will happen to the user’s experience in user agents where the custom attributes won’t work. A good example of this would be JavaScript validation attributes in browsers that don’t support JavaScript. Will the absence of support prevent use of your site? If it doesn’t then go ahead and use those custom attributes.
If absence of support breaks the site then you’d better rethink what you are doing.
Now, if you’ve used custom attributes then you’d better tell the browser you are doing so and what it can expect to see. This is the purpose of DTDs after all, to tell programs reading our document what it can expect to find there in terms of structure. This includes both validation programs and browsers, even if the popular ones don’t actually bother to look at it.
Of course the document won’t strictly be a 100% W3C standard XHTML document, but if you construct the DTD correctly it will still, for all intents and purposes, still be XHTML. Don’t just use random prefixes for your attributes, put them in a seperate XML namespace title appropriately. Your company name would be a good namespace. This seperates your additions cleanly from XHTML with no threat of conflicting with anything and has more meaning to it than random prefixes.
If a lot of people are using the same attributes which have exactly the same meaning, then it would be wise to use the same namespace (but still seperate from the XHTML namespace) as it would identify to supporting user agents that they can expect the same thing from all these uses of the attribute.
Ultimately the way forward is treat extensions to W3C standards like treading on egg shells. It can be done safely, but only if you are very careful not to break anything. ;-)
Antti Tuppurainen
What people seem to keep missing is that behavior means a change of the information immediately available to the user, while style means the presentation of all information. Style should not affect the way the information is perceived, only give an aesthetically pleasing surrounding for it.
As an example, a hover button with a different-colored background is not behavior, but style—no matter whether you do it with CSS or JavaScript. A drop-down menu with options is behavior, as it presents more information than the original view.
Someone is going to ask “Well, smartypants, where’s the line between content and behavior then?”
The line is that behavior controls the displayed content i.e. information. In the most degraded form (as in no css, js, etc for web pages) of the media, all content that can be made available through behavior should be shown.
(Disclaimer: These are all my own thoughts and strictly IMO, but if you feel like giving constructive criticism, feel free.)
kL
If you want to add new tags and attributes, take a look at WAHTWG specs (proposed to W3C):
http://whatwg.org/specs/web-apps/current-work/
http://whatwg.org/specs/web-forms/current-work/
…at least you can have some (non-)standard for your non-standard elements.
Todd
This is preposterous… XML means eXtensible Markup language. As in you should extend it and create new vocabularies accroding to it’s syntax rules to fit your business need. To suggest that we should not use XML to do the things XML was created for just doesn’t make sense.
HomelessMechanic
Great! let us be thankful for XHTML’s modular design, oh the wisdom, and add a module describing a flag attribute using our own DTD. It’s not-trivial, we are told.
Not-trivial, repeat that. And then hear the truth. “It’s not trivial either because we’ve obfuscated it, or because there isn’t a teacher/writer/actualuser amongst us”.
“But at least its jobs for the boys for a few years yet.”
Practical accessible reading material on the subject appears not to exist. Give up now and save yourself some time. Some messiah will come along with the subject on a stick one day, maybe. You lucky lazy jobless web mechanics.
The use of language belies the w3c as technocratic elitists more inclined to ponder their own cleverness than encapsulating XHTMLs logic for anyone with more than one thing to do.
Of course it’s astonishingly simple when you know how, but don’t worry your pretty little heads about it.
Anthony Armendariz
ALA Writers,
I have read this web site religiously since the late 90’s and I am a believer and follower of web standards. As I do understand some of the lingo and jargon in this article, some of it is just alien to me, and thus i open and quickly close the document. How techy does an article really need to be. Content is key, and if you want to really educate people, start talking to them in a manner that a broad range of people can understand, and not just us code geeks.
Sure this site is a great resource, but is it really at its full potential?? I reccomend comparing the time a user spends on a page that is easy to understand vs. pages like this. I am sure there is some drastic results.
Thanks,
Anthony Armendariz
Partner/Creative Director
Design Dialogue
Houston, TX