Forum Moderators: open
Does anyone know what technique(s) some sites are using to prevent a web user who likes to surf with text size set to Larger or Largest from messing up the display of their site in the users browser?
I've also noticed that changing the text size (in IE) has absolutely no effect on how some sites are displayed
IE will not resize text if font sizes are specified in PX.
Let me warn, however, that intentionally denying users the option to resize your text is a BAD idea. User who surf with the default text size increased generally do so because they NEED the text size increased; i.e., they can't see the text at a smaller font-size. Intentionally denying those users the ability to increase the size also denies then the ability to access your site.
On a personal/philosophical note, I believe the very nature of the web medium dictates the use of relative font sizing. The internet is not a place where creators dictate the experience, like a book or a TV show. Here, the user is supposed to be in charge. Fighting that can only serve to alienate/annoy them.
As to your other question: one way to prevent text size increases from destroying your site is to size both text and (certain) layout elements in EMs. This allows the font to be resized, and as the font resizes, the container will resize with it. This is especially handy with navigation items, where the 'button' will increase in step with the text and maintain a uniform appearance.
It also helps to design pages in such a way that large text areas (like content areas) have free reign to expand vertically as needed. In this case, a rigid width will not cause text size increase to affect the layout, since the box will simply expand down to accomodate the increase in line breaks.
I take the point about users wanting to resize text for accessibility reasons and creating flowing text, etc. but if you use frames or Iframes, fixing the size of text is handy to avoid scroll bars. If the text is clearly readably (12pt or larger) then there is no problem. However, I think both Mozilla and Opera will scale text however it is sized. (I'm away from home so I can't check this.)
Kaled.
specify font sizes in pt not px
If the text is clearly readably (12pt or larger) then there is no problem
Mozilla and Opera will scale text however it is sized
Jimmy
I don't normally design sites this way, but I've got one that has a fixed width and height. It explodes when you use too large a font.
Also, while I've used EM's with text, I never thought of using them for layout purposes. That's a great idea I'm going to start working with.
...design pages in such a way that large text areas (like content areas) have free reign to expand vertically
Yes! This points to an essential shift that HTML authors need to make to be comfortable on the web. HTML, at its root, is a "mark-up language" and not a layout utility. That's what the "ML" stands for.
So the basis, the root, the "genetic" heritage of HTML is a document in an abstract sense. It's a collection of semantic information, and not a fixed layout. This is a paradigm shift for the author, because we are very accustomed to layout thinking -- whether it's word processing or something more intesive like Quark or Pagemaker. But working in HTML with a layout mind-set makes for many different kinds of frustration.
The document and its semantics are the root of HTML. After years of evolution in HTML, this principle is, for instance, still reflected in the fact that images are display:inline by default.
Even before we talk about font-size, we can't depend that the user's version of a font will look exactly like the font on the original computer. There are hundreds of varieties of Arial, for instance, and each with slightly different letterforms and dimensions.
All the recent advances in CSS have still not turned HTML into a true layout utility. So it is important to understand this principle and accommodate it in our web authoring.
Search engines also become much more understandable when this conceptual shift is accomplished.
If an item is for sale, and its image and name are in one table cell but it's description and price are in another, then the relationship between the two bits of content is hard to uncover except through visual means. It gets even worse when nested tables are used to create margins and indents and such.
Thinking "markup" you can do a better job of making relationships in meaning and reference clearer -- even if you still use tables for some layout purposes. And you create documents that have enough breathing room to allow user agents the liberties that they will take anyway. They may not show exactly what you envisioned, but it will still be comprehensible and usable.
Thanks!
One "em" in a css rule means the font-size currently set within the element. So if you set the font-size for the <body> to be .8 em, it will be .8 times whatever font-size is set as the browser default.
However, I said "not on its own." In theory, if you give the body element a fixed unit font-size, like 12px for example, then anywhere else within that document, 1em means 12px, 1.5em means 18px, and so on.
I'm not sure how well this carries through practically on all browsers. I believe some older browsers incorrectly look to the default font-size set in their preferences whenever the em unit is mentioned, even though you declared a rule for the body element.
I find it much easier to declare the font-size in px whenever I want a fixed size. I also don't need to worry about whether the browser rounds up or down when the multiple of em results in a fractional number of pixels.
In theory, if you give the body element a fixed unit font-size
I recently discovered that doing this prevents users from being able to resize your text using "View->TextSize". Apparently, ANY non-relative font sizing keeps IE from resizing text when a user wants to, including a fixed size in the body rule decl. and EMs everywhere else. Pity.
There is nothing inherently resizeable about relative units. It's an IE thing.
Opera and Mozilla will resize pixel-based layouts and also layouts using em and percent.
