Re: [WSG] Converting font size from pt to % or em
Thnx for the suggestion..but i need to define the font size in the body
itself
I've defined 75% which works well in IE6..but it appears smaller in IE6
-Sagnik
On 5/25/07, Kane Tapping [EMAIL PROTECTED] wrote:
Hi ,
Setting the body to font size to 65% - 70% is a good start. this averages
out the differences between the browsers,
body {font-size: 70%;}
From then on set your font sizes in ems.
h1 {font-size: 1.8em;}
And keep in mind that changes to the em size will cascade through
container objects.
Kind Regards,
Kane Tapping
Web Standards Developer
Web and Content Management Services
Griffith University. 4111. Australia.*
[EMAIL PROTECTED] //[EMAIL PROTECTED]/
Phone: +61 (0)7 3735 7630
*Sagnik Dey [EMAIL PROTECTED]*
Sent by: [EMAIL PROTECTED]
25/05/2007 03:18 PM Please respond to
wsg@webstandardsgroup.org
To
wsg@webstandardsgroup.org cc
Subject
[WSG] Converting font size from pt to % or em
Hi Guys,
I'm developing a website that have some standards defined. The font size
specified is 9pt. But due to accessibility standards I wanted to convert
that in % or em. Can anybody tell what do i need to use to view the same
size in different browsers?
--
:: Sagnik ::
***
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]
***
--
:: Sagnik ::
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
[WSG] ADMIN - personal attacks, or disrespect on list are not acceptable
Hi all, Today we have seen a range of unacceptable behaviour on list including rude or abusive comments, personal attacks and a post to a closed thread. None of these are acceptable and future offenders will be removed from the list immediately. Around 12 months ago I posted about this to the list. It seems that a little reminder is in order... --- original post I want to talk today about respect. For those of you who have not heard of this concept, respect is sometimes defined as courteous regard for people's feelings. When you reply to a post on the list, you should at all times try to do so with respect. Everyone on this list is entitled to their own opinion. Sometimes they may be factually incorrect, other times they may have a different view from you but EVERYONE should be treated with respect. Below are some examples of replies that LACK respect: You are totally wrong That is silly That is stupid You know nothing about... You are dumb You smell Below are some more respectful alternatives: I'm not sure I agree with that I think you may be misinterpreting... I respectfully disagree for the following reasons Have you considered taking a bath? Today's lesson: when replying to others, be courteous or leave! -- end post -- Russ *** 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
Hi ,
Yeah, your never going to get an exact match through the browsers using
ems, you kind of have to let go of pixel perfect design and aim your
design as a flexible interpretation of your css. This approach will also
mean your design will cope with users setting larger (or smaller) text
sizes in their browser (or you could add this feature into your site
yourself).
When you start using ems you cannot give and exact height or width for
your text (it will change across browsers), but you can ensure that there
is a constant ratio between your elements on all browsers. ie your h1's
are ALWAYS 2x the size of your p's.
Another thing that may crop up is that Firefox has absolute s***house
rounding when calculating em sizes, so you will need to keep a careful eye
on any borders that are declared on objects sized with ems. quite often it
will round the border size to 0, and not display a border :-(
Kind Regards,
Kane Tapping
Web Standards Developer
Web and Content Management Services
Griffith University. 4111. Australia.
[EMAIL PROTECTED]
Phone: +61 (0)7 3735 7630
Sagnik Dey [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
25/05/2007 04:02 PM
Please respond to
wsg@webstandardsgroup.org
To
wsg@webstandardsgroup.org
cc
Subject
Re: [WSG] Converting font size from pt to % or em
Thnx for the suggestion..but i need to define the font size in the body
itself
I've defined 75% which works well in IE6..but it appears smaller in
IE6
-Sagnik
On 5/25/07, Kane Tapping [EMAIL PROTECTED] wrote:
Hi ,
Setting the body to font size to 65% - 70% is a good start. this averages
out the differences between the browsers,
body {font-size: 70%;}
From then on set your font sizes in ems.
h1 {font-size: 1.8em;}
And keep in mind that changes to the em size will cascade through
container objects.
Kind Regards,
Kane Tapping
Web Standards Developer
Web and Content Management Services
Griffith University. 4111. Australia.
[EMAIL PROTECTED]
Phone: +61 (0)7 3735 7630
Sagnik Dey [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
25/05/2007 03:18 PM
Please respond to
wsg@webstandardsgroup.org
To
wsg@webstandardsgroup.org
cc
Subject
[WSG] Converting font size from pt to % or em
Hi Guys,
I'm developing a website that have some standards defined. The font size
specified is 9pt. But due to accessibility standards I wanted to convert
that in % or em. Can anybody tell what do i need to use to view the same
size in different browsers?
--
:: Sagnik ::
***
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]
***
--
:: Sagnik ::
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
[WSG] another image maps question
I was trying to do something as an old-style ISMAP (server-side) image map and noticed some wierd behaviour Is this type of image map still supported properly by browsers? I can't do it client-side because the coordinates that were clicked on need to be sent to the server to be compared with the image (also generated by a script on the server) The imagemap is to be used on other websites (and no javascript can be used in this case ... must be just plain html) *** 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
Karl Lurman wrote:
How am I going to highlight the label input
pair without a container div? A fieldset?
Hello Karl,
I will add a div or paragraph to a form if needed. A division in the form
normally marked by color or a border is okay (as that slight meaning will be
carried by the Div in the same way) and if -- I don't usually -- I'm after a
style I can't seem to achieve with the form's own elements. I just don't
feel a table or list is the right way. Paragraph elements for errors if
they're on the same page are okay, and spans are like little bundles of air
so they're okay. I don't want to add something to the form that is going to
disrupt its inherent goodness, so to speak.
Now, regarding your example, I wonder if something like this could be done
in the partial form example below (?). Just thinking out loud. It's late
here so I haven't the time to test it...
pFields marked with * (asterisk) are required./p
labelspan*/span Name: ?php echo $error; ?
input value= /
/label
- Note: Error would be empty if not applicable. And the script outputted
error would be in an unclassed span like the asterisk.
Okay, now here's the proposed CSS...
label {
display : block;
width : 99%;
height : auto;
padding : 5px 10px;
margin : 5px;
text-align : right;
border : 1px solid #000;
background-color : #eee;
}
label span {
color : red;
font-weight : bold;
}
input {
width : 30%;
text-align : left;
margin : 5px;
display : inline;
border : 1px solid #666;
background-color : #f9f9f9;
}
I'm *guessing* the input will display within the somewhat styled label. But
like I wrote, I didn't test it, I'd most likely have to fuss with it. And if
I had to have the styling but couldn't figure it out eventually, I think the
best remaining solution would be a Div so that's what I'd use too.
Cheers.
Mike Cherim
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] Map of Australia Image Map
At 5/24/2007 09:49 PM, Geoff Pack wrote: If the image is a map, and you want to link areas of it, then an image map is the semantically correct solution. Faking them with lists and CSS is no better than using tables for layout IMHO. Wouldn't that depend on whether you thought of the map as the semantic content itself or merely the graphic presentation of a list? To my surprise, the presentational result might not depend on which markup is chosen. Undoubtedly the reason Pete chose CSS for the http://www.domain.com.au/ job was to make the states highlight on hover. I was about to say that image map areas wouldn't work for this because IE6 won't support area:hover, but rereading the HTML spec I'm reminded that a map can consist of a series of anchors as well. [1] It's entirely possible to style the Anchors (or AREAs) as blocks and absolutely position them on the image to make them do double duty as both image map polygons and sprite hover rectangles. Of course we're still left facing the sad fact that today's CSS can manipulate only rectangles and not circles or polygons, so it remains our noble quest to persuade our respective governments to redraw all political boundaries rectilinearly. [1] HTML 4.01 Specification 13 Objects, Images, and Applets 13.6 Image maps http://www.w3.org/TR/html4/struct/objects.html#h-13.6 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] Converting font size from pt to % or em
On 2007/05/25 15:24 (GMT+0930) Katrina apparently typed: Sagnik Dey wrote: I'm developing a website that have some standards defined. The font size specified is 9pt. But due to accessibility standards I wanted to convert that in % or em. Can anybody tell what do i need to use to view the same size in different browsers? I think you should respect your users' default. Make sure the design scales properly when text size is increased, beyond what MIE allows you to do. It is so cliche, but the web is not print. You cannot and should not insist that people see things at the font-size you decree. To go further, the size you decree is only the size you decree sitting in your chair looking at your screen. You don't know whether that size is bigger or smaller or the same to your visitor, who may: 1-have a different size display 2-have a different resolution setting 3-sit a different distance from the display than you 4-have better (uncommon) or worse (very common) eyesight than you the designer 5-have other local conditions different from yours that affect suitability of any particular size While 9pt always means 9pt when printed, 9pt on a computer screen could mean anything from 15pt on down below to below 6pt on a computer screen. When a web author specifies 9pt for screen, I see text that is roughly 41% of the size I find suitable for my screen use, if I'm not using a browser than enforces a legible size of my choosing. What you can do is set relative sizes for various types of text. Exactly. Set font-size in body to 100%, then set some smaller size for your footer, some other smaller size for breadcrumbs, some larger sizes for various headings, etc., but keep main content text at 100% of the size the user has selected. See: http://www.informationarchitects.jp/100e2r?v=4 http://www.useit.com/alertbox/designmistakes.html http://css.nu/articles/font-analogy.html http://www.xs4all.nl/~sbpoley/webmatters/essence.html http://mrmazda.no-ip.com/auth/accessibility.html -- 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 15:31 (GMT+1000) Kane Tapping apparently typed: Setting the body to font size to 65% - 70% is a good start. Actually it's a bad start, arbitrarily assuming that there's something wrong with the user's choice of default, and reducing it by some arbitrary amount, even though you don't have a clue what it was to start with. Browser default sizes are purposely adjustable so that their users can tailor web page text sizes to suit their own personal needs. http://mrmazda.no-ip.com/auth/bigdefaults.html It's also an excellent definition of disrespect for your site's visitors. -- 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] ***
[WSG] making form elements the same height
Hi all,
I have a question I hope one of you might be able to answer.
http://www.clickfind.com.au/test-index.html
I am trying to get the form elements the same height, I would expect that
the following would do the trick;
input.text {
border: 1px solid #A9D46F;
height: 1.2em;
font-size: 1em;
margin: 0;
padding: 0.2em;
}
input.submit {
border: 1px solid #99;
height: 1.2em;
font-size: 1em;
margin: 0;
padding: 0.2em;
}
But it does not, and I do not understand why, I would like to understand why
it does not.
Also, is there any way to align the text on the left hand side of the text
field to the middle of the textfield?
Thanks in advance for any help.
***
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 25/05/07, Katrina [EMAIL PROTECTED] wrote:
I think you should respect your users' default. Make sure the design
scales properly when text size is increased, beyond what MIE allows you
to do.
I disagree a little here, about user defaults. Yes you should respect them,
but not by using 100% or 1em.
1em = 100% = 16px = 16pt (yes 1px = 1pt for the screen) in all PC based
browsers since 2000 unless changed by the user or PC manufacturer (this is
becoming a little more common with laptops having twice the pixels per inch
or cm that desktop screens).
From experience almost all users do not change the default.
Those that do, tend to push the size up a bit to deal with sites that set
the base pixel size in percentages (usually somewhere between 62 and 76%).
If I as a user want 16px text on sites I visited, I would set my default
size to 20px or 22px.
Due to a bug in an old version of IE most people when choosing to use
scaling fonts is set the body size in percentage and them use ems for all
other font size measurements.
Due to a rounding error bug in an old old version on Opera some people tend
to push the percentage up by 1%.
I would (and regularly do) decided on my base font size for text in px and
set my body font-size to:
percentages to pixels
56.25% or 57% = 9px or 9pt (way too small IMHO)
62.5% or 63% = 10px
69.75, 70 or 71% = 11px
75 or 76% = 12px
81.25 or 82% = 13px
87.5 or 88% = 14px
Then set
p, ol, ul, li, table, tr, td, a, input {font-size: 1em}
h1 {font-size: 2.5em or whatever}
There is another view that you should set your body font-size to 62.5% then
1em = 10px and calculate your sizes from there, ie 12px body text, 18px h1
is:
p { font-size: 1.2em or 120%;}
h1{font-size: 1.8em or 180%;}
I don't like this method, just in case I nest something or make small
mistake in my css.
ie if p, ol, ul, li, table, tr, td, a, input {font-size: 120%;}
would be 12px inside a paragraph, 14px links, 14px list and 17px links in a
list.
hopes that makes sense too much caffeine and other things for lunch
and if you want to scale your design to your font-size google elastic
design http://www.google.com/search?q=elastic+design
--
Nick Cowie
http://nickcowie.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 25/05/07, Felix Miata [EMAIL PROTECTED] wrote: On 2007/05/25 15:31 (GMT+1000) Kane Tapping apparently typed: Setting the body to font size to 65% - 70% is a good start. Actually it's a bad start, arbitrarily assuming that there's something wrong with the user's choice of default, and reducing it by some arbitrary amount, The majority of users won't know how to adjust their default browser settings though. Providing the changes to text size are being made in an informed way, are tested and most importantly all of the text can be resized - then there isn't too much harm in changing the text size. It's possible to set an absolute size for the body text of some browsers and a matching relative size for the body text of those browsers that can't resize absolute text sizes (use some conditional CSS). If you do that and specify all the text/heading sizes that follow in ems then you should have few problems with cross browser consistency. Stephen http://www.twoplayer.net *** 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
pFields marked with * (asterisk) are required./p Yep, instructions are definitely the way to go with the 'required'. we might even look at making instructions for the required as a definition list (hahaha just for fun) form dl dt*/dt ddFields whose labels contain an asterisk require a value./dd /dl Hey, I mean it kind of makes sense - I have defined what a '*' means in the context of the form... :) Seriously though, we could look at adding more text instructions and aids to help non-visual browsers with the error messages e.g: labelField Label a name=fieldAnchor/ainput span class=error span class=forScreenReaders emAn Error Has Occurred For Field ?php =$fieldLabel?:/embr / /span?php echo $error? span class=forScreenReaders br /a href=#?php =$fieldAnchor? title=Fix the errorTake me to the field so I can fix the error/a /span /span!-- Close of error -- And style accordingly, where forScreenReaders 'hides' elements off left of screen. Not sure if a link to a named anchor before/after/around the field is enough - it would be nice to focus the screen reader onto the input field itself, perhaps a piece of javascript in the onclick would work with SOME screen readers here. labelspan*/span Name: ?php echo $error; ? input value= / /label Im not the biggest fan of a label 'around' an input. To me, it doesn't make a lot of sense, but I know that its standard practice with a lot of people. I understand that it gives us another means of encapsulating our label/field pair, but again I am unsure on the semantics - it poses the question, what is the purpose of the attribute for in labels? - Note: Error would be empty if not applicable. And the script outputted error would be in an unclassed span like the asterisk. About putting the error in the label, not sure on that one either. Is an error a label after all... Overall though, I think if we are trying to cut down on the use of superfluous containers, your method is as good as any other :) Man, I hope for us all that the new HTML and XHTML standards cover form semantics better... Karl *** 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/25/2007 12:15 AM, Felix Miata wrote: On 2007/05/25 15:31 (GMT+1000) Kane Tapping apparently typed: Setting the body to font size to 65% - 70% is a good start. Actually it's a bad start, arbitrarily assuming that there's something wrong with the user's choice of default, and reducing it by some arbitrary amount, even though you don't have a clue what it was to start with. Isn't that true only if you then use 1em as your base font size? In my efforts to build zoomable layouts [max-width at window width] I've found it convenient to declare a body font-size of 62.5% so that, on a PC with a default font size of 16px, 1em = 10px at normal zoom. It makes calculations very easy. For example, if you begin with a content column of 790px, that converts to 79em and becomes zoomable. An image that's 100px wide becomes 10em wide. In that context, one can make one's base font size 1.6em (16px at normal zoom on a PC). This presents body text at the same size it would have been had font-size not been styled, yet at the same time makes scaling calculations much easier for the designer. It seems like a win-win situation. Can you see a flaw? Even on Mac monitors running at 96dpi, reducing the text to 62.5% and then increasing to 1.6 should bring it back to 100% of the default size, whatever that may be. 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] Converting font size from pt to % or em
Setting the font-size like that is to create a more even base-line size across multiple browsers. http://www.thenoodleincident.com/tutorials/box_lesson/font/browser.html It is not the determining factor on end-user font size. (unless of course you never declare the em size for your markup) - that is depended on the value of the em declarations used for markup and the em declarations used on any container objects. If you want to complain that 9-11pt text is too small? fine, but you are disagreeing with one possible end result, not the body: font-size % declaration. arbitrarily assuming that there's something wrong with the user's choice of default ... I guess we also shouldnt be second guessing our users choice of font, weight, spacing, color ... positioning ? And one day all users will view the webpages using their own custom user stylesheets... Until that day expect designers to be actively styling their pages as they see fit. The point i was trying to make is that you can design your site while also allowing scaleability, user preference to impact the design and to also ensure your content is usable across a variety of mediums. - Kane Felix Miata [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 25/05/2007 05:15 PM Please respond to wsg@webstandardsgroup.org To wsg@webstandardsgroup.org cc Subject Re: [WSG] Converting font size from pt to % or em On 2007/05/25 15:31 (GMT+1000) Kane Tapping apparently typed: Setting the body to font size to 65% - 70% is a good start. Actually it's a bad start, arbitrarily assuming that there's something wrong with the user's choice of default, and reducing it by some arbitrary amount, even though you don't have a clue what it was to start with. Browser default sizes are purposely adjustable so that their users can tailor web page text sizes to suit their own personal needs. http://mrmazda.no-ip.com/auth/bigdefaults.html It's also an excellent definition of disrespect for your site's visitors. -- 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] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] making form elements the same height
PS. The form elements I was referring to are the text field and the submit
button.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Taco Fleur
Sent: Friday, 25 May 2007 5:18 PM
To: wsg@webstandardsgroup.org
Subject: [WSG] making form elements the same height
Hi all,
I have a question I hope one of you might be able to answer.
http://www.clickfind.com.au/test-index.html
I am trying to get the form elements the same height, I would expect that
the following would do the trick;
input.text {
border: 1px solid #A9D46F;
height: 1.2em;
font-size: 1em;
margin: 0;
padding: 0.2em;
}
input.submit {
border: 1px solid #99;
height: 1.2em;
font-size: 1em;
margin: 0;
padding: 0.2em;
}
But it does not, and I do not understand why, I would like to understand why
it does not.
Also, is there any way to align the text on the left hand side of the text
field to the middle of the textfield?
Thanks in advance for any help.
***
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] making form elements the same height
On 25 May 2007, at 5:18 PM, Taco Fleur wrote: http://www.clickfind.com.au/test-index.html I am trying to get the form elements the same height Hi Taco Form Submit buttons are system-level widgets - they're different shapes and sizes according to which browser/OS combination is in use. They're notoriously difficult to style, as in most instances, being generated at the system level, they just won't accept css styling. Have you thought about using a custom image, which you can make the size you want? This is only a partial answer, of course, as an image (unless it's sized in ems or %) won't enlarge as the text is enlarged. You already have a problem in that regard, as one level of enlargement is enough to cause your Submit button to wrap to the next line... (I'm viewing in Safari/Mac - and the Submit button also doesn't resize with text - it's just pushed around.) BTW, 5,712,590 million = 5,712,590,000,000 N ___ omnivision. websight. http://www.omnivision.com.au/ *** 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 25/05/07, Karl Lurman [EMAIL PROTECTED] wrote: Im not the biggest fan of a label 'around' an input. To me, it doesn't make a lot of sense, but I know that its standard practice with a lot of people. I understand that it gives us another means of encapsulating our label/field pair, but again I am unsure on the semantics - it poses the question, what is the purpose of the attribute for in labels? Putting the label around the input is implicit association - it is a standard. It needs to be done correctly though. http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels Using 'for' explicitly associates the label with the control. Stephen http://www.twoplayer.net *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] making form elements the same height
Thanks guys and girls... This is helpful.. Not the answers I was hoping for, but it certainly helps. I am slowly building a JavaScript library that will replace the HTML elements with elements that I can style, so it should eventually not be a problem anymore. PS. :-) I had 6.5 Million there first, changed it and forgot to remove the million, thanks for pointing it out though. BTW, 5,712,590 million = 5,712,590,000,000 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Gleitzman Sent: Friday, 25 May 2007 6:50 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] making form elements the same height On 25 May 2007, at 5:18 PM, Taco Fleur wrote: http://www.clickfind.com.au/test-index.html I am trying to get the form elements the same height Hi Taco Form Submit buttons are system-level widgets - they're different shapes and sizes according to which browser/OS combination is in use. They're notoriously difficult to style, as in most instances, being generated at the system level, they just won't accept css styling. Have you thought about using a custom image, which you can make the size you want? This is only a partial answer, of course, as an image (unless it's sized in ems or %) won't enlarge as the text is enlarged. You already have a problem in that regard, as one level of enlargement is enough to cause your Submit button to wrap to the next line... (I'm viewing in Safari/Mac - and the Submit button also doesn't resize with text - it's just pushed around.) BTW, 5,712,590 million = 5,712,590,000,000 N ___ omnivision. websight. http://www.omnivision.com.au/ *** 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] making form elements the same height
Taco Fleur wrote: Hi all, I have a question I hope one of you might be able to answer. http://www.clickfind.com.au/test-index.html I am trying to get the form elements the same height, I would expect that the following would do the trick; That certainly got me! I'm sorry I can't add much more to what Nick has said. I don't know if this helps, but I think PPK has written on this topic: http://www.quirksmode.org/css/tests/mozie_button.html I hope that helps, to at least understand the phenomenon. Kat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] making form elements the same height
Hi Taco,
Styling form elements as you are hoping to do is not quite that
simple, and a good place to read about this is in a recent article by
Eric Meyer:
http://meyerweb.com/eric/thoughts/2007/05/15/formal-weirdness/
The crux of the article is that there are no standard guidelines for
how browsers should respond to applying various CSS properties to
form controls, and that even if one browser styles the controls how
you would expect, another may not (and probably WILL not, given the
current state of affairs).
That said, here's some advice:
* Don't apply a height to either the submit button, or the text
input. Simply use font-size, and let the browser work out the height.
* Put Your email address: inside a label tag like so:
label for=emailAddressYour email address:/label
Then you could style the label something like:
label {
line-height: 1.2em;
display: block;
float: left;
}
Hopefully then, your label will line up a bit better with the text
input - you should provide that label tag anyway, for accessibility
reasons.
* Don't expect that your submit button will ever match the height of
the input field. If you really want this though, try making the font
size of the submit button larger than the text field, you may be able
to get it to match in a lot of browsers. Or you could use an input
type=image... to get consistency across all browsers.
I hope this helps a bit. Forms are always a fairly tricky thing to
style!
Good Luck!
Travis
On 25/05/2007, at 6:27 PM, Taco Fleur wrote:
PS. The form elements I was referring to are the text field and
the submit
button.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Taco Fleur
Sent: Friday, 25 May 2007 5:18 PM
To: wsg@webstandardsgroup.org
Subject: [WSG] making form elements the same height
Hi all,
I have a question I hope one of you might be able to answer.
http://www.clickfind.com.au/test-index.html
I am trying to get the form elements the same height, I would
expect that
the following would do the trick;
input.text {
border: 1px solid #A9D46F;
height: 1.2em;
font-size: 1em;
margin: 0;
padding: 0.2em;
}
input.submit {
border: 1px solid #99;
height: 1.2em;
font-size: 1em;
margin: 0;
padding: 0.2em;
}
But it does not, and I do not understand why, I would like to
understand why
it does not.
Also, is there any way to align the text on the left hand side of
the text
field to the middle of the textfield?
Thanks in advance for any help.
***
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] dl v table for form layout
I think some people dont understand Forms to well. Without a label how will you label what your inputs are to be used for? On 5/25/07, Stephen Kelly [EMAIL PROTECTED] wrote: On 25/05/07, Karl Lurman [EMAIL PROTECTED] wrote: Im not the biggest fan of a label 'around' an input. To me, it doesn't make a lot of sense, but I know that its standard practice with a lot of people. I understand that it gives us another means of encapsulating our label/field pair, but again I am unsure on the semantics - it poses the question, what is the purpose of the attribute for in labels? Putting the label around the input is implicit association - it is a standard. It needs to be done correctly though. http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels Using 'for' explicitly associates the label with the control. Stephen http://www.twoplayer.net *** 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] Converting font size from pt to % or em
Hi, Yes you're absolutely correct - except that one day is NOW. People with certain visual problems do have their own stylesheets to change fonts/colours to make Webpages accessible to them (and there is no reason why anyone else could not do so either). In order to facilitate this you should only use external stylesheets. Since there are increasingly many different browsers/hardware/OS all of which will present your design differently, designers actively styling pages as they see fit are not second-guessing users - merely stating their preference. Stuart On Fri, May 25, 2007 9:07 am, Kane Tapping wrote: I guess we also shouldnt be second guessing our users choice of font, weight, spacing, color ... positioning ? And one day all users will view the webpages using their own custom user stylesheets... Until that day expect designers to be actively styling their pages as they see fit. Felix Miata [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 25/05/2007 05:15 PM Please respond to wsg@webstandardsgroup.org To wsg@webstandardsgroup.org cc Subject Re: [WSG] Converting font size from pt to % or em On 2007/05/25 15:31 (GMT+1000) Kane Tapping apparently typed: Setting the body to font size to 65% - 70% is a good start. Actually it's a bad start, arbitrarily assuming that there's something wrong with the user's choice of default, and reducing it by some arbitrary amount, even though you don't have a clue what it was to start with. Browser default sizes are purposely adjustable so that their users can tailor web page text sizes to suit their own personal needs. http://mrmazda.no-ip.com/auth/bigdefaults.html It's also an excellent definition of disrespect for your site's visitors. -- 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] *** *** 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] A CMS for POSH sites?
On 5/25/07, Matthew Pennell [EMAIL PROTECTED] wrote: POSH as a concept is not about HTML vs. XHTML, it's about using the correct semantic elements. Agreed, when I read the question I thought it was about getting an editor to use pre-built sections of code to create certain HTML patterns, but I guess not. As David says, most platforms - Wordpress, Textpattern, Expression Engine - will output whatever you put into their templates. Wordpress will, however, you might have to dig around to prevent it putting in closing slashes on head elements. (Closing slashes on content items such as images are fine, they are within the body and do not cause validation issues.) -Alastair *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] A CMS for POSH sites?
On 25 May 2007, at 11:54, Alastair Campbell wrote: Wordpress will, however, you might have to dig around to prevent it putting in closing slashes on head elements. (Closing slashes on content items such as images are fine, they are within the body and do not cause validation issues.) Not causing validation issues does not make them fine; even if the vast majority of user agents don't respect it, img / in an HTML document means An image element followed by a greater than sign. The HTML specification explicitly advises authors to avoid them: http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7 -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] screen readers repeated legends (was dl v table for form layout)
On 25 May 2007, at 01:08:49, Rebecca Cox wrote: On 5/23/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: As an aside, note that screen readers will read the legend of a fieldset before the label of every element in the fieldset, so legends should be kept short and sweet This is interesting, just wondered if you had any other info about this, which screen readers in particular and how customisable is this behaviour to a user (eg is there an option to disable the repetition of this info). Cheers Rebecca Hi, I got this from Ann McMeekin's presentation Accessibility: what not to do at the WSG London meetup back in February http:// muffinresearch.co.uk/wsg/280207.php. There's a podcast available at: http://muffinresearch.co.uk/wsg/audio/07/02/28/ann.mp3 I don't have an exhaustive knowledge of screen readers, but what I've gathered from listening to those who do is that: a) They tend to be highly configurable; b) 99.9% of users never change from the default settings. Maybe somebody with more experience in this area can chip in with more detailed info? 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] ***
[WSG] Design vs Standards
On May 25, 2007, at 7:08 AM, Stephen Kelly wrote: On 25/05/07, Stuart Foulstone [EMAIL PROTECTED] wrote: Since there are increasingly many different browsers/hardware/OS all of which will present your design differently, designers actively styling pages as they see fit are not second-guessing users - merely stating their preference. Or expressing themselves, or communicating. One text size does not fit all. And most users don't want to decide for themselves, even if they can. Design always has to adapt to the constraints of the medium. In print the presentational constraints are very different for, say, a newspaper printed in black ink at 85 lpi on newsprint, vs. a high-end magazine printed at 200 lpi in 4c (or more with spot colors) at 200 lpi. An ad designer producing a piece for both would not insist that the newspaper adapt to reproduce his beautiful 4c ad exactly as he conceived it. Obviously concessions must be made to the medium, and a good designer understands and adapts to those constraints. When designing a web page, a designer may certainly have a perfectly legitimate vision of an optimal version of the page, and I would say the developer's task is to present the closest possible version of that optimal view in as many browsers as possible at default settings. The good designer will take into account the various user display options and will do everything he can to ensure that the design holds up under those options. Designers who cannot embrace, or at least adapt to the medium will eventually be forced out. there's still plenty of print work. However, characterizing designers as arrogant idiots, denigrating marketing people and various other self-righteous (self-pitying?) reactions that I've noticed from time to time on these threads is counter-productive. Good designers welcome constraints as a challenge, so rather than tearing one's hair out behind closed doors, how about engaging in a dialogue, educate the designer about the medium? I have found more often than not that once I explain why something doesn't really work, a designer will gladly collaborate to find a solution. And, yes, designers, even marketing people, have legitimate concerns and desires, and the developer has an equal duty to understand and as far as possible accommodate those concerns and desires. If the aim of this group is truly to promote the adoption and use of web standards, then it would be good to note the moderators' recent comments and apply them to our interactions with clients, bosses, designers, even (god bless 'em) marketing wonks. (Obviously these thoughts do not apply to designers who are expressing themselves, or communicating - those are artists and are at perfect liberty to be as rigid as they choose. Hence the cliche starving artist). Andrew http://www.andrewmaben.com [EMAIL PROTECTED] In a well designed user interface, the user should not need instructions. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] A CMS for POSH sites?
On 5/25/07, David Dorward [EMAIL PROTECTED] wrote: On 25 May 2007, at 11:54, Alastair Campbell wrote: Wordpress will, however, you might have to dig around to prevent it putting in closing slashes on head elements. (Closing slashes on content items such as images are fine, they are within the body and do not cause validation issues.) Not causing validation issues does not make them fine; even if the vast majority of user agents don't respect it, img / in an HTML document means An image element followed by a greater than sign. The HTML specification explicitly advises authors to avoid them: http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.7 Getting Wordpress to use HTML 4.01 as opposed to XHTML is something I do all the time, and it's not hard at all. Read my article: http://www.christianmontoya.com/2006/02/13/serve-your-weblog-as-html-401/ Wordpress can be pretty good about using semantic HTML (it encourages em and strong at the least) and there are some plugins out there that add microformats support if you are interested in that. -- -- Christian Montoya christianmontoya.net .. designtocss.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 08:45 (GMT+0100) Stephen Kelly apparently typed: On 25/05/07, Felix Miata [EMAIL PROTECTED] wrote: On 2007/05/25 15:31 (GMT+1000) Kane Tapping apparently typed: Setting the body to font size to 65% - 70% is a good start. Actually it's a bad start, arbitrarily assuming that there's something wrong with the user's choice of default, and reducing it by some arbitrary amount, The majority of users won't know how to adjust their default browser settings though. That matters not. What matters is: 1-that any do 2-that they are all provided the means to do so (most anyway, since some use browsers located in public places which have had this ability disabled) 3-that designers not respecting user choice, whether made actively or passively, means users do not get what they want, and deserve 4-that users are the only ones in good position to do so. The designer is most assuredly not, since he has no way of knowing any size on a display he can't see, and isn't using the the eyes of the user. 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. -- 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] dl v table for form layout
Good morning :-) I should have expanded my example a little more since I do use the for attribute in labels, even when directly (implicitly?) associated: form fieldset legendSend us your contact info/legend pFields marked with * (asterisk) are required./p label for=namespan*/span Name: ?php echo error(); ? input type=text id=name name=name value= / /label label for=emailspan*/span Email: ?php echo error(); ? input type=text id=email name=email value= / /label label for=urlWeb site: input type=text id=url name=url value= / /label /fieldset /form (Note: The labels/names were chosen to best accommodate autofill users.) Karl Lurman wrote: About putting the error in the label, not sure on that one either. Is an error a label after all... Me neither actually, just not sure. In a way I think it's smart for accessibility in that it changes that label (changes what it says and what it means), and for locating the offense I think it's smart. On my form the errors are on a different screen with a #results bookmark so when submitted the user is brought directly to the result of their action (same for the success confirmation message), but getting back can be problematic. Either way, for screen reader users it can't be easy to know: 1) The results of their action. 2) How/where to fix the result if needed if unsuccessful. Man, I hope for us all that the new HTML and XHTML standards cover form semantics better... Hehe, that might be a good thing. Take out some of the gray areas. It'll have to be pretty complete though since most of the gray areas are content-related and there are so many unique situations :-) Cheers and happy Friday! Mike Cherim *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Mocking up web interfaces
Hi When I worked in Windows I loved Fireworks for creating web graphics but I always found that writing code was actually more efficient than creating a graphic, as I had the code for later use. For mocking up a site I generally use pencil and paper, then ask my wife about it who has a good layout brain, then build the initial site using my app. framework. To create graphics I use, Inkscape (http://www.inkscape.org) which is also available for Windows, Gimp for photos. I'm trying to get my head around Krita and Karbon14 (both KDE apps). Is there a KDE tool like Fireworks out there? (replies off list thanks) Cheers James *** 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 15:24 (GMT+0800) Nick Cowie apparently typed: 1em = 100% = 16px = 16pt (yes 1px = 1pt for the screen) in all PC based browsers since 2000 This statement would be technically incorrect even if sic s/16pt/12pt/. s/16pt/12pt/ because the majority of systems are running a nominal DPI/PPI of 96, which because points are 72 DPI real, means there is 1.333px per pt nominal. Another reason it's incorrect is that not all modern browsers use the common 16px/12pt default. http://archivist.incutio.com/viewlist/css-discuss/68515 The third reason follows. unless changed by the user or PC manufacturer (this is becoming a little more common with laptops having twice the pixels per inch or cm that desktop screens). While it is true that it is becoming more common, it's been doing so long enough that it is already very common, particularly since laptops have been outselling desktops for several years. The higher resolution laptops tend to have windoz set to 120 DPI instead of 96 DPI, with the result that their 12pt defaults are all 20px instead of 16px. The ones that don't use the 120 setting tend to not sell very well because so many people see everything is too tiny otherwise compared to the systems they're familiar with. -- 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] dl v table for form layout
Hi, The for attribute should NOT be used when the label tag encloses the label text. On Fri, May 25, 2007 2:45 pm, Mike at Green-Beast.com wrote: Good morning :-) I should have expanded my example a little more since I do use the for attribute in labels, even when directly (implicitly?) associated: form fieldset legendSend us your contact info/legend pFields marked with * (asterisk) are required./p label for=namespan*/span Name: ?php echo error(); ? input type=text id=name name=name value= / /label label for=emailspan*/span Email: ?php echo error(); ? input type=text id=email name=email value= / /label label for=urlWeb site: input type=text id=url name=url value= / /label /fieldset /form (Note: The labels/names were chosen to best accommodate autofill users.) Karl Lurman wrote: About putting the error in the label, not sure on that one either. Is an error a label after all... Me neither actually, just not sure. In a way I think it's smart for accessibility in that it changes that label (changes what it says and what it means), and for locating the offense I think it's smart. On my form the errors are on a different screen with a #results bookmark so when submitted the user is brought directly to the result of their action (same for the success confirmation message), but getting back can be problematic. Either way, for screen reader users it can't be easy to know: 1) The results of their action. 2) How/where to fix the result if needed if unsuccessful. Man, I hope for us all that the new HTML and XHTML standards cover form semantics better... Hehe, that might be a good thing. Take out some of the gray areas. It'll have to be pretty complete though since most of the gray areas are content-related and there are so many unique situations :-) Cheers and happy Friday! Mike Cherim *** 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
On 25 May 2007, at 15:40, Stuart Foulstone wrote: The for attribute should NOT be used when the label tag encloses the label text. Why not? The specification doesn't appear to forbid it. Does it cause problems in any user agents? -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ *** 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
Stuart Foulstone wrote: Hi, The for attribute should NOT be used when the label tag encloses the label text. What are the dangers? Regards, Barney *** 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 15:24 (GMT+0800) Nick Cowie apparently typed: 1em = 100% = 16px = 16pt (yes 1px = 1pt for the screen) in all PC based browsers since 2000 Not true. On high resolution displays (widescreen laptops, for example) that use 120 dpi instead of the standard, classic 96 dpi and use Windows' font-scaling to compensate, 1em = 100% = 18px = ?pt. -- -- Christian Montoya christianmontoya.net .. designtocss.com *** 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
David Dorward wrote: Why not? In response to... Stuart Foulstone wrote: The for attribute should NOT be used when the label tag encloses the label text. My question exactly. I can't see that it is in any way harmful. Cheers. Mike Cherim *** 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
Barney Carroll wrote: Stuart Foulstone wrote: Hi, The for attribute should NOT be used when the label tag encloses the label text. What are the dangers? Regards, Barney Hello, Its probably not a danger per se for most people but if you ever use a cms that writes out form fields sometimes they write out hidden fields along with them, if these are wrapped in a label along with the intended input/select/whatever then firefox chokes, I can't remember now whether it was only when the visible input wrapped in the label had no id matching the for attribute. If the label wraps a select and there are hidden inputs inside that label then the select does not stay open unless you click and drag the mouse to the desired option. Basically either way is fine, so long as it's one input per label. Rob *** 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
Sorry, I meant to say, when the label teg encloses the label text AND the input. However, on checking W3C acessibility guidelines, it appears I may be wrong about this. (http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels ) But, in the W3C recomendations for form labels it gives implicit/explicit labels as two distinct methods (one not using the for). (http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.9.1 ) Interesting... On Fri, May 25, 2007 3:40 pm, Stuart Foulstone wrote: Hi, The for attribute should NOT be used when the label tag encloses the label text. On Fri, May 25, 2007 2:45 pm, Mike at Green-Beast.com wrote: Good morning :-) I should have expanded my example a little more since I do use the for attribute in labels, even when directly (implicitly?) associated: form fieldset legendSend us your contact info/legend pFields marked with * (asterisk) are required./p label for=namespan*/span Name: ?php echo error(); ? input type=text id=name name=name value= / /label label for=emailspan*/span Email: ?php echo error(); ? input type=text id=email name=email value= / /label label for=urlWeb site: input type=text id=url name=url value= / /label /fieldset /form (Note: The labels/names were chosen to best accommodate autofill users.) Karl Lurman wrote: About putting the error in the label, not sure on that one either. Is an error a label after all... Me neither actually, just not sure. In a way I think it's smart for accessibility in that it changes that label (changes what it says and what it means), and for locating the offense I think it's smart. On my form the errors are on a different screen with a #results bookmark so when submitted the user is brought directly to the result of their action (same for the success confirmation message), but getting back can be problematic. Either way, for screen reader users it can't be easy to know: 1) The results of their action. 2) How/where to fix the result if needed if unsuccessful. Man, I hope for us all that the new HTML and XHTML standards cover form semantics better... Hehe, that might be a good thing. Take out some of the gray areas. It'll have to be pretty complete though since most of the gray areas are content-related and there are so many unique situations :-) Cheers and happy Friday! Mike Cherim *** 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] *** -- 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] screen readers repeated legends (was dl v table for form layout)
Certainly JAWS reads the content of the legend element before each label element as described previously, and I agree about keeping the legend short. My understanding is that other 'professional' screen readers also do, although some of the free ones may not since they typically have greatly reduced functionality. I would also agree with the statement that most users never change from the default settings. Whilst the ability to customise settings may appear to be a good idea, it causes difficulties when the user works on a different machine that has the default settings or different customisation. I understand that Freedom Scientific are working on a means of making the customisation portable, which will at least partially resolve that problem. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Fitzsimons Sent: 25 May 2007 14:01 To: wsg@webstandardsgroup.org Subject: Re: [WSG] screen readers repeated legends (was dl v table for form layout) On 25 May 2007, at 01:08:49, Rebecca Cox wrote: On 5/23/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: As an aside, note that screen readers will read the legend of a fieldset before the label of every element in the fieldset, so legends should be kept short and sweet This is interesting, just wondered if you had any other info about this, which screen readers in particular and how customisable is this behaviour to a user (eg is there an option to disable the repetition of this info). Cheers Rebecca Hi, I got this from Ann McMeekin's presentation Accessibility: what not to do at the WSG London meetup back in February http:// muffinresearch.co.uk/wsg/280207.php. There's a podcast available at: http://muffinresearch.co.uk/wsg/audio/07/02/28/ann.mp3 I don't have an exhaustive knowledge of screen readers, but what I've gathered from listening to those who do is that: a) They tend to be highly configurable; b) 99.9% of users never change from the default settings. Maybe somebody with more experience in this area can chip in with more detailed info? 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] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] semantic HTML for intro text
Hi all, Just marking up a page, the layout seems to require various tags, as far as I can gather, I need seperate tags for: - The intro heading (a H2) - The orange intro text (not sure what tag to add here) - a smaller, bold heading, same size as body text (probably a h3) - a quote (probably a blockquote tag) My question is, what would be the best semantic tags to use here, that will be picked up by assistive technology and validate for XHTML 1.0 Transitional. In particular, I want to know about the Orange intro text and the quote. Any suggestions would be great, I have posted a JPEG here: http://www.method.com.au/storage/sampleText.gif Cheers Paul *** 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 00:58 (GMT-0700) Paul Novitski apparently typed:
At 5/25/2007 12:15 AM, Felix Miata wrote:
On 2007/05/25 15:31 (GMT+1000) Kane Tapping apparently typed:
Setting the body to font size to 65% - 70% is a good start.
Actually it's a bad start, arbitrarily assuming that there's something wrong
with the user's choice of default, and reducing it by some arbitrary amount,
even though you don't have a clue what it was to start with.
In my efforts to build zoomable layouts [max-width at window width]
I've found it convenient to declare a body font-size of 62.5%
The Clagnutt 62.5% scourge or bane of user stylesheets. :-(
so that, on a PC with a default font size of 16px, 1em = 10px at normal
zoom. It makes calculations very easy. For example, if you begin
with a content column of 790px, that converts to 79em and becomes
zoomable. An image that's 100px wide becomes 10em wide.
It may be convenient as long as you find it necessary to fight the inherent
nature of the web instead of embracing it. Pixels are a purely arbitrary
size that bear no relationship to any particular physical size, and
certainly not one that bears any useful relationship to right sized fonts
from a typical web user's perspective.
Instead of wanting a content column of Xpx, you should want a column of Xem
or Xex or Xwords, from which you set sizes in em or ex or %, and let the
user agents futz over how many pixels to use to do it. The web isn't print.
In that context, one can make one's base font size 1.6em (16px at
normal zoom on a PC). This presents body text at the same size it
would have been had font-size not been styled, yet at the same time
makes scaling calculations much easier for the designer.
But not easier for the visitor
It seems like a win-win situation. Can you see a flaw?
Every day
Even on Mac monitors running at 96dpi, reducing the text to 62.5% and
then increasing to 1.6 should bring it back to 100% of the default
size, whatever that may be.
Here's a site probably pretty typical of Clagnutt 62.5% sites: http://eons.com/
Here's what its designers probably expect it to look like (same in FF and
Safari):
http://mrmazda.no-ip.com/SS/eons-16ms.jpg
Here's what it looks like when the user has bumped his default up from 16px
to 20px (same in FF and Safari): http://mrmazda.no-ip.com/SS/eons-20ms.jpg
Here's what it looks like in Safari with the 20px default size enforced as a
minimum: http://mrmazda.no-ip.com/SS/eons-20ms-m20.jpg
And here's what it looks like in FF with the 20px default size enforced as a
minimum: http://mrmazda.no-ip.com/SS/eons-20mf-m20.jpg
Note the radical difference between the latter two applies also when a user
stylesheet employs the simple 'body {font-size: 100% !important}' rule
designed to counteract web sites that employ the more common methods of
undersizing content text.
Since neither Opera nor Safari are available on my OS of choice, and thus
have only SeaMonkey and Firefox to choose from, I get to choose between
gigantic fonts on Clagnut pages, or turning off author styles entirely.
Clearly Eons is a site designed neither for its own users (people over 50,
whose eyesight is poorer than average), nor for cross-browser compatibility,
nor to accommodate users generally who need text to be big enough to read
and who use text zoom and/or user stylesheets and/or minimum text size
and/or a higher than 96 DPI system setting to do it.
One thing that is standard about the web is there is no standard
relationship between the size text a designer sees on his screen and the
size a visitor sees on his own screen on that same page.
http://pages.prodigy.net/chris_beall/TC/You%20don't%20know.html
--
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] A CMS for POSH sites?
On Fri, 25 May 2007 08:56:31 -0400, Christian Montoya wrote: Getting Wordpress to use HTML 4.01 as opposed to XHTML is something I do all the time, and it's not hard at all. Read my article: http://www.christianmontoya.com/2006/02/13/serve-your-weblog-as-html-401/ Thank you all for your feedback. The article Christian wrote is particularly useful. Cordially, David -- *** 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 18:07 (GMT+1000) Kane Tapping apparently typed: Felix Miata wrote: arbitrarily assuming that there's something wrong with the user's choice of default ... I guess we also shouldnt be second guessing our users choice of font, weight, spacing, color ... positioning ? Those are part of a continuum of things that have a greater or lesser impact on legibility/usability compared to the foundational element that is text size. CSS provides both users and authors a great deal of power. The wise exercise restraint is utilizing that power. -- 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] semantic HTML for intro text
On 25 May 2007, at 18:03:06, Paul Collins wrote: Hi all, Just marking up a page, the layout seems to require various tags, as far as I can gather, I need seperate tags for: - The intro heading (a H2) - The orange intro text (not sure what tag to add here) - a smaller, bold heading, same size as body text (probably a h3) - a quote (probably a blockquote tag) My question is, what would be the best semantic tags to use here, that will be picked up by assistive technology and validate for XHTML 1.0 Transitional. In particular, I want to know about the Orange intro text and the quote. Any suggestions would be great, I have posted a JPEG here: http://www.method.com.au/storage/sampleText.gif Assuming the page on which this will appear already has an h1: h2.../h2 p class=introduction.../p h3...h3 p.../p blockquotep.../p/blockquote p.../p and then apply things like the different font sizes weights, colours and spacing with CSS. If there will only ever be one introductory paragraph per page, then you could use p id=introduction instead. HTH, 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] ***
Jaws 8 MP3s - was Re: [WSG] dl v table for form layout
Hi all, To help with the whole forms/fieldsets/accessibility debate, here's some links to a couple of (edited) MP3 files of Jaws 8 reading Mike Cherim's accessible form example: http://green-beast.com/gbcf/ Virtual cursor mode: http://www.nickfitz.co.uk/tests/accessibility/audio/Jaws%208/Jaws- AccessibleForm-VirtualCursor.mp3 Forms mode: http://www.nickfitz.co.uk/tests/accessibility/audio/Jaws%208/Jaws- AccessibleForm-FormsMode.mp3 On 25 May 2007, at 20:09:03, Mike at Green-Beast.com wrote: I must say, forms mode was a LOT better. It *seems* that my claim of it being an accessible form is indeed true unless you heard something that I didn't. It seemed OK to me, although I'm not a screen reader user, just experimenting. I was mainly interested in testing what happened when there were nested fieldsets, and it seems that only the innermost fieldset's legend is spoken before a form control's label, so nested fieldsets aren't a problem for this one screen reader, at least. I will say this: My goodness it's fast reading. I had a hard time with comprehension due to the speed, but maybe that's adjustable and you turned it up a bit (?). Plus I'm not practiced in this sort of browsing. It is adjustable, but I haven't changed any of the default settings except for switching to the supposedly English accent from the default (American) one. From what I've been told, many experienced screen reader users set the voice much faster than the default - it's about the only setting people do change. Note that, in forms mode, I was just tabbing to the next field once the voice had said its piece, and edited out a couple of pauses where I got distracted by something on the telly :-) Thanks for going through the trouble of making these. Curious, will these be permanently available? If not, may I get copies of the recordings from you to post (with credit given of course). I'll post the links right on that page for the world to hear. I've got no plans to remove them, and will hopefully find time over the weekend to set up a page on my site linking to them. You're welcome to download them and host copies on your own site, as is anybody else who wants to. Anything to save my bandwidth :-) Cheers, Nick. - Original Message - From: Nick Fitzsimons [EMAIL PROTECTED] To: Mike at Green-Beast.com [EMAIL PROTECTED] Sent: Friday, May 25, 2007 2:48 PM Subject: Re: [WSG] dl v table for form layout On 24 May 2007, at 22:01:52, Mike at Green-Beast.com wrote: See a real (somewhat styled) example: http://green-beast.com/gbcf/ (Demo Form) Mike, I've taken the liberty of accessing your demo page using Jaws 8 with MSIE 6, first in virtual cursor mode, then in forms mode. I've then edited the audio down into two MP3 files, one for each mode. Are you OK with me posting these online, as I think they could be useful for people wanting to learn how screen readers handle forms (well, one screen reader)? If that's OK with you I'll post the links to the WSG list; apart from anything else I think many people will be rather surprised by the way the legend element is handled in forms mode :-) If you want a listen they're at: http://www.nickfitz.co.uk/tests/accessibility/audio/Jaws%208/Jaws- AccessibleForm-VirtualCursor.mp3 http://www.nickfitz.co.uk/tests/accessibility/audio/Jaws%208/Jaws- AccessibleForm-FormsMode.mp3 Cheers, Nick. - Nick Fitzsimons http://www.nickfitz.co.uk/ -- 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] Converting font size from pt to % or em
On 2007/05/25 00:58 (GMT-0700) Paul Novitski apparently typed: In my efforts to build zoomable layouts [max-width at window width] I've found it convenient to declare a body font-size of 62.5% At 5/25/2007 10:16 AM, Felix Miata wrote: The Clagnutt 62.5% scourge or bane of user stylesheets. :-( Felix, thanks for your lucid reply, but you apparently didn't actually read my posting even as you quoted it. I'm talking about creating zoomable pages and you lecture me about the disadvantages of fixed width! Sheesh. The reason I'm needing to convert from pixels to ems is that I'm implementing designs mocked up as bitmapped images in Photoshop InDesign. The designer creates the mockup to depict the page as they want to see it, which I interpret as the way the page should look at normal zoom. I translate all their pixel measurements to ems so that the page is zoomable. The arithmetic on this gets tedious, so I use 62.5% to make 1em = 10px to make my life easier. I could as easily have set the body font-size to 6.25% so that 1 page em = 1 mockup pixel but I thought I might break something. The pages I craft this way are not absolutely zoomable -- I halt the layout zoom at window width to avoid the pitfalls of horizontal scrollbar and hidden content which I consider to be accessibility concerns. But I want the pages to be zoomable within that constraint to enable people to enlarge their text to the greatest extent possible without breaking the layout (i.e. enlarging single words beyond the width of their containers). 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] Converting font size from pt to % or em
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 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: setting the body font size to 65%-76% or so is the size that 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. 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. Isn't this basically the same kind of thing that a designer does when they apply zeroing to the body margins or body padding or to any other CSS element that different browsers set differently. Designers modify the default settings of CSS elements all the time - that is what a designer does in order to create a design. Sure, designers should create designs that scale nicely and play well with user specified font sizes, and of course web designers should learn to embrace the idea that the sites they create will be accessed in different ways and with different technologies that will not permit pixel-perfect identical versions to be served to all users. However, that doesn't mean that they have to give up on trying to produce designs that look almost identical to the way they want in the default settings of the browsers that appear most frequently in their site traffic logs. I wonder, is it possible that 65%-76% base size body font is in fact the level that has become a kind of standard on the web? Or perhaps the web has a dual standard: one is 65-76% and the other is 100%? In any case, I'm not convinced that the choice by many web designers to use 65-76% will be easily overcome, especially given its usefulness from a design standpoint, and the apparent arbitrariness of the 100% alternative. Phil. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] screen readers repeated legends (was dl v table for form layout)
Hi, Does the ability for the user of a screenreader to customise at leasst partially resolve the problem or should we design for the default screenreader (which would mean Jaws presumably, since it seemms to be the most commonly used)? If we then design to this standard, we should then at least have a starting point for further constructive criticism. On Fri, May 25, 2007 5:54 pm, Steve Green wrote: Certainly JAWS reads the content of the legend element before each label element as described previously, and I agree about keeping the legend short. My understanding is that other 'professional' screen readers also do, although some of the free ones may not since they typically have greatly reduced functionality. I would also agree with the statement that most users never change from the default settings. Whilst the ability to customise settings may appear to be a good idea, it causes difficulties when the user works on a different machine that has the default settings or different customisation. I understand that Freedom Scientific are working on a means of making the customisation portable, which will at least partially resolve that problem. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Fitzsimons Sent: 25 May 2007 14:01 To: wsg@webstandardsgroup.org Subject: Re: [WSG] screen readers repeated legends (was dl v table for form layout) On 25 May 2007, at 01:08:49, Rebecca Cox wrote: On 5/23/07, Nick Fitzsimons [EMAIL PROTECTED] wrote: As an aside, note that screen readers will read the legend of a fieldset before the label of every element in the fieldset, so legends should be kept short and sweet This is interesting, just wondered if you had any other info about this, which screen readers in particular and how customisable is this behaviour to a user (eg is there an option to disable the repetition of this info). Cheers Rebecca Hi, I got this from Ann McMeekin's presentation Accessibility: what not to do at the WSG London meetup back in February http:// muffinresearch.co.uk/wsg/280207.php. There's a podcast available at: http://muffinresearch.co.uk/wsg/audio/07/02/28/ann.mp3 I don't have an exhaustive knowledge of screen readers, but what I've gathered from listening to those who do is that: a) They tend to be highly configurable; b) 99.9% of users never change from the default settings. Maybe somebody with more experience in this area can chip in with more detailed info? 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] *** *** 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] Converting font size from pt to % or em
On 5/25/07, Philip Kiff [EMAIL PROTECTED] wrote: 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 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: setting the body font size to 65%-76% or so is the size that 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. 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. Isn't this basically the same kind of thing that a designer does when they apply zeroing to the body margins or body padding or to any other CSS element that different browsers set differently. Designers modify the default settings of CSS elements all the time - that is what a designer does in order to create a design. Sure, designers should create designs that scale nicely and play well with user specified font sizes, and of course web designers should learn to embrace the idea that the sites they create will be accessed in different ways and with different technologies that will not permit pixel-perfect identical versions to be served to all users. However, that doesn't mean that they have to give up on trying to produce designs that look almost identical to the way they want in the default settings of the browsers that appear most frequently in their site traffic logs. I wonder, is it possible that 65%-76% base size body font is in fact the level that has become a kind of standard on the web? Or perhaps the web has a dual standard: one is 65-76% and the other is 100%? In any case, I'm not convinced that the choice by many web designers to use 65-76% will be easily overcome, especially given its usefulness from a design standpoint, and the apparent arbitrariness of the 100% alternative. 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). -- -- Christian Montoya christianmontoya.net .. designtocss.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] semantic HTML for intro text
Hi, If the choice of the colour orange is to add emphasis to this text, the answer to this part is really a no brainer - code it with emphasis (the actual colour/styling is down to the CSS). I would use strong markup for this. On Fri, May 25, 2007 7:56 pm, Nick Fitzsimons wrote: On 25 May 2007, at 18:03:06, Paul Collins wrote: Hi all, Just marking up a page, the layout seems to require various tags, as far as I can gather, I need seperate tags for: - The intro heading (a H2) - The orange intro text (not sure what tag to add here) - a smaller, bold heading, same size as body text (probably a h3) - a quote (probably a blockquote tag) My question is, what would be the best semantic tags to use here, that will be picked up by assistive technology and validate for XHTML 1.0 Transitional. In particular, I want to know about the Orange intro text and the quote. Any suggestions would be great, I have posted a JPEG here: http://www.method.com.au/storage/sampleText.gif Assuming the page on which this will appear already has an h1: h2.../h2 p class=introduction.../p h3...h3 p.../p blockquotep.../p/blockquote p.../p and then apply things like the different font sizes weights, colours and spacing with CSS. If there will only ever be one introductory paragraph per page, then you could use p id=introduction instead. HTH, 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] *** -- 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] screen readers repeated legends (was dl v table for form layout)
To answer the question, JAWS is the most widely used screen reader by a long way in the English speaking world and some other markets, and anecdotal evidence suggests that it is invariably used without any relevant changes to the configuration settings. I hesitate to call it a standard because its own behaviour changes from version to version, although some aspects are very consistent. Nevertheless, it is the only sensible reference point for discussion. I would add the following points: 1. Some aspects of design affect screen reader users irrespective of the screen reader they use. Designers should be aware of these issues, as they should be aware of issues facing other user groups. 2. Few aspects of behaviour are the same with all screen readers. For instance most 'professional' products such as JAWS announce semantic information such as headings and lists, but some common ones including VoiceOver (built into Mac OS X 10.4) do not. Some do not announce tables, JAWS announces some tables and FireVox announces all tables. In the absence of label elements, JAWS 'intelligently' associates nearby text with form controls but other products do not. JavaScript support varies greatly. And so on. 3. It is dangerous to specifically design for a particular product because even the behaviour of one product varies from version to version. Not only do features get added, but existing behaviours change. And if you install a screen reader on a different browser it will behave differently due to differences in the way it interacts with the browser's DOM and the varying levels of MSAA support in browsers. 4. Some aspects of customisation reflect the user's preferences. The punctuation verbosity level (none, some, most or all) would be an example. The user adjusts this at their own risk, and the designer does not need to take it into account. The language and synthesizer voice would be others. 5. You cannot rely on users changing the configuration options even when it becomes easy to do so. Skill levels can be very high (our trainers are awesome) but average skill levels are very low. When you consider that most fully-able users don't even know you can change the font size, it's unreasonable to expect screen reader users to be able to understand the consequences of the hundreds (really!) of configuration options available to them. Before worrying about the minutiae of screen reader behaviour I think that designers should: a. Code to standards (not a problem for subscribers to this list). b. Understand the users and their needs. This is a big problem because few designers get the opportunity to see their designs used by any kind of users, disabled or otherwise. Hands up anyone who has done any user testing this year. Or ever. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Foulstone Sent: 25 May 2007 22:53 To: wsg@webstandardsgroup.org Subject: RE: [WSG] screen readers repeated legends (was dl v table for form layout) Hi, Does the ability for the user of a screenreader to customise at leasst partially resolve the problem or should we design for the default screenreader (which would mean Jaws presumably, since it seemms to be the most commonly used)? If we then design to this standard, we should then at least have a starting point for further constructive criticism. *** 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/25/2007 03:10 PM, 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).
ruin? Wouldn't it just make everything larger if they overrode the
stylesheet with, say, body {font-size: 100%}?
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.
(The past tense of the verb to width I just coined is so difficult
to pronounce I just had to use it.)
Regardth,
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
On 5/25/07, Paul Novitski [EMAIL PROTECTED] wrote:
At 5/25/2007 03:10 PM, 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).
ruin? Wouldn't it just make everything larger if they overrode the
stylesheet with, say, body {font-size: 100%}?
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.
(The past tense of the verb to width I just coined is so difficult
to pronounce I just had to use it.)
It can ruin text if it means that things suddenly get much bigger than
the user or designer ever expected and (sometimes) breaks out of
containers. If I enforce 18px as a default because I have a high
resolution display and no elegant way of scaling fonts, I would expect
all text to be just a step larger than the default 16px that most
users at 96 dpi would get. But then you are talking about a page where
the default was intended to start at 10px getting enlarged by a factor
of 1.4, for example, on a container, and with my default of 18px
suddenly I'm getting 25 or 26 px, much much bigger than what I wanted
and bigger than what the designer expected. That's ruined in my book.
IMO it's not hard to just leave the default body size alone and size
from there, which is why I do that in my own stylesheets.
--
--
Christian Montoya
christianmontoya.net .. designtocss.com
***
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
Stuart Foulstone schreef: But, in the W3C recomendations for form labels it gives implicit/explicit labels as two distinct methods (one not using the for). (http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.9.1 ) On that page it also says To associate a label with another control implicitly, the control element must be within the contents of the LABEL element. In this case, the LABEL may only contain one control element. The label itself may be positioned before or after the associated control. You could read that as if, when you do use the 'for' attribute, you may have more than one control element contained within the LABEL. Does anyone knows something about that? cheers. Sander *** 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/25/2007 03:10 PM, Christian Montoya wrote:
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).
On 5/25/07, Paul Novitski [EMAIL PROTECTED] wrote:
ruin? Wouldn't it just make everything larger if they overrode the
stylesheet with, say, body {font-size: 100%}?
At 5/25/2007 06:16 PM, Christian Montoya wrote:
It can ruin text if it means that things suddenly get much bigger than
the user or designer ever expected and (sometimes) breaks out of
containers. If I enforce 18px as a default because I have a high
resolution display and no elegant way of scaling fonts, I would expect
all text to be just a step larger than the default 16px that most
users at 96 dpi would get. But then you are talking about a page where
the default was intended to start at 10px getting enlarged by a factor
of 1.4, for example, on a container, and with my default of 18px
suddenly I'm getting 25 or 26 px, much much bigger than what I wanted
and bigger than what the designer expected. That's ruined in my book.
IMO it's not hard to just leave the default body size alone and size
from there, which is why I do that in my own stylesheets.
OK, I'm being persuaded.
I have a high resolution display and no elegant way of scaling fonts
Do you mean no elegant way to scale them in a user stylesheet or no
elegant way to scale them in real time, e.g. with a mouse wheel? In
either case I'm curious for an elaboration on this. (I assume you're
talking about a hypothetical user here and not yourself...)
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] Converting font size from pt to % or em
On Fri, 25 May 2007 10:48:29 +0530, Sagnik Dey wrote: Hi Guys, I'm developing a website that have some standards defined. The font size specified is 9pt. But due to accessibility standards I wanted to convert that in % or em. Can anybody tell what do i need to use to view the same size in different browsers? Experimenting in IE7, Opera 9, FF2, and NS 7.2 on a Win xp PC running at 120 DPI shows all of them display text specified as 9pt to be 15px in size. I think this will be the same at 96 DPI. Same size in different browsers is not really achievable. But you do raise an interesting question, as I have been reading Richard Rutter's ideas on composing to a rhythm.[1]. He employs a scale of font sizes that are measured in points. It occurred to me that a base of ten points would make it easy to use percents or ems - along the lines of the (problematic) idea of using 62.5% as a base font size to represent ten pixels. 10pt translates to 17px if my browsers interpretation of points is to be trusted. Now comes the tricky bit that I need help with. We could use 17px as the base font size, but IE Win will not resize the results. We could use a base of 104.2% to help IE users, but at 120 DPI the results are 25% bigger in both IE and Opera. The bigger text may not affect the scale I am attempting - I need to do more experiments. [1] http://24ways.org/2006/compose-to-a-vertical-rhythm Cordially, David -- *** 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 May 26, 2007, at 11:16 AM, Paul Novitski wrote: Do you mean no elegant way to scale them in a user stylesheet or no elegant way to scale them in real time, e.g. with a mouse wheel? I have my minimum font-size set to 12px [1] (Gecko browser), or sometimes 14px (when I'm tired, and really p*** by mouse type and the need to zoom in way to often) * No elegant way to scale the whole thing correctly in a user stylesheet, short of rewriting the whole author stylesheet [2]: with the 62.5% 'trick', the base for all computation will be 12px in my case. Say I reset the font-size to 16px for a particular site (using @-moz-document), all scaling in that author style-sheet will be oversized, as I thing Christian explained). * No nice way to zoom out in real time, due to the clash between minimum font-size and the author specified miniscule base. [1] that is my minimum font-size, below which I cannot read text. It is _not_ my preferred font-size. [2] user stylesheets are already a pain for the average user, image if they have to rewrite the author stylesheet completely... (even for me it would be serious nuisance - and I have a 3000 lines long user stylesheet) --- While in theory, I, as a user, should like that method of setting font-size - combined with my minimum font-size is should guarantee readable text, in practice it is a pain: many more sites break (even some where e.g width is set to ems or the like), or quickly become way to wide for my preferred window width. Philippe --- Philippe Wittenbergh http://emps.l-c-n.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] The use of asterisks in forms to indicate required fields
I saw Dan Cederholm's presentation at the @media conference in San Francisco yesterday. I took a look at the markup of a one page web site he created for the purpose of the presentation and noticed that he marked up a 4 star image like this: abbr class=rating title=4 img alt= src=img/icon-4stars.gif/ /abbr What about marking up * used in forms with ABBR elements? I mean (using Mike's code from another thread), we'd replace this: pFields marked with * (asterisk) are required./p label for=namespan*/span Name: ?php echo error(); ? input type=text id=name name=name value= / /label With this: pPlease fill fields marked with * (required field)./p label for=nameabbr title=required field*/abbr Name: ?php echo error(); ? input type=text id=name name=name value= / /label label for=emailabbr*/abbr Email: ?php echo error(); ? input type=text id=email name=email value= / /label Would that make sense? --- 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
On 26 May 2007, at 05:05:33, Thierry Koblentz wrote: What about marking up * used in forms with ABBR elements? pPlease fill fields marked with * (required field)./p label for=nameabbr title=required field*/abbr Name: ? php echo error(); ? input type=text id=name name=name value= / /label label for=emailabbr*/abbr Email: ?php echo error(); ? input type=text id=email name=email value= / /label It makes sense to me, assuming that the second abbr (the one for the email field) is missing a title attribute, and ought to be the same as the first one. (transposed from original position:) I saw Dan Cederholm's presentation at the @media conference in San Francisco yesterday. Have you asked Dan about it? He doesn't bite, as far as I've seen :-) 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] The use of asterisks in forms to indicate required fields
On Behalf Of Nick Fitzsimons pPlease fill fields marked with * (required field)./p label for=nameabbr title=required field*/abbr Name: ? php echo error(); ? input type=text id=name name=name value= / /label label for=emailabbr*/abbr Email: ?php echo error(); ? input type=text id=email name=email value= / /label It makes sense to me, assuming that the second abbr (the one for the email field) is missing a title attribute, and ought to be the same as the first one. Yes, the second title attribute is missing because of a post of yours in the thread Acronym tag usage :) (transposed from original position:) I saw Dan Cederholm's presentation at the @media conference in San Francisco yesterday. Have you asked Dan about it? He doesn't bite, as far as I've seen :-) No, and I regret now... --- Regards, Thierry | www.TJKDesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
