Re: [WSG] stretching of html elements

[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  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
***

Re: [WSG] ems versus pixels

[tee]

 
On Jul 20, 2010, at 7:10 PM, Mathew Robertson wrote:

> On 21 July 2010 11:52, tee  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] ems versus pixels

[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

[Mathew Robertson]

On 21 July 2010 11:52, tee  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

[Scott Elcomb]

On Tue, Jul 20, 2010 at 9:52 PM, tee  wrote:

> 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 
> "xxx" 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

[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}

xxx

xxx


some text
some more texts depend on  situation 
extra more texts depend on above situation 

  xxx
 
 some text 
some more texts 
extra more texts depend on above situation 





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 
"xxx" 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,  
 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

[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 ...


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

[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] stretching of html elements

[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
***

[WSG] Accessibility standards - examples?

[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] ems versus pixels

[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



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


To

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
***

Re: [WSG] link rel="stylesheet" question

[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
***

[WSG] stretching of html elements

[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] ems versus pixels

[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
***

RE: [WSG] ems versus pixels

[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

[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

[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,  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

[Jason Arnold]

On Tue, Jul 20, 2010 at 9:59 AM, David Laakso
 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

[Dan Freeman]

Points?  I thought points were for print and should never be used:

http://webdesign.about.com/cs/typemeasurements/a/aa042803a.htm

http://css-tricks.com/css-font-size/



Dan Freeman
Webmaster & ERP Administrator
800.650.6506 (TOLL FREE)
330.655.0341 (DIRECT)
www.lexi.com

-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On
Behalf Of David Laakso
Sent: Tuesday, July 20, 2010 11:00 AM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] ems versus pixels

Phil Archer wrote:
>  Ems are proportional to the size of text you're using - and that's 
> generally the thing you want to be proportional to.
>
> Phil.
>
> Edward Lynn wrote:
>>  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,  wrote:
>>
>>> Hi,
>>>
>>> I've been converting some of our company public-facing static
web-sites
>>> from pixels to ems for layout and font-size.
>>>
>>> Anya Gerasimchuk
>>>
>>>
>







Points is the way to go nowadays :-) .

Best,
~d




-- 
http://chelseacreekstudio.com/



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


LEXI-COMP CONFIDENTIALITY NOTICE
The information in this electronic mail is intended for the named 
recipients only.  Any use of this information by anyone other than 
the intended receiver is prohibited.  If the reader of this message is
not the intended recipient, you are hereby notified that any 
dissemination, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.  If you have received this 
message in error, please notify the sender immediately by replying 
to this electronic e-mail or by calling 330-650-6506.  Please delete 
it from your computer.  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

[David Laakso]

Phil Archer wrote:
 Ems are proportional to the size of text you're using - and that's 
generally the thing you want to be proportional to.


Phil.

Edward Lynn wrote:

 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,  wrote:


Hi,

I've been converting some of our company public-facing static web-sites
from pixels to ems for layout and font-size.

Anya Gerasimchuk












Points is the way to go nowadays :-) .

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

[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  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,  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

[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,  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

[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,  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
***

[WSG] ems versus pixels

[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
***