RE: [WSG] IE and the button element
Which IS semantic and separates content (the link) from presentation (a button). On Mon, February 23, 2009 10:56 pm, Chris F.A. Johnson wrote: On Tue, 24 Feb 2009, John Horner wrote: Thanks for all the discussion so far. It seems I'll have to re-code. I will definitely not be using Javascript. It seems entirely logical to me that there should be such a thing as a button, which can exist outside a form, which has an HREF attribute or can be wrapped in an anchor. Why? All you need do is style the anchor element. -- Chris F.A. Johnson, webmaster http://woodbine-gerrard.com = Do not reply to the From: address; use Reply-To: Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] IE and the button element
Which IS semantic and separates content (the link) from presentation (a button). On Mon, February 23, 2009 10:56 pm, Chris F.A. Johnson wrote: On Tue, 24 Feb 2009, John Horner wrote: Thanks for all the discussion so far. It seems I'll have to re-code. I will definitely not be using Javascript. It seems entirely logical to me that there should be such a thing as a button, which can exist outside a form, which has an HREF attribute or can be wrapped in an anchor. Why? All you need do is style the anchor element. -- Chris F.A. Johnson, webmaster http://woodbine-gerrard.com = Do not reply to the From: address; use Reply-To: Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] IE and the button element
On Tue, 24 Feb 2009, John Horner wrote: Advantages of using buttons: 1) Button elements don't need styling, they take their styling from the user's operating system, which they are, I assume, familiar and comfortable with. I won't be reinventing the wheel. Button elements are styled by the browser. 2) Anchor elements don't have a built-in disabled mode, buttons do, Disabled mode is just more styling. and again the styling comes directly from the OS and the user is familiar with it. Anchor elements are styled by the browser. -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Chris F.A. Johnson Sent: Tuesday, 24 February 2009 9:56 AM To: wsg@webstandardsgroup.org Subject: RE: [WSG] IE and the button element On Tue, 24 Feb 2009, John Horner wrote: Thanks for all the discussion so far. It seems I'll have to re-code. I will definitely not be using Javascript. It seems entirely logical to me that there should be such a thing as a button, which can exist outside a form, which has an HREF attribute or can be wrapped in an anchor. Why? All you need do is style the anchor element. -- Chris F.A. Johnson, webmaster http://woodbine-gerrard.com = Do not reply to the From: address; use Reply-To: Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** Please consider the environment before printing this e-mail. The information contained in this email and any attachment is confidential and may contain legally privileged or copyright material. It is intended only for the use of the addressee(s). If you are not the intended recipient of this email, you are not permitted to disseminate, distribute or copy this email or any attachments. If you have received this message in error, please notify the sender immediately and delete this email from your system. The ABC does not represent or warrant that this transmission is secure or virus free. Before opening any attachment you should check for viruses. The ABC's liability is limited to resupplying any email and attachments. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Chris F.A. Johnson, webmaster http://woodbine-gerrard.com = Do not reply to the From: address; use Reply-To: Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] IE and the button element
Chris F.A. Johnson On Tue, 24 Feb 2009, John Horner wrote: 1) Button elements don't need styling, they take their styling from the user's operating system, which they are, I assume, familiar and comfortable with. I won't be reinventing the wheel. Button elements are styled by the browser. But the browser should, in normal circumstances, heed any OS preferences (or at least, unless explicitly styled differently, present all those controls with a consistent look and feel). 2) Anchor elements don't have a built-in disabled mode, buttons do, Disabled mode is just more styling. It's also a functional change, as it disables the button (makes it unclickable and does not trigger the specified onclick action). and again the styling comes directly from the OS and the user is familiar with it. Anchor elements are styled by the browser. I believe John meant the styling of the 'disabled' button, so same as above applies. P Patrick H. Lauke Web Editor Enterprise Development University of Salford Room 113, Faraday House Salford, Greater Manchester M5 4WT UK T +44 (0) 161 295 4779 webmas...@salford.ac.uk www.salford.ac.uk A GREATER MANCHESTER UNIVERSITY *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] IE and the button element
On Tue, February 24, 2009 1:54 am, John Horner wrote: Advantages of using buttons: 1) Button elements don't need styling, they take their styling from the user's operating system, which they are, I assume, familiar and comfortable with. I won't be reinventing the wheel. Actually, the specific purpose of the button is to allow one to have buttons that *don't* look like ordinary buttons: Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content. http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON In other words, the purpose of the button element is to allow the functionality of a button without imposing the appearance of one. 2) Anchor elements don't have a built-in disabled mode, buttons do, and again the styling comes directly from the OS and the user is familiar with it. If it doesn't do anything (that is, it is disabled), then it shouldn't be an anchor element. An anchor element used as a hyperlink has a semantic meaning. If that meaning should not be attached to a piece of content - e.g. the words Next page when there is no next page - then the link should be absent. While there may be good usability reasons for retaining the content, such as maintaining consistency of interface, to think in terms of providing functionality and then disabling it is to put the cart before the horse: instead, only provide the functionality when it is functional. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
Nick Fitzsimons wrote: Actually, the specific purpose of the button is to allow one to have buttons that *don't* look like ordinary buttons: Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content. http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON No, you can have richer rendering possibilities without giving up looking like ordinary buttons. The typical case is a button with an icon on it. http://www.packagekit.org/img/kpk-confirm.png for example. -- David Dorward http://dorward.me.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
On Tue, February 24, 2009 10:57 am, David Dorward wrote: Nick Fitzsimons wrote: Actually, the specific purpose of the button is to allow one to have buttons that *don't* look like ordinary buttons: Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content. http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON No, you can have richer rendering possibilities without giving up looking like ordinary buttons. The typical case is a button with an icon on it. http://www.packagekit.org/img/kpk-confirm.png for example. True; I didn't phrase that very well. The point I was really trying to make is that to suggest that the value of the button element is that it *looks* like a button is to miss the point; the point is that it *behaves* like a button. In other words its purpose is to provide a specific kind of functionality, not a specific kind of appearance. Cheers, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
On Feb 24, 2009, at 7:28 AM, Nick Fitzsimons wrote: the point is that it *behaves* like a button. In other words its purpose is to provide a specific kind of functionality and if I remember correctly, the functionality to be provided as originally stated was a link to a next page. I'd suggest that that specific functionality - linking - is adequately provided by the anchor tag, and it is inappropriate to use a button (of any kind) to provide that functionality. (And I believe it's irrelevant that various screens specific to an OS use buttons to progress from screen to screen, e.g. MacOS's use of a Continue button during software installation. If it's a web site provide a consistent, standard *web* interface). $0.02 Andrew http://www.andrewmaben.net and...@andrewmaben.com In a well designed user interface, the user should not need instructions. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
John Horner wrote: I adopted the use of the button element in an application I'm working on, used like this: a href=foo.htmlbuttonfoo/button/a one main reason I liked buttons is that they can be disabled with an attribute, which was useful for things like keeping a next button everywhere, so that the layout was consistent, but disabling it when there was no next page to go to. Also I could build up the right URLs (complex ones using query strings) which populate the HREFs on the server side and have a click which just followed that link rather than submitting a form, which would mean using a number of hidden fields and branching based on the button name. This is valid HTML, though it might be an unorthodox approach, and it worked well until I tested the code in IE. In IE6 it just plain doesn't work, the buttons don't respond to clicks. Unless they're set to disabled in which case they *do* work. Any ideas or workarounds? Or am I just going to have to re-code everything? Buttons were mainly designed as triggers for javascript behaviour, as they don't really do anything. You'll either just have to use plain links (which you could always style similarly to your submit buttons) or only use submit buttons with name attributes and handle them accordingly server-side eg: input type=submit name=nextButton value=Next / input type=submit name=backButton value=Back / ?php if (isset($_POST['nextButton']) { header('location: /nextpage.php'); } if (isset($_POST['backButton']) { header('location: /prevpage.php'); } ? These are the only non-javascript cross browser solutions to your problem that I know of. -Rob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
Rob wrote: Buttons were mainly designed as triggers for javascript behaviour, I disagree, if you look at the original HTML 4 material, you will see that the button element promoted as an improved input element. Why not form action=foo.html type=postbutton type=submitfoo/button/form -- Nick Cowie http://nickcowie.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
IMHO, not very semantic in nature. We need the button element to be able to carry a valid link-type attribute. Enclosing it in a form just don't cut it. It must be able to stand by itself as an alternative means to activate a hyperlink, as another aspect of its functionality. Med vennlig hilsen / Kind regards, Frank M. Palinkas Technical Writer, Opera Software http://dev.opera.com/articles/accessibility/ On Mon, Feb 23, 2009 at 1:43 PM, Nick Cowie cowie.n...@gmail.com wrote: Rob wrote: Buttons were mainly designed as triggers for javascript behaviour, I disagree, if you look at the original HTML 4 material, you will see that the button element promoted as an improved input element. Why not form action=foo.html type=postbutton type=submitfoo/button/form -- Nick Cowie http://nickcowie.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
Frank Palinkas wrote: http://dev.opera.com/articles/accessibility/ On Mon, Feb 23, 2009 at 1:43 PM, Nick Cowie cowie.n...@gmail.com mailto:cowie.n...@gmail.com wrote: Rob wrote: Buttons were mainly designed as triggers for javascript behaviour, I disagree, if you look at the original HTML 4 material, you will see that the button element promoted as an improved input element. Why not form action=foo.html type=postbutton type=submitfoo/button/form -- Nick Cowie http://nickcowie.com IMHO, not very semantic in nature. We need the button element to be able to carry a valid link-type attribute. Enclosing it in a form just don't cut it. It must be able to stand by itself as an alternative means to activate a hyperlink, as another aspect of its functionality. Med vennlig hilsen / Kind regards, Frank M. Palinkas Technical Writer, Opera Software http://dev.opera.com/articles/accessibility/ I've asked on the WHATWG mailing list before whether they will consider adding the href attribute to buttons and inputs in HTML5 but no one really noticed it. Maybe someone with a bit more clout could do the same? Also thanks for educating me Nick, the button element is an improvement semantically and more useful from a CSS point of view aswell. I hadn't considered that. In terms of an immediate solution it look like there isn't one without using CSS and :hover to make the links in question and submit buttons look and behave the same way. -Rob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
Indeed, and that's where the problem lies. I don't believe that using button (which must be placed within a form) purely for _hyperlink_ purposes is good practice or semantically correct. My apologies, I may have gotten a bit ahead of myself. Med vennlig hilsen / Kind regards, Frank M. Palinkas Technical Writer, Opera Software http://dev.opera.com/articles/accessibility/ On Mon, Feb 23, 2009 at 3:10 PM, michael.brocking...@bt.com wrote: Surely the button element is REQUIRED to be enclosed in a form ?? Mike -- *From:* li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] *On Behalf Of *Frank Palinkas *Sent:* 23 February 2009 12:56 *To:* wsg@webstandardsgroup.org *Subject:* Re: [WSG] IE and the button element IMHO, not very semantic in nature. We need the button element to be able to carry a valid link-type attribute. Enclosing it in a form just don't cut it. It must be able to stand by itself as an alternative means to activate a hyperlink, as another aspect of its functionality. Med vennlig hilsen / Kind regards, Frank M. Palinkas Technical Writer, Opera Software http://dev.opera.com/articles/accessibility/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
On Mon, Feb 23, 2009 at 2:10 PM, michael.brocking...@bt.com wrote: Surely the button element is REQUIRED to be enclosed in a form ?? Is it though? Just looking at HTML 4.01, I don't think it's forbidden/invalid to have form elements outside of form http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON and even in HTML 5 I don't get the impression they have to http://www.w3.org/TR/html5/forms.html#the-button-element (Sorry, genuine question...not trying to be facetious). P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com | http://flickr.com/photos/redux/ __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] IE and the button element
That's part of why I posed it as a question, not as a statement. Though, from what I recall, part of the problem was that the mechanism of a DTD was not capable of making such a requirement, and the DTD was regarded as more definitive than the written spec. Mike -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Patrick H. Lauke Sent: 23 February 2009 14:52 To: wsg@webstandardsgroup.org Subject: Re: [WSG] IE and the button element On Mon, Feb 23, 2009 at 2:10 PM, michael.brocking...@bt.com wrote: Surely the button element is REQUIRED to be enclosed in a form ?? Is it though? Just looking at HTML 4.01, I don't think it's forbidden/invalid to have form elements outside of form http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON and even in HTML 5 I don't get the impression they have to http://www.w3.org/TR/html5/forms.html#the-button-element (Sorry, genuine question...not trying to be facetious). P -- Patrick H. Lauke __ re*dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com | http://flickr.com/photos/redux/ __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
2009/2/23 Frank Palinkas fmpalin...@gmail.com: IMHO, not very semantic in nature. We need the button element to be able to carry a valid link-type attribute. Enclosing it in a form just don't cut it. We are talking HTML 4 here, so to have a link you have to use an anchor tag, a form or javascript. Frank is correct, a link is semantically correct way to go and to get the behaviour John wants, he is better off using javascript than a button. Though I don't know of a way of disabling a link with javascript The form option, gives more control, but is less semantically correct than a plain link and will work with javascript disabled. You can use a button outside of a form and attached javascript to it. This might not be semantically correct, does everything John wants. Only problem does not work with javascript disabled. -- Nick Cowie http://nickcowie.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
Patrick H. Lauke wrote: On Mon, Feb 23, 2009 at 2:10 PM, michael.brocking...@bt.com wrote: Surely the button element is REQUIRED to be enclosed in a form ?? Is it though? Just looking at HTML 4.01, I don't think it's forbidden/invalid to have form elements outside of form http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON and even in HTML 5 I don't get the impression they have to http://www.w3.org/TR/html5/forms.html#the-button-element (Sorry, genuine question...not trying to be facetious). P I don't really know how toread the DTDs properly but the following from the HTML4 Strict Doctype seems to suggest they need to be inside a form. !ELEMENT BUTTON http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON - - (%flow; http://www.w3.org/TR/html401/sgml/dtd.html#flow)* -(A|%formctrl; http://www.w3.org/TR/html401/sgml/dtd.html#formctrl|FORM|FIELDSET) -- push button -- I did some tests anyway to be sure http://www.sanchothefat.com/dev/sfhelp/validations.php and Michael is exactly right. -Rob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
Nick Cowie wrote: 2009/2/23 Frank Palinkas fmpalin...@gmail.com: IMHO, not very semantic in nature. We need the button element to be able to carry a valid link-type attribute. Enclosing it in a form just don't cut it. We are talking HTML 4 here, so to have a link you have to use an anchor tag, a form or javascript. Frank is correct, a link is semantically correct way to go and to get the behaviour John wants, he is better off using javascript than a button. Though I don't know of a way of disabling a link with javascript You can remove the href attribute and save it in a variable to add back later, though I don't think that's John's problem. Having the buttons disabled was just so he didn't have to remove them when they weren't needed to keep the design consistent. You could use a span element instead with a class name eg. span class=disabledNext/span. Don't forget if it's a form you probably don't want to make it rely on javascript. The form option, gives more control, but is less semantically correct than a plain link and will work with javascript disabled. You can use a button outside of a form and attached javascript to it. This might not be semantically correct, does everything John wants. Only problem does not work with javascript disabled. Unfortunately not valid HTML according to my tests but it will work. Alternatively you can use syntax such as button type=button id=nextButtonNext/button and attach javascript with that. The type=button attribute means nothing will happen when you click it unless you attach behaviour via JS. -Rob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
Nick Cowie wrote: Frank is correct, a link is semantically correct way to go and to get the behaviour John wants, he is better off using javascript than a button. Though I don't know of a way of disabling a link with javascript ? capture the click event and stop it. In the bad old obtrusive days it meant including something like: a href=/foo onclick=return falsefoo/a :: but we have more advanced ways now :-) Search on the term event bubbling, for instance... -- Hassan Schroeder - has...@webtuitive.com Webtuitive Design === (+1) 408-621-3445 === http://webtuitive.com dream. code. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
On Mon, Feb 23, 2009 at 3:39 PM, Robert O'Rourke r...@sanchothefat.com wrote: I don't really know how toread the DTDs properly Yeah, it's obscure for sure. !ELEMENT BUTTON http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON - - (%flow; http://www.w3.org/TR/html401/sgml/dtd.html#flow)* -(A|%formctrl; http://www.w3.org/TR/html401/sgml/dtd.html#formctrl|FORM|FIELDSET) -- push button -- Using Toolman's excellent 2005 article The Art of Reading a DTD http://www.autisticcuckoo.net/archive.php?id=2005/05/01/art-of-reading-dtd I think the above can be decyphered as: !ELEMENT BUTTON - - (%flow;)* -(A|%formctrl;|FORM|FIELDSET) -- push button -- opening and closing tags are required, it can contain any number of flow elements (block or inline), but can't CONTAIN links, other form controls, forms or fieldsets. P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com | http://flickr.com/photos/redux/ __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
There was a wee bug (or two!) in that link I posted, very sorry. http://www.sanchothefat.com/dev/sfhelp/validations.php If you validate that page now it works with the buttons outside of a form. They do however need to be contained by a block element such as a div. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
Patrick H. Lauke wrote: On Mon, Feb 23, 2009 at 3:39 PM, Robert O'Rourke r...@sanchothefat.com wrote: I don't really know how toread the DTDs properly Yeah, it's obscure for sure. !ELEMENT BUTTON http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON - - (%flow; http://www.w3.org/TR/html401/sgml/dtd.html#flow)* -(A|%formctrl; http://www.w3.org/TR/html401/sgml/dtd.html#formctrl|FORM|FIELDSET) -- push button -- Using Toolman's excellent 2005 article The Art of Reading a DTD http://www.autisticcuckoo.net/archive.php?id=2005/05/01/art-of-reading-dtd I think the above can be decyphered as: !ELEMENT BUTTON - - (%flow;)* -(A|%formctrl;|FORM|FIELDSET) -- push button -- opening and closing tags are required, it can contain any number of flow elements (block or inline), but can't CONTAIN links, other form controls, forms or fieldsets. P Thanks Patrick, that's a really useful link. So I guess it's just up to John whether to use javascript or regular links now. -Rob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] IE and the button element
Thanks for all the discussion so far. It seems I'll have to re-code. I will definitely not be using Javascript. It seems entirely logical to me that there should be such a thing as a button, which can exist outside a form, which has an HREF attribute or can be wrapped in an anchor. But if there isn't, I guess I have to accept that. Please consider the environment before printing this e-mail. The information contained in this email and any attachment is confidential and may contain legally privileged or copyright material. It is intended only for the use of the addressee(s). If you are not the intended recipient of this email, you are not permitted to disseminate, distribute or copy this email or any attachments. If you have received this message in error, please notify the sender immediately and delete this email from your system. The ABC does not represent or warrant that this transmission is secure or virus free. Before opening any attachment you should check for viruses. The ABC's liability is limited to resupplying any email and attachments. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] IE and the button element
On Tue, 24 Feb 2009, John Horner wrote: Thanks for all the discussion so far. It seems I'll have to re-code. I will definitely not be using Javascript. It seems entirely logical to me that there should be such a thing as a button, which can exist outside a form, which has an HREF attribute or can be wrapped in an anchor. Why? All you need do is style the anchor element. -- Chris F.A. Johnson, webmaster http://woodbine-gerrard.com = Do not reply to the From: address; use Reply-To: Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE and the button element
John, I like your approach - I think I might start using it. IMO - button means button whether it is in a form or not. And button has more meaning than input type="button|submit". Don't give into design by committee, just look at how it ruined Tim Berner-Lee's original vision for the web. He is only starting to claw some of it back with his recent Semantic Web work. John Horner wrote: Thanks for all the discussion so far. It seems I'll have to re-code. I will definitely not be using _javascript_. It seems entirely logical to me that there should be such a thing as a button, which can exist outside a form, which has an HREF attribute or can be wrapped in an anchor. But if there isn't, I guess I have to accept that. Please consider the environment before printing this e-mail. The information contained in this email and any attachment is confidential and may contain legally privileged or copyright material. It is intended only for the use of the addressee(s). If you are not the intended recipient of this email, you are not permitted to disseminate, distribute or copy this email or any attachments. If you have received this message in error, please notify the sender immediately and delete this email from your system. The ABC does not represent or warrant that this transmission is secure or virus free. Before opening any attachment you should check for viruses. The ABC's liability is limited to resupplying any email and attachments. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Rob Turner Company Leader www. f l e x a d a t a .com +1 415 448 7652 +61 7 3040 1337 ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***begin:vcard fn:Rob Turner n:Turner;Rob org:Flexa Pty Ltd email;internet:r...@flexadata.com title:Company Leader tel;work:+61 7 3040 1337 tel;cell:+61 4 0115 9060 x-mozilla-html:TRUE url:http://flexadata.com version:2.1 end:vcard
Re: [WSG] IE and the button element
Agree. It is very easy to style the anchor element. Chris F.A. Johnson wrote: On Tue, 24 Feb 2009, John Horner wrote: Thanks for all the discussion so far. It seems I'll have to re-code. I will definitely not be using Javascript. It seems entirely logical to me that there should be such a thing as a button, which can exist outside a form, which has an HREF attribute or can be wrapped in an anchor. Why? All you need do is style the anchor element. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] IE and the button element
Advantages of using buttons: 1) Button elements don't need styling, they take their styling from the user's operating system, which they are, I assume, familiar and comfortable with. I won't be reinventing the wheel. 2) Anchor elements don't have a built-in disabled mode, buttons do, and again the styling comes directly from the OS and the user is familiar with it. -Original Message- From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Chris F.A. Johnson Sent: Tuesday, 24 February 2009 9:56 AM To: wsg@webstandardsgroup.org Subject: RE: [WSG] IE and the button element On Tue, 24 Feb 2009, John Horner wrote: Thanks for all the discussion so far. It seems I'll have to re-code. I will definitely not be using Javascript. It seems entirely logical to me that there should be such a thing as a button, which can exist outside a form, which has an HREF attribute or can be wrapped in an anchor. Why? All you need do is style the anchor element. -- Chris F.A. Johnson, webmaster http://woodbine-gerrard.com = Do not reply to the From: address; use Reply-To: Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** Please consider the environment before printing this e-mail. The information contained in this email and any attachment is confidential and may contain legally privileged or copyright material. It is intended only for the use of the addressee(s). If you are not the intended recipient of this email, you are not permitted to disseminate, distribute or copy this email or any attachments. If you have received this message in error, please notify the sender immediately and delete this email from your system. The ABC does not represent or warrant that this transmission is secure or virus free. Before opening any attachment you should check for viruses. The ABC's liability is limited to resupplying any email and attachments. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] IE and the button element
I adopted the use of the button element in an application I'm working on, used like this: a href=foo.htmlbuttonfoo/button/a one main reason I liked buttons is that they can be disabled with an attribute, which was useful for things like keeping a next button everywhere, so that the layout was consistent, but disabling it when there was no next page to go to. Also I could build up the right URLs (complex ones using query strings) which populate the HREFs on the server side and have a click which just followed that link rather than submitting a form, which would mean using a number of hidden fields and branching based on the button name. This is valid HTML, though it might be an unorthodox approach, and it worked well until I tested the code in IE. In IE6 it just plain doesn't work, the buttons don't respond to clicks. Unless they're set to disabled in which case they *do* work. Any ideas or workarounds? Or am I just going to have to re-code everything? Please consider the environment before printing this e-mail. The information contained in this email and any attachment is confidential and may contain legally privileged or copyright material. It is intended only for the use of the addressee(s). If you are not the intended recipient of this email, you are not permitted to disseminate, distribute or copy this email or any attachments. If you have received this message in error, please notify the sender immediately and delete this email from your system. The ABC does not represent or warrant that this transmission is secure or virus free. Before opening any attachment you should check for viruses. The ABC's liability is limited to resupplying any email and attachments. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***