1 |
Sven Vermeulen wrote: |
2 |
|
3 |
>On Mon, Jan 17, 2005 at 09:36:47PM -0800, Aaron Shi wrote: |
4 |
> |
5 |
> |
6 |
>>Another thing was using |
7 |
>>a span and a CSS rule to make text italic, but(X)HTML already has such a tag |
8 |
>>for the exact purpose: <em>. |
9 |
>> |
10 |
>> |
11 |
I'm sure you know this, but just to expand on that explanation for |
12 |
people on this list that might not know, <em> is for /emphasising/ |
13 |
something, making sure people see that this is extra important. In a |
14 |
graphical browser the recomended way to show this by writing it in |
15 |
italics, but in other browsers it might be something else, eg a |
16 |
different color in a cli browser or a different tone of voice in a |
17 |
speach syntesizer. |
18 |
|
19 |
OTOH for things that are /not/ of extra high importance, just written in |
20 |
italics becuse it happens to look good, the construct with CSS + span is |
21 |
the apropriate method since span is a neutral container that won't get |
22 |
flagged as "IMPORTANT" in non graphical browsers. This btw was the |
23 |
reason the old <i> tag was deprecated/removed from the (x)html specs, it |
24 |
was ambigulent in if something was in italics becuse it was |
25 |
a) Important |
26 |
b) Prettier that way |
27 |
|
28 |
>>justify for the text (which has quirks when you try to print, |
29 |
>>but very negligible). |
30 |
>> |
31 |
We could always use non justified text in a CSS for media="print". Or |
32 |
does that still cause problem due to browserbugs? |
33 |
|
34 |
>>To address the issue of font sizes, I've implemented a font size changer on |
35 |
>>the content pages. The user could increase/decrease the content font size |
36 |
>>and the changes are saved into a cookie so that it will apply site wide. I |
37 |
>>think this give users flexibility without compromising the layout of the |
38 |
>>pages. Without this system, the user would use his browser to increase font |
39 |
>>size. The browser would increase all the fonts...making the navigation bar |
40 |
>>(and other) fonts extremely out of proporation |
41 |
>> |
42 |
That sort of works in most cases. |
43 |
But what happens if a user don't have eg JS or cookies turn on (for |
44 |
security/preference/whatever reasons)? The browser default setting is |
45 |
already applied site wide without any extra magic that may or may not work. |
46 |
|
47 |
And "making the navigation bar (and other) fonts extremely out of |
48 |
proporation" in regard to what? The graphics? What if forcing a fontsize |
49 |
on the navbar makes it compleatly unreadable on a users screen? I would |
50 |
prefer "slightly weird looking" above "compleatly unreadable navigation" |
51 |
on a site. |
52 |
|
53 |
In the days of a CRT doinated world it was pretty safe to make |
54 |
assumtions about users fontsizes, you couldn't go too wrong if it was |
55 |
readable to yourself. But nowdays there are really tiny LCDs with HUGE |
56 |
resolutions of 1280 or more. In a world where a user on a 14" monitor |
57 |
might be using anything from 640 to 1600 res, all bets are off. That is |
58 |
why I belive it's a better design principle to simply let go of textsize |
59 |
control and concentrate on making a design highly resilient to whatever |
60 |
fontsize is thrown at it. |
61 |
|
62 |
>>making the navigation bar |
63 |
>>(and other) fonts extremely out of proporation, causing it to wrap in the |
64 |
>>lower bound "designed for" resolution of 800x600. |
65 |
>> |
66 |
>> |
67 |
IMO that problem should preferably be solved by making the design adapt |
68 |
nicely when forced to wrap instead of trying to fixate the fontsize. |
69 |
Such a design would additionally be beneficial for when visitors don't |
70 |
have 800px res available, eg on PDA/Handhelds. Reading pages 3-4 |
71 |
screensizes wide is a PITA. Looking at your design I don't see any major |
72 |
reasons why we couldn't adapt it to behave well on as little as a 400px |
73 |
vert res or even smaller. |
74 |
|
75 |
/ Stefan :) |
76 |
|
77 |
-- |
78 |
www-redesign@g.o mailing list |