Re: [css-d] help with menu bar
thanks for help..i found the problem..the #header container had an explicit height set On Thu, Mar 13, 2014 at 6:56 PM, Tom Livingston tom...@gmail.com wrote: Sent from my iPhone On Mar 13, 2014, at 4:53 PM, Brian Jones bdotjo...@gmail.com wrote: Inside header, div class=col-md-9 col-sm-12 at small widths is being told to be 12 cols wide, which is too wide next to your logo - which is also being told to be 12col wide - so it drops down i fixed the submenu issue by removing the width:170px; http://jsfiddle.net/dTsrY/5/ i dont mind that the menu drops down..i just want the menu to still be above the shadow border (div class=row top-shadow/div) Can't look right now. Is there an explicit hight set on that div? On Thu, Mar 13, 2014 at 3:23 PM, Tom Livingston tom...@gmail.com wrote: On Thu, Mar 13, 2014 at 10:47 AM, Brian Jones bdotjo...@gmail.com wrote: Hi, I have this demo setup here http://jsfiddle.net/dTsrY/ and i need help with a few issues that i am having. I am using bootstrap 3.0 and when the page gets smaller the menu moves outside of the bottom shadow image border and i would like for it to stay inside the border. Inside header, div class=col-md-9 col-sm-12 at small widths is being told to be 12 cols wide, which is too wide next to your logo - which is also being told to be 12col wide - so it drops down Also, the width of the submenu is longer than the hover for the items in the submenu, so when you hover a submenu item there is extra white space to the right. ul.sub-menu has a width of 200px (see ul#mainnav li ul - line 279) and also is getting padding right (line 422). I guess that's too wide for the parent. Thanks in advance for any help. -- Hope this helps. -- Tom Livingston | Senior Front-End Developer | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com -- -bdot There are only 10 kinds of people in this world. Those who understand binary and those who don't -- -bdot There are only 10 kinds of people in this world. Those who understand binary and those who don't __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] iOS Safari and multiple fixed backgrounds
List,
I have a page with multiple divs that have fixed backgrounds. This
isn't working in iOS Safari or iOS Chrome. Actually, not even a single
div with a fixed background is working. In desktop appears to work
fine.
The CSS rule I am using is:
.myDiv{background: fixed url(../img/careers/careers-header-bg.jpg) 50%
0 no-repeat;}
Some Googling produced nothing that will help.
Anyone have any ideas? Anyone know if there's a trick to this?
Thanks
--
Tom Livingston | Senior Front-End Developer | Media Logic |
ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] iOS Safari and multiple fixed backgrounds
Den 14.03.2014 16:55, skrev Tom Livingston: List, I have a page with multiple divs that have fixed backgrounds. This isn't working in iOS Safari or iOS Chrome. Actually, not even a single div with a fixed background is working. In desktop appears to work fine. Read somewhere - a long time ago - that many browsers don't support anything fixed on small devices, because of the problems it unintentionally may cause. Also too easy to intentionally mess things up with fixed. regards Georg __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] SASS or LESS
Hey everyone, Just wondering if there is a good place for tutorials to learn SASS or LESS? And which one would be better to dive into? Thanks in advance everyone, Vince Sent from my iPhone __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] iOS Safari and multiple fixed backgrounds
Sent from my iPhone On Mar 14, 2014, at 12:11 PM, Georg ge...@gunlaug.com wrote: Den 14.03.2014 16:55, skrev Tom Livingston: List, I have a page with multiple divs that have fixed backgrounds. This isn't working in iOS Safari or iOS Chrome. Actually, not even a single div with a fixed background is working. In desktop appears to work fine. Read somewhere - a long time ago - that many browsers don't support anything fixed on small devices, because of the problems it unintentionally may cause. Also too easy to intentionally mess things up with fixed. Can u give an example of intentionally mess things up? regards Georg __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] SASS or LESS
Both sass-lang.com and lesscss.org have pretty good tutorials right on their site. Best way to learn is right there. FWIW, I'm partial to less, but that's probably just because I've been using it for quite a while. I found getting started to be ridiculously easy. I just started by renaming my .CSS file to .LESS and compiling it, a legal CSS file with pass through perfectly. Then I started cleaning things up, adding tweaks, and so on until I had eventually worked through the whole thing. Can't imagine going back... On 3/14/14 9:38 AM, Vince Mendella vi...@graymatterstudios.ca wrote: Just wondering if there is a good place for tutorials to learn SASS or LESS? And which one would be better to dive into? __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] SASS or LESS
Sent from my iPhone On Mar 14, 2014, at 12:38 PM, Vince Mendella vi...@graymatterstudios.ca wrote: Hey everyone, Just wondering if there is a good place for tutorials to learn SASS or LESS? And which one would be better to dive into? May be 'holy war' territory. A lot is personal preference but IMO there's a bigger pool of resources for SASS. See http://sass-lang.com Thanks in advance everyone, Vince HTH Sent from my iPhone __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] SASS or LESS
Hi , I too am currently learning SASS , i use treehouse , as I’m a member already , the module is taught buy the guy who created SASS .. and has little code challenges along the way so you know at least some of it is sinking in =) give it a try if you like .. Carl On 14 Mar 2014, at 16:54, Tom Livingston tom...@gmail.com wrote: Sent from my iPhone On Mar 14, 2014, at 12:38 PM, Vince Mendella vi...@graymatterstudios.ca wrote: Hey everyone, Just wondering if there is a good place for tutorials to learn SASS or LESS? And which one would be better to dive into? May be 'holy war' territory. A lot is personal preference but IMO there's a bigger pool of resources for SASS. See http://sass-lang.com Thanks in advance everyone, Vince HTH Sent from my iPhone __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] iOS Safari and multiple fixed backgrounds
Hey Tom,
Did you see this support chart:
http://www.quirksmode.org/css/backgrounds-borders/mobile.html
There appear to be some hacks, with one from 2012 referenced here:
http://stackoverflow.com/a/13337504/1108292
And what could potentially be a starting point for a polyfill:
http://stackoverflow.com/a/14115437/1108292
And, finally, this post tries to explain why position:fixed is unreliable
in iOS (and Android):
http://webreflection.blogspot.co.nz/2009/09/css-position-fixed-solution.html
Hope it helps.
On Fri, Mar 14, 2014 at 11:55 AM, Tom Livingston tom...@gmail.com wrote:
List,
I have a page with multiple divs that have fixed backgrounds. This
isn't working in iOS Safari or iOS Chrome. Actually, not even a single
div with a fixed background is working. In desktop appears to work
fine.
The CSS rule I am using is:
.myDiv{background: fixed url(../img/careers/careers-header-bg.jpg) 50%
0 no-repeat;}
Some Googling produced nothing that will help.
Anyone have any ideas? Anyone know if there's a trick to this?
Thanks
--
Tom Livingston | Senior Front-End Developer | Media Logic |
ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
--
Chris Rockwell
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] SASS or LESS
So true. Suggest to the OP that you google SASS vs LESS and read some of the latest articles. Here's a great one: http://flippinawesome.org/2014/01/20/less-vs-sass-its-time-to-switch-to-sas s/ Like many web articles, it's less about the article itself than it is about the comments. Lots of good feedback on the difference between the two, and which works best in which environment. On 3/14/14 9:54 AM, Tom Livingston tom...@gmail.com wrote: May be 'holy war' territory. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Do modern mobile browsers deliberately ignore font size?
mar 14 2014 00:24 L. David Baron dba...@dbaron.org: On Sunday 2014-03-09 21:52 +0100, Ezequiel Garzón wrote: Is this font boosting/inflation? It sounds like it is. Could it be that only certain android versions are affected? I’ve never encountered this issue on any platform before. I also have never heard of it. Maybe the context and/or the specific rules affect the outcome? __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] iOS Safari and multiple fixed backgrounds
On Fri, Mar 14, 2014 at 1:18 PM, Chris Rockwell ch...@chrisrockwell.com wrote: Hey Tom, Did you see this support chart: http://www.quirksmode.org/css/backgrounds-borders/mobile.html There appear to be some hacks, with one from 2012 referenced here: http://stackoverflow.com/a/13337504/1108292 And what could potentially be a starting point for a polyfill: http://stackoverflow.com/a/14115437/1108292 And, finally, this post tries to explain why position:fixed is unreliable in iOS (and Android): http://webreflection.blogspot.co.nz/2009/09/css-position-fixed-solution.html Hope it helps. -- Chris Rockwell Hi Chris, Thanks. I did see those. The last link you posted above talks about position:fixed in terms of, for example, a fixed navbar at the top of a page. What I'm after is a fixed background image applied to a div. Now technically, that may be the same thing and in my limited knowledge I just don't realize it, but I would think these are two different things. In the end, I'll go with what I thought and that's 'no, you can't do that', and just code my MQs accordingly. Georg, I remember reading something a while back as well, but the way things change in this biz, you never know if someone figured out a way around it. Thanks. -- Tom Livingston | Senior Front-End Developer | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Do modern mobile browsers deliberately ignore font size?
[ cc:ing list again, with Ezequiel Garzón's permission ] On Friday 2014-03-14 10:36 +0100, Ezequiel Garzón wrote: Is this font boosting/inflation? It sounds like it is. Thanks for the feedback, David. I don't mean to extend this thread ad infinitum, but it's basically the core of my question to this list. Doesn't a feature named font inflation, which basically decides what's the best size for a given chunk of text, break CSS badly? If this is the industry trend I wouldn't be surprised to see major browsers apply font boosting even with the meta tag, etc. What's next? Font wisdom, where the browser chooses font family, color, weight, etc., ignoring all the styling? I wish browsers spent more time on making CSS-free content look better, improving their defaults (tables come quickly to mind), instead of ignoring CSS declarations. The alternative to font inflation is substantially worse. Mobile browsers give you a viewport in which you can pan and zoom around a desktop-size viewport of the page. This feature exists for compatibility, to allow mobile Web browsers to view Web pages designed before good mobile Web browsers existed, or designed without considering them. If you've considered mobile in your design, you can use a meta viewport in your page to opt out of parts or all of this behavior. Some Web pages contain text that the user wants to read, and to do this, and in cases where these dual viewports exist, the user needs to zoom in to make the text a decent size. If, at that zoom level where the font is readably large, the user needs to scroll side to side to reach *each line* of the text, because the width of the block is wider than the device. This is a horrible experience. Font inflation exists to solve only this problem, which is a problem that fundamentally would make mobile Web browsers unusable. It doesn't happen if pages declare a meta viewport that means there's no viewport scaling involved, and it doesn't happen if all their blocks are narrow enough to be readable without side-to-side scrolling for each line. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Do modern mobile browsers deliberately ignore font size?
The alternative to font inflation is substantially worse. Mobile browsers give you a viewport in which you can pan and zoom around a desktop-size viewport of the page. This feature exists for compatibility, to allow mobile Web browsers to view Web pages designed before good mobile Web browsers existed, or designed without considering them. If you've considered mobile in your design, you can use a meta viewport in your page to opt out of parts or all of this behavior. Some Web pages contain text that the user wants to read, and to do this, and in cases where these dual viewports exist, the user needs to zoom in to make the text a decent size. If, at that zoom level where the font is readably large, the user needs to scroll side to side to reach *each line* of the text, because the width of the block is wider than the device. This is a horrible experience. Font inflation exists to solve only this problem, which is a problem that fundamentally would make mobile Web browsers unusable. It doesn't happen if pages declare a meta viewport that means there's no viewport scaling involved, and it doesn't happen if all their blocks are narrow enough to be readable without side-to-side scrolling for each line. -David -- 턞 L. David Baron http://dbaron.org I'd go along with this except... You say Font inflation exists to solve only this problem, which is a problem that fundamentally would make mobile Web browsers unusable. It doesn't happen if pages declare a meta viewport. The OP's page here: http://81.4.104.136/fonts.html doesn't inflate the fonts for me on my iPhone. It miniaturizes them. Severely. This page doesn't have the viewport meta tag in the head. Without the meta tag, I will need to pinch and zoom, but the sizes are ridiculously small. I'm gonna guess that because there is no layout, the width of the page is very large so it is zoomed OUT a great deal. Right? Am I missing something? -- Tom Livingston | Senior Front-End Developer | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] coordinate link and li hover states?
I hope the bits below are enough, else the whole beast can be viewed at:
http://coffeeonmars.com/W200/test/DTake_Index.html
Right now, the li a:hover state appears visually before the a: hover
state, depending on how fast you mouse over it, which could lead the
User to believe that clicking on the color area around the actual link
is enough to fire off that link...is there a way I can get the a:hover
and the li a:hover to happen at the same time? I suspect it's to do with
increasing a:hover's clickable area to co-incide with li a:hover's
Thank you,
John
a{
color:rgb(0,0,0);
text-decoration:none;
border-bottom:1px dotted rgb(0,0,0);
}
a:hover{
color:rgb(255,0,0);
}
nav li{
display:inline;
line-height:1.65em;
margin:0 9% 0 0;
padding:.12em 1em .4em 1em;
border-radius:3px;
background-color:rgb(0,0,0);
}
nav ul li a{
color:rgb(255,255,255);
border-bottom:0;
}
nav ul li a:hover{
color:rgb(255,0,0);
border-bottom:0;
}
nav ul li:hover{
background-color:rgb(200,200,200);
}
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] coordinate link and li hover states?
You could have the a be display: block; and add padding//bg color etc. to achieve the look you are after. Remove the hover from the li. Or a as inline-block instead of block. -- Tom Livingston | Senior Front-End Developer | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] coordinate link and li hover states?
On Fri, Mar 14, 2014 at 5:17 PM, John j...@coffeeonmars.com wrote:
I hope the bits below are enough, else the whole beast can be viewed at:
http://coffeeonmars.com/W200/test/DTake_Index.html
Right now, the li a:hover state appears visually before the a: hover state,
depending on how fast you mouse over it, which could lead the User to
believe that clicking on the color area around the actual link is enough to
fire off that link...is there a way I can get the a:hover and the li a:hover
to happen at the same time? I suspect it's to do with increasing a:hover's
clickable area to co-incide with li a:hover's
Thank you,
John
a{
color:rgb(0,0,0);
text-decoration:none;
border-bottom:1px dotted rgb(0,0,0);
}
a:hover{
color:rgb(255,0,0);
}
nav li{
display:inline;
line-height:1.65em;
margin:0 9% 0 0;
padding:.12em 1em .4em 1em;
border-radius:3px;
background-color:rgb(0,0,0);
}
nav ul li a{
color:rgb(255,255,255);
border-bottom:0;
}
nav ul li a:hover{
color:rgb(255,0,0);
border-bottom:0;
}
nav ul li:hover{
background-color:rgb(200,200,200);
You could have the a be display: block; and add padding//bg color
etc. to achieve the look you are after. Remove the hover from the
li.
--
Tom Livingston | Senior Front-End Developer | Media Logic |
ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] coordinate link and li hover states?
Den 14.03.2014 22:17, skrev John:
Right now, the li a:hover state appears visually before the a: hover
state, depending on how fast you mouse over it, which could lead the
User to believe that clicking on the color area around the actual link
is enough to fire off that link...is there a way I can get the a:hover
and the li a:hover to happen at the same time? I suspect it's to do
with increasing a:hover's clickable area to co-incide with li a:hover's
Style list-items and links the other way round...
nav li {
display:inline-block;
padding: 0;
margin:0 6% 0 0;
border-radius:3px;
background-color:rgb(0,0,0);
}
nav ul li a{
display: block;
line-height:1.65em;
padding:.12em 1em .4em 1em;
}
...and it will work as you intended.
regards
Georg
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] coordinate link and li hover states?
On 3/14/14 2:42 PM, Georg wrote:
Style list-items and links the other way round...
nav li {
display:inline-block;
padding: 0;
margin:0 6% 0 0;
border-radius:3px;
background-color:rgb(0,0,0);
}
nav ul li a{
display: block;
line-height:1.65em;
padding:.12em 1em .4em 1em;
}
...and it will work as you intended.
That worked nicely, Georg...Is it that making the links block forces
their area of clickability to take up all the space the parent affords?
Thank you,
John
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] coordinate link and li hover states?
Den 14.03.2014 23:02, skrev John: Is it that making the links block forces their area of clickability to take up all the space the parent affords? Yes, the link expands to full size of its parent-element, whatever that parent-element is. Typical example: see the list of links here... http://www.gunlaug.com/contents/design/index.html ...and also the regular navigation at the bottom of that page. Both simple unordered lists carrying achors. regards Georg __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Do modern mobile browsers deliberately ignore font size?
Le 15 mars 2014 à 05:52, Tom Livingston tom...@gmail.com a écrit : You say Font inflation exists to solve only this problem, which is a problem that fundamentally would make mobile Web browsers unusable. It doesn't happen if pages declare a meta viewport. The OP's page here: http://81.4.104.136/fonts.html doesn't inflate the fonts for me on my iPhone. It miniaturizes them. Severely. This page doesn't have the viewport meta tag in the head. Without the meta tag, I will need to pinch and zoom, but the sizes are ridiculously small. I'm gonna guess that because there is no layout, the width of the page is very large so it is zoomed OUT a great deal. Right? Am I missing something? Mobile Safari, in the absence of any viewport meta declaration, assumes a viewport 980px wide (that is equivalent to 980px wide window on a desktop browser). Of course the 'window' on iPad/iPhone is (much) narrower, thus the uniform downwards scaling of the page - this is/was done to insure that pages designed for the desktop would be viewable as a whole on those devices. Apple then invented two things to improve the usability: the double-tap on a column zooms/inflates that column and center it in the viewport, and then the viewport meta to set a specific width. (OK, and a few more - font-inflation in some circumstances [*], and the ability to control it via the text-size-adjust property) So no, you're not really missing anything. And fwiw apple.com still has meta name=viewport content=width=1024 / [*] it always puzzles me how it exactly works, most of the time relying on it is like a game of Russian roulette… and gives bizarre results. On sites that can't really be made “responsive” for a variety of reasons I routinely set the text-size-adjust property to 100% (prefixed!), and use the viewport meta to set a width - similar to what apple.com does. Although Apple doesn't use the text-size-adjust property afaict; but then, they structured their content to avoid the font-inflation problem, I think. Philippe -- Philippe Wittenbergh http://l-c-n.com __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
[css-d] Font Size Small in FireFox ?
Hi, how come the font-size is smaller in FireFox compared to Chrome and
IE, which is displaying the font size correctly. I want to change the
line spacing for the UL, is there a more elegant way then just
{line-spacing} ?
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Font Size Small in FireFox ?
On 2014-03-14 23:42 (GMT-0400) Crest Christopher composed:
Hi, how come the font-size is smaller in FireFox compared to Chrome and
IE, which is displaying the font size correctly. I want to change the
line spacing for the UL, is there a more elegant way then just
{line-spacing} ?
Here most fonts in FF are larger than those in Chrome.
How are the font sizes being declared? If relative to browser defaults (em,
rem, %, keywords) instead of in px (which disregard user preferences), then
different size browser defaults in the various browsers stand a good chance
of being the reason. Defaults in Chrome and IE vary according to DE DPI.
Defaults in Geckos do not vary by DPI. If the DE DPI is 120 and the Gecko
preference has been left as shipped by Mozilla, then it will be 80% of the
height of the defaults shipped by Chrome and IE. If the DE DPI is 144 while
OEM defaults are undisturbed, then Gecko fonts will be 2/3 the size of Chrome
and IE. When DE DPI and browser defaults remain as shipped (96 DPI,
12pt/16px), then sizes in all three browsers should be the same no matter how
sizes are declared.
--
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 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
__
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
