www.webdeveloper.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 21

Thread: Closing tags in HTML vs. XHTML

  1. #1
    Join Date
    Jul 2012
    Posts
    4

    Closing tags in HTML vs. XHTML

    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">

    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php echo $this->language; ?>" lang="<?php echo $this->language; ?>" >

    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.

    Thanks so much!

  2. #2
    Join Date
    Jun 2012
    Location
    Dark Side of the Moon
    Posts
    70
    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.

  3. #3
    Join Date
    Feb 2012
    Location
    Bokaro Steel City (Jharkhand), India!
    Posts
    194

    Lightbulb 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 11:24 PM. Reason: Acidity! :(

  4. #4
    Join Date
    Mar 2011
    Posts
    1,148
    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.

  5. #5
    Join Date
    May 2005
    Location
    Gold Coast (MS)
    Posts
    2,217
    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.

    Validating:

    Why Validate?: http://validator.w3.org/docs/why.html
    CSS Validator: http://jigsaw.w3.org/css-validator/
    HTML Validator: http://validator.w3.org/#validate_by_uri+with_options

  6. #6
    Join Date
    Nov 2002
    Location
    Baltimore, Maryland
    Posts
    12,278
    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

  7. #7
    Join Date
    Jul 2012
    Posts
    10
    <a href="URL"></a>
    <img src="URL" />
    <br/>

    but keep in mind browsers auto correct some times depend on browser version

    the space doesn't matter when close
    Thats what i know , hope it will be helpfull

  8. #8
    Join Date
    Nov 2002
    Location
    Baltimore, Maryland
    Posts
    12,278
    Quote Originally Posted by Ttawor.com View Post
    Thats what i know , hope it will be helpfull
    Let's stop darkening counsel with words without knowledge. See http://www.w3.org/TR/xhtml1/#h-4.6 .
    “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

  9. #9
    Join Date
    Jun 2012
    Location
    Dark Side of the Moon
    Posts
    70
    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.

  10. #10
    Join Date
    Dec 2005
    Posts
    2,984
    @burnme

    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"

  11. #11
    Join Date
    Jul 2012
    Posts
    10
    @Charles

    what is wrong in my post , Correct me if i am wrong let me know what i don't know

    the w3 link say same what i have said

  12. #12
    Join Date
    May 2005
    Location
    Gold Coast (MS)
    Posts
    2,217
    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.

  13. #13
    Join Date
    Dec 2005
    Posts
    2,984
    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?

  14. #14
    Join Date
    Jan 2009
    Posts
    3,346
    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). :-)

  15. #15
    Join Date
    Jun 2012
    Location
    Dark Side of the Moon
    Posts
    70
    Quote Originally Posted by criterion9 View Post
    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.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles