Re: [WSG] Accessibility of Nav Links using Title Tag??
Because the title attribute is part of Standards, screenreaders have been designed with a knowledge it, it's what they expect and it's what they use. So, no there is no better way. -- Stuart Foulstone. http://www.bigeasyweb.co.uk BigEasy Web Design 69 Flockton Court Rockingham Street Sheffield S1 4EB Tel. 07751 413451 On Fri, August 3, 2007 8:30 am, Cole Kuryakin wrote: Hello All - While I know that one should use improve accessibility of form eloements, it is also a common (best practice) to use a title attribute inside a link anchor like this: a href=home.htm title=Navigate Back to the Home Pagehome/a If there's a better way, or if I'm completely incorrect regarding making my links more accessible, I'd greatly appreciate guidance. Cole *** 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] Accessibility of Nav Links using Title Tag??
Hello All - While I know that one should use improve accessibility of form eloements, it is also a common (best practice) to use a title attribute inside a link anchor like this: a href=home.htm title=Navigate Back to the Home Pagehome/a If there's a better way, or if I'm completely incorrect regarding making my links more accessible, I'd greatly appreciate guidance. Cole *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessibility of Nav Links using Title Tag??
Quoting Cole Kuryakin [EMAIL PROTECTED]: Hello All - While I know that one should use improve accessibility of form eloements, it is also a common (best practice) to use a title attribute inside a link anchor like this: a href=home.htm title=Navigate Back to the Home Pagehome/a If there's a better way, or if I'm completely incorrect regarding making my links more accessible, I'd greatly appreciate guidance. Navigate is useless, on par with having a title start with Link to It's a link, it's used for navigation, and your title doesn't need to explain that again. Users will know by now that activating the link will navigate them somewhere. Back is irrelevant because it assumes that they always came *from* the homepage. What if they hit the page directly from a search engine result or deep link? Lastly, Home Page is unnecessary as well, in my opinion, as the actual link text home is, I'd argue, pretty much unequivocal for anybody who's used the web. Also, more generally: if you really must have a title attribute to explain a link (it's always better to actually have the link text in the clear be understandable even without the need for title, especially since title isn't exposed to sighted keyboard users - i.e. don't rely on it), I'd suggest front-loading it, so the important and distinguishing bit of information is at the front. This way, users that may need that info don't have to listen to the generic bit of text first before getting to the part that actually explains what the link is (in the above example, imagine having 10 links and having to listen to Navigate Back to 10 times when all you want to do is just know which link goes where). P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Accessibility of Nav Links using Title Tag??
Quoting Stuart Foulstone [EMAIL PROTECTED]: Because the title attribute is part of Standards, screenreaders have been designed with a knowledge it, it's what they expect and it's what they use. Depending on user settings. Many screenreaders don't actually read title by default. So, no there is no better way. Making the actual link text clear whenever possible, not having to rely on explanatory text, is the best way. P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
Tee G. Peng wrote: I got an impression that setting 100.1% fontsize in body tag is a better approach and have been doing so for many sites. Also, with the 100.1% in the body, I usually declare .85em (.95 for my site as I love big fontsize :) ) for paragraph and lists. I also find that I get a more stable, closer fontsize across browsers. I have the same experience, but I usually only set 100% - not 100.1% - as starting-point, since the old problems that '.1' was supposed to solve isn't there anymore. Besides, the only reason to set that percentage as a starting-point at all, is to avoid IE's 'em sizing bug'... http://www.gunlaug.no/contents/wd_additions_13.html ...which also affects font-size keywords btw. ... I aware that Opera often makes the size a bit bigger but this is a bit unusual for me. If I change the 62.5 to 100.1, nothing gets change for the Tab nav in Opera, it still shows 3/4px bigger than other browsers but the second level link text shrinks to like 4 or 5 pixel in IE, thus making it impossible to read. I'm not aware of the latest Opera-versions having a _general_ problem causing bigger font sizes. Haven't seen any such problems since around version Op 7.20. In today's version such deviations are usually caused by inheritance through too many up and down sized wrappers, where Opera, or some other browser, may (seem to) lose steps. Sometimes that's caused by a a setting in a browser that is overlooked, and sometimes it's caused by different tip-over values in browsers. I may of course also have overlooked a genuine Opera-bug. Client sent me this link, kind of suggesting that 62.5% is the better approach because his client isn't happy that now the heading texts are too small and the paragraph texts are too big due to the changes I made. http://www.clagnut.com/blog/348/ What do you think? The suggested 62.5% as starting-point is too vulnerable, IMO. For the time being at least, the 'minimum font size' may create problems when extremely small font-sizes are used as starting-points... http://www.gunlaug.no/contents/wd_1_03_04.html Add the effect of different, and growing, screen-resolutions - and how browsers handle screen-resolutions differently - into the equation, and small font-sizes as starting-points may create even more problems. The readable size of different font-families shouldn't be forgotten either, since readability _is_ the most important point, IMO. Generally: if a document/design can take the stress from font-resizing options in browsers reasonably well - not break too early and allow the text to be easy to read without blowing up in the visitor's face, then it doesn't really matter what method you choose. I never argue against what browsers and screen-resolutions can do to my designs when it comes to font-size, I just try to make it work well no matter what. Usually that means my font-sizing starts at 100% and doesn't deviate too much from 100%, whereafter I leave to each visitor to decide what that 100% is. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
On Fri, August 3, 2007 11:36 am, Rick Lecoat wrote: At 10:13 (London time), on 3/8/07, [EMAIL PROTECTED] said: Client sent me this link, kind of suggesting that 62.5% is the better approach because his client isn't happy that now the heading texts are too small and the paragraph texts are too big due to the changes I made. http://www.clagnut.com/blog/348/ One thing I would point out about clagnut's method (which I've been using recently, actually, but I'm looking for a better option) is that the 62.5% sizing (applied to Body) is only meant to provide a handy '1em = 10 pixels' baseline to make your subsequent, em-based, resizing calculations easier. It is NOT intended to be the size that text is set at, because 10 pixels is way too small for most people to read easily unless they are teenagers with 20/20 vision. Note also that it doesn't actually work, as I've previously mentioned on the list: http://www.archivist.incutio.com/viewlist/css-discuss/74993 IE ignores fractional components of percentages - or, as another way of looking at it, only uses the first two decimal places of em based sizes - which means that any subsequent use of ems for sizing parts of the page won't work properly. (The demo I link to in the above post is still there, if anybody wants to look.) Also, Opera has a default font size of, I think, 12px, and treats attempts to go below that and then scale back up slightly differently than IE or Firefox in the same situation. I can't quite remember all the ins and outs of that one, but could try to dig out the work I did on it the other year if anybody's interested. Regards, 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] Looking for a Stylesheet Switcher Script
Ya, it's colliding with another script i have but i'll figure it out. Thanks Again. On 8/3/07, Robert O'Rourke [EMAIL PROTECTED] wrote: Ryan Moore wrote: page cannot be displayed...??? On 8/2/07, *Robert O'Rourke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: http://webrocket.ulmb.com/ability/ http://webrocket.ulmb.com/ability/ Strange, works for me... The alistapart article someone sent you looks like a good solution. Same thing I guess but it won't conflict with scriptaculous (I assume because the article is from 2001). Rob *** 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] setting fontsize in body
At 12:41 (London time), on 3/8/07, [EMAIL PROTECTED] said: Note also that it doesn't actually work .../ snip / IE ignores fractional components of percentages - or, as another way of looking at it, only uses the first two decimal places of em based sizes - which means that any subsequent use of ems for sizing parts of the page won't work properly. Very interesting Nick, I wasn't aware of the decimal place limitation in IE. Another negative point racked up against the Clagnut ems method, which is a shame because I liked the simple and elegant idea behind it. Looks like I'm still on the hunt for the definitive font-sizing technique then. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
At 10:13 (London time), on 3/8/07, [EMAIL PROTECTED] said: I got an impression that setting 100.1% fontsize in body tag is a better approach and have been doing so for many sites. Also, with the 100.1% in the body, I usually declare .85em (.95 for my site as I love big fontsize :) ) for paragraph and lists. I also find that I get a more stable, closer fontsize across browsers. Working on a project, client has the fontsize declared at 62.5%, and the paragraph, nav list at 1em. It works ok for most part, my responsible is to clean up all messy code and restructure the layout structure. I had the fontsize changed to 100.1% which affected many elements, so I changed it to 70% and adjust fontsizes in other elements accordingly, but suggested client to go with 100.1% so that I can rework the font size in every elements. The tab nav that is at 1em, break to second line in Opera, and the fontsize appears to be 3 or 4px bigger than other browsers (however the 1em in p more or less the same. I aware that Opera often makes the size a bit bigger but this is a bit unusual for me. If I change the 62.5 to 100.1, nothing gets change for the Tab nav in Opera, it still shows 3/4px bigger than other browsers but the second level link text shrinks to like 4 or 5 pixel in IE, thus making it impossible to read. Client sent me this link, kind of suggesting that 62.5% is the better approach because his client isn't happy that now the heading texts are too small and the paragraph texts are too big due to the changes I made. http://www.clagnut.com/blog/348/ The 'best' way to size text is something that I've been looking into a bit recently, and the only thing I'm *really* sure of is that whatever route you take you'll find people who will declare, in no uncertain terms, that you're wrong. Actually, scratch that: one thing /is/ agreed upon and that is that sizing text in pixels is Bad because of the IE non- resizability factor, but there doesn't appear to be any real consensus about the 'best' alternative (just have a read through the comments at the end of the clagnut article!). One thing I would point out about clagnut's method (which I've been using recently, actually, but I'm looking for a better option) is that the 62.5% sizing (applied to Body) is only meant to provide a handy '1em = 10 pixels' baseline to make your subsequent, em-based, resizing calculations easier. It is NOT intended to be the size that text is set at, because 10 pixels is way too small for most people to read easily unless they are teenagers with 20/20 vision. Clagnut's method has some downsides, too, the biggest perhaps being that it makes an assumption about the user's default font size as set in their browser and, as we all know, making assumptions about user settings is a dangerous road to tread when it comes to web design. Also, I understand (although I've not come across it myself) that IE can badly mis-display text that is set in ems BELOW the 1em threshhold -- I might have that slightly mixed up, so somebody should probably clarify/ correct me on that point. But if you've used the 62.5% resize command then all your subsequent text sizing should be larger than 1 em anyway, for the reason stated above. Not sure if this helps, but hey. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] setting fontsize in body
Hi, I got an impression that setting 100.1% fontsize in body tag is a better approach and have been doing so for many sites. Also, with the 100.1% in the body, I usually declare .85em (.95 for my site as I love big fontsize :) ) for paragraph and lists. I also find that I get a more stable, closer fontsize across browsers. Working on a project, client has the fontsize declared at 62.5%, and the paragraph, nav list at 1em. It works ok for most part, my responsible is to clean up all messy code and restructure the layout structure. I had the fontsize changed to 100.1% which affected many elements, so I changed it to 70% and adjust fontsizes in other elements accordingly, but suggested client to go with 100.1% so that I can rework the font size in every elements. The tab nav that is at 1em, break to second line in Opera, and the fontsize appears to be 3 or 4px bigger than other browsers (however the 1em in p more or less the same. I aware that Opera often makes the size a bit bigger but this is a bit unusual for me. If I change the 62.5 to 100.1, nothing gets change for the Tab nav in Opera, it still shows 3/4px bigger than other browsers but the second level link text shrinks to like 4 or 5 pixel in IE, thus making it impossible to read. Client sent me this link, kind of suggesting that 62.5% is the better approach because his client isn't happy that now the heading texts are too small and the paragraph texts are too big due to the changes I made. http://www.clagnut.com/blog/348/ What do you think? Sorry I can't post the url for you to take a closer look. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Looking for a Stylesheet Switcher Script
Ryan Moore wrote: page cannot be displayed...??? On 8/2/07, *Robert O'Rourke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: http://webrocket.ulmb.com/ability/ http://webrocket.ulmb.com/ability/ Strange, works for me... The alistapart article someone sent you looks like a good solution. Same thing I guess but it won't conflict with scriptaculous (I assume because the article is from 2001). Rob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Julie Watkins-Lyall is away from the office.
I will be out of the office starting 03/08/2007 and will not return until 08/08/2007. I am attending a conference and will respond to your message when I return. If you require an urgent response, please leave a message on my mobile 0422917755. ** IMPORTANT: This e-mail is intended for the use of the addressee and may contain information that is confidential, commercially valuable or subject to legal or parliamentary privilege. If you are not the intended recipient you are notified that any review, re-transmission, disclosure, use or dissemination of this communication is strictly prohibited by several Commonwealth Acts of Parliament. If you have received this communication in error please notify the sender immediately and delete all copies of this transmission together with any attachments. ** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
On 3 Aug 2007, at 16:08:55, Rick Lecoat wrote:
At 12:41 (London time), on 3/8/07, [EMAIL PROTECTED] said:
Note also that it doesn't actually work
.../ snip /
IE ignores fractional components of percentages - or, as another
way of
looking at it, only uses the first two decimal places of em based
sizes -
which means that any subsequent use of ems for sizing parts of the
page
won't work properly.
Very interesting Nick, I wasn't aware of the decimal place
limitation in
IE. Another negative point racked up against the Clagnut ems method,
which is a shame because I liked the simple and elegant idea behind
it.
Looks like I'm still on the hunt for the definitive font-sizing
technique then.
When dealing with this the other year, I came up with this solution
requiring an additional div, which happened to be there anyway:
body {
font-size: 125%; /* bump it up to 20px, assuming browser starts
at 16px */
}
div#wrapper {
font-size: 50%; /* and back down to 10px */
}
and took it from there :-)
(Still falls foul of a minimum font-size set in the browser
preferences, though.)
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] setting fontsize in body
Nick Fitzsimons wrote:
On 3 Aug 2007, at 16:08:55, Rick Lecoat wrote:
When dealing with this the other year, I came up with this solution
requiring an additional div, which happened to be there anyway:
body {
font-size: 125%; /* bump it up to 20px, assuming browser starts at
16px */
}
div#wrapper {
font-size: 50%; /* and back down to 10px */
}
You could also save yourself the wrapper by doing the first declaration
on the html element, and the second on the body
html { font-size: 125%; }
body { font-size: 50%; }
(Still falls foul of a minimum font-size set in the browser preferences,
though.)
I wouldn't say it falls foul. If a user has set a minimum size, then a
page should heed that. It still *respects* minimum font-size settings.
P
--
Patrick H. Lauke
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
__
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
__
Take it to the streets ... join the WaSP Street Team
http://streetteam.webstandards.org/
__
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] setting fontsize in body
On 2007/08/03 21:14 (GMT+0100) Patrick H. Lauke apparently typed:
Nick Fitzsimons wrote:
On 3 Aug 2007, at 16:08:55, Rick Lecoat wrote:
When dealing with this the other year, I came up with this solution
requiring an additional div, which happened to be there anyway:
body {
font-size: 125%; /* bump it up to 20px, assuming browser starts at
16px */
}
div#wrapper {
font-size: 50%; /* and back down to 10px */
}
You could also save yourself the wrapper by doing the first declaration
on the html element, and the second on the body
html { font-size: 125%; }
body { font-size: 50%; }
(Still falls foul of a minimum font-size set in the browser preferences,
though.)
I wouldn't say it falls foul. If a user has set a minimum size, then a
page should heed that. It still *respects* minimum font-size settings.
http://mrmazda.no-ip.com/SS/Clagnut/eonsSS.html demonstrates the meaning of
falls foul in such cases.
The same also applies when a user has applied a rudimentary user stylesheet
(containing only 'body {font-size: medium !important}' or equivalent). A
slightly more elaborate one adding e.g. td, dd, p, div, li, pre, code,
textarea to body generally falls foul also, as so many authors apply their
CSS to classes and ids instead of simply elements.
--
It is impossible to rightly govern the world without
God and the Bible.George Washington
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] setting fontsize in body
At 20:14 (London time), on 3/8/07, [EMAIL PROTECTED] said: (Still falls foul of a minimum font-size set in the browser preferences, though.) I wouldn't say it falls foul. If a user has set a minimum size, then a page should heed that. It still *respects* minimum font-size settings. Well, the problem as far as I can see it, is the assumption that the user has a default font size of 16. Using the clagnut method (or Nick's reverse 125%/50% method), I would be specifying 1.2ems in order to get text 12px high that IE can resize. But if the user has changed his default size to 12 because, not unreasonably, he or she felt that 12 was a comfortable reading size, then my 1.2 em type will be displayed at 9px, not 12, which is not very readable at all. So, in calculating your 'readable' text size as a proportion of the (admittedly overlarge) default size, you make yourself vulnerable should the user have already made their own compensation for the overly large default size. The more I look at the clagnut solution, the more I come to the conclusion that relying on the user having their browser's default text size unchanged is simply building a house on sand. Sooner or later it's coming down around your ears. -- Rick Lecoat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
On 2007/08/03 16:16 (GMT-0400) Rick Lecoat apparently typed: So, in calculating your 'readable' text size as a proportion of the (admittedly overlarge) default size, you make yourself vulnerable should the user have already made their own compensation for the overly large default size. The time when is was reasonable to assume the default was either 16px or admittedly overlarge is long since past. While the former still might in fact be the case the majority of the time, in the face of growing screen resolutions and DPI the minority of the time is large and rapidly growing, with many instances the DPI high enough that the PC supplier (for laptops usually, and indirectly) changes the default to 20px (actually still 12pt, the real default in most cases) by changing the system DPI from the normal 96 to a necessarily larger 120. The only way to know a size is too large is if you are looking at it. You know neither how many px your visitors have available (without JS), nor how big each is (with or without JS). You don't have your users' eyes, nor their seating distance, nor their hardware, nor their lighting conditions, nor their personal software settings, except by small chance. Something you probably do have is no less than average eyesight, which biases you into thinking smaller is OK. So, there's just no way you can know too large or too small or anything in between for any typical site's users. The only reasonable current assumption is that the users' defaults are exactly as they want and/or need them to be. Assuming otherwise with anything other than medium, 1em or 100% in body flowing through to main content unaltered could somehow be any improvement is thus an inexcusably rude imposition. http://mrmazda.no-ip.com/auth/bigdefaults.html The more I look at the clagnut solution, the more I come to the conclusion that relying on the user having their browser's default text size unchanged is simply building a house on sand. Sooner or later it's coming down around your ears. Absolutely. -- It is impossible to rightly govern the world without God and the Bible.George Washington 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] setting fontsize in body
Hi Thanks for all the insightful feedback.
I have a very limited freedom on this particular project. A previous
version was done quite messy and it seemed time were waste quite a
lot, so I was brought in to fix, clean up the code, but the end-
client wanted the fontsize stays the same. The problem I am facing
now, is that in Opera Mac version, fontsize in every element is 2
pixel bigger than other browsers, the PC version stays consistent.
Here are the basic codes for font size adopted from the previous
version and I am not allowed to touch it.
body {font-size: 62.5%}
#nav li {font-size: 1em} /*10px */
p {font-size: 1em} /*10px */
h2 {font-size: 1.2em} /*12px */
h3 {font-size: 1.1em}
no specific declaration is made for IE, but there is no issue there
as far as consistency concerned. Mac version Opera makes everything 2
pixel larger. It looks fine and acceptable for the content area
(nobody seems to care how this browser render the fontsize as long as
the layout looks the same and thing doesn't fall apart) but because
the navigation tab is a bit crowded, thus making the last tab drops
to next line. And this is the problem I need to fix, I suggested a
change to 100.1% in the body and adjust other element accordingly
because from my experience, I know I can get a better result for Mac
version Opera. No, can't do it because I can't touch the fontsize if
it affects the size in other elements.
What I don't understand is, why the Mac version Opera behaves so
erratic. My guess is the 62.5% causing the problem.
tee
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] setting fontsize in body
Felix Miata wrote: (Still falls foul of a minimum font-size set in the browser preferences, though.) I wouldn't say it falls foul. If a user has set a minimum size, then a page should heed that. It still *respects* minimum font-size settings. http://mrmazda.no-ip.com/SS/Clagnut/eonsSS.html demonstrates the meaning of falls foul in such cases. Ah, a misunderstanding of terminology. I thought minimum font-size settings referred to things like Firefox's preference setting for disallowing fonts, even when resized by the user, to fall below a certain fixed size...while in this case y'all seem to mean the default font size. P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Footer taking width from form
Good morning http://www.colouru.com.au/contactus.html On this particular page in IE only, the #footer seems to be taking its width from the form. I have cleared everything I can think of but cannot find the problem. Thanks Lyn www.westernwebdesign.com.au *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] setting fontsize in body
Patrick H. Lauke wrote:
Ah, a misunderstanding of terminology. I thought minimum font-size
settings referred to things like Firefox's preference setting for
disallowing fonts, even when resized by the user, to fall below a
certain fixed size...while in this case y'all seem to mean the default
font size.
We better clear up the terminology then.
- 'minimum font size' is the user-option most browsers except IE have,
as you describe. It works differently in those browsers that have this
option, and the preset value varies.
- 'default font size' is most often referred to as the medium,
normal or 100% font size, which can also be changed by the user in
most browsers. Most browsers today also change their preset default(s)
based on screen-DPI - one way or another.
The combination of altered 'minimum font size' and 'default font size'
can create some interesting results for some unprepared pages with
unnecessary complex font-sizing.
Back to Tee's problem with 'body {font-size: 62.5%}' etc in Opera/Mac.
It may be caused by the preset value for 'minimum font size' in that
browser/OS.
If someone can check the preset value for 'minimum font size' in an
unaltered Opera/Mac, as I set mine to '14px' years ago and have since
just updated it, and I can't remember the preset value. Now I can't even
check Tee's problem, because my Mac is off-line.
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] setting fontsize in body
On Aug 4, 2007, at 10:45 AM, Gunlaug Sørtun wrote:
Back to Tee's problem with 'body {font-size: 62.5%}' etc in Opera/
Mac. It may be caused by the preset value for 'minimum font size'
in that browser/OS.
If someone can check the preset value for 'minimum font size' in an
unaltered Opera/Mac, as I set mine to '14px' years ago and have
since just updated it, and I can't remember the preset value. Now I
can't even check Tee's problem, because my Mac is off-line.
Unless my copy is sick, the default is 9px.
I did notice sometimes that Opera Mac (and maybe Win) tends to round-
up decimal percentage points more aggressively than other browsers on
my Mac(s). That is more often the case in a complex cascade (e.g.
starting at 85.5% font-size, then a descendant has 90.5%, etc). I've
seen Opera round the numbers upwards more often (that is not more
than 1px per step, but can add up for deeply nested elements)
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]
***
Re: [WSG] Footer taking width from form
Lyn Patterson wrote: Good morning http://www.colouru.com.au/contactus.html On this particular page in IE only, the #footer seems to be taking its width from the form. I have cleared everything I can think of but cannot find the problem. Hi Lyn You have a typo in your clearfooter div: xdiv id=clearfooter/div See if fixing that helps. Regards -- Scott Swabey Design Development Director - Lafinboy Productions www.lafinboy.com | www.thought-after.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Please help! CSS/IE Link Color Problem
Hello All -
After tearing my hair out for over 4 hours I come to you guys/gals for a
fresh eye and perhaps a solution.
I've got a simple class name (.active) attached to an a tag. This class is
programmatically activated when a link is chosen and the page loads.
When the chosen page loads, the chosen link turns deep red.
The declaration for this is as follows:
/*ACTIVE LINKS ONLY*/
ul#navTopSimpleUL li a.active
{
color: #CC0033;
cursor: default;
text-decoration: none;
}
A similar declaration is in force for the side AND footer navigation.
In FF it works as required/expected. But, even though the HTML and CSS
validates, this small but important functionality doesn't work in IE 6.
If you look at the testing site in FF (www.koisis.com/.problems/index.php)
this works as required and expected.
If you then view the same page in IE 6 however, the .active class doesn't
work at all - I haven't begun to test in IE7 yet and I can't figure out a
work-around for IE 6..
If you'd like to view the css that controls the navigation rules, it's named
c.project_navigation.css.
Can someone(s) please take a look at this for me and tell me where I'm going
wrong, or what alteration(s) I can make to trigger this class in IE?
Great appreciation and thanks to all in advance!
Cole
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***attachment: winmail.dat
Re: [WSG] Footer taking width from form
Scott Swabey wrote: Lyn Patterson wrote: http://www.colouru.com.au/contactus.html On this particular page in IE only, the #footer seems to be taking its width from the form. I have cleared everything I can think of but cannot find the problem. You have a typo in your clearfooter div: xdiv id=clearfooter/div Hi Scott Thanks - not exactly a typo - I use that method if I want to temporarily take something out of the CSS and might want to put it back later. Anyway, I solved the main problem by removing the footer from #container so now it just sits under all the content. IE7 is happy with that. However IE6 is still misbehaving. I tried a * hack but it still is not showing the footer correctly. Lyn *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Please help! CSS/IE Link Color Problem
FWIW seems to work in IE7 - dont have IE6 setup at the moment.
On 8/4/07, Cole Kuryakin [EMAIL PROTECTED] wrote:
Hello All -
After tearing my hair out for over 4 hours I come to you guys/gals for a
fresh eye and perhaps a solution.
I've got a simple class name (.active) attached to an a tag. This class
is
programmatically activated when a link is chosen and the page loads.
When the chosen page loads, the chosen link turns deep red.
The declaration for this is as follows:
/*ACTIVE LINKS ONLY*/
ul#navTopSimpleUL li a.active
{
color: #CC0033;
cursor: default;
text-decoration: none;
}
A similar declaration is in force for the side AND footer navigation.
In FF it works as required/expected. But, even though the HTML and CSS
validates, this small but important functionality doesn't work in IE 6.
If you look at the testing site in FF (www.koisis.com/.problems/index.php)
this works as required and expected.
If you then view the same page in IE 6 however, the .active class doesn't
work at all - I haven't begun to test in IE7 yet and I can't figure out a
work-around for IE 6..
If you'd like to view the css that controls the navigation rules, it's
named
c.project_navigation.css.
Can someone(s) please take a look at this for me and tell me where I'm
going
wrong, or what alteration(s) I can make to trigger this class in IE?
Great appreciation and thanks to all in advance!
Cole
***
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] Please help! CSS/IE Link Color Problem
you could try adding !IMPORTANT after the colour declaration just to see if
it is an inheritance issue
On 8/4/07, James Gollan [EMAIL PROTECTED] wrote:
FWIW seems to work in IE7 - dont have IE6 setup at the moment.
On 8/4/07, Cole Kuryakin [EMAIL PROTECTED] wrote:
Hello All -
After tearing my hair out for over 4 hours I come to you guys/gals for a
fresh eye and perhaps a solution.
I've got a simple class name (.active) attached to an a tag. This
class is
programmatically activated when a link is chosen and the page loads.
When the chosen page loads, the chosen link turns deep red.
The declaration for this is as follows:
/*ACTIVE LINKS ONLY*/
ul#navTopSimpleUL li a.active
{
color: #CC0033;
cursor: default;
text-decoration: none;
}
A similar declaration is in force for the side AND footer navigation.
In FF it works as required/expected. But, even though the HTML and CSS
validates, this small but important functionality doesn't work in IE 6.
If you look at the testing site in FF (www.koisis.com/.problems/index.php
)
this works as required and expected.
If you then view the same page in IE 6 however, the .active class
doesn't
work at all - I haven't begun to test in IE7 yet and I can't figure out
a
work-around for IE 6..
If you'd like to view the css that controls the navigation rules, it's
named
c.project_navigation.css.
Can someone(s) please take a look at this for me and tell me where I'm
going
wrong, or what alteration(s) I can make to trigger this class in IE?
Great appreciation and thanks to all in advance!
Cole
***
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] Footer taking width from form
Good morning http://www.colouru.com.au/contactus.html On this particular page in IE only, the #footer seems to be taking its width from the form. I have cleared everything I can think of but cannot find the problem. Hi Lyn You have a typo in your clearfooter div: xdiv id=clearfooter/div See if fixing that helps. -- Hi, Another thing I find odd is that you are using an empty tag for your form instead of wrapping the form fields with a start and end tag. Instead of: form method=post action=/cgi-bin/formmail/FormMail.pl / Maybe try: form method=post action=/cgi-bin/formmail/FormMail.pl fieldset ... /fieldset /form Please note I left the DOCTYPE and other W3C standard structural elements out of my description for brevity. Regards, Kepler *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Please help! CSS/IE Link Color Problem
When the chosen page loads, the chosen link turns deep red.
The declaration for this is as follows:
/*ACTIVE LINKS ONLY*/
ul#navTopSimpleUL li a.active
{
color: #CC0033;
cursor: default;
text-decoration: none;
}
Hi Cole,,
You may want to also set focus on the element and declare a
ul#navTopSimpleUL li a.focus definition mimicking the active definition. I
believe I read somewhere that IE6 treats active and focus states the same,
or confuses them.
Regards,
Kepler
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***attachment: winmail.dat
Re: [WSG] Footer taking width from form
http://www.colouru.com.au/contactus.html On this particular page in IE only, the #footer seems to be taking its width from the form. I have cleared everything I can think of but cannot find the problem. Another thing I find odd is that you are using an empty tag for your form instead of wrapping the form fields with a start and end tag. Instead of: form method=post action=/cgi-bin/formmail/FormMail.pl / Maybe try: form method=post action=/cgi-bin/formmail/FormMail.pl fieldset ... /fieldset /form Well, that is amazing! It fixed the problem in IE6. This is the first site with this hosting company and that is how they gave me the example for the Form. I used to do it form .../form but changed it on this site. Thank you, Keppler Lyn *** 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] Please help! CSS/IE Link Color Problem
the given rule is not using a pseudo selector (:) - it is a simple class
definition. This should be consistent across browsers.
On 8/4/07, Kepler Gelotte [EMAIL PROTECTED] wrote:
When the chosen page loads, the chosen link turns deep red.
The declaration for this is as follows:
/*ACTIVE LINKS ONLY*/
ul#navTopSimpleUL li a.active
{
color: #CC0033;
cursor: default;
text-decoration: none;
}
Hi Cole,,
You may want to also set focus on the element and declare a
ul#navTopSimpleUL li a.focus definition mimicking the active definition.
I
believe I read somewhere that IE6 treats active and focus states the same,
or confuses them.
Regards,
Kepler
***
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] CSS/IE Link Color Problem - SOLVED
James and Kepler - Thank you both for your input; I tried suffixing the color and text declaration with !important and that solves the problem. So this, I guess, is an issue of IE's built-in proprietary styles over-riding user styles??? I've never run into that one before. Irritating. Aside from the !important solution or the (as yet untried) focus solution that Kepler suggested, does anyone else have an even more elegant option or ... for my issue ... is this (these) the only ones that'll work? What is WEIRD, is that this framework that I'm devising also has an option for a CSS drop-down menuing system. When I've tested that in IE6, the .active class WORKS on both trigger and menu links. It's issues like these that makes me wonder why I hadn't become a gardener. James and Kepler, thanks again! Cole *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***attachment: winmail.dat
Re: [WSG] setting fontsize in body
On Aug 3, 2007, at 8:19 PM, Philippe Wittenbergh wrote:
On Aug 4, 2007, at 10:45 AM, Gunlaug Sørtun wrote:
Back to Tee's problem with 'body {font-size: 62.5%}' etc in Opera/
Mac. It may be caused by the preset value for 'minimum font size'
in that browser/OS.
If someone can check the preset value for 'minimum font size' in
an unaltered Opera/Mac, as I set mine to '14px' years ago and have
since just updated it, and I can't remember the preset value. Now
I can't even check Tee's problem, because my Mac is off-line.
Unless my copy is sick, the default is 9px
Mine is 12px. I don't remember I ever altered the fontsize in Opera
(9.22), as I only use this browser for testing.
Monitor Screen resolution: 1680 x 1050.
Just got an email from client, his client doesn't care the Opera, if
it can be fix with a 'conditional comment' like we treat the IE than
it's great, go ahead and do it, if not, ignore. Which is very
unfortunately and I must admit I get discourage by this type of
attitude. It would be nice if every client can have the same attitude
toward IE :)
tee
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
