Forum Moderators: phranque
As wide as your users want it to be.
W.
If a report has to be wider, I'll make it dynamic, but still fixed.
Set it for your screen and hope for teh best.
Fluid or Elastic is my preferred style.
Ta
Limbo
So if the page is primarily text and you let it just stretch to 100%, your readibility will likely be terrible if someone is on a 21" monitor set to a width of 1280 pixels or more. What you want to shoot for is
- 60-75 characters per line for adults
- less (40-50) for children.
I do academic publishing and there is a certain tolerance for even longer line lengths (actually, much longer in our micro-font footnotes), but you would never want to publish a trade paperback with lines as long as you can get away with in the academic world. This is all the more true on screen.
How to translate characters per line to standard CSS units isn't necessarily obvious as this is will depend on the font. Roughly, if you divide by two and add a bit, that gives you the width in ems. So for adults, you would like to keep text blocks under 40 ems for sure, preferably around 30-35em; smaller still if your main audience is learning readers.
I've started using max-width and the IE equivalent for large text blocks.
So in brief, fluid, yes, but only to a point when dealing with large blocks of straight text.
Resources
Ideal line length for content [maxdesign.com.au] from maxdesign
Max width in IE [svendtofte.com] from Svend Tofte
Tom
[edited by: Brett_Tabke at 12:29 pm (utc) on May 20, 2004]
[edit reason] Please reread the TOS. no sig files please. [/edit]
That's the point I was driving at in my previous post. You have to think not just about the small end, but how is your layout going to look on a giant monitor.
Tom
While the web has changed slightly how we receive the text we read, it hasn't changed the more basic limitations on memory and language that reading has for us.
If fluid sizing is a must, I'd agree with the above poster that setting page size at 90% (that's not a function of tables or divs, you can do that easily with either construction method) is a pretty good compromise.
What is especially interesting is the failure of organizations who should know better to implement this, like apache, w3c, etc. I've had to start using opera with its user css set to max-width about 40em to read some of these stupid tech sites, hopefully tech types will start realizing that the ideal width can and should be set in ems for paragraphs at least, but if they don't I may have to switch to opera if I can't find a comparable extension in firefox to fix this error.
<added>I found a good link on how to change user CSS [squarefree.com] in IE, Mozilla, and Opera, along with some interesting user CSS samples [squarefree.com].
I would say 100% is better.
This is not helpful. Isitreal and I have given some very good reasons based on rules that have been worked out over centuries of people doing text layout and, more recently, usability studies.
I've never seen a book laid out with the text block at 100% and I've never seen a book meant for public consumption with 100 words on a line and, aside from poetry and a few special uses, I haven't seen any books with five words on a line.
If you have a graphic-heavy page, then you need to have some folks with a good eye look and achieve the right balance. For text, though, you can't have a rule like "100%" or "750px".
It's like asking what size a book should be. My rule of thumb: 20cmW 30cmH and 325 pages long. Most people can fit this in their briefcase, so that's how big a book should be.
Tom
[webmasterworld.com...]
Personally, I like both, 100% or 90% fluid layouts together with setting:
p, li, blockquote, h1-6 at a max-width 38-40em, it's the best of both worlds, lets you take advantage of extra screen space for your side bars and floated sidebars when available, and maintains readability.
Commercially I'm sticking to 750px, it's just easier, most users don't resize, and a 600px column at normal font size is about the right width, I have no trouble making that kind of decision for visitors, it's the same as all print publishers have ever done for their readers.
I've also seen the argument: oh, you can always resize the screen if you don't like the size. Obviously by a person who only visits one site a day, and never uses tabs, or any other advanced features.
<added>Oh, just added a mozilla user stylesheet, now these threads have the right width, very nice, except for the first 'paragraph' of each posting, which isn't in a p tag, is there any particular reason that the first 'paragraph' is not a paragraph but uses only <font> tags, is it to avoid that margin-top default of p tags?
By the way, one major problem with the svend tofte method ... is that it breaks floats completely
Hmm. I hadn't noticed, though I have seen other mentions of the problem. So if I size a DIV with it, and the div is not floated, it's okay, or will I even have problems if the DIV is merely within a floated element or contains floated elements?
Personally, I like both, 100% or 90% fluid layouts together with setting: p, li, blockquote, h1-6 at a max-width 38-40em, it's the best of both worlds,
That's a good method. I was, of course, only referring to the width of text blocks, which might be all or only a small part of a given page. A page width of 100%=60em=750px (for example) might be just fine if there's 20-25em of graphics, sidebars and so on. It will be a sub-optimal with a full-width text block or, conversely with 45em worth of graphics and sidebars.
In other words, I am NOT saying that 100% is bad, just that it's a bad RULE (meaning, every situation needs to be treated individually). If you are putting your non-illustrated novel online, 100%, fluid layout is going to be terrible.
... it's the same as all print publishers have ever done for their readers.
Except, of course, they never expected their readers to have to scroll horizontally and vertically and turn pages.... ;-)
Truth be told, the same type of decisions are not always easy to make in print either. How much padding above/below a heading, what sort of running titles, etc etc etc. The big advantage and pleasure of working in print is that you can come up with a layout and be sure that everyone sees exactly that layout. You make decisions knowing what line length and page width every user will see. You can still create unreadable books, but it's generally a lot less frustrating (my books, by the way, are text only, but there are still a surprising number of issues to address when making camera-ready copy). The big bummer is that typos are forever!
Tom
So if I size a DIV with it, and the div is not floated, it's okay, or will I even have problems if the DIV is merely within a floated element or contains floated elements?
I'll describe the scenario where I found this to be a major problem.
<div width 90%>
<div to separate text block subdivisions, unsized, expands to fit containner>
<p using svendtofte method></p>
<dl floated, right, image and subtext>dl stuff</dl>
</div>
</div>
It was a little more complex than that, there is also a floated right column, but with container div having a margin equal to width of that column, but I tried putting max width on both the subdivision div and the p, IE could not handle it, the image dl would just vanish, there's something that happens in IE when float meets resize in the same container, I'm not sure what, but float is I believe incredibly difficult to program in, at least with the current IE 4-6 core that I believe MS is stuck with until IE 7.
the exact thing is a heavily modified but still similar to default looking wordpress page, to help you picture it.
But a technique that isn't stable like this isn't one I'm going to use, you never know what little thing you do will trigger it.
But check for yourself, this stuff can only be determined empirically, I just mentioned the float problem due to its extreme failure, if you can pinpoint the exact point that makes IE fail, that would be interesting, but I'm pretty sure that the float location is determined before the javascript runs, then when the javascript runs, it destroys the float.
If you are putting your non-illustrated novel online, 100%, fluid layout is going to be terrible.
Not just novel, any writing at all, the svendtofte example of
That policy has given us pages like usability guru Jakob Nielsen's rather unreadable site
is typical, the larger monitors get, the more extreme this problem is getting. I think this is simply due to the web being in its infant stages, only a few years ago did > 800 px widths become normal, before that most text did in fact fit quite nicely into 640 or 800 including leftnav, so this wasn't a particularly pressing issue, but now it is becoming one.
re: real print: it's still in my opinion far superior to web based print, except for the searchability question, I can absorb probably 10 times more information per hour by reading an o'reilly book than from searching php manuals or whatever, because there are editors, seasoned published authors, publishers, etc, professional levels that is, I forget this sometimes as I wade through the stuff on the web to learn stuff, then pick up a real book, the difference is stunning usually. Except for solving bugs and errors, then the web excells.
The layout decisions you mentioned are one large part of that, as is the impossible to get around fact that print is around 300-600 dots per inch, screen 72, which means a printed page is just easier to read because the text is much higher resolution.
Example, in 8 or 9 pages an o'reilly book [web database applications] gave me a radically better explanation of regular expressions than all of the online stuff I found referenced as authoritative combined, including all the links given by jdMorgan in the Apache forum re mod rewrite.
<added>As to the success of the DMCA [copyright.gov] in stifling high end content on the web... too sadly successful to contemplate, talk about a dead dream... along with the commercial difficulties of getting money from online writing... see the rapid switch to pay to view for online newspapers this and last year, for instance.
get around fact that print is around 300-600 dots per inch, screen 72,
Not to mention excellent control over dynamic range (light/dark contrast). It's still dependent on ambient light, but nothing like dealing with different computer setups.
Since I'm still using tables, (haven't upgraded to css yet) I like 85 - 90%, which seems to look acceptable on all monitor widths, and doesn't look really lame on huge ones like the fixed width pages do.
I wouldn't consider CSS an "upgrade" - Tables still rule the web, and in many ways are much better than CSS. Just because some W3C-supporting geeks on this board scream CSS is "better" doesn't mean it is :)
That aside, ergophobe's post hit the nail on the head. On my laptop, my resolution is 1024x768 so most web pages look great regardless of whether they are 100% or fixed-width text alignment. At my office machine however, my desktop resolution is twice that, 2048x1024. Pages that use 100% alignment tend to look HORRIBLE if I have my browser open full screen. When an entire paragraph is one or two lines on the screen it just looks bad and I get tired of reading it.
Most of you who are designing based on 100% are doing so out of consideration for resolutions lower than yours but didn't give any thought to resolutions GREATER than yours. 100% looks bad on more web pages than it looks good on for high-resolution systems. And sure, people who run at 2048 may be in the minority but wasn't the question about supporting everyone? :)
Fixed width is the way to go. Even though 800x600 is a minority (remember, anything less than 50% is a minority and 800x600 falls into this category) it's still a COMMON enough minority to base your designs on. A width of 780 (778 if you use 1-pixel borders on your tables) would look nice for everyone except 640x480 users. You can't please everyone, but I'd rather alienate the lowest minority than everyone higher than 1280x1024.
Maybe some of you CSS-heads know if there is (or ever will be) an "up to" option in CSS... where you can say the with should be 100% up to "X" pixels or something. If that feature exists, someone should give the poster code on how to use it. If not, it should be invented :)
The big advantage and pleasure of working in print is that you can come up with a layout and be sure that everyone sees exactly that layout
Not to mention that you have made something that actually exists, as an autonomous object, and doesn't depend on you paying your hoster or the hoster getting unplugged or a user owning a pc connected by wire to other pcs...
if there is (or ever will be) an "up to" option in CSS... where you can say the with should be 100% up to "X" pixels or something
that's what ergophobe and I are talking about, it's called:
min-width: 30em;
max-width: 38em; [or any other unit of measure, % etc]
IE doesn't support it, the fix we mentioned allows a virtual support of that through a proprietary IE CSS method, works ok, except in the instances I noted.
This type of thing is why people stop using IE, Opera and Mozilla support max-width, for example this thread motivated me to setup a user stylesheet with max-width for p, li, h1-6, blockquote that runs over all other stylesheets, so now for example I'm reading WebmasterWorld posts at 38 ems wide even though the page is at full screen, 90% width or whatever it's set to, 38 em is still a bit wider than standard print widths, maybe 36 em is closer.
