[WSG] style issue in blackberry
HI ,
I am developing a sire for blackberry. I have a rounded corner button style for
all the buttons. I have used the sliding door technic for this.
the xhtml + styles for my button is like this
a href=# class=buttonspan submit/span/a
.button { background:transparent url(../images/buttons.png) no-repeat scroll
left -32px; color:#FF; font-size:0.50em;font-weight:bold;padding:0 0 0
10px ; text-transform:uppercase; height:30px;cursor:pointer;border:none;
line-height:30px;float:left;}
.button span { background:transparent url(../images/buttons.png) no-repeat
scroll right -69px; height:30px;line-height:30px;float:left; text-align:left;
width:70px;}
on normal view buttons looks like broken. but when I use the zoom in option,
button looks perfect. Is there any way to see the button style correctly in
the normal view in blackberry.
has anybody came across such issues before. pls help.
how do I fix this issue.
Thanks Regards
--
Naveen Bhaskar
Bangalore, India.
***
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
It's still a bit hard to tell without seeing an example. Can you send a link to a cut down version of what the problem is? Thanks Russ On 21/07/2010, at 3:31 PM, Jayachandran Kandasamy wrote: 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 *** 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 ***
