Re: [WSG] Re: px em pt ???

2003-12-09 Thread russ weakley 
http://westciv.com/style_master/academy/browser_support/selectors.html
Try this - keep in mind you can hide content from NN4 if needed using
@import

Russ


> 
> Any links to information about descendant selectors and backwards
> compatibility?  In particular Netscape 4...
> 
> -Original Message-
> From: russ weakley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2003 3:41 PM
> To: Web Standards Group
> Subject: Re: [WSG] Re: px em pt ???
> 
> 
> Taco,
> 
> If you code well, relative font sizes do not require a great deal to apply
> across a site. You are simply making decisions on font-sizes as you develop
> each section of the page - exactly as you would for pixels. There is really
> very little excuse not to use one of the methods below.
> 
> Method 1 - environmental coding:
> If you are building a full CSS site the first thing to do is to break your
> page into divs and then styling each div using descendant selectors where
> possible - this means there is little class and id clutter on the page. This
> also means you can set relative font sizes for any element at any level of
> the page - without running into inheritance problems. Mark Newhouse calls
> this "environmental coding" - coding each div or "environment" as a unit.
> 
> An example would be:
> #navigation {}
> #navigation h1 {}
> #navigation p {}
> #navigation ul {}
> #navigation a {}
> #navigation li a {}
> 
> As you can see, they are all designed to target very specific instances of
> type elements within one "environment".
> 
> Method 2. the body
> Another way (which can be used in conjunction with the first method) is to
> simply set the relative size on the body and use that as a base - keeping in
> mind that certain browsers need minor adjustments (may not inherit inside
> tables etc). As long as you are aware of the few  small bugs, this is a safe
> option and runs into very little inheritance issues.
> 
> Method 3 - type selectors
> Peter and I used to use this method a lot, but have moved on to the first
> two methods. If you set relative font sizing on actual HTML elements you can
> run into inheritance problems discussed in previous email and may need a few
> small work-arounds (or hacks).
> 
> Method 4 - leave it up to the user!
> There are many developers who believe that we should not be touching font
> sizes at all - by reducing any font size we are taking the control away from
> the user. 
> 
> No excuses any more!
> : )
> Russ
> 
> 
>> 
>> Makes sense too..
>> 
>> I guess in the end it all becomes a case of - is the client willing to pay
>> for
>> your extra time required to apply all these hacks.
>> 
>> Having worked for several government bodies I am afraid to say I have NEVER
>> worked with %, simply because it looked like a paint to work with. And the
>> only downfall I see in using pixels is due to the fact IE (some versions)
>> can't scale it.
>> (the only sites I developed for the gorvernment were Intranet, so don't come
>> down to hard on me ;-)
>> 
>> I'll give it a go though at some stage.
>> 
>> -Original Message-
>> From: russ weakley [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, 10 December 2003 2:19 PM
>> To: Web Standards Group
>> Subject: Re: [WSG] Re: px em pt ???
>> 
>> 
>> Sorry for the length of this...
>> 
>> 1. All government sites are supposed to follow WAI guideline - which
>> recommend the use of relative font sizes.
>> 
>> 2. The aim is to give users the option. Saying that users can change their
>> screen resolution is throwing the responsibility back onto them - it is our
>> job to make it as easy as possible for all users to see our content.
>> 
>> 3. There are many different users out there with a wide variety of vision
>> impairments from mildly reduced eyesight to totally blind. Each of these
>> groups has specific needs and we have to keep them all in mind.
>> 
>> We have done extensive testing with a wide range of these groups. I really
>> recommend all web designers and developers sit with both blind and near
>> blind users and watch them use your sites. It changes your perspective on
>> accessiblity.
>> 
>>

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] Re: px em pt ???

2003-12-09 Thread Miles Tillinger 

Any links to information about descendant selectors and backwards compatibility?  In 
particular Netscape 4...

-Original Message-
From: russ weakley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 3:41 PM
To: Web Standards Group
Subject: Re: [WSG] Re: px em pt ???


Taco,

If you code well, relative font sizes do not require a great deal to apply
across a site. You are simply making decisions on font-sizes as you develop
each section of the page - exactly as you would for pixels. There is really
very little excuse not to use one of the methods below.

Method 1 - environmental coding:
If you are building a full CSS site the first thing to do is to break your
page into divs and then styling each div using descendant selectors where
possible - this means there is little class and id clutter on the page. This
also means you can set relative font sizes for any element at any level of
the page - without running into inheritance problems. Mark Newhouse calls
this "environmental coding" - coding each div or "environment" as a unit.

An example would be:
#navigation {}
#navigation h1 {}
#navigation p {}
#navigation ul {}
#navigation a {}
#navigation li a {}

As you can see, they are all designed to target very specific instances of
type elements within one "environment".

Method 2. the body 
Another way (which can be used in conjunction with the first method) is to
simply set the relative size on the body and use that as a base - keeping in
mind that certain browsers need minor adjustments (may not inherit inside
tables etc). As long as you are aware of the few  small bugs, this is a safe
option and runs into very little inheritance issues.

Method 3 - type selectors
Peter and I used to use this method a lot, but have moved on to the first
two methods. If you set relative font sizing on actual HTML elements you can
run into inheritance problems discussed in previous email and may need a few
small work-arounds (or hacks).

Method 4 - leave it up to the user!
There are many developers who believe that we should not be touching font
sizes at all - by reducing any font size we are taking the control away from
the user. 

No excuses any more!
: )
Russ


> 
> Makes sense too..
> 
> I guess in the end it all becomes a case of - is the client willing to pay for
> your extra time required to apply all these hacks.
> 
> Having worked for several government bodies I am afraid to say I have NEVER
> worked with %, simply because it looked like a paint to work with. And the
> only downfall I see in using pixels is due to the fact IE (some versions)
> can't scale it.
> (the only sites I developed for the gorvernment were Intranet, so don't come
> down to hard on me ;-)
> 
> I'll give it a go though at some stage.
> 
> -Original Message-
> From: russ weakley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 10 December 2003 2:19 PM
> To: Web Standards Group
> Subject: Re: [WSG] Re: px em pt ???
> 
> 
> Sorry for the length of this...
> 
> 1. All government sites are supposed to follow WAI guideline - which
> recommend the use of relative font sizes.
> 
> 2. The aim is to give users the option. Saying that users can change their
> screen resolution is throwing the responsibility back onto them - it is our
> job to make it as easy as possible for all users to see our content.
> 
> 3. There are many different users out there with a wide variety of vision
> impairments from mildly reduced eyesight to totally blind. Each of these
> groups has specific needs and we have to keep them all in mind.
> 
> We have done extensive testing with a wide range of these groups. I really
> recommend all web designers and developers sit with both blind and near
> blind users and watch them use your sites. It changes your perspective on
> accessiblity.
> 
> One quick example to do with pixels: people with severe eye problems (close
> to blind) would probably be using assistive technologies such as Zoom Text-
> software based screen enlargers that can increase parts of the screen up to
> 400-600%. Pixel based fonts become a real issue for these people as there
> are often not enough pixels to render a font properly. I sat with a woman
> testing one of my sites were a footer was set to 12px and saw that the text
> was unreadable for her. Fonts in nearby areas of the page that were
> relatively positioned were able to be read easily.
> 
> 4. Relative font sizing is very easy to manage as long as you understand two
> things:
> 
> 1. The document tree
> 2. inheritance
> 
> Relative font sizes will be inherited by items lower down the tree. EG.
> Nested lists set with 80% will inherit and be reduced to 80% x 80%  = 64%.
> 
> To solve this problem, place your relative font declarations at one level of
> the document tree or pay attention to how they can cascade and affect your
> content. It is easy to reverse the effect with rules like:
> 
> ul ul { font-size: 100%;}
> 
> Russ
> 
> 
> 
>> 
>> thats a good one...
>> It makes sense wha

RE: [WSG] Re: px em pt ???

2003-12-09 Thread Miles Tillinger 

Peter, I know its a bit of a cop-out and less of a 'learning experience', but I'd love 
to get my hands on a generic CSS template that I can use as a starting point...  Has 
anyone been nice enough to make one available anywhere?

-Original Message-
From: Peter Firminger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 3:40 PM
To: [EMAIL PROTECTED]
Subject: RE: [WSG] Re: px em pt ???


Hi Taco,

> I guess in the end it all becomes a case of - is the client
> willing to pay for your extra time required to apply all these hacks.

First thing to note is that it is soo much quicker to develop a site
this way once you get the basics right. Once you have the basics, you start
the next new site with a template based on these basics and you can churn
out sites in half the time you used to.

Secondly, these (relative fonts) are definitely NOT hacks. Using a table to
lay out non-tabular content is a hack. Exploiting a bug in a browser (like
the voice family hack mentioned a few days ago) is a hack (and this one
should be considered dangerous.. At least fully explore the pros and cons
before using it).

> Having worked for several government bodies I am afraid to
> say I have NEVER worked with %, simply because it looked like
> a paint to work with. And the only downfall I see in using
> pixels is due to the fact IE (some versions) can't scale it.
> (the only sites I developed for the gorvernment were
> Intranet, so don't come down to hard on me ;-)

A behaviour in IE is the most important one to worry about as it has a 93%
market share (like it or not, and I'm not saying it's better than any other
browser, it's just reality). I suggest you look at the user_agents hitting
your site(s) at some stage. If you don't have access to analyse your log
files, then a generic breakdown is a good second bet. See lists like:
http://www.thecounter.com/stats/2003/November/browser.php

Also FWIW (a good generic audience) take a look at the AM Online stats
breakdown of browsers and platforms for November 2003
http://www.amonline.net.au/website/reports/amonline/0311/index_08_b.htm

Regards,

Peter


*
The discussion list for http://webstandardsgroup.org/
* 

*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] Re: px em pt ???

2003-12-09 Thread russ weakley 
Taco,

If you code well, relative font sizes do not require a great deal to apply
across a site. You are simply making decisions on font-sizes as you develop
each section of the page - exactly as you would for pixels. There is really
very little excuse not to use one of the methods below.

Method 1 - environmental coding:
If you are building a full CSS site the first thing to do is to break your
page into divs and then styling each div using descendant selectors where
possible - this means there is little class and id clutter on the page. This
also means you can set relative font sizes for any element at any level of
the page - without running into inheritance problems. Mark Newhouse calls
this "environmental coding" - coding each div or "environment" as a unit.

An example would be:
#navigation {}
#navigation h1 {}
#navigation p {}
#navigation ul {}
#navigation a {}
#navigation li a {}

As you can see, they are all designed to target very specific instances of
type elements within one "environment".

Method 2. the body 
Another way (which can be used in conjunction with the first method) is to
simply set the relative size on the body and use that as a base - keeping in
mind that certain browsers need minor adjustments (may not inherit inside
tables etc). As long as you are aware of the few  small bugs, this is a safe
option and runs into very little inheritance issues.

Method 3 - type selectors
Peter and I used to use this method a lot, but have moved on to the first
two methods. If you set relative font sizing on actual HTML elements you can
run into inheritance problems discussed in previous email and may need a few
small work-arounds (or hacks).

Method 4 - leave it up to the user!
There are many developers who believe that we should not be touching font
sizes at all - by reducing any font size we are taking the control away from
the user. 

No excuses any more!
: )
Russ


> 
> Makes sense too..
> 
> I guess in the end it all becomes a case of - is the client willing to pay for
> your extra time required to apply all these hacks.
> 
> Having worked for several government bodies I am afraid to say I have NEVER
> worked with %, simply because it looked like a paint to work with. And the
> only downfall I see in using pixels is due to the fact IE (some versions)
> can't scale it.
> (the only sites I developed for the gorvernment were Intranet, so don't come
> down to hard on me ;-)
> 
> I'll give it a go though at some stage.
> 
> -Original Message-
> From: russ weakley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 10 December 2003 2:19 PM
> To: Web Standards Group
> Subject: Re: [WSG] Re: px em pt ???
> 
> 
> Sorry for the length of this...
> 
> 1. All government sites are supposed to follow WAI guideline - which
> recommend the use of relative font sizes.
> 
> 2. The aim is to give users the option. Saying that users can change their
> screen resolution is throwing the responsibility back onto them - it is our
> job to make it as easy as possible for all users to see our content.
> 
> 3. There are many different users out there with a wide variety of vision
> impairments from mildly reduced eyesight to totally blind. Each of these
> groups has specific needs and we have to keep them all in mind.
> 
> We have done extensive testing with a wide range of these groups. I really
> recommend all web designers and developers sit with both blind and near
> blind users and watch them use your sites. It changes your perspective on
> accessiblity.
> 
> One quick example to do with pixels: people with severe eye problems (close
> to blind) would probably be using assistive technologies such as Zoom Text-
> software based screen enlargers that can increase parts of the screen up to
> 400-600%. Pixel based fonts become a real issue for these people as there
> are often not enough pixels to render a font properly. I sat with a woman
> testing one of my sites were a footer was set to 12px and saw that the text
> was unreadable for her. Fonts in nearby areas of the page that were
> relatively positioned were able to be read easily.
> 
> 4. Relative font sizing is very easy to manage as long as you understand two
> things:
> 
> 1. The document tree
> 2. inheritance
> 
> Relative font sizes will be inherited by items lower down the tree. EG.
> Nested lists set with 80% will inherit and be reduced to 80% x 80%  = 64%.
> 
> To solve this problem, place your relative font declarations at one level of
> the document tree or pay attention to how they can cascade and affect your
> content. It is easy to reverse the effect with rules like:
> 
> ul ul { font-size: 100%;}
> 
> Russ
> 
> 
> 
>> 
>> thats a good one...
>> It makes sense what you are saying, to me anyway.
>> 
>> -Original Message-
>> From: Miles Tillinger [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, 10 December 2003 1:42 PM
>> To: [EMAIL PROTECTED]
>> Subject: RE: [WSG] Re: px em pt ???
>> 
> 
> *
>

RE: [WSG] Re: px em pt ???

2003-12-09 Thread Peter Firminger 
Hi Taco,

> I guess in the end it all becomes a case of - is the client
> willing to pay for your extra time required to apply all these hacks.

First thing to note is that it is soo much quicker to develop a site
this way once you get the basics right. Once you have the basics, you start
the next new site with a template based on these basics and you can churn
out sites in half the time you used to.

Secondly, these (relative fonts) are definitely NOT hacks. Using a table to
lay out non-tabular content is a hack. Exploiting a bug in a browser (like
the voice family hack mentioned a few days ago) is a hack (and this one
should be considered dangerous.. At least fully explore the pros and cons
before using it).

> Having worked for several government bodies I am afraid to
> say I have NEVER worked with %, simply because it looked like
> a paint to work with. And the only downfall I see in using
> pixels is due to the fact IE (some versions) can't scale it.
> (the only sites I developed for the gorvernment were
> Intranet, so don't come down to hard on me ;-)

A behaviour in IE is the most important one to worry about as it has a 93%
market share (like it or not, and I'm not saying it's better than any other
browser, it's just reality). I suggest you look at the user_agents hitting
your site(s) at some stage. If you don't have access to analyse your log
files, then a generic breakdown is a good second bet. See lists like:
http://www.thecounter.com/stats/2003/November/browser.php

Also FWIW (a good generic audience) take a look at the AM Online stats
breakdown of browsers and platforms for November 2003
http://www.amonline.net.au/website/reports/amonline/0311/index_08_b.htm

Regards,

Peter


*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] Re: px em pt ???

2003-12-09 Thread Taco Fleur 

Makes sense too..

I guess in the end it all becomes a case of - is the client willing to pay for your 
extra time required to apply all these hacks.

Having worked for several government bodies I am afraid to say I have NEVER worked 
with %, simply because it looked like a paint to work with. And the only downfall I 
see in using pixels is due to the fact IE (some versions) can't scale it.
(the only sites I developed for the gorvernment were Intranet, so don't come down to 
hard on me ;-)

I'll give it a go though at some stage.

-Original Message-
From: russ weakley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 December 2003 2:19 PM
To: Web Standards Group
Subject: Re: [WSG] Re: px em pt ???


Sorry for the length of this...

1. All government sites are supposed to follow WAI guideline - which
recommend the use of relative font sizes.

2. The aim is to give users the option. Saying that users can change their
screen resolution is throwing the responsibility back onto them - it is our
job to make it as easy as possible for all users to see our content.

3. There are many different users out there with a wide variety of vision
impairments from mildly reduced eyesight to totally blind. Each of these
groups has specific needs and we have to keep them all in mind.

We have done extensive testing with a wide range of these groups. I really
recommend all web designers and developers sit with both blind and near
blind users and watch them use your sites. It changes your perspective on
accessiblity.

One quick example to do with pixels: people with severe eye problems (close
to blind) would probably be using assistive technologies such as Zoom Text-
software based screen enlargers that can increase parts of the screen up to
400-600%. Pixel based fonts become a real issue for these people as there
are often not enough pixels to render a font properly. I sat with a woman
testing one of my sites were a footer was set to 12px and saw that the text
was unreadable for her. Fonts in nearby areas of the page that were
relatively positioned were able to be read easily.

4. Relative font sizing is very easy to manage as long as you understand two
things:

1. The document tree
2. inheritance

Relative font sizes will be inherited by items lower down the tree. EG.
Nested lists set with 80% will inherit and be reduced to 80% x 80%  = 64%.

To solve this problem, place your relative font declarations at one level of
the document tree or pay attention to how they can cascade and affect your
content. It is easy to reverse the effect with rules like:

ul ul { font-size: 100%;}

Russ



> 
> thats a good one...
> It makes sense what you are saying, to me anyway.
> 
> -Original Message-
> From: Miles Tillinger [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 10 December 2003 1:42 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [WSG] Re: px em pt ???
> 

*
The discussion list for http://webstandardsgroup.org/
* 

*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] OT: Opening documents in _blank window

2003-12-09 Thread Gino Ferraro 

Hi All,

I am a new member and this is my first post.

Miles I came across your problem a while back while
upgrading my work site, trying everything I was about
to give up when Sitepoint.com published an article
from Kevin Yank that explained exactly how to open
documents in a new window. And it's standards
compliant as well!

View the article at
http://www.sitepoint.com/article/1041

Regards
Gino


 --- Miles Tillinger <[EMAIL PROTECTED]>
wrote: > 
> Just a question about how other developers handle
> opening documents e.g. PDF, DOC, in a new window.
> 
> At the moment I am using _blank targets.
> 
> Scenario 1: User is using IE with Word configured to
> open inside the IE window.  When the user clicks on
> a link to the Word doc a new IE window opens and the
> doc is loaded in that window.
> 
> Scenario 2: User is using IE or another browser, but
> is configured to open Word doc's in Word, not in the
> Browser window.  When the user clicks on a link to
> the Word doc a new Browser window open and the user
> either prompted to Save or Open the doc, or may even
> open the doc in Word automatically if the user has
> previously selected that option.  The problem here
> is that the user is left with a blank Browser
> window.
> 
> So Scenario 1 is how I'd like it to behave in every
> case, but is this possible?  Since I have no way of
> knowing how the user has their system configured I
> don't know whether to offer the link with a _blank
> target or not?  Is there an accessible standard way
> of doing it?
> 
> Regards,
> 
> Miles
> 
>
*
> The discussion list for
> http://webstandardsgroup.org/
>
*
>  

http://personals.yahoo.com.au - Yahoo! Personals
New people, new possibilities. FREE for a limited time.
*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] Re: px em pt ???

2003-12-09 Thread russ weakley 
Sorry for the length of this...

1. All government sites are supposed to follow WAI guideline - which
recommend the use of relative font sizes.

2. The aim is to give users the option. Saying that users can change their
screen resolution is throwing the responsibility back onto them - it is our
job to make it as easy as possible for all users to see our content.

3. There are many different users out there with a wide variety of vision
impairments from mildly reduced eyesight to totally blind. Each of these
groups has specific needs and we have to keep them all in mind.

We have done extensive testing with a wide range of these groups. I really
recommend all web designers and developers sit with both blind and near
blind users and watch them use your sites. It changes your perspective on
accessiblity.

One quick example to do with pixels: people with severe eye problems (close
to blind) would probably be using assistive technologies such as Zoom Text-
software based screen enlargers that can increase parts of the screen up to
400-600%. Pixel based fonts become a real issue for these people as there
are often not enough pixels to render a font properly. I sat with a woman
testing one of my sites were a footer was set to 12px and saw that the text
was unreadable for her. Fonts in nearby areas of the page that were
relatively positioned were able to be read easily.

4. Relative font sizing is very easy to manage as long as you understand two
things:

1. The document tree
2. inheritance

Relative font sizes will be inherited by items lower down the tree. EG.
Nested lists set with 80% will inherit and be reduced to 80% x 80%  = 64%.

To solve this problem, place your relative font declarations at one level of
the document tree or pay attention to how they can cascade and affect your
content. It is easy to reverse the effect with rules like:

ul ul { font-size: 100%;}

Russ



> 
> thats a good one...
> It makes sense what you are saying, to me anyway.
> 
> -Original Message-
> From: Miles Tillinger [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 10 December 2003 1:42 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [WSG] Re: px em pt ???
> 

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] Re: px em pt ???

2003-12-09 Thread Miles Tillinger 

touché Mark ;)  It is a problem that Windows buries its accessibility options so deep. 
 I think it would be better that he could walk into a net cafe and be able to easily 
changes the OS font-size.  However since this isn't the case, the ability to change it 
in the browser IS the next best thing...

Personally I am not going to use anything but relative font sizes in future site 
design, however I think it can be a steep learning curve for an amateur web designer 
when pixel sizes seem to be consistent in all browsers and so much simpler to use.

-Original Message-
From: Mark Stanton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 2:19 PM
To: [EMAIL PROTECTED]
Subject: RE: [WSG] Re: px em pt ???



I get your point Miles - but why should your grandfather NOT be able to walk
into an internet cafe and use the 15" monitor at 1024x768 with IE 5 on it?
Accessibility means removing as many obstacles as possible.


Cheers

Mark


--
Mark Stanton
Technical Director
Gruden Pty Ltd
Tel: 9956 6388
Mob: 0410 458 201
Fax: 9956 8433
http://www.gruden.com

*
The discussion list for http://webstandardsgroup.org/
* 

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] px em pt ???

2003-12-09 Thread Mark Stanton 

Hey Taco

In some browsers, yes. For example on a hand held the font size will
probably be quite a bit smaller than on a normal desktop.

But in terms of the common desktop browsers its ok, there are problems with
how %'s cascade in some cases but you can usually fix this up with a bit of
tweaking. In general we manage to get a pretty good level of accuracy across
the browsers we test in. However it does take more time than using pixel's
to get it right.


Cheers

Mark


--
Mark Stanton
Technical Director
Gruden Pty Ltd
Tel: 9956 6388
Mob: 0410 458 201
Fax: 9956 8433
http://www.gruden.com

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] Re: px em pt ???

2003-12-09 Thread Miles Tillinger 

Yes, I just thought of it whilst looking around at all the various articles about 
relative font sizes since I am in the midst of redeveloping a sites' stylesheet to use 
them.  I have previously used pixel sizes in a few sites without realising the impact. 
 However relative font sizes seem to have their fair share of inconsistencies as well. 
 I suppose only time and practise will help me to work out the most effective way of 
using em or %... 

-Original Message-
From: Taco Fleur [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 2:20 PM
To: [EMAIL PROTECTED]
Subject: RE: [WSG] Re: px em pt ???



thats a good one... 
It makes sense what you are saying, to me anyway.

-Original Message-
From: Miles Tillinger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 December 2003 1:42 PM
To: [EMAIL PROTECTED]
Subject: RE: [WSG] Re: px em pt ???



I definitely agree that relative sized fonts provide a more accessible design but I 
wonder about how sight-impaired users themselves use the web and their PC's in 
general?  For instance, my grandfather has coke-bottle-thickness glasses and as such 
uses a 19" monitor in 800x600 resolution, which seems ridiculous to me with my 20/20 
vision.  However for him it is perfect and when he reads websites he doesn't have to 
adjust the font size because it is already fine for him based on the fact that his 
interface is already configured to be large in all respects.

I doubt there would be site-impaired users who use 1280x1024 resolution for Windows 
and just increase the font-size in their browser.  In fact I would guess that they 
would, like my grandfather, already have their interface appearance tweaked the way 
thay want and therefore their browser would inherit the same appearance.

Just my $0.02...

Miles.


-Original Message-
From: Cameron Adams [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 1:49 PM
To: [EMAIL PROTECTED]
Subject: [WSG] Re: px em pt ???



That article gives the worst advice I've seen.

Basically, they're saying that if someone wants to
resize the text on your web page, you shouldn't allow
them to because it will break your site, making it
illegible.

If a user wants to resize the text on your site, it is
because it is illegible to them in the first place;
increasing font size can only improve matters.  Better
that it breaks your design and they're able to see the
content, rather than them not being able to see it at
all.

By using px units, you lock many users into exactly
the font size specified (some browsers can resize px,
but not IE).  Using a relative unit, such as em or %
(I use em), allows users to resize text so they can
ACTUALLY SEE IT.  If you ask any reasonably
usability-oriented designer they will tell you to use
relative units (www.stopdesign.com | www.zeldman.com),
and to code your web page structure to allow for
variable text sizes.

Hope this helps (and it didn't seem like I was yelling
at you), 
--
Cameron Adams

W: www.themaninblue.com


In reply to:

(aayyy, my third post today?) 

I'd like to see what all of yours opinion is on what
to use for sizes, I have always been a believer to
stick to pixels, because that is the only size that to
me sounds as something that is not platform/OS bound.

Anyway, I also found the following article to back
this up, who wants to break it down? 
 
Using CSS (cascading style sheets) makes it easy to
specify font sizes, but before you set a font size you
should be aware that it could change the layout of
your site considerably. Different browsers interpret
font sizes differently, so a font that appears
readable in Microsoft Internet Explorer may be smaller
when viewed in Netscape. In addition, font sizes on
Windows systems are not always the same as they are on
other platforms. Your site may look great to Windows
users, but it may be illegible to those using a Mac.

There is much controversy in relationship to font-size
specifications. Our advice is the same as the majority
of long-time designers. When you specify a font size,
specify it in pixels (px) not points (pt) or em. Using
a pt or em font-size property instead of px allows for
your site text to be resized according to the viewer's
system settings. If their system is set to view very
large text, your web site's layout will become
distorted and your web site may be illegible to them.

Also, be very careful not to set your font-size pixels
too small. Some folks may not be able to read tiny
text and adjusting their system text size will have no
effect on your site because your font-size is
specified as px. There truly is a happy medium in any
situation and the font-size (ie. 12px) will vary
depending on the font-family (ie. Arial, Times New
Roman, etc.) you use. 

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
*
The discussion list for http://webstandard

RE: [WSG] Re: px em pt ???

2003-12-09 Thread Mark Stanton 

I get your point Miles - but why should your grandfather NOT be able to walk
into an internet cafe and use the 15" monitor at 1024x768 with IE 5 on it?
Accessibility means removing as many obstacles as possible.


Cheers

Mark


--
Mark Stanton
Technical Director
Gruden Pty Ltd
Tel: 9956 6388
Mob: 0410 458 201
Fax: 9956 8433
http://www.gruden.com

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] Re: px em pt ???

2003-12-09 Thread Taco Fleur 

thats a good one... 
It makes sense what you are saying, to me anyway.

-Original Message-
From: Miles Tillinger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 December 2003 1:42 PM
To: [EMAIL PROTECTED]
Subject: RE: [WSG] Re: px em pt ???



I definitely agree that relative sized fonts provide a more accessible design but I 
wonder about how sight-impaired users themselves use the web and their PC's in 
general?  For instance, my grandfather has coke-bottle-thickness glasses and as such 
uses a 19" monitor in 800x600 resolution, which seems ridiculous to me with my 20/20 
vision.  However for him it is perfect and when he reads websites he doesn't have to 
adjust the font size because it is already fine for him based on the fact that his 
interface is already configured to be large in all respects.

I doubt there would be site-impaired users who use 1280x1024 resolution for Windows 
and just increase the font-size in their browser.  In fact I would guess that they 
would, like my grandfather, already have their interface appearance tweaked the way 
thay want and therefore their browser would inherit the same appearance.

Just my $0.02...

Miles.


-Original Message-
From: Cameron Adams [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 1:49 PM
To: [EMAIL PROTECTED]
Subject: [WSG] Re: px em pt ???



That article gives the worst advice I've seen.

Basically, they're saying that if someone wants to
resize the text on your web page, you shouldn't allow
them to because it will break your site, making it
illegible.

If a user wants to resize the text on your site, it is
because it is illegible to them in the first place;
increasing font size can only improve matters.  Better
that it breaks your design and they're able to see the
content, rather than them not being able to see it at
all.

By using px units, you lock many users into exactly
the font size specified (some browsers can resize px,
but not IE).  Using a relative unit, such as em or %
(I use em), allows users to resize text so they can
ACTUALLY SEE IT.  If you ask any reasonably
usability-oriented designer they will tell you to use
relative units (www.stopdesign.com | www.zeldman.com),
and to code your web page structure to allow for
variable text sizes.

Hope this helps (and it didn't seem like I was yelling
at you), 
--
Cameron Adams

W: www.themaninblue.com


In reply to:

(aayyy, my third post today?) 

I'd like to see what all of yours opinion is on what
to use for sizes, I have always been a believer to
stick to pixels, because that is the only size that to
me sounds as something that is not platform/OS bound.

Anyway, I also found the following article to back
this up, who wants to break it down? 
 
Using CSS (cascading style sheets) makes it easy to
specify font sizes, but before you set a font size you
should be aware that it could change the layout of
your site considerably. Different browsers interpret
font sizes differently, so a font that appears
readable in Microsoft Internet Explorer may be smaller
when viewed in Netscape. In addition, font sizes on
Windows systems are not always the same as they are on
other platforms. Your site may look great to Windows
users, but it may be illegible to those using a Mac.

There is much controversy in relationship to font-size
specifications. Our advice is the same as the majority
of long-time designers. When you specify a font size,
specify it in pixels (px) not points (pt) or em. Using
a pt or em font-size property instead of px allows for
your site text to be resized according to the viewer's
system settings. If their system is set to view very
large text, your web site's layout will become
distorted and your web site may be illegible to them.

Also, be very careful not to set your font-size pixels
too small. Some folks may not be able to read tiny
text and adjusting their system text size will have no
effect on your site because your font-size is
specified as px. There truly is a happy medium in any
situation and the font-size (ie. 12px) will vary
depending on the font-family (ie. Arial, Times New
Roman, etc.) you use. 

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
*
The discussion list for http://webstandardsgroup.org/
* 

*
The discussion list for http://webstandardsgroup.org/
* 

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] px em pt ???

2003-12-09 Thread Taco Fleur 

Correct me if I am wrong, but if your working with % percentage, does that mean that 
in some browsers the font size can be bigger or smaller than intended? Thats what I 
understoud from the article that Russ send me the link of.

-Original Message-
From: Mark Stanton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 December 2003 1:32 PM
To: [EMAIL PROTECTED]
Subject: RE: [WSG] px em pt ???



Hey Taco

The general idea that we stick to in here is that % or ems are best.

This is to work around a "bug" in IE/WIN that prevents px based fonts being
resized easily. It is still possible to resize px fonts in IE but you have
to dig around in the menu rather than using ctrl+scrolly mouse.

Perfect case of theoretical accessibility vs. real life accessibility.

Using pt for fonts on the web is a mistake. Points are a unit for measuring
fonts on paper and do not adapt well to the complexities of screen
resolution, etc..


Cheers

Mark


--
Mark Stanton
Technical Director
Gruden Pty Ltd
Tel: 9956 6388
Mob: 0410 458 201
Fax: 9956 8433
http://www.gruden.com

*
The discussion list for http://webstandardsgroup.org/
* 

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] Re: px em pt ???

2003-12-09 Thread Miles Tillinger 

I definitely agree that relative sized fonts provide a more accessible design but I 
wonder about how sight-impaired users themselves use the web and their PC's in 
general?  For instance, my grandfather has coke-bottle-thickness glasses and as such 
uses a 19" monitor in 800x600 resolution, which seems ridiculous to me with my 20/20 
vision.  However for him it is perfect and when he reads websites he doesn't have to 
adjust the font size because it is already fine for him based on the fact that his 
interface is already configured to be large in all respects.

I doubt there would be site-impaired users who use 1280x1024 resolution for Windows 
and just increase the font-size in their browser.  In fact I would guess that they 
would, like my grandfather, already have their interface appearance tweaked the way 
thay want and therefore their browser would inherit the same appearance.

Just my $0.02...

Miles.


-Original Message-
From: Cameron Adams [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 1:49 PM
To: [EMAIL PROTECTED]
Subject: [WSG] Re: px em pt ???



That article gives the worst advice I've seen.

Basically, they're saying that if someone wants to
resize the text on your web page, you shouldn't allow
them to because it will break your site, making it
illegible.

If a user wants to resize the text on your site, it is
because it is illegible to them in the first place;
increasing font size can only improve matters.  Better
that it breaks your design and they're able to see the
content, rather than them not being able to see it at
all.

By using px units, you lock many users into exactly
the font size specified (some browsers can resize px,
but not IE).  Using a relative unit, such as em or %
(I use em), allows users to resize text so they can
ACTUALLY SEE IT.  If you ask any reasonably
usability-oriented designer they will tell you to use
relative units (www.stopdesign.com | www.zeldman.com),
and to code your web page structure to allow for
variable text sizes.

Hope this helps (and it didn't seem like I was yelling
at you), 
--
Cameron Adams

W: www.themaninblue.com


In reply to:

(aayyy, my third post today?) 

I'd like to see what all of yours opinion is on what
to use for sizes, I have always been a believer to
stick to pixels, because that is the only size that to
me sounds as something that is not platform/OS bound.

Anyway, I also found the following article to back
this up, who wants to break it down? 
 
Using CSS (cascading style sheets) makes it easy to
specify font sizes, but before you set a font size you
should be aware that it could change the layout of
your site considerably. Different browsers interpret
font sizes differently, so a font that appears
readable in Microsoft Internet Explorer may be smaller
when viewed in Netscape. In addition, font sizes on
Windows systems are not always the same as they are on
other platforms. Your site may look great to Windows
users, but it may be illegible to those using a Mac.

There is much controversy in relationship to font-size
specifications. Our advice is the same as the majority
of long-time designers. When you specify a font size,
specify it in pixels (px) not points (pt) or em. Using
a pt or em font-size property instead of px allows for
your site text to be resized according to the viewer's
system settings. If their system is set to view very
large text, your web site's layout will become
distorted and your web site may be illegible to them.

Also, be very careful not to set your font-size pixels
too small. Some folks may not be able to read tiny
text and adjusting their system text size will have no
effect on your site because your font-size is
specified as px. There truly is a happy medium in any
situation and the font-size (ie. 12px) will vary
depending on the font-family (ie. Arial, Times New
Roman, etc.) you use. 

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
*
The discussion list for http://webstandardsgroup.org/
* 

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] px em pt ???

2003-12-09 Thread Mark Stanton 

Hey Taco

The general idea that we stick to in here is that % or ems are best.

This is to work around a "bug" in IE/WIN that prevents px based fonts being
resized easily. It is still possible to resize px fonts in IE but you have
to dig around in the menu rather than using ctrl+scrolly mouse.

Perfect case of theoretical accessibility vs. real life accessibility.

Using pt for fonts on the web is a mistake. Points are a unit for measuring
fonts on paper and do not adapt well to the complexities of screen
resolution, etc..


Cheers

Mark


--
Mark Stanton
Technical Director
Gruden Pty Ltd
Tel: 9956 6388
Mob: 0410 458 201
Fax: 9956 8433
http://www.gruden.com

*
The discussion list for http://webstandardsgroup.org/
*

[WSG] OT: Opening documents in _blank window

2003-12-09 Thread Miles Tillinger 

Just a question about how other developers handle opening documents e.g. PDF, DOC, in 
a new window.

At the moment I am using _blank targets.

Scenario 1: User is using IE with Word configured to open inside the IE window.  When 
the user clicks on a link to the Word doc a new IE window opens and the doc is loaded 
in that window.

Scenario 2: User is using IE or another browser, but is configured to open Word doc's 
in Word, not in the Browser window.  When the user clicks on a link to the Word doc a 
new Browser window open and the user either prompted to Save or Open the doc, or may 
even open the doc in Word automatically if the user has previously selected that 
option.  The problem here is that the user is left with a blank Browser window.

So Scenario 1 is how I'd like it to behave in every case, but is this possible?  Since 
I have no way of knowing how the user has their system configured I don't know whether 
to offer the link with a _blank target or not?  Is there an accessible standard way of 
doing it?

Regards,

Miles

*
The discussion list for http://webstandardsgroup.org/
*

[WSG] Re: px em pt ???

2003-12-09 Thread Cameron Adams 

That article gives the worst advice I've seen.

Basically, they're saying that if someone wants to
resize the text on your web page, you shouldn't allow
them to because it will break your site, making it
illegible.

If a user wants to resize the text on your site, it is
because it is illegible to them in the first place;
increasing font size can only improve matters.  Better
that it breaks your design and they're able to see the
content, rather than them not being able to see it at
all.

By using px units, you lock many users into exactly
the font size specified (some browsers can resize px,
but not IE).  Using a relative unit, such as em or %
(I use em), allows users to resize text so they can
ACTUALLY SEE IT.  If you ask any reasonably
usability-oriented designer they will tell you to use
relative units (www.stopdesign.com | www.zeldman.com),
and to code your web page structure to allow for
variable text sizes.

Hope this helps (and it didn't seem like I was yelling
at you), 
--
Cameron Adams

W: www.themaninblue.com


In reply to:

(aayyy, my third post today?) 

I'd like to see what all of yours opinion is on what
to use for sizes, I have always been a believer to
stick to pixels, because that is the only size that to
me sounds as something that is not platform/OS bound.

Anyway, I also found the following article to back
this up, who wants to break it down? 
 
Using CSS (cascading style sheets) makes it easy to
specify font sizes, but before you set a font size you
should be aware that it could change the layout of
your site considerably. Different browsers interpret
font sizes differently, so a font that appears
readable in Microsoft Internet Explorer may be smaller
when viewed in Netscape. In addition, font sizes on
Windows systems are not always the same as they are on
other platforms. Your site may look great to Windows
users, but it may be illegible to those using a Mac.

There is much controversy in relationship to font-size
specifications. Our advice is the same as the majority
of long-time designers. When you specify a font size,
specify it in pixels (px) not points (pt) or em. Using
a pt or em font-size property instead of px allows for
your site text to be resized according to the viewer's
system settings. If their system is set to view very
large text, your web site's layout will become
distorted and your web site may be illegible to them.

Also, be very careful not to set your font-size pixels
too small. Some folks may not be able to read tiny
text and adjusting their system text size will have no
effect on your site because your font-size is
specified as px. There truly is a happy medium in any
situation and the font-size (ie. 12px) will vary
depending on the font-family (ie. Arial, Times New
Roman, etc.) you use. 

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
*
The discussion list for http://webstandardsgroup.org/
*

[WSG] Hours of thrilling reading from the W3C

2003-12-09 Thread Mark Stanton 

Hey All

Just thought I'd let you know there are two new docs out from the W3C today.

The first is the Working Draft for HTML Techniques for WCAG 2.0. I've had a
browse over this doc and it actually looks quite interesting & useful. It
seems the idea is to make accessibility a bit more accessible.

The document is broken down into tasks or common problems, for each task
there is a statement, a description and an example showing the best
solution. This is really a reference document rather than a "read start to
finish" document, so download a copy and check it when you are stuck.

- http://www.w3.org/TR/2003/WD-WCAG20-HTML-TECHS-20031209/


The second doc is a bit heavier going, its the Working Draft for the
Architecture of the World Wide Web. Its a big title but it lives up to its
name.

Basically this document is there to define how all the bits work together.
Things like URIs, MIME Types, character encoding, namespaces,
content/presentation and all that. Even if you just skim this document and
read the guidelines in boxes you'll get the general idea of it all.

- http://www.w3.org/TR/2003/WD-webarch-20031209/


Cheers

Mark


--
Mark Stanton
Technical Director
Gruden Pty Ltd
Tel: 9956 6388
Mob: 0410 458 201
Fax: 9956 8433
http://www.gruden.com

*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] form input [Virus checkedAU]

2003-12-09 Thread James Ellis 
rereading that it may not be clear, if you want to style the button in 
the label you could do something like this...

label.submitbuttons input
{
  rule : value;
}
wonder if just

.submitbuttons input

would work?

James Ellis wrote:

Not really, there is no class on the submit, it's a class on the 
surrounding block.. a label in this example. Better to use a class as 
their may be more than one submit/reset on the page.



.submitbuttons
{
 background-color : red;
}


.resetbuttons
{
background-color : blue;
}
Cheers
James
Taco Fleur wrote:

Yes, but that would the same as assigning a class to the submit button.

Anyway, thanks for the input - answer: it can't be done yet;-))
*
The discussion list for http://webstandardsgroup.org/
*
*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] form input [Virus checkedAU]

2003-12-09 Thread James Ellis 
Not really, there is no class on the submit, it's a class on the 
surrounding block.. a label in this example. Better to use a class as 
their may be more than one submit/reset on the page.



.submitbuttons
{
 background-color : red;
}


.resetbuttons
{
background-color : blue;
}
Cheers
James
Taco Fleur wrote:

Yes, but that would the same as assigning a class to the submit button.

Anyway, thanks for the input - answer: it can't be done yet;-))
*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] px em pt ???

2003-12-09 Thread russ weakley 
http://www.maxdesign.com.au/presentation/relative/



> (aayyy, my third post today?)
> 
> I'd like to see what all of yours opinion is on what to use for sizes, I have
> always been a believer to stick to pixels, because that is the only size that
> to me sounds as something that is not platform/OS bound.
> 
> Anyway, I also found the following article to back this up, who wants to break
> it down? 
> 
> Using CSS (cascading style sheets) makes it easy to specify font sizes, but
> before you set a font size you should be aware that it could change the layout
> of your site considerably. Different browsers interpret font sizes
> differently, so a font that appears readable in Microsoft Internet Explorer
> may be smaller when viewed in Netscape. In addition, font sizes on Windows
> systems are not always the same as they are on other platforms. Your site may
> look great to Windows users, but it may be illegible to those using a Mac.
> 
> There is much controversy in relationship to font-size specifications. Our
> advice is the same as the majority of long-time designers. When you specify a
> font size, specify it in pixels (px) not points (pt) or em. Using a pt or em
> font-size property instead of px allows for your site text to be resized
> according to the viewer's system settings. If their system is set to view very
> large text, your web site's layout will become distorted and your web site may
> be illegible to them.
> 
> Also, be very careful not to set your font-size pixels too small. Some folks
> may not be able to read tiny text and adjusting their system text size will
> have no effect on your site because your font-size is specified as px. There
> truly is a happy medium in any situation and the font-size (ie. 12px) will
> vary depending on the font-family (ie. Arial, Times New Roman, etc.) you use.
> 
> Taco Fleur
> 07 3535 5072 
> Tell me and I will forget
> Show me and I will remember
> Teach me and I will learn
> 


Thanks
Russ

---
Russ Weakley
Max Design
Phone: (02) 9410 2521
Mobile: 0403 433 980
Email: [EMAIL PROTECTED]
http://www.maxdesign.com.au
---


*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] form input [Virus checkedAU]

2003-12-09 Thread Stephen Dixon 

Taco,

There's more than one way to reference a cat.

I think what Mark means is that if there was a  around the submit
button you could use that as a more specific selector.  IMHO, probably just
easier to use a class (as previously mentioned...)

Steve Dixon.


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**

*
The discussion list for http://webstandardsgroup.org/
*

[WSG] px em pt ???

2003-12-09 Thread Taco Fleur 
Title: px em pt ???






(aayyy, my third post today?)


I'd like to see what all of yours opinion is on what to use for sizes, I have always been a believer to stick to pixels, because that is the only size that to me sounds as something that is not platform/OS bound.

Anyway, I also found the following article to back this up, who wants to break it down?



Using CSS (cascading style sheets) makes it easy to specify font sizes, but before you set a font size you should be aware that it could change the layout of your site considerably. Different browsers interpret font sizes differently, so a font that appears readable in Microsoft Internet Explorer may be smaller when viewed in Netscape. In addition, font sizes on Windows systems are not always the same as they are on other platforms. Your site may look great to Windows users, but it may be illegible to those using a Mac.

There is much controversy in relationship to font-size specifications. Our advice is the same as the majority of long-time designers. When you specify a font size, specify it in pixels (px) not points (pt) or em. Using a pt or em font-size property instead of px allows for your site text to be resized according to the viewer's system settings. If their system is set to view very large text, your web site's layout will become distorted and your web site may be illegible to them.

Also, be very careful not to set your font-size pixels too small. Some folks may not be able to read tiny text and adjusting their system text size will have no effect on your site because your font-size is specified as px. There truly is a happy medium in any situation and the font-size (ie. 12px) will vary depending on the font-family (ie. Arial, Times New Roman, etc.) you use. 

Taco Fleur
07 3535 5072

Tell me and I will forget
Show me and I will remember
Teach me and I will learn

Re: [WSG] form input

2003-12-09 Thread Ryan Christie 
As far as I know you can't really target tags by their elements. Since 
the submit button is just a type="submit" input tag, the normal input 
rules will apply to it. I'd say go with your second style and remember 
that some of the properties will cascade down.. you may have to redefine 
certain properties in the CSS for the submit button to look like you 
want it.

I'd also give the form an ID because that those declarations will bleed 
throughout your entire site. This may not be a problem, but it 
potentially could be in the future if you added more forms that needed 
different style. Besides, it's just good practice to keep everything 
orderly :) I.E., if it is a Search form, you'd use search#form input, 
and use  for your tag.

Besides, that way is perfectly acceptable and very clean structure-wise 
- what exactly were you "after"?

Ryan
--
"Heck with kids - standards are our future."
Webmaster, http://www.theward.net
Taco Fleur wrote:

Is there some way that you can only target input elements with type 
SUBMIT?

Example;


form input
{
background-color: #FFCFCE;
border: 1px solid black;
font-weight: bold;
color: white;
width: 160px;
background-image: url(../image/buttonSubmit_background03.gif);
cursor: hand;
background-repeat: repeat-x;
}





  
  

This would apply the style over all INPUT elements, but I was 
wondering if it could be just applied to the input elements that have 
type SUBMIT or BUTTON?

I realize I could do it the following way, but thats not what I am after.


form input .submit
{
background-color: #FFCFCE;
border: 1px solid black;
font-weight: bold;
color: white;
width: 160px;
background-image: url(../image/buttonSubmit_background03.gif);
cursor: hand;
background-repeat: repeat-x;
}





  
  

*Taco Fleur
*Tell me and I will forget
Show me and I will remember
Teach me and I will learn
*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] form input [Virus checkedAU]

2003-12-09 Thread Taco Fleur 

Steve,

I realize what your saying, and thats exactly what I meant by "I realize I could do it 
the following way, but thats not what I am after." Which was refering to using a class.

Cheers.

-Original Message-
From: Stephen Dixon [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 December 2003 10:51 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [WSG] form input [Virus checkedAU]



Taco,

There's more than one way to reference a cat.

I think what Mark means is that if there was a  around the submit
button you could use that as a more specific selector.  IMHO, probably just
easier to use a class (as previously mentioned...)

Steve Dixon.


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**

*
The discussion list for http://webstandardsgroup.org/
* 

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] form input [Virus checkedAU]

2003-12-09 Thread Taco Fleur 

Yes, but that would the same as assigning a class to the submit button.

Anyway, thanks for the input - answer: it can't be done yet;-))

-Original Message-
From: James Ellis [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 December 2003 10:36 AM
To: [EMAIL PROTECTED]
Subject: Re: [WSG] form input [Virus checkedAU]



..using a descendant selector...

#mydiv input
{
   blah : blah;
}

#anotherdiv input
{
   blah : blah;
}

That said, I've had some issues with getting markup to validate with 
divs in forms.

Cheers
James
*
The discussion list for http://webstandardsgroup.org/
* 

*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] form input [Virus checkedAU]

2003-12-09 Thread James Ellis 
..using a descendant selector...

#mydiv input
{
  blah : blah;
}
#anotherdiv input
{
  blah : blah;
}
That said, I've had some issues with getting markup to validate with 
divs in forms.

Cheers
James
*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] new member says hello

2003-12-09 Thread Universal Head 
Hi folks,

Peter Gifford here, new member just introducing myself. Hopefully I 
can be of some service on the list and not just poke about in your 
experienced brains whenever I'm stumped.

I've been designing as 'Universal Head' for almost ten years, and 
have done everything from print to websites to 3D game design and 
production. You can check out my work at the url below if you're 
interested. I also have a personal site, www.petergifford.com (mostly 
travel diaries). I started getting into XHTML and CSS a few months 
ago, mostly after admiring the work of Zeldman and Todd Dominey, and 
did a seminar with John Allsop just last Friday. I finally feel like 
I'm getting the hang of the whole thing and am now after many years 
back to making sites in code rather than in GoLive. Yay!

Right, thanks for listening, and looking forward to participating,
Peter
--
peter gifford

universal head
design that works
visit   7/43 bridge road
stanmore nsw 2048
australia
call(+612) 9517 1466
fax (+612) 9565 4747
email   [EMAIL PROTECTED]
sitewww.universalhead.com
*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] new member says hello

2003-12-09 Thread russ weakley 
Hi again, Peter, welcome to the list.
Had a look at your site the other day. Beautiful stuff in the portfolio
section!
Russ


> 
> Hi folks,
> 
> Peter Gifford here, new member just introducing myself. Hopefully I
> can be of some service on the list and not just poke about in your
> experienced brains whenever I'm stumped.
> 
> I've been designing as 'Universal Head' for almost ten years, and
> have done everything from print to websites to 3D game design and
> production. You can check out my work at the url below if you're
> interested. I also have a personal site, www.petergifford.com (mostly
> travel diaries). I started getting into XHTML and CSS a few months
> ago, mostly after admiring the work of Zeldman and Todd Dominey, and
> did a seminar with John Allsop just last Friday. I finally feel like
> I'm getting the hang of the whole thing and am now after many years
> back to making sites in code rather than in GoLive. Yay!
> 
> Right, thanks for listening, and looking forward to participating,
> Peter

*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] form input [Virus checkedAU]

2003-12-09 Thread Taco Fleur 

Hi Mark,



The answer as ever is yes and no.  Yes in mozilla et al and no in IE.


As always ofcourse.


The only way to do it reliable is the way you are proposing - unless you
can refer to it another way - i.e. does it sit in another div that is
referencable?


I don't see however how it being in another div would make any difference? Can you 
explain how it would make a difference if it was in another DIV?

Thanks
*
The discussion list for http://webstandardsgroup.org/
*

RE: [WSG] form input [Virus checkedAU]

2003-12-09 Thread Mark Stanton 

Or apply a class to it.


Cheers

Mark


--
Mark Stanton 
Technical Director 
Gruden Pty Ltd 
Tel: 9956 6388
Mob: 0410 458 201 
Fax: 9956 8433 
http://www.gruden.com
*
The discussion list for http://webstandardsgroup.org/
*

Re: [WSG] form input [Virus checkedAU]

2003-12-09 Thread Mark . Lynch 





This email is to be read subject to the disclaimer below.

Hi Taco,

The answer as ever is yes and no.  Yes in mozilla et al and no in IE.

The "attribute" selector is used as follows:

input[type="submit"]{  your css attributes here}

The only way to do it reliable is the way you are proposing - unless you
can refer to it another way - i.e. does it sit in another div that is
referencable?

Mark Lynch
Development Manager - Business Innovation Online
Ernst & Young - Australia
http://www.eyware.com/
http://www.eyonline.com/
Direct: +612 9248 4038
Fax: +612 9248 4073
Mobile: +61 421 050 695


   

   "Taco Fleur"

   <[EMAIL PROTECTED] To:  <[EMAIL PROTECTED]> 
   
   com.au> cc: 

   Subject: [WSG] form input  [Virus 
checkedAU]
   10/12/2003  

   10:56 AM

   Please respond  

   to wsg  

   

   




Is there some way that you can only target input elements with type SUBMIT?


Example;



form input
{
background-color: #FFCFCE;
border: 1px solid black;
font-weight: bold;
color: white;
width: 160px;
background-image: url(../image/buttonSubmit_background03.gif);
cursor: hand;
background-repeat: repeat-x;
}








  
  



This would apply the style over all INPUT elements, but I was wondering if
it could be just applied to the input elements that have type SUBMIT or
BUTTON?


I realize I could do it the following way, but thats not what I am after.



form input .submit
{
background-color: #FFCFCE;
border: 1px solid black;
font-weight: bold;
color: white;
width: 160px;
background-image: url(../image/buttonSubmit_background03.gif);
cursor: hand;
background-repeat: repeat-x;
}








  
  

Taco Fleur
Tell me and I will forget
Show me and I will remember
Teach me and I will learn








NOTICE - This communication contains information which is confidential and
the copyright of Ernst & Young or a third party.

If you are not the intended recipient of this communication please delete
and destroy all copies and telephone Ernst & Young on 1800 655 717
immediately. If you are the intended recipient of this communication you
should not copy, disclose  or distribute this communication without the
authority of Ernst & Young.

Any views expressed in this Communication are those of the individual
sender, except where the sender specifically states them to be the views of
Ernst & Young.

Except as required at law, Ernst & Young does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained nor
that the communication is free of errors, virus, interception or
interference.

Liability limited by the Accountants Scheme, approved under the
Professional Standards Act 1994 (NSW)




*
The discussion list for http://webstandardsgroup.org/
*

[WSG] form input

2003-12-09 Thread Taco Fleur 
Title: form input






Is there some way that you can only target input elements with type SUBMIT?


Example;





form input


{


    background-color: #FFCFCE;


    border: 1px solid black;


    font-weight: bold;


    color: white;


    width: 160px;


    background-image: url(../image/buttonSubmit_background03.gif);


    cursor: hand;


    background-repeat: repeat-x;


}












  

  




This would apply the style over all INPUT elements, but I was wondering if it could be just applied to the input elements that have type SUBMIT or BUTTON?

I realize I could do it the following way, but thats not what I am after.





form input .submit


{


    background-color: #FFCFCE;


    border: 1px solid black;


    font-weight: bold;


    color: white;


    width: 160px;


    background-image: url(../image/buttonSubmit_background03.gif);


    cursor: hand;


    background-repeat: repeat-x;


}












  

  



Taco Fleur
Tell me and I will forget
Show me and I will remember
Teach me and I will learn

Re: [WSG] website help, fixing problem with ie5

2003-12-09 Thread Ryan Christie 
Try redoing the layout aspects of the CSS using a shell from 
http://www.inknoise.com/experimental/layoutomatic.php ... For 
educational purposes I would keep an old copy of your stylesheet 
settings to check for differences.

The only markup error I noticed was in your  declaration. You 
should declare it as follows:
http://www.w3.org/1999/xhtml"; xml:lang="en">
If that fixes the spacing problem, all the better ;) I'm just a trained 
monkey, and my master (W3C) says that's how the cookie crumbles.

I suspect that it would have something to do with margins or pad 
settings. If you do not define the margins or paddings in IE as zero 
explicitly, the browser will make up its own values and misbehave 
accordingly.

IE versions are really a tiresome ordeal to work with. I feel your pain.

Ryan
--
"Heck with kids - standards are our future."
Webmaster, http://www.theward.net
Hill, Tim wrote:

Hi, sorry to do this but I cant find the problem I am having.

The address is http://www.pinkforlife.info/new/home.html

My site is structured with;

A header div

A container div, that contains, a content (left), and nav (right)

A footer div

In ie5 there is a gap from the containing div to the header, and footer.

Margins dont seem to remove this. But if I add a border to the 
container div on the top and bottom, it removes the gap on the top.

I dont think it is a box model problem but I could be wrong. I am 
using XHTML transitional for my DTD.

Thanks for any help.

Tim Hill

Computer Associates

Graphic Artist

tel: +612 9937 0792

fax: +612 9937 0546

[EMAIL PROTECTED] 

*
The discussion list for http://webstandardsgroup.org/
*