Re: [css-d] Font size dilemma
On Sat, 14 Mar 2009 18:42:06 -1000 Came this utterance formulated by david to my mailbox: Jukka K. Korpela wrote: Michael Stevens wrote: Calibri I have but do not have installed all the time and use it maybe a couple times a month. And I've never heard of Vrinda. I picked up Vrinda after considering the material at http://www.codestyle.org/css/font-family/sampler-WindowsResults.shtml and noticing that Vrinda is the only widely available sans-serif font where letters are small as compared with the font size. So it's the best backup for Calibri, the font I'd really like to use. As you can see from http://www.ascenderfonts.com/font/vrinda-bengali.aspx Vrinda was really designed for Bengali writing, but it has Latin 1 characters too, so it might serve as a fallback font when you don't need other characters. I guess the Bengali orientation explains the large intrinsic line-height. Well, in my 20+ years of using computers, including desktop publishing, graphic and web design work - I've never used a computer that had either Calibri or Vrinda on it. And I used to be a real font junky! (That spans every version of Windows, Mac OS7/8/9 and OS X, one version of UNIX and several distros of Linux.) Calibri is one of a set of Office 2007 fonts which can be obtained free with the new powerpoint viewer. http://www.microsoft.com/downloads/details.aspx?familyid=048DC840-14E1-467D-8DCA-19D2A8FD7485displaylang=en http://en.wikipedia.org/wiki/Calibri It's use is expected to grow as uptake of office 2007, and this free viewer, gets established. -- Michael All shall be well, and all shall be well, and all manner of things shall be well - Julian of Norwich 1342 - 1416 __ css-discuss [cs...@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 dilemma
Michael Adams wrote: On Sat, 14 Mar 2009 18:42:06 -1000 Came this utterance formulated by david to my mailbox: Jukka K. Korpela wrote: Michael Stevens wrote: Calibri I have but do not have installed all the time and use it maybe a couple times a month. And I've never heard of Vrinda. I picked up Vrinda after considering the material at http://www.codestyle.org/css/font-family/sampler-WindowsResults.shtml and noticing that Vrinda is the only widely available sans-serif font where letters are small as compared with the font size. So it's the best backup for Calibri, the font I'd really like to use. As you can see from http://www.ascenderfonts.com/font/vrinda-bengali.aspx Vrinda was really designed for Bengali writing, but it has Latin 1 characters too, so it might serve as a fallback font when you don't need other characters. I guess the Bengali orientation explains the large intrinsic line-height. Well, in my 20+ years of using computers, including desktop publishing, graphic and web design work - I've never used a computer that had either Calibri or Vrinda on it. And I used to be a real font junky! (That spans every version of Windows, Mac OS7/8/9 and OS X, one version of UNIX and several distros of Linux.) Calibri is one of a set of Office 2007 fonts which can be obtained free with the new powerpoint viewer. http://www.microsoft.com/downloads/details.aspx?familyid=048DC840-14E1-467D-8DCA-19D2A8FD7485displaylang=en http://en.wikipedia.org/wiki/Calibri It's use is expected to grow as uptake of office 2007, and this free viewer, gets established. Well, that explains it. I've never worked for any organization that uses Office 2007. (And I've worked for some very big organizations in the education, health insurance and health care fields.) I've never encountered a Powerpoint 2007 format file in the wild, so have never had any need for the MS Powerpoint viewer (OpenOffice opens the Office 2007 files just fine). I don't expect Office 2007 use to establish itself, but that's just my opinion. -- David gn...@hawaii.rr.com authenticity, honesty, community __ css-discuss [cs...@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 dilemma
david wrote: I don't expect Office 2007 use to establish itself, but that's just my opinion. May well be right. For instance: OpenOffice is officially recommended as alternative to / upgrade-replacement for MS Office(s) and other proprietary office software in my country. The bottom line for web designers is that no matter what range of fonts an end-user may have access to, we can't know what that range is or what fonts they'll allow/enforce for web sites. Therefore we can't design with any specific font, or range of fonts, in mind and expect our choices to get through to end-users. Tough, but that's life on the web :-) We should ideally make sure our creations come through in a reasonable and readable fashion no matter what, which means (among other things) that it is better, and safer, to size text to what some call too large than to size it too small. For some reason or another: all systems/browsers have a default of exactly 100% (of some predefined value(s)), so a font-size of 100% can be considered safe. In addition to that we have the WCAG 2 recommendation that our creations should be able to handle 200% font resizing and still be readable/accessible, so there's our safe range. Of course: no web designer really has to play it safe, and we're still free to make up our own math and take our chances. We /may/ hit right here and there now and then ;-) regards Georg -- http://www.gunlaug.no __ css-discuss [cs...@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 dilemma
I would imagine setting a browser minimum font size to bring (say) cnn.com back to 100% font size equivalent would have no effect on a site set to 100% font size; very little effect on one set to say 85%; but running the browser in some zoom mode to get cnn to 100% equiv would blow our font-size 100% sites out to 150% equiv or similar!! I have a related question, because when I first took up CSS in my designs in 2002 or so, I used to size my fonts in points. That was what word processing programs did it in, so that was how I did it. I gradually learned through online reading that that was not the right way to do it, and stopped, but I've never been able to figure out why it's wrong in the first place. It seems that this whole font sizing mess boils down to the fact that pixel is not a standardized unit of measure. one pixel on my monitor is a different size from one pixel on your monitor. But a point is a standardized unit of measure. it's 1/72 of an inch. And an inch is 0.0254 meters. And meters are well defined. Most graphic arts programs have the ability to guess the size of a pixel on your monitor, presumably from your drivers or some setting in your OS or something, so it seems that web browsers must be able to do that same thing. So it stands to reason that if you want your fonts to be 10pt (which is normal for print media) instead of 12 or 16pt (which is the common default size at the most common monitor resolutions) why not just set the font size to 10pt? and then if you have a 120dpi monitor, your browser knows that's 17px, and if you have an old 72dpi monitor, your browser knows that's 10px. And then it's no more illegible than a novel or a newspaper. ---Tim __ css-discuss [cs...@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] :: molly :: Font size dilemma
Gunlaug Sørtun wrote: ... Of course: no web designer really has to play it safe, and we're still free to make up our own math and take our chances. We /may/ hit right here and there now and then ;-) regards Georg Nice summation for this thread imo. These discussions, more often than not, dwindle to the argument for the exchange of one set of control factors for another set control factors. A calm voice filled with simple common sense and rational thinking is a welcome relief... As ever, Frederic W. Goudy -- A thin red line and a salmon-color ampersand forthcoming. http://chelseacreekstudio.com/ __ css-discuss [cs...@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] Size calculations
Hi. I'm looking for some kind of formular to calculate sizes. This is a hypotetical question: I want a 2 column design with header and footer, a left nav- and info-column, and a right content-column. Centered. Lets say the size are: Header and footer : 90% These two columns together: 80% Left column: 20-25% Content column : 80-75% How do I change these measurements to: em -- Regards / Mhv. Ib K. jensen - http://ikjensen.dk __ css-discuss [cs...@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] Suckerfish in Wordpress - 'current page' in sub menu
oftp:\ Suckerfish snippets don't work in IE6. Is it different in Wordpress ? __ css-discuss [cs...@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 dilemma
Tim Climis wrote: I have a related question, because when I first took up CSS in my designs in 2002 or so, I used to size my fonts in points. That was what word processing programs did it in, so that was how I did it. I gradually learned through online reading that that was not the right way to do it, and stopped, but I've never been able to figure out why it's wrong in the first place. It isn't wrong, but it cripples certain browsers and makes it harder to apply reasonable end-user preferences in all browsers. We refer to points for font sizing as part of the print on screen philosophy, and print doesn't work all that well on all that many screens - it belongs on paper and similar surfaces. Most graphic arts programs have the ability to guess the size of a pixel on your monitor, presumably from your drivers or some setting in your OS or something, so it seems that web browsers must be able to do that same thing. So it stands to reason that if you want your fonts to be 10pt (which is normal for print media) instead of 12 or 16pt (which is the common default size at the most common monitor resolutions) why not just set the font size to 10pt? and then if you have a 120dpi monitor, your browser knows that's 17px, and if you have an old 72dpi monitor, your browser knows that's 10px. The problem is complex but also quite simple. We work with what we have and what we gonna get - pushed by ourselves and those who build browsers and write standards, and, most important: what the end-users are likely to have, or get within a reasonable time-frame. With way more than a billion end-user installations on line, we better put emphasis on reasonable time-frame, as we will have to cater for decade-old installations alongside the latest and greatest week-old installations. Of course: we don't have to cater for old and new installations in the same way, as long as we don't cripple any of them. Practically: 1: screen-resolution is low compared to print-resolution - we need 300dpi on screens before we can call it acceptable. Coarser steps makes it harder to make points - and any other unit - hit screen-pixels exactly, and browsers round up/down at differing points. This results in variations, that are much larger on screens than on print. 2: most graphic arts programs - or their users - solve this low screen-resolution problem by resizing the entire project - zoom it, and the artist then moves/scrolls parts into view while working. Most browsers can do that too - now, but end-users are not _working_ on the project - they _interact_ with it, and most end-users would prefer to not have to scroll both ways just to be able to read and interact. 3: browsers have only recently started to take screen-resolution into account and apply default-resizing. Not all browsers are there yet, and those that are are not equally good at it. 4: end-users should be able to use their software - browser - to re-format text to suit their needs/preferences. This is an advantage we have in our digital age, and it would be sad if we limited and/or crippled our software to frozen print now that we have finally gotten out of it. 5: some browsers - IE - can't resize text where points or pixels are used. The solution: ignore font sizes on web pages, doesn't solve the designer's problem. Blame whoever you like, but the problem persists. And then it's no more illegible than a novel or a newspaper. 6: if a printed work has too small text, the end-user can either use a magnifying glass or throw the entire work into the fireplace. Neither are very practical when the work is on screens, but the end-user can of course look for better options elsewhere on the world wide web. I can't prove it but I think many do. I derive from the above that it is better to conform to reality than to apply wishful thinking (and mouse-type in points) now. At the same time I test how much of my wishful thinking that actually works anywhere, hoping I may be able to apply some of it tomorrow as I'd hate being stuck in the past at every crossroad and turn of evolution. regards Georg -- http://www.gunlaug.no __ css-discuss [cs...@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] Size calculations
Ib Jensen wrote: How do I change these measurements to: em What are those hypothetical '%' you want to convert to hypothetical 'em', relative to? That is: what is your hypothetical 100% starting-width? You can't convert anything to 'em' without having an absolute starting point. regards Georg -- http://www.gunlaug.no __ css-discuss [cs...@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] Size calculations
Ib Jensen wrote:
I want a 2 column design with header and footer, a left nav- and
info-column, and a right content-column. Centered.
Header and footer : 90%
These two columns together: 80%
Left column: 20-25%
Content column : 80-75%
How do I change these measurements to: em
Use ems...and a calculator. Relying on the browser to calculate the
percentage is sketchy at best. You probably want something like this:
~~~
!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN'
'http://www.w3.org/TR/html4/strict.dtd'
html
head
title%TITLE%/title
meta http-equiv='content-type'
content='text/html;charset=utf-8'
style type='text/css'
#head-frame,#main-frame,#menu-frame,#foot-frame {
padding: 1px 0; /* Fix margin collapsing */
}
#page-shell {
margin: 0 auto;
width: 80em;
}
#head-frame, #foot-frame {
background: #dedede;
margin: 0 auto;
width: 72em; /* 90% of 80em */
}
#page-frame {
background: #999;
margin: 0 auto;
width: 64em; /* 80% of 80em */
}
#page-panel {
background: #ccc;
margin-left: 16em; /* Same as #menu-frame width */
}
#main-frame {
float: right;
width: 48em; /* 75% of 64em */
}
#menu-frame {
display: inline; /* Fix IE double-margin bug */
float: left;
margin-left: -16em; /* Width x -1 */
width: 16em; /* 25% of 64em */
}
/* FLOAT BEHAVIOR SWITCH FOR STANDARDS COMPLIANT BROWSERS */
#page-panel:after {
clear: both;
content: .;
display: block;
font-size: 1px;
height: 0;
line-height: 0;
overflow:hidden;
visibility: hidden;
}
/* FLOAT BEHAVIOR SWITCH FOR IE */
#page-panel {
display: inline-block;
}
#page-panel {
display: block;
position:relative;
}
/style
/head
body id='www-css_sig-tld'
div id='page-shell'
div id='head-frame'
p%HEAD%/p
/div
div id='page-frame'
div id='page-panel'
div id='main-frame'
p%MAIN%/p
p%MAIN%/p
p%MAIN%/p
/div
div id='menu-frame'
p%MENU%/p
p%MENU%/p
p%MENU%/p
p%MENU%/p
p%MENU%/p
/div
/div
/div
div id='foot-frame'
p%FOOT%/p
/div
/div
/body
/html
~~~
Hope it helps.
--Bill
--
!--
! Bill Brown macnim...@gmail.com
! Web Developologist, WebDevelopedia.com
--
__
css-discuss [cs...@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] Size calculations
Bill Brown wrote:
/* FLOAT BEHAVIOR SWITCH FOR IE */
#page-panel {
display: inline-block;
}
#page-panel {
display: block;
position:relative;
}
I lied: remove the position:relative from that last block. That's an
artifact from another template. Sorry.
--
!--
! Bill Brown macnim...@gmail.com
! Web Developologist, WebDevelopedia.com
--
__
css-discuss [cs...@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] Size calculations
Ib Jensen wrote: The template should fill a total of 90% of the viewport / screen. I don't know if this clears something. Not really. My viewport / screen is 3840pixel wide on one machine, but it is 1280pixel wide on another machine and 1440pixel wide on yet another. No problem filling all these correctly with one set of percentages - although it will look strangely wide on some viewports / screens. However, my viewports / screens provide 3 different starting-widths for converting to 'em' - and I have no idea what viewport / screen widths end-users have. You have to decide if the 100% starting-width is 800, 1024, 1280, 1600pixel or something else, since you can't convert percentages into 'em' directly for anything but font-size and line-height. If your 100% starting-width is 800pixel, then 800/16='em' will hit right as long as we're dealing with the default font-size for 96dpi. If browsers correct correctly for resolution, then it'll still be correct (in a manner of speaking) for other resolutions. Problem is: browsers are not very good at the various resolution game yet, so you may get more than one actual width as result on higher resolutions - depending on browser. Hope that came through a bit clearer. regards Georg -- http://www.gunlaug.no __ css-discuss [cs...@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] Size calculations
2009/3/15 Bill Brown macnim...@gmail.com:
Bill Brown wrote:
/* FLOAT BEHAVIOR SWITCH FOR IE */
#page-panel { display: inline-block; }
#page-panel { display: block; }
I lied: remove the position:relative from that last block. That's an
artifact from another template. Sorry.
It should be as corrected above your lie ;-)
I'll try it out, and se how it looks, and I, maybe be back !
--
Regards / Mhv.
Ib K. jensen - http://ikjensen.dk
__
css-discuss [cs...@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] Size calculations
2009/3/15 Gunlaug Sørtun gunla...@c2i.net: Ib Jensen wrote: How do I change these measurements to: em What are those hypothetical '%' you want to convert to hypothetical 'em', relative to? That is: what is your hypothetical 100% starting-width? You can't convert anything to 'em' without having an absolute starting point. The template should fill a total of 90% of the viewport / screen. I want the header and footer in the template to fill 90% of the viewport / screen. The left- and content-column in the template should only fill 80% of the viewport / screen. I don't know if this clears something. -- Regards / Mhv. Ib K. jensen - http://ikjensen.dk __ css-discuss [cs...@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] Size calculations
2009/3/15 Gunlaug Sørtun gunla...@c2i.net: Ib Jensen wrote: My viewport / screen is 3840pixel wide on one machine, but it is 1280pixel wide on another machine and 1440pixel wide on yet another. Kind a the same problem here: I'm developing on a 19 widescreen, resolution unknown for the moment. I'm writing this, looking for tips and tricks and seing my own and other sites on a 22 widescreen. You have to decide if the 100% starting-width is 800, 1024, 1280, 1600pixel or something else, since you can't convert percentages into 'em' directly for anything but font-size and line-height. Now you are forcing me do something quit new to me, taking descissions. Problably because I want to much at the same time. But I assume that the mostly used monitor-size is either a 17 or 19 screen, then it should be something around 800 or 1024px. If your 100% starting-width is 800pixel, then 800/16='em' will hit right as long as we're dealing with the default font-size for 96dpi. If browsers correct correctly for resolution, then it'll still be correct (in a manner of speaking) for other resolutions. Problem is: browsers are not very good at the various resolution game yet, so you may get more than one actual width as result on higher resolutions - depending on browser. Hope that came through a bit clearer. I think. That means roughly, that a developer should have at least three screens with different resolutions and X number of browsers installed, on different systems, to in fact have a chance to guess which size of units to use. -- Regards / Mhv. Ib K. jensen - http://ikjensen.dk __ css-discuss [cs...@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] Size calculations
Ib Jensen wrote:
The template should fill a total of 90% of the viewport / screen.
I want the header and footer in the template to fill 90% of the
viewport / screen.
The left- and content-column in the template should only fill 80% of
the viewport / screen.
I don't know if this clears something.
If you don't care about IE, or you're not using full-height column
backgrounds, you can get away with this:
~~~
!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN'
'http://www.w3.org/TR/html4/strict.dtd'
html
head
title%TITLE%/title
meta http-equiv='content-type'
content='text/html;charset=utf-8'
style type='text/css'
#page-frame,#core-panel
{width:90%;margin:0 auto}
#head-frame,#core-frame,#foot-frame
{display:table;margin:0 auto}
#head-frame,#foot-frame
{width:90%}
#core-frame
{width:80%}
#head-panel,#core-panel,#foot-panel
{display:table-row}
#header,#menu,#main,#footer
{display:table-cell;vertical-align:top}
#head-panel,#foot-panel
{background:#ccc;width:100%}
#menu
{background:#bbb;width:20%}
#main
{background:#ddd;width:80%}
/* Faking display:table-cell for IE as best we can */
#menu,#main
{display:inline-block!ie}
#menu,#main
{display:inline!ie}
/style
/head
body id='www-css_sig-tld'
div id='page-frame'
div id='head-frame'
div id='head-panel'
div id='header'
p%HEADER%/p
/div
/div
/div
div id='core-frame'
div id='core-panel'
div id='menu'
p%MENU%/p
p%MENU%/p
/div
div id='main'
p%MAIN%/p
/div
/div
/div
div id='foot-frame'
div id='foot-panel'
div id='footer'
p%FOOTER%/p
/div
/div
/div
/div
/body
/html
~~~
Hope it helps.
--Bill
--
!--
! Bill Brown macnim...@gmail.com
! Web Developologist, WebDevelopedia.com
--
__
css-discuss [cs...@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] Size calculations
2009/3/15 Bill Brown macnim...@gmail.com:
Ib Jensen wrote:
If you don't care about IE, or you're not using full-height column
backgrounds, you can get away with this:
I do care about IE ( a lot of faul words ), to a certain limit IE6 and up.
And wish to use full-height columns without graphics, just colors.
#page-frame,#core-panel
{width:90%;margin:0 auto}
Now I've had to calculate the other way round. From % to em. ;-)
/* Faking display:table-cell for IE as best we can */
#menu,#main
{display:inline-block!ie}
#menu,#main
{display:inline!ie}
Is this a way of making a kind of table-layout ??
Hope it helps.
--Bill
At least I have something to play with.
Just got finished with your first suggestion.
It showed me that % and em, are two very diiferent units to play with.
I've had to recalculate the meassures, to something smaller. So it
could fit on _my_ screen, but the original meassures will problably
show up differently on another screen.
--
Regards / Mhv.
Ib K. jensen - http://ikjensen.dk
__
css-discuss [cs...@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] Epileptic DIV jumping in IE on initial page load (disappears after resize)
Hi all -- I'm trying to track down the source of an annoying CSS jumping problem that happens when loading http://www.emmacarlson.com/emmablog/ in IE. During page load, the left-hand nav jumps back and forth between the left size and center of the page, and often ends up stuck in the middle after the loading completes. What is strange is that the problem seems to go away if you let the page load and then resize it. This is a fluild layout (not centered) so I don't believe it is the page shift / scrollbar problem. The problem doesn't happen in FF (or Safari), so I can't use my beloved Firebug to track it down. Any suggestions on how to resolve this, or at least debug it more effectively? Thanks in advance! Ramon __ css-discuss [cs...@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] Epileptic DIV jumping in IE on initial page load (disappears after resize)
Ramon Felciano wrote:
Hi all --
I'm trying to track down the source of an annoying CSS jumping problem
that happens when loading http://www.emmacarlson.com/emmablog/ in IE.
During page load, the left-hand nav jumps back and forth between the
left size and center of the page, and often ends up stuck in the
middle after the loading completes. What is strange is that the
problem seems to go away if you let the page load and then resize it.
This might help:
#content-inner{zoom:1}
...ensures the content-inner container 'hasLayout'.
--
!--
! Bill Brown macnim...@gmail.com
! Web Developologist, WebDevelopedia.com
--
__
css-discuss [cs...@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] Size calculations
Ib Jensen wrote: That means roughly, that a developer should have at least three screens with different resolutions and X number of browsers installed, on different systems, to in fact have a chance to guess which size of units to use. Not at all. You can check all conditions on a screen with high enough resolution, but you may have to keep track of those browsers and how they evolve and respond to changes on the hardware side. The reason I opted for such a large screen-area on my workstation, is that I can simulate nearly all hardware/software induced conditions on it through a few clicks. Most web designers can simulate parts of modified conditions at the user-end by zooming up and down the entire page in a capable browser. First: get the terms, and sizes, right. Resolution is somewhere between 72 and 300dpi and most viewports/screens are between 640 and 3600px wide. Resolution vs pixel-width affect actual screen size, so a 2400px wide screen with 220dpi resolution (not many of those around, but they're coming) will be physically quite small in size. So, forget about 15, 17, 19 and so on for screens. A screen is so and so many screen-pixels wide and tall, regardless of its actual size. This resolution vs. size range can not be covered by web designers by using one size fits all methods - the browsers and end-user settings have to bridge the gap. What we have to do is to allow browsers to do their job - we have to work _with_ the media and not against them, and only decide which limits we have to set so our creations have a chance to survive. The only somewhat safe way to lay out web pages so they work everywhere, is to not lock sizes to anything but viewport - using percentage, and decide what is too wide or too narrow for our creations. 'em' is locked to font-size, so 'em' is in most cases only useful for setting limits - min-width and/or max-width, and those limits should be quite generous. 'px' is also locked, so they're also most useful for setting generous limits. In time browsers and other software will be modified to un-lock both 'em' and 'px' - in a way, in order to make sensible use of higher resolution on screens. Full page zoom is one way to do that, and most browsers already have the basics (for manual setting) in place. Screen-pixels and design-pixels then become relative to each other - as they already are on regular printers, and the software will do the conversion (see wishful thinking in another thread today). For full page zoom browsers seem to go the adaptive zoom route, probably because they can't cover the wide resolution/actual screen size range any other way and make it fit on screen for all end-users. Most fluid-width designs will then work quite well without modifications, but both 'em' sized and 'px' sized designs may run into range problems since they can't really adapt to viewports/screens unless browsers override their fixed width (my browser-preference can already do that). Fixed-width layouts, being it 'px' or 'em', will probably never go out of fashion ... they just won't work very well outside their creators' preferred range. Support for media queries is slowly growing across browser-land, so we are, or will be, able to modify our designs a bit to suit the various conditions. Great care has to be taken here though, as we must know what various browsers actually do under various conditions before we try to improve things. Now, browsers and screen-resolutions can only go one way, upwards, while screen-sizes can and will go both ways. Thus, the future for rendering on flat screens is predictable, although it is hard to say how quickly they evolve and spread. They have to introduce one or more non-flat screens for anything to change. So, IMO, it is best *not* to convert a fluid layout into anything else right now, but instead only control the upper and lower limit for its fluidity so it doesn't become ridiculously and/or unusably wide or narrow. That this control of fluidity can be achieved both forward and in reverse, and in a few other ways, may complicate matters for those who haven't grasped the whole adapt or fail concept. However, rising resolution and both larger and smaller screens and various devices are hitting the market around us, so quick learners will be at an advantage. regards Georg -- http://www.gunlaug.no __ css-discuss [cs...@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 dilemma
At 11:01 + on 03/13/2009, Bobby Jack wrote about Re: [css-d] Font size dilemma: Having said all that, I don't think we need to be too dogmatic about it. Web pages are NOT the same as books - I believe there should be more of a visual identity to a site than just a logo and a couple of images. If browsers did a better job of handling font-sizing, every web site could easily be readable by all whilst maintaining a unique look of its own, even in regards to the 'base' font size. In some ways CSS is a step backwards on this issue from the old HTML FONT tag. With FONT ... you display in the USER'S defined font size and increase/decrease the display via the SIZE parm. With CSS you can get the same result via use of EM or % sizes but using PT (or other measures that ignore the user's default font size) causes the user's settings to be overridden and ignored. -- Bob Rosenberg RockMUG Webmaster webmas...@rockmug.org www.RockMUG.org __ css-discuss [cs...@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 dilemma
At 21:26 -0400 on 03/14/2009, Felix Miata wrote about Re: [css-d] Font size dilemma: It's also possible for fonts to show up at the preferred size, regardless how large or small that happens to be. It's also possible that the difficulties resulting from common too small fonts will be reduced or eliminated. There is also the problem that the character height on a site designed on a Windows Machine makes the characters look smaller on a Macintosh Computer (to get the same image size on the Mac you must bump the size up one notch). This has to do with the 96dpi font sizing on the Windows Machine requiring larger letters than the Macintosh fonts which are based on 72dpi measurements. -- Bob Rosenberg RockMUG Webmaster webmas...@rockmug.org www.RockMUG.org __ css-discuss [cs...@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] Size calculations
On Sun, 15 Mar 2009 21:12:39 +0100 Came this utterance formulated by Gunlaug Sørtun to my mailbox: Ib Jensen wrote: That means roughly, that a developer should have at least three screens with different resolutions and X number of browsers installed, on different systems, to in fact have a chance to guess which size of units to use. Not at all. You can check all conditions on a screen with high enough resolution, but you may have to keep track of those browsers and how they evolve and respond to changes on the hardware side. The reason I opted for such a large screen-area on my workstation, is that I can simulate nearly all hardware/software induced conditions on it through a few clicks. Most web designers can simulate parts of modified conditions at the user-end by zooming up and down the entire page in a capable browser. First: get the terms, and sizes, right. Resolution is somewhere between 72 and 300dpi and most viewports/screens are between 640 and 3600px wide. Phone and palm browsing is on the increase and screen width there is typically under 400px. Resolution vs pixel-width affect actual screen size, so a 2400px wide screen with 220dpi resolution (not many of those around, but they're coming) will be physically quite small in size. So, forget about 15, 17, 19 and so on for screens. A screen is so and so many screen-pixels wide and tall, regardless of its actual size. This resolution vs. size range can not be covered by web designers by using one size fits all methods - the browsers and end-user settings have to bridge the gap. What we have to do is to allow browsers to do their job - we have to work _with_ the media and not against them, and only decide which limits we have to set so our creations have a chance to survive. The only somewhat safe way to lay out web pages so they work everywhere, is to not lock sizes to anything but viewport - using percentage, and decide what is too wide or too narrow for our creations. 'em' is locked to font-size, so 'em' is in most cases only useful for setting limits - min-width and/or max-width, and those limits should be quite generous. 'px' is also locked, so they're also most useful for setting generous limits. In time browsers and other software will be modified to un-lock both 'em' and 'px' - in a way, in order to make sensible use of higher resolution on screens. Full page zoom is one way to do that, and most browsers already have the basics (for manual setting) in place. Screen-pixels and design-pixels then become relative to each other - as they already are on regular printers, and the software will do the conversion (see wishful thinking in another thread today). For full page zoom browsers seem to go the adaptive zoom route, probably because they can't cover the wide resolution/actual screen size range any other way and make it fit on screen for all end-users. Most fluid-width designs will then work quite well without modifications, but both 'em' sized and 'px' sized designs may run into range problems since they can't really adapt to viewports/screens unless browsers override their fixed width (my browser-preference can already do that). Fixed-width layouts, being it 'px' or 'em', will probably never go out of fashion ... they just won't work very well outside their creators' preferred range. Support for media queries is slowly growing across browser-land, so we are, or will be, able to modify our designs a bit to suit the various conditions. Great care has to be taken here though, as we must know what various browsers actually do under various conditions before we try toimprove things. Now, browsers and screen-resolutions can only go one way, upwards, while screen-sizes can and will go both ways. Thus, the future for rendering on flat screens is predictable, although it is hard to say how quickly they evolve and spread. They have to introduce one or more non-flatscreens for anything to change. So, IMO, it is best *not* to convert a fluid layout into anything else right now, but instead only control the upper and lower limit for its fluidity so it doesn't become ridiculously and/or unusably wide or narrow. That this control of fluidity can be achieved both forward and in reverse, and in a few other ways, may complicate matters for those who haven't grasped the whole adapt or fail concept. However, rising resolution and both larger and smaller screens and various devices are hitting the market around us, so quick learners will be at an advantage. regards Georg -- http://www.gunlaug.no __ css-discuss [cs...@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 dilemma
At 16:59 +0100 on 03/15/2009, =?ISO-8859-1?Q?Gunlaug_S=F8rtun?= wrote about Re: [css-d] Font size dilemma: 6: if a printed work has too small text, the end-user can either use a magnifying glass or throw the entire work into the fireplace. Or just buy the book (or get it from your local public library) as a LPE (Large Print Edition - ie: 16pt type [like the children's books use]) in the first place. -- Bob Rosenberg RockMUG Webmaster webmas...@rockmug.org www.RockMUG.org __ css-discuss [cs...@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] Size calculations
2009/3/15 Gunlaug Sørtun gunla...@c2i.net: Ib Jensen wrote: First: get the terms, and sizes, right. Resolution is somewhere between 72 and 300dpi and most viewports/screens are between 640 and 3600px wide. Resolution vs pixel-width affect actual screen size, so a 2400px wide screen with 220dpi resolution (not many of those around, but they're coming) will be physically quite small in size. So, forget about 15, 17, 19 and so on for screens. A screen is so and so many screen-pixels wide and tall, regardless of its actual size. Uuuups. Something that I have completely misunderstood. Thats problably why I sometimes have problems getting the right size of the layout i working with locally. 'em' is locked to font-size, so 'em' is in most cases only useful for setting limits - min-width and/or max-width, and those limits should be quite generous. 'px' is also locked, so they're also most useful for setting generous limits. By this, you mean that, how should I write it: A fluid / Elacstic layout: The skeleton of a layout in % Font-size in % or em A fixed layout: The skeleton of a layout in em or px Font-size in em or px -- Regards / Mhv. Ib K. jensen - http://ikjensen.dk __ css-discuss [cs...@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] Was : Size calculations
Hi A little layout issue. Link : http://ikjensen.dk/test/ Pictures: Link : http://ikjensen.dk/test/capture_ff.jpg Link : http://ikjensen.dk/test/capture_ie.jpg I tryed a layout suggestion mentioned in the thread: Size calculations. But had this weird layout issue on my screen, as seen on the pictures. -- Regards / Mhv. Ib K. jensen - http://ikjensen.dk __ css-discuss [cs...@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] Size calculations
Ib Jensen wrote: By this, you mean that, how should I write it: [...] Some say elastic when they mean fluid layouts, while some say elastic when they mean em-sized layouts. Confusing. To cut through; for the basic layout, I mean: 1: Fluid layout: all widths in '%'. (One can also use auto-width in some cases.) - adapt well to various viewports, but can become overly wide and narrow. 2: Conditional fluid layout: all widths in '%', + min-width/max-width for entire layout in 'em' and/or 'px'. - adapt well to various viewports, and can *not* become overly wide or narrow. - if 'em' is used for max-width, I sometimes refer to these as conditional elastic since they behave as fluid and 'em'-sized at the same time. 3: Fixed layout: all widths in 'px'. - can't adapt to anything. 4: Em-sized layout: all widths in 'em'. - can't adapt to anything. Basic layout variants: 5: Fixed - fluid - fixed: overall width in '%', with fixed-width side columns and fluid main column. - adapt well to various viewports, but main column can become overly wide and narrow. - also comes in 2-columns fixed-fluid or fluid-fixed, and in other column-mixes. 6: Conditional fixed - fluid - fixed: overall width in '%', with fixed-width side columns and fluid main column, + min-width/max-width for entire layout in 'em' and/or 'px'. - adapt well to various viewports, and main column can *not* become overly wide or narrow. - also comes in 2-columns fixed-fluid or fluid-fixed, and in other column-mixes. 7: Overly backwards and unnecessary complex adaptive fixed/em-sized layout: width in 'px' or 'em', + max-width in '%' and min-width in 'em' or 'px'. - can adapt to various viewports to a certain degree, but 'em' sized tends to break under font resizing stress unless all font-sizes are left at default. Font-size for all the above in whatever unit, but preferably in '%' and/or 'em' for optimal end-user friendliness. FYI: I most often use a 2 or 6 variation with generous min/max limits. For my personal site I use 6 and mix in conditional elastic for the main column in an otherwise fixed-fluid-fixed layout. A bit of cross-container absolute positioning tops it up. I then add in mediaqueries to reconfigure the entire layout for really small screens, and look to the future for help ;-) In essence: one can mix in layout variations in one layout to kingdom come and get away with it, as long as one understands the adapt or fail concept ... and test well. Not possible to make really old/obsolete browser play along with everything though, so one still has to be pragmatic and make choices for under which conditions ones creation has to work and under which it may be allowed to fail - and how much it should be allowed to fail. However, ones creation should only be allowed to fail for real in those old/obsolete browsers, as one should be able to at least hope that makers of new browser versions know what they're doing and can make _their_ creations work. Think I got the above about right. Hard to compress a thousand choices into a mail. regards Georg -- http://www.gunlaug.no __ css-discuss [cs...@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 dilemma
On Sun, 15 Mar 2009, Tim Climis wrote I gradually learned through online reading that that was not the right way to do it, and stopped, but I've never been able to figure out why it's wrong in the first place. One reason is that points are inches and some people who write about these topics just don't understand how an Operating System differentiates between inches on paper and inches on screen. In computer typography a point is 1/72 of an inch so anything measured in points is actually measured in inches. In Eric Meyer on CSS he says There is no clearly defined mapping between pixels and the physical world. How many pixels should there be per inch?. Nonsense. Of course there are completely defined mappings of inches to pixels. Programmers have been writing text editors and word processing programs for years where they clearly map font size in points (inches) to pixels on screen. When printing the programmer knows the size of the piece of paper, but when putting text on screen the programmer has no way of reliably, or accurately, knowing the size of your screen so there had to be a standard way of converting lengths specified in inches into lengths in pixels, and this is done by using 'screen dpi', the value of which, in Windows, we can change in the Control Panel Length in inches * screen dpi = Length in pixels So if something is specified as one inch long and screen dpi is set, via the Control Panel, to 102 dpi (my current setting) then: 1 * 102 = 102 pixels. Unfortunately people then put their ruler up to the screen and find it's not one inch on their ruler so incorrectly conclude that There is no clearly defined mapping between pixels and the physical world'. Add to that the fact that the actual physical number of pixels per linear inch (determined by the monitor manufacturing process) is specified as a number of dpi it's hardly surprising that there is confusion and inches get a bad press. After all that, browsers (as opposed to the Operating System) don't treat inch measurements in a completely consistent manner why be surprised? They don't seem to treat many other quantity's in a consistent manner either e.g. Don't use pixels because If inches are going to get a bad press then authors should do so for the right reasons, not the spurious reasons so often seen. It seems that this whole font sizing mess boils down to the fact that pixel is not a standardized unit of measure. one pixel on my monitor is a different size from one pixel on your monitor. The word standard means what here? The CSS spec tries to define a standard pixel, and talks rubbish. Actually one pixel on your monitor is different to another pixel on your monitor at different times. If, say, you usually operate at 1280 * 1024 and then switch to 1024 * 768 then 20% of pixels have 'disappeared' both horizontally and vertically, but the whole screen is still filled. Pixels have changed their size. -- Richard Mason http://www.emdpi.com __ css-discuss [cs...@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 dilemma
On 2009/03/15 17:14 (GMT-0400) Bob Rosenberg composed: There is also the problem that the character height on a site designed on a Windows Machine makes the characters look smaller on a Macintosh Computer (to get the same image size on the Mac you must bump the size up one notch). This has to do with the 96dpi font sizing on the Windows Machine requiring larger letters than the Macintosh fonts which are based on 72dpi measurements. All that was made obsolete by Mac OS X, which, unlike windoz, is locked to 96 DPI. Except to the devs and some dev wannabes, deviating from 96 on OS X is just a dream. It may never be literally possible. Instead resolution independence may come via a different model than DPI adjustment. -- The plans of the diligent lead to profit as surely as haste leads to poverty. Proverbs 21:5 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ __ css-discuss [cs...@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 dilemma
Tim Climis wrote: Most graphic arts programs have the ability to guess the size of a pixel on your monitor, presumably from your drivers or some setting in your OS or something, so it seems that web browsers must be able to do that same thing. So it stands to reason that if you want your fonts to be 10pt (which is normal for print media) instead of 12 or 16pt (which is the common default size at the most common monitor resolutions) why not just set the font size to 10pt? and then if you have a 120dpi monitor, your browser knows that's 17px, and if you have an old 72dpi monitor, your browser knows that's 10px. And then it's no more illegible than a novel or a newspaper. But text on monitors is inherently less legible than text printed on paper. Even old moldy cheap laserprinters use 600dpi, and paper doesn't suffer from even subliminally-perceived refresh rates. And I don't personally consider 10px type sizes readable! -- David gn...@hawaii.rr.com authenticity, honesty, community __ css-discuss [cs...@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 dilemma
On 2009/03/14 18:42 (GMT-1000) david composed: Well, in my 20+ years of using computers, including desktop publishing, graphic and web design work - I've never used a computer that had either Calibri or Vrinda on it. And I used to be a real font junky! (That spans every version of Windows, Mac OS7/8/9 and OS X, one version of UNIX and several distros of Linux.) Vrinda comes in right below Book Antiqua @ 84.58% on http://www.codestyle.org/css/font-family/sampler-WindowsResults.shtml I haven't figured out where Vrinda came from, other than it's a M$ font NAICT originally from mid-2004. Calibri is one of the standard Vista fonts, all of which are closer in apparent size to Times New Roman than Arial, Georgia or Verdana. http://fm.no-ip.com/auth/Font/fonts-msvista.html -- The plans of the diligent lead to profit as surely as haste leads to poverty. Proverbs 21:5 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ __ css-discuss [cs...@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 dilemma
On Mar 16, 2009, at 2:14 PM, Felix Miata wrote: Well, in my 20+ years of using computers, including desktop publishing, graphic and web design work - I've never used a computer that had either Calibri or Vrinda on it. And I used to be a real font junky! (That spans every version of Windows, Mac OS7/8/9 and OS X, one version of UNIX and several distros of Linux.) Vrinda comes in right below Book Antiqua @ 84.58% on http://www.codestyle.org/css/font-family/sampler-WindowsResults.shtml I haven't figured out where Vrinda came from, other than it's a M$ font NAICT originally from mid-2004. Calibri is one of the standard Vista fonts, all of which are closer in apparent size to Times New Roman than Arial, Georgia or Verdana. http://fm.no-ip.com/auth/Font/fonts-msvista.html Vrinda is part of a default install of Windows XP (I wouldn't know how it got installed on my VM's otherwise). The 'Vista' fonts, installed by Vista, Office 2007, Office 2008 Mac have an aspect ratio as follows: Calibri 0.467 sans-serif Cambria 0.467 serif Candara 0.464 sans-serif Constantia 0.453 serif Corbel 0.464 sans-serif Times New Roman 0.448 All those 'vista fonts' have a 'normal' line-height equivalent to ~1.220. Philippe --- Philippe Wittenbergh http://l-c-n.com/ __ css-discuss [cs...@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/
