Re: [WSG] ems versus pixels
On Jul 21, 2010, at 7:43 AM, David Hucklesby wrote:
With all due respect, I suggest you are attempting to control the
uncontrollable far too finely. 0.9em is either one or two pixels smaller
than default, depending on the rounding applied by the browser. In other
words, you are already getting as much difference between browsers as
you are trying to apply.
This does not eliminate the inheritance issue I raised. Even if I use 15em in
my example for span class, the problem still exist.
I am not advocating not to use EM, and I am not advocating using Pixel only. I
use EM 90% of the time, 10% of the time Pixel could be a far better approach
for font size. Anybody who advocating the use of EM only and preach other do so
(especially to those who are new to Pixel Vs EM or new to web design in
general), IMO, should make people aware there are exception to the rule, that
in some situations, EM may not be a better choice due to inheritance, and in
some special case when consistency cannot be compromised (this is very common
if the design is done by a pixel-obsessed designer).
obviously there's a little more work involved with ems (although it
didn't take me long to fix things), but you have to agree your example
is a little contrived.
The example I showed, was not contrived. It's quite common for some complicated
layouts which are template based, where content get pulled in based on how
user uses the site or how the site owner does the configuration from backend. I
cannot tell you which social networking site I partially coded (that has the
similar markup as in my example) due to NDA even though I no longer work for
that company, but if you are interested to find out what kind of template based
sites have similar markup, and that it's very hard to change due to the
upgradability issue and other issues related to budget or client wishes, go try
out Magento, download a free theme, play with it, try change the messy markup
in every phtml template to semantical markup, play with it even more for a
couple update version, you may get a bit different perspective a year later.
Now this is contrived and extreme case, likely you won't be doing this but
inexperienced web designer may get into this if he/she is told to use EM only
but was not told there are exception to the rule.
http://greensho.nexcess.net/em-vs-px/ie6.png
http://greensho.nexcess.net/em-vs-px/ie7.png
http://greensho.nexcess.net/em-vs-px/ie8.png
http://greensho.nexcess.net/em-vs-px/ie9.png
http://greensho.nexcess.net/em-vs-px/chrome.png
http://greensho.nexcess.net/em-vs-px/safari.png
This is a more realistic result for experienced web designer:
http://greensho.nexcess.net/em-vs-px/fontsizes.png
http://greensho.nexcess.net/em-vs-px/example1.png
http://greensho.nexcess.net/em-vs-px/example2.png
Yet with so many rules written, one still cannot get consistent font size
within one paragraph
#content div span, #content span {font-size: 1.125em}
#content p span, #content li span, #content li div span {font-size: 0.75em}
#content p span span, #content span span, #content span span span, #content
li span span, #content li span span
span, li div, #content li div p, #content li li div p, #content li li
{font-size: 1em}
In a case like this, shouldn't the 10% exception works better, more effective
and productive (there is a different between it doesn't take long to solve
and one that takes less than a minute or less to write and get a consistent
result across browsers)?
#content-alt p, li {font-size: 24px}
#content-alt span {font-size: 18px}
The only issue I see using pixel that may cause problem is mobile devices, but
we have media queries and handheld style sheet to take care of it don't we?
Now that we are in the hype for CSS3 and the power of @font-face allows us to
use many fancy fonts, this inheritance for font size using EM may complicate
the issue a bit more.
In example2 (I admit not a very good example to present the @font-face issue
with font size inheritance one may run into as I have not used too many open
type fonts yet, and Museo is the one I use most and is currently available in
my server), you see that in IE6 and 7, where Lucida Sans is used because the
two browsers have no support for @font-face , the differences are much bigger
with Lucida Sans comparing the example1 where Arial is used.
A more thorough web designer and one who has control over what font face can be
used may get rid of Museo and Lucida Sans and serve Arial only for older IEs,
yet this still does not solved the inheritance issue if a site requires
consistent font size within a block of content, a paragraph where span tag is
used and is wrapped inside other tags, or if a client insists on using a Lucida
Sans or a typeface that result something similar to Lucida Sans.
tee
***
List Guidelines:
Re: [WSG] ems versus pixels
On 7/22/10 7:13 AM, tee wrote: On Jul 21, 2010, at 7:43 AM, David Hucklesby wrote: With all due respect, I suggest you are attempting to control the uncontrollable far too finely. 0.9em is either one or two pixels smaller than default, depending on the rounding applied by the browser. In other words, you are already getting as much difference between browsers as you are trying to apply. This does not eliminate the inheritance issue I raised. Even if I use 15em in my example for span class, the problem still exist. I am not advocating not to use EM, and I am not advocating using Pixel only. I use EM 90% of the time, 10% of the time Pixel could be a far better approach for font size. Anybody who advocating the use of EM only and preach other do so (especially to those who are new to Pixel Vs EM or new to web design in general), IMO, should make people aware there are exception to the rule, that in some situations, EM may not be a better choice due to inheritance, and in some special case when consistency cannot be compromised (this is very common if the design is done by a pixel-obsessed designer). I think you may have missed my point. I do agree that it's silly to suggest that one technique or another is universally the best. I am trained as an engineer, and believe that design--even of a website--is a matter of compromise. So your point about pixels versus points versus ems etc. is well taken. The case I tried to make is that I see no reason to have more than a couple or three font sizes on any one page. For me, a page full of text of varying sizes is distracting and difficult to interpret. I would also have the same reaction to a printed page full of varied type size. But I do sympathize with your situation, having to deal with lousy markup you have no control over. To my engineering brain, the markup is the structure upon which page is built. If the structure is faulty, no amount of paper and paint over the top will create a sound result. Good luck with your struggles. 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
On 7/20/10 9:58 PM, tee wrote:
On Jul 20, 2010, at 7:10 PM, Mathew Robertson wrote:
On 21 July 2010 11:52, tee weblis...@gmail.com
mailto: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.
[example snipped]
With all due respect, I suggest you are attempting to control the
uncontrollable far too finely. 0.9em is either one or two pixels smaller
than default, depending on the rounding applied by the browser. In other
words, you are already getting as much difference between browsers as
you are trying to apply.
I suggest you not attempt to make such minuscule adjustments to
font-size; set a size for a container or class and leave it at that. For
the most part I find browser default sizes good, with only a couple of
variations on a page (for more or less important content.)
Anyway, that's how I have managed to preserve my hair. Hopefully it can
help you.
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
On Tue, Jul 20, 2010 at 11:58 PM, tee weblis...@gmail.com wrote:
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
A lot of whether or not you use EMs vs Pixels is going to depend a lot
on what the structure of your content looks like and how well you know
what that the structure is going to be consistent. Even with your
example I was able to get the EMs and Pixel versions to look exactly
the same (using Chrome, IE may need some minor tweeks but it should
look okay there too).
Pixel code:
style
p, li {font-size: 24px}
span {font-size: 18px}
/style
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
Ems code:
style
body {font-size: 100%}
p, li {font-size: 1.5em}
div span, span {font-size: 1.125em}
p span, li span, li div span {font-size: 0.75em}
p span span, span span, span span span, li span span, li span span
span, li div, li div p, li li div p, li li {font-size: 1em}
/style
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
obviously there's a little more work involved with ems (although it
didn't take me long to fix things), but you have to agree your example
is a little contrived. If you're content looks this horrible then my
sympathies, because you're gonna have a heck of a time styling the
layout for any document that is this poorly structured let alone
figuring out the typography. It all just goes back to writing
semantically good content and utilizing web standards and you should
be able to use ems just fine.
--
Jason Arnold
Re: [WSG] ems versus pixels
I agree - I usually set just the body font for something like 95%, and
then the container font for 1em. I don't setup anything else, except if I
need something different for some .classes or #ids.
Is that a good solution?
Anya V. Gerasimchuk
Web Designer, IT - Web Shared Services
UNIFI Information Technology
agerasimc...@unioncentral.com
(513) 595 -2391
David Hucklesby huckle...@gmail.com
Sent by: li...@webstandardsgroup.org
07/21/2010 10:52 AM
Please respond to
wsg@webstandardsgroup.org
To
wsg@webstandardsgroup.org
cc
Subject
Re: [WSG] ems versus pixels
On 7/20/10 9:58 PM, tee wrote:
On Jul 20, 2010, at 7:10 PM, Mathew Robertson wrote:
On 21 July 2010 11:52, tee weblis...@gmail.com
mailto: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.
[example snipped]
With all due respect, I suggest you are attempting to control the
uncontrollable far too finely. 0.9em is either one or two pixels smaller
than default, depending on the rounding applied by the browser. In other
words, you are already getting as much difference between browsers as
you are trying to apply.
I suggest you not attempt to make such minuscule adjustments to
font-size; set a size for a container or class and leave it at that. For
the most part I find browser default sizes good, with only a couple of
variations on a page (for more or less important content.)
Anyway, that's how I have managed to preserve my hair. Hopefully it can
help you.
Cordially,
David
--
***
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] ems versus pixels
On 2010/07/21 11:47 (GMT-0400) agerasimc...@unioncentral.com composed: I agree - I usually set just the body font for something like 95%, and then the container font for 1em Is that a good solution? Almost. 95% on body is telling users they've screwed up choosing their browsers' default sizes by choosing a size that's too big for their own needs or taste. You have no idea what theirs are, nor do you know they haven't already set DejaVu Sans, Verdana or Arial as default family to bias text larger than the typical serif defaults. http://www.dev-archive.net/articles/font-analogy.html -- 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] ems versus pixels
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
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
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
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
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
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
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
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
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
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 ***
Re: [WSG] ems versus pixels
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
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
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
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
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
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
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
***
