Re: [WSG] The use of asterisks in forms to indicate required fields
Thierry Koblentz wrote: Some clients do not want [required on the end of each label], they think it pollutes the visual. Understandable - most people buy a design from a visual - not actually using the product they are commissioning. This is a great way to bring usability into the conversation by talking about how frustrating it is when you make a mistake filling in forms, and what the client can do to help their customers avoid a frustrating experience. kind regards, Terrence Wood. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] dl v table for form layout
Nick Fitzsimons wrote: While I agree that use of lists, tables or definition lists is mere abuse, a fieldset is for grouping thematically related controls and labels: http://www.w3.org/TR/html4/interact/forms.html#edef-FIELDSET So a hypothetical (semantic!) form could/should look something like this (I'm sure there are at least a million things wrong with my example - pretend those errors aren't there): form action= method= fieldsetlegendThe legend for the form/legend fieldsetlabel for=nameYou Name/labelinput type=text name=name id=name/fieldset fieldsetlabel for=poetFavourite poet/labelinput type=text id=poet name=poet/fieldset fieldsetlabel for=dinosaurFavourite dinsaur/labelinput type=text name=dinosaur id=dinosaur/fieldset /fieldset /form My point being that fieldset could be used to wrap label and input pairs? I always thought you had to have a group of controls (more than one input field). I note that in Mike's example, he using a br / in order to achieve a block-level style visual. Surely that should be avoidable? http://green-beast.com/gbcf/gbcf_form.php If the fieldset to contain label/input pairs is true, it would be exciting because it would mean that the form would look reasonable in vanilla and could maintain semantics. Kat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] dl v table for form layout
On 27/05/2007, at 7:58 PM, Katrina wrote: My point being that fieldset could be used to wrap label and input pairs? No. fieldset is to group related controls, not labels and controls. kind regards Terrence Wood. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] dl v table for form layout
Terrence Wood wrote: On 27/05/2007, at 7:58 PM, Katrina wrote: My point being that fieldset could be used to wrap label and input pairs? No. fieldset is to group related controls, not labels and controls. From http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.10 The FIELDSET element allows authors to group thematically related controls and labels. In some sense, the label and input are thematically related. I understand that a legend is not required for each fieldset, and not including a legend for the label/input pair, it avoids the screen reader reading it out. Thus avoiding the situation where the legend is the same as the label. Would using fieldset be be harmful to accessibility, if used in this way (for label/input pairs without the legend)? Kat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] dl v table for form layout
The label associates the label-text with the input, i.e. their realtionship is already firmly established and needs no other confirmation. The fieldset is to group together multiple inputs: to add stucture in long complex forms. Moreover, if multiple inputs are expected (since this is what the standards say), then confusion and accessibility problems may well result from this abuse of the fieldset tag. On Sun, May 27, 2007 9:30 am, Katrina wrote: Terrence Wood wrote: On 27/05/2007, at 7:58 PM, Katrina wrote: My point being that fieldset could be used to wrap label and input pairs? No. fieldset is to group related controls, not labels and controls. From http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.10 The FIELDSET element allows authors to group thematically related controls and labels. In some sense, the label and input are thematically related. I understand that a legend is not required for each fieldset, and not including a legend for the label/input pair, it avoids the screen reader reading it out. Thus avoiding the situation where the legend is the same as the label. Would using fieldset be be harmful to accessibility, if used in this way (for label/input pairs without the legend)? Kat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Stuart Foulstone. http://www.bigeasyweb.co.uk BigEasy Web Design 69 Flockton Court Rockingham Street Sheffield S1 4EB Tel. 07751 413451 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] dl v table for form layout
Katrina wrote:
I note that in Mike's example, he using
a br / in order to achieve a block-level
style visual. Surely that should be avoidable?
http://green-beast.com/gbcf/gbcf_form.php
Certainly it would be avoidable using label { display : block; } but I
wanted the form to retain its current organization regardless of
CSS-controls. I do believe this is an acceptable (as in non-harmful) use of
the break element.
If the fieldset to contain label/input pairs is true
It probably shouldn't be used for pairing as you describe, but rather a
group of inputs that all share some common-ground. In my case I use them to
contain groups of required versus non-required inputs as well as the type of
information sought (contact info, etc.). I should have probably not done
that to the submit type input though. That, I'm thinking it would have
better left in the form's main fieldset and not given its own since it's
grouped in with the form itself (a whole-form control) so to speak.
Cheers.
Mike Cherim
- Original Message -
From: Katrina [EMAIL PROTECTED]
To: wsg@webstandardsgroup.org
Sent: Sunday, May 27, 2007 3:58 AM
Subject: Re: [WSG] dl v table for form layout
Nick Fitzsimons wrote:
While I agree that use of lists, tables or definition lists is mere
abuse, a fieldset is for grouping thematically related controls and
labels:
http://www.w3.org/TR/html4/interact/forms.html#edef-FIELDSET
So a hypothetical (semantic!) form could/should look something like this
(I'm sure there are at least a million things wrong with my example -
pretend those errors aren't there):
form action= method=
fieldsetlegendThe legend for the form/legend
fieldsetlabel for=nameYou Name/labelinput type=text
name=name id=name/fieldset
fieldsetlabel for=poetFavourite poet/labelinput
type=text id=poet name=poet/fieldset
fieldsetlabel for=dinosaurFavourite dinsaur/labelinput
type=text name=dinosaur id=dinosaur/fieldset
/fieldset
/form
My point being that fieldset could be used to wrap label and input pairs?
I always thought you had to have a group of controls (more than one
input field).
I note that in Mike's example, he using a br / in order to achieve a
block-level style visual. Surely that should be avoidable?
http://green-beast.com/gbcf/gbcf_form.php
If the fieldset to contain label/input pairs is true, it would be
exciting because it would mean that the form would look reasonable in
vanilla and could maintain semantics.
Kat
***
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] The use of asterisks in forms to indicate required fields
Thierry Koblentz wrote:
Some clients do not want [required on the end of each label], they
think it pollutes the visual.
I'm sure the origin of the asterisk to indicate required fields was
literally that of a footnote:
Name:*
Email:*
* Required field
As Thierry indicates, the original rationale behind this structure
was undoubtedly simply to avoid cluttering a form occupying limited
real estate with the word 'required' beside every required field.
However, it would be clumsy and irritating to mark this up so that
each asterisk were literally a hyperlink that jumped to the footnote
explaining that it was required.
At the same time, the word 'required' (at least in English) is so
short that I don't think its repetition would be irritating on an
aural page (which I suppose might be just my lack of sensitivity as
I'm not a screen reader user).
All this makes me try to come up with a way to present the asterisks
as footnote indicators visually but not aurally. One could present
the asterisks as background images on the abbrev elements, but as
such they wouldn't scale. If they were scalable foreground images,
they'd need an alt:
img src=asterisk.jpg alt=required class=required /
img.required {width: 1em;}
The problem would then be how to mark this up:
* Required fields
As plain text it would make sense to the visual users as the referent
for the asterisks but would seem a bit nonsensical to listeners.
Musingly,
Paul
__
Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] The use of asterisks in forms to indicate required fields
Paul Novitski wrote: As Thierry indicates, the original rationale behind this structure was undoubtedly simply to avoid cluttering a form occupying limited real estate with the word 'required' beside every required field. That's why I like my technique of using fieldsets to group the required inputs. It serves the purpose, doesn't clutter, and doesn't rely on symbolism (and extra mark-up to make said symbolism more accessible). fieldset legendRequired Contact Info:/legend label for=nameEnter your full name:br / input type=text id=name name=name value= / /label label for=emailEnter your email address:br / input type=text id=email name=email value= / /label /fieldset fieldset legendOptional Contact Info:/legend label for=phoneEnter your phone number:br / input type=text id=phone name=phone value= / /label label for=urlEnter your web site address:br / input type=text id=url name=url value=http://; / /label /fieldset Cheers. Mike Cherim http://green-beast.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] The use of asterisks in forms to indicate required fields
On Behalf Of Paul Novitski
All this makes me try to come up with a way to present the asterisks
as footnote indicators visually but not aurally. One could present
the asterisks as background images on the abbrev elements, but as
such they wouldn't scale. If they were scalable foreground images,
they'd need an alt:
img src=asterisk.jpg alt=required class=required /
img.required {width: 1em;}
The problem would then be how to mark this up:
* Required fields
You're right, that's tricky, but the image idea is interesting.
I like Mike's use of the legend element, but the problem I see with that
approach is that Required Contact Info is read before every single
label...
So what about going with something *very simple*, just using an em for
example:
Required fields are displayed in italic span class=pa(read with
emphasis)/span.
.pa { position:absolute;left:-px }
label for=emailemEmail/em:/label
input type=text id=email name=email value= /
English is not my native language so I'm sure the wording could be improved
to makes sense in IE, JAWS, LYNX but that would be the idea. Then we could
abandon the meaningless spans used within the labels.
Would that make sense? The issue of course would be to make *sure*
screen-reader users get the info line. Anything special that can be used
when the cursor goes into form mode?
---
Regards,
Thierry | www.TJKDesign.com
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] The use of asterisks in forms to indicate required fields
At 5/27/2007 11:41 AM, Thierry Koblentz wrote: I like Mike's use of the legend element, but the problem I see with that approach is that Required Contact Info is read before every single label... What if it were simply the word required? pEnter your contact information:/p fieldset legendRequired:/legend label for=nameName:br / input type=text id=name name=name value= / /label ... That would vocalize required name, required email address, required password, etc. That doesn't seem so egregious to me, and all of the suggestions of adding a required markup to each input field will surely produce at least that much baggage to the aural experience. (I've shortened Mike's suggested labels, e.g. Enter your full name to simply Name. Doesn't the aural user agent make it amply clear that this is a form and that each input field is an input field? On that assumption I wouldn't consider it necessary to repeat Enter your each time, but I'm open to being corrected on that point.) Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] The use of asterisks in forms to indicate required fields
On Behalf Of Mordechai Peller The problem would then be how to mark this up: * Required fields As plain text it would make sense to the visual users as the referent for the asterisks but would seem a bit nonsensical to listeners. Perhaps, leave the asterisk as an asterisk and mark it up as such: pdfn*/dfn Required fields/p Nice --- Regards, Thierry | www.TJKDesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Mocking up web interfaces
24 maj 2007 kl. 01.22 skrev Douglas Reith: Just a quick one - what do people most commonly mock up web site designs in? (Photoshop?) Hi Douglas, I've just scanned this thread and agree about Photoshop, Fireworks (which is very handy when creating designed flows by the help of the Frames). But I see that no one have mentioned Axure. It is the best application (Windows, requiring .NET 2) I've worked with when the need is to model interactions and form based web applications. It is indeed not a pixel design tool but has its clear benefits when your need to rapid prototype. Give it a try and I think you will like it. Demo at http:// www.axure.com/demo.aspx 30-days free trial: http://www.axure.com/downloads.aspx Cheers /oa *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The use of asterisks in forms to indicate required fields
Paul Novitski wrote: What if it were simply the word required? pEnter your contact information:/p fieldset legendRequired:/legend label for=nameName:br / input type=text id=name name=name value= / /label ... That would vocalize required name, required email address, required password, etc. Oh, Paul, you da man. I do like that suggestion very much. It is aurally perfect (a lot less wordy) and visually precise. Very good! Cheers. Mike *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Converting font size from pt to % or em
On 2007/05/25 17:47 (GMT-0400) Philip Kiff apparently typed: Felix Miata wrote: What matters is: [...] 5-that any deviation a designer makes from 100% is arbitrary, as it's made from an entirely unknown starting point 100% of the visitor's choice equals respect for the visitor. I'm not really convinced that this is an issue of respect for the users of one's site. The reference that Kane provided to Owen Briggs's charts over at thenoodleincident.com I think demonstrates how the operating system manufacturers and browser companies are the ones who have been arbitrary about what 100% font size on the body element means. Here is a link to Owen Briggs's page discussing Sane CSS Typography: http://www.thenoodleincident.com/tutorials/typography/index.html That's the 2nd time in this thread that poison-pill anachronism has been included. Its focus is on pixel perfection with tiny fonts that provides at most marginal utility when applied to the much larger pixel sizes necessary on modern high resolution/high PPI displays. It only applied when the very overwhelming majority of browsers had 16px defaults *and* most users were running sub-~72DPI displays. It misleads the uninitiated into thinking mousetype is an OK standard for web pages. As Kane pointed out, and as Owen Briggs's screenshot studies demonstrate, the use of 76% as the body font size is to create a more even base-line size across multiple browsers. This 76% figure is not therefore entirely arbitrary: The arbitrariness is an illusion induced by a mindset that all browsers should make every web look like a clone of that page in every other web browser. Modern browsers do a remarkable job of providing the similarity among themselves that they do, which is due in no small part to the standards bodies considerable efforts to create sensible and achievable standards. Different, within reason, should be a perfectly OK standard. setting the body font size to 65%-76% or so is the size that 76% was a particular sweet spot for a particular period that has since passed. Any deviation from 76% did and does move the result out of that anachronistic sweet spot. designers have come up with over the years that allows them the most freedom to produce designs that appear similiar across different browsers and different operating platforms. That particular basis doesn't make it any less arbitrary with regard to users. A designer does not know the particulars of particular visitors' local environments, and has no basis to know anything other than 100% basing could possibly be more usable or more accessible for any environment outside the one he is currently situated in. These levels don't come from any disrespect felt towards site visitors, but from a disrespect for the arbitrariness of different browser defaults and a desire to override the choices made by those browsers. 65%-80% produces a uniformity of substantially reduced accessibility and usability that 100% basing does not do. Whether 65%-80% is intended to disrespect visitors is irrelevant; only the fact that it does is. It's unrealistic to strive for pixel perfection across all browsers, so to use undersized fonts purely in the interest of achieving that goal is fighting the inherent nature and strength of the web rather than embracing it, besides disrespecting visitors. apparent arbitrariness of the 100% alternative. Because no designer knows the real world starting point outside his local world, any deviation from 100% is inherently arbitrary. OTOH, the 100% Easy-2-Read Standard is a standard worthy of embracing to the fullest. http://www.informationarchitects.jp/100e2r?v=4 -- The path of the righteous is like the first gleam of dawn, shining ever brighter till the full light of day. Proverbs 4:18 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Converting font size from pt to % or em
Felix Miata wrote: Because no designer knows the real world starting point outside his local world, any deviation from 100% is inherently arbitrary. OTOH, the 100% Easy-2-Read Standard is a standard worthy of embracing to the fullest. http://www.informationarchitects.jp/100e2r?v=4 Though I agree with the sentiment, the fact remains that the large majority of websites out there do size text below 100% (and yes, more often than not around the 75%ish mark). If a user perceives that size to be a problem, she more likely than not has bumped up the default text size of the browser to compensate for her daily browsing activity. Going to 100% could then, potentially, go the opposite way and make the text too big for her. Couple that with a client's habit of comparing the site they're commissioning with the majority of other sites out there (and the resultant moaning of why is the text on our site bigger than on competitor X's site?)... 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 __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Converting font size from pt to % or em
On 2007/05/27 23:33 (GMT+0100) Patrick H. Lauke apparently typed: Felix Miata wrote: Because no designer knows the real world starting point outside his local world, any deviation from 100% is inherently arbitrary. OTOH, the 100% Easy-2-Read Standard is a standard worthy of embracing to the fullest. http://www.informationarchitects.jp/100e2r?v=4 Though I agree with the sentiment, the fact remains that the large majority of websites out there do size text below 100% (and yes, more often than not around the 75%ish mark). If a user perceives that size to be a problem, she more likely than not has bumped up the default text size of the browser to compensate for her daily browsing activity. Going Probably so with users of modern browsers, but the most common browser in use remains IE6, which with many users don't bother to try to bump the text size up on due to its inexplicable inability to make text bigger on the unfortunate mass of sites that still undersize text using px. to 100% could then, potentially, go the opposite way and make the text too big for her. Too big is not the same class of problem that is too small. It happens to me routinely on 62.5% body sites, but it's a magnitudes smaller problem than mousetype and px-width containers. Couple that with a client's habit of comparing the site they're commissioning with the majority of other sites out there (and the resultant moaning of why is the text on our site bigger than on competitor X's site?)... Your mission, should you choose to embrace it, is to convince the client that maintaining an anachronistic practice is the wrong thing to do, and that doing the right thing is always the right thing to do. Maybe this will help whenever that discussion ensues. http://www.lighthouse.org/accessibility/top-10/ -- The path of the righteous is like the first gleam of dawn, shining ever brighter till the full light of day. Proverbs 4:18 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Converting font size from pt to % or em
On 2007/05/25 17:54 (GMT-0700) Paul Novitski apparently typed:
At 5/25/2007 03:10 PM, Christian Montoya wrote:
not all designers set
body font size to 62.5% when creating websites. It's enough to start
at 100% and set nested containers to fractions of that... just do the
math starting off from 16px. The point that Felix is making is that
setting the body to something small like 62.5% is very destructive,
since user stylesheets and user settings usually just override the
body rule (and ruin all your specific rules).
ruin? Wouldn't it just make everything larger if they overrode the
stylesheet with, say, body {font-size: 100%}?
Sort of, but Gecko browsers behave somewhat like IE does when it encounters
no explicit non-em font-size set on HTML or BODY and child elements are
sized in em, compounding the intended effect of the em-specified sizes.
That's what the images, particularly the last two, in my upthread post at
http://webstandardsgroup.org/manage/archive.cfm?uid=C46B1968-B1CC-B29E-B1E7CE11FA5AD23C
were supposed to demonstrate.
I guess it will depend on which aspects of the layout are widthed in
ems, but for most pages I'd think it would just start you out at a
larger degree of [text and/or layout] magnification.
It's pretty routine that I must on 62.5% pages turn off author styles in
order to use the page, this due to content being allocated inadequate width
to fit without hiding or overlapping.
--
The path of the righteous is like the first gleam of dawn, shining
ever brighter till the full light of day. Proverbs 4:18 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://mrmazda.no-ip.com/
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] The use of asterisks in forms to indicate required fields
Paul Novitski wrote:
fieldset
legendRequired:/legend
label for=nameName:br /
input type=text id=name name=name
value= /
/label
...
That would vocalize required name, required email address,
required password, etc.
Interesting; but what if you need (as is commonly the case) non-required
fields interspersed with required ones?
Instead of using a legend, how's about:
label.required span {
position : absolute;
left : -px;
}
label class=requiredspanRequired/span...
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] The use of asterisks in forms to indicate required fields
Mordechai Peller wrote: Interesting; but what if you need (as is commonly the case) non-required fields interspersed with required ones? Optional I suppose. Just group them accordingly using the technique. fieldset legendOptional:/legend labelPhone input [...] / /label labelWeb site input [...] / /label /fieldset In a new fieldset grouping optional inputs. Cheers. Mike Cherim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] The use of asterisks in forms to indicate required fields
On Behalf Of Mordechai Peller
Instead of using a legend, how's about:
label.required span {
position : absolute;
left : -px;
}
label class=requiredspanRequired/span...
This has been suggested already, but I don't think it's as clean as using
legend.
As a side note, I don't think we'd need to use a class if we consider that only
the required fields would have a label containing a span.
labelspanRequired/span...
label span {...}
---
Regards,
Thierry | www.TJKDesign.com
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] The use of asterisks in forms to indicate required fields
But sometimes at least one phone number might be required but others are optional (e.g. mobile, home, fax etc) - doesn't seem as logical to split your phone number fields up into different groupings. On Mon, 28 May 2007 10:26:31 +1000, Mike at Green-Beast.com [EMAIL PROTECTED] wrote: Mordechai Peller wrote: Interesting; but what if you need (as is commonly the case) non-required fields interspersed with required ones? Optional I suppose. Just group them accordingly using the technique. fieldset legendOptional:/legend labelPhone input [...] / /label labelWeb site input [...] / /label /fieldset In a new fieldset grouping optional inputs. Cheers. Mike Cherim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Tyssen Design www.tyssendesign.com.au Ph: (07) 3300 3303 Mb: 0405 678 590 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Fieldsets in IE7
Hi James Got any example URL's? Maybe you need to place a background colour on the em ? fieldsets and legends are notoriously difficult to present with CSS - they seem to have non-overrideable styles that are put in place by the OS/Browser. Like where the legend is placed... Cheers James On 5/27/07, James Gollan [EMAIL PROTECTED] wrote: Has anyone encountered issues with IE7 rendering fieldset borders strangely when a label contains the em element, and do you have any idea of how to resolve it? The problem I have is that IE7 is placing extra borders behind the labels that contain the em - it looks a little like a strikethrough effect. I remember IE6 having strange problems with em elements, but this form is rendering properely in IE6. hmm, wierd *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Site Review (www.richardson.co.nz)
G'day all, I've decided to make the jump from full time web development to freelance work. Mostly front end development, (X)HTML/CSS/JavaScript development etc. Anyway, to support myself, I've created a portfolio here: www.richardson.co.nz I just want to make sure I haven't missed anything obvious with the build phase of things. If you've all got time to have a look at the code/design and give me some feedback that would be fantastic. It's somewhat off topic but I don't think my copy writing is too hot, if anyone has some suggestions on how to present myself better then I'd love to hear them. I'm going to be dealing strictly with design companies rather then the public so I've tried to keep thing short. Thanks heaps! -- Samuel Richardson Freelance Web Developer www.richardson.co.nz | 0405 472 748 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Accessible Photoshop and flash
Hi. doing certificate iv in web site development at my local college. now for second semester, will be using photo shop, to manipulate 2 and 3 d objects. now, is there any way to do this accessibly with jaws? also, need to use flash, to create 2 and 3 d buttons, objects, etc. is there an accessible way to code this? let me know asap. cheers Marvin. _ Join the millions of Australians using Live Search. Try live.com.au http://ninemsn.com.au/share/redir/adTrack.asp?mode=clickclientID=740referral=millionURL=http://live.com.au *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Site Review (www.richardson.co.nz)
Looks good. Only comment I'd make is about your skills and their ratings: at the moment that information is only really of value to people already in the web dev game and not really useful to anyone who doesn't know anything about web development but who wants a website done. If you're not really targetting the latter sort of people, and are only looking to outsource your work to other agencies, then what you've got is probably fine. On Mon, 28 May 2007 11:05:01 +1000, Samuel Richardson [EMAIL PROTECTED] wrote: G'day all, I've decided to make the jump from full time web development to freelance work. Mostly front end development, (X)HTML/CSS/JavaScript development etc. Anyway, to support myself, I've created a portfolio here: www.richardson.co.nz I just want to make sure I haven't missed anything obvious with the build phase of things. If you've all got time to have a look at the code/design and give me some feedback that would be fantastic. It's somewhat off topic but I don't think my copy writing is too hot, if anyone has some suggestions on how to present myself better then I'd love to hear them. I'm going to be dealing strictly with design companies rather then the public so I've tried to keep thing short. Thanks heaps! -- Tyssen Design www.tyssendesign.com.au Ph: (07) 3300 3303 Mb: 0405 678 590 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The use of asterisks in forms to indicate required fields
John Faulds wrote: But sometimes at least one phone number might be required but others are optional (e.g. mobile, home, fax etc) - doesn't seem as logical to split your phone number fields up into different groupings. Great point, John. That's a conundrum for sure. And it will happen, the frequency thereof is probably in proportion to a form's complexity. In the example you illustrate it might be okay to stick to the required/optional thing, like so. Enter contact info in the form below. fieldset legend: required label/input: name label/input: email label/input: phone fieldset legend: optional label/input: fax label/inout: web But I can definitely see instances where that just woudn't do and the logical groupings wouldn't allow such an easy solution. That's when we'd have to revisit one of the other methods we've been comtemplating I suppose, treating each occurence independantly unless a one-size-fits-all solution is found. A likely candidate might be putting the word in the in the label. fieldset legend: foo stuff label/input: required foo one label/input: optional foo two label/input: required foo red label/input: optional foo blue :-) Cheers. Mike Cherim http://green-beast.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The use of asterisks in forms to indicate required fields
Mike at Green-Beast.com wrote: A likely candidate might be putting the word in the in the label. which will bring us back to doe. doe a deer, a female deer [from the sound of music]... I said: How about just including (required) on the end of each label, Then, Thierry Koblentz wrote: Some clients do not want this at all, they think it pollutes the visual. kind regards, Terrence Wood. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Converting font size from pt to % or em
Christian Montoya wrote: I hate to make a quick reply to a long post, but not all designers set body font size to 62.5% when creating websites. It's enough to start at 100% and set nested containers to fractions of that... just do the math starting off from 16px. The point that Felix is making is that setting the body to something small like 62.5% is very destructive, since user stylesheets and user settings usually just override the body rule (and ruin all your specific rules). The practice of setting body font size to 62.5% has some very interesting assumptions built in. Any style sheet designed using this supposition would be inappropriate for a fully internationalised site. Andrew -- Andrew Cunningham Research and Development Coordinator Vicnet, Public Libraries and Communications State Library of Victoria 328 Swanston Street Melbourne VIC 3000 Australia andrewc+AEA-vicnet.net.au Ph. 3-8664-7430 Fax: 3-9639-2175 http://www.openroad.net.au/ http://www.libraries.vic.gov.au/ http://www.vicnet.net.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***begin:vcard fn:Andrew Cunningham n:Cunningham;Andrew org:State Library of Victoria;Vicnet adr:;;328 Swanston Street;Melbourne;VIC;3000;Australia email;internet:[EMAIL PROTECTED] title:Research and Development Coordinator tel;work:+61-3-8664-7430 tel;fax:+61-3-9639-2175 tel;cell:0421-450-816 note;quoted-printable:Current projects:=0D=0A= =0D=0A= Open Road=E2=80=94http://www.openroad.net.au/=0D=0A= =0D=0A= MyLanguage=E2=80=94http://www.mylanguage.gov.au/=0D=0A= =0D=0A= WoVG Multilingual portal research project=E2=80=94http://www.mylanguage.v= ic.gov.au/wovgdemo/ x-mozilla-html:FALSE url:http://home.vicnet.net.au/~andrewc/ version:2.1 end:vcard
Re: [WSG] Site Review (www.richardson.co.nz)
Samuel Richardson wrote: G'day all, I've decided to make the jump from full time web development to freelance work. Mostly front end development, (X)HTML/CSS/JavaScript development etc. Anyway, to support myself, I've created a portfolio here: www.richardson.co.nz I just want to make sure I haven't missed anything obvious with the build phase of things. If you've all got time to have a look at the code/design and give me some feedback that would be fantastic. It's somewhat off topic but I don't think my copy writing is too hot, if anyone has some suggestions on how to present myself better then I'd love to hear them. I'm going to be dealing strictly with design companies rather then the public so I've tried to keep thing short. Thanks heaps! I only looked at the home page. A piece of the browser scrollbar (very strange) is covering the last numeral of what I assume is your phone number in Safari and Mac FF and Opera. The page is ok in XP FF, Opera, and IE7 and IE6. The start point(before scaling the fonts) of the content text in Mac Opera is almost unreadable for me (I am at 1680). Best, ~dL *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Site Review (www.richardson.co.nz)
risk of going OT but I would like to ask you why did you choose a one page info page with anchor links going down to the content??? I thought multi pages would be the way to go apart from this I do not really have any problems with it, the menu is a bit small though Thanks and sorry On 5/28/07, Samuel Richardson [EMAIL PROTECTED] wrote: G'day all, I've decided to make the jump from full time web development to freelance work. Mostly front end development, (X)HTML/CSS/JavaScript development etc. Anyway, to support myself, I've created a portfolio here: www.richardson.co.nz I just want to make sure I haven't missed anything obvious with the build phase of things. If you've all got time to have a look at the code/design and give me some feedback that would be fantastic. It's somewhat off topic but I don't think my copy writing is too hot, if anyone has some suggestions on how to present myself better then I'd love to hear them. I'm going to be dealing strictly with design companies rather then the public so I've tried to keep thing short. Thanks heaps! -- Samuel Richardson Freelance Web Developer www.richardson.co.nz | 0405 472 748 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- JP2 Designs http://www.jp2designs.com http://www.germworks.net *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The use of asterisks in forms to indicate required fields
Terrence Wood wrote: Mike at Green-Beast.com wrote: A likely candidate might be putting the word in the in the label. which will bring us back to doe. doe a deer, a female deer [from the sound of music]... I said: How about just including (required) on the end of each label, Then, Thierry Koblentz wrote: Some clients do not want this at all, they think it pollutes the visual. Hello Terrence, Yep. That's why I preceded that with: That's when we'd have to revisit one of the other methods we've been contemplating I suppose. If that's the client's request it'd be time to wear one of the two hats we are forced to put on sometimes: 1) Wizard hat to figure out the best way deal with the situation at hand. 2) Salesman hat to convince the client of the benefits of usability and accessibility. Cheers. Mike Cherim http://green-beast.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The use of asterisks in forms to indicate required fields
On 28 May 2007, at 03:42:55, Terrence Wood wrote: Then, Thierry Koblentz wrote: Some clients do not want this at all, they think it pollutes the visual. That's the trouble with this job: clients who won't listen to professional advice. It makes me wonder what they think they're paying for in the first place :-) I wonder how they treat their dentists... 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] Site Review (www.richardson.co.nz)
Hi Sam, It looks great but there are lots of grammar errors. I also noticed that in your CV you seem to be missing employment details on your current position? When I scrolled down to where you have rated your skills there is a scrollbar thing happening that looks ugly and obscures some of the text. (I'm using Mozilla 1.7.2) Also, I think if I didn't work in Web dev, I wouldn't understand what all that meant... if I was a customer I'd want to know what is ASP, PHP etc and what can it do for me and my web site? Cheers, Mary-Anne Samuel Richardson wrote, On 28/05/07 11:05 AM: G'day all, I've decided to make the jump from full time web development to freelance work. Mostly front end development, (X)HTML/CSS/JavaScript development etc. Anyway, to support myself, I've created a portfolio here: www.richardson.co.nz I just want to make sure I haven't missed anything obvious with the build phase of things. If you've all got time to have a look at the code/design and give me some feedback that would be fantastic. It's somewhat off topic but I don't think my copy writing is too hot, if anyone has some suggestions on how to present myself better then I'd love to hear them. I'm going to be dealing strictly with design companies rather then the public so I've tried to keep thing short. Thanks heaps! -- ~ Mary-Anne Nayler Department of Defence Australia [EMAIL PROTECTED] +61 2 6127 5327 ~ ~ ~ ~ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Site Review (www.richardson.co.nz)
Cool, thanks for the comments. It sounds like I still have a few cross browser issues to work out, lucky I just bought a Mac :D The portfolio is strictly for design agencies to get an idea of what I can do rather then the public. I went with a one page design to get the content across quickly, I didn't feel the site warranted multiple pages with such little content. I'll proof the content a bit more, that was one area I'm a little unsure on. Thanks, Samuel On 5/28/07, Mary-Anne Nayler [EMAIL PROTECTED] wrote: Hi Sam, It looks great but there are lots of grammar errors. I also noticed that in your CV you seem to be missing employment details on your current position? When I scrolled down to where you have rated your skills there is a scrollbar thing happening that looks ugly and obscures some of the text. (I'm using Mozilla 1.7.2) Also, I think if I didn't work in Web dev, I wouldn't understand what all that meant... if I was a customer I'd want to know what is ASP, PHP etc and what can it do for me and my web site? Cheers, Mary-Anne Samuel Richardson wrote, On 28/05/07 11:05 AM: G'day all, I've decided to make the jump from full time web development to freelance work. Mostly front end development, (X)HTML/CSS/JavaScript development etc. Anyway, to support myself, I've created a portfolio here: www.richardson.co.nz I just want to make sure I haven't missed anything obvious with the build phase of things. If you've all got time to have a look at the code/design and give me some feedback that would be fantastic. It's somewhat off topic but I don't think my copy writing is too hot, if anyone has some suggestions on how to present myself better then I'd love to hear them. I'm going to be dealing strictly with design companies rather then the public so I've tried to keep thing short. Thanks heaps! -- ~ Mary-Anne Nayler Department of Defence Australia [EMAIL PROTECTED] +61 2 6127 5327 ~ ~ ~ ~ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Samuel Richardson Freelance Web Developer www.richardson.co.nz | 0405 472 748 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Converting font size from pt to % or em
At 5/27/2007 07:44 PM, Andrew Cunningham wrote: The practice of setting body font size to 62.5% has some very interesting assumptions built in. Any style sheet designed using this supposition would be inappropriate for a fully internationalised site. Please elaborate on this point. Is your statement based on the assumption that body text will be sized at 1em, or that the column widths will be fixed? Thanks, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Converting font size from pt to % or em
Paul Novitski wrote: At 5/27/2007 07:44 PM, Andrew Cunningham wrote: The practice of setting body font size to 62.5% has some very interesting assumptions built in. Any style sheet designed using this supposition would be inappropriate for a fully internationalised site. Please elaborate on this point. Is your statement based on the assumption that body text will be sized at 1em, or that the column widths will be fixed? Neither. My assumption is that not all fonts in all scripts are measured the same way and mixed script situations are even more problematic. For Thai body text at 1.0 em with English words or phrases within the text, the English content would need to be approximately 0.75em to match the Thai text. Setting body type to a value significantly less that one em will make Thai and English text (if English text is resized) potentially illegible. -- Andrew Cunningham Research and Development Coordinator Vicnet, Public Libraries and Communications State Library of Victoria 328 Swanston Street Melbourne VIC 3000 Australia andrewc+AEA-vicnet.net.au Ph. 3-8664-7430 Fax: 3-9639-2175 http://www.openroad.net.au/ http://www.libraries.vic.gov.au/ http://www.vicnet.net.au/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***begin:vcard fn:Andrew Cunningham n:Cunningham;Andrew org:State Library of Victoria;Vicnet adr:;;328 Swanston Street;Melbourne;VIC;3000;Australia email;internet:[EMAIL PROTECTED] title:Research and Development Coordinator tel;work:+61-3-8664-7430 tel;fax:+61-3-9639-2175 tel;cell:0421-450-816 note;quoted-printable:Current projects:=0D=0A= =0D=0A= Open Road=E2=80=94http://www.openroad.net.au/=0D=0A= =0D=0A= MyLanguage=E2=80=94http://www.mylanguage.gov.au/=0D=0A= =0D=0A= WoVG Multilingual portal research project=E2=80=94http://www.mylanguage.v= ic.gov.au/wovgdemo/ x-mozilla-html:FALSE url:http://home.vicnet.net.au/~andrewc/ version:2.1 end:vcard
Re: [WSG] Site Review (www.richardson.co.nz)
Hi Samuel: Good work dude ;) The site looks neat, cool and usable. Still I have a couple of suggestions: 1) To make the headings bigger 2) Maybe provide with a simple form to get in touch with you 3) N i think copy needs to be reviewed otherwise looks awesome, have a look at mine to ! Best -P www.puneetsakhuja.com - Original Message - From: Samuel Richardson To: wsg@webstandardsgroup.org Sent: Mon, 28 May 2007 11:05:01 +1000 Subject: [WSG] Site Review (www.richardson.co.nz) G'day all, I've decided to make the jump from full time web development to freelance work. Mostly front end development, (X)HTML/CSS/JavaScript development etc. Anyway, to support myself, I've created a portfolio here: www.richardson.co.nz I just want to make sure I haven't missed anything obvious with the build phase of things. If you've all got time to have a look at the code/design and give me some feedback that would be fantastic. It's somewhat off topic but I don't think my copy writing is too hot, if anyone has some suggestions on how to present myself better then I'd love to hear them. I'm going to be dealing strictly with design companies rather then the public so I've tried to keep thing short. Thanks heaps! -- Samuel Richardson Freelance Web Developer www.richardson.co.nz | 0405 472 748 *** 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] Site Review (www.richardson.co.nz)
I dont find anything wrong is displaying all the content on one page. The main concern is to provide the content and information required with minimum clicks and in the most efficient manner, n thats the latest trend mate ! thats what i did with my website, have a look www.puneetsakhuja.com neways good work dude, as somebody said, just the grammer etc needs to be reviewed. Best -P - Original Message - From: Samuel Richardson To: wsg@webstandardsgroup.org Sent: Mon, 28 May 2007 14:04:08 +1000 Subject: Re: [WSG] Site Review (www.richardson.co.nz) Cool, thanks for the comments. It sounds like I still have a few cross browser issues to work out, lucky I just bought a Mac :D The portfolio is strictly for design agencies to get an idea of what I can do rather then the public. I went with a one page design to get the content across quickly, I didn't feel the site warranted multiple pages with such little content. I'll proof the content a bit more, that was one area I'm a little unsure on. Thanks, Samuel On 5/28/07, Mary-Anne Nayler lt;[EMAIL PROTECTED]gt; wrote: gt; Hi Sam, gt; gt; It looks great but there are lots of grammar errors. I also noticed that gt; in your CV you seem to be missing employment details on your current gt; position? gt; When I scrolled down to where you have rated your skills there is a gt; scrollbar thing happening that looks ugly and obscures some of the text. gt; (I'm using Mozilla 1.7.2) Also, I think if I didn't work in Web dev, I gt; wouldn't understand what all that meant... if I was a customer I'd want gt; to know what is ASP, PHP etc and what can it do for me and my web site? gt; gt; Cheers, gt; gt; Mary-Anne gt; gt; Samuel Richardson wrote, On 28/05/07 11:05 AM: gt; gt; gt; G'day all, gt; gt; gt; gt; I've decided to make the jump from full time web development to gt; gt; freelance work. Mostly front end development, (X)HTML/CSS/JavaScript gt; gt; development etc. gt; gt; gt; gt; Anyway, to support myself, I've created a portfolio here: gt; gt; gt; gt; www.richardson.co.nz gt; gt; gt; gt; I just want to make sure I haven't missed anything obvious with the gt; gt; build phase of things. If you've all got time to have a look at the gt; gt; code/design and give me some feedback that would be fantastic. gt; gt; gt; gt; It's somewhat off topic but I don't think my copy writing is too hot, gt; gt; if anyone has some suggestions on how to present myself better then gt; gt; I'd love to hear them. I'm going to be dealing strictly with design gt; gt; companies rather then the public so I've tried to keep thing short. gt; gt; gt; gt; Thanks heaps! gt; gt; gt; gt; -- gt; ~ gt; Mary-Anne Nayler gt; Department of Defence gt; Australia gt; [EMAIL PROTECTED] gt; +61 2 6127 5327 gt; gt; gt; gt; ~ gt; ~ gt; ~ gt; ~ gt; gt; gt; gt; gt; *** gt; List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm gt; Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm gt; Help: [EMAIL PROTECTED] gt; *** gt; gt; -- Samuel Richardson Freelance Web Developer www.richardson.co.nz | 0405 472 748 *** 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] ***
