Hi guys, I'm sure there are many answers to this out there but I'm having trouble finding anything definite. I've done a lot of research and can't seem to find an answer that isn't confusing or that I can confirm relates to my exact doctype.
I am currently finishing up a site which I began with a template. I've heavily edited the template to create a new design but the doctype of course remains the same. This is the info specified in the template:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Even after reading tons of pages on the subject, I can't for my life confirm what type of coding to use when it comes to closing tags. For this doctype, do I use:
<br>, <br/> or <br />
<a href="url.com">, <a href="url.com"/> or <a href="url.com" />
<img src="img.jpg">, <img src="img.jpg"/> or <img src="img.jpg" />
Or for this doctype does it not matter at all? I'm sure the answer is quite obvious but this is one of those cases where there seems to be TOO much information with many different viewpoints and I've been left feeling unsure of the exact rules.
As of now, my pages uses <br/>, <a href="url.com"> and <img src=img.jpg" /> so they are all possibly following different rules and I just want to clarify whether or not I need to touch that up before the site goes live.
When you put in XHTML, it is synonymous with html. XHTML is the current definition of html. They are one in the same. Back in the day you could specify html and the version type, but even then browser only output what the can. If you want to get down to brass tacks, you don't have to tell the browser what type of doc you are giving, it will either figure it out by the code, the extension, or just push it out, hence the reason you can feed it a text file and it just simply reads it, even if it doesn't have a .txt on the end. So don't worry yourself with it, its all a load of garbage.
As far as tags, if you want to be "compliant" you would use tags that are not blocks, meaning all in one tag, like img, and br, and all you do is put a / and the end, like <img src="blah" /> or <br />, but even if you don't put in the /, it will still work. Personally I have yet to have a browser complain about either.
I love how people get an attitude when THEY asked for help.
Why don't you simply validate your code to clarify your doubts?
It is always helpful to validate your code snippet or the entire web page to understand the correct way of coding and to remove errors!
It ascertains you if you are following the correct standards or not! The W3C Markup Validation Service!
Last edited by TheAliveWinner; 07-28-2012 at 10:24 PM.
Reason: Acidity! :(
"It will never rain roses: when we want to have more roses, we must plant more roses."
- George Eliot
According to the W3C specification for XHTML, you should use the " />" syntax on empty elements such as "<br />" and "<img />". As TheAliveWinner points out, it's a good idea to validate your code with the W3C Validator to insure proper syntax.
And the <!DOCTYPE> declaration is a very important part of your documents. It not only declares the format, it has a major impact on how your pages are rendered by browsers - specifically, whether they are rendered in "Standards Compliance Mode" or "Quirks Mode". While browsers will accept just about any document and do their best to render them, if you want your users to see your pages the way you intend, it's vital to adhere to the W3C Standards and use a proper <!DOCTYPE>. A search on "doctype switch" will explain this in detail.
HTML coding and XHTML coding are not the same. XHTML requires much stricter syntax than any version of HTML. Anyone who doesn't want to add closing tags even when unnecessary are just lazy. Creates bad habits. Like leaving off the semicolon in last CSS rule for a selector. Lazy.
XHTML requires the space and "/" character for those tags which were not normally closed in HTML. Also, all tags and attributes are to be lowercase. JavaScript will be flagged on things like "onClick" when XHTML wants "onclick". Follow the syntax rules only if you care.
The current version of HTML is HTML 4.01 and you should be using HTML 4.01 Strict.
But if you are using XHTML all tags must be closed but you are free to use <br />, <br/> or even <br></br>. Only the first one, however, comes close to being compatible with HTML browsers. Which is the problem with XHTML. It isn't compatible with HTML. You can get it close by following both the HTML and the XHTML rules at the same time but then you might has well just use HTML.
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”
—Tim Berners-Lee, W3C Director and inventor of the World Wide Web
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”
—Tim Berners-Lee, W3C Director and inventor of the World Wide Web
I hate to have to post on this one again, but I just can't let it go. I have always run into people in this business that want to say they are doing the right thing by being compliant with w3c standards. BUT in the real world there is a huge difference between compliance, and reality. I know a couple of you posted and saying you have to validate, and that not being standard is poor coding, but in the real world we code for cash, plain and simple.
If you have real deadlines, and not projects due for school, getting your code to pass the tests of w3c can be time consuming, and sometime times impossible. AND YES, sometimes it pays to half ass a project, if we aren't getting paid top dollar for work, your not getting top dollar work, that's just a the way it is. I have been doing this for years, and if the browser doesn't complain, and it looks and functions as I need it, guess what, ITS DONE. It's nice to have projects that let you devote all the time in the world to them, but sometimes you have a project where the client is like "is it done?, you have that yet?, when is it gonna be done?" , oh and btw "you have 72 hours for that one month project".
I can do whatever you want, but you get what you get. I have more projects, and more clients, and more development, revamping, layouts, design, and definition time to get done, because at the end of the week, month, and year, I have bills to pay. So, while I appreciate the need to make things pretty, define this, that, and the other, but when it comes down to it, I don't have time to go bankrupt, miss payroll, insurance, and taxes. Unfortunately in the real world, its about production, production, production, and is it working, got it working, and done.
Nothing against anyone and their opinion, or what they have been taught, and how they do their thing, but this is the world I have to live in. And I agree, if you are going for a good grade in school, do the best, most compliant, most perfect, pretty coding you can do, and when you are getting paid to do what you love, just make it work.
I love how people get an attitude when THEY asked for help.
Don't waste your time discussing the validator. As far as I am concerned:
The HTML validator was invented for people who can't quite spot the error (e.g. missed a closing div tag) in their HTML syntax that is causing the browser to display their code "incorrectly".
The HTML validator was/is used by pompous/newbie coders who think that "valid" is actually a synonym for "better"
I've switched careers...
I'm NO LONGER a scientist,
but now a web developer...
awesome.
There is no problem with validating if you are able to correct your own coding (HTML and CSS). You should do this, but it is not a necessity or life-death decision. Many browsers will forgive your sloppy coding (that's why IE is/was so poular), but not knowing how to properly code and being lazy about it are two different things.
I recommend knowing how to do it correctly the first time and just run the code through the validator for a quick check to be sure. Many browsers have web developer tools that make validating/correcting code a swift operation. People who code with deadlines have other problems of their own. If you don't care, no one else will either as long as your clients are happy.
Validation errors you have no control over are just that...validation "errors". (Facebook code is a good example.) They are not going to break the operation of your site. Look at the "errors" on Google's pages or after logging into GMail. Google has lots of people to do the coding, yet they are not worried about non-compliance with the validators. If you are too lazy to do it right the first time, you'll never find time to correct it later...and I'm referring only to the coding YOU have control over.
If you are too lazy to do it right the first time, you'll never find time to correct it later
That's the problem with people's thoughts on the validator in my opinion. That coders who don't validate are "lazy" implying that validation is something to be strived for by efficient and good coders.
This is simply not true. I don't run my code through the validator, which takes about 30 seconds, yet I do run it through at least 6 different browsers/browser versions to make sure that it renders and works correctly in all of them
Which of those two things takes more time? Which of those two things makes more of a difference in the experience of the users who use my site?
I've switched careers...
I'm NO LONGER a scientist,
but now a web developer...
awesome.
FWIW...I think there is merit in preparing for possible future browsers (which coding towards standards as much as possible should prepare you for) is where the sweet spot is. Not everything has to completely validate (especially if you have to support an old browser or two) but if you aim towards valid standards based code, the chances are better that down the road you won't have to pull apart the hacks that slipped in unexpectedly to make your site work in a new release of a browser (cough cough IE6 to IE7 cough cough). :-)
FWIW...I think there is merit in preparing for possible future browsers (which coding towards standards as much as possible should prepare you for) is where the sweet spot is. Not everything has to completely validate (especially if you have to support an old browser or two) but if you aim towards valid standards based code, the chances are better that down the road you won't have to pull apart the hacks that slipped in unexpectedly to make your site work in a new release of a browser (cough cough IE6 to IE7 cough cough). :-)
I'm sorry dude, but that made me laugh, I mean literally LOL. I know you are familiar with life cycles, it does say bs cs under your name. Why kid people, if your site doesn't update and change, at least yearly, at which time you address what you would like and don't like, then your site is dead and you probably don't need one. Come on, if you do this for a living you aren't hacking, your functioning. There is such a HUGE difference from academia and industry. When I program an application, that is when you have to make it work for 5 years, not a web page. On the web if you aren't changing, then your stale. Where in the world do you think php, asp, ruby, java, and every other dynamic language came from. If there wasn't a need to be constantly updating, then we would all just be using notepad and basic tags. The change from IE6 to 7 was 5.5 years, if your site didn't change or get updated in that time, you aren't programming, your a script kiddie.
I love how people get an attitude when THEY asked for help.
Reply With Quote
Why don't you simply validate your code to clarify your doubts?
Originally Posted by Ttawor.com
Bookmarks