CSS The definitive guide -absolute and relative sizes
aa
The definitive guide.
The only thing I am not still absolutely sure about, is:
1. Is it correct to suggest that an absolute font size needs to be set
somewhere (say in the styles for the body), before using any relative units?
Consequently as NC's tables do not inherit, an absolute font size needs to
be set for every table before using relative units there, needs it not?
AA
Alan J. Flavell
> 1. Is it correct to suggest that an absolute font size needs to be set
> somewhere
Absolutely not. That's the reader's prerogative. Authors who try to
overrule that, at least for screen display, are what is known as
control-freaks.
Absolute font size (length units) are there in the CSS specification
for a purpose: the CSS spec says that it's for rendering situations
where the properties of the display are exactly known. For example if
you were designing a stylesheet for printing onto a known paper size.
> Consequently as NC's tables do not inherit, an absolute font size needs to
> be set for every table before using relative units there, needs it not?
I don't follow your logic there.
Not even if we decide to try to help out this lame creature. The
reader still has some normal text size configured (either deliberately
or by their inaction). The text won't just evaporate in a puff of
smoke without your setting an absolute size for it: it'll be rendered
relative to the user's default setting, which is meant to be their
favoured rendering size for normal text.
ttfn
aa
1." That's the reader's prerogative"
So you mean that the relative sizes are calculated using absolute sizes
which are set up on the user computer (unless absolute sizes are set by the
author) ?
If so, this answers my question.
2." Authors who try to overrule that, at least for screen display, are what
is known as control-freaks."
These control-freaks - are they considered to be good guys or bad guys?
Eric Meyer, who seems to be an authority in CSS, neither encourage nor
discourage the use of absolute units from this viewpoint.
AA
Alan J. Flavell <fla...@mail.cern.ch> wrote in message
news:Pine.GHP.4.21.00111...@hpplus03.cern.ch...
Sue Sims
...
>These control-freaks - are they considered to be good guys or bad guys?
>Eric Meyer, who seems to be an authority in CSS, neither encourage nor
>discourage the use of absolute units from this viewpoint.
P. 74, directly after Figure3-4
"This is an excellent example of why points should be avoided when
designing for the web."
That's pretty discouraging, eh?
Sue
aa
It is good to know the book that good, but you slightly missed the point of
my second question (please notice "from this viewpoint") as well as that
made by Alan.
The point seemed to be a moral one, rather than technical: font sizes being
the reader's prerogative and if overriding them is good or bad.
English is not my mother tongue, but for me freak has some negative taste
and this surprised me, because if control-freaks are bad things, CSS should
be made illegal as CSS are there to interfere with the user settings.
AA
Sue Sims <s...@sue-sims.nu> wrote in message
news:ru651t8sfa6rg0aoo...@4ax.com...
Alan J. Flavell
> The point seemed to be a moral one, rather than technical: font sizes being
> the reader's prerogative and if overriding them is good or bad.
No, you're over-stating the case. Setting an _absolute_ base for font
size is something which the _reader_ can do very effectively, but the
_author_ does not know the details of the reader's browsing situation
nor their needs, and so everything works much better overall if they
do not interfere with it.
In practice you will see this kind of author applying all kinds of
complex logic (if Mac, if Windows, what screen size, and so on and so
on) in a desperate attempt to compensate for the few differences that
they are able to measure[1]: but in doing so they only make things
worse in relation to many factors which they cannot measure - the
reader's eyesight being the one that is getting the lawyers
interested...
Certainly there's no objection to suggesting relative sizes (within a
reasonable range). Even in HTML2.0 - the first version of HTML to be
written down in the form of a formal specification - there is the very
reasonable _suggestion_ that headings should be displayed in a larger
font than normal text. This still remains only a suggestion, and
there are some browsers which have no alternative than to ignore it
(think of character cell browsers) and must indicate headings by some
other mechanism.
> English is not my mother tongue,
That should be no problem on usenet. I also participate in some
groups for which their language is not my mother tongue, and have
always been received with courtesy.
> but for me freak has some negative taste
I can assure you that it _is_ intended to be negative, yes,
> and this surprised me, because if control-freaks are bad things,
> CSS should be made illegal as CSS are there to interfere with the
> user settings.
Just keep in mind that the design of CSS is to _suggest_ an
appropriate presentation, that is aimed to be appropriate for some
range of browsing situations. The design includes the possibility to
offer several different stylesheets for different rendering
situations...
In the final analysis, the reader can turn off CSS styling entirely;
the art of applying CSS from the author side is to create suggestions
which don't have to be turned off, but which can be folded together
with the user's own preferences to reach a final rendering that
represents a good compromise between the users needs and wishes, and
the author's intentions.
Take another look at the FAQs, and see how this logic falls into
place.
You'll see some authors telling us "fixed size fonts are OK because if
the reader doesn't like them they can turn them off". Well, alright,
but why would I as an author want to rely on my readers having to
overrule my suggestions, when CSS has more appropriate ways of dealing
with that?
[1] I haven't time to write the long footnote that is needed here,
sorry.
Ian Graham
>
> Thanks, Alan.
>
> 1." That's the reader's prerogative"
>
> So you mean that the relative sizes are calculated using absolute sizes
> which are set up on the user computer (unless absolute sizes are set by the
> author) ?
> If so, this answers my question.
That's correct. The user (using browser configuration tools) sets
preferred 'default' font sizes and families (for regular text and
also for 'fixed-width/monospace' text), and these CSS property values
are 'inherited' throughout the document unless overridden by a style
sheet rule.
> 2." Authors who try to overrule that, at least for screen display, are what
> is known as control-freaks."
> These control-freaks - are they considered to be good guys or bad guys?
> Eric Meyer, who seems to be an authority in CSS, neither encourage nor
> discourage the use of absolute units from this viewpoint.
Being a control freak can have it's problems. Here are some examples:
* there are many different types of browsers, with different display
capabilities and sizes. Thus it's impossible to be a 'control
freak' and, and the same time, have your pages look and work well
on all these platforms.
* some users need to be able to adjust things like text size,
colors, etc., perhaps to account for vision problems (e.g., poor
vision, color blindness, etc.). Setting fixed, as opposed to
relative, font sizes, means that is can be difficult to 'rescale'
the page if the user wants to enlarge the text.
Thus, for visual display, it is 'safest' to use relative sizes, and
let the user choose what the sizes should be 'relative' to. But, if
you really need to fix the size, then you can try to do so, but at the
risk of having pages that are less usable on some browsers, or under
some circumstances.
Ian
--
http://www.utoronto.ca/ian/books/
- The XHTML 1.0 Language and Design Sourcebook (XHTML, HTML and CSS)
- The XHTML 1.0 Web Development Sourcebook (Site design and management)
- The XML Specification Guide - and several others .....
Scott Stevenson
>> 1. Is it correct to suggest that an absolute font size needs to be set
>> somewhere
>
> Absolutely not. That's the reader's prerogative. Authors who try to
> overrule that, at least for screen display, are what is known as
> control-freaks.
I think that's a bit extremist. In an ideal world, all font size are
relative for the widest accessibility, but there are always exceptions.
Sometimes the decision is not up to the author, but rather the author's
client/employer. The branding people may not want a gigantic default font
size (common in browsers that render at 96dpi) as the company's trademark.
You can also encounter a fundamental legibility problem. If the text is too
big for 85% of your audience, and a majority of the same audience doesn't
even know how to change the browser's default font size, then you've got a
barrier to entry. Plus, even if they do know how to change it, perhaps won't
for the concern of making the other sites too small.
I don't think there is an answer to this that doesn't have some
consequences. It has to be taken on a case-by-case basis.
- Scott
--
Scott Stevenson
Maxify Corp.
http://maxify.com/
Alan J. Flavell
> > Authors who try to
> > overrule that, at least for screen display, are what is known as
> > control-freaks.
>
> I think that's a bit extremist. In an ideal world, all font size are
> relative for the widest accessibility, but there are always exceptions.
Absolute length units don't work, in any technical sense, in a WWW
display context.
The results they produce in the range of presentation situations that
the designer had in mind aren't demonstrably better than doing the
right thing; and the results they produce in situations that are
outside of that narrow range are worse - or in some cases the fact
that they seem to work at all is based only on the inability of
browsers to actually implement the specification (i.e 12pt is required
to be precisely 1/6th of an inch on the 2cm wearable display just as
it is 1/6th of an inch on the lecture room or cinema projection screen
- what use would _that_ be to anyone?).
Absolute length units are in the CSS spec for a reason, and the CSS
spec tells you what that reason is: it's for when the characteristics
of the display are precisely known (I give you the example of a
stylesheet for printing on a known size of paper). They are
irrelevant to WWW screen display.
> Sometimes the decision is not up to the author, but rather the author's
> client/employer.
Then _they_ are the ones that qualify as control freaks.
> The branding people may not want a gigantic default font
> size (common in browsers that render at 96dpi) as the company's trademark.
"Gigantic" can still be measured in ems. If you specify, say, 2
inches for a wearable display, you're asking for the trademark alone
to be bigger than the entire screen. But on the cinema projector it
would come out tiny - if the projector implemented CSS correctly. Why
take that risk, when there's a right way to do it?
> You can also encounter a fundamental legibility problem.
Indeed you can, which is why specifying pt or other absolute length
units for an unknown display is misguided.
If you really, really wanted to specify an actual perceived size,
and if browsers really, really did support the CSS specification, you
would use CSS px units. Remember, these are not screen pixels.
But you'd still be discriminating against a subset of your users.
> If the text is too
> big for 85% of your audience, and a majority of the same audience doesn't
> even know how to change the browser's default font size, then you've got a
> barrier to entry.
You've already got a barrier to entry: the ability to read. Do you
address that by refusing to write anything, and trying to convey every
message in pictures only? No, that can be addressed (to some extent)
by using a speaking browser; refusing to write text would disadvantage
the people who already know how to read.
The problem that you are describing is one of user education.
Learning how to adjust a browser isn't rocket science. It isn't
comparable with having to learn to read.
> Plus, even if they do know how to change it, perhaps won't
> for the concern of making the other sites too small.
Then get them up to speed on using their browser.
Scott Stevenson
> * there are many different types of browsers, with different display
> capabilities and sizes. Thus it's impossible to be a 'control freak' and, and
> the same time, have your pages look and work well on all these platforms.
Actually my experience has been just the opposite. In fact, the only way I
have ever been able to get font sizes to appear roughly the same on all
platforms (in respect to the size of other page elements) is to use CSS
pixel units in font sizes. In general, I agree that relative sizes
throughout the web is the ideal, but there are obstacles to that utopia. And
in the interim, fixed sizes are sometimes required for the situation.
> * some users need to be able to adjust things like text size,
> colors, etc., perhaps to account for vision problems (e.g., poor
> vision, color blindness, etc.). Setting fixed, as opposed to
> relative, font sizes, means that is can be difficult to 'rescale'
> the page if the user wants to enlarge the text.
In my experience, MacIE5 and Mozilla appear have no problems resizing fonts
specified in pixel units.
Scott Stevenson
> The results they produce in the range of presentation situations that
> the designer had in mind aren't demonstrably better than doing the
> right thing;
The default font size in MacIE5 and Mozilla (96dpi) is quite jarring for Mac
users that have been used to browsing at 72dpi for years. The text just
seems plain huge and hard to read/navigate. Windows-centric sites figured
this out years ago. That's why such sites so frequently bring it down a few
notches just to bring it into the area of legibility. Sure, you can change
the defaults, but this affects all sites, not just the ones with large
fonts.
I'm not saying this is a good approach, I just don't think it's fair to
expect everyone to not use absolute units in all cases. The huge size of
default text in 96dpi browsers is not something that tends to appeal to the
marketing/branding department in my experience, and with good reason. It
looks wrong. Microsoft made some unfortunate decisions regarding font sizes
for their OS (which broke with desktop publishing standards), and it set the
precedent for the web.
I'm extremely in favor of making the display flexible for the user, and
content abstracted from the presentation as much as possible. I always try
to validate my documents. But it's a grey area. We need to be sensitive to
the fact that priorities are different for different people, and simply
declaring their priorities invalid is the wrong approach. We have to reach a
compromise of attractive presentation and accessibility.
> "Gigantic" can still be measured in ems. If you specify, say, 2
> inches for a wearable display, you're asking for the trademark alone
> to be bigger than the entire screen. But on the cinema projector it
> would come out tiny - if the projector implemented CSS correctly. Why
> take that risk, when there's a right way to do it?
I agree with you. I think we're in a transition phase right now. Ultimately,
I would expect myself and everyone else to be using relative sizes
exclusively. But I don't think we're in a position to throw away absolute
sizes just yet.
> If you really, really wanted to specify an actual perceived size, and if
> browsers really, really did support the CSS specification, you would use CSS
> px units.
I do.
I think we fundamentally agree what the right thing is to do, I just think
we disagree on how soon that is practical.
Alan J. Flavell
> The default font size in MacIE5 and Mozilla (96dpi) is quite jarring for Mac
> users that have been used to browsing at 72dpi for years.
So what? If they don't like it, the solution is in their hands, not
yours.
> That's why such sites so frequently bring it down a few
> notches just to bring it into the area of legibility.
Therby ensuring it's unreadable for anyone who's set a comfortable
size already.
> Sure, you can change the defaults, but this affects all sites, not
> just the ones with large fonts.
Gosh, that's exactly my point! One adjustment to each reader's
desired normal font size, and the job is done. Just as long as those
control-freak authors stop trying to mess everyone around.
> I'm not saying this is a good approach, I just don't think it's fair to
> expect everyone to not use absolute units in all cases.
Just re-read what you said. "this affects all sites". That includes
your "other cases" too, you know.
> The huge size of
> default text in 96dpi browsers is not something that tends to appeal to the
> marketing/branding department in my experience, and with good reason. It
> looks wrong. Microsoft made some unfortunate decisions regarding font sizes
> for their OS (which broke with desktop publishing standards), and it set the
> precedent for the web.
You're losing it again. There is no "huge size", not once the browser
has been commissioned for each user's requirements. At least, if
there is a "huge size" there's one of two explanations: either the
reader needs it, in which case it's discriminatory for you to
interfere; or it's not so far from what they'd like that they can be
bothered to find out how to change it.
Say, when you buy a new office chair, do you use it at the settings it
was delivered with, or do you find out how the adjuster works?
aa
I am the same oppinion, but pixels are considered as relative units, not
absolute ones, although for a given monitor they are absolute.(I am not sure
if the pixel size can be affected by changing display resolution Control
Panel).
As a lot of people seem to be against absolute sizes, using pixsels might be
a common denominator.
AA
Scott Stevenson <sp...@maxify.com> wrote in message
news:B638514F.7131%sp...@maxify.com...
Scott Stevenson
> I am the same oppinion, but pixels are considered as relative units, not
> absolute ones, although for a given monitor they are absolute.(I am not sure
> if the pixel size can be affected by changing display resolution Control
> Panel). As a lot of people seem to be against absolute sizes, using pixsels
> might be a common denominator.
> AA
I'm definitely have no complaints about using the pixel unit. If everyone
else is okay with this, then we may have found some common ground.
aa
From you definition, I am probably a control-freak because I really want my
work to be displayed to user as I did it, not as some fancy preference
setting could render it.
I heard someone saying "Who are you to override the user preferences?", and
the answer to that is "I am the author".
And the author has the right his creature to be seen as designed, not a
caricature of it.
I am not breaking into a user's machine and changing his preferencies. It is
the other way round, a user comes to me to see what I am doing and I think I
have the right to stick to my preferences.
Of course, if I care about my visitors, I should think of how my
preferencies would be delivered to the user. And here two things should be
separated:
1. Platforms considerations - these should be respected.
2. Fancy customer settings - I am inclined to ignore them, unless they are
dictated by some eyesight problems.
Let's take Windows. It is overloaded with all these bells and wistles like
customised desktop backgroungs, settable colors, fonts etc. I know a lot of
people getting hight from re-arranging these regularly. But I think these
preferencies is a crazy idea (again, except that for limited eyesight) which
should not be there (sure, they also contribute to the Windows' famous
instability). People still read Financial Times without asking it to be
printed with some Helvetica-Monospace-Italic on a blue paper rather than on
the pink. People are happy to stir with the stirring wheel and do not
request a customizeable car to set user preferences so that you can stir
with the gear stick using it as a joystick. And it is accepted that the
blind people cannot drive (except Al Pachino) - it is a fact of today's
reality.
I am making utility sites. I do not much care about colors, font-faces (as
long as they are easily readable) and try to make things simple and
convenient for the customers (and this approach also addresses those with
limited eyesight).
I care about font sizes (and CSS) mainly to preserve the page layout, to
make sure that elements do not overlap and the contents does not go outside
the screen (as you probably noticed from another message of mine, this is
the main problem with NC Layers, and that was the reason I applied to this
group, but so far there is no solution)
AA
Alan J. Flavell <fla...@mail.cern.ch> wrote in message
news:Pine.GHP.4.21.00111...@hpplus03.cern.ch...
aa
> was delivered with, or do you find out how the adjuster works?
Good example, Alan.
It is important to know where exactely you start to limit customer's freedom
to adjust your design.
If we proceed alone this root, the chair should allow to adjust the number
od legs and their positions, because 4 legs in a square might not fit onto
the carpet, the customer wants to install the chair on.
What if he adjusts it to 3 legs and puts them in one row and then crushes
his head?
AA
Alan J. Flavell <fla...@mail.cern.ch> wrote in message
news:Pine.GHP.4.21.00111...@hpplus03.cern.ch...
Dennis Guertin
"aa" <aast...@hkw.co.uk> wrote in message
news:3a13bf45$1...@news.star.co.uk...
>
> What if he adjusts it to 3 legs and puts them in one row and then crushes
> his head?
>
Ah, that's structure. I thought you were asking about "seat covers". ;)
Paint the legs and change the fabric to a nice tartan!
aa
An author has to decide where the seat cover ends and the legs start in his
design. Often too big a font size can collapse the whole page and in that
case the author not only has the right, but also has the duty to
control-freak it.
Of course, if a chair collapses after the seat-color is changed, something
wrong is in the design - but unfortunatelly this is almost the rule with
Netscape.
AA
Dennis Guertin <dguNO...@guertSPAMin.com> wrote in message
news:8v10qs$llp$1...@news.drenet.dnd.ca...
Dennis Guertin
> Exactely, Dennis, you've got my point.
> An author has to decide where the seat cover ends and the legs start in
his
> design. Often too big a font size can collapse the whole page and in that
No, no. I meant I get to change the chair AFTER I've got it from you. You
make
sure it's stable, durable (won't break) and comfortable. It'll be appealling
all on
its own just from that (to me). Leave the rest to me.
Scott Stevenson
> I think a bigger problem was that *developers* were used to Mac users
> browsing at 72dpi. Many sites worked around the 96dpi/72dpi difference by
> the lousy solution of sniffing the OS and sending pages with bigger
> point sizes to Macs.
That may have been part of it. But assuming the following page:
<html>
<head>
<style type="text/css">
P { font-family: Verdana; }
</style>
</head>
<body>
<p>Here is some text</p>
</body>
</html>
The text is way too big to be comfortably legible for normal text. It would
be appropriate for a heading. And while this is somewhat subjective, it is
considerably larger than the size of fonts in the Mac menu bar, and at least
twice as large as the default text size for plain text messages in Outlook
Express. Furthermore, putting a paper book up to most screens would yield an
on-screen font size about twice as large as the printed text (varies by
screen resolution, I'm making some assumptions based on experience).
The problem is that when the text gets too large, it reduces the speed at
which we can read. I'm no expert, but I believe this is partially due to
shape recognition. In normal situations, the brain doesn't look for each
individual letter of a word, it scans paragraphs for shapes that it
recognizes as certain words or short sentences. Making the text too large
breaks this reflex, and makes it much harder to read. The same thing happens
when text is in all caps -- the letters lose a lot of their familiar shape
definition, so we have to revert to reading each word separately.
I agree that the default font size for IE 4.5 and Netscape 4 (both at
72dpi), was too small, but the default size of Verdana in the above example
is just too big. A height of 14px seems to bring it into the comfort range.
And the nice thing is that it "fixes" both 72dpi browsers and 96dpi browsers
at the same time, as long as they support CSS. Times seems to be quite a bit
more acceptable at its default size, however.
> 96dpi isn't a font size, it's an assumed monitor resolution. As such it isn't
> inherently any better or worse than 72dpi. It's a question of how the default
> font point size, or the font size set by some page that uses pt units,
> interacts with *that*.
I realize 96dpi isn't a font size. This can certainly be a confusing topic.
The nomenclature actually encourages some of the confusion. However, the end
result is that when pages are rendered at what the browser considers 96dpi
(the Windows display standard, and the W3C recommendation), the fonts end up
being much larger.
Matt McIrvin
<sp...@maxify.com> wrote:
>The default font size in MacIE5 and Mozilla (96dpi) is quite jarring for Mac
>users that have been used to browsing at 72dpi for years.
It was a terrible shock not to squint at everything any more.
I was overcome with the vapors. Also, I had to part with my
beloved microscope...
I think a bigger problem was that *developers* were used to Mac users
browsing at 72dpi. Many sites worked around the 96dpi/72dpi difference by
the lousy solution of sniffing the OS and sending pages with bigger
point sizes to Macs. Of course this made the fonts look huge on Macs
when the difference went away, until the authors tweaked their scripts
to take the newer browsers into account.
96dpi isn't a font size, it's an assumed monitor resolution. As such it
isn't inherently any better or worse than 72dpi. It's a question of how
the default font point size, or the font size set by some page that uses
pt units, interacts with *that*.
I'd say more about IE5's default font point size except that I can't
remember what it was; I tinker with these things almost immediately. It
is, of course, sad that most people don't, and that we've gotten into a
vicious circle that may actually discourage them from doing it... see
http://css.nu/articles/font-analogy.html for Todd Fahrner's insightful
take on the sorry state of affairs.
--
Matt McIrvin http://world.std.com/~mmcirvin/
Matt McIrvin
>2." Authors who try to overrule that, at least for screen display, are what
>is known as control-freaks."
>These control-freaks - are they considered to be good guys or bad guys?
>Eric Meyer, who seems to be an authority in CSS, neither encourage nor
>discourage the use of absolute units from this viewpoint.
From my perspective, it's essentially always bad to use absolute font size
units in author CSS intended for screen display... except for one glaring
thing: px units are the only ones that work really well in Netscape 4
(relative units are afflicted by various problems of inheritance).
This is one of the many areas in which Netscape 4's bugs ruin the Web
for everybody. Internet Explorer 3 is even worse-- *any* use of relative
units will *completely destroy* a page rendering in IE3. But IE3 is
almost completely extinct, whereas Netscape 4's undead corpse still
shambles about the earth wreaking a horrific vengeance upon the living.
So if you *don't* want to do convoluted browser-sniffing stuff, you pretty
much have to use px or nothing. Zeldman took a lot of heat for saying
this, but I think he was more or less right.
I do the rough moral equivalent of browser-sniffing through the @import
hack, which has its dangers but works most of the time. So I can use
relative units on good browsers and nothing on NS4, and that works pretty
well... unless somebody uses one of the NS4 versions that crashes on
@import.
Basically, you can't win. Abandon all hope ye who enter here. The only
safe thing is never to set any font sizes ever, or do *anything* that
involves size units (in other words, avoid maybe 80 percent of CSS1), until
the really bad browsers are flushed from the universe several years from
now. Of course, foolish monkey that I am, I'm not satisfied with that.
J.B. Nicholson-Owens
> From you definition, I am probably a control-freak because I really want my
> work to be displayed to user as I did it, not as some fancy preference
> setting could render it.
Then you've picked the wrong medium in which to express yourself.
Unfortunately I doubt there is a medium in which the author has as much
control as some web authors think they have on the web. People can and will
view your webpage on a variety of devices where you have no control over the
rendering. Get used to it. Books can be read in suboptimal light, the
pages can be read out of order. Some readers skim text instead of reading
thoroughly looking for deep meaning. I can't think of a medium where
authors have as much control as some web authors think they have on the web.
In my opinion this form of control is a myth.
I'm sure various web FAQs can give you plenty of examples of how web-based
presentation control just doesn't work.
> I am not breaking into a user's machine and changing his preferencies. It is
> the other way round, a user comes to me to see what I am doing and I think I
> have the right to stick to my preferences.
Legal rights don't enter into it. If rights ever did matter here people
would argue the other way saying they've always felt free to read a book
with a magnifying glass or use browsers that let them ignore various markup,
not render images (or not render certain images like ads).
> Alan J. Flavell <fla...@mail.cern.ch> wrote in message [...]
Please don't repost the entire thread up to the point of your contribution.
People don't need to download the same article more than once and poorly
requoted text doesn't assist in maintaining context.
Etan Wexler
webm...@nospam.the-isg.co.uk (Webmaster @ the ISG) wrote:
> >The majority of your text you set at size 'small'. Why do you decrease
> >the font size?
>
> Layout and readability. Larger text reduced the area of the page
> available under 800x600, while the smaller font size means that I can
> maintain the overall layout, without sacrificing the look and feel of
> the site.
How can you know what the font size 'small' is on an arbitrary system
originating a request to you? The plain fact is that you cannot know the
result of 'small'. If current browsers share a narrow range of results
for 'small', this phenomenon is by happenstance, not by mandate of the CSS
specification.
The 'small' font size is not even guaranteed to be smaller than the
'medium' font size. The CSS2 specification makes no rules regarding the
relations of sizes linked to font size keywords:
<http://www.w3.org/TR/REC-CSS2/fonts.html#value-def-absolute-size>. The
following rule, though not normative, is sensible and follows the
precedent of <border-width>. For a given document:
xx-small <= x-small <= small <= medium <= large <= x-large <= xx-large
> >At the end, your copyright statement (with curious
> >implications for caching)
>
> Sorry? I don't follow?
The copyright statement prohibits routine, non-malicious, beneficial
caching of resources from your Web site:
"The only internet site these pages should be present on, are the
Impossible Scenarios Group pages at http://www.the-isg.co.uk/index.html,
and it's sub-pages. Any other location is a breach of copyright, and WILL
be dealt with through legal methods."
> >is set in size 'x-small', which is yet more
> >puzzling. Why would you diminish the readability of the statement if you
> >intend that people understand and respect your copyright?
>
> In the UK, copyright exists from the moment of creation. The page
> renders correctly under IE, which (unfortunately to some, I suspect!)
> is my preferred browser. Your is the first comment on this in over
> five years, by the way.
I have not disputed your legal retention of copyright. I am noting that,
if you desire that people understand and respect your legal copyright, you
should take measures to notify people of your copyright, not to obscure
the fact of your copyright. Having a copyright notice at all is a good
first step, but why suggest text that is less legible than the default?
You write that the text "renders correctly under IE"; I do not understand
what you mean. Regardless of that, 'x-small' clearly suggests a font
smaller than the default font and so is less legible than the default
font. Whether the less legible 'x-small' font remains in a zone
comfortable to a given reader is a matter determined case by case.
Perhaps my comment on the copyright notice is the first in five years
because previous readers either missed the notice (perhaps because of the
diminished font size) or read the notice and did not care. Of those who
read and did not care, I guess that the majority did not care because they
had no intention of violating your copyright while the minority did not
care because they knew that the chances are tiny of you finding them in
violation of your copyright.
--
Etan Wexler
"Stand back, son. Them's some trouble." --British football hooligan
advising his 10-year-old son at a riot.
Etan Wexler
mmci...@world.std.com (Matt McIrvin) wrote:
> I'd say more about IE5's default font point size except that I can't
> remember what it was; I tinker with these things almost immediately. It
> is, of course, sad that most people don't, and that we've gotten into a
> vicious circle that may actually discourage them from doing it... see
> http://css.nu/articles/font-analogy.html for Todd Fahrner's insightful
> take on the sorry state of affairs.
The way out of this sorry state of font size affairs is better support for
user control of style. First, user agents must make the editing of style
sheets comprehensible and readily accessible. Then, user agents must
provide a means to associate certain style sheets and style settings with
a given Web site or subsite or document, and maybe with MIME types.
Refusal settings that ignore author style sheets and stylistic markup must
have the same fine granularity. When users can isolate and correct
annoying styles without affecting their general browsing, poor author
style will matter much less.
Among style settings that CSS cannot and should not express but that the
user should control are the font faces used for generic font families, the
font sizes of the font size keywords, and the size of the 'px' unit.
Associating style sheets with documents is not the tough part; crafting a
user interface that encourages users to choose their settings is the tough
part. So, which browser will have this feature first: iCab, Mozilla, or
Opera?
Etan Wexler
(J.B. Nicholson-Owens) wrote:
> I can't think of a medium where
> authors have as much control as some web authors think they have on the web.
Art in a gallery or in a museum can be such a medium. Lighting, viewing
distance, viewing angle, ambient temperature, and level of noise are all
under the control of the presenters rather than the viewers.
Scott Stevenson
"But IE3 is almost completely extinct, whereas Netscape 4's undead corpse
still shambles about the earth wreaking a horrific vengeance upon the
living."
This is definitely the most entertaining thing I've read on usenet in some
time.
aa
>People can and will > view your webpage on a variety of devices where you
have no control over the
> rendering
Theoretically this is true. In practice he who trys to please everyone,
pleases none.
One cannot write code which would be eqially viewed on a desk-top color
monitor and on WAP phone. Still some people use 640*480 monitors and some
still use black-and-whites. Some are using browsers which do not support
scripts, CSS, even frames and pictires. To please all these one has to stick
to the very basic stuff which would appeal to nobody.
Of course you can set up a separate code for everyone of the abovemention
groups, but this is not practical and cost prohibitive.
A lot of people are taking executive decision to limit the audience to those
with more or less up-to-date equipment and this is the only way to progress.
Netscape set an interesting example by dropping all pre-NC6 specific
features in NC6 - why should web-authors care about Netscape's customers
more than Netscape does?
J.B. Nicholson-Owens <j...@forestfield.org> wrote in message
news:slrn919lv...@next.forestfield.org...
Scott Stevenson
> Then you've picked the wrong medium in which to express yourself.
Funny, I thought that was up to us to decide. :)
> Unfortunately I doubt there is a medium in which the author has as much
> control as some web authors think they have on the web. People can and will
> view your webpage on a variety of devices where you have no control over the
> rendering.
I'd like to try to bring this statement out of the vast generalization zone
and back into reality. You have to take the audience into consideration.
You're not going to browse GameCenter on a mobile phone. You're not going to
have WebTV users checking out code at JavaPro. And you sure as hell aren't
going use a refrigerator to download Quake 4.
These devices that are popping up -- mobile phones, Palm VII, etc -- have
internet access for specific purposes. Even the Palm VII uses web clippings
rather than just setting you lose on the web. Without customization,
Yahoo.com not be practical for a PCS phone. You need a customized version of
the interface.
So just throwing up your hands and saying that's it's useless for designers
to try to make sites render in the intended way, all because it won't look
right on my bagel toaster seems a bit extreme. I think it's wiser to focus
on balance. Try to figure out what the needs of both sides are
(aesthetics/accessibility), and find a common ground.
Person 1: "We need full layout control"
Person 2: "You should have no layout control"
Person 1: "We need full layout control"
Person 2: "You should have no layout control"
Seems silly, eh?
> I'm sure various web FAQs can give you plenty of examples of how web-based
> presentation control just doesn't work.
The truth is that with CSS1 and CSSP, it actually does work quite well in
the vast majority of cases. Whether you personally want this to be the case
or not is another matter. But this positioning and formatting tools and
standards are there for a reason: because humans are visual creatures.
Alan J. Flavell
> Person 1: "We need full layout control"
> Person 2: "You should have no layout control"
Neither. In the WWW, you as author have no 'control' in any absolute
sense.
You can only make suggestions. Even your _content_ is capable of
being filtered (e.g to avoid offending the residents of Scunthorpe or
those of a particular religious persuasion). But the usual principle
that's applied is that the structural HTML is the key content, while
the presentation is optional.
> The truth is that with CSS1 and CSSP, it actually does work quite well
The truth is that it works very well, in the sense that it can do
what's suggested when that's appropriate, whereas it does no
harm when the reader needs to - or chooses to - disable it.
That's assuming that, in a WWW context, you are using it in an
appropriate way.
If, on the other hand, you had control over your reader's browsing
situation, things would be different - in the sense that you could
force it to work and you'd find yourself in court much faster for
violating the applicable disability discrimination legislation.
> the vast majority of cases.
We don't really know, because there's still far too many instances of
bug-ridden browser versions out there. See my recent accident with
blockquote.
> Whether you personally want this to be the case
> or not is another matter. But this positioning and formatting tools and
> standards are there for a reason: because humans are visual creatures.
That statement is discriminatory. CSS's visual presentation
suggestions are designed to do no harm to those who cannot perceive
them, and rightly so too.
--
3/4 meiner Kunden sagt von sich, dass sie keinen Wert auf Animationen, bunte
Bilder und Effekte legt. Und die gleichen 3/4 sagen mir, dass ich sowas
machen soll, da alle ihre Kunden das wollten. - Steffi Abel
Alan J. Flavell
[..]
> The text is way too big to be comfortably legible for normal text.
No, it isn't any particular size at all. You as author have sent it
out marked as normal text. That's the correct thing to do. You've
now displayed it on a browser that hasn't been commissioned correctly
according to your requirements. So it's the browser that needs
adjusting, not the source.
Think of that office chair again. Do you blame the manufacturer or
the supplier for the fact that when it came, it wasn't properly
adjusted to your measurements? Neither of them did anything wrong.
> The problem is that when the text gets too large, it reduces the speed at
> which we can read.
No, the problem is that your browser isn't properly adjusted, and
you're putting the blame for that in the wrong place. The remainder
of your detailed arguments are otiose.
regards
Scott Stevenson
>> Person 1: "We need full layout control"
>> Person 2: "You should have no layout control"
>
> Neither. In the WWW, you as author have no 'control' in any absolute sense.
> You can only make suggestions.
Whatever you want to call it. I'm not suggesting that the hand of God comes
down out of the sky and positions the image at top: 120; left: 200. The
point is that with the vast majority of desktop browsers (yes, we DO know
that), the aforementioned positioning will be respected. I call this
control. You can call "peanut butter and jelly on rye" if you like.
I don't think anyone here is under the impression that these positioning or
font rules will apply to mobile phones or Palms.
>> the vast majority of cases.
>
> We don't really know, because there's still far too many instances of
> bug-ridden browser versions out there. See my recent accident with
> blockquote.
Actually, we do know by doing testing.
>> Whether you personally want this to be the case or not is another matter. But
>> this positioning and formatting tools and standards are there for a reason:
>> because humans are visual creatures.
>
> That statement is discriminatory. CSS's visual presentation suggestions are
> designed to do no harm to those who cannot perceive them, and rightly so too.
Damn. I really was hoping to do some harm.
Scott Stevenson
>> The text is way too big to be comfortably legible for normal text.
>
> No, it isn't any particular size at all. You as author have sent it out
> marked as normal text. That's the correct thing to do. You've now displayed
> it on a browser that hasn't been commissioned correctly according to your
> requirements. So it's the browser that needs adjusting, not the source.
Again, this is a theory vs. reality situation.
The theory is that all sites should use relative sizes and the user should
adjust the defaults. The reality is that most sites already bring the font
size down into the legible range on the most popular browsers (not saying
this is good). Leaving it at the default size means that most people will
see it to large. If they resize their defaults, the rest of the web will be
too small. They're not going to do this, and I can't afford to have people
not visit a site simply because the text is hard to read (or just plain
ugly) at its default size. I have bills to pay.
In the ideal world, all sites would use relative font sizes and the user
could set the size to their preference. But this just isn't the case. In
many cases, I cannot simply ignore the majority to comply to a theory or
spec. It has to be practical to do so.
> Think of that office chair again. Do you blame the manufacturer or the
> supplier for the fact that when it came, it wasn't properly adjusted to your
> measurements?
This is a nice little analogy but doesn't address the fact that many web
users can barely bring up a web site, let alone understand how to set their
default font size or understand the repercussions of doing so. My mom, for
example, is still at the stage where she'll occasionally type an email
address in the URL field and expect to see a web site. She does, however,
know how to adjust a chair height.
The problem is many sites need these people, regardless of their ability to
adjust their own font size.
Alan J. Flavell
> Damn. I really was hoping to do some harm.
<fairy-godmother>
"And so you shall!" -
Maxify Spacer Home Image
Home
Develop
Design
Contact
About
</>
Matt McIrvin
<sp...@maxify.com> wrote:
>The theory is that all sites should use relative sizes and the user should
>adjust the defaults. The reality is that most sites already bring the font
>size down into the legible range on the most popular browsers (not saying
>this is good). Leaving it at the default size means that most people will
>see it to large. If they resize their defaults, the rest of the web will be
>too small. They're not going to do this, and I can't afford to have people
>not visit a site simply because the text is hard to read (or just plain
>ugly) at its default size. I have bills to pay.
I think that here you've put your finger on the real problem; it's the
"devolutionary" spiral that Fahrner talked about. The default is big;
Web pages often decrease the font size relative to the default, or
reset it entirely; so there's no incentive (or an active disincentive)
for anyone to change the default and the vicious cycle continues.
Perhaps site designers aren't the ones we should expect to break the
cycle, since they have their bills to pay. The browser manufacturers are
taking some positive steps to break it at long last. I like browsers such
as IE5/Mac (and, apparently, Mozilla/NS6 for Windows[1]) that let users
rescale ALL text, *including* the text that has been sized with absolute
units. (I don't care what the standards say about the legality of this,
one way or the other; it's clearly a good thing for users, so I'm all
for it.)
However, it's still too obscure for most users to mess with. IE5/Mac lets
you put the requisite buttons on the toolbar, but they're not there by
default; you have to use a menu item.
I have a proposal. Computers should have a font size knob. I don't mean
some onscreen virtual gadget, I mean a physical knob. I don't know
whether it should affect things like menu bar fonts or just content of
application windows. It should at least rescale fonts in the content of
Web pages. A knob is obvious and tactile enough that people are going
to *want* to twiddle it until the screen looks right for them. Maybe
they can put it on keyboards, if there's enough space in between all
those little rubber buttons that bring up MSN and Yahoo.
Maybe paint it bright red.
[1] There have been reports that the control is mysteriously missing in
NS6/Mac, though not Mozilla/Mac. I wouldn't know, since I haven't been
able to get NS6/Mac working at all; the stupid thing just puts up a
splash screen and freezes. Maybe I oughta try Mozilla M18...
Scott Stevenson
>> Damn. I really was hoping to do some harm.
>
> <fairy-godmother>
> "And so you shall!" -
>
> Maxify Spacer Home Image
>
> Home
>
> Develop
>
> Design
>
> Contact
>
> About
>
> </>
Is there a problem?
Alan J. Flavell
> > Maxify Spacer Home Image
> Is there a problem?
No, there's two. One is the obvious problem; two is that you can't
see it.
You probably think this is a perfectly fine web page too (which I just
saw posted to the uk web authoring group, and promptly lifted for my
"howlers" collection):
Welcome to...
Borough Crest
The Borough of
On-Line
Having problems accessing our site? [Click Here]
Matt McIrvin
>Theoretically this is true. In practice he who trys to please everyone,
>pleases none.
>
>One cannot write code which would be eqially viewed on a desk-top color
>monitor and on WAP phone. Still some people use 640*480 monitors and some
>still use black-and-whites. Some are using browsers which do not support
>scripts, CSS, even frames and pictires. To please all these one has to stick
>to the very basic stuff which would appeal to nobody.
Occasionally I get nice e-mail from people who read my Web site. I assume
that it appealed to them somehow. I'll admit that that's more for the
words than for the look, which is kind of austere though not 1994 gray,
and I probably couldn't make any money off of it; there's a certain luxury
associated with not doing this for a living, and not being beholden to
clients, bosses or the marketing department. But I have some evidence
that *somebody* likes it.
Anyway, my pages are supposed to be bare-bones usable on Lynx, OK-looking
if plain on Netscape 2 through 4 and iCab, better-looking on Opera, and
moderately pretty with nifty things like tooltips and hover coloring on
IE4/5 and Mozilla.
*Everybody* gets the same HTML. The only differences are in the CSS,
since some browsers don't have CSS support and others get different styles
through the use of the @import hack... if I were a pro I'd probably use
server-side browser sniffing instead, and serve two or three different
stylesheets, but no more. In historical terms, I wouldn't call them
technologically backward; I use some features that first became
standardized in CSS2, for instance.
I doubt it would be usable on a WAP phone, but I'm skeptical that anyone
can do much of anything on a WAP phone. However, I can imagine someone
browsing it on, say, Opera for Psion/EPOC without any trouble.
Sometimes I slip up, and there are some very buggy browsers (such as very
early NS4 versions) that it will break, but I consider support for
egregious bugs slightly less worthy of my time than support for simple
browsers.
I use pictures, CSS, even a table layout on the front page. I guess I
*am* being slightly exclusionary there, since browsers with absolutely no
table support (Mosaic 1, early Lynx versions) might have trouble with it.
But the bar is set pretty low.
I hear lots of complaints to the effect that a site won't work *really
well* on text or audio browsers, etc., without a lot more work (see the
latest A List Apart), but these days the people who rely on such things
aren't asking for them to work really well; they'd be somewhat satisfied
if they worked at all.
>A lot of people are taking executive decision to limit the audience to those
>with more or less up-to-date equipment and this is the only way to progress.
>Netscape set an interesting example by dropping all pre-NC6 specific
>features in NC6 - why should web-authors care about Netscape's customers
>more than Netscape does?
A thing that bothers me is that some sites exclude browsers even when
it would be trivial to let them in. This is not as common now as it
was in the olden days of Netscape 2 dominance, but there are still some
that will kick out Opera users even though Opera is fully capable of
rendering the site. In other cases, it might take a little bit of
work to support more platforms, but not as much as is expended on
excluding them: ALT tags are *easy*, JavaScript that tells people to go
away is harder.
I am reassured by the karmic justice of the fact that these same sites
often kick out indexing spider bots, often because they are "non-frames
browsers," and then the authors express puzzlement about why they don't
get the search engine hits.
The other thing that bothers me is that many sites are written without an
eye to *forward* compatibility, which is what you get when you follow
standards. When Netscape dropped NS4 proprietary features, it was in
order to move forward and embrace standards. There are many exclusionary
Web developers who ignore standards and build to certain client browsers;
then they complain vociferously about "browser bugs" when their pages
break in the next one that comes along.
Scott Stevenson
> [1] There have been reports that the control is mysteriously missing in
> NS6/Mac, though not Mozilla/Mac. I wouldn't know, since I haven't been
> able to get NS6/Mac working at all; the stupid thing just puts up a
> splash screen and freezes. Maybe I oughta try Mozilla M18...
I haven't tried NS6/Mac yet, but M18 does have text zooming.
Scott Stevenson
> No, there's two. One is the obvious problem; two is that you can't
> see it.
There's no need for personal attacks, thank you.
> You probably think this is a perfectly fine web page too (which I just
> saw posted to the uk web authoring group, and promptly lifted for my
> "howlers" collection):
Rather than speaking in riddles, you could tell me exactly when you believe
to be wrong with the site?
It validates, all the images have alts, and all of the links have titles.
The home page intentionally has no textual content because it is a
graphic-design centric site. You should have no trouble navigating the site,
even with Lynx.
Alan J. Flavell
> A thing that bothers me is that some sites exclude browsers even when
> it would be trivial to let them in. This is not as common now as it
> was in the olden days of Netscape 2 dominance, but there are still some
> that will kick out Opera users even though Opera is fully capable of
> rendering the site.
Some also kick out Netscape 6, and demand that one upgrade. To what
is unclear. Some authors are just to dumb to be trusted to put
anything on the WWW.
> I am reassured by the karmic justice of the fact that these same sites
> often kick out indexing spider bots, often because they are "non-frames
> browsers," and then the authors express puzzlement about why they don't
> get the search engine hits.
See the summaries when they _do_ manage to get indexed!
J.B. Nicholson-Owens
> Funny, I thought that was up to us to decide. :)
I never said it wasn't up to you to decide. I said the poster picked the
wrong medium if they want the kind of control they advocate. I am not
stopping anyone from using the web for purposes that don't meet their
control requirements.
> I'd like to try to bring this statement out of the vast generalization zone
> and back into reality. You have to take the audience into consideration.
And the audience uses browsers (even broken ones), proxies and displays that
might not render your page the way you think it should be rendered. Since
you think obeying markup is the norm, visit an about.com link to a
non-about.com page and notice the about.com banner frame. Someone who knows
less about the web than you and I might think about.com operates a lot more
of the web because of this reframing. Try visiting an ad-sponsored proxy
sometime and notice how every page proxied has an ad banner on the top
(again, only if you obey the markup suggestions).
I doubt the authors of destination pages are told beforehand their their
pages are being presented with this additional content. This might not be
how they intend users to view their page, yet this presentation exists.
These examples lie completely within the desktop browser user group you want
to focus on so even if you want to ignore alternative web UAs, these are
concrete examples of how you can't predict how your page will be seen.
> So just throwing up your hands and saying that's it's useless for designers
> to try to make sites render in the intended way, all because it won't look
> right on my bagel toaster seems a bit extreme.
Again, I never said it was useless, I said you can't guarantee your
presentation suggestions will be honored. Check my previous posts to
web-related newsgroups and you'll see I advocate use of valid markup and
CSS, even going so far as to adopt that for my own pages because I think
valid strictly structural HTML + CSS offer a gracefully degradable page and
a nice set of layout suggestions.
> Seems silly, eh?
Seems like I'm being misunderstood because the arguments against my position
consist of a false dichotomy.
> Person 2: "You should have no layout control"
I assume this is supposed to be me. I never said one shall have no layout
control. Clearly CSS and presentational markup suggest some layout control.
The issue is whether the UA will honor these suggestions and do so in a way
the author expects. This cannot be guaranteed.
> The truth is that with CSS1 and CSSP, it actually does work quite well in
> the vast majority of cases.
Technology like user CSS, ad-blocking proxies, browsers like iCab that allow
users to easily not render ads make it so one has to design a webpage to
work with a lot of unknowns. Then there's all the subjective viewpoints
that can make the same exact object look different (the story of the blind
men feeling an elephant seems relevant here--see Rashomon).
So, in the end, your statement only holds water if the UA renders what you
intended. Without random surveys of people that visit your webpage (surveys
I believe most authors haven't done) we'll never really know how well the
expectations match rendered pages.
> Whether you personally want this to be the case or not is another matter.
It has nothing to do with what I want, it has to do with how things work. I
have grown tired now of replying to your straw arguments.
J.B. Nicholson-Owens
> Art in a gallery or in a museum can be such a medium. Lighting, viewing
> distance, viewing angle, ambient temperature, and level of noise are all
> under the control of the presenters rather than the viewers.
Good catch. I see your point and I'm willing to agree partially. Art in a
gallery seems as close as one can come to presentational control. But there
are some problems. The presenter might not be the artist. The artist might
be long dead so nobody knows how the art is intended to be taken in. People
might bring different understandings of the allusions to the viewing so they
come away with different interpretations; who knows how many of which match
the artist's intentions. Even multiple people standing in roughly the same
spot in the museum looking at the same work of art can see different things
(consider the story of the blind men feeling an elephant).
Some of this gets into how much the audience understands versus what the
artist is presenting but since messages are intended to be received, I'd say
that is a mighty fine hair to split.
I'll keep thinking of mediums where such control might exist but so far I'm
still convinced the kind of control the original poster desires is a myth in
any medium, certainly the web.
Matt McIrvin
<sp...@maxify.com> wrote:
>Matt McIrvin wrote on 11/17/00 2:30 PM:
>
>> [1] There have been reports that the control is mysteriously missing in
>> NS6/Mac, though not Mozilla/Mac. I wouldn't know, since I haven't been
>> able to get NS6/Mac working at all; the stupid thing just puts up a
>> splash screen and freezes. Maybe I oughta try Mozilla M18...
>
>I haven't tried NS6/Mac yet, but M18 does have text zooming.
Just got NS6 to work (well, sort of), and actually looked at my pages
under Gecko for the first time. I thought its rendering of lists under
CSS was just horribly broken... in a strangely familiar way... until I got
through my thick head something that people have been warning me about
for a while, namely that it does DOCTYPE sniffing differently from IE5: it
goes into "compatibility mode" even if you use the transitional DTD. (IE5
doesn't do that unless you use *no* DTD.)
Yeah, it's acting like Netscape 4 ON PURPOSE.
So I've decided that I'm in the "DOCTYPE sniffing sucks" camp. That's my
story and I'm sticking to it.
On to the recoding...
Todd Fahrner
mmci...@world.std.com wrote on 11/17/00 7:03 PM:
> Just got NS6 to work (well, sort of), and actually looked at my pages
> under Gecko for the first time. I thought its rendering of lists under
> CSS was just horribly broken... in a strangely familiar way... until I got
> through my thick head something that people have been warning me about
> for a while, namely that it does DOCTYPE sniffing differently from IE5: it
> goes into "compatibility mode" even if you use the transitional DTD. (IE5
> doesn't do that unless you use *no* DTD.)
Minor corrections:
Mozilla goes into compatibility mode when you use the 4.0 Transitional, but
not the 4.01 Transitional DOCTYPE. And (I think) you need to use the form
with URI, too.
MacIE5 goes into compat mode when you use the 4.0 Transitional *without
URI*.
Both should go into standard mode using 4.01 Transitional with URI.
Some of the more salient differences are apparent here:
<http://descend.metrius.com/~todd/macie/resolved/inheritance.html>
<http://descend.metrius.com/~todd/macie/resolved/medium_1em.html>
<http://descend.metrius.com/~todd/macie/resolved/fontsize.html>
<http://descend.metrius.com/~todd/macie/resolved/keywords.html>
Note the DOCTYPE-toggle widget at the bottom of these pages, courtesy of
Apache's XSSI; makes the differences jump.
An upshot is that the keywords are now consistently implemented in
Mozilla/NS6 and MacIE5 in standard mode. As soon as you're willing to forget
about good results in NS4 entirely, and assuming you are willing to send
WinIE a stylesheet with n-1 font size keyword values ("small" for Mozilla =
"x-small" for WinIE), it should be feasible to leave both absolute and
relative length units for font size specification behind - and good riddance
in many cases!
--
Todd Fahrner
"But IE3 is almost completely extinct, whereas Netscape 4's undead corpse
still shambles about the earth wreaking a horrific vengeance upon the
living."
--Matt McIrvin
Shawn K. Quinn
Matt McIrvin <mmci...@world.std.com> wrote:
| In article <3a14...@news.star.co.uk>, "aa" <aast...@hkw.co.uk> wrote:
|
| >Theoretically this is true. In practice he who trys to please
| >everyone, pleases none.
| >
| >One cannot write code which would be eqially viewed on a desk-top
| >color monitor and on WAP phone. Still some people use 640*480
| >monitors and some still use black-and-whites. Some are using browsers
| >which do not support scripts, CSS, even frames and pictires. To
| >please all these one has to stick to the very basic stuff which would
| >appeal to nobody.
|
| Occasionally I get nice e-mail from people who read my Web site. I
| assume that it appealed to them somehow. I'll admit that that's more
| for the words than for the look, which is kind of austere though not
| 1994 gray, and I probably couldn't make any money off of it; there's
| a certain luxury associated with not doing this for a living, and not
| being beholden to clients, bosses or the marketing department. But I
| have some evidence that *somebody* likes it.
|
| Anyway, my pages are supposed to be bare-bones usable on Lynx,
| OK-looking if plain on Netscape 2 through 4 and iCab, better-looking
| on Opera, and moderately pretty with nifty things like tooltips and
| hover coloring on IE4/5 and Mozilla.
[from sig]
| http://world.std.com/~mmcirvin/
I took a quick look at this, and I am rather impressed. Definitely
not a site that will hold the attention span of people who crave the
"multimedia web experience" of course.
You might want to take a look at your kibology/index.html page though;
it's unusable on w3m (and Lynx with the wrong settings, too) due to a
comment you open and never close.
| *Everybody* gets the same HTML. The only differences are in the CSS,
| since some browsers don't have CSS support and others get different
| styles through the use of the @import hack... if I were a pro I'd
| probably use server-side browser sniffing instead, and serve two or
| three different stylesheets, but no more.
Server-side browser sniffing doesn't work too well with caching proxies,
and can easily be fooled. It may also blow up when you least expect it,
as in when a new CSS-capable browser comes along and gets some crummy
minimalist CSS reserved for less standards-compliant implementations.
| I doubt it would be usable on a WAP phone, but I'm skeptical that
| anyone can do much of anything on a WAP phone. However, I can imagine
| someone browsing it on, say, Opera for Psion/EPOC without any trouble.
While your site is hardly a magnet for wireless Web-enabled device
users, I can see the potential for an occasional mobile access or two
here and there.
| Sometimes I slip up, and there are some very buggy browsers (such as
| very early NS4 versions) that it will break, but I consider support
| for egregious bugs slightly less worthy of my time than support for
| simple browsers.
Agreed. I think many of the major bugs got ironed out by 4.08 if not
4.5x though.
| I use pictures, CSS, even a table layout on the front page. I guess I
| *am* being slightly exclusionary there, since browsers with absolutely
| no table support (Mosaic 1, early Lynx versions) might have trouble
| with it. But the bar is set pretty low.
Actually Lynx doesn't have that much trouble with content within tables
other than completely ignoring the table markup. If the content doesn't
make sense after that step that's where the problems, if any, begin. (It
is still possible to make sense of some tables that are rather horribly
mangled. For tables used as ersatz page layout bounding boxes, of
course, dropping table markup can often be seen as a feature. For
tables that are actual tables, like when you'd see "Table 1" in a
college textbook or scientific report, that's when things get hairy with
Lynx. Of course, there's always w3m as well.)
| I hear lots of complaints to the effect that a site won't work *really
| well* on text or audio browsers, etc., without a lot more work (see
| the latest A List Apart), but these days the people who rely on such
| things aren't asking for them to work really well; they'd be somewhat
| satisfied if they worked at all.
That kind of depends on what is meant by "really well." An audio
(speech) browser may have a mode that goes to the next link (A element
with an HREF attribute) and reads the text inside it, making it easier
to follow such links. Well written hypertext (HTML or otherwise) will
have text that describes where the link goes, or at least hints at what
might be there.
| >A lot of people are taking executive decision to limit the audience
| >to those with more or less up-to-date equipment and this is the only
| >way to progress. Netscape set an interesting example by dropping all
| >pre-NC6 specific features in NC6 - why should web-authors care about
| >Netscape's customers more than Netscape does?
|
| A thing that bothers me is that some sites exclude browsers even when
| it would be trivial to let them in. This is not as common now as it
| was in the olden days of Netscape 2 dominance, but there are still
| some that will kick out Opera users even though Opera is fully capable
| of rendering the site.
Doesn't Opera let one change User-Agent if one encounters such a
site? (One shouldn't have to, though.)
| In other cases, it might take a little bit of work to support more
| platforms, but not as much as is expended on excluding them: ALT tags
| are *easy*, JavaScript that tells people to go away is harder.
Nominally harder, but still frighteningly easy. Not to mention
validators will raise hell when encountering ALT-less IMG tags for a
document declared as HTML 4.0 (implicitly or explicitly).
| The other thing that bothers me is that many sites are written without
| an eye to *forward* compatibility, which is what you get when you
| follow standards. When Netscape dropped NS4 proprietary features, it
| was in order to move forward and embrace standards.
It's too bad Netscape didn't do this sooner, as in dropping frames
around the time of Navigator/Communicator 4.x. Of course now that frames
are in a W3C standard (something I honestly never expected nor hoped to
see) this seems unlikely.
--
Shawn K. Quinn
Shawn K. Quinn
try and rearrange most of them into something usable.]
In message <3a14...@news.star.co.uk>,
aa <aast...@hkw.co.uk> wrote:
| J.B. Nicholson-Owens <j...@forestfield.org> wrote in message
| news:slrn919lv...@next.forestfield.org...
| > aa wrote:
| > > From you definition, I am probably a control-freak because I
| > > really want my work to be displayed to user as I did it, not as
| > > some fancy preference setting could render it.
| >
| > Unfortunately I doubt there is a medium in which the author has as
| > much control as some web authors think they have on the web. People
| > can and will view your webpage on a variety of devices where you
| > have no control over the rendering. Get used to it.
|
| Theoretically this is true. In practice he who trys to please everyone,
| pleases none.
Nonsense.
| One cannot write code which would be eqially viewed on a desk-top color
| monitor and on WAP phone. Still some people use 640*480 monitors and some
| still use black-and-whites.
Only if you are hung up on "looks the same everywhere" will the
different rendering on different devices displease you. The *content*
(in this case, hypertext in HTML) is the message, not the flashy way in
which it is rendered.
| Some are using browsers which do not support scripts, CSS, even
| frames and pictires.
Scripting (Javascript, JScript, ActiveX) is often disabled as a security
risk. CSS was designed to degrade gracefully; browsers use it if they
can and the reader wants it, if not the user still gets the default
non-CSS rendering.
| To please all these one has to stick to the very basic stuff which
| would appeal to nobody. Of course you can set up a separate code for
| everyone of the abovemention groups, but this is not practical and
| cost prohibitive.
In fact, HTML and other markup languages standardized by the W3C were
designed so one does not have to rewrite anything! The only reason
making multiple versions of content became common to begin with was due
to HTML 3.2 and rendering hints being delivered in HTML tags -- a huge
step backward.
| A lot of people are taking executive decision to limit the audience
| to those with more or less up-to-date equipment and this is the only
| way to progress.
"Up-to-date equipment" includes WebTV, wireless telephone browsers,
handheld devices like the Palm units, and speech browsers. Many of those
devices have resolution smaller than 640x480, if they render visually at
all.
| > > Alan J. Flavell <fla...@mail.cern.ch> wrote in message [...]
| >
| > Please don't repost the entire thread up to the point of your
| > contribution. People don't need to download the same article more
| > than once and poorly requoted text doesn't assist in maintaining
| > context.
Apparently you missed this in the message you followed up to. Network
bandwidth wasted by excessive quotes adds up to a rather high cost, and
indiscriminately wasting resources because *you* don't have to pay those
costs is rude and selfish.
--
Shawn K. Quinn
Matt McIrvin
<1FB666C44914BCA9.26C01B8E...@lp.airnews.net>,
skq...@suespammers.org wrote:
>You might want to take a look at your kibology/index.html page though;
>it's unusable on w3m (and Lynx with the wrong settings, too) due to a
>comment you open and never close.
Thanks for spotting that. It was an accident caused by the fact that
my ISP's Web server works better if "index.html" pages have base href
tags in them. I usually comment those out (sometimes in a malformed
way) while working on my pages locally so that the browser doesn't
connect to the Internet to get the stylesheet, but sometimes I forget
to uncomment it again on upload.
Matt McIrvin
>I took a quick look at this, and I am rather impressed. Definitely
>not a site that will hold the attention span of people who crave the
>"multimedia web experience" of course.
Yes, and one problem with arguments about what's right and wrong to
do on the Web is that of course everything depends on what you're
trying to accomplish. Some of the Flash- and DHTML-heavy
design-experimentation sites that hotshot Web designers play with
in their spare time, things like Once Upon a Forest, etc., are
more akin to Nam June Paik installations than to the stuff I do;
they're *about* the fancy graphic/kinetic experience, and making
them work in text would turn them into something else entirely.
The concept of graceful degradation doesn't really apply; the
basic HTML/CSS paradigm is not suited to these works.
I wouldn't want those people to feel that they're not allowed to
do that; the web is richer for having these strange fragile artworks
living on it, whether or not it was designed to do that. But on the
other hand, I wouldn't want to buy airline tickets through Praystation
or Once Upon a Forest.
>Actually Lynx doesn't have that much trouble with content within tables
>other than completely ignoring the table markup.
Later Lynx versions do pretty well with some kinds of tabular layout
just by putting spaces at the table cell boundaries and newlines at
the table row breaks. Very early ones would, I think, just mash them
all together in a row with no spaces between the table cells.
I've heard (he said, trying to get the discussion back on topic) that
some people have mused about giving Lynx some CSS support. It's an
interesting concept... some things might actually be appropriate for
a text-mode browser.
>Doesn't Opera let one change User-Agent if one encounters such a
>site? (One shouldn't have to, though.)
Yes, though I think that sometimes you have to do some homework and mimic
the User-Agent string of some other browser annoyingly closely, rather
than just using that "Mozilla" identifier used by every graphical browser
in the world to get around the favorite exclusionary coding tactic of
1995.
Shawn K. Quinn
Matt McIrvin <mmci...@world.std.com> wrote:
| In article
| <1FB666C44914BCA9.26C01B8E...@lp.airnews.net>,
| skq...@suespammers.org wrote:
| >I took a quick look at this, and I am rather impressed. Definitely
| >not a site that will hold the attention span of people who crave the
| >"multimedia web experience" of course.
|
| Yes, and one problem with arguments about what's right and wrong
| to do on the Web is that of course everything depends on what
| you're trying to accomplish.
Oh, I didn't say anything was wrong with "multimedia web experience"
necessarily. In some (probably rare) cases they may even be the only
feasible way to present the content. However, note that the printed text
of, say, Martin Luther King's "I Have A Dream" speech is still very
effective at communicating the idea, even if it lacks the nuances of an
audio recording.
| Some of the Flash- and DHTML-heavy
As I have said before elsewhere, "DHTML" really doesn't have a precise
meaning. If you mean scripting-heavy, say so. If you mean something
else, say that. Otherwise you really aren't saying much of anything.
| design-experimentation sites that hotshot Web designers play with in
| their spare time, things like Once Upon a Forest, etc.,
Never heard of it.
| are more akin to Nam June Paik installations than to the stuff I do;
| they're *about* the fancy graphic/kinetic experience, and making
| them work in text would turn them into something else entirely. The
| concept of graceful degradation doesn't really apply; the basic
| HTML/CSS paradigm is not suited to these works.
I'd have to see it to know what you're talking about for certain, but
what you speak of reminds me of the movie "Web sites" that put a 500K to
1M Flash intro in addition to a metric boatload of animated GIFs when
all I want to do is view the trailer and go on to the next site. They
make it hard for me to evaluate their movie? Fine. I go on to the next
site. They are hurting their own box-office totals.
| I wouldn't want those people to feel that they're not allowed to do
| that; the web is richer for having these strange fragile artworks
| living on it, whether or not it was designed to do that. But on the
| other hand, I wouldn't want to buy airline tickets through Praystation
| or Once Upon a Forest.
Agreed. However, I would not lump true Web sites in with "works of
virtual art" as some may call them.
| >Actually Lynx doesn't have that much trouble with content within tables
| >other than completely ignoring the table markup.
|
| Later Lynx versions do pretty well with some kinds of tabular layout
| just by putting spaces at the table cell boundaries and newlines at
| the table row breaks. Very early ones would, I think, just mash them
| all together in a row with no spaces between the table cells.
I don't know if I'd call them very early; I think what you describe is
as of 2.4.x or maybe as late as 2.6.x which was during the time I was
using OS/2 on my home PC (up through about 1998).
| I've heard (he said, trying to get the discussion back on topic) that
| some people have mused about giving Lynx some CSS support. It's an
| interesting concept... some things might actually be appropriate for a
| text-mode browser.
If it doesn't bloat the size of the resulting binary too badly, I'm all
for it. It would be neat to see e.g. Figlet fonts used for initial caps
but I'm not banking on that.
| >Doesn't Opera let one change User-Agent if one encounters such a
| >site? (One shouldn't have to, though.)
|
| Yes, though I think that sometimes you have to do some homework
| and mimic the User-Agent string of some other browser annoyingly
| closely, rather than just using that "Mozilla" identifier used by
| every graphical browser in the world to get around the favorite
| exclusionary coding tactic of 1995.
Every server-side "browser sniffer" I've had to foil would be fooled by
such balderdash as "Definitely Not Your Father's Mozilla." Of course
Lynx will gladly tell you "Alert!: WARNING: Misrepresentation of the
User-Agent may be a copyright violat[ion]" which surprises me because
one can do the same thing with a proxy.
--
Shawn K. Quinn
Scott Stevenson
> Only if you are hung up on "looks the same everywhere" will the different
> rendering on different devices displease you. The *content* (in this case,
> hypertext in HTML) is the message, not the flashy way in which it is rendered.
That's not universally true. Sometimes the design is the content. I imagine
I visit much more of these type of sites than the average person. But even
for the average person, there are sites that revolve around concepts like
Flash games or video clips.
> Scripting (Javascript, JScript, ActiveX) is often disabled as a security risk.
This is a pretty broad sweeping statement. Do you have any hard data to back
this up?
> In fact, HTML and other markup languages standardized by the W3C were
> designed so one does not have to rewrite anything! The only reason
> making multiple versions of content became common to begin with was due
> to HTML 3.2 and rendering hints being delivered in HTML tags -- a huge
> step backward.
I think it's a pretty strong statement to say that rendering hints were a
huge step backwards. The implementation was bad -- we sure could have used
CSS back them -- but the concept was essential to the web gaining the
popularity it did. Without that it's possible it would have remained a tool
for the scientific and education elite (a least for a bit longer), and AOL
would have kept its stranglehold for a bit longer.
Scott Stevenson
> of course everything depends on what you're trying to accomplish. Some of the
> Flash- and DHTML-heavy design-experimentation sites that hotshot Web designers
> play with in their spare time [...snip...] they're *about* the fancy
> graphic/kinetic experience [...snip...] I wouldn't want those people to feel
> that they're not allowed to do that; the web is richer for having these
> strange fragile artworks living on it, whether or not it was designed to do
> that. But on the other hand, I wouldn't want to buy airline tickets through
> Praystation or Once Upon a Forest.
Excellent articulation of this point! Too bad something like this doesn't
preface this newsgroup's FAQ. It would certainly make the text seem much
less defensive and open the discussion to wider range of participants.
Scott Stevenson
> | design-experimentation sites that hotshot Web designers play with in
> | their spare time, things like Once Upon a Forest, etc.,
>
> Never heard of it.
http://www.once-upon-a-forest.com/
> I'd have to see it to know what you're talking about for certain, but
> what you speak of reminds me of the movie "Web sites" that put a 500K to
> 1M Flash intro in addition to a metric boatload of animated GIFs when
> all I want to do is view the trailer and go on to the next site. They
> make it hard for me to evaluate their movie? Fine. I go on to the next
> site. They are hurting their own box-office totals.
Matt is referring to the sites whose main purpose is experiments in graphic,
UI and multimedia design. The design is the content, for the most part.
'Forest certainly falls into this category, and Praystation.com to a lesser
extent. Adobe actually sponsors some sites like this as well, such as
http://www.shredtheweb.com/, though they're clearly pushing their products
in that case. Doesn't have the purity of 'Forest.
> Agreed. However, I would not lump true Web sites in with "works of
> virtual art" as some may call them.
All sites are "true web sites" in my book. No sense in being elitist about
it. That the difference between the web and AOL. The fact that anybody can
be into whatever they want to put up a site about it in whatever form they
want is truly remarkable.
Jan Roland Eriksson
comp.infosystems.www.authoring.stylesheets Scott Stevenson
<sp...@maxify.com> wrote:
>Matt McIrvin wrote on 11/18/00 4:28 PM:
>
>> of course everything depends on what you're trying to accomplish. Some of the
>> Flash- and DHTML-heavy design-experimentation sites that hotshot Web designers
>> play with in their spare time [...snip...] they're *about* the fancy
>> graphic/kinetic experience [...snip...] I wouldn't want those people to feel
>> that they're not allowed to do that; the web is richer for having these
>> strange fragile artworks living on it, whether or not it was designed to do
>> that. But on the other hand, I wouldn't want to buy airline tickets through
>> Praystation or Once Upon a Forest.
>
>Excellent articulation of this point! Too bad something like this doesn't
>preface this newsgroup's FAQ. It would certainly make the text seem much
>less defensive and open the discussion to wider range of participants.
Ok, I'm listening :)
Do we have a suggestion for how such a passage should be formulated in
detail to fit in as FAQ content?
--
Jan Roland Eriksson <r...@css.nu> .. <URL:http://css.nu/>
Etan Wexler
<sp...@maxify.com> wrote:
> > to HTML 3.2 and rendering hints being delivered in HTML tags -- a huge
> > step backward.
>
> I think it's a pretty strong statement to say that rendering hints were a
> huge step backwards. The implementation was bad -- we sure could have used
> CSS back them -- but the concept was essential to the web [...]
The mixture of clumsy, overbroad rendering hints with structure and
content *in the same stream* was and is the problem. The Web has had
style sheets since its early days:
<http://www.w3.org/Style/LieBos2e/history/>. Besides, the practice of
using style sheets was established and successful beyond the Web. So,
yes, the stylistic devolution of HTML was a huge step backward.
--
Etan Wexler
Keep your friends close but keep your
enemies in a hole lined with pointy sticks.
Alan J. Flavell
> Shawn K. Quinn wrote on 11/18/00 11:56 AM:
>
> > Only if you are hung up on "looks the same everywhere" will the different
> > rendering on different devices displease you.
> That's not universally true. Sometimes the design is the content.
You give a rather unsettling impression that you think you're bringing
out some kind of new argument that we've never seen before. I really
think you'd find more sympathy for your newness here if you showed a
little more interest in doing the homework that would get you up to
speed, and rather less at telling old hands about things that they
already understand or have direct experience of.
> > making multiple versions of content became common to begin with was due
> > to HTML 3.2 and rendering hints being delivered in HTML tags -- a huge
> > step backward.
Indeed.
> I think it's a pretty strong statement to say that rendering hints were a
> huge step backwards.
Why do you think that? When you say "pretty strong", do you mean
"pretty strong" compared with a light breeze, or have you got any
factual basis on which to argue that Shawn would be exaggerating?
FWIW, I thought Shawn's comment was well-measured.
> The implementation was bad
No, the fundamental _design_ was bad, considering that the concept of
stylesheets had been around already (I had been using it in a related
context half a decade before and understood its benefits), the
principle of separating content and structure from presentation was
already well established and was also clearly stated in HTML 2.0,
there was work in progress to define CSS, and so on.
Sure, the _implementation_ of that fundamentally broken DTP-in-HTML
design was also bad in a number of ways, but that's not the point.
It wasn't a case of "a few rough edges, that could be smoothed off in
later versions", it was a fundamentally dead-end design that was
demonstrably inferior to what was already being worked on but Not
Invented Here.
> -- we sure could have used CSS back them
Some of us were already using a prototype of CSS back then, looking
forward to it being properly defined and supported, and were appalled
to see that junk emerging from NS and MS.
> -- but the concept was essential to the web gaining the
> popularity it did.
Oh, yawn. Just because it happened that way doesn't mean it was the
essential cause. You might as plausibly argue that the popularity of
the web was caused by any of the other things that happened to be
developing at that time, such as better dial-up modems, the Apple Mac,
faster PCs, windowing UIs, or what-have-you.
> Without that it's possible it would have remained a tool
> for the scientific and education elite
You're just churning out old, tired arguments for which there can be
no proof or disproof, since whatever happened, happened, and there's
no way anyone can unmake it and prove which bits were essential and
which bits were just incidental.
Whichever way you parse it, presentational HTML was a dead-end.
Well, I haven't got time or inclination to go over this again, I don't
plan to continue this thread.
Matt McIrvin
<sp...@maxify.com> wrote:
>Matt is referring to the sites whose main purpose is experiments in graphic,
>UI and multimedia design. The design is the content, for the most part.
Yeah, and when I mentioned "DHTML" I was thinking of Assembler, an
experiment in the heavy use of scripting to make Lego-like toys
and other special effects.
>All sites are "true web sites" in my book. No sense in being elitist about
>it. That the difference between the web and AOL. The fact that anybody can
>be into whatever they want to put up a site about it in whatever form they
>want is truly remarkable.
The way I see it, the important thing is that people setting out to do
exotic stuff at least understand the potential consequences and aren't too
quick to blame others when they happen (e.g. all the people complaining
that their scripts won't work with Netscape 6).
I actually think that commercial Web design is getting better in terms of
standards and accessibility. Things like the font size issue still create
trouble, but on the whole, I think that most of the vicious cycles are
actually breaking. Big commercial sites are starting to shed the most
egregious abominations, the spinning logos and pages that scold you for
wanting to buy something without having ActiveX and JavaScript turned on.
Some of the better commercial sites are even using some CSS these days.
That's incredibly gratifying to me, because I've always liked it so much
in concept, and for a couple of years it seemed to be dead or dying, one
of the most promising Web technologies murdered by bad implementations and
the desire to turn it into a proprietary feature. Somehow, people
actually got the browser manufacturers to implement it correctly enough to
be worthy of consideration, and I think the general wariness of it is
beginning to evaporate.
(The major exception to this generally optimistic picture is what Shawn
Quinn mentioned: the promotional sites put up by entertainment companies.
They're moving more and more to whole sites implemented in Flash, and
often it's not even *good* Flash, but a thin layer of Flash used to
encapsulate bandwidth-busting raster animation and suchlike. I can see
their motivation, but they haven't quite caught on to the fact that one of
the reasons unauthorized fan sites flourish is that people can usually
*use* the fan sites. At least some of the more enlightened companies
aren't trying to shut the fans down any more.)
Etan Wexler
Eriksson <r...@css.nu> wrote:
> Do we have a suggestion for how such a passage should be formulated in
> detail to fit in as FAQ content?
Cascading Style Sheets (CSS) is a style language that suggests (but cannot
force) certain styles for structured documents, like HTML documents or XML
documents. For some Web sites, style--including colors, layout,
sound, animation, and interaction--is not merely an optional enhancement.
For such sites, which are a valuable part of the World Wide Web, the style
is itself content which users want. Among such sites are those that
explore user interfaces and those that present works of art. Although CSS
can be a part of such Web sites, CSS is, by design, open to the influence
of the user. Therefore it may be appropriate to use a technology other
than CSS for a presentation that demands close control.
Scott Stevenson
> You give a rather unsettling impression that you think you're bringing
> out some kind of new argument that we've never seen before. I really
> think you'd find more sympathy for your newness here if you showed a
> little more interest in doing the homework that would get you up to
> speed, and rather less at telling old hands about things that they
> already understand or have direct experience of.
Alan,
I feel this personal attack is really uncalled for, and disappointing. I
hope it's not indicative of what newcomers to this group should expect when
participating in the discussion, even if their viewpoints stray from
majority.
Best Regards,
- Scott
Shawn K. Quinn
Scott Stevenson <sp...@maxify.com> wrote:
| Shawn K. Quinn wrote on 11/18/00 11:56 AM:
|
|
| > Only if you are hung up on "looks the same everywhere" will the
| > *content* (in this case, hypertext in HTML) is the message, not the
| > flashy way in which it is rendered.
|
| That's not universally true. Sometimes the design is the content. I
| imagine I visit much more of these type of sites than the average
| person. But even for the average person, there are sites that revolve
| around concepts like Flash games or video clips.
| > Scripting (Javascript, JScript, ActiveX) is often disabled as a
| > security risk.
|
| This is a pretty broad sweeping statement. Do you have any hard data
| to back this up?
Numerous CERT advisories for starters. Take a look (each of these is a
single URL, split onto two lines):
<http://search.cert.org/query.html?rq=0&col=certadv&ht=0&qp=&qt=javascript
&qs=&qc=&pw=100%25&ws=1&la=&qm=0&st=1&nh=25&lk=1&rf=2&oq=&rq=0&si=1>
<http://search.cert.org/query.html?rq=0&col=certadv&ht=0&qp=&qt=jscript
&qs=&qc=&pw=100%25&ws=1&la=&qm=0&st=1&nh=25&lk=1&rf=2&oq=&rq=0&si=1>
<http://search.cert.org/query.html?rq=0&col=certadv&ht=0&qp=&qt=activex
&qs=&qc=&pw=100%25&ws=1&la=&qm=0&st=1&nh=25&lk=1&rf=2&oq=&rq=0&si=1>
Even if the newest browsers have no such known security holes, that
track record is not exactly reassuring, now is it?
The site for the Internet Junkbuster recommends disabling Javascript to
avoid unauthorized cookies:
<http://www.junkbuster.com/ijbfaq.html#cookies>
| > In fact, HTML and other markup languages standardized by the W3C
| > were designed so one does not have to rewrite anything! The only
| > reason making multiple versions of content became common to begin
| > with was due to HTML 3.2 and rendering hints being delivered in HTML
| > tags -- a huge step backward.
|
| I think it's a pretty strong statement to say that rendering hints
| were a huge step backwards.
Re-read what I wrote. Rendering hints *in HTML tags* which often could
not be overridden on the browsers that supported them.
| The implementation was bad -- we sure could have used CSS back them --
The CSS spec sat there gathering dust for a good two years until some
attempts at implementation outside of Amaya (which personally I found
hard to use) finally saw the light of day.
| but the concept was essential to the web gaining the popularity it
| did. Without that it's possible it would have remained a tool for the
| scientific and education elite (a least for a bit longer), and AOL
| would have kept its stranglehold for a bit longer.
I don't think AOL ever had a "stranglehold" per se. The ISP business has
had plenty of competition. Personally I've had no need for an AOL
account; the last proprietary online service I used was Prodigy back
in 1991, and I got a lot more enjoyment out of hobbyist bulletin board
systems (BBSes) until I got my first Internet account in 1996.
Even then, accessibility of information was a concern of mine; there
were a couple of boards switching to some software that required
an oddball, only-available-for-Windows client and had no text-mode
alternative interface like most other systems. As I was running OS/2 at
the time and had no reason to switch back to Windows, the sysops found
out they lost me as a regular user shortly after making the switch (but
there was no way to tell them that in a message).
--
Shawn K. Quinn
Shawn K. Quinn
Scott Stevenson <sp...@maxify.com> wrote:
| Shawn K. Quinn wrote on 11/18/00 9:48 PM:
Nice... not. Throw sound at the unexpecting user with no warning, and if
they want to view September's page, crash their browser.
--
Shawn K. Quinn
Scott Stevenson
>>> Scripting (Javascript, JScript, ActiveX) is often disabled as a
>>> security risk.
>>
>> This is a pretty broad sweeping statement. Do you have any hard data
>> to back this up?
>
> Numerous CERT advisories for starters. Take a look (each of these is a
> single URL, split onto two lines):
I don't deny that there are security risks, particularly on the Windows,
side, but I don't think that translates as the technologies being "often
disabled." That assumes that the general public keeps up with such
advisories, and cares enough to actually shut it off while losing
functionality for sites they visit.
> Even if the newest browsers have no such known security holes, that
> track record is not exactly reassuring, now is it?
Certainly not!
>> I think it's a pretty strong statement to say that rendering hints
>> were a huge step backwards.
>
> Re-read what I wrote. Rendering hints *in HTML tags* which often could
> not be overridden on the browsers that supported them.
You're right. I stand corrected.
> Even then, accessibility of information was a concern of mine; there
> were a couple of boards switching to some software that required
> an oddball, only-available-for-Windows client and had no text-mode
> alternative interface like most other systems. As I was running OS/2 at
> the time and had no reason to switch back to Windows
I was using OS/2 then as well. Few BBSs had non-Windows shareware/freeware.
Though I think there was an OS/2 section on both AOL and CompuServ.
Cerberus
news:B63AC44C.71FD%sp...@maxify.com...
> Alan J. Flavell wrote on 11/17/00 3:31 AM:
>
> >> The text is way too big to be comfortably legible for normal text.
> >
> > No, it isn't any particular size at all. You as author have sent it
out
> > marked as normal text. That's the correct thing to do. You've now
displayed
> > it on a browser that hasn't been commissioned correctly according to
your
> > requirements. So it's the browser that needs adjusting, not the source.
>
> Again, this is a theory vs. reality situation.
>
> The theory is that all sites should use relative sizes and the user should
> adjust the defaults. The reality is that most sites already bring the font
> size down into the legible range on the most popular browsers (not saying
> this is good). Leaving it at the default size means that most people will
> see it to large. If they resize their defaults, the rest of the web will
be
> too small. They're not going to do this, and I can't afford to have people
> not visit a site simply because the text is hard to read (or just plain
> ugly) at its default size. I have bills to pay.
Again, nice in theory, but bites in reality. I have adjusted my browser's
defaults to what is comfortable to me. BTW, "most sites" _don't_ assume my
text is too large. Some sites do, and I never visit them again because
they're too difficult to read.
--
Your Friendly Neighborhood Hellhound
We do not see things as they are, we see things as we are. -Talmudic Saying
Scott Stevenson
> Again, nice in theory, but bites in reality. I have adjusted my browser's
> defaults to what is comfortable to me. BTW, "most sites" _don't_ assume my
> text is too large. Some sites do, and I never visit them again because
> they're too difficult to read.
If people like us were in the majority, we'd have no problem.