[WSG] ems versus pixels

2010-07-20 Thread AGerasimchuk
Hi,

I've been converting some of our company public-facing static web-sites 
from pixels to ems for layout and font-size.
But just recently I encountered several references that pixels are getting 
back into popularity - as it offers absolute control over text,  and 
that most browsers now can resize font based on pixels.

Any thoughts/suggestions on whether I should push the effort on converting 
our sites to ems?

Anya Gerasimchuk
 
***
This message may contain confidential information intended only
for the use of the addressee(s) named above and may contain
information that is legally privileged. If you are not the
addressee, or the person responsible for delivering it to the
addressee, you are hereby notified that reading, disseminating,
distributing or copying this message is strictly prohibited.  If you
have received this message by mistake, please immediately notify
us by replying to the message and delete the original message
immediately thereafter.  Thank you.
***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] ems versus pixels

2010-07-20 Thread Edward Lynn
Modern browsers now implement page zoom, and so using ems for me is becoming
unnecessary. I get much better x-browser control with px's and so that is
the direction im moving in

Ed

On Tue, Jul 20, 2010 at 2:53 PM, agerasimc...@unioncentral.com wrote:


 Hi,

 I've been converting some of our company public-facing static web-sites
 from pixels to ems for layout and font-size.
 But just recently I encountered several references that pixels are getting
 back into popularity - as it offers absolute control over text,  and that
 most browsers now can resize font based on pixels.

 Any thoughts/suggestions on whether I should push the effort on converting
 our sites to ems?

 Anya Gerasimchuk


 ***
 This message may contain confidential information intended only
 for the use of the addressee(s) named above and may contain
 information that is legally privileged. If you are not the
 addressee, or the person responsible for delivering it to the
 addressee, you are hereby notified that reading, disseminating,
 distributing or copying this message is strictly prohibited.  If you
 have received this message by mistake, please immediately notify
 us by replying to the message and delete the original message
 immediately thereafter.  Thank you.
 ***


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] ems versus pixels

2010-07-20 Thread Phil Archer

I must offer a contrary view to Edward!

Any page that requires a user with normal vision to have to zoom on any 
device is, in my view, a sign of a really badly designed page on a 
really smart device.


Pixels can be regarded as a proportional measure since pixel density 
varies between screens. Ems are proportional to the size of text you're 
using - and that's generally the thing you want to be proportional to.


For me, line thickness can justifiably given in pixels (and that's 
mainly because 'thin' means 1px in the standards browsers and a 
different measure, 2px, in you-know-which browser). Image sizes should 
always be specified in the markup, so that's in pixel sizes too. Apart 
from that, it's ems all the way for me.


Phil.

Edward Lynn wrote:

Modern browsers now implement page zoom, and so using ems for me is becoming
unnecessary. I get much better x-browser control with px's and so that is
the direction im moving in

Ed

On Tue, Jul 20, 2010 at 2:53 PM, agerasimc...@unioncentral.com wrote:


Hi,

I've been converting some of our company public-facing static web-sites
from pixels to ems for layout and font-size.
But just recently I encountered several references that pixels are getting
back into popularity - as it offers absolute control over text,  and that
most browsers now can resize font based on pixels.

Any thoughts/suggestions on whether I should push the effort on converting
our sites to ems?

Anya Gerasimchuk


***
This message may contain confidential information intended only
for the use of the addressee(s) named above and may contain
information that is legally privileged. If you are not the
addressee, or the person responsible for delivering it to the
addressee, you are hereby notified that reading, disseminating,
distributing or copying this message is strictly prohibited.  If you
have received this message by mistake, please immediately notify
us by replying to the message and delete the original message
immediately thereafter.  Thank you.
***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


--


Phil Archer
W3C Mobile Web Initiative
http://www.w3.org/Mobile

http://philarcher.org
@philarcher1


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] ems versus pixels

2010-07-20 Thread Edward Lynn
I actually think this is a really interesting, key area of current web
development, how about we add some links to resources putting either
argument forward?

On Tue, Jul 20, 2010 at 3:30 PM, Phil Archer ph...@w3.org wrote:

 I must offer a contrary view to Edward!

 Any page that requires a user with normal vision to have to zoom on any
 device is, in my view, a sign of a really badly designed page on a really
 smart device.

 Pixels can be regarded as a proportional measure since pixel density varies
 between screens. Ems are proportional to the size of text you're using - and
 that's generally the thing you want to be proportional to.

 For me, line thickness can justifiably given in pixels (and that's mainly
 because 'thin' means 1px in the standards browsers and a different measure,
 2px, in you-know-which browser). Image sizes should always be specified in
 the markup, so that's in pixel sizes too. Apart from that, it's ems all the
 way for me.

 Phil.

 Edward Lynn wrote:

 Modern browsers now implement page zoom, and so using ems for me is
 becoming
 unnecessary. I get much better x-browser control with px's and so that is
 the direction im moving in

 Ed

 On Tue, Jul 20, 2010 at 2:53 PM, agerasimc...@unioncentral.com wrote:

  Hi,

 I've been converting some of our company public-facing static web-sites
 from pixels to ems for layout and font-size.
 But just recently I encountered several references that pixels are
 getting
 back into popularity - as it offers absolute control over text,  and
 that
 most browsers now can resize font based on pixels.

 Any thoughts/suggestions on whether I should push the effort on
 converting
 our sites to ems?

 Anya Gerasimchuk


 ***
 This message may contain confidential information intended only
 for the use of the addressee(s) named above and may contain
 information that is legally privileged. If you are not the
 addressee, or the person responsible for delivering it to the
 addressee, you are hereby notified that reading, disseminating,
 distributing or copying this message is strictly prohibited.  If you
 have received this message by mistake, please immediately notify
 us by replying to the message and delete the original message
 immediately thereafter.  Thank you.
 ***


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***



 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***


 --


 Phil Archer
 W3C Mobile Web Initiative
 http://www.w3.org/Mobile

 http://philarcher.org
 @philarcher1


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] ems versus pixels

2010-07-20 Thread Jason Arnold
On Tue, Jul 20, 2010 at 9:59 AM, David Laakso
da...@chelseacreekstudio.com wrote:
 Points is the way to go nowadays :-) .

 Best,
 ~d

I think picas is the way to go ;)

here are some resources on the use of Ems vs Pixels

http://css-discuss.incutio.com/wiki/Using_Font_Size

which links to these two additional pages

http://css-discuss.incutio.com/wiki/Using_Pixels
http://css-discuss.incutio.com/wiki/Using_Ems

Then i found this document from 2007 which is a decent read and is
relative to the this topic

http://www.alistapart.com/articles/howtosizetextincss/

personally, I prefer ems to pixels.

-- 

Jason Arnold
http://www.jasonarnold.net



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] ems versus pixels

2010-07-20 Thread Foskett, Mike
Has anyone on the list considered using keywords?

Set body tag to either 100.1% in IE, while pixels are fine in non-IE browsers:

  body { font: 16px/1.4em verdana, helvetica, sans-serif; }
  * html body { font: 100.1%/1.4em verdana, helvetica, sans-serif; }

Though recently I've been using line-heights without the unit type with good 
success.

There on in use keywords:
   x-small - disclaimer and legal footers
   small - body text
   medium to xx-large for headings.

A sizing chart may be found here:
http://websemantics.co.uk/resources/font_size_conversion_chart/




Mike Foskett
http://websemantics.co.uk/



-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On 
Behalf Of Phil Archer
Sent: 20 July 2010 15:31
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] ems versus pixels

I must offer a contrary view to Edward!

Any page that requires a user with normal vision to have to zoom on any
device is, in my view, a sign of a really badly designed page on a
really smart device.

Pixels can be regarded as a proportional measure since pixel density
varies between screens. Ems are proportional to the size of text you're
using - and that's generally the thing you want to be proportional to.

For me, line thickness can justifiably given in pixels (and that's
mainly because 'thin' means 1px in the standards browsers and a
different measure, 2px, in you-know-which browser). Image sizes should
always be specified in the markup, so that's in pixel sizes too. Apart
from that, it's ems all the way for me.

Phil.

Edward Lynn wrote:
 Modern browsers now implement page zoom, and so using ems for me is becoming
 unnecessary. I get much better x-browser control with px's and so that is
 the direction im moving in

 Ed

 On Tue, Jul 20, 2010 at 2:53 PM, agerasimc...@unioncentral.com wrote:

 Hi,

 I've been converting some of our company public-facing static web-sites
 from pixels to ems for layout and font-size.
 But just recently I encountered several references that pixels are getting
 back into popularity - as it offers absolute control over text,  and that
 most browsers now can resize font based on pixels.

 Any thoughts/suggestions on whether I should push the effort on converting
 our sites to ems?

 Anya Gerasimchuk


 ***
 This message may contain confidential information intended only
 for the use of the addressee(s) named above and may contain
 information that is legally privileged. If you are not the
 addressee, or the person responsible for delivering it to the
 addressee, you are hereby notified that reading, disseminating,
 distributing or copying this message is strictly prohibited.  If you
 have received this message by mistake, please immediately notify
 us by replying to the message and delete the original message
 immediately thereafter.  Thank you.
 ***


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***


 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***

--


Phil Archer
W3C Mobile Web Initiative
http://www.w3.org/Mobile

http://philarcher.org
@philarcher1


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


This is a confidential email. Tesco may monitor and record all emails. The 
views expressed in this email are those of the sender and not Tesco.

Tesco Stores Limited
Company Number: 519500
Registered in England
Registered Office: Tesco House, Delamare Road, Cheshunt, Hertfordshire EN8 9SL
VAT Registration Number: GB 220 4302 31


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] ems versus pixels

2010-07-20 Thread David Laakso

Foskett, Mike wrote:

Has anyone on the list considered using keywords?



Mike Foskett


  









Has anyone conceived of a layout for the page using percent, em, /and/ 
pixel width, with the fonts specified in percent [ or em ]  :-) ?


Best,
~d




--

http://chelseacreekstudio.com/



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] ems versus pixels

2010-07-20 Thread michael.brockington
The basic plan that I follow is to use % for structural items, which generally 
need to be proportional to other structural items, and ultimately the viewport 
itself.
Then, pixels purely for borders and images,
And EMs only for text.

Margins and padding can be either pixels, EMs or % depending on the particular 
situation, ie whether you are using them as structural pieces, for text-indent, 
or for decoration.


My argument for this is that if a box has width:50% or 98% or something like 
that, it is immediately obvious when reading the CSS how big it should end up; 
not nearly so obvious with width:43em
At the other end of the scale, if you want a fine line, then what you really 
want is 1px, or 2px for medium etc, not 0.05em or 0.004%, particularly since 
the latter are more likely to be subject to rounding errors.

With text itself, it should then be obvious that EMs are the most appropriate - 
% may work in a very similar way, but there is plenty of scope for confusion 
with percentages used for structural elements.


As for page-zoom, everyone that I have ever heard comment on it, prefers 
text-zoom, myself included.

Regards,
Mike

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] ems versus pixels

2010-07-20 Thread Felix Miata
On 2010/07/20 09:53 (GMT-0400) agerasimc...@unioncentral.com composed:

 I've been converting some of our company public-facing static web-sites 
 from pixels to ems for layout and font-size.
 But just recently I encountered several references that pixels are getting 
 back into popularity - as it offers absolute control over text,  and 
 that most browsers now can resize font based on pixels.

There is no such thing as designer CSS having absolute control over text.
Absent user's browser having designer CSS disregarded entirely, necessary
browser defenses will be applied, for better or not, often resulting in
visitor leaving prematurely.

 Any thoughts/suggestions on whether I should push the effort on converting 
 our sites to ems?

Minimum text size and zoom functions built into browsers were put there to
allow users to defend against bad web design. Absent offense, defense needn't
be applied. It shouldn't need to be applied, first because the web is too old
for bad design to be standard practice, second because it's unnecessary, and
third because it's rude.

Text sized in px completely disregards user preferences. That's an excellent
definition of rude.

In contrast, text sized in em (applied to size text, em is nothing but an
alternative syntax for %) relates to the user's preference. When 1em or 100%
is the result, the user is getting precisely what he prefers, making him a
happy site visitor.

Text containers sized in em, within a range that depends on resolution,
viewport size,  1em size, retain for all practical purposes the proportions
of the original design regardless of the actual sizes used by the designer.
Beyond the range, contraints will cause variance, but usually not cause the
page to be unusable. In contrast, when user defenses force legible text
sizing upon sites sized in px, usability often deteriorates, and sometimes
disappears altogether.

It's often said images should be sized in px because only display at
intrinsic size is acceptable, that deterioration from browser scaling to
non-intrinsic sizes is unacceptable. I'm sure that's true from a
perfectionist designer's point of view.

What is also unacceptable is unscaled images due to a too small intrinsic
size leaving necessary detail undiscernable to the user.

The user impact of scaled vs too small is equivalent quality reduction, but
scaled images have the advantage of preserving the site design's proportions.
-- 
The wise are known for their understanding, and pleasant
words are persuasive. Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



[WSG] stretching of html elements

2010-07-20 Thread Jayachandran Kandasamy
Hi Team,

Is there any idea to overcome the problem when there is content without
blankspace (spaces between words) inside TD / DIV is still expanding though
it has fixed width.

Any suggestions welcome :)

Cheers,
JC


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] link rel=stylesheet question

2010-07-20 Thread Jody Tate
Many thanks to those who respond to the link rel=stylesheet question, 

Best,
jody


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] ems versus pixels

2010-07-20 Thread AGerasimchuk
That sounds like a good solution.  The primary reason we want to switch to 
EMS is for Accessibility and ability to enlarge text via browser's 
settings.  Will using % for structure be able to accomodate the growing 
size of the text accordingly if text is in ems? My understanding is that 
primary structure (like if I have a fixed size of a container in ems 
instead of pixels) will be able to adjust accordinly to text only if it is 
in EMS (elastic ?)  If it is in percentages , it will scale according to 
parent - which is a screen size for a container.  Therefore, I am still 
thinking to using EMS even for structural elements, and px for any static 
border, etc 

I was thrown off by this article where pixels were described as a 
preferred method, so wasn;t sure...
Thanks to everyone!




Anya V.  Gerasimchuk
Web Designer, IT - Web Shared Services
UNIFI Information Technology 
agerasimc...@unioncentral.com
(513) 595 -2391



michael.brocking...@bt.com 
Sent by: li...@webstandardsgroup.org
07/20/2010 11:34 AM
Please respond to
wsg@webstandardsgroup.org


To
wsg@webstandardsgroup.org
cc

Subject
RE: [WSG] ems versus pixels






The basic plan that I follow is to use % for structural items, which 
generally need to be proportional to other structural items, and 
ultimately the viewport itself.
Then, pixels purely for borders and images,
And EMs only for text.

Margins and padding can be either pixels, EMs or % depending on the 
particular situation, ie whether you are using them as structural pieces, 
for text-indent, or for decoration.


My argument for this is that if a box has width:50% or 98% or something 
like that, it is immediately obvious when reading the CSS how big it 
should end up; not nearly so obvious with width:43em
At the other end of the scale, if you want a fine line, then what you 
really want is 1px, or 2px for medium etc, not 0.05em or 0.004%, 
particularly since the latter are more likely to be subject to rounding 
errors.

With text itself, it should then be obvious that EMs are the most 
appropriate - % may work in a very similar way, but there is plenty of 
scope for confusion with percentages used for structural elements.


As for page-zoom, everyone that I have ever heard comment on it, prefers 
text-zoom, myself included.

Regards,
Mike

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


***
This message may contain confidential information intended only
for the use of the addressee(s) named above and may contain
information that is legally privileged. If you are not the
addressee, or the person responsible for delivering it to the
addressee, you are hereby notified that reading, disseminating,
distributing or copying this message is strictly prohibited.  If you
have received this message by mistake, please immediately notify
us by replying to the message and delete the original message
immediately thereafter.  Thank you.
***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

[WSG] Accessibility standards - examples?

2010-07-20 Thread AGerasimchuk
Hello - and another question from me:

Can anyone recommend a good understandable interpretation of 
Accessibility Guidelines 2.0?  I, as a designer/developer, understand 
pretty much most of it (or whatever I need for our company purposes),  but 
we are in process of Defining how we are going to comply with these 
guidelines.  This is difficult as far as discussing those with a group of 
people with different industry knowledge - web architects, managers, 
content editors of Marketing type, and individual developers.  Therefore, 
I need to put together a good solid document stating what we need to do, 
why we need to do that and how we are going to accomplish that.

For example (and this is a bad example :):  What - JavaScript needs to be 
unobtrusive, and the site features need to be accessible with or without 
JavaScript.  Why - in some case if JS is turned off then the site breaks, 
(is there any statistics of how many users turn off JS?) ...How - this 
particular topic has various techniques, so no example here.

Does anyone have a good, solid, detailed by easy to understand/read 
example of such Accessibility compliance standards?  We are an insurance 
company and have never done this before, therefore this is a big start for 
us...
Thank you!
Anya



Anya V.  Gerasimchuk
Web Designer, IT - Web Shared Services
UNIFI Information Technology 
agerasimc...@unioncentral.com
(513) 595 -2391
***
This message may contain confidential information intended only
for the use of the addressee(s) named above and may contain
information that is legally privileged. If you are not the
addressee, or the person responsible for delivering it to the
addressee, you are hereby notified that reading, disseminating,
distributing or copying this message is strictly prohibited.  If you
have received this message by mistake, please immediately notify
us by replying to the message and delete the original message
immediately thereafter.  Thank you.
***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] stretching of html elements

2010-07-20 Thread Russ Weakley

Hi JC,

This is a question where a example would help. It all depends on:

1. the element in question (the TD element operates differently to DIV  
element in many cases)

2. whether sizing has been applied to the element
3. whether positioning had been applied to the element
4. which browser you are referring to (unless it is all browsers)

Here is a long-winded answer...

A DIV is a block level element by nature and will stretch to fit the  
viewport (browser window) or any containing box. As soon as you apply  
float, position: absolute or position: fixed the element MAY  
change in dimension (depending on whether you also add a width/height  
to the element). If no width is applied to a float, absolute or fixed  
width element they naturally tend to shrink-wrap or collapse in width.


The DIV, or any block level element for that matter, is also set to  
overflow:visible as the initial value. This means that an extremely  
long word, if wider than the width of the DIV, will poke out the right  
side of the DIV (assuming you have the default language - left to  
right - ltr).


You can control this behavior using the overflow property. The  
possible values in CSS2.1 are: visible | hidden | scroll | auto |  
inherit. For example:


div { overflow: visible; } /* will show any content regardless of  
whether it's wider or deeper than the element */
div { overflow: hidden; } /* will hide (cut off) any content that is  
wider or deeper than the element */
div { overflow: scroll; } /* will add horizontal and vertical scroll  
bars to the right and bottom of the element */
div { overflow: auto; }  /* will add a scroll bar to the affected axis  
of the element */


A TD element is quite different.

Unlike a block level element they naturally collapse in height and  
width. You can change this - giving them a set width or stretching  
them. They have one other unique characteristic. If you set a width on  
a TD and the content is wider than the applied width, the content will  
not flow outside the TD element (it will not overflow). Instead, the  
TD will expand to suit the needs of the content. You cannot apply  
overflow to a TD.


So are there any solutions? Well, CSS3 offers two properties that may  
be of use... word-wrap and word-break. Keep in mind that milage  
may vary. Safari and Internet Explorer support both of these  
properties. Firefox seems to support word-wrap but not word-break.  
Opera does not seem to support either.


Here super-quick is a test case for you:
http://www.maxdesign.com.au/jobs/html-tests/property-wordwrap.htm

HTH
Russ


On 21/07/2010, at 2:58 AM, Jayachandran Kandasamy wrote:


Hi Team,

Is there any idea to overcome the problem when there is content  
without blankspace (spaces between words) inside TD / DIV is still  
expanding though it has fixed width.


Any suggestions welcome :)

Cheers,
JC

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] ems versus pixels

2010-07-20 Thread David Hucklesby

On 7/20/10 8:25 AM, David Laakso wrote:

Foskett, Mike wrote:

Has anyone on the list considered using keywords?

Mike Foskett


Has anyone conceived of a layout for the page using percent, em,
/and/ pixel width, with the fonts specified in percent [ or em ] :-)
?

Best, ~d


Eric seems to have done so:
http://meyerweb.com/eric/thoughts/2005/11/09/multi-unit-any-order-columns/

:-D

FWIW - Even for a fixed width design I'd use percents for inner block
widths. Not only because it makes future changes for newer devices
easier, but it happens to be the way I think about layout, that is, in
proportions.

As for font-size, I see little need to change the browser defaults,
except, perhaps, smaller for subsidiary text, and larger for items of
special importance. For these I currently do use keywords, Mike, as they
seem more consistent cross-browser (ignoring IE 5). But IE 6 gets
percents as it is a bit funky where keywords are concerned.

But that's me. I think browser defaults follow typographic conventions
used in print reasonably well. But then, I know just enough about those
conventions to know that my own choices are likely to be worse rather
than an improvement...

Cordially,
David
--


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] ems versus pixels

2010-07-20 Thread David Laakso

David Hucklesby wrote:

On 7/20/10 8:25 AM, David Laakso wrote:

Foskett, Mike wrote:

Has anyone on the list considered using keywords?

Mike Foskett


Has anyone conceived of a layout for the page using percent, em,
/and/ pixel width, with the fonts specified in percent [ or em ] :-)
?

Best, ~d


Eric seems to have done so:
http://meyerweb.com/eric/thoughts/2005/11/09/multi-unit-any-order-columns/ 



Cordially,
David






Yes, Eric -- among others ...
http://www.gunlaug.no/tos/moa_12a.html

Best,
~d


--
http://chelseacreekstudio.com/



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] ems versus pixels

2010-07-20 Thread tee
EM can fail miserably in below senario for IEs for p, li and span tags due to 
inheritance making them very tiny and unable to get consistence font size for 
one block of content in different browsers not just the IE.

body {font-size: 100.1%}
p, li {font-size: 0.95em}
span  {font-size: 0.9em}

pspanspanxxxspanspan/p

divspanspanspanxxx/spanspanspan/div

ul
lispansome text
some more texts depend on  situation span
spanextra more texts depend on above situation 
/spanspanspanli
li div spanxxx/span/div/li
li 
ullidiv psome text 
spansome more texts 
spanextra more texts depend on above situation /span
/span
p/div/liul
/li
/ul

You might question what kind of developer would code such markups, if you have 
this question, chances are, you have not done layout for sites that how content 
being pulled largely depend on how users user the website.

I used to use EM only for font size, something I learned from this list. It was 
time when you are new, you have no your opinion and know nothing about 
exception that some fine ivory tower idea cannot withstand real world practise 
but followed others , The first time I saw 
spanspanspanxxx/spanspanspan from a project I did for a social 
networking site, I changed them, and used EM for font size, the programmer 
changed my hard work back and I was very resentful my web-standards compliant 
work got chopped off so brutally with no explanation ever given.

It took me a few years to understand why the programmer did what he did.

adding these do not solved the problem
span span {font-size: 1.2em}
span span span {font-size:1.3em}
li li span  {font-size:1.2em}


tee

On Jul 20, 2010, at 8:27 AM, michael.brocking...@bt.com 
michael.brocking...@bt.com wrote:

 The basic plan that I follow is to use % for structural items, which 
 generally need to be proportional to other structural items, and ultimately 
 the viewport itself.
 Then, pixels purely for borders and images,
 And EMs only for text.
 
 Margins and padding can be either pixels, EMs or % depending on the 
 particular situation, ie whether you are using them as structural pieces, for 
 text-indent, or for decoration.
 
 
 My argument for this is that if a box has width:50% or 98% or something like 
 that, it is immediately obvious when reading the CSS how big it should end 
 up; not nearly so obvious with width:43em
 At the other end of the scale, if you want a fine line, then what you really 
 want is 1px, or 2px for medium etc, not 0.05em or 0.004%, particularly since 
 the latter are more likely to be subject to rounding errors.
 
 With text itself, it should then be obvious that EMs are the most appropriate 
 - % may work in a very similar way, but there is plenty of scope for 
 confusion with percentages used for structural elements.
 
 
 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] ems versus pixels

2010-07-20 Thread Scott Elcomb
On Tue, Jul 20, 2010 at 9:52 PM, tee weblis...@gmail.com wrote:
snip
 I used to use EM only for font size, something I learned from this list. It 
 was time when you are new, you have no your opinion and know nothing about 
 exception that some fine ivory tower idea cannot withstand real world 
 practise but followed others , The first time I saw 
 spanspanspanxxx/spanspanspan from a project I did for a social 
 networking site, I changed them, and used EM for font size, the programmer 
 changed my hard work back and I was very resentful my web-standards compliant 
 work got chopped off so brutally with no explanation ever given.

 It took me a few years to understand why the programmer did what he did.

Out of curiosity, and as a programmer, why did the programmer change
your work.  You suggest that you figured it out without an
explanation...

-- 
  Scott Elcomb
  http://www.psema4.com/   @psema4

  Member of the Pirate Party of Canada
  http://www.pirateparty.ca/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] ems versus pixels

2010-07-20 Thread Mathew Robertson
On 21 July 2010 11:52, tee weblis...@gmail.com wrote:

 EM can fail miserably in below senario for IEs for p, li and span tags due
 to inheritance making them very tiny and unable to get consistence font size
 for one block of content in different browsers not just the IE.

 body {font-size: 100.1%}
 p, li {font-size: 0.95em}
 span  {font-size: 0.9em}

 [snipped]

As a general rule, you shouldn't be putting any font-size in tags, as that
will frequently suffer inheritance problems.  This general-rule applies to
most attributes on most tags.  The one example where this may not apply, is
when defining a reset.

Instead, you should be targeting your styles, using #id, .class or
derived-selectors - this helps to avoid most inheritance problems and saves
your sanity.

regards,
Mathew Robertson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] ems versus pixels

2010-07-20 Thread Josh Godsiff

Yup. Check out http://nican.com.au/

On 21/7/2010 1:25 AM, David Laakso wrote:

Foskett, Mike wrote:

Has anyone on the list considered using keywords?



Mike Foskett











Has anyone conceived of a layout for the page using percent, em, /and/ 
pixel width, with the fonts specified in percent [ or em ]  :-) ?


Best,
~d







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] ems versus pixels

2010-07-20 Thread tee
 
On Jul 20, 2010, at 7:10 PM, Mathew Robertson wrote:

 On 21 July 2010 11:52, tee weblis...@gmail.com wrote:
 EM can fail miserably in below senario for IEs for p, li and span tags due to 
 inheritance making them very tiny and unable to get consistence font size for 
 one block of content in different browsers not just the IE.
 
 body {font-size: 100.1%}
 p, li {font-size: 0.95em}
 span  {font-size: 0.9em}
 
 [snipped]
 
 As a general rule, you shouldn't be putting any font-size in tags, as that 
 will frequently suffer inheritance problems.  This general-rule applies to 
 most attributes on most tags.  The one example where this may not apply, is 
 when defining a reset.

That was just a quick example to illustrate the problem using EM unit when a 
layout has a span (class) 3 level deep or a li 2 level deep. It doesn't matter 
whether the font size is declare in a type selector or a class. The general 
rule that you may stick with, will still fail miserably.

Let me make an example and partially answer Scott's question.
In a eCommerce site, price is showed everywhere in a page, and pricing info are 
stored in one template, we have regular price show in the product listing, in 
cart report, in best selling product block, in recently view product block, in 
checkout, in invoice, in quick report etc etc; then we also have as low as 
together with regular price, suggested price vs our price, or from x 
price to y price. The price maybe wrapped in a p, a div, a li, a td, a dd 
tag, and it can be 2, 3 or 4 level deep of other tags,  with so many variations 
and no matter where the pricing will be showed, the font size of the pricing 
must be consistent with the rest of the content where the block is, or it maybe 
that all pricing, no matter where they get shows up, have to be the same font 
size. Under these condition, whether I have 

span {font-size:0.9em}

or

.price {font-size:0.9em}

make no differences as far as how it fails in some browsers.


If {font-size:0.9em} change to {font-size:12px}, I will  be getting 
consistent font-size if it needs to be exact the same font size no matter where 
it shows up.

Using the same pixel unit, with extra rule, I can also get the pricing info's 
font-size be consistent with the rest of text in the same block of content.

Using EM, all I get is headache and madness to try to make something show up 
consistently in the same block of content within the same browser -- this was 
the reason the programmer changed my code back. He needed something be absolute 
consistent, and a chunk of code that can be inserted in any part of the content.

tee







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


Re: [WSG] stretching of html elements

2010-07-20 Thread Jayachandran Kandasamy
Hi Russ,

I tried these CSS 3 properties and tested in the IE7 and Mozilla FF 3.6.6
browser, they are not helping is there any special hacks available to
overcome this problem

Thanks for your immediate response and article link you have given me.

Cheers,
JC

On Wed, Jul 21, 2010 at 5:15 AM, Russ Weakley r...@maxdesign.com.au wrote:

 Hi JC,

 This is a question where a example would help. It all depends on:

 1. the element in question (the TD element operates differently to DIV
 element in many cases)
 2. whether sizing has been applied to the element
 3. whether positioning had been applied to the element
 4. which browser you are referring to (unless it is all browsers)

 Here is a long-winded answer...

 A DIV is a block level element by nature and will stretch to fit the
 viewport (browser window) or any containing box. As soon as you apply
 float, position: absolute or position: fixed the element MAY change in
 dimension (depending on whether you also add a width/height to the element).
 If no width is applied to a float, absolute or fixed width element they
 naturally tend to shrink-wrap or collapse in width.

 The DIV, or any block level element for that matter, is also set to
 overflow:visible as the initial value. This means that an extremely long
 word, if wider than the width of the DIV, will poke out the right side of
 the DIV (assuming you have the default language - left to right - ltr).

 You can control this behavior using the overflow property. The possible
 values in CSS2.1 are: visible | hidden | scroll | auto | inherit. For
 example:

 div { overflow: visible; } /* will show any content regardless of whether
 it's wider or deeper than the element */
 div { overflow: hidden; } /* will hide (cut off) any content that is wider
 or deeper than the element */
 div { overflow: scroll; } /* will add horizontal and vertical scroll bars
 to the right and bottom of the element */
 div { overflow: auto; }  /* will add a scroll bar to the affected axis of
 the element */

 A TD element is quite different.

 Unlike a block level element they naturally collapse in height and width.
 You can change this - giving them a set width or stretching them. They have
 one other unique characteristic. If you set a width on a TD and the content
 is wider than the applied width, the content will not flow outside the TD
 element (it will not overflow). Instead, the TD will expand to suit the
 needs of the content. You cannot apply overflow to a TD.

 So are there any solutions? Well, CSS3 offers two properties that may be of
 use... word-wrap and word-break. Keep in mind that milage may vary.
 Safari and Internet Explorer support both of these properties. Firefox seems
 to support word-wrap but not word-break. Opera does not seem to support
 either.

 Here super-quick is a test case for you:
 http://www.maxdesign.com.au/jobs/html-tests/property-wordwrap.htm

 HTH
 Russ



 On 21/07/2010, at 2:58 AM, Jayachandran Kandasamy wrote:

 Hi Team,

 Is there any idea to overcome the problem when there is content without
 blankspace (spaces between words) inside TD / DIV is still expanding though
 it has fixed width.

 Any suggestions welcome :)

 Cheers,
 JC

 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***




 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***