Re: [WSG] Printing business letters from a brower
On 11/10/06, Nick Roper [EMAIL PROTECTED] wrote: Ideally I don't want the user to have to go through any print setup operations each time they print, or to make too many assumptions about their current setup. For example, it would be good if filenames etc were not printed by default at the top of the page. So, in an ideal world, the code and css would take care of most of that and the letter would be displayed on-screen in a format that the user could just hit 'print'. Use server-side PDF generation. You can't control browser header/footer output by Javascript, etc., and this is really the only reliable way to make sure it does things properly. Advantage of universal browser support, too. And it's hard to imagine your clients not having Adobe Reader installed (certainly, it's more common than Firefox if you're going to be mandating platforms). My AU$0.02. josh *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] We do not support the Safari browser yet
On 11/9/06, Tee G. Peng [EMAIL PROTECTED] wrote: Looking at its code, I do not understand why Safari browser is notsupported.Can someone enlighten me? Thanks!I believe Safari has some issues with certain _javascript_/Ajax implementations, maybe? Or maybe they only had earlier versions to test on and couldn't get the site to work in 1.2... ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***
Re: [WSG] safari version of an IE underscore hack
On 11/10/06, Bojana Lalic [EMAIL PROTECTED] wrote:
Does anyone know of a hack for safari that will enable the
css to display ONLY in safari?#mydiv { width: 500px; /* for Safari */}/* all other browsers - Safari ignores rules with a hash/pound after the semi-colon */
#mydiv { width: 800px;#}
***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***
Re: [WSG] Printing business letters from a brower
Hi Josh, Yeah, I guess that makes sense. I'll get my sleeves rolled up with PHP's PDF libraries. Thanks for the AU$0.02 Nick Joshua Street wrote: On 11/10/06, Nick Roper [EMAIL PROTECTED] wrote: Ideally I don't want the user to have to go through any print setup operations each time they print, or to make too many assumptions about their current setup. For example, it would be good if filenames etc were not printed by default at the top of the page. So, in an ideal world, the code and css would take care of most of that and the letter would be displayed on-screen in a format that the user could just hit 'print'. Use server-side PDF generation. You can't control browser header/footer output by Javascript, etc., and this is really the only reliable way to make sure it does things properly. Advantage of universal browser support, too. And it's hard to imagine your clients not having Adobe Reader installed (certainly, it's more common than Firefox if you're going to be mandating platforms). My AU$0.02. josh *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Nick Roper partner logical elements innovative web and internet solutions zend/php mysql approved partner email: [EMAIL PROTECTED] phone: +44 1749 676798 www: www.logical.co.uk skype: nick.roper / +44 20 7870 9587 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Print Styles and Display:None
Carolyn Diaz wrote: The layout has a left navigation, header, and footer in tables. I've styled the header and footer for print by using display:none;, but cannot get my main content all the way over to the left margin. It's as if the left navigation is somehow preventing it from moving all the way over. Perhaps margin, padding et al? Resetting padding and margins globally, in your print stylesheet may help. However, ideally, you'd post a test page. Regards, - Rahul. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] We do not support the Safari browser yet
On 11/10/06, Barney Carroll [EMAIL PROTECTED] wrote: Matthew Pennell wrote: I believe Safari has some issues with certain _javascript_/Ajax implementations, maybe? Or maybe they only had earlier versions to test on and couldn't get the site to work in 1.2...Safari's _javascript_ support is very patchy, to the extent where you canno longer rely on functionality degrading gracefully if you have heavyfunctional implementation of js.I also get the impression that there is a bit of an unspoken culture of I built this up nice and clean to work in Firefox, and then I worked myfingers to the bone getting it to work in IE because it's themajorities' browser... Safari can fuck off.Regards,Barney I've noticed that much of the AJAX stuff in gmail doesn't show in Safari either, so there's probably something going on there.~eys ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***
Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
on 10/11/2006 05:03 [EMAIL PROTECTED] said the following: Please could someone tell me what I'm obviously missing? snip Your text for each input isn't enclosed by the label element so the explicit association is being lost. Instead of: label for=ainput type=radio value=0 name=answer alt=make your mark id=a accesskey=l tabindex=2 //labelTextbr / It should be label for=ainput type=radio value=0 name=answer alt=make your mark id=a accesskey=l tabindex=2 /Text/labelbr / Personally I'd also: 1. Scrap the accesskeys. All of the keys you're using conflict with keystrokes reserved for JAWS, Home Page Reader, Firefox/Mozilla and Opera 7: http://www.wats.ca/show.php?contentid=43 2. Get rid of the tabindexing. If your natural tab order is intuitive, you don't need it. The last thing you should do is interfere with the intuitive tab ordering on a page. It can drive keyboard navigators up the wall. 3. Get rid of the tabled layout. What you posted is simple enough to achieve without tabling. 4. Change the title attribute on your link from Off Site Link to Opens in new window. In fact, consider either not spawning a new window or placing the warning in clear text and, if necessary, using css to position it offscreen. A significant number of screen reader users configure their software to ignore the title attribute (because it's so over-used) so will not be pre-warned about the new window. Automated accessibility parser warnings about tab indexes and access keys can be safely ignored provided you've actually tested the keybaord navigation of the page yourself and you're happy that it behaves logically. Hope that helps Mel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] We do not support the Safari browser yet
Actually this particular site has been like this since a year ago at least when I first came across it. It is quite possible that the developer(s) may have his/her/their biases and used a browser sniffer to flush out the "unconverted" users and let them know how they can become "saved" - (I am not referring to you).Wells Fargo Bank in the US had similar messages denying safari users. This was changed within the last year after I complained to the bank's chief marketing officer and the president that this was clearly a false assertion since I had been ignoring their message and used Safari every day for the previous five years to conduct my personal and business Internet banking on their website. The president was quite unhappy that his programmers had done such an "unfriendly" thing on their website. The message disappeared.I think it is a caution to all web designers.I may prefer Safari, Firefox and Opera to Internet Explorer 6. And, IE4, 5, and 6 do get their share of similar "blasts" from many designers and programmers. The new IE7 appears to be more web-friendly.My newest web pages work fine in IE 5, 5.5 and 7. I use transparent PNG-24's and "height: 100%;" to get browsers to "background-repeat: repeat-y" a left and right edge graphic border, but these disappear in IE6 and Opera 8.5.But, I will not put a message on my site telling people to "bugger off" "or get a "real" browser. I will use a hack to fix it for IE6 and Opera 8.5.I caution all designers to never do anything on company or personal sites that may alienate a group of customers who frequently have little say in what browser is on their company-owned computer or who have limited knowledge of how to upgrade their current browser or to install a different one.I bite my tongue beyond this pointWill ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***
Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
Hello Sharon, I echo what Mel said, though I'd like to add that the label should probably be the same as the name (and the ID, if needed, may as well match too). label for=answerinput type=radio value=0 name=answer alt=make your mark id=answer /Text/labelbr / Respectfully, Mike Cherim - Original Message - From: Mel [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Friday, November 10, 2006 10:07 AM Subject: Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form on 10/11/2006 05:03 [EMAIL PROTECTED] said the following: Please could someone tell me what I'm obviously missing? snip Your text for each input isn't enclosed by the label element so the explicit association is being lost. Instead of: label for=ainput type=radio value=0 name=answer alt=make your mark id=a accesskey=l tabindex=2 //labelTextbr / It should be label for=ainput type=radio value=0 name=answer alt=make your mark id=a accesskey=l tabindex=2 /Text/labelbr / Personally I'd also: 1. Scrap the accesskeys. All of the keys you're using conflict with keystrokes reserved for JAWS, Home Page Reader, Firefox/Mozilla and Opera 7: http://www.wats.ca/show.php?contentid=43 2. Get rid of the tabindexing. If your natural tab order is intuitive, you don't need it. The last thing you should do is interfere with the intuitive tab ordering on a page. It can drive keyboard navigators up the wall. 3. Get rid of the tabled layout. What you posted is simple enough to achieve without tabling. 4. Change the title attribute on your link from Off Site Link to Opens in new window. In fact, consider either not spawning a new window or placing the warning in clear text and, if necessary, using css to position it offscreen. A significant number of screen reader users configure their software to ignore the title attribute (because it's so over-used) so will not be pre-warned about the new window. Automated accessibility parser warnings about tab indexes and access keys can be safely ignored provided you've actually tested the keybaord navigation of the page yourself and you're happy that it behaves logically. Hope that helps Mel *** 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] We do not support the Safari browser yet
Will Jensen Personal Public wrote: I caution all designers to never do anything on company or personal sites that may alienate a group of customers who frequently have little say in what browser is on their company-owned computer or who have limited knowledge of how to upgrade their current browser or to install a different one. I bite my tongue beyond this point In terms of commercial website design it is utterly unforgivable - even the tone of the message is arrogant. However there's something perversely refreshing from the view-point of someone who continually tells friends and family to use Firefox only to have the 'if it ain't broke' line pulled on me. The only reason it ain't broke is because people like us spend hour upon hour fixing it - and to a certain extent, unless we let things break occasionally, nobody else will fix them! Childish logic, but I do contemplate it a lot. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
Mike at Green-Beast.com I echo what Mel said, though I'd like to add that the label should probably be the same as the name (and the ID, if needed, may as well match too). Just being mindful that obviously, for radio buttons, the ID can't match the name, as the former needs to be unique, while the latter needs to match the other radio buttons in the same group so that they're mutually exclusive. P Patrick H. Lauke Web Editor External Relations Division University of Salford Room 113, Faraday House Salford, Greater Manchester M5 4WT UK T +44 (0) 161 295 4779 [EMAIL PROTECTED] www.salford.ac.uk A GREATER MANCHESTER UNIVERSITY *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
On Fri, Nov 10, 2006 at 10:49:43AM -0500, Mike at Green-Beast.com wrote: I echo what Mel said, though I'd like to add that the label should probably be the same as the name (and the ID, if needed, may as well match too). You mean the text used to label the control with should be the same as the value of the name and id attributes? That is not always reasonable. The two key examples being multilingual websites and radio buttons (where the name and id have to be different). label for=answerinput type=radio value=0 name=answer alt=make your mark id=answer /Text/labelbr / Why alt text on a radio button? The purpose of the attribute is to provide an textual alternative for image inputs. -- 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] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
I echo what Mel said, though I'd like to add that the label should probably be the same as the name (and the ID, if needed, may as well match too). label for=answerinput type=radio value=0 name=answer alt=make your mark id=answer /Text/labelbr / Being picky, the name isn't actually required (unless being used in scripts etc). The 'for' attribute of the label gets matched with the 'id' attribute of the associated form field. M ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify [EMAIL PROTECTED] or the sender of the e-mail. It is your responsibility to protect your system from viruses and any other harmful code or device. This e-mail message has been scanned for the presence of computer viruses; However LMUK accepts no liability for any which remain. We may monitor or access any or all e-mails sent to us. ** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
On 10 Nov 2006, at 16:11:14, Emma Sax wrote: label for=answerinput type=radio value=0 name=answer alt=make your mark id=answer /Text/labelbr / Being picky, the name isn't actually required (unless being used in scripts etc). The 'for' attribute of the label gets matched with the 'id' attribute of the associated form field. The name is needed for each member of a group of radio buttons: it's how they're grouped. For other input fields, the name is needed if the form is going to be submitted to the server, as otherwise there's no way to form a name:value pair, and so the field can't be submitted. 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: [EMAIL PROTECTED] ***
Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
Patrick wrote: [...] the ID can't match the name, as the former needs to be unique [...] Good point Patrick. Being it's a radio button you're right on. --- David wrote: You mean the text used to label the control with should be the same as the value of the name and id attributes? Actually I didn't mean the label text but label for= attribute. Why alt text on a radio button? The purpose of the attribute is to provide an textual alternative for image inputs. I just copied what Mel posted and I agree that the alt attribute isn't needed in that. I wouldn't use it. --- Emma wrote: Being picky, the name isn't actually required (unless being used in scripts etc). True. Most of my work is scripted so I tend to use the name attribute. --- My main focus was to have a label's for attribute match but I understand there are unique circumstances here being it's a radio button. Have a great weekend everyone. Mike *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] zefrank on web developers
Hey list. Just wanted to let you know that zefrank's videoblog yesterday was about web developers. It's really funny and maybe some can relate? Beware though, there's some bad language if I remember correctly, in case that's a problem. Here's the link: http://www.zefrank.com/theshow/archives/2006/11/110906.html -- -- Christian Montoya christianmontoya.com ... portfolio.christianmontoya.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
Nick wrote: For other input fields, the name is needed if the form is going to be submitted to the server, as otherwise there's no way to form a name:value pair, and so the field can't be submitted. Good to know. I've always used the name attribute on form inputs. Now I know why ;-) Mike *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] zefrank on web developers
Thanks for sharing that. I've seen his videos before and count myself as a fan. He does some great stuff. Okay, I'm off to the smoking terrace now. ;-) Mike - Original Message - From: Christian Montoya [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Friday, November 10, 2006 12:57 PM Subject: [WSG] zefrank on web developers Hey list. Just wanted to let you know that zefrank's videoblog yesterday was about web developers. It's really funny and maybe some can relate? Beware though, there's some bad language if I remember correctly, in case that's a problem. Here's the link: http://www.zefrank.com/theshow/archives/2006/11/110906.html -- -- Christian Montoya christianmontoya.com ... portfolio.christianmontoya.com *** 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] Font-sizing in quirksmode
On 10/11/2006, at 12:23 PM, David McKinnon wrote:
I'm trying to get font sizing consistent between IE6 and Firefox.
body {
font-size: medium;
}
/* Make sure IE only sees this... use CC's if you want, I prefer *
html */
* html body {
font-size: small
}
/* use your favorite (non-keyword) sizing everywhere else. Example */
h1 {font-size: 1.6em}
no fuss, no muss.
kind regards
Terrence Wood.
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Cynthia Reports Warnings 9.4 and 9.5 as relates to form
On 11/11/2006, at 4:49 AM, Mike at Green-Beast.com wrote: the label should probably be the same as the name (and the ID, if needed, may as well match too). Disagree Mike, the name attribute on form controls is used server side to process the form. Example: radios should/could have the same name. Don't confuse it with the name attribute on other elements. !-- half a likert. Dropped the fieldset for brevity -- label forq1-1input type=radio name=q1 id=q1-1 Strongly Agree/label label forq1-2input type=radio name=q1 id=q1-2 Agree/label label forq1-3input type=radio name=q1 id=q1-3 Ambivalent/ label kind regards Terrence Wood. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
