Sven Vermeulen wrote:
>On Mon, Jan 17, 2005 at 09:36:47PM -0800, Aaron Shi wrote:
>>Another thing was using
>>a span and a CSS rule to make text italic, but(X)HTML already has such a tag
>>for the exact purpose: <em>.
I'm sure you know this, but just to expand on that explanation for
people on this list that might not know, <em> is for /emphasising/
something, making sure people see that this is extra important. In a
graphical browser the recomended way to show this by writing it in
italics, but in other browsers it might be something else, eg a
different color in a cli browser or a different tone of voice in a
OTOH for things that are /not/ of extra high importance, just written in
italics becuse it happens to look good, the construct with CSS + span is
the apropriate method since span is a neutral container that won't get
flagged as "IMPORTANT" in non graphical browsers. This btw was the
reason the old <i> tag was deprecated/removed from the (x)html specs, it
was ambigulent in if something was in italics becuse it was
b) Prettier that way
>>justify for the text (which has quirks when you try to print,
>>but very negligible).
We could always use non justified text in a CSS for media="print". Or
does that still cause problem due to browserbugs?
>>To address the issue of font sizes, I've implemented a font size changer on
>>the content pages. The user could increase/decrease the content font size
>>and the changes are saved into a cookie so that it will apply site wide. I
>>think this give users flexibility without compromising the layout of the
>>pages. Without this system, the user would use his browser to increase font
>>size. The browser would increase all the fonts...making the navigation bar
>>(and other) fonts extremely out of proporation
That sort of works in most cases.
But what happens if a user don't have eg JS or cookies turn on (for
security/preference/whatever reasons)? The browser default setting is
already applied site wide without any extra magic that may or may not work.
And "making the navigation bar (and other) fonts extremely out of
proporation" in regard to what? The graphics? What if forcing a fontsize
on the navbar makes it compleatly unreadable on a users screen? I would
prefer "slightly weird looking" above "compleatly unreadable navigation"
on a site.
In the days of a CRT doinated world it was pretty safe to make
assumtions about users fontsizes, you couldn't go too wrong if it was
readable to yourself. But nowdays there are really tiny LCDs with HUGE
resolutions of 1280 or more. In a world where a user on a 14" monitor
might be using anything from 640 to 1600 res, all bets are off. That is
why I belive it's a better design principle to simply let go of textsize
control and concentrate on making a design highly resilient to whatever
fontsize is thrown at it.
>>making the navigation bar
>>(and other) fonts extremely out of proporation, causing it to wrap in the
>>lower bound "designed for" resolution of 800x600.
IMO that problem should preferably be solved by making the design adapt
nicely when forced to wrap instead of trying to fixate the fontsize.
Such a design would additionally be beneficial for when visitors don't
have 800px res available, eg on PDA/Handhelds. Reading pages 3-4
screensizes wide is a PITA. Looking at your design I don't see any major
reasons why we couldn't adapt it to behave well on as little as a 400px
vert res or even smaller.
/ Stefan :)
firstname.lastname@example.org mailing list