SitePoint Sponsor

User Tag List

Results 1 to 22 of 22
  1. #1
    SitePoint Addict justjon's Avatar
    Join Date
    Mar 2004
    Location
    UK
    Posts
    237
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    <p>,<div> or <fieldset> for small form

    Could someone please tell me the the correct container for input elements inside a form. I understand that if there are lots of inputs that need to be grouped into sections then fieldset and legend should be used, but how about small forms with only one or two inputs where no grouping is necessary?

    Should fieldset be used with no legend? Should a <div> be used? Should a <p> be used?

    I've seen this asked many times but people don't seem to agree on an answer.

    Thanks.

  2. #2
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A FIELDSET must have a LEGEND (although it may be hidden with CSS).

    I'd recommend a FIELDSET or a DIV.

    There are few cases when the content of a form constitutes a paragraph, so P is almost never correct. (It does happen, though. I've encountered it myself.)

  3. #3
    SitePoint Wizard bronze trophy bluedreamer's Avatar
    Join Date
    Jul 2005
    Location
    Middle England
    Posts
    3,403
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Hmmm, <p> inside <form><fieldset> validates fine so if you need to divide form fields up that way why not?

  4. #4
    CTO htmlguy's Avatar
    Join Date
    Feb 2005
    Location
    North Carolina
    Posts
    420
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would recommend a styled <p>. Use CSS to style it, that way it performs exactly how you want it to behave.
    HTMLGuy

  5. #5
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bluedreamer View Post
    Hmmm, <p> inside <form><fieldset> validates fine so if you need to divide form fields up that way why not?
    Er ... because labels and form controls do not constitute paragraphs of text?

    Using <h1> to mark up form fields would validate, too. But that doesn't mean you should do it.

    FIELDSET is semantically correct.
    DIV is semantically neutral.
    P is semantically wrong (in 99.999% of all forms).
    Birnam wood is come to Dunsinane

  6. #6
    SitePoint Wizard bronze trophy bluedreamer's Avatar
    Join Date
    Jul 2005
    Location
    Middle England
    Posts
    3,403
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    Er ... because labels and form controls do not constitute paragraphs of text?

    Using <h1> to mark up form fields would validate, too. But that doesn't mean you should do it.

    FIELDSET is semantically correct.
    DIV is semantically neutral.
    P is semantically wrong (in 99.999&#37; of all forms).
    Yep that's true for labels/input, but for putting in additional information (such as an explaination for a field> then surely a <p> or <div> would be relevant? You could include the <label> and <input> inside a <p>

    I'm thinking either

    <p>Please type your full name</p>
    <label for="name"> <input name="name" type="text" value="">

    or

    <p>Please type your full name<br />
    <label for="name"> <input name="name" type="text" value=""></p>

    There's more than one way of writing valid html, despite what the "gurus" tell you what you "should" do?

  7. #7
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bluedreamer View Post
    Yep that's true for labels/input, but for putting in additional information (such as an explaination for a field> then surely a <p> or <div> would be relevant?
    Yes, as I said, when you do have a paragraph of text, then it is correct to mark it up with <p>. On the other hand, it may not be a good idea to have explanatory text inside a form, for accessibility reasons. (Screen readers often have a special 'form' mode, where they ignore anything other than labels and form controls.)

    Quote Originally Posted by bluedreamer View Post
    I'm thinking either

    <p>Please type your full name</p>
    <label for="name"> <input name="name" type="text" value="">

    or

    <p>Please type your full name<br />
    <label for="name"> <input name="name" type="text" value=""></p>
    Neither of those are good examples, in my opinion. It should be something along this:
    HTML Code:
    <fieldset>
      <legend>Contact information</legend>
      <label for="name">Please type your full name</label>
      <input name="name" type="text">
    </fieldset>
    (Although I'd be inclined to use just 'Full name' as the label. Most people will know that they are supposed to type it. )

    Quote Originally Posted by bluedreamer View Post
    There's more than one way of writing valid html, despite what the "gurus" tell you what you "should" do?
    Indeed there is, but not all of them are semantically 'correct' or proper. A DTD is a coarse way of defining a grammar. It just tells us the basic guidelines. We're left to realise that a paragraph element should contain a paragraph of text, that a block quote element should contain a block of quotation, and that a fieldset should contain a set of input fields.
    Birnam wood is come to Dunsinane

  8. #8
    SitePoint Addict justjon's Avatar
    Join Date
    Mar 2004
    Location
    UK
    Posts
    237
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the responses guys.

    So is the consensus a fieldset?
    The only reason I want/need to add anything is to get it to validate. I don't need to style as this is already done. It just seems strange to add a fieldset and a legend which implies a grouping when there are only two inputs and both already have labels. That said it seems just as strange to add a p or div with no real meaning just to get it to validate.

    Am I right in thinking that all form inputs should be contained in fieldsets in strict docs?

  9. #9
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In the Strict DTDs, a FORM element can only contain block-level children. Labels and form controls are inline-level. Thus you have to enclose them in some sort of container.

    FIELDSET is ideal, semantically, because this is exactly what it exists for. A DIV can be acceptable as well, but other block-level elements are less useful.
    Birnam wood is come to Dunsinane

  10. #10
    SitePoint Addict justjon's Avatar
    Join Date
    Mar 2004
    Location
    UK
    Posts
    237
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Fair enough.

    Just out of curiosity, why did they make it so only block level elements can be direct descendants? Is there a practical reason for this?

  11. #11
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You'll have to ask the W3C.
    This applies to a number of block-level containers in the Strict DTDs; e.g., BODY and BLOCKQUOTE.

    It makes sense to me. FORM, BODY and BLOCKQUOTE are high-level containers and it doesn't make much semantical sense to have inline-level content as immediate children to them.
    Birnam wood is come to Dunsinane

  12. #12
    I meant that to happen silver trophybronze trophy Raffles's Avatar
    Join Date
    Sep 2005
    Location
    Tanzania
    Posts
    4,662
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    What if the W3C are wrong? Everyone follows them blindly. I'm not saying I don't like their recommendations (I agree with them on the whole), but some things are really annoying, such as this of having to enclose form elements in a block-level element when they are already in a form. FORM is already block-level, so why the extra container?

    The same goes for not putting block-level element inside anchors. If I want to make some large complex section of layout into one big link (OK, I have never wanted to do this yet, but it's possible), I would have to mess about with spans and display:block. Which seems just as "unclean" to me.

    I don't mind adhering to the standards because they make sense and I like them on the whole, but they do make things much more difficult sometimes.

  13. #13
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Raffles View Post
    What if the W3C are wrong?
    They can't be, by definition. They make the recommendations, which means whatever they say is 'right'.

    Quote Originally Posted by Raffles View Post
    FORM is already block-level, so why the extra container?
    It doesn't matter that FORM is block-level. What matters is the semantics of what's inside the form. The W3C have decided that it should only be allowed to contain block-level elements.

    Quote Originally Posted by Raffles View Post
    The same goes for not putting block-level element inside anchors.
    No, that would allow very odd things. Anchors are inline-level elements, which means you can put them inside other inline elements (like STRONG) and inside P elements.

    If you were allowed to have block-level elements inside an anchor, you would implicitly be allowed to have lists, tables and forms inside a paragraph. That makes no semantic sense whatsoever.

    In fact, there is no semantical reason to have block-level elements inside an anchor, IMHO. If you want a block-level presentation, then that should be done with CSS.

    What if this were allowed, and you'd put a FORM inside an anchor. What should happen if a user clicked on a form control ...?
    Birnam wood is come to Dunsinane

  14. #14
    SitePoint Addict justjon's Avatar
    Join Date
    Mar 2004
    Location
    UK
    Posts
    237
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Raffles View Post
    What if the W3C are wrong? Everyone follows them blindly. I'm not saying I don't like their recommendations (I agree with them on the whole), but some things are really annoying, such as this of having to enclose form elements in a block-level element when they are already in a form. FORM is already block-level, so why the extra container?
    Particularity true for small forms, like a quick search form where you might only have one text input. You end up with a label, a fieldset and a legend for one input. A bit overkill IMO.

    Quote Originally Posted by Raffles View Post
    The same goes for not putting block-level element inside anchors. If I want to make some large complex section of layout into one big link (OK, I have never wanted to do this yet, but it's possible), I would have to mess about with spans and display:block. Which seems just as "unclean" to me.

    I don't mind adhering to the standards because they make sense and I like them on the whole, but they do make things much more difficult sometimes.
    I must admit that although standards are obviously an essential thing some of the recommendations also leave me thinking why? To me, the IE box model makes much more sense. When you have a real world padded box, where is the padding?

    To me it would make much more sense to put padding inside the box (to pad the content) and margins on the outside.

    And then theres removing the target attribute with no real alternative. (Which is probably one of the main reasons many people have not switched to strict.) I understand the thinking, but with no real alternative were does it leave you? It just seems to make life harder sometimes with not a lot of real gain.

    Anyway, vent over.

  15. #15
    I meant that to happen silver trophybronze trophy Raffles's Avatar
    Join Date
    Sep 2005
    Location
    Tanzania
    Posts
    4,662
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    They can't be, by definition. They make the recommendations, which means whatever they say is 'right'.
    I can't say I am 100&#37; OK with that! However, they've done a good job so far so I can't complain.
    Quote Originally Posted by AutisticCuckoo View Post
    It doesn't matter that FORM is block-level. What matters is the semantics of what's inside the form. The W3C have decided that it should only be allowed to contain block-level elements.

    In fact, there is no semantical reason to have block-level elements inside an anchor, IMHO. If you want a block-level presentation, then that should be done with CSS.

    What if this were allowed, and you'd put a FORM inside an anchor. What should happen if a user clicked on a form control ...?
    Well, I just tried it out (form controls inside anchor) and this browser (IE7) behaves rather quirkily. You can click the text in a text field but outside the text (but inside the field) the link isn't followed.

    However, I know that FF does allow DIV and P inside anchors (as in, it makes them clickable). What if, for instance, I wanted to make each post in this thread clickable. The whole post. I could wrap the table cells, images, paragraphs etc. in an anchor. I know that's wrong, but it's a neat solution. I'm inclined to think that should be controlled by javascript, though, because otherwise you'd end up rewriting your code to make sure the anchor contains only inline-level elements, mostly likely lots of spans with display:block.

    I know the standards are there to make things more rigid and ultimately usable, but they do make working with them more time-consuming and to be honest, quite annoying sometimes when I know exactly what I'm after but I have to implement a roundabout sort of way of doing it.

    Sometimes I feel like I'm sacrificing some design aspects for the sake of keeping my markup semantically correct. Which one is more important? For the customer and the user, the former, most people don't give a damn what the source looks like. But for the web itself I suppose it's the latter. And I know that if I were a really good web designer, I wouldn't have this design vs semantics issue, but I'm not.

  16. #16
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Raffles View Post
    However, I know that FF does allow DIV and P inside anchors (as in, it makes them clickable).
    I haven't tried, but I seriously doubt that. If that is true, FF is in flagrant violation with the HTML specification.

    Quote Originally Posted by Raffles View Post
    What if, for instance, I wanted to make each post in this thread clickable. The whole post.
    Sounds like a behavioural issue to me. Thus: JavaScript.

    Why would you want to do something like that?
    How would you convey to the user (who may not have a user agent that supports CSS) that the whole post is clickable?

    I'd say it would be far better to include a regular anchor link that points to the specific post. Oh ... look! ... that's exactly how it's done here!

    Quote Originally Posted by Raffles View Post
    I know the standards are there to make things more rigid and ultimately usable
    Not more rigid, but more logical. And that, in turn, improves usability, because people don't have to think about ordinary things like what's clickable (a fairly basic concept on the web).

    Quote Originally Posted by Raffles View Post
    but they do make working with them more time-consuming
    Doing things properly can sometimes be more work than doing things sloppy, that's true. But there are advantages.

    Compare to English. It has lots of rules as well, both for spelling and for grammar. You have to think about the proper order of words in a sentence, so that it will make sense to the reader. And you will have to care about spelling to reduce the risk of misunderstanding.

    othrys i rit lik this n its much simplr but ud hav a hard tim reedn it

    Quote Originally Posted by Raffles View Post
    Sometimes I feel like I'm sacrificing some design aspects for the sake of keeping my markup semantically correct. Which one is more important?
    For a user without any disability, with a mainstream browser with all the plugins and everything enabled, the design might be more important.

    For anyone outside this group (and that includes 'users' like Google), the semantics can sometimes be more important.
    Birnam wood is come to Dunsinane

  17. #17
    CSS & JS/DOM Adept bronze trophy
    Join Date
    Mar 2005
    Location
    USA
    Posts
    5,482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Over the last two or three years, I've seen several people ask how to make a section of a page into one big link. From a usability standpoint, it's easier to click larger targets, however, HTML doesn't allow for this and using CSS to do this is a nasty hack. This is an enhancement that should be done with JavaScript if done at all.

    Quote Originally Posted by justjon View Post
    Particularity true for small forms, like a quick search form where you might only have one text input. You end up with a label, a fieldset and a legend for one input. A bit overkill IMO.
    The legend might be helpful to someone/something that can't see the page and can only read the text in it. You can always hide it with CSS. There is also the alternative of using a <div> instead of a <fieldset>.

    Quote Originally Posted by justjon View Post
    I must admit that although standards are obviously an essential thing some of the recommendations also leave me thinking why? To me, the IE box model makes much more sense. When you have a real world padded box, where is the padding?

    To me it would make much more sense to put padding inside the box (to pad the content) and margins on the outside.
    That depends on your perspective. I suggest you read this.

    Quote Originally Posted by justjon View Post
    And then theres removing the target attribute with no real alternative. (Which is probably one of the main reasons many people have not switched to strict.) I understand the thinking, but with no real alternative were does it leave you? It just seems to make life harder sometimes with not a lot of real gain.
    The target attribute's main purpose is to be used with frames and iframes, making pages open in a new window is a secondary purpose.

    One alternative is to not force links to open in new windows. (Why can't users decide for themselves?) The other is to use JavaScript to do this, it is a behavior, is it not?
    We miss you, Dan Schulz.
    Learn CSS. | X/HTML Validator | CSS validator
    Dynamic Site Solutions
    Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.

  18. #18
    SitePoint Addict justjon's Avatar
    Join Date
    Mar 2004
    Location
    UK
    Posts
    237
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Kravvitz View Post
    The legend might be helpful to someone/something that can't see the page and can only read the text in it. You can always hide it with CSS.
    I can totally understand that legends etc would help if you had a form with more than one section, but for a single section form, or a single field form, with a search field labeled "Search", would a Fieldset and legend really make it any clearer?

    Quote Originally Posted by Kravvitz View Post
    There is also the alternative of using a <div> instead of a <fieldset>.
    I think this is the conclusion I've come to concerning simple forms. Correct me if I'm wrong, but I think a field set denotes a grouping and provides information about it and if there is no grouping then it serves no purpose and a <div> may be more appropriate.

    But then I find myself asking "Should I be adding a tag with no meaning just to get the page to validate?" I thought one of the goals of CSS and standards (sort of) was to remove redundant meaningless tags, not to add them for the sole purpose of getting pages to validate - which is the only reason I can see to add a <div> or a fieldset / legend (In this scenario).

    Quote Originally Posted by Kravvitz View Post
    That depends on your perspective. I suggest you read this.
    Point taken - that inline elements like images can't have padding on the inside. But should inline elements be allowed padding anyway? The only advantage I can see to this is to allow a gap between the inline element (an image) and its border and this could be taken care of with another property - border-padding for example.

    Quote Originally Posted by Kravvitz View Post
    The target attribute's main purpose is to be used with frames and iframes, making pages open in a new window is a secondary purpose.
    But unfortunately an extremely useful one and one that has now IMO, become a standard that users expect for external links.

    Quote Originally Posted by Kravvitz View Post
    One alternative is to not force links to open in new windows. (Why can't users decide for themselves?)
    I don't think the majority of users know how to choose for themselves and it can be a very useful indication that they are now looking at a different site and not a different page on the same site. Personally, I think that external links opening in new windows is a convention that users expect and to remove a convention like that just results in confusion and goes against the grain of usability. My opinion is that if users expect something to work in a certain way then it should work like that.

    Quote Originally Posted by Kravvitz View Post
    The other is to use JavaScript to do this, it is a behavior, is it not?
    Point taken it is behavior, but there is no real alternative. Say you do it with JavaScript (which is a right pain for something that was previously very easy) and then mark the link somehow so users know it will open in a new window. What happens when a user with JavaScript disabled clicks the link? Fair enough the link will still work, but it won't open in a new window as expected, which results in a confused user who assumes your site doesn't work properly - Not ideal.

    Another issue with removing ALL behavior to JavaScript (even basic stuff like this) is that people with no JavaScript can't use any of your behavior, which just excludes people from functionality that was previously available. What was the real benefit of depreciating it? I can't see any for the user and I certainly can't see any for the developer. Was it really doing any harm or has removing it just created extra, unnecessary work? Also, if loading a page in a new window is behavior, then it could be argued that getting the current window to load a new page is also behavior. Surely we're not going to remove links as well.

    Anyway, if you've read this far I apologise for the rant but it just seems that sometimes the specs are so clear cut with no apparent reason apart from being clear cut.
    Last edited by justjon; Dec 12, 2006 at 05:35.

  19. #19
    I meant that to happen silver trophybronze trophy Raffles's Avatar
    Join Date
    Sep 2005
    Location
    Tanzania
    Posts
    4,662
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    I haven't tried, but I seriously doubt that. If that is true, FF is in flagrant violation with the HTML specification.
    I first noticed this at http://www.facebook.com . The Register and Tour links at the bottom are anchors containing paragraphs. And I just did a small test putting a div inside an anchor and the whole thing becomes clickable. My god, Firefox violates standards! That said, it is doing what one would expect from a div inside an anchor, however wrong it may be.

    Quote Originally Posted by AutisticCuckoo View Post
    Sounds like a behavioural issue to me. Thus: JavaScript.

    Why would you want to do something like that?
    How would you convey to the user (who may not have a user agent that supports CSS) that the whole post is clickable?

    I'd say it would be far better to include a regular anchor link that points to the specific post. Oh ... look! ... that's exactly how it's done here!
    Yes, I agree that's a better way to do it, I was just presenting that as a hypothetical situation... where visual appeal may be more important to the designer than usability!

    Quote Originally Posted by AutisticCuckoo View Post
    Doing things properly can sometimes be more work than doing things sloppy, that's true. But there are advantages.

    Compare to English. It has lots of rules as well, both for spelling and for grammar. You have to think about the proper order of words in a sentence, so that it will make sense to the reader. And you will have to care about spelling to reduce the risk of misunderstanding.

    othrys i rit lik this n its much simplr but ud hav a hard tim reedn it
    Very true. But nobody is reading it except the people who know that View Source exists. Everyone else doesn't care. So, do we spend more time making it nicer to read for the View Source people or for those living ignorantly in bliss? The good web designer can do both, but it seems to me that's quite hard.

  20. #20
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Raffles View Post
    That said, it is doing what one would expect from a div inside an anchor, however wrong it may be.
    I wouldn't, but to my great disappointment even Opera 9 does the wrong thing.
    The spec doesn't state explicitly how invalid markup like this should be handled. One might expect an implicit </a> before the <div>, since an anchor cannot contain block-level elements.

    The problem with this sort of invalid markup is that you cannot know how the DOM tree will be constructed. Will the DIV be a sibling to the A, or a child? Not something I'd want to put money on.

    Quote Originally Posted by Raffles View Post
    Very true. But nobody is reading it except the people who know that View Source exists. Everyone else doesn't care.
    You're missing an important point here: accessibility.
    Ordinary graphical browsers may be good at recovering from invalid markup, but who's to say that assistive technologies, search engines, etc. are quite as good? Or, if they are, that they do it exactly the same way?

    You can do several things (including reformatting the user's hard drive) and still be compliant with the HTML specification, since error handling is undefined. The spec merely suggests (in a non-normative section) that user agents attempt to handle errors in a certain way.
    Birnam wood is come to Dunsinane

  21. #21
    CSS & JS/DOM Adept bronze trophy
    Join Date
    Mar 2005
    Location
    USA
    Posts
    5,482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I was under the impression that HTML parsers don't automatically close elements that don't have optional end tags.
    Quote Originally Posted by justjon View Post
    Point taken - that inline elements like images can't have padding on the inside. But should inline elements be allowed padding anyway? The only advantage I can see to this is to allow a gap between the inline element (an image) and its border and this could be taken care of with another property - border-padding for example.
    You want to add another property? Actually, they are thinking of putting something similar in CSS3.

    Quote Originally Posted by justjon View Post
    But unfortunately an extremely useful one and one that has now IMO, become a standard that users expect for external links.
    ...
    I don't think the majority of users know how to choose for themselves and it can be a very useful indication that they are now looking at a different site and not a different page on the same site. Personally, I think that external links opening in new windows is a convention that users expect and to remove a convention like that just results in confusion and goes against the grain of usability. My opinion is that if users expect something to work in a certain way then it should work like that.
    ...
    Point taken it is behavior, but there is no real alternative. Say you do it with JavaScript (which is a right pain for something that was previously very easy) and then mark the link somehow so users know it will open in a new window. What happens when a user with JavaScript disabled clicks the link? Fair enough the link will still work, but it won't open in a new window as expected, which results in a confused user who assumes your site doesn't work properly - Not ideal.
    I agree that making something work differently from what a user expects is bad. I wish more web designers/developers realized that. However, I'm not sure how users in general expect that to work. Does anyone know of any case studies done on this topic?

    Quote Originally Posted by justjon View Post
    Another issue with removing ALL behavior to JavaScript (even basic stuff like this) is that people with no JavaScript can't use any of your behavior, which just excludes people from functionality that was previously available. What was the real benefit of depreciating it? I can't see any for the user and I certainly can't see any for the developer. Was it really doing any harm or has removing it just created extra, unnecessary work? Also, if loading a page in a new window is behavior, then it could be argued that getting the current window to load a new page is also behavior. Surely we're not going to remove links as well.
    Links and form controls has inherent behaviors. JavaScript is used to add additional behaviors to web pages.

    I would argue if you use a little unobtrusive JavaScript, making links open in new windows is no more difficult than using the target attribute. I can give you links to a few such scripts, if you want.
    We miss you, Dan Schulz.
    Learn CSS. | X/HTML Validator | CSS validator
    Dynamic Site Solutions
    Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.

  22. #22
    SitePoint Addict justjon's Avatar
    Join Date
    Mar 2004
    Location
    UK
    Posts
    237
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Kravvitz View Post
    I'm glad they're listening to my recommendations.

    Quote Originally Posted by Kravvitz View Post
    I agree that making something work differently from what a user expects is bad. I wish more web designers/developers realized that. However, I'm not sure how users in general expect that to work. Does anyone know of any case studies done on this topic?
    I bet that if one exists it would show that users (of the ones that have an opinion) expect external links to open in new windows. Just going on the amount of time target=blank has been around for and how often it's used for external links.

    Quote Originally Posted by Kravvitz View Post
    Links and form controls has inherent behaviors. JavaScript is used to add additional behaviors to web pages.
    I think that part of the link itself should be "where to load it" as well as "what to load" and this info should be in the link along with the URL not hidden with JavaScript for only some people to see. It think it has a semantic purpose, it describes the link, it says "this link is external" or "this goes somewhere completely different to the set of pages you are currently viewing". Granted target may not of been in the original spec (?) but neither was a lot of stuff.

    Quote Originally Posted by Kravvitz View Post
    I would argue if you use a little unobtrusive JavaScript, making links open in new windows is no more difficult than using the target attribute. I can give you links to a few such scripts, if you want.
    Thank you, please post the links, but I don't think any JavaScript could be as easy as target="_blank". Anyway, there should be no need. Was there any real practical reason to depreciate it other than to fit it into the behavior box?
    Last edited by justjon; Dec 12, 2006 at 18:36.


Bookmarks

Posting Permissions

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