wrote in message <36504211.3671@olemiss.edu>:
> - - FONT is a text-level element. TD is a block-level
>element. The opening implicitly closes any open FONT
>elements. This is one thing that Netscape got right.
In principle, omission of the tag is not allowed; the HTML 4.0
Transitional DTD says:
So when there is an unclosed FONT element and a tag is
encountered, there is a _syntax error_. Different browsers have
different error recovery methods; some of them may imply a closing
whereas others act as if it were allowed to have a TABLE
element inside a FONT element.
Jukka Korpela
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On Tue, 17 Nov 1998, Aaron wrote:
> Anyone know where I could download a WebTV simulator for use in
> developing pages on a Win98 system?
webtv, where else?
Oh, you couldn't find your way through the maze?
Well, go to
http://developer.webtv.net/tools/viewer/license.html
Even Lynx had no problems after that (in spite of all the earlier hassle
with "your browser doesn't support frames" - of course it bloody does,
stupid morons. It just doesn't display them as frames.)
It's a fun viewer, once you get there. Much better than their thicko
developer's web site...
all the best
Alan J. Flavell
---------------------
On Tue, 17 Nov 1998 02:29:13 +0100, Alan J. Flavell saw fit to expound:
>
>Well, go to
> http://developer.webtv.net/tools/viewer/license.html
>
>Even Lynx had no problems after that (in spite of all the earlier hassle
>with "your browser doesn't support frames" - of course it bloody does,
>stupid morons. It just doesn't display them as frames.)
Web authors are going to have to get used to the fact that many browsers
are now supporting frames in 'unorthodox' ways: that is, different to
the way Netscape does it. Speaking browsers aside, platforms with little
screen real estate (palmtops and smartphones) are being forced to adopt
new ways of handling frames. One that I know of offers at least three:
o The Netscape method (showing all frames on screen at once; virtually
unusable with complex framesets)
o The Lynx method (showing FRAME references as links)
o Showing one frame at a time in the main window, with a side toolbar
allowing you to switch frames
This time it's no good 'commercial' web authors ducking the problem
by saying they're simply not interested in the group of people
concerned. After all, people with palmtop computers have money to burn
and they're not likely to give it to you if they can't get past Page 1
of your web site.
Jedi Master Yoda
---------------------
Aaron wrote:
>
> Anyone know where I could download a WebTV simulator for use in
> developing pages on a Win98 system?
You can get it at:
http://developer.webtv.net/
You can find links to this and other "non-big-two" browsers on my Brand
X Browsers page at:
http://www.softdisk.com/comp/dan/webtips/brand-x.html
Daniel R. Tobias
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
As a recovering Front Page user, I would thoroughly recommend Dreamweaver
1.2..or 2... :-)
David McDonald
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Lex Spoon schrieb:
> It is commonly held that HTML is misused by the vast majority of web
> sites: it is used as a graphical layout language, instead of as a
> markup language. Purists argue that these sites are evil, and that's
> the end of it. If they want layout, they should wait for style sheets
> to get worked out, and only THEN use layout.
> But these purists are quietly assuming that web pages MUST use HTML,
> and furthermore that web pages MUST be content-oriented and in
> particular should be readable by the blind and by the GUI-challenged.
No, that is different HTML is (was intended to be) content-orientated
and all of the above. I for example always recommended using PDF,
whenever someone complained about the lack of control in HTML.
> I think what the web really needs is a new hyperlinkable *graphical*
> layout language. For example, why is the web not based on postscript?
Postscript is far too complex and introduces many incompatibility
problems -- and the files are just too big. PDF is fully webable, i.e.
provides hyperlinks, #part addressing, forms, etc.
With PDF, you get what you want: Full control over layout. But, are you
sure this is what web authors and users really want? (Sometimes, sure,
but always?)
The problem is not HTML, it's the users and - even more - the autors.
Joe Average User did not grow up with HTML and other structural
languages.
Maybe he started with a typewriter. He just hit the keys on the keyboard
and the letters appeared whereever the carrige was. For underlining, he
wrote the text and then went back and printed underscores over them. And
all other effects (of a very limited set) were created similarily.
Now, Joe gets his first computer. Unless he happens to be author for a
magazine/newspaper, he probably starts with a WYSIWY(M)G word processor.
Most people start with using word processors just as they used their
typewriter (they even press Return at the end of each line!) If he wants
to set some text in italics, he selects it and applies the style
italics. He does not think: "Hm, I want this text to be emphasized, so I
apply the style italics, which I use for emphasized text."
The maximum the avgerage word processor user comes in contact with his
document's structure are headings and the outline view most modern word
processors offer. Word processors are truly light-weight DTP software,
not structural document processors.
Now, our Average User wants to make "Web pages". He expects his HTML
editor to work just like his light-weight DTP software; which is the
problem because HTML was not _meant_ to work that way. But, Everyone
uses HTML, so he does, too, although he expects something he could only
get from layout languages, such as PDF, Postscript, etc.
But the _real_ advantage of HTML escapes him: By describing the
structure and giving presentation _hints_ (pres. markup/CSS), HTML
adapts to a wide variety of media and gets the best out of every medium,
whereas layout languages such as PDF or Postscript always describe the
layout on a particular medium - which can be _simulated_ on other media
(i.e. you can view a paged PDF file on screen or you can fit an Letter
PDF page on a A4 paper), but remains a siumlation.
On the other hand, HTML is not fixed layout on a medium, but can be
rendered - i.e. layouted - on any medium like screen windows of
different sizes, a terminal, A4 paper, Letter paper ans so on...
--
Claus Andre Faerber
---------------------------
[WHY can't people learn to leave the attributions in place?!? (this
discussion took place during a period of flaky news flow at my end...)]
Anonymous 2 wrote:
> Anonymous 1 wrote:
> | Even with HTML's limitted graphical capabilities nowadays, it
> | is a standard procedure for many sites to maintain a "graphical"
> | version and a "textual" version of their pages. Making a single page
> | that is viewable on both is usually considered more difficult than
> | just making two separate pages.
>
> Because people are unwilling to *learn HTML* as opposed to just grab
> the latest pseudo-HTML regurgitator like FP, even though there really
> is no excuse to not know how to write at least basic HTML since the
> basics are ridiculously simple.
>
-----------------------------
On 18 Nov 1998, Lex Spoon wrote:
> Some font changes aren't just suggestions.
If you're referring to HTML, you're mistaken. This is not a proprietary
word-processor application.
> A less-than-or-equal sign
> from a symbols font just doesn't look the same as the equivalent
> character in ASCII.
That's why HTML defines a correct way of doing this, and that wasn't it.
Don't confuse a font (cosmetic appearance) with a repertoire.
> An author needs to do something completely
> different here if the appropriate symbols font isn't available:
Precisely. See
http://www.w3.org/TR/REC-html40/sgml/entities.html#h-24.3
> cases. An HTML+CSS document that must display correctly on both kinds
> of browsers would need some sort of HTML equivalent to C's #ifdef.
I think it's time you learned how HTML does things, before you spread
this kind of stuff. The character hexA3 (163 decimal) in HTML
represents the pound sterling sign. If you put it inside FONT
FACE=Symbol it may confuse people by looking like a less than or equal
sign, but in HTML terms it is still a pound sterling sign. So don't do
that. A pedantically implemented browser would tell the reader that
the symbol font doesn't have a pound sterling sign in it and so this
character cannot be displayed.
Of course, not all client agents implement HTML4.0, but that's
a different problem from the one that you have invented.
(and please, read that materials that have been provided for you
on news.announce.newusers about the proper way to quote. Hanging
the whole previous discussion on the end of your f'ups is rude.)
Alan J. Flavell
--------------------------------
Lex Spoon schrieb:
> Darin McGrew writes:
>
> > Lex Spoon wrote:
> > > Let me put it one more way. Imagine if all the magazines in the world
> > > suddenly switched to strict HTML-based layout. No more font changes,
> >
> > Why not? When the document structure calls for it, and the style sheet
> > suggests it, and the browser configuration allows it, the fonts could
> > change as much as the magazine designers wanted them to. (Although I'd
> > still select the "Ignore font styles specified on Web pages" option to
> > guarantee legibility.)
>
>
> Some font changes aren't just suggestions. A less-than-or-equal sign
> from a symbols font just doesn't look the same as the equivalent
> character in ASCII.
There is no equivalent character in ASCII. A "Symbol" font just contains
another character repertiore that a font that contains Latin characters.
Yes, in many word processors, you have to change the font and type some
other characters to get the character you want, but this is not how HTML
(or a modern word processor) works. In HTML, you use Unicode characters
and the browser is responsible for finding that character in the fonts
you specified. In no case should you for example tell the browser to use
the character "F" in the font "Symbol" when you actually mean the Greek
characther "Phi". Instead, you would write "Φ" and let the browser
find the appropraite font. You could also specify a font list like
"Times, Symbol", which means: try to find the characters in "Times", but
if you don't saerch for them in "Symbol" and if they aren't there
either, use the default font.
> An author needs to do something completely
> different here if the appropriate symbols font isn't available: they
> need to use two characters "<=".
No, the author uses the character LESS-THAN OR EQUAL TO (U+2264) and
it's the browsers task to transcribe that to "<=" if it can't find any
font which contains this character.
> The model of style sheets just giving hints breaks down in these
> cases. An HTML+CSS document that must display correctly on both kinds
> of browsers would need some sort of HTML equivalent to C's #ifdef.
No. It needs (partialy language-dependent) translation tables for
unavailable characters to available characters.
Examples:
ࣘ <=
ä[lang=de] ae
© (C)
> In many cases, though, layout *is* content. Geerheads often forget,
> there really are other things than dictionaries and technical papers
> that people would like to put on the web.
>
> For an extreme example, consider a person who writes a poem on top of
> a drawing of a rose, in such a way that the text and the drawing
> interact in subtle ways. There is no real text mode equivalent
> here--the visual relations are critical to the message.
To the message - yes. To the content - no. Even although layout often
(always?) is part of the message, you can still devide content (the
words of the text) and appearance (the layout). The question is: If
someone can't see the layout, would you want him/her to experience the
text anyway? Usually, the answer is yes. It is however important that
you get enough
> Should this artiste be forced to package up the whole thing as a big
> GIF, simply because some purists believe that authors only write out
> data and cannot be allowed to do layout?
Who said authors should not be able to specidy layout? Why is there the
possibility of !important rules? Why the term "author stylesheet"
anyway?
> Or for a less extreme example, how about an author who uses italics to
> specify what a character is thinking? On a plain-text browser which
> simply drops the italics, the text becomes almost unreadable;
This a perfectly valid argument -- for using structural markup, such as
and @media rules ...
> to make the document displayable on a text-mode browser will take
> concious changes by the author.
... and you won't have to do that. Is that an advantage of structural
markup + style sheet vs. different versions?
Another advantage is the machine-processibility of structural markup
(vs. layout languages). Just write a programme that extracts all
headlines of (a) an HTML file that uses , (b) an HTML file that uses
and (c) a Postscript file -- it gets
more and more difficult from (a) to (c).
> Or, less extreme yet, consider inlining an image into a page. Yeah,
> pretty far out, huh? But really, inline images are an effect specific
> to visual browsers. And whenever an author puts in an inline image,
> they must also put an explicit alt in the HTML. They are explicitly
> specifying how the document will show up on a visual vs. a non-visual
> browser.
Yes. Did someone claim IMaGes (or more general: OBJECTs) would be
structural?
--
Claus Andre Faerber
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On Tue, 17 Nov 1998 18:00:59 +0100, "Alan J. Flavell"
wrote:
| They just _have_ to believe it. They don't want it any other way.
| Actually trying out Lynx themselves would spoil their fun.
Maybe not. It could confirm their beliefs, in a funny sort of way:
"That's not what I expected. Therefore, it's bad." This is similar to
the "ugly duckling" syndrome used to explain the religious wars over
programs like editors: your first exposure "impresses" you and makes
you resistant to change and/or difference. Not to mention facts and
logic.
Arjun Ray
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Alan J. Flavell wrote:
> [...] Do you know how long it takes to
> download netploder over a cellphone?
I've never tried that one, but it seems to me that it
would be silly to point out that the software is free. :-)
Same goes for anyone using a dial-up connection from
a hotel room. Anyway, be advisded that a large number
of users pay for local calls and they're easily
offended by huge downloads. A number of US companies
doesn't understand this until their products and
services fail in the european market.
When designing a web site, please note that the US
term "patience" becomes "cost" for dial-up users in
many countries.
--
Håkon Styri
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> out. I'm not sure about the counter problem, (will counters like that
> ever validate?),
When you need an "&" character in a URL, and you want to reference it
in an A HREF, then the rules of HTML call for you to express the "&"
as "&" - that's all there is to it.
If you want a counter-example (!), then try mocking-up a URL
that contains, say, ?print=yes©=5
Well, you could try mine (compare strike1 with strike2):
http://ppewww.ph.gla.ac.uk/~flavell/tests/amp.html
Both MSIE and Netscape behave as if they've seen a copyright sign
in there, although they handle it differently.
Some other browsers produce the effect that the author presumably
intended, though I can't say I think the author has any right to
expect that.
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On 20 Nov 1998, Neil wrote:
> I am looking for suggestions on the color of a link and a link once it has
> been hit (the vlink tag).
I recommend you read Jakob Nielsen's articles. All of them. For now,
you want http://www.useit.com/alertbox/9712a.html and
http://www.useit.com/alertbox/9611.html
Some people say that WWW users are now much more sophisticated, and
don't need links to be in the expected colours. Other people say that
WWW users are on average more stupid than they used to be, and getting
increasingly more stupid as more and more newcomers arrive. It's your
job to take a design decision, based on your assessment of these
factors. Me, I'd generally take Nielsen's advice, unless I had a _very_
good reason for doing otherwise in a specific case.
Alan J. Flavell
-------------------------------
Leslie wrote:
> The whole discussion of what color links should be reminds me of the famous
> Henry Ford quote about his brand new cars, "You can have any color you
> want, as long as it's black."
Can you imagine the the chaos that would ensue if automobiles changed color
based upon which parking lot they were parked in? It's a lot easier to
find your car (or your web links) when colors remain consistent.
And yes, it's nicer if the user can choose the colors for his/her own car
(or web browser).
--
Darin McGrew
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
You might want to go to the Faq-O-Matic at
http://www.dartmouth.edu/~jonh/ff-cache/1.html
and visit the playground.
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
"Alan J. Flavell" wrote:
>Have we considered how useful _any_ kind of HTML link is on a
>printed copy, if the client agent doesn't summarise the links and
>their URLs somewhere on the printout?
I think I see your point - it would be the printing user agent's (such
as the print function of a browser, or a separate program for printing
HTML documents, such as html2ps) responsibility to present links
meaningfully, so authors shouldn't need to consider what the page
looks like when printed in a simplistic way which ignores that
responsibility.
I have a practical remark on that, and a more fundamental one.
Current browsers do a lousy job in printing documents, in general.
They break tables horribly, put a page break between a heading and the
following paragraph, and worse, get rather wild if you have nontrivial
style sheets enabled, etc. Moreover, current users aren't even well
aware of the possibilities, such as requested link targets to be
presented as footnotes (or whatever the browser's print function is
able to do). Even educated users may print pages without touching the
settings, so later on they'll see printed pages where links are
indicated with underlining only if at all.
The more fundamental, or theoretical, point is that a hypertext
document should degrade gracefully into normal text, if possible. It
should be possible to read hypertext, on screen or on paper or aloud,
ignoring the hypertext features. In such a mode, words like "send a
mail" don't even suggest anything about a particular destination for
mail. And with hypertextuality "turned on", hypertext links should
appear as meaningful items of information, rather than random words
("click here!" or "here") with no association with the content.
In my opinion, a good printing user agent would have two different
print functions, such as "print as text" (formatted text, not plain
text, but without any hypertextuality) and "print as hypertext" (or
"simulated hypertext"), effectively forcing the user to decide which
of them he wants. The latter would normally indicate link texts
visually (underline and/or different color, for example) and include
footnotes which specify the _titles_ (TITLE attribute values) of the
links, and optionally including other information like HREF and
HREFLANG values.
But as we know, current browsers are simple-minded in this area, so it
seems that authors must pay some attention to the fact that their
pages will actually be printed using a print function which is
somewhere in-between, and which often does not provide any real
information about links (except underlining the link text, which per
se isn't that helpful).
Jukka Korpela
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Pete Cooper wrote:
> We've just got a client and I'm in the throes of producing design
> proofs for them (as well as for our own site) and after a small
> display of ideas most practical ideas were immediately turned down
> (despite being the most usable and 'user-friendly') in favour of
> whizzy graphic based ideas using graphic-rendered text and large
> animated GIFs. After proclaiming the bandwidth and usability
> problems, my 'task' has become to make a highly bloated and slow
> page become 'ultra-usable', a challenge I'm trying to plod through.
My sympathies.
The WWW is a very different medium than either print or TV, despite
the possibility of using attractive graphics. I'm sure you know this,
but your colleagues are graphic designers who are not experienced
"web guys". You can talk about bandwidth till you're blue in the
face, but it probably won't faze them. Maybe the best thing to do is
make two or three mock-ups (varying levels of graphics, Java, frames,
and tables) and throw a little demo. Last I read in the GVU's
semi-annual WWW User Surveys, average modem speed is somewhere
between 28.8 and 33.6. Also, the number one complaint, according to
the GVU Survey, is that the web is _too slow_. Jakob Nielsen's
column, already mentioned, can give you hints on how long people
are willing to wait.
Clear your cache. Have the pages up at a real (remote) server. Use
an ordinary modem. Time the pages. Don't say anything while you're
waiting. Maybe even _they_ will get impatient if their
all-singing, all-dancing design takes 3 minutes to appear in normal
conditions. Then you drop the other shoe and say, "You know, I read
that 85% of people on the web will give up in disgust and leave if
they can't see *something* in 20 seconds." (Or whatever the
statistics you could track down.) Also remind them that the web is
not like print or TV: if someone visits, you already _have_ their
interest, but you won't hold them if you try their patience, let
alone if you insinuate that the visitor's browsing situation is not
good enough.
Elizabeth T. Knuth
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Lynn Alford wrote:
| jm9998@my-dejanews.com writes:
| >Sorry, no idea what Scooter is. x
|
| My, I can't remember the last time I saw someone miss a clue *that*
| thoroughly.
Quite normal on Usenet: the phenomenon is usually known as Invincible
Ignorance. The HEP people recently got to the bottom of this when they
managed to isolate the mozon. A mozon, they found, is a cluster of
bogons surrounded by a cloud of anti-cluons to annihilate any clues in
the vicinity.
HTH.
Arjun Ray
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On Wed, 2 Dec 1998, JSC wrote:
> I just read Warren Steele's excellent page, and now the Eternal Question
> comes to mind again: Is it now acceptable to use style sheets?
I'd say it always was acceptable.
> My
> understanding is that browsers prior to version 4 (Netscape/IE) do not
> support them.
Style sheets are designed that way. So if you use them right, it
doesn't matter. And the audio style sheet does no harm on a visual
browser, nor vice versa, if you've done your job right. And the reader
who has a brailler still gets your content, irrespective of the fact
that it can honour neither the audio stylesheet nor the visual one.
I'm not clear why this has to be repeated so often. It isn't exactly
secret lore.
> If one is trying to design for the most possible people, and using the
> FONT FACE attribute is not acceptable, how would style sheets be
> preferable?
Look, "design" of a web page comprises many things, of which visual
appearance is just one component. The ability of a page to calmly and
automatically adapt itself to a good range of viewing situations is
another aspect of web design, and in my opinion the more interesting and
challenging part of the WWW.
The only thing you can successfully do on the WWW with font control is
to select some boring mass-market font out of a small repertoire that
you can rely on everyone having. This means that for those who cared
enough to shell out for a really good specialist font, every time your
FONT FACE is successful you're degrading their browsing experience.
This is not just "authoring for the lowest common denominator": you're
forcing the lowest common denominator down everyone's throat.
(Fortunately they can turn that off, at least to some extent in most
browsers).
Speaking in more general terms, rather than focussing on FONT FACE...
Style sheets do no harm at all in browsers that don't support them, and
don't get in the way when a reader, for whatever good reason, has to
turn them off because they're causing a problem. And they don't clog up
7kB of content with 35kb of idiotic markup, like some wannabeWYSIWYG
tools I could think of.
Admittedly there are problems with Win MSIE3 and Mac MSIE3 (careful:
these are two different browsers, with different behaviours), that
implement some kind of partial prototype of CSS1. If you're interested,
you study the various workarounds that are discussed on the stylesheets
group and via the resource at http://css.nu
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On 4 Dec 1998, Didier Godefroy wrote:
> What bothers me is that to comply with these validation rules, there are things
> that won't work right with the browsers,
I don't think it's very productive to make blanket allegations like
that. If you encounter a specific problem, then I suggest you raise it
here: for many of the alleged problems with validation, there are well
known and respectable solutions, for others there are serviceable
workarounds, and if you've found one of the rare cases when there really
isn't a solution then I, for one, wouldn't be too proud to concede the
point.
The benefits of validation for programmatically locating real errors are
just too great, in my experience, to want to pass them up because of
some IMO "rare" anomalies.
> and what's important is that these
> browsers get the job done right,
That depends on your definition of the job. "Writing broken HTML
to get the job done on the browsers one's familiar with" translates into
"taking risks with browsers one's not familiar with". While I'll
certainly avoid writing a bit of valid HTML knowing that it can cause
problems, I'll only very rarely admit to writing invalid HTML to get the
effect I want; and in the classic case, my carefully tested bit of
invalid HTML did finally stop working when a new browser version came
out.
> they don't comply with the rules, so why should we?
Because of the first rule of client/server interworking.
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On Fri, 4 Dec 1998, Panos Stokas wrote:
> The accessibility of your document depends on what your readers use.
> Thus, if your logical markup is OK and your document works in Lynx,
> Opera, Netscape and IE -- then I don't think you need to bother.
You know, people said that about Netscape version 1, and then they had
to scurry around fixing some well-known defects when they found that
version 2 had tightened up the syntax. And much the same happened
with version 3. And along came version 4, and surprise, surprise, they
had to fix some more. Those who had written valid HTML were busy
making new documents, amd smirking at those who had to go back and
repair the problems that they had created for themselves.
I never claimed that mere HTML syntax validation was a complete
recipe for success; there is no such guarantee. However, when there's
a right and a wrong way of doing something, I'm going to choose the
right way.
I've seen a page, some years back (amusingly, it was the CERN home page,
but I'm glad to say the fault was soon repaired) that was completely
empty when viewed on a conforming browser. It was only visible due to
the then-current version of Netscape incorrectly parsing comments.
(I'm only a user here, I have nothing to do or say in the design
of CERN's official pages).
MSIE was originally designed to be bug compatible with Netscape. Well,
OK, this will be less of an issue nowadays, but I still say it's more
reliable to use progammatical validators and checkers than to mess
around previewing content on several browsers and hoping to spot some
maybe inconspicuous but potentially significant problem. Previewing on
browsers is useful, which is why I keep as many as I reasonably can
(pity that Win MSIE is so wilful in this regard); but I'm not previewing
in order to catch HTML syntax errors, but for quite other reasons.
Alan J. Flavell
-------------------------
>
>You know, people said that about Netscape version 1, and then they had
>to scurry around fixing some well-known defects when they found that
>version 2 had tightened up the syntax.
[etc. with later versions]
For a brief story of this with some illustrating details, see
http://www.htmlhelp.com/tools/validator/reasons.html
Jukka Korpela
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On 2 Dec 1998, Didier Godefroy wrote:
> Jukka Korpela wrote:
>
> > Interestingly, you are using the icon for validated HTML 3.2, despite
> > still having difficulties in trying to make the page comply even with
> > HTML 4.0 Transitional.
(reformatted to usenet conventions:)
> I had the doctype set to 3.2 before, but errors were showing up
> anyway, I tried several doctypes, including the netscape specific one,
> and I gave up on that, I ended up with 4.0 transitional and I fixed
> many things to comply with it, there are only few of them left, and
> these won't go away, one deals with the NAME in an IMG tag, I use it
> with Javascript, so I can't take it out, one is a BORDER also in an
> IMG tag associated with a Submit button, same problem there, it won't
> go away as if I remove it, Browsers display a border around that
> button picture, so there's no way this BORDER is getting removed.
etc.
Look, it's entirely your decision how far you're going to go with
validation. I'd recommend it, and some of the problems you mentioned
can clearly be solved in the terms of one of the available public DTDs.
But there's a different point being made: that it can be seen as
dishonest, as well as misleading, to include a specific HTML checked
icon when you haven't earned it. Considering that this is right
alongside an offer to design web sites for customers, this comes
very close to fraud.
If I hadn't already been in favour of writing correct syntax, then
I feel sure that experiences with CSS would have convinced me. I do
urge you to take this on board; but in the final analysis it's your
choice, all that anyone else can do is present you with considerations
that you should take into account.
> Lastly, errors show up also on every one of my
and I want to keep
> them too, unless you know of something to replace them with...
You did the validation; if you want an answer, why not show us what
the validator told you? There are people around here who are still
trying to help, in spite of the way that this thread seems to be
stubbornly going on and on.
Btw if you want more easily understandable reports, I recommend
using the online validator at www.htmlhelp.org instead. It applies
the same rules (of course; it wouldn't be a validator if it didn't),
but its diagnostics are less cryptic:
Line 140, character 22:
^
Error: element HR not allowed here; possible cause is an
inline element containing a block-level element
And indeed you have a structure like this
...
which is trivial to fix. (Get rid of that SIZE="-2" nonsense while
you're about it. TWO sizes smaller than for normal reading? That would
be fine for, say, a detailed copyright notice, and such stuff as your
business register number whatever, that the lawyers told you to put
there although normal mortals wouldn't be interested in it; but it's
absurd for conveying your real message.)
You might suppose that the site was "optimised" for the Big Two, but
apart from some slightly weird choices of ALT text, frankly this site
was easier to read with Lynx than with either of the Big Two as I
normally use them.
And just bear in mind that readers who have gained a little experience
with using the web have probably learned to translate "Optimised for the
Big Two" into "This author doesn't know how to design for the WWW".
What are they paying you for advertising them, anyway?
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On Fri, 4 Dec 1998 11:03:06 +0100, Alan J. Flavell wrote:
>On Fri, 4 Dec 1998, Eric Bohlman wrote:
>> I have seen mention of programs that take a plain text file and guess at
>> the markup needed to do a useful HTML conversion, e.g. identify
>> paragraphs, headings, lists.
>
>I've used a perl script called (not surprisingly) txt2html, which is
>nowadays found at http://www.thehouse.org/txt2html/
I'm quite impressed with this particular implementation: it
correctly auto-recognized almost everything I threw at it, and
generated valid markup to boot.
I may eventually set up a CGI gateway for this fine tool, unless
someone else beats me to it...
--
Gerald Oskoboiny
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Reverend Iyengar (keeda@worldnet.att.net) wrote:
: font-size:8pt ;
You shouldn't really use points as font size units--they are
practically unsuitable for screen display. See
http://www.verso.com/agitprop/points/font_wars.GIF for a
nice example complete with explanations.
Use em's, ex's or %'s instead--or pixels, if you *really* think
you must specify absolute sizes.
Antti Nayha
----------------------------
On 7 Dec 1998, Antti Nayha wrote:
> : font-size:8pt ;
>
> You shouldn't really use points as font size units --they are
> practically unsuitable for screen display.
agreed
> See
> http://www.verso.com/agitprop/points/font_wars.GIF for a
> nice example complete with explanations.
So we're in good company...
> Use em's, ex's or %'s instead--or pixels, if you *really* think
> you must specify absolute sizes.
Some absolutes are less absolute than others, it seems.
I wouldn't call em, ex or % an "absolute" size.
There's one case where stylesheets can address a real problem:
persuading images and text to be sized together (e.g when using images
of characters that aren't supported as text - latex2html is the classic
case in my field). But I haven't made up my mind yet whether I prefer to
do that by sizing the images in ems to match the font, or sizing the
text in pixels to match the images.
Alan J. Flavell
------------------------------
> On 7 Dec 1998, Antti Nayha wrote:
> > http://www.verso.com/agitprop/points/font_wars.GIF for a
> > nice example complete with explanations.
The problem with GIFs is that they don't have links, but I went
walkabout, and he has more about this at
http://www.verso.com/agitprop/points/dump.html
I strongly recommending reading this page. I feel that I've learned
a lot from Todd Fahrner; this is no exception.
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Pablo Gutierrez Torrero wrote:
> in which browsers work ccs?
According to (the CSS Pointers Group's
answers to general questions), Amaya, Emacs-w3, Internet Explorer 3x+,
Netscape Navigator 4x+, and Opera 3.5+.
> how i can make the links not underlined?
The answer to this FAQ is at or
.
comp.infosystems.www.authoring.stylesheets is a better place to discuss
CSS.
--
Darin McGrew
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
(Patrick J McDonough) writes:
> Anybody want to chime in on which fonts they think look best? Which fonts
> appear most often in fontsets on most machines? Can anyone point me to
> examples of a particularly great-looking font layout?
Courier is the only font I have on all four of my computer systems.
And it's not a nice web font for general text. On each system I'm
using a different font -- because for different monitors, resolutions,
windowing systems, font sets, I have a different favorite. It's
unlikely that a person writing a web page can figure out what fonts
look good on my system, so it's probably better to use the user's
default.
Amit J Patel
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
MPCM wrote:
: Showing them the progress of the site can help a great deal. It allows
: you to show off what you know and lets them know your ability in
: genuine.
Even more important, it gives the customer a chance to make sure that
what they want and what they've asked for are the same. In development
projects of all sorts, it's often very hard to fully specify what you
want until you have something concrete to compare it to. If you build
the whole thing in a closet and don't unveil it until it's complete, you
run a good risk of discovering that you've built the right solution to
the wrong problem.
Another point related to the speed with which sites (or any development
projects) can be created: in all but the most trivial cases, you're
going to be dealing with multiple "constituencies." Different
departments within a company that's getting a site designed for them are
likely to have different ideas of what the site should do for them. And
you're going to have to rely on different people within the organization
to provide you with different peices of information that you need.
Coordinating all this takes time. It's very rare that you can get
precise specifications handed to you through a single contact point.
IMHO, in any non-trivial project things like coding and graphic design
are going to take up the *smallest* portion of your total time. Basic
requirements analysis, which includes time spent coming up with
compromises when there are conflicting needs, is likely to be the biggest
chunk of time. And a good chunk of that time is going to be spent
waiting: waiting for people to get back from trips, waiting for people to
hash out conflicts among themselves, waiting for people to return your calls.
Eric Bohlman
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
[ 8< ]
Oh, and one last complaint. I hate homepage links on a home page. They
remind me of the old joke about how to keep a moron (or JavaScript)
busy for hours, you remember, the one about the piece of paper with
"The statement on the other side of this paper is true!" on one side
and "The statement on the other side of this paper is false!" on the
other.
Jim Hollomon
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Patrick J McDonough wrote:
> Okay, someone got on my case for having a dark blue new link color on this
> pink-to-red gradient fade background.
This is a practical human-factors issue. Blue and red are at opposite ends
of the spectrum, and it strains the eye to keep such different wavelengths
in focus simultaneously. Or so I hear.
> Anybody want to recommend a good color scheme, or recommend some general
> good practices in finding colors that work? I want to keep the regular
> text black, but I'm flexible in most other respects. The client also
> likes the gradient.
Assuming that you won't take the "specify no colors, use the reader's
default colors" approach--
On the web, most readers expect blue links and purple visited links. If
you use any other colors, your readers will need a moment to figure out
your color scheme. Confusion (however brief) regarding basic site
navigation is a bad thing.
It's better for unvisited links to be more prominant than visited links, so
choose a more subdued purple and a more vibrant blue.
Do not make links and visited links the same color as each other, and do
not make either the same color as normal text.
The above is all basic interface-usability stuff. If you want to go beyond
that, I know just a few basics of visual design:
Keep it simple. Limit yourself to three basic colors--foreground,
background, and emphasis. Usually, two of these colors should be black and
white, and usually black and white should be your foreground and background
colors. Be very careful adding more colors to your palette.
On the web, you've already got two colors for links, and links form a
natural emphasis. You need to be very careful with adding colors to your
palette. Reusing the link colors invites confusion (and confusion over
site navigation is a bad thing), and adding a third color can make things
too busy.
--
Darin McGrew
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
d-con wrote:
> In almost 4 years I've had very few (hardly
>any, actually) complaints from either site owners or from site
>visitors.
Getting no complaints is rather serious. It typically means nobody is
interested enough, or perhaps unable to complain since the page lacks
a feedback address, or has it misspelled. :-) There is nothing perfect
on the earth, so any really good site will inevitably cause some
"complaints".
Jukka Korpela
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
WYSIATI (What You See Is All There Is)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Roberta and Craig Becker wrote:
>
> nYcHen (nychen@hotmail.com) wrote:
> : Please critique the site design for
> : http://www.parkers-place.net/nychen/wop
>
> The graphics are very nice, and everything loaded quickly for me
> over a 33K modem connection. My one criticism is that it's not
> obvious just what the site is all about--a pet peeve of mine, I
> guess, but I hate visiting a site, even a nice-looking site, and
> having to wander all over it just to figure out what it _is_.
It's apparently an X-Files fan page, judging from the titles of the
"fanfic" items. But your criticism is on-target; every site whose
purpose is not immediately obvious (and not just to a limited in-group)
ought to have an "About Us" section linked prominently from the front
page to provide explanations as to the purpose, contents, and intended
audience of the site.
--
--Daniel R. Tobias
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Some general tips on how to "surf" the web more efficiently:
* Turn off Java and Javascript (and only turn them on when you really
want to see a web page that doesn't work without them). You will find
that this makes many pages load much faster and causes your browser
to crash less.
* Turn off image loading (and load those images you want to see, after
the page has already loaded). This will make the page load faster.
Often the only pictures people have on pages with mostly text are
just decorations, that don't really add anything to the content. This
way you don't have to see those decorations.)
Some general tips on how to make fast web sites:
* Don't use _unnecessary_ graphics, sound, Javascript and Java.
* Reduce the file size of the pictures you do use. Most photographs
will have a smaller file size (and better visual quality) in the JPG
format. Most drawings will have a smaller file size (and better
visual quality!) in the GIF format.
* Make sure to add WIDTH and HEIGHT to *all* "IMG" tags! (especially
those at the top of a page and those inside tables) This can make a
page appear to load *much* faster (the user will _experience_ that
the page is faster, even though it _really_ takes just as long to
load as before, but in this situation it is what the user experiences
that matters).
* Make sure to add good ALT text to all your images (for images that
are only decorative you use ALT="" to tell the reader that the image
is decoration and not content). This helps the reader to see which
images are interesting enough to download, and he/she will then
experience a faster page.
* If you are going to put a sound file on a web site, don't make it so
that it loads automatically. Instead, make an ordinairy link to the
sound file. Example: My cat can sing!. This
way the reader has a choice to load or not load (remember, many sound
files are HUGE, i.e. they will take long to download).
* Don't use tables or frames unless it is really necessary. It is often
better to "hand code" a page than to use "WYSIWYG" HTML editors, since
that gives you "cleaner" and "leaner" code, that often loads faster
(depending somewhat on the author's skills, of course).
* Write correct html. Incorrect html will make the browser work harder,
which will make the page feel slower. A "validator" (like a "spell
checker" for html) can be very useful. You can find one here:
http://validator.w3.org/
--
:) Irebavpn Xneyffba \ /_ _ _ _ . _ _ Zl bgure fvt vf n Cbefpur
( r93-ixa@fz.yhgu.fr \/(-| (_)| )|(_(_| uggc://jjj.yhqq.yhgu.fr/~ix/ )
If you have a question about html, read the FAQ before asking it to the
group: http://www.htmlhelp.com/faq/wdgfaq.htm (No? Read it anyway!)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
VK [email] [home] 12 Dec. 22:02, from: 130.240.2.25, red
[Correct way to do it: CSS ]
FS 12 Dec. 22:04, from: 130.240.2.193, turquoise
[Redundant garbage: CSS]
VK [email] [home] 12 Dec. 22:06, from: 130.240.2.25, red
FS >> Exactly! Use CSS for "redundant garbage"! (that's what it's for...) :)
FS 12 Dec. 22:09, from: 130.240.2.193, turquoise
VK >> Use CSS and people with Real Computers (Amigas) won't see colour
for at least a year from now.
VK [email] [home] 12 Dec. 22:10, from: 130.240.2.25, red
FS >> So? The pages should still be _useful_... (which they won't be
in some browsers if you use and things like that...)
FS 12 Dec. 22:21, from: 130.240.2.193, turquoise
_
_(_)_
( )
\___/
______(_|_)______
_____/ U \_____
.---.
|CSS|
`---'
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Subject: Re: What are the design software for web design?
A) Notepad, and B) a Browser. A comes with the computer, B comes with the
ISP software. (ie you already got it) Learn HTML, practice, invest in a
coffee percolator (you're gonna need it, bub), practice some more, go into
therapy, face up to a life of caffeine addiction (and probably nicotine
addiction). That's how the REAL designers do it, without none o' this
fancy-ancy FrontPage Publisher HotDog+Onions DeBabylon5 schmeer.
1. "Necessity is the Mother of Invention." (or should that be "Mutha"?)
2. "Form follows Function."
P.S. And always run the Spell Checker. Always. One thing guaranteed to make
me hit "Back" is bad spelling. There is no excuse. As we speak, Satan is
decorating the bad Spellers Room in Hell ()
Sarah E Edgson
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On Tue, 8 Dec 1998, PJ Browning used up another spare apostrophe to say:
> It's not how you get the code written that counts, it's how you lay out
> the site and it's pages.
Who ever said that you couldn't do both: write some valid HTML, that in
a certain range of browsing situations gets rendered in the way that you
had in mind (and, it's hoped, in situations outside of that range still
makes its content accessible to readers).
> I can hand code a valid page that still
> doesn't work because I did a poor job with the 'design'.
Nobody ever said that valid HTML syntax was all that it took to achieve
a good WWW page. "Design", to my way of thinking, encompasses the
selection and marshalling of content, working out how best to divide it
up into reader-friendly chunks ("web pages"), which formats (HTML, with
or without i18n, object, etc; GIF, JPEG, PDF, TeX, whatever) to use to
achieve an appropriate compromise between functionality and
acessibility, and all that.
If you think that the word "design" in relation to the WWW means nothing
more than creating a specific visual effect in one narrow range (albeit
rather common) of browsing situations, then we have a serious language
problem. To quite a degree, I'd say that "form follows function", so
that a well-organised page has a tendency to look good simply by virtue
of its having been well-organised, and the cosmetics can make it look
even better; whereas a disorganised page can't be made to look good by
any amount of mere cosmetic attention.
But either way, given a choice of doing it with syntactically valid or
invalid HTML, I would choose the valid option. I doubt if a fraction of
one percent of the HTML syntax errors I've seen in web pages have
brought any benefit to the page, and in most cases seemed to be there
only to give the author an excuse to advertise the Big Two web-salad
tossers.
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Troels Tolstrup - u972757@daimi.aau.dk
Computer Science student at the university of Aarhus.
Real men dont comment their programs. It was hard to write,
It should be impossible to understand.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
I use the Web primarily for my work doing supercomputer software
support, a bit now for finding out what my running club's plans are
and a distant third for part of the process of acquiring some desired
good or service .
For my work, I want sites that load very fast and use virtually no
graphics unless the topic of interest is supercomputer graphics --
then I expect and want graphics. Unfortunately I see too many such
professionally oriented sites that are now loaded up with things like
useless backgrounds, pointless graphics and general flash that
actively obstruct my goal. Sometimes these sites take a long time to
load, even over a T3.
When I use the Web for personal reasons, I have a far slower
connection -- a 33.6 Kbaud modem. By the time I've decided to check a
site, I'm well past the introductory phase of the sales process. A
visually striking image is fine, perhaps even necessary, in a
television commercial or print advertisement. I'll pause in what I'm
doing and pay attention to the new stimulus. To me, however, when I
go to the Web, I'm already a bit interested. What I want at this
point is more information (and possibly an easy way to purchase). If
this means more graphics, so be it. But I don't want the design of
these kinds of sites to interfere with my ultimate goal, either.
Remember, before I've even reached your site, I've had to turn on my
PC, connect to the Web (multiple steps) and then go to your site. I
don't want to sit there and wait, wait, wait. I've been known to put
down a selected purchase and leave the KMart (US bargain chain) across
the street because I've waited too long in the checkout line.
In short, I have two objections -- closely related -- to some sites
designed for a high visual impact. In one part of my life, these
ideas are actively obstructing my work in totally pointless ways.
These ideas are not staying where they belong. Outside of work, I
want a commercial Web site to be like a helpful salesperson, not a
flashy magician. With sites oriented to my personal enjoyment, I'm
looking for something more like a letter from a friend or a note from
a social organization that will enable me to do something. The design
of high visual impact sites frequently works against these goals.
--
Chuck Divine
-------------------------
I've sometimes wondered if some Web marketroids have decided that if
e-commerce is to take off, the online shopping experience has to be made
as close to the the "real-world" experience as possible, complete with
checkout lines and music-on-hold.
You touch on a point that I've frequently written about (that Web sites
need to *maintain*, rather than *attract* attention, and you've inspired
me to repeat an analogy I used some time ago. If you're in a ballpark,
you expect to hear vendors yelling "Hot Dogs! Get your Hot Dogs!" at the
top of their lungs. But if you want a hot dog and approach a vendor, you
expect him to communicate with you by asking "what do you want on them?"
in a conversational tone, rather than yelling "Hot Dogs! Get your Hot
Dogs!" in your ear.
By the time you access a commercial Web site, you're at the stage where
you already know you want hot dogs; you're past the stage where you
"need" to be convinced to buy some. But all too many sites pretend that
they're part of the initial "attention grabbing" phase of the pre-sales
process, and turn off potential customers who are already past that
phase. Quite a pity, because while the latter are a *smaller* group than
the former, they're much more likely to buy.
Somebody else used the analogy that if they want to buy a car, they want
to go into a dealer and look at the models for sale and start
negotiating without having to first sit down and watch the manufacturer's
promotional video before a salesperson will talk to them.
Eric Bohlman
----------------------------
There's a theory that contemporary American businesspeople really only
understand a few aspects of running a business. This leads them to make
major blunders once they leave their areas of knowledge. I wonder if the
annoying, rather than helpful, Web site might be a consequence of this
shortcoming. For people interested in reading more about this idea, I
recommend Byrne's "The Whiz Kids." The book came out in the early
90s . It examined the careers of the team (Thornton, McNamara, others)
who joined Ford Motor Company in 1946 both individually, collectively and
their impact on American business. Some of the thinking in this book might
also apply to other nations as well.
Chuck Divine
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
[Date: Tue, 15 Dec 1998 01:48:49 GMT]
Braden N. McDaniel wrote:
>On the contrary, Mozilla is changing rapidly and NGLayout (read "Gecko" if
>you prefer) edges closer to conformance each day. But don't take my word for
>it. Go to mozilla.org and check the statistics in Bugzilla, and download a
>binary to put through its paces.
Indeed. Gecko is looking more like Opera in green scaly clothing every
day...
8^)
--
Dan McGarry
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Pete Cooper wrote:
> I tend to agree with you in that pages should be as compliant as possible,
> and more importantly to myself, usable and efficient. However.. your comment
> above seems to project the image that you think pages should just be long
> text files with links and the odd image. Correct me if I'm wrong, but is
> this really your opinion?
See http://ppewww.ph.gla.ac.uk/~flavell/www/html-smac.html
Most of this has been repeatedly discussed in this newsgroup,
and is archived at dejanews.com.
> Does anyone else here think that way? I'm personally between the two
> extremes, but I still see columned layout etc as being useful to improve the
> layout of a site..
HTML is too unreliable a means of creating "layout."
That's an opinion, of course, but it's the conclusion that
thousands of authors draw after months of trying to fight
it. If you use frames or tables for layout, you immensely
decrease the speed and efficiency of rendering, and you
increase the likelihood of illegibility or serious
inconvenience on systems with configurations the author
has not foreseen, including screen readers, palmtop
devices, or even untypical font sizes (for viewers with
impaired vision). If you use layout gimmicks, they will
become obstacles to getting your message across. If you
use honest markup, it will always represent your message
in a way that suits the medium.
Style sheets, used properly (which currently means
lots of extra work to coddle broken implementations),
offer a means of suggesting _optional_ visual
information, including fonts and layout, without
interfering with accessibility.
Author A: content is king, and might as well be
seen in whatever fonts, colors, and styles the reader
is comfortable and familiar with. Solution A: use
HTML, with few presentational elements and attributes.
This solution does not, however, rule out generous use
of images and multimedia to illustrate the author's
points. Without speaking for Jukka, of course, I'd
venture a guess that this comes pretty close to his
needs--he has a record as a skeptic on style sheets.
Author B: content is of primary importance, but
"it would be nice" if the reader can see the text in
an attractive presentation designed by the author or
his agents. Solution B: HTML with style sheets. Not
everyone can or will see the styles, but at least the
content will not be compromised.
Author C: content is of primary importance, but
it contains layouts, mathematical formulae, or other
material that cannot be entrusted to a simple markup
language. Specialist readers may be expected to have,
or to download, appropriate software. Solution C: use
PDF or another sophisticated page description format,
with instructions for obtaining readers or plugins.
Author D: Content? what content? content is
of secondary importance, presentation is everything.
Viewers? who needs 'em? if they haven't got setups
that are just like mine, they can take a hike.
Solution: any old thing, from broken HTML, stupid
frames, inefficient tables, to Flash and Java.
Doesn't really matter to anyone but the author.
>(as well as make it more original)
What's original about it--so many people are doing it...
--
Warren Steel
-----------------------
Pete Cooper wrote:
>In a recent posting by Jukka Karpala (sp?):
>
>>Yes. Write your page using device-independent markup. Refrain from
>>attempts to do "layout", especially things like trying to force some
>>particular text width, multi-column presentation, etc.
>
>I tend to agree with you in that pages should be as compliant as possible,
>and more importantly to myself, usable and efficient. However.. your comment
>above seems to project the image that you think pages should just be long
>text files with links and the odd image. Correct me if I'm wrong, but is
>this really your opinion?
I don't really advocate long files, although I may have the tendency
of writing long documents, but that's a separate issue. (Ideally, and
quite often in practice, one should provide material in several
formats, including one large file and a hyperlinked hierarchic set of
pages. But I don't think this was what you were asking about.)
There's very little I can add to the idea of having text, images, and
hyperlinks, except headings, phrase level markup (like emphasis, via
EM or STRONG), and tables for tabular material. Then there are forms
and some other ingredients. In fact, HTML is quite a lot richer than
plain text, yet simple.
It's sad if browsers present HTML documents poorly despite adequate
markup. But authors' efforts to improve the presentation are mostly
wasted efforts. If you marginally improve the presentation on some
browsers by using presentational markup, there's high risk of messing
things up in other browsing situations. Ultimately, you would be
trying to do what browsers should handle, and it's not very
productive.
Adding presentational suggestions to that might often be interesting,
but the fact is that there is rather little to be gained in practice
at present. If popular browsers supported style sheets more robustly
and if users were generally educated enough to turn style sheets off
when needed, it might be a different story.
>Does anyone else here think that way? I'm personally between the two
>extremes, but I still see columned layout etc as being useful to improve the
>layout of a site.. (as well as make it more original)
Originality is an interesting point. If all authors used simple
structural markup and all users had browsers set to display the markup
according to the user's preferences--headings the way I like, fonts
according to my taste, elements colored to please my eye, etc--things
might get slightly boring. My solution to that would be to add some
randomness to browser settings, variating details which don't matter
too much. :-) But seriously, I don't think there's much risk of that.
The avantgardistic layout schemes and fancy color combinations which
are so widespread make "puristic" page look something extraordinary.
The specific problem with multi-column layout is that it restricts the
browsing possibilities. And I don't see why it would be particularly
useful even when it works, i.e. when the user can afford a wide
window. We don't actually _read_ in a multicolumnar way.
Consider the way we read a newspaper. I open it, I scan thru the
headlines and images, and I decide to read some of the articles (and I
usually quit reading an article before reaching its end). To simulate
that on the Web would require a rather wide screen devoted entirely to
a Web browser. But there is no need to simulate. You can construct a
page with a few key sentences and images, and the reader can follow
the links. There is little reason to scatter those little pieces of
information around the screen. There is no reason whatsoever to make
the texts screaming big. When all of your text is headlines, there is
no reason to indicate them as headlines; they would _best_ be viewed
as normal text, since there is nothing they should be distinguished
from. So the document can be, roughly speaking, a text file "with
links and the odd image".
If you think this is too Laconic, there is nothing to prevent you from
trying various methods of suggesting presentational features.
Multicolumnar presentation is, however, especially problematic. If
it's just the popular design with a "navigational column" and a column
with content, it could be relatively harmless if the former is narrow.
But real newspaper-look causes confusion. A typical presentation of a
Web page as displayed by browsers resembles a scroll more than a
newspager page.
Jukka Korpela
---------------------------------
> Luck for
>them they don't have to market their web design skills to demanding
>net-commerce customers.
Oh I definately agree with that one. The thing I hear most is "So how can
you put across a full corporate image using plain HTML?".
>There are more than 60 million people reading the WWW now. To see
>which side is winning, visit any major commercial site like
>www.microsoft.com, www.netscape.com, www.amazon.com or any of hundreds
>more. See what you find. All text and tables applied to tabular
>information only? Hardly.
Although, that does bring up an interesting point.. Netscape.Com, Amazon.Com
and Microsoft.Com are all very plain sites (from an initial presentation
point of view), they all contain regular text, with a few images, and table
layout. Compare those to sites such as www.thedogs.co.uk or
www.jbwhisky.com , which focus nearly primarily on visual design.. those are
the sites that seem to win awards in magazines and are most initially liked
by their respective companies. However, when the site fails to get
sufficient returns due to being too bloated, they soon become disheartened
with the web and think it's a waste of money.
It seems to me that larger companies with hordes of graphics designers seem
to pull the large contracts for websites, but the websites produced by these
companies are the ones you read about once, and then never hear of again!
This is entirely a British spin, I wouldn't know if this goes in the States.
>My vote goes for sites that succeed in using a limited set of
>extensions to present material in a highly pleasing but very widely
>accessible form.
Agreed.
Pete Cooper
---------------------------
"Pete Cooper" wrote:
>Netscape.Com, Amazon.Com
>and Microsoft.Com are all very plain sites (from an initial presentation
>point of view), they all contain regular text, with a few images, and table
>layout.
I listed only those three precisely because of that. These sites use
tables to achieve pleasing presentation, not just to present tabular
information. However, they go a long way toward making their
presentation viewable for the wide audience that they wish to reach.
They are examples of what I think a reasonable design vs. rigid HTML
compromise should be.
Jim Hollomon
--------------------------
>It seems to me that larger companies with hordes of graphics designers seem
>to pull the large contracts for websites, but the websites produced by these
>companies are the ones you read about once, and then never hear of again!
This isn't new. In the advertising world, the award winning "designs" never
account for, nor corralate to "success".
REBUS
--------------------------
On Tue, 15 Dec 1998, Jim wrote:
> you are spot on when you note that there are some posting
> regularly here who favor plain-vanilla HTML and nothing more.
Please identify one for us.
> There are more than 60 million people reading the WWW now. To see
> which side is winning, visit any major commercial site like
> www.microsoft.com, www.netscape.com, www.amazon.com
http://www.useit.com/alertbox/9706a.html
The Fallacy of Atypical Web Examples
>or any of hundreds more.
There aren't "hundreds more" like microsoft.com, netscape.com and
amazon.com. You chose them because they were atypical, but somehow
you don't seem to have realised that.
> See what you find.
Well, for example a site that my colleague said he only visited
reluctantly, and only when he had no alternative. Finally he lost his
cool and ordered the CDs, so as not to have to struggle with the web
site. Is that an advertisement for a web site?
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> From: RacerX@Mach5.com (Richard)
> Date: 13 Dec 1998 14:01:04 -0600
>
> How come the most arrogant and judgemental bastards in the field of
> web site authoring are the ones who believe in creating web sites with
> very minimal graphics and technology? I hate these people.
(Geez, who pissed in your Corn Flakes this morning?)
You're not saying that every minimalist is an arrogant bastard, are you?
I'll take your minimalist label and leave the rest for someone else.
I suspect that the more gracious minimalists think that the People of
the Cluttered Sites are merely ignorant.
So you know, we could as easily rant against arrogant maximalists. What
makes them think we want to see their animated clip-art gifs, squint at
their text-on-background-images, see how many people accessed their
page, click every link to find what we're looking for, wait for java to
initialize just to see an animated image, download special plugins, ad
nauseum? In short, what makes them think their site is worth the effort
needed to read it?
I hate those people.
Err, I'm not sounding arrogant and judgemental, am I?
ken mohnkern
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Dave Updike wrote:
>I've been given a task of figuring out how to view Excel and PowerPoint
>files on our intranet.
In principle, you just need to make them available on a Web server
which sends adequate media type information about them. It is then up
to users how they have configured their browsers. It shouldn't be too
difficult, since a browser, upon encountering an unknown media type
for the first time, will ask the user what to do, and the processing
specified thereby will usually become part of the browser settings.
Sometimes things get more complicated, of course. But basically,
that's it. See
http://www.hut.fi/u/jkorpela/HTML3.2/4.7.html#links2bin
which actually discusses how to _link_ to such resources in HTML. You
need not do even that. But of course, things might become easier if
you used HTML as "hyperglue" (to use Alan Flavell's nice word), i.e.
you could for instance write an HTML document which just contains a
list of links to Excel and PowerPoint files, with verbal explanations
or even with some images if desired, to make it easier to users to
access them.
In practice, if you use IE, you need to take care of that browser's
peculiarities by naming the files the way it likes to have them named
(e.g. name.xls and name.ppt), but probably you'll use such names
anyway since they are so commonly used.
Jukka Korpela
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Stewart Dean wrote:
> At the end of the day an interactive designer (not graphic designer or
> computer programmer) can create a better interface than the user in
> the vast majority of cases,
I don't think that was ever in dispute. But many WWW authors seem to
think they have to create their own user interfaces, to hide or
eliminate the ones provided by the browser developers. I don't think
they're doing a particularly good job of it - and for the most part, I
just wish they wouldn't try it, and get on and provide the content that
I'm seeking, instead.
Nothing wrong with video games, in their place, but that isn't usually
what I'm looking for on the WWW.
> I'll repeat for those who may not agree that
> interface design is less about 'common sense' than you may think.
OK then, I'll repeat that, for me, that was never in dispute. I don't
claim to be good at it myself, but I think I can recognise a bad one
when I meet one. (Did someome mention frames?).
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martín Capón Borrego wrote:
>I used...
>
>style="display='none' ...and...
>style="display=''
>
>in order to show and hide a submenu.
>
>In IE it is okey, but in Netscape it fails. U know an alternative in
>Netscape so I can hide a submenu in this browser. I didn't find a
>solution!!
You may want to start by reading up on the CSS specs in the first place.
I'm moved into one of my "rare" angry modes by posts like this one, and
I just want to say that "Your Use Of CSS Stinks" (got that?)
(if it's of any comfort to you, you just happened to be the one that
triggered this response, following a lot of others doin the same stupid
thing)
But I still get damned angry when I see people that does not even try to
find out a single detail about what they are trying to do.
1) MSIE _is_not_a_reference_browser_ for Cascading Stylesheets
(in fact MSIE stinks totally in this area)
2) The correct info about CSS1 is here...
http://www.w3.org/TR/REC-CSS1
...it does, among a lot of other things, say that style rules should be
written like this (your examples used)
style="display:none"
style="display:''"
...please note the definite distinction between '=' and ':'
Then if you can make that "work" inside the browser of your choise,
that's still a big question, but if nothing else it should give you
"fodder" for a few bug reports to "well known" browser vendors.
P.S.
Don't rely on scripting languages to do anything of real value for you.
There are thousands and more thousands of people sitting behind
proxies/firewalls that don't let that type of crap-info through to their
browsers.
DHTML is equal to a "dead end" for pro's.
D.S.
--
Jan Roland Eriksson ..
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Stewart Eastham (sme@planetpod.com) wrote on MCMXXXIV September MCMXCIII
in :
++ We are creating a database driven website using HTML templates, PERL and
++ mySQL. The content for many pages does not physically live on any
++ particular page, and is filled in by a PERL script upon request. What is
It's either Perl, the language, or perl, the binary. But not PERL.
++ the process for ensuring that sites like this get indexed in search
++ engines, if at all possible?
Do you really think a search engine would care how your web pages are
generated? You would use exactly the same process as for every other
way to create web pages.
++ Additionally, we recently reorganized our
++ site's structure and many search engines on the net have the links wrong,
++ and we'd like to reindex. Is there an easy way to do this, like a meta
++ index which reindexes many (or all) other engines? Or is there something
++ like a script which we may install on our server which can broadcasting to
++ search engines when our site's content or structure changes?
No. They'll find out. Eventually.
Abigail
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
"[T]he ability to write well is the most powerful weapon you can wield in
cyberspace."
-- Jay Conrad Levinson
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
"Stephen Foster" wrote:
> [ 8< ]
>Thank you I am aware that HTML is a language. Is it not a language used to
>program Web pages? I hear this usage all the time online and my brother, who
>is a programmer, concurs with it.
Html is a mark up language, like rtf etc so the correct phrase is
probably authored. Javascript, java, C++ etc are programming
languages so you program those.
Now I'm just off to program a magazine article :)
Stewart Dean
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Penfold wrote:
>Can someone tell me the IE equivilent of |