Re: [WSG] Chrome and Safari
Seeing as though Google's new Chrome browser uses the same rendering engine as Apple's Safari, would it be acceptable to test browser layout issues in Chrome and assume the same CSS solutions apply in Safari? Does anyone know of any distinct differences in CSS rendering between the 2 browsers? I don't know of any issues now, but as a long term solution I would assume that the two browsers will get out of synch at some stage in terms of the specific version of teh rendering engine. Also as other people have noted the whole browser is more than just the rendering engine; so it's prudent to test them separately. cheers, Ben -- --- http://weblog.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Browser loading images issue
Working fine first load Kristine in the UK Winxp: SP2 1680x1050 IE6 Kate Forum: http://princess.invisionzone.com/index.php Borneo: http://simplyborneo.com/borneosnaturaltreasures/ - Original Message - From: Kristine Cummins [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Wednesday, October 15, 2008 7:55 PM Subject: [WSG] Browser loading images issue Hi all, I'm still having this issue as the client is contacting about images simply not showing up but on refresh, they do. Frustrating as I don't know how to solve this issue. The page is http://www.cpwrehab.com/employee_listing.html Stylesheet is: http://www.cpwrehab.com/styles.css Thanks, Kristine -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristine Cummins Sent: Friday, October 10, 2008 11:28 AM To: wsg@webstandardsgroup.org Subject: [WSG] Browser loading images issue I noticed that sometimes some images will not load upon visiting a page while others on the page will, but when I hit the browser's refresh button, the image will load. This was happening in IE, but no other browser. Anyone have any ideas how to fix this issue? Thanks, Kristine *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Chrome and Safari
Not only JS, there are differences in CSS as well. Shadows appear, but kinda buggy, not as it should. text-shadow and box-shadow. The rounded borders are not antialiased (as in aliased or pixelated) in Chrome whereas FF3 and Safari handle it correctly. And font-face doesn't work at all, whereas it does in safari. I know these properties are not part of css2.1, so it's acceptable, but good to know. That was a few weeks ago as well. Maybe it's been fixed... I haven't checked today. I've heard about problems with png as well, but I haven;t seen any problems on that side of things. There are probably other things that are different in Chrome than in Safari. Cheers, Johan Douma 2008/10/16 Ben Buchanan [EMAIL PROTECTED] Seeing as though Google's new Chrome browser uses the same rendering engine as Apple's Safari, would it be acceptable to test browser layout issues in Chrome and assume the same CSS solutions apply in Safari? Does anyone know of any distinct differences in CSS rendering between the 2 browsers? I don't know of any issues now, but as a long term solution I would assume that the two browsers will get out of synch at some stage in terms of the specific version of teh rendering engine. Also as other people have noted the whole browser is more than just the rendering engine; so it's prudent to test them separately. cheers, Ben -- --- http://weblog.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] labels as input wrappers + h6 in place of legend
I am looking for feedback on two questions, based on the simple form snippet below. fieldset legendbPersonal Details/b/legend label for=nameName:/label input id=name type=text name=name size=30 br label for=idID Number:/label input id=id type=text name=id number size=10 /fieldset Question 1: Is it acceptable, or advisable, to use a header tag h6 in place of the legend in order to get cross-browsers consistency when dealing with complex form styling? How much impact might this have on accessibility, if any? Question 2: I don't see many folks using the label as a wrapper to contain the input. Any reason not to do this? It allows for the br / to be removed via display: block; on the label tag as well as allowing users (of most browsers) to click on a much larger label to select the accompanying input. fieldset h6Personal Details/h6 label for=nameName: input id=name type=text name=name size=30 /label label for=idID Number: input id=id type=text name=id number size=10 /label /fieldset *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
Jason Grant wrote: Ok you got both of these quite wrong for following reasons: In the first instance you shouldn't use b or br / at all. In the second instance you should not wrap input into label as the label should quite clearly be used for denoting a label of an input field and not the input field itself. Not so: When [the for attribute is] absent, the label being defined is associated with the element's contents. LABEL First Name INPUT type=text name=firstname /LABEL -- http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1 -- David Dorward http://dorward.me.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
I've always used label arount input fields labeltext: input type=text //label without the for= attribute. I've never had problems with it, and I don't think I've ever seen any recommendation against it. Johan Douma [EMAIL PROTECTED] 2008/10/16 David Dorward [EMAIL PROTECTED] Jason Grant wrote: Ok you got both of these quite wrong for following reasons: In the first instance you shouldn't use b or br / at all. In the second instance you should not wrap input into label as the label should quite clearly be used for denoting a label of an input field and not the input field itself. Not so: When [the for attribute is] absent, the label being defined is associated with the element's contents. LABEL First Name INPUT type=text name=firstname /LABEL -- http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1 -- David Dorward http://dorward.me.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
This is the first time for me to see someone proposing use of labelinput //label structure.I agree that ol is not strictly necessary and that a form is not necessarily a list, but one could argue that you are dealing with a list of form input elements. Read more why I do this here: http://www.alistapart.com/articles/prettyaccessibleforms Using a list also gives better control over the look as I never do: float:left; clear: left; since that proves to cause cross browser issues more often than not. Cheers, Jason On Thu, Oct 16, 2008 at 1:23 PM, Johan Douma [EMAIL PROTECTED] wrote: I've always used label arount input fields labeltext: input type=text //label without the for= attribute. I've never had problems with it, and I don't think I've ever seen any recommendation against it. Johan Douma [EMAIL PROTECTED] 2008/10/16 David Dorward [EMAIL PROTECTED] Jason Grant wrote: Ok you got both of these quite wrong for following reasons: In the first instance you shouldn't use b or br / at all. In the second instance you should not wrap input into label as the label should quite clearly be used for denoting a label of an input field and not the input field itself. Not so: When [the for attribute is] absent, the label being defined is associated with the element's contents. LABEL First Name INPUT type=text name=firstname /LABEL -- http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1 -- David Dorward http://dorward.me.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com [EMAIL PROTECTED] +44 (0)7748 591 770 Company no.: 5587469 www.twitter.com/flexewebs www.linkedin.com/in/flexewebs *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] labels as input wrappers + h6 in place of legend
Johan – what you are describing is the correct usage in that scenario. Thanks, Tatham Oddie callto:+61414275989 call:+61414275989, callto:+61280113982 call:+61280113982, skype:tathamoddie?call skype:tathamoddie, msnim:[EMAIL PROTECTED] msn:[EMAIL PROTECTED], http://tatham.oddie.com.au/ tatham.oddie.com.au From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johan Douma Sent: Thursday, 16 October 2008 11:23 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] labels as input wrappers + h6 in place of legend I've always used label arount input fields labeltext: input type=text //label without the for= attribute. I've never had problems with it, and I don't think I've ever seen any recommendation against it. Johan Douma [EMAIL PROTECTED] 2008/10/16 David Dorward [EMAIL PROTECTED] Jason Grant wrote: Ok you got both of these quite wrong for following reasons: In the first instance you shouldn't use b or br / at all. In the second instance you should not wrap input into label as the label should quite clearly be used for denoting a label of an input field and not the input field itself. Not so: When [the for attribute is] absent, the label being defined is associated with the element's contents. LABEL First Name INPUT type=text name=firstname /LABEL -- http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1 -- David Dorward http://dorward.me.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Flash replace Javascript in Future?
Hi Guys/Gals, I would like to get some opinion from you all, that would Flash 10 or ++ will replace JavaScript in the future? According to this blog : http://ajaxian.com/archives/flash-10-and-the-bad-news-for-javascript-interaction . I found that alot of media website started to replace Javascript to play their audio/video and of course Flash required to be install as third party plugin and had to be updated (which is annoying). Did you guys/gals use alot of flash in your past projects that you were working with? Cheers, Charles. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
Johan Douma wrote: I've always used label arount input fields labeltext: input type=text //label without the for= attribute. I've never had problems with it, and I don't think I've ever seen any recommendation against it. There's a discussion about some problems with that pattern at: http://www.w3.org/TR/WCAG20-TECHS/H44.html and http://green-beast.com/blog/?p=254 I'd suggest just using: div class=fieldlabel for=field-idLabel text:/label input id=field-id name=field-key type=text/div (substituting whatever you feel most appropriate for DIV) -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Flash replace Javascript in Future?
On Thu, Oct 16, 2008 at 9:27 AM, Charles Ling [EMAIL PROTECTED] wrote: Hi Guys/Gals, I would like to get some opinion from you all, that would Flash 10 or ++ will replace JavaScript in the future? According to this blog : http://ajaxian.com/archives/flash-10-and-the-bad-news-for-javascript-interaction. I found that alot of media website started to replace Javascript to play their audio/video and of course Flash required to be install as third party plugin and had to be updated (which is annoying). Did you guys/gals use alot of flash in your past projects that you were working with? I think you misunderstood the article big-time. It's saying that Flash 10 is planned to not support DHTML scripting access, which means you won't be able to control a flash video via Javascript. That just means that a lot of interfaces where Flash is *not* currently sufficient (such as Yahoo Video) or where Flash is used as a workaround to assist Javascript/HTML (such as batch uploading in Wordpress) will no longer be possible, at which point people will need to find a way to make these things work with Javascript alone, or convince Adobe to change their minds about this. As for whether or not Javascript is ever going away, try using web apps like Gmail or Facebook without Javascript and see what you lose. The reason why Javascript has gained so much traction in the past few years is because you can do a heck of a lot with it before you have to load up a third-party plugin. -- -- Christian Montoya christianmontoya.net *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Flash replace Javascript in Future?
Charles Ling wrote: I would like to get some opinion from you all, that would Flash 10 or ++ will replace JavaScript in the future? According to this blog : http://ajaxian.com/archives/flash-10-and-the-bad-news-for-javascript-interaction. I'm not entirely sure Christian's right that Flash 10 Security breaks all JS-triggering of Flash functionality rather than just preventing it triggering the File dialog. (Given how important this is for accessibility, I rather hope not!) I found that alot of media website started to replace Javascript to play their audio/video and of course Flash required to be install as third party plugin and had to be updated (which is annoying). Alternative possibility: over the next decade (the lifetime of a typical IE version), this use-case for Flash will disappear, except as fallback for native HTML video and audio elements: http://www.whatwg.org/specs/web-apps/current-work/#video http://www.whatwg.org/specs/web-apps/current-work/#audio -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Flash replace Javascript in Future?
Read the story on that page carefully. What has happened is that flash 10 has increased restrictions over what features within the flash plugin can be invoked via javascript. This only applies to one specific feature (file uploads), and effects virtually no other flash features. It does not effect javascript's abilities in general, only the abilities of javascript to use flash in certain ways. This point will largely become moot once video/audio/3d/canvas becomes widespread and built into browsers, and flash as a result becomes less relevant- Particularly on low powered platforms like the iPhone, and Android which do not have flash- or the wii which only has an older and underpowered version of flash. So in my opinion, to the contrary- This news story is reporting on decreased ability of the flash plugin to play well with javascript- It will not make flash replace javascript- Except as a workaround in the specific case of file uploads. On Fri, Oct 17, 2008 at 12:27 AM, Charles Ling [EMAIL PROTECTED] wrote: Hi Guys/Gals, I would like to get some opinion from you all, that would Flash 10 or ++ will replace JavaScript in the future? According to this blog : http://ajaxian.com/archives/flash-10-and-the-bad-news-for-javascript-interaction. I found that alot of media website started to replace Javascript to play their audio/video and of course Flash required to be install as third party plugin and had to be updated (which is annoying). Did you guys/gals use alot of flash in your past projects that you were working with? Cheers, Charles. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
2008/10/16 David Dorward [EMAIL PROTECTED]
Jason Grant wrote:
Ok you got both of these quite wrong for following reasons:
In the first instance you shouldn't use b or br / at all.
In the second instance you should not wrap input into label as the
label should quite clearly be used for denoting a label of an input
field and not the input field itself.
Not so:
When [the for attribute is] absent, the label being defined is
associated with the element's contents.
Which it isn't in the original example provided, the *for* attribute is
provided.
In addition, there is no need to use the li elements around the input
elements, as you can use the display: option in CSS to make them appear like
a list, which is probably what you want, and not going through the hassle of
adding the list HTML elements. Since it is technically not a list.
My suggestion would be something to the content of:
fieldset
*legend //h6 /
*label for=name
input type=text id=name /
*etc...
*/fieldset
CSS:
label, input {
float: left;
clear: left;
}
Or, alternatively;
label, input {
display: list-element;
}
Or just mess around with it. Dude...
Also, no one has yet to answer the original question. And my suggestion is
no, because legend can easily be configured via CSS to look and appear
exactly as h6. So there.
/Svip
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] labels as input wrappers + h6 in place of legend
Ok you got both of these quite wrong for following reasons: In the first instance you shouldn't use b or br / at all. In the second instance you should not wrap input into label as the label should quite clearly be used for denoting a label of an input field and not the input field itself. Using a heading instead of a legend is OK, but use legend if the design allows it for even better accessibility. What you ought to do is something like this. fieldset h3Personal details/h3 ol li label for=surnameSurname/label input type=text name=surname id=surname / /li li label for=emailEmail/label input type=text name=email id=email / /li /ol /fieldset Each /li is a container for labelinput pairs. No need for br/. Each element is nicely 'styleable' via CSS. The ol gives a user insight into how many elements exist inside the given fieldset so for non-sighted user they will know to expect a more complex form if there are 15 items in the given list. You can give each li a class attribute to give it a more specific hook for styling or behaviour purposes. Hope this helps. Jason On Thu, Oct 16, 2008 at 12:35 PM, [EMAIL PROTECTED] wrote: I am looking for feedback on two questions, based on the simple form snippet below. fieldset legendbPersonal Details/b/legend label for=nameName:/label input id=name type=text name=name size=30 br label for=idID Number:/label input id=id type=text name=id number size=10 /fieldset Question 1: Is it acceptable, or advisable, to use a header tag h6 in place of the legend in order to get cross-browsers consistency when dealing with complex form styling? How much impact might this have on accessibility, if any? Question 2: I don't see many folks using the label as a wrapper to contain the input. Any reason not to do this? It allows for the br / to be removed via display: block; on the label tag as well as allowing users (of most browsers) to click on a much larger label to select the accompanying input. fieldset h6Personal Details/h6 label for=nameName: input id=name type=text name=name size=30 /label label for=idID Number: input id=id type=text name=id number size=10 /label /fieldset *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com [EMAIL PROTECTED] +44 (0)7748 591 770 Company no.: 5587469 www.twitter.com/flexewebs www.linkedin.com/in/flexewebs *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
Hi Ben, I've always used label arount input fields [...] I don't think I've ever seen any recommendation against it. Here's one for you: http://green-beast.com/blog/?p=254 I haven't been paying attention to this, and someone's probably already said it (if so, sorry), but it's also worth noting that only form elements will be read in a screen reader's forms mode. Being as such, it's better to style the legend to look like an h6 rather than substituting it for one. Respectfully, Mike Cherim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
Johan Douma wrote: I've always used label arount input fields labeltext: input type=text //label without the for= attribute. I've never had problems with it, and I don't think I've ever seen any recommendation against it. Support is weaker then for the for attribute, so I would avoid it. It is just worth pointing out that it isn't wrong to put the input inside the label. -- David Dorward http://dorward.me.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] labels as input wrappers + h6 in place of legend
I understand where you’re coming from because for some designs the legend isn’t easy to style consistently cross-browser, and so sometimes I have used a heading instead. However if possible, using the legend is much better. I also used to wrap form inputs in labels for the same reason as you say – styling the form becomes easy – however Mike’s article is very insightful and since then I’ve changed what I did and wrap as he suggests. So I just realised I’m basically echoing Mike’s comments, as that’s what I have also discerned as my best practice after quite a bit of form css experience and research. J Rach From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 16 October 2008 12:35 To: wsg@webstandardsgroup.org Subject: [WSG] labels as input wrappers + h6 in place of legend I am looking for feedback on two questions, based on the simple form snippet below. fieldset legendbPersonal Details/b/legend label for=nameName:/label input id=name type=text name=name size=30 br label for=idID Number:/label input id=id type=text name=id number size=10 /fieldset Question 1: Is it acceptable, or advisable, to use a header tag h6 in place of the legend in order to get cross-browsers consistency when dealing with complex form styling? How much impact might this have on accessibility, if any? Question 2: I don't see many folks using the label as a wrapper to contain the input. Any reason not to do this? It allows for the br / to be removed via display: block; on the label tag as well as allowing users (of most browsers) to click on a much larger label to select the accompanying input. fieldset h6Personal Details/h6 label for=nameName: input id=name type=text name=name size=30 /label label for=idID Number: input id=id type=text name=id number size=10 /label /fieldset *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Chrome and Safari
On Thu, 16 Oct 2008 10:49:59 +1000, [EMAIL PROTECTED] wrote: Hi, Seeing as though Google's new Chrome browser uses the same rendering engine as Apple's Safari, would it be acceptable to test browser layout issues in Chrome and assume the same CSS solutions apply in Safari? Does anyone know of any distinct differences in CSS rendering between the 2 browsers? The two are mostly in sync, but I wouldn't depend on it. I would test in both, if I were you. Cordially, David -- *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] labels as input wrappers + h6 in place of legend
Thank you everyone for your replies. So it seems the trusty old traditional filedset llegendContact Information/legend label for=nameName/labelbr / input id=name type=text /fieldset is the way to go to keep all browsers and screen readers happy. I think I can likely lose the br / and replace that with a display: block; on the label or input. This is the first of a series of questions I will have. I have the opportunity to rewrite some extremely complex forms for a very large CMS and I want to make them the best they can be. Thanks! - Original Message - From: Mike at Green-Beast.com [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Thursday, October 16, 2008 11:07:33 AM GMT -05:00 US/Canada Eastern Subject: Re: [WSG] labels as input wrappers + h6 in place of legend Hi Ben, I've always used label arount input fields [...] I don't think I've ever seen any recommendation against it. Here's one for you: http://green-beast.com/blog/?p=254 I haven't been paying attention to this, and someone's probably already said it (if so, sorry), but it's also worth noting that only form elements will be read in a screen reader's forms mode. Being as such, it's better to style the legend to look like an h6 rather than substituting it for one. Respectfully, Mike Cherim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Flash replace Javascript in Future?
I don't see flash becoming a dominant technology in the future. It's definitly not going to replace javascript. It wouldn't actually surprise me if it is going to die off really slowly... Only to be used in really specific cases. Flash gets used a lot today because the flash video codec is good and because it's the easiest way to integrate some video into the browser without needed any plugins that might not be on everybody's computer. Flash is on 99.9% of the computers. Now that might change as well in the next 3 or 4 years as the video and audio tag are going to be more and more available to easily integrate video and audio files into a page. We would still need plugins anyway, but browser could at least integrate open sources plugins, like ogg... etc... I only use flash for multiple file uploads, and some small animations in the page itself. Ow and damn flash 10 has broken my file uploader, I'll have to work on that. Cheers, Johan Douma 2008/10/16 Breton Slivka [EMAIL PROTECTED] Read the story on that page carefully. What has happened is that flash 10 has increased restrictions over what features within the flash plugin can be invoked via javascript. This only applies to one specific feature (file uploads), and effects virtually no other flash features. It does not effect javascript's abilities in general, only the abilities of javascript to use flash in certain ways. This point will largely become moot once video/audio/3d/canvas becomes widespread and built into browsers, and flash as a result becomes less relevant- Particularly on low powered platforms like the iPhone, and Android which do not have flash- or the wii which only has an older and underpowered version of flash. So in my opinion, to the contrary- This news story is reporting on decreased ability of the flash plugin to play well with javascript- It will not make flash replace javascript- Except as a workaround in the specific case of file uploads. On Fri, Oct 17, 2008 at 12:27 AM, Charles Ling [EMAIL PROTECTED] wrote: Hi Guys/Gals, I would like to get some opinion from you all, that would Flash 10 or ++ will replace JavaScript in the future? According to this blog : http://ajaxian.com/archives/flash-10-and-the-bad-news-for-javascript-interaction . I found that alot of media website started to replace Javascript to play their audio/video and of course Flash required to be install as third party plugin and had to be updated (which is annoying). Did you guys/gals use alot of flash in your past projects that you were working with? Cheers, Charles. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
