"Nick Sabalausky" <a@a.a> wrote in message news:hu8rgi$q6g$1@digitalmars.com...
> "Matthias Pleh" <matthias.pleh@gmx.at> wrote in message news:hu8r4f$p6j$1@digitalmars.com...
>> thanks for your comments
>>
>> I've played around with the font-size problem and have setup a test page
>> under my folder on the wiki.
>> I also like the idea from Justin to make the look more like the official
>> d-page.
>>
>> So please have a look, comment here or change the files directly for the
>> testpage.
>> http://www.prowiki.org/wiki4d/wiki.cgi?MatthiasPleh/TestPage
>>
>
> Not a big deal (no pun intended), but the H1 and header/footer links seem absolutely enormous.
>

And the Links in the Table Of Contents box have way too much vertical spacing.

"Nick Sabalausky" <a@a.a> wrote in message news:hu8rih$qbg$1@digitalmars.com...
> "Nick Sabalausky" <a@a.a> wrote in message news:hu8rgi$q6g$1@digitalmars.com...
>> "Matthias Pleh" <matthias.pleh@gmx.at> wrote in message news:hu8r4f$p6j$1@digitalmars.com...
>>> thanks for your comments
>>>
>>> I've played around with the font-size problem and have setup a test page
>>> under my folder on the wiki.
>>> I also like the idea from Justin to make the look more like the official
>>> d-page.
>>>
>>> So please have a look, comment here or change the files directly for the
>>> testpage.
>>> http://www.prowiki.org/wiki4d/wiki.cgi?MatthiasPleh/TestPage
>>>
>>
>> Not a big deal (no pun intended), but the H1 and header/footer links seem absolutely enormous.
>>
>
> And the Links in the Table Of Contents box have way too much vertical spacing.
>
>

Other than those things, it looks good though.

>>
>
> Other than those things, it looks good though.
>
>

thanks!

I've tried to left out the specification of the font-size (as someone mentioned here), and the result was this big font!

But now it should look better.

Matthias Pleh wrote:
> thanks for your comments
> 
> I've played around with the font-size problem and have setup a test page
> under my folder on the wiki.
> I also like the idea from Justin to make the look more like the official
> d-page.
> 
> So please have a look, comment here or change the files directly for the
> testpage.
> http://www.prowiki.org/wiki4d/wiki.cgi?MatthiasPleh/TestPage
> 
	Mostly, looks fine here, except that having some headers smaller
than the text body looks funny (of course, h4, h5... are not used
that often in real pages).

	Your font specifications should always end with one of the standard
CSS font families ("serif", "sans-serif", "monospace", "cursive" or
"fantasy"), you should not assume that everyone has one of the fonts
specified explicitely ("Helvetica" for example is not that common in
the Windows world).

		Jerome

PS: btw, do you know browsershots? http://browsershots.org It allows you to see screenshots of how a web page looks on a wide variety of OSes and browsers (although of course you won't see the differences due to the screen that way).
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

> 	Mostly, looks fine here, except that having some headers smaller
> than the text body looks funny (of course, h4, h5... are not used
> that often in real pages).
>
> 	Your font specifications should always end with one of the standard
> CSS font families ("serif", "sans-serif", "monospace", "cursive" or
> "fantasy"), you should not assume that everyone has one of the fonts
> specified explicitely ("Helvetica" for example is not that common in
> the Windows world).
>
> 		Jerome
Ah, I see! I will have a look at this

>
> PS: btw, do you know browsershots? http://browsershots.org It allows
> you to see screenshots of how a web page looks on a wide variety of
> OSes and browsers (although of course you won't see the differences
> due to the screen that way).
Hey, really cool site. But it seems, that my testpage was already tested.

Am 29.05.2010 00:47, schrieb Matthias Pleh:
> I have renewed the layout of the wiki4d-site.
> It's not finished, but I think it is already useable!
> Content itself hasn't changed!
>
> Any thoughts?
> Please check also the links on the sidebar!
> I have taken this from a template from Justin Calvarese (thanks), so
> maybe some links should changed, reordered or even removed!
>
> greets
> Matthias

Great Work!

I especially like the D Logo in the banner. It looks amazing :]

-- 
ruunhb [AT] googlemail.com
http://www.ruuns.de/blog

Jérôme M. Berger wrote:
> Stewart Gordon wrote:
>> Matthias Pleh wrote:
>>> I have renewed the layout of the wiki4d-site.
>>> It's not finished, but I think it is already useable!
>>> Content itself hasn't changed!
>>>
>>> Any thoughts?
>> <snip>
>>
>> Get rid of the abomination that is font sizes in px!  Specify them in em
>> or, even better, not at all.
>>
> 	I agree that font sizes in px is an abomination, but font sizes in
> em is just plain ridiculous since 1em is defined in terms of the
> font size!

Not quite.
http://www.w3.org/TR/2009/CR-CSS2-20090908/syndata.html#length-units

"The 'em' unit is equal to the computed value of the 'font-size' property of the element on which it is used. The exception is when 'em' occurs in the value of the 'font-size' property itself, in which case it refers to the font size of the parent element. It may be used for vertical or horizontal measurement. (This unit is also sometimes called the quad-width in typographic texts.)"

> Use either pt (which should work if the os/browser is
> configured properly), percents, or the keywords (x-large, large,
> normal, small, x-small).

By suggesting pt, you have contradicted the point I was making.  The point is _not_ to inflict a fixed size.

No size specified
Pros: Conforms to the size setting that the user has set for his/her comfort
Cons: Some fonts look bigger or smaller at the same point size than the default Times New Roman, so the ideal size is dependent on the font

Size in em
Pros: Always scales to the user's font size setting.  Can be used to compensate for the aforementioned relative sizes of different fonts.
Cons: If used on body text, it's still annoying if you change the size significantly from the default.  Maintaining font sizes of elements relative to each other can get complicated.

Size keywords
Pros: Easy to maintain since you don't have to worry about how relative sizes work.  Zooms correctly in browsers.
Cons: Those of em, plus it's coarse-grained.

Size in pt
Cons: Those of em, plus in some broken browsers (such as IE) it overrides the text size/zoom option.

Size in px
Cons: All those of pt, plus works against the ability to change the system font scale.


But you can use em without it becoming too complicated.  All you need to do is:
- understand how em works (it's actually quite simple - see the quoted paragraph above)
- if you must change the body text size, do it by just setting it for the body element
- keep the font size scheme generally as simple as you can get away with

Stewart.

Adam Ruppe wrote:
> On 5/31/10, "Jérôme M. Berger" <jeberger@free.fr> wrote:
>> 	The problem is that px is not even theoretically reliable: it
>> depends on the screen you are viewing the page on.
> 
> That's true, it definitely changes across different screens.
> 
> I'm probably biased by the fact that the majority of the sites I've
> been doing are very picture and video heavy - the pixel measurements
> are always the right size relative to the images, which are also sized
> in pixels.

You mean if you're using inline images to present such things as mathematical expressions?  I'm never sure what's the best thing to do about this either.

>> Pt is an absolute measure
>> (there are exactly 72 points in an inch)
> 
> Huh, I read somewhere that it wasn't defined on screen, but only for
> printers. I guess I was wrong - the measuring tape agrees with you.
> Though, it still comes out different on my Linux box than it does on
> the designer's Mac, leading to bug reports whenever I try it.  I
> really don't know why, but I've gotta deal with it somehow.
<snip>

This is because an inch in the context of screen measurements doesn't correspond to an actual physical inch.  Rather, there is a setting somewhere in the OS that determines how many pixel side lengths constitute a logical inch (or centimetre or whatever).  On Windows, the factory default is 96dpi.  Other OSs might have different defaults.  In any case, it isn't right to work against this setting.

Stewart.

Jérôme M. Berger wrote:
> David Gileadi wrote:
<snip>
>> The bottom line for its recommendations is to use ems, plus
>> font-size:100% in the body tag.
> 	Funny thing is: they got it wrong! The text of that page is too
> small here...

Indeed, there are many web pages that don't practise what they preach. Take a look at this page
http://tinyurl.com/36pb56w
and then run it through a validator.  (Notice also the sheer mix of good and bad advice on that page!)

Stewart.

Adam Ruppe wrote:
> Going OT here, but I've gotta defend the pixel font sizes.
> 
> I used to do percents, (since I read somewhere that px is evil and
> zomfg never use it...) but I got tired of the constant "bug" reports
> coming in from the clients saying "it doesn't match the psd exactly on
> my Mac". Specifying them explicitly in px avoids this.
<snip>

People should get their heads around the fact that web design isn't about specifying the precise pixel position of everything.

See also this discussion I was once involved in:
http://tinyurl.com/3ysen6d
and in particular Alan J. Flavell's comment (number 12 in the tree).

Stewart.