Re: [WSG] Flash replace Javascript in Future?
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 they introduce a very useful feature then they take it away again in the next version!! annoying! *** 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. I forgot that the Wii has a browser! (I think I was surprised to see it come up in the server logs here a while back) Flash Lite maybe? ... (quite a lot of mobile phones have some version of Flash Lite - which is I think compatable with flash versions up to 7 - so no AS3/flex/etc ... but AS2 is ok) linux desktop distros often come with non-Adobe open source flash players which also don't do some of the newer features introduced recent versions of Adobe flash player. (Firefox 3 on my ubuntu box was like this until I manually downloaded Adobe flash player 9 and compiled it from the shell prompt) For me its basically horses for courses, comparing javascript and actionscript is like comparing apples and oranges, I don't see either as a replacement for the other. .. not yet anyway... ... *** 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?
Don¹t hold your breath for ogg support in all browsers. I imagine microsoft will be more interested in pushing silverlight than flash or ogg. Audio and video is a key front in the next generation of browser wars, so it won¹t be that simple. As you note, Flash offers some useful stuff that¹s not yet core browser functionality. I imagine it will continue to innovate and push browser vendors. On 17/10/2008 06:38, Johan Douma [EMAIL PROTECTED] wrote: 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-interac tion. 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] *** All correspondence, attachments and agreements remain strictly subject to fully executed contract. (c) GCap Media plc 2008. All rights remain reserved. This e-mail (and any attachments) contains information which may be confidential, subject to intellectual property protection and may be legally privileged and protected from disclosure and unauthorised use. It is intended solely for the use of the individual(s) or entity to whom it is addressed and others specifically authorised to receive it. If you are not the intended recipient of this e-mail or any parts of it please telephone 020 7054 8000 immediately upon receipt. No other person is authorised to copy, adapt, forward, disclose, distribute or retain this e-mail in any form without prior specific permission in writing from an authorised representative of GCap Media plc. We will not accept liability for any claims arising as a result of the use of the internet to transmit information by or to GCap Media plc. GCap
Re: [WSG] labels as input wrappers + h6 in place of legend
Actually, the label tag wrapped around form input is the old traditional method. The for attribute method was introduced later to allow designers greater flexibility in positioning/styling forms whilst maintaining accessibility. On Fri, October 17, 2008 12:53 am, [EMAIL PROTECTED] wrote: 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] *** *** 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
- Original Message - From: Jason Grant [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Friday, October 17, 2008 4:51:46 AM GMT -05:00 US/Canada Eastern Subject: Re: [WSG] labels as input wrappers + h6 in place of legend You should also be aware of the fact that for a commercial project the below code snippet you posted will not be sufficient, as it does not have enought styling/behavioural hooks in it... -- That's my next bone to pick, and why I really liked the label wrapper. I really dislike the idea of wrapping the label input in a div but I will likely have to for the exact point you have made. I need lots of flexibility but want minimal code bloat. Here's a simplified version of where I am heading: ... fieldset class=parent id=address legendspanContact Information/span/legend div class=nameFirst label for=nameFirstName/label input id=nameFirst type=text /div div class=nameLast label for=nameLastName/label input id=nameLast type=text /div fieldset class=child id=dob legendspanDate of Birth/span/legend div class=dobMonth label for=dobMonthMonth/label input id=dobMonth type=text /div div class=dobDay label for=dobDayDay/label input id=dobDay type=text /div div class=dobYear label for=dobYearDay/label input id=dobYear type=text /div /fieldset /fieldset ... Why the span in the fieldset? I may potentially need to style that area as a sliding doors tab, plus it seems easier to achieve consistent cross-browser styles on the span as opposed to the legend. The nested fieldset is to allow for the DOB to me horizontal if/when desired. Still lots to do regarding other form elements...more questions as I progress. I will also post an example. Thanks thus far! /fieldset Seems painfully blaoted to me, but I need a lot of control to match virtually any situation *** 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
You don't need the nested fieldset for styling, but for semantics and general better structure/meaning of your form. It so happens that you can also then style that section nicer if you need to. More bloated than it needs to be? Yes. Is it better to use a list instead of divs? Of course it is. As you get more advanced in this, the whole 'set' will get even more bloated. Enjoy your HTML forms 'discovery'. Cheers, Jason On Fri, Oct 17, 2008 at 5:50 PM, [EMAIL PROTECTED] wrote: - Original Message - From: Jason Grant [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Friday, October 17, 2008 4:51:46 AM GMT -05:00 US/Canada Eastern Subject: Re: [WSG] labels as input wrappers + h6 in place of legend You should also be aware of the fact that for a commercial project the below code snippet you posted will not be sufficient, as it does not have enought styling/behavioural hooks in it... -- That's my next bone to pick, and why I really liked the label wrapper. I really dislike the idea of wrapping the label input in a div but I will likely have to for the exact point you have made. I need lots of flexibility but want minimal code bloat. Here's a simplified version of where I am heading: ... fieldset class=parent id=address legendspanContact Information/span/legend div class=nameFirst label for=nameFirstName/label input id=nameFirst type=text /div div class=nameLast label for=nameLastName/label input id=nameLast type=text/div fieldset class=child id=dob legendspanDate of Birth/span/legend div class=dobMonth label for=dobMonthMonth/label input id=dobMonth type=text /div div class=dobDay label for=dobDayDay/label input id=dobDay type=text /div div class=dobYear label for=dobYearDay/label input id=dobYear type=text /div /fieldset /fieldset ... Why the span in the fieldset? I may potentially need to style that area as a sliding doors tab, plus it seems easier to achieve consistent cross-browser styles on the span as opposed to the legend. The nested fieldset is to allow for the DOB to me horizontal if/when desired. Still lots to do regarding other form elements...more questions as I progress. I will also post an example. Thanks thus far! /fieldset Seems painfully blaoted to me, but I need a lot of control to match virtually any situation *** 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
On Oct 17, 2008, at 9:50 AM, [EMAIL PROTECTED] wrote: That's my next bone to pick, and why I really liked the label wrapper. I really dislike the idea of wrapping the label input in a div but I will likely have to for the exact point you have made. I need lots of flexibility but want minimal code bloat. Here's a simplified version of where I am heading: ... fieldset class=parent id=address legendspanContact Information/span/legend div class=nameFirst label for=nameFirstName/label input id=nameFirst type=text /div div class=nameLast label for=nameLastName/label input id=nameLast type=text /div /fieldset ... Why the span in the fieldset? I may potentially need to style that area as a sliding doors tab, plus it seems easier to achieve consistent cross-browser styles on the span as opposed to the legend. The nested fieldset is to allow for the DOB to me horizontal if/ when desired. Still lots to do regarding other form elements...more questions as I progress. I will also post an example. Thanks thus far! I have an obsession with web form styling - I cannot stand ugly web form :-) So here is my two cents: if you want consistent cross-browser web form that looks nice. Add class in the input instead, especially when it involves using checkboxes, radio button, borders for input field, select and multiselect. Though you can utilize input ID, but for a web form, or various forms used throughout entire site that have many checkboxes, radio buttons and select options, using class will be a lot clearer for your style sheet and no need for extra div to wrap up each form element. Fieldset, label and input tags are enough for basic and nice styling, no extra div needed. fieldset legendspanContact Information/span/legend label for= xyz/label input id= type=checkbox class=add-a-class /fieldset That is for the site I have full control and know I will be the only one updating the site. But if I make a template and the targeted users are people who want to build their sites, then definitely bloated divs to prevent customer service nightmare. I will even eliminate legend with a clear conscious. Alas! IE and Opera are not kind to form elements. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Online WSG Mail Archive
Hi Is the online wsg mail archive good enough to use instead of having all the emails sent to the email program? I've currently got well over 5000 emails in Mail on Leopard and I think that's too much. Is it easy to find things and maybe bookmark them on the online wsg mail archive? Thanks -- Peter Mount Web Development for Business Mobile: 0411 276602 [EMAIL PROTECTED] http://www.petermount.com *** 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
Boots.com is one of the most 'formsy' web sites out there. I suggest you sign up for it and try to see what has been done there. It's not bad and it will give insight into today's commercial needs from clients regarding forms. Hope that helps as a concrete example. Regards. On Fri, Oct 17, 2008 at 9:22 PM, tee [EMAIL PROTECTED] wrote: On Oct 17, 2008, at 9:50 AM, [EMAIL PROTECTED] wrote: That's my next bone to pick, and why I really liked the label wrapper. I really dislike the idea of wrapping the label input in a div but I will likely have to for the exact point you have made. I need lots of flexibility but want minimal code bloat. Here's a simplified version of where I am heading: ... fieldset class=parent id=address legendspanContact Information/span/legend div class=nameFirst label for=nameFirstName/label input id=nameFirst type=text /div div class=nameLast label for=nameLastName/label input id=nameLast type=text /div /fieldset ... Why the span in the fieldset? I may potentially need to style that area as a sliding doors tab, plus it seems easier to achieve consistent cross-browser styles on the span as opposed to the legend. The nested fieldset is to allow for the DOB to me horizontal if/when desired. Still lots to do regarding other form elements...more questions as I progress. I will also post an example. Thanks thus far! I have an obsession with web form styling - I cannot stand ugly web form :-) So here is my two cents: if you want consistent cross-browser web form that looks nice. Add class in the input instead, especially when it involves using checkboxes, radio button, borders for input field, select and multiselect. Though you can utilize input ID, but for a web form, or various forms used throughout entire site that have many checkboxes, radio buttons and select options, using class will be a lot clearer for your style sheet and no need for extra div to wrap up each form element. Fieldset, label and input tags are enough for basic and nice styling, no extra div needed. fieldset legendspanContact Information/span/legend label for= xyz/label input id= type=checkbox class=add-a-class /fieldset That is for the site I have full control and know I will be the only one updating the site. But if I make a template and the targeted users are people who want to build their sites, then definitely bloated divs to prevent customer service nightmare. I will even eliminate legend with a clear conscious. Alas! IE and Opera are not kind to form elements. tee *** 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
Stuart Foulstone wrote: Actually, the label tag wrapped around form input is the old traditional method. The for attribute method was introduced later to allow designers greater flexibility in positioning/styling forms whilst maintaining accessibility. Really? As far as I can tell looking at the historical record, Internet Explorer 4.0 and HTML 4.0 introduced the LABEL element, including the FOR attribute, IE didn't support implicit association until version 7.0, and the old tutorials tended to teach it the FOR attribute, so I'm not sure what tradition you're referring to. http://www.w3.org/TR/1998/REC-html40-19980424/appendix/changes.html#h-A.1.1.1 http://www.w3.org/TR/1998/REC-html40-19980424/interact/forms.html#h-17.9.1 http://www.sxlist.com/TECHREF/language/html/ib/Forms/label.htm http://www.insidedhtml.com/tips/elements/ts17/page1.asp http://www.cs.tut.fi/~jkorpela/forms/kbd.html -- Benjamin Hawkes-Lewis -- Benjamin Hawkes-Lewis *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] min-might question
Maybe this is something impossible with CSS, still I hope I am wrong and hope someone who knows better than me able to tell me yes, it can be done. In a block where I have min-height declared, something like this: div class=box div class=set-minheightcontent here/div pa line of text/p /div I cannot control or foresee how long the content in the 'set- minheight' div be. What do I do to have the p tag always stay at the bottom of the block? Thanks! tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
