I’m the head of the website division of my team’s website, which has been pretty cool, since we’re a rookie team and starting from scratch. We’ve been working primarily in dreamweaver, and then I go back and edit the code as needed. I’ve been trying to validate my page, because I think that’s pretty important. I’ve gotten all the errors cleaned up except one. It comes up saying that there is no attribute “onclick.” I have multiple lines of code that all are similar to this…
Basically it’s a calendar that when you click on the date it displays the message. Anyway, for some reason dreamweaver stuck the “onclick” inside the font tag, which I know is the problem. But I’m not sure where to put the “onclick” tag. And is the problem due to the fact that the onclick is on text, instead of a link or anchor?
I hope that made sense. If anyone has any advice, I’d greatly appreciate it.
The reason “onclick” is not validating is because it is a Javascript element, and not really part of the web standards. Technically, you should be using Javascript to add the event handler to that node, instead of including it in the HTML. However, this is super-complicated and not really necessary.
If you <i>really</i> are worried about web standards, you wouldn’t be using a <FONT> tag in the first place. Putting styling information in HTML is so 1999 . I know you’re using Dreamweaver, but CSS (Cascading Style Sheets) are really the wave of the Internet-future. Give the w3 site a bit of a read; it’s pretty interesting.
I wouldn’t worry too much about validating. Technically, your code isn’t “broken” in any way. It’s just not as perfect as it could be.
First things first; the <font> tag has depreciated a few years ago–replaced with the likes of <div> and <span>.
you can change the code in Dreamweaver. If Dreamweaver ‘sticks’ your onclick message inside or wherever you don’t want it to be, simple copy n paste.
The dependancy on Dreamweaver is incredible. What You See Is What You Get editors should really die off and start to fade away because all they promote are bad coding standards. It’s considered horrible code to be using tables for your layout structure as well as <font> for all text issues. Sure you can use a WYSIWYG editor that implements CSS for you–blam. But you still have no idea of what you’re doing. If you want to do web design / coding right, get a book. You need to learn the languages as well as become acquainted with coding techniques used for layouts.
Granted, IE does not support CSS as well as FF, but that’s poor development of the IE browser on Microsoft’s part. Keep in mind while coding for browser compatability, do not scale back to depreciated tags or informal code just to appease one browser’s likings-- build your site the way it should be coded and hack away untill you can make the best out of it.
I don’t think tables are depreciated (in other words its not “bad” to use them - keep in mind that they render differently in different browsers though).
Remember though that not everyone has the time to learn how to code and must depend on Dreamweaver/Frontpage/etc. Afterall if it works, does it really matter if it was made by hand or in a WYSIWYG editor?
It still wouldn’t make sense to replace certain elements with divs or spans if you’re not writing the code fully with CSS, or to change that one tag to be XHTML Strict valid when you’re writing the rest of the site with HTML 4.0 Transitional. Consistency is more important.
And it’s not necessarily “not as perfect as it could be”. It’s true it’s not valid, but you should have a reason for wanting it to be valid. Otherwise, it’s perfect if it’s what you need it to be.
I would say that if the onclick attribute is what you really want, keep it. In general, I do agree that less attributes and more CSS is better–just don’t use it if you have a strong preference for older HTML.
I don’t think tables are depreciated (in other words its not “bad” to use them - keep in mind that they render differently in different browsers though).
No, of course not. Tables probibly wont ever depreciate unless they’re replaced by a better coding technique (essentially, reinventing tables :P). I’m just stating that using tables for your whole site’s framework/backbone is considered poor coding practice these days.
It still wouldn’t make sense to replace certain elements with divs or spans if you’re not writing the code fully with CSS, or to change that one tag to be XHTML Strict valid when you’re writing the rest of the site with HTML 4.0 Transitional. Consistency is more important.
True Which is why the push for converting over to full XHTML & CSS code is becoming greater and greater. Can’t really avoid standards.
A big idea behind XHTML is semantic coding: Tables should be used for information that takes the form of a table, such as a list of products, descriptions, and prices. Unfortunately, it’s still tricky to make complex, 3-column web pages using CSS that look right on all browsers.
Thanks for the advice to add in the css. I added the style sheet, spent 2 hours deleting font tags haha, and now every works great, validates, and kinda looks better too…
I agree css is a pretty good way to go at times, but somethings are just accomplished better with tables. To each their own?
Thanks for the advice to add in the css. I added the style sheet, spent 2 hours deleting font tags haha, and now every works great, validates, and kinda looks better too…
I agree css is a pretty good way to go at times, but somethings are just accomplished better with tables. To each their own?
Well that’s good! Glad you got some CSS in there. Whatever floats your boat.
:cough: CSS 3 :/cough:
:cough:^ignorant^:cough:
I still stand by my statment. Re-read? Tables for data use wont ever depreciate unless they’re replaced by a better coding technique which wouldn’t be a form of CSS. Using tables for data, coded in CSS, is too inefficient.
Table use for layouts has been a thing of the past (refering to the standards here) and have had CSS layout alternatives since the first CSS rev.
. I know you’re using Dreamweaver, but 
