Subject: Using a lleft-aligned image at the start of a list item
Date: Wed, 22 Dec 1999 09:15:15 GMT
From: Jukka.Korpela@hut.fi (Jukka Korpela)
Newsgroups: comp.infosystems.www.authoring.html
I'd like to include an image at the beginning of a list item,
left-aligned (inside that item). The obvious way
seems to cause weird effects. Used inside an ordered list
(demo: http://www.hut.fi/u/jkorpela/test/wdl.html ), it gives:
- on IE 4.0, the presentation is what I'd expect but without the
number for the list item!
- on Netscape 4.0, the image appears below the first line of text in
the item, and depending on the window width, the next item's number
may appear wrongly nested
- on Opera 3.6, as on Netscape.
(My demo uses a style sheet which has some rules related to lists, but
taking that away, i.e. removing the element, does not change
the situation.)
Later I noticed that simply removing the align attribute helps. So
it's not a big _practical_ problem _if_ you know it, but I'm still
puzzled. Especially since Netscape and Opera behave similarly, I
wonder whether the meaning of align="left" is obscure. I thought it
meant aligning to the left inside the space available (here: inside
the space reserved for a list item content) and no other effect,
except that text flows on the right of the image. Am I missing
something?
------
Jukka Korpela wrote:
> I'd like to include an image at the beginning of a list item,
> left-aligned (inside that item). The obvious way
>
> seems to cause weird effects.
I must admit that does not surprise me. ALIGN (left or right) on the
IMG tag calls for the image to be floated to the (left or right)
margin.
With respect, I'm not at all sure I agree with you that this is the
"obvious" way (if I'm understanding correctly what you wanted to
achieve). Using the IMG without an ALIGN attribute would be my first
try. Of course, that's assuming that the whole list is subject to
block-level markup that specifies or implies left alignment anyhow,
so that the IMG needs no special horizontal alignment control.
If that isn't so, maybe you're looking for something like
...
rest of list item
...
Not that I can see very much use for this, since a UL inside the scope
of a block structure with ALIGN=RIGHT or CENTER with an occasional item
explicitly aligned left seems quite odd. Sorry, no criticism intended,
I'm just thinking aloud.
Alan J. Flavell
--------
Alan J. Flavell wrote:
>ALIGN (left or right) on the IMG tag calls for the image to be floated
>to the (left or right) margin.
Yes, but the question is: which margin? The overall page margin?
Perhaps such an idea lies behind some of the odd behavior I saw. But:
"Two other values, left and right, cause the image to float to the
current left or right margin."
http://www.w3.org/TR/REC-html40/struct/objects.html#adef-align-IMG
In the case of ...
..., I'd say the
current margin is what the browser uses for list items, no matter how
that margin is determined (browser defaults/settings, CSS).
But in location cited, we see a warning (which I should have noticed
previously of course):
"Differing interpretations of align. User agents vary in their
interpretation of the align attribute. Some only take into account
what has occurred on the text line prior to the element, some take
into account the text on both sides of the element."
I'm not sure I understand it fully, but I take it as a general caveat.
>Using the IMG without an ALIGN attribute would be my first try.
A rational approach, but given that there is no default value for
ALIGN by the specs, I thought I'd suggest left alignment explicitly.
Browsers seem to use left alignment by default rather unanimously, so
my thought was probably too theoretic.
The problem with IMG without ALIGN is that text does not flow on the
right of it. In my case it doesn't really matter, but for someone who
wants to set up a pretty normal
text here
construct, it can be annoying that you can't do that inside a LI
element. If this were important, I'd probably replace the list
construct with a table, with explicit item numbers in the first column
and list items in the second.
Jukka Korpela
------
Jukka Korpela wrote:
> >Using the IMG without an ALIGN attribute would be my first try.
>
> A rational approach, but given that there is no default value for
> ALIGN by the specs, I thought I'd suggest left alignment explicitly.
> Browsers seem to use left alignment by default rather unanimously, so
> my thought was probably too theoretic.
Sorry, I'd have to contradict you there.
While it's true that the alignment of block structures usually defaults
to LEFT, you have to keep in mind that IMG is not a block structure, and
an ALIGN value on IMG has a special meaning. (As it does also on
TABLE). Their default behaviour is quite different from their behavior
when given the attribute ALIGN=LEFT.
> The problem with IMG without ALIGN is that text does not flow on the
> right of it.
Uh-uh. I think you're saying that you want to see something like
(*) ---------- some text some text some text
| | flowed onto lines and lines of
| | the area alongside the image...
v v
where (*) is the list bullet. I don't know how to get that, as a list
item, with any kind of reliability.
> In my case it doesn't really matter, but for someone who
> wants to set up a pretty normal
^^^^^^^^^^^^^
>
text here
> construct, it can be annoying that you can't do that inside a LI
> element.
That all depends on what you expect a "pretty normal" result from that
construction to be. I have surmised that you intend it to be as I
diagrammed above, but unless/until you say what you expect, I don't see
how we can understand your "pretty normal" expectations.
> If this were important, I'd probably replace the list
> construct with a table, with explicit item numbers in the first column
> and list items in the second.
Could well be. Depends a bit on the content, but it could be
justifiably argued that this is tabular data. That it will produce the
desired visual result is of course not in dispute.
Alan J. Flavell
------
Alan J. Flavell wrote:
> Jukka Korpela wrote:
>> Browsers seem to use left alignment by default rather unanimously, so
>> my thought was probably too theoretic.
>
>Sorry, I'd have to contradict you there.
Is that how you spell "teach" in British English? :-) Thanks. I hope
some other people have learned from this too.
>While it's true that the alignment of block structures usually defaults
>to LEFT, you have to keep in mind that IMG is not a block structure, and
>an ALIGN value on IMG has a special meaning.
Now that you say it, yes.
>Uh-uh. I think you're saying that you want to see something like
>
> (*) ---------- some text some text some text
> | | flowed onto lines and lines of
> | | the area alongside the image...
> v v
>
>where (*) is the list bullet. I don't know how to get that, as a list
>item, with any kind of reliability.
Yes, that's what I meant. And it seems obvious that align="left" for
an inside a
can have strange effects, but I still don't
quite see why (i.e. whether it is a browser bug, or a feature, or
something else).
>> If this were important, I'd probably replace the list
>> construct with a table, with explicit item numbers in the first column
>> and list items in the second.
>
>Could well be. Depends a bit on the content, but it could be
>justifiably argued that this is tabular data. That it will produce the
>desired visual result is of course not in dispute.
Yes, it seems to work, so to say. What still puzzles me is why
is processed by browsers quite differently from
Both LI and TD elements are containers which occur inside block level
elements and may themselves contain both text and block level
elements. I suppose the essential difference, in this issue, is that
for LI, there (usually) is a bullet or item number of some kind, and
that stuff is part of the box in which the LI is rendered. But I still
see this as a flaw in implementations; a presentational suggestion on
an image shouldn't cause an list item number to be suppressed.
Jukka Korpela
-----
Jukka Korpela wrote:
> >Uh-uh. I think you're saying that you want to see something like
> >
> > (*) ---------- some text some text some text
> > | | flowed onto lines and lines of
> > | | the area alongside the image...
> > v v
> >
> >where (*) is the list bullet. I don't know how to get that, as a list
> >item, with any kind of reliability.
>
> Yes, that's what I meant.
Well, I've played around with various permutations of
, ,
and
, inside
, in syntactically valid ways;
nothing really seemed to do the trick as depicted above.
With NS4.7 I can either get:
(*) text text text text text text
------------ text text text
| | text text text
v v
Or:
(*)
------------ text text text
| | text text text
v V
Much the same happened in IE3.
Whereas on IE5, whatever I do, the bullet disappears, as you pointed
out. Curiously, IE5 didn't put the image in the place where the missing
bullet would have been: it put the image further to the right, lining up
nicely with the start of the text in other, text-only,
items
I think I'm going to give up on this.
I don't think you're being unreasonable to hope for it to work. But it
doesn't seem as if it's going to.
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Mike Wagner wrote:
> Can anyone point me to resources for designing pages for color blind folks?
Two come to mind, and I'll be interested in what other replies you get.
"Effective Color Contrast" by Aries Arditi
http://www.lighthouse.org/color_contrast.htm
"Color Vision, Color Deficiency" by Diane Wilson
http://www.firelily.com/opinions/color.html
Susan Lesch
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
David Wier wrote:
> If you want to be safe regarding your domain name, you ought to buy
> all the extensions possible, it looks like.
"Mom! David just jumped off a bridge! Can I jump too?"
greg@apple2.com
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Subject: Browsing in New Windows
Date: Tue, 11 Jan 2000 18:10:29 -0500
From: Jay Goldman
Newsgroups: comp.human-factors
It's occured to me over the last few months that I've developed a very
defined surfing style. I almost always open new links into new windows,
especially if they link to a page on a different site. I don't think I
ever conciously decided to surf this way but I feel really trapped if I
can't find a way to spawn a new page.
What really brought this to my attention was the number of people who do
the same thing. I keep running across comments from people all over the
world who casually mention this habit. I watch people surf who do it all
the time. It's become such a part of my daily-web viewing that I would
probably disown a browser that didn't have an "Open in new window..."
command in the contextual menu.
My question: how do you surf? Is this actually a documentable trend and,
if so, how could the browser UI be redesigned to accomodate this?
------
> It's occured to me over the last few months that I've developed a very
> defined surfing style. I almost always open new links into new windows,
> especially if they link to a page on a different site.
My (informal) user surveys and user observations saw that, pretty much
as a rule, power users do this and normal users do not. It's a fairly
linear progression.
I have no idea what you'd do to the browser UI to fix this except
maybe get the weasels to standardize the contextual menus to put the
item in the same place (I'm chronically opening the wrong menu items
when I switch browsers/platforms).
It is an issue for UI developers though: you have to account for
power users who may be opening windows willy nilly, yet you cannot
rely on novice users doing it.
Faisal Jawdat
------
> My (informal) user surveys and user observations saw that, pretty much
> as a rule, power users do this and normal users do not. It's a fairly
> linear progression.
I follow this browsing patterns as well. Periodically during the day i go on
what amounts to foraging missions on sites I frequent. A number of these are
meta resources for technology news like Slashdot or Yahoo!'s news. I will
scan the headlines opening the ones i'd like to read into a new window, then
minimize it and set it aside (I'm on a macG4 by the way). Once I've gathered
the articles that interest me from a meta resource I close it and proceed
with the next until I've exhausted all of them. Then I go about reading the
pages i've opened into separate windows.
In terms of implementing a UI tool to assist with this type of browsing
style, something less permanent than a bookmarks file would be nice --
something like a URL cue that a user could add to throughout their browsing
and easily access to open stored pages into the browser window. I really
wouldn't need to open any additional windows if this feature were present.
Hey, anyone from mozilla.org on this newsgroup? ;)
Rick Dietz
-------
Rick Dietz wrote:
> I follow this browsing patterns as well. Periodically during the day i go on
> what amounts to foraging missions on sites I frequent. A number of these are
> meta resources for technology news like Slashdot or Yahoo!'s news. I will
> scan the headlines opening the ones i'd like to read into a new window, then
> minimize it and set it aside (I'm on a macG4 by the way). Once I've gathered
> the articles that interest me from a meta resource I close it and proceed
> with the next until I've exhausted all of them. Then I go about reading the
> pages i've opened into separate windows.
I do exactly this too. It is especially helpful with slow connections
since using the 'back' button can involve reloading the page (damn
Netscape even reloads the page if a window is resized! grrr!)
Something CyberDog (Apple's now-defunct OpenDoc-based browser) allowed,
was option-clicking a link which opened a new window with the link, and
most importantly, **did NOT bring that window to the front**!
This way, if I am reading something which contains a link to something
that looks interesting that I may want to read later, i just option click
to create a new window and can continue my reading uninterrupted. By the
time I finish reading the orignal doc, my stupid 33.6 will have finished
loading the newer page, which I can then switch to.
Sean McBride
------
> >I follow this browsing patterns as well.
I do this as well. It is mostly because I am looking for a lot of
information, and it takes time for the pages to load (even with nice
fast T1 connections). I guess it is a sense of immediacy that makes
me intolerant of sitting and waiting for the page to load. Instead I
open the next one, and so forth. That way, as I am reading the first,
which has finnally loaded, the others can load, and I have wait free
browsing.
I am not sure a UI change would prevent this, except maybe much facter
loading.
Chris Eisbach
-------
> My question: how do you surf? Is this actually a documentable trend and,
> if so, how could the browser UI be redesigned to accomodate this?
I surf using multiple windows as well. In Internet Explorer, and I think
Netscape, I usually shift-click on a link to open it in a new window. But my
default browser now is NetCaptor, which uses IE's rendering engine. It uses
a multiple-document interface, using tabs to switch between web pages. I
think it's great. You can check it out at http://www.netcaptor.com
Mark Cidade
------
> I surf using multiple windows as well. In Internet Explorer, and I think
> Netscape, I usually shift-click on a link to open it in a new window.
Thanks for this tip. I have searched IE5's help system for this feature and
it just isn't in there! What's the use of a help system if only the obvious
functionalities are described (or the things that *should* be obvious ;-)
and not the nice hidden power functionalities?
Sim D'Hertefelt
------
Wallace Chigona wrote:
> Mark Cidade wrote:
>
> > I surf using multiple windows as well. In Internet Explorer, and I think
> > Netscape, I usually shift-click on a link to open it in a new window.
>
> In Internet Explorer yes but not in in netscape. In Netscape there
> seems to be no short cut for doing it other than going through the menu.
>
with a three button mouse, clicking with the middle button (at least in
UNIX works). shift-clik (using the left button), open the "save as"
dialog box
Jordi Regincos Isern
-------
On the Mac OS, (Apple-Click) opens a hyperlink destination into a new window
on both Netscape and MS Explorer.
Rick Dietz
------
Seems on my NT box here at work, ALT-CLICK opens a new window, SHIFT-CLICK
opens the Save As.
Jay Goldman
------
Jaana Järve wrote:
> Wallace Chigona wrote:
> > Mark Cidade wrote:
> > > I surf using multiple windows as well. In Internet Explorer, and I think
> > > Netscape, I usually shift-click on a link to open it in a new window.
> >
> > In Internet Explorer yes but not in in netscape. In Netscape there
> > seems to be no short cut for doing it other than going through the menu.
>
> What are you talking about? Right-click, Open in New Window. Your mouse
> does have a right button, doesn't it?
At least in UNIX, the middle button also does this.
$0.02 - I find myself using "new window" when I want to take a
temporary fork in my browsing activities, e.g. visit a sideshow page
and be able to easily close the window and go back to where I was. In
other words, I use it as a very temporary bookmark.
Elliot Lee
------
Jay Goldman wrote:
> It's occured to me over the last few months that I've developed a very
> defined surfing style. I almost always open new links into new windows,
> especially if they link to a page on a different site.
I sometimes surf in this way. There's a bit of analysis I perform first:
1 Is the link a 'mainstream' link or a sidetrack link?
When I'm surfing I'm usually following streams of information. I'm either
looking for specific information, or following interesting trails of links.
If the link is on the path I'm following then it's a mainstream link - I am
likely to follow it and then proceed forward, probably not returning to this
point. For example, I've used a search engine to find info on a company and
see a link to their home page.
With sidetrack links I'm much more likely to return to my current location.
For example, I use a search engine to find information on a company and find
a single press release article on a news site.
With mainstream links I tend to open in the same window, with sidetrack
links I tend to open in new windows, view the information then close them.
2 How important is the page I'm viewing?
If I've started at a bookmarked or known location (say, cnet.com) then
losing this page is not important to me - I can easily return any time I
want. Similarly, if I've been browsing aimlessly and I'm in the midst of
pages I don't care about, what does it matter if I can't find my way back?
In this case I'm much more likely to open the link in the current window, as
it requires less effort.
Conversely, if the current page has value, was hard to find (say a
customised search in a search engine, several pages into the results) or an
unbookmarked page containing valuable and interesting information, then I'm
much more likely to open any links in new windows, for fear of losing what
I've already struggled to find.
3 How likely is the new page to 'trap' me?
I think that this one has a lot to do with my browsing behaviour. Some
links/sites make it difficult to re-trace your steps, through a number of
mechanisms:
- Redirecting you to another page, so that the browsers 'back' button simply
loops you onto the same page
- Providing page after page of junk, links, intros and weird sections, where
you quickly become lost
- Bad code, scripts or ASP/JSP that crashes the browser or confuses it so it
won't let you go back
The looping page problem in particular makes backing up frustrating - and if
the user doesn't know how to display the list of previous pages, then they
can be completely trapped.
For me, at least, it comes down to the value of the page/data I already
have, against the perceived risk of losing it. As soon as either or both of
these two factors outweigh the minimal extra effort involved in opening a
link in a secondary window, I take that approach.
Although I have no usability data on this issue, I can easily believe that
Faisal's findings are correct in that power users use secondary windows more
often. I believe that over time new users lose pages/data, get caught in the
eddies of looping pages, and eventually learn the safety mechanism of
opening a link in a new window.
Gary Bunker
-------
Adding my voice to the crowd:
I use the above technique a lot too. I usually have 2-3 windows open
at all times. My default browser is IE 4.5 on the Mac. Here are some
things that would aid in using web-browsers easier:
1. Have an option for Browser windows. A check box for "browse in
place" (turned on by default). Option clicking on a link should spawn
a new window. Reverse the notation if the "browse in place" option is
turned off. Cyberdog, that ill-fated browser had a browse in place
option off by default if I remember....
2. In addition, allow drag-n-drop of links from one window to the
other. This becomes useful in loading links in the background
3. The Page-holder feature in IE4.5 (Mac) is a godsend for browsing
meta-info pages and pages with a lot of links.
4. Also another "no-brainer" that in HI should be the positioning of
the Back and forward arrows. I believe that these widgets should be
placed to the right of the screen rather than the traditional
left-hand side. This will be better suited for Western readers since
the scroll bars are usually placed on the right too....
Sandeep
-------
I've noticed myself doing this some lately, but I think it's been brought on
in large part by sites the set immediate (or very short) expiration times so
the "back" button reloads the page (with accompanying wait). Using a
separate window allows me to walk the branches of a tree while holding on to
the root.
Sarr Blumson
-------
Jay Goldman wrote:
>It's occured to me over the last few months that I've developed a very
>defined surfing style. I almost always open new links into new windows,
>especially if they link to a page on a different site.
Augh!
I hate this way of surfing. I don't mind having the ability to
choose to open a new window (or not to, in my case!) but it absolutely
drives me nuts when I click on a link and a new window opens up.
Did I ask for the new window? No. If I wanted a new window I would have
asked for it, with a click with a different finger, but now I have an extra
window on my screen. A few more of these and I will have my screen completely
cluttered with all sorts of windows, and I can't find what I was browsing a
few moments ago because it's in window 9 of 10, and the icons have all
splatted themselves on top of each all over the screen and I can't find the
one I'm looking for.
Plus this is usually done by commerical web sites when they have a link
out of their site, so I also get annoyed by the impression that they give me,
that although they'll let me see this other site, their site is so
important that it must stay on the screen so I can still see it!
Please don't tell me I'm the only person who thinks like this....!
Sharon Curtis
------
> Please don't tell me I'm the only person who thinks like this....!
You're not.
I like to be able to open new windows (saves time when you're browsing
over a modem or on a slow machine; don't have to reload pages). But I
want full control over this. Often the webmaster does not have _my_
interests at heart when deciding to pop up a window.
My ideal browser would have toolbar buttons for allow/disallow images
and allow/disallow popups (but if I asked for a new window, I'd get
one).
Scott Oglesby
-------
Eugene R. Somdahl wrote:
> Scott Oglesby wrote:
> > I like to be able to open new windows (saves time when you're browsing
> > over a modem or on a slow machine; don't have to reload pages). But I
> > want full control over this.
>
> In "mega" pages that have list of links I find myself going to a link, then
> "back" to the parent, and then selecting the next list link. What I want is
> a "next" button that selects the next link in the parent page but opens it
> in the current page. Alternately, in the parent page's window open all the
> links in the same child window but different than the parent window.
>
I use the online bookmark service Blink (as I access the web from many
different locations). It has a feature similar to this, it installs a
couple of bookmarks on the favourites toolbar in Netscape, one of
which is a 'Next Blink' link. That takes you to the next bookmark in
your list. Useful if you place your news sites in a row, you can
quickly trawl each of them with a single click.
I think adding a generic feature like this to other sites could be
useful, though a little difficult to implement and track. Feedback is
an issue too - with the Blink service you have no feedback as to where
you are in the list, or where the next click will take you...
Gary Bunker
------
> My ideal browser would have toolbar buttons for allow/disallow images
> and allow/disallow popups (but if I asked for a new window, I'd get
> one).
NetCaptor has a load images toggle button on its browser, and it also has a
feature that lets you add a URL to a list where any page on that list is
automatically closed if it's opened using JavaScript, beore you have a
chance to notice it.
Mark Cidade
------
> My question: how do you surf? Is this actually a documentable trend and,
> if so, how could the browser UI be redesigned to accomodate this?
Intresting question.
I did internet tech support for a while, and I noticed that one of the
most obvious differences between novice and experienced surfers is
that the experienced people brows a lot in new windows.
nothing more then my personal observation though.
Personally, I like opening links in new windows, but hate when a web
site does it for me without warning....
Xslf
------
Jay Goldman wrote:
> I keep running across comments from people all over the
> world who casually mention this habit.
I have some limited poll-results on this, asking how many people
regularly use each of these 'power surfing' tricks (unfortunately the
polling site doesn't count how many people voted altogether!):
119 Trimming off segments of URLs to explore a site
118 Copy selected text
114 Find word on page
113 Viewing source
112 Opening links in a new window <<<<<<<<<<<<<<<<<<<<<<<
96 Opening a subframe in a new window
88 Copying link-URLs directly to the clipboard
88 Saving pages to your local disk
71 Personal 'toolbar' of fave bookmarks
58 Custom startup page on Web
53 Dragging bookmarks to copy them
39 Dragging images to copy them
37 Custom startup page on local drive
21 Auto-check for updated pages
Poll:
I have a page on multiwindow surfing:
Javascript 'bookmarklets' let you create lists of URLs to open in a
batch, and Steve 'Mr Bookmarklets' Kangas is also a multiwindow surfing
advocate:
Jorn Barger
------
>I have some limited poll-results on this, asking how many people
>regularly use each of these 'power surfing' tricks (unfortunately the
>polling site doesn't count how many people voted altogether!):
At the bottom of the poll results table I see "1127 total votes".
That suggests that about 10% of the poll submitters open links in new
windows.
>Poll:
It would be interested to know where the poll was advertised. i.e.
Web related news groups, misterpol.com, etc. I would expect such a
poll to attract people who use the WWW frequently, but it seems odd
that such a small proportion of the respondants use these techniques.
Calum I Mac Leod
-------
Calum I Mac Leod
> Jorn Barger wrote:
> > Calum I Mac Leod wrote:
> > > At the bottom of the poll results table I see "1127 total votes".
> >
> >That's just a (useless) sum.
>
> Thanks. Yes, it does seem pretty useless there. It makes more sense
> on other polls by 'Mister Poll'.
>
> Although such a sample is likely to be limited by self-selection, a
> little context might be helpful. I'd be interested to know where the
> poll was announced.
I forget. Mostly on my weblog, maybe also on some newsgroups, maybe Mr
Poll featured it on their index page.
My weblog readers are mostly power users, so the stats are more about
relative ratios than absolute percentages.
Jorn Barger
-----
I open new windows all the time. Just now I stumbled upon one drawback
of this method.
When I search a site and get a list of links that look very similar,
when opening a new window from on of the links, it doesn't change its'
color because the page isn't reloaded (re-rendered). Then I go back to
the results page and don't remember what link I have clicked.
I hope that future browsers will be able to change the color of visited
links without re-rendering the page.
Hanan Cohen
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The Blonde and the Lawyer
A blonde and a lawyer are seated next to each other on a flight from LA
to NY. The lawyer asks if she would like to play a fun game?
The blonde, tired, just wants to take a nap, politely declines and rolls
over to the window to catch a few winks. The lawyer persists and
explains that the game is easy and a lot of fun. He explains, "I ask you
a question, and if you don't know the answer, you pay me $5.00, and vice
versa."
Again, she declines and tries to get some sleep. The lawyer, now
agitated, says, "Okay, if you don't know the answer you pay me $5.00,
and if I don't know the answer, I will pay you $500.00."
This catches the blonde's attention and, figuring there will be no end
to this torment unless she plays, agrees to the game.
The lawyer asks the first question. "What's the distance from the earth
to the moon?"
The blonde doesn't say a word, reaches into her purse, pulls out a $5.00
bill and hands it to the lawyer.
Okay says the lawyer, your turn. She asks the lawyer, "What goes up a
hill with three legs and comes down
with four legs?"
The lawyer, puzzled, takes out his laptop computer and searches all his
references, no answer.
He taps into the air phone with his modem and searches the net and the
library of congress, no answer.
Frustrated, he sends e-mail to all his friends and coworkers, to no
avail.
After an hour, he wakes the blonde, and hands her $500.00.The blonde
says, "Thank you," and turns back to
get some more sleep.
The lawyer, who is more than a little miffed, wakes the blonde and asks
"Well, what's the answer?"
Without a word, the blonde reaches into her purse, hands the lawyer
$5.00, and goes back to sleep.
And you thought blondes were dumb.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
On Wed, 19 Jan 2000, .. turned usenet on its head with:
> The HTTP-EQUIV meta sequence is supposed to be the EQUIVelant
> of an HTTP header, with http being the method of delivery for almost
> anything you actually view on the web.
Well, yes, that seems to be a restatement of the question.
> HTTP is (Hyper Text Transport Protocol)
>
> As to the RFC's in question , read them and understand what you can.
>
> http://www.cis.ohio-state.edu/htbin/rfc/rfc1945.html
> http://www.cis.ohio-state.edu/htbin/rfc/rfc2068.html
OK, but RFC2068 has been obsoleted by RFC2616.
I guess the questioner needs to know that RFCs are the Internet's way of
propagating Internet-related specifications of various kinds. HTTP/1.1
is covered by a "Standards Track" RFC, 2616. The Ohio-state site is a
useful place for web access to copies of RFCs.
The original intention of META HTTP-EQUIVs was that web _servers_ would
parse them and use them for generating real headers in the HTTP protocol
transaction. In practice, this hasn't happened to any extent. There
are some good reasons (as well as probably some bad ones) why that
hasn't happened, but this is probably not the place to go into detail
about them.
De facto, quite a proportion of clients will interpret these headers and
somehow merge them into the HTTP protocol headers that it has received
from the server. However, this is risky, because any proxies involved
in the activity will generally not parse the document - and therefore
will miss the fact that there were pseudo HTTP headers stashed inside
the document instead of having been sent as real HTTP headers as the
protocol originally envisaged. This is, for example, one of the chief
reasons why the various cargo-cult recipes for inhibiting cacheing don't
properly work in a WWW context, especially when web proxies are
involved.
The Netscape-defined "Refresh" is anomalous as an HTTP-EQUIV, as it
claims to be HTTP-EQUIV to a header that does not, in fact, exist in the
HTTP procol definition. Indeed, if you try to use Refresh as a real
HTTP protocol header it causes various strange effects with actual
browsers, as they don't seem to have thought-through their handling of
this as a real protocol header. They only work as the vendor intended
when the HTTP-EQUIV form is used. This kind of oddity is quite usual in
vendor-defined extensions, as they are promulgatged without the kind of
extensive peer-review process that gave us, for example, the series of
three RFCs listed above.
It's a pity that I don't know a good beginner's tutorial to HTTP
protocol, nor can I find one at W3C nor the usual places. A Google
search produced a reference to http://www.jmarshall.com/easy/http/ which
looks quite reasonable to me, although it folds-in to the tutorial some
aspects of implementing it yourself (sockets programming) that might not
be essential at a first reading.
best I can do, sorry.
There doesn't seem to be a usenet group that has discussion of HTTP
protocol on its explicit agenda. This group (HTML) is surely
inapprorpriate. Aspects of HTTP get discussed on the servers groups and
on the CGI group as necessary, but I'm going to suggest steering this
towards the WWW misc group as the best general match for the topic.
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Once upon a time, in a kingdom not far T~~
from here, a king summoned two of his |
advisors for a test. He showed them /"\
both a shiny metal box with two slots T~~ |'| T~~
in the top, a control knob, and a lever. T~~ | T~ WWWW|
"What do you think this is?" | /"\ | | |/\T~~
/"\ WWW /"\ |' |WW|
One advisor, an engineer, answered WWWWW/\| / \|'/\|/"\
first. "It is a toaster," he said. | /__\/]WWW[\/__\WWWW
|" WWWW'|I_I|'WWWW' |
The king asked, "How would you design | |' |/ - \|' |' |
an embedded computer for it?" |' | |LI=H=LI|' | |
| |' | |[_]| | |' |
The engineer replied, "Using a four- jgs | | |_|###|_| | |
bit microcontroller, I would write a '---'--'-/___\-'--'---'
simple program that reads the darkness
knob and quantizes its position to one of 16 shades of darkness, from
snow white to coal black. The program would use that darkness level
as the index to a 16-element table of initial timer values. Then it
would turn on the heating elements and start the timer with the
initial value selected from the table. At the end of the time delay,
it would turn off the heat and pop up the toast. Come back next
week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the
danger of such short-sighted thinking. He said, "Toasters don't just
turn bread into toast, they are also used to warm frozen waffles.
What you see before you is really a breakfast food cooker. As the
subjects of your kingdom become more sophisticated, they will demand
more capabilities. They will need a breakfast food cooker that can
also cook sausage, fry bacon, and make scrambled eggs. A toaster that
only makes toast will soon be obsolete. If we don't look to the
future, we will have to completely redesign the toaster in just a few
years."
"With this in mind, we can formulate a more intelligent solution to
the problem. First, create a class of breakfast foods. Specialize
this class into subclasses: grains, pork, and poultry. The special-
ization process should be repeated with grains divided into toast,
muffins, pancakes, and waffles; pork divided into sausage, links, and
bacon; and poultry divided into scrambled eggs, hard-boiled eggs,
poached eggs, fried eggs, and various omelet classes."
"The ham and cheese omelet class is worth special attention because it
must inherit characteristics from the pork, dairy, and poultry
classes. Thus, we see that the problem cannot be properly solved
without multiple inheritance. At run time, the program must create
the proper object and send a message to the object that says, 'Cook
yourself.' The semantics of this message depend, of course, on the
kind of object, so they have a different meaning to a piece of toast
than to scrambled eggs."
"Reviewing the process so far, we see that the analysis phase has
revealed that the primary requirement is to cook any kind of breakfast
food. In the design phase, we have discovered some derived require-
ments. Specifically, we need an object-oriented language with mul-
tiple inheritance. Of course, users don't want the eggs to get cold
while the bacon is frying, so concurrent processing is required, too."
"We must not forget the user interface. The lever that lowers the
food lacks versatility, and the darkness knob is confusing. Users
won't buy the product unless it has a user-friendly, graphical inter-
face. When the breakfast cooker is plugged in, users should see a
cowboy boot on the screen. Users click on it, and the message
'Booting Breakfast Food Cooker". Users can pull down a menu and
click on the foods they want to cook."
"Having made the wise decision of specifying the software first in the
design phase, all that remains is to pick an adequate hardware plat-
form for the implementation phase. An Intel Pentium II with 64 MB of
memory, a 8.4 Gig hard disk, and a 19" SVGA monitor should be suffi-
cient. If you select a multitasking, object oriented language that
supports multiple inheritance and has a built-in GUI, writing the
program will be a snap. (Imagine the difficulty we would have had if
we had foolishly allowed a hardware-first design strategy to lock us
into a four-bit microcontroller!)."
_.+._
(^\/^\/^)
\@*@*@/
The king had the computer {_____}
scientist thrown in the moat, ///"""\\\
and they all lived happily (/6 6\)
ever after. ||=^=||
\\\\///
\\///
jgs `)/
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
HTML - Have Two Meaty Lunchmeats
SGML - Suck God Maybe Later
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Michael Hamm writes:
> Alan J. Flavell wrote, in part:
> > I'm still puzzling how to educate my users about CA-2000-02
>
> Huh?
Simon Brooke
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Subject: Re: disable back button
Obakesan wrote:
> hey I thought that it was a dumb idea too. but the client wants this
> feature on the intranet stuff ... beats me!
This sort of thing is almost always a case of what I label "premature
closure," Diane Wilson labels as "solutions as requirements" and many
people call the "XY problem"; someone has a requirement X, guesses that
implementation Y is the way to achieve it, and asks how to do Y rather
than asking how to do X. What you need to do is find out what your
client's X requirement is and figure out a way to accomplish it, a
different way from the Y they communicated to you.
For example, a fairly common X for this particular Y is "we need to keep
our database from getting screwed up if somebody goes back and resubmits a
partially completed form." A reasonable solution is to generate the form
from a script that assigns a unique serial number to each form, and then
have the script that processes the form detect if the same serial number
has been submitted twice. But that's a solution that simply can't be
designed until you know what the *real* requirement was.
Of course, it may turn out that the real requirement is something
inherently impossible to achieve, like "we want to trap users on our site
to make it difficult for them to go back to the search engine listing and
comparison-shop with our competitors." In that case you're going to have
to do a *lot* of persuasion with your client! But most cases aren't that
bad, you just have to get them to think about their requirements as such.
Eric Bohlman
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
[Somebody asked for good links for web design]
www.w3c.org
www.useit.com
http://www.goodpractices.com/
http://www.w3.org/WAI/
http://www.webstandards.org/
http://validator.w3.org/
http://www.hut.fi/u/jkorpela/www.html
http://www.cast.org/bobby/
http://www.htmlhelp.com/
???
http://www.webreview.com/pub/1999/10/29/feature/index3a.html
(Browser Compatibility)
http://www.apache.org/docs/
(Specialized: how to deal with an Apache server)
Getting started with HTML
http://www.w3.org/MarkUp/Guide/
http://www.dantobias.com/webtips/
--------
http://www.hut.fi/u/jkorpela/www.html
Documents about WWW written or recommended by Jukka Korpela
Swear to God, if anyone posts in comp.infosystems.www.authoring.html
"I'm having trouble rendering kumquats under IE 2", he'll come back
with "There's a known bug with citrus fruit under IE <= 3; see my
article at ..."
Timothy A. McDaniel
------
Keith Bowes wrote:
>I think Project Cool's developer's zone,
>http://www.projectcool.com/developer/ , is the best newbie site on
>the Internet.
McDaniel's Laws:
1: The worst book of the trilogy is the fourth. (See _Dune_,
originally a stand-alone: _God-Emperor_ was therefore #4 of 3 and
#4 of 1, which explains the extra badness.)
2: If you don't know whether you can get away with breaking the rules,
you can't.
3: You need more bookcases.
and now
4: Anything self-described as "cool" isn't.
Obvious "insight", of course, but I just hadn't thought much about it.
An interesting and useful use of frames -- to allow a short definition
to fit at the top, like reserving an area for small pop-up windows --
but I dislike aspects of the content.
>Oh yeah, by the way, purism (ie, fuddy-duddiness) sucks- in both
>human and computer languages.
And you're the Spawn of Satan and a meanyhead to boot!
I'm plugging my ears and going "LA LA LA" really loudly.
Tim McDaniel
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
From: Michael Hamm
Subject: Why XHTML??
Date: Sat, 19 Feb 2000 22:38:03 -0500
Message-ID:
Newsgroups: comp.text.sgml,comp.text.xml,alt.html,comp.infosystems.www.authoring.html
I read "XML in 10 Points" and still fail to see the
point of using XHTML. XHTML, as I understand it, claims to add to HTML the
ability to add new elements at will. That's the only difference I see in
the claims about XHTML. And I don't see that that's a difference with a
distinction. After all, you can always modify a DTD to add elements, even
before the invention of XHTML. The problem has not been adding elemeents
but getting browsers to show them as you wish -- and no browser will show
an XHTML element it doesn't know any better than it will shwow an HTML
element it doesn't know.
Am I missing something important here?
(Maybe I should read the XHTML spec, to see *precisely* how it differs
[besides in the use of forward-slashes and quotation marks] and not ask
such questions until I do. But I haven't the patience to read a long spec
I see no use for.)
-----------
I do see a use for XHTML, it's just too early to introduce it. The spec
itself admits problems with XHTML(eg, you can't create your own tags and mix
namespaces legally in version 1.0). I think they should have spent more
time working out the details so that the spec could live up to the promises,
but they didn't and it doesn't.
I think we should wait until XHTML is a marked improvement over HTML before
we spend the time and money to convert.
In other words, XHTML 1.0 is worthless, in my opinion.
Keith Bowes
------------
> In other words, XHTML 1.0 is worthless, in my opinion.
No, it just wasn't designed to address your problems. It was designed
to address the problems of people developing primarily XML based
systems, and that it does very well. It isn't worthless to me: to me,
it's vital. If you don't want to use it you don't have to, no-one is
forcing it down your throat.
Simon Brooke
------------
> In other words, XHTML 1.0 is worthless, in my opinion.
I might be able to agree that converting pages is worthless at the present
time. But surely now is the time to break the all-cap tags habits, and
sloppiness with omitted commands.
I personally have started attempting to follow the xhtml standards,
especially the dreaded quotes around attributes.
I once thought that
was a unnecessary tag. Then I spent a week trying
to make a split image in a table line up. Sometimes it pays to follow the
rules.
Don McCahill
-------------
Don McCahill wrote:
>
> I might be able to agree that converting pages is worthless at the present
> time. But surely now is the time to break the all-cap tags habits, and
> sloppiness with omitted commands.
While I agree that using XHTML can clean up some sloppiness, I am
dissapointed that tags must be all lower-case. First, XML is
case-sensitive, but not limited, XHTML could have been written to
allow both. HTML is not case-sensitive, and the migration will be
a pain for many of us...
Since we do a number of things with HTML that include mixing
some HTML with perl code, Java code, and now a number of JSP related
things, it has always been *very* helpful to have all of our tags in
upper-case. It makes them stand out, makes reading the code easier,
and results in fewer errors. Now if we want to standardize on XHTML,
we have to convert to all lower-case... a pain in the butt.
-Dave
--------------
> While I agree that using XHTML can clean up some sloppiness, I am
> dissapointed that tags must be all lower-case. First, XML is
> case-sensitive, but not limited, XHTML could have been written to
> allow both. HTML is not case-sensitive, and the migration will be
> a pain for many of us...
This seemed almost pulled out of the blue. All the previous
recommendations include examples of tags all in upper-case. I had coded
everything to that stylistic attribute.
> Since we do a number of things with HTML that include mixing
> some HTML with perl code, Java code, and now a number of JSP related
> things, it has always been *very* helpful to have all of our tags in
> upper-case. It makes them stand out, makes reading the code easier,
> and results in fewer errors. Now if we want to standardize on XHTML,
> we have to convert to all lower-case... a pain in the butt.
I agree. This is my main reason for initially adopting the "uppercase"
standard. I code mostly in lowercase or lowerCase and tags were in
.
This is only a minor aesthetic thing, however.
Dave Dash
--------------
>... Now if we want to standardize on XHTML,
>we have to convert to all lower-case... a pain in the butt.
No you don't Dave...just be consistent (XML is case-sensitive, but not
case-restrictive).
Mark A Preston
--------------
My viewpoint:
0. Coding in XHTML is no harder than coding in HTML: converting a site from
HTML to XHTML can be a non-trivial task for a large site, but making a new
site with XHTML is no burden.
1. XHTML is stricter than HTML, e.g., requires closing tags. Coding in XHTML
therefore helps to make pages whose behaviour in different browsers is more
predictable.
2. XHTML is a 'bridge' to the further evolution of HTML and to the use of
XML. As I read it, there will be no more versions of HTML: XHTML is HTML's
successor. So making a site in XHTML makes it easier in the future to add
the newer features that will inevitably arrive. Making a site in HTML will
impair future growth of the site, since conversion from HTML to XHTML is (as
of today) a problem.
C. A. Upsdell
---------------
I concur with Mr. Upsdell - and a starter tool is at www.chami.com and
called HTML Kit (which has a great XHTML/XML plug-in called HTML-Tidy)
BMRW
---------------
> 0. Coding in XHTML is no harder than coding in HTML: converting a site from
> HTML to XHTML can be a non-trivial task for a large site, but making a new
> site with XHTML is no burden.
Actually, it's automatable - get Dave Raggett's Tidy from
> 1. XHTML is stricter than HTML, e.g., requires closing tags. Coding in XHTML
> therefore helps to make pages whose behaviour in different browsers is more
> predictable.
XHTML is no stricter than HTML, it's exactly the same but with
slightly different syntax. However, XML clients will not be forgiving
to incompetent, mangled markup. If the markup you generate now is poor
quality, now is the time to be learning better discipline - but then
you should have been producing good quality markup all along.
> 2. XHTML is a 'bridge' to the further evolution of HTML and to the use of
> XML. As I read it, there will be no more versions of HTML: XHTML is HTML's
> successor. So making a site in XHTML makes it easier in the future to add
> the newer features that will inevitably arrive. Making a site in HTML will
> impair future growth of the site, since conversion from HTML to XHTML is (as
> of today) a problem.
Actually, if all you are doing is static markup of static documents, I
don't agree. HTML will be around for a considerable period, and XHTML
does not in itself offer any significant benefits for static
markup. If you want to use SMIL (synchronised multimedia), SVG
(scalable vector graphics), or MathML (mathematical markup) then you
need to be moving in an XML direction anyway, in which case XHTML may
be a natural part of that process; but for people doing only simple
static markup of text documents illustrated with pictures, HTML does
the job and will continue so to do.
Simon Brooke
----------------
> Actually, it's automatable - get Dave Raggett's Tidy from
>
Not quite. First, Tidy makes mistakes, e.g., fails to convert certain
attribute values to lowercase, and mucks up some lines with nested quotes.
Second, Tidy totally destroys the indentation of the source. Third, Tidy
does not convert relevant items in CSS to lowercase. I have converted about
half a dozen sites to XHTML, mainly as an exercise so that I can scope the
difficulty: for smaller sites, it is fairly easy; for larger sites, it is a
lot of work.
> XHTML is no stricter than HTML, it's exactly the same but with
> slightly different syntax.
XHTML is stricter. Lots of closing tags in HTML are required: body, head,
html, li, p, td, et. cetera. They are all required in XHTML.
> HTML does the job and will continue so to do.
My point is that shifting to XHTML makes adoption of new technologies
easier. Who knows what a new site will need two years from now? Better to
make it flexible now while it costs nothing, than to do a more costly
conversion two years from now.
C. A. Upsdell
----------------
>XHTML is no stricter than HTML, it's exactly the same...
Are you sure?
From the HTML4.01 DTD...
From the XHTML1.0 DTD...
You do see the difference, as in that '- O' don't you?
In fact that's gone for all element defs in XHTML1.0 indicating that xml
syntax is required, i.e. closing tags are required, and are not any
longer left to parser inference.
XHTML1.0 is HTML4.0x "rewritten" in xml, that to me mandates closing
tags otherwise we will end up in trouble sometime in the future, if not
already now.
[...]
>...but for people doing only simple static markup of text
>documents illustrated with pictures, HTML does the job and
>will continue so to do.
I can fully agree with that of course.
Jan Roland Eriksson
----------------
> You do see the difference, as in that '- O' don't you? ...
Yes, certainly I'm aware of the difference. But this is (in my
opinion) a semantic argument. Although closing paragaph tags are not
required in HTML 4, nevertheless there is no valid reason (other than
laziness or sloppiness) for omitting them.
Simon Brooke
---------------
> Yes, certainly I'm aware of the difference. But this is (in my
> opinion) a semantic argument. Although closing paragaph tags are not
> required in HTML 4, nevertheless there is no valid reason (other
> than laziness or sloppiness) for omitting them.
Of course, there are "reasons" -- end tags are left out for "formatting"
purposes! Or, vice versa, some people insert empty
elements to
"finish" a paragraph and/or to produce whitespace (e.g., in front of an
block).
These "tricks" are numerous and they are known to break clean browser
implementations :-(
Unfortunately, even lynx isn't XHTML clean.
Karl EICHWALDER
-------------
>Yes, certainly I'm aware of the difference [ that in XHTML e.g. end tag
>for P is required ]. But this is (in my opinion) a semantic argument.
It looks syntax to me. And syntax is what DTD is about.
>Although closing paragaph tags are not
>required in HTML 4, nevertheless there is no valid reason (other than
>laziness or sloppiness) for omitting them.
Mostly so. But it still means that there are lots of HTML documents,
including valid HTML documents, which aren't valid XHTML documents.
And in this very sense XHTML is stricter than HTML.
I have sometimes _intentionally_ omitted tag before, say, a
, knowing that several browsers then leave no vertical
space between the paragraph and the quotation. I'm making use of a
browser bug then, in a sense, though only for a presentational purpose
comparable to using style sheets, but my markup is surely _valid_ HTML
still. I'm not advocating such usage; style sheets are much better;
but it's a _conceivable_ reason.
Jukka Korpela
-------------
> ... I'm not advocating such usage; style sheets are
> much better; but it's a _conceivable_ reason.
The difficulty, of course, is that "theoretically", the HTML trees
generated by both of these expressions should be the same. So it is a
browser "bug", yes. The more irritating problem, as someone who's had
to deal with it, is how it varies from browser to browser. I believe
both Netscape and IE handle the above the same way, but in situations
like this where they don't, it can be hell to figure out a
browser-neutral encoding.
Hopefully, xhtml will promote the removal of such "features", and make
the world more consistent.
John Prevost
--------------
Michael Hamm wrote:
> Am I missing something important here?
The most important point is that XHTML avoids ambiguity as much as
possible -- example: People will start to learn that the contents of a
paragraph live inside
...
and that "
" doest not end a
paragraph or create a new line.
And browser implementors will easily understand whether their parser
engine and/or their formatter modules are buggy or not ;-)
The time for tips and tricks will be over.
Karl EICHWALDER
--------------
> People will start to learn that the contents of a
> paragraph live inside
...
and that "
" doest not end a
> paragraph or create a new line.
XHTML is great, in this respect. I learnt everything I know about web
design off of the Internet. When I was learning HTML last year, the
tutorial claimed that
skips two lines. So, I tried to use multiple Ps
to skip multiple lines and I was very frustrated when it didn't work.
Now I know you can use CSS for this purpose, but my point is that those that
are still learning don't.
OTOH, I think XHTML is a bit too strict. But, I guess that's the way it
works- BASIC, a language anybody can learn, was succeeded by C, an
un-decipherable language. I guess that's what's going to happen to HTML as
well, be succeeded by the un-decipherable XML.
Keith Bowes
-------------
> I read "XML in 10 Points" http://www.w3.org/XML/1999/XML-in-10-points> and still fail to see the
> point of using XHTML.
read back a few days to a post I started, it will naswer some of that
(called something like "XML bad?").. but basiclaly it IS pointless. It's
just an intermediate step between HTML and XML... they're (W3C) getting us
used to it I guess :)
Ryan Stewart
-------------
Xhtml is more of a leaping point to Xml, read up on both and you'll understand
why both are important.
Kyle Tully
-------------
> Am I missing something important here?
XML -> XSL/XSLT -> XHTML
...since XSL itself must be a well-formed XML document.
Oliver Scheel
--------------
>XHTML, as I understand it, claims to add to HTML the
>ability to add new elements at will.
Just as XML is a strongly simplified version of SGML, XHTML is a
simplified, restricted version of HTML. Yes, you are supposed to think
"X" stands for "eXtended". You did read 1984, didn't you? War is
peace.
Well, the watering down also includes the idea that XML documents can
be written without referring to DTDs, i.e. without explicit formalized
syntax. Yes, you are supposed to think this is progress. Of course
it's nothing new; for years, browser vendors have blessed us with lots
of kewl tags without even specifying the exact syntax. But in addition
to browser-specific adhockery, we'll have author-specific adhockery.
It's so clumsy to write ... or
...
(for use with style sheets that define their
"meaning" in the "appearance is all" school of thought) that a big
noise has to made about the future possibility of writing just
....
>Am I missing something important here?
Just the opportunity to join the chorus of clueless praise.
But assuming that you don't expect anything, moving to XHTML
compatible syntax in your HTML markup is rather harmless. When you
write new documents, or edit existing documents, or write or modify
programs which generate HTML markup, why not play the XHTML game?
Among the alternatives of the traditional HTML syntax, XHTML isn't
much worse than any other.
The potential gain is rather small though. Browsers will of course
continue their (broken) support to traditional HTML. It would be very
foolish of them to stop recognizing , and it would require extra
effort. But some _other_ software, which is only XML capable, might in
the future be used to process XHTML documents but not HTML documents
which don't conform to XHTML. I have no idea whether this will mean
anything in reality, but it's of course an existing possibility.
Jukka Korpela
-----------------
If you code in XHTML you can use XML tools to parse and process your
code.
If you markup your XHTML with "class" attributes to add semantic
information, XML tools can be used to convert sensibly into other
XMLs.
Steve Slatcher
------------------
> Am I missing something important here?
Yes. Everything.
XHTML does *not* allow you to add new elements to HTML (although you
can create new XML dialects which are supersets of XHTML). If you just
add new elements you no longer have XHTML and consequently your
document will not validate; and in some circumstances if it doesn't
validate it won't parse at all and nothing at all will be rendered.
XHTML is just HTML 4.01 in XML syntax. This means that it can be
parsed with a standard, lightweight, XML parser, generated with a
standard XML generator, and, more importantly, can be a target for
standard XML to XML transformations.
In other words, XHTML is largely for people who generate content in a
primarily XML environment, but who wish to be able to deliver human
readable versions of some of that content to HTML browsers. It may
also be easier for new XML based editing tools to generate XHTML, but
if what you do it primarily markup static content, XHTML has (as you
suggest) few if any advantages for you.
> (Maybe I should read the XHTML spec, to see *precisely* how it differs
Perhaps you should at least read the subtitle of the specification
document, which states what I've explained above in just eight words:
'A Reformulation of HTML 4 in XML 1.0'.
Simon Brooke
------------------
I guess the main advantage would be that you could use default HTML
formatting for the "unimportant" things (nav bar, header graphics etc)
and still be able to include structured data in the document.
tzin mein
------------------
As noted by others, XHTML is just XML-ized HTML -- it doesn't let you do
anything really "new".
I think it's best to think of of XHTML as a 'bridge' between HTML and XML.
Today you can write pages using XHTML, happily send them to browsers as
HTML, but also integrate them into XML-based document managgement systems
or databases. In the future, you'll be able to integrate all the new XML
stuff (SMIL, MathML, etc.) right into these XHTML pages -- you won't have
to recode the markup, other than to insert the correct XML markup (and
namespace declarations, I suppose).
I find, also, that there are some smaller but real advantages to using XHTML,
even if just writing standard 'web' pages. Since XHTML places stricter
rules on markup (no missing end tags, special notation for empty elements,
such as for a br element, etc.), it actually makes it easier to write
accurate markup (it helps if you can verify the syntax of course -- HTML TIdy
is a good first pass at this) . This is particularly important when you use
CSS formatting rules -- which often act unpredictably when markup is incorrect.
I tend to think that the time I lose writing XHTML is gained in reduced
CSS/XHTML debugging ;-)
So, I would say that XHTML buys you 3 things:
* at worst, somewhat more accurate markup (by eliminating missing end
tags), and fewer CSS debugging problems.
* an easy upgrade path to XML-based based browsers, including support
for other 'embedded' xml data types, such as MathML, SMIL, etc.
* easier integration with XML-based document management systems that
store or import data as XML (actually becoming quite common)
So, it costs you a little (it's a bit harder to write accurate code), but
it gains you about what you lose (in reducing markup errors), and promises
to gain you a lot more in the future (when xml data types are far more
common). All in all, a reasonable trade-off.
Of course, I've a new book on XHTML/HTML/CSS due out in march, so I am a
bit biased ;-).
Ian Graham
--------------------
[ Ian Graham ] skrev:
>such as for a br element, etc.), it actually makes it easier to
>write
There are actually two correct ways to do empty elements. is just a
shorthand for
It is however not recommended to use the long notation for documents that
may be presented in broken UA's.
Arve Bersvendsen
---------------------
>There are actually two correct ways to do empty elements. is
>just a shorthand for
Um, according to
http://www.htmlhelp.com/reference/wilbur/special/br.html and
http://www.htmlhelp.com/reference/html40/special/br.html , and what I
can understand of the XHTML 1.0 DTD at
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd , is an empty
tag, and thus has no closing . Did I misunderstand something in
the specs, or is " " in the quotes above just referring to some
random generic tag (as one might write "" without there actually
being a FOO tag)?
Tim McDaniel
--------------------
> is an empty tag, and thus has no closing . Did I
> misunderstand something in the specs,
XML doesn't have empty tags.
Alan J. Flavell
--------------------
>> is an empty tag
>XML doesn't have empty tags.
I am unfamiliar with DTDs and with XML. In XML, if you have
stuff more stuff
what is the technical term for "stuff more stuff", any stuff between a
tag opening and tag closing?
In http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd , they have
Now in HTML 3.2, according to
http://www.htmlhelp.com/reference/glossary.html#empty
"Empty tag" is "A starting tag which does not have an ending tag.".
I take it, then, that the XML or DTD definition of "empty" differs --
that in the latter, "empty" means it can't have "stuff more stuff"?
Tim McDaniel
---------------------
>I am unfamiliar with DTDs and with XML. In XML, if you have
> stuff more stuff
>what is the technical term for "stuff more stuff", any stuff between a
>tag opening and tag closing?
This is all derived from SGML:
bar consists of 3 parts:
start tag
bar content (your "stuff more stuff")
end tag
the entire bar is an element, is the element-name
For better explainations of XML, XHTML and other technologies, I recommend
you read the technical recommendations on ,
which are a tad easier to read than the dtd's
Arve Bersvendsen
--------------------
In XML, the technical term for "stuff more stuff" is PCDATA (parsed
character data), that is, text that is not markup.
marc
-------------------
> >> is an empty tag
> >XML doesn't have empty tags.
>
>
Apologies for the loose terminology, but tags that don't take
any content still have to be terminated in XML.
Alan J. Flavell
---------------------
>Apologies for the loose terminology, but tags that don't take
>any content still have to be terminated in XML.
I was just reading through the XHTML spec on the streetcar (you've
gotta do something, right?) and here's the scoop for empty tags in
XHTML:
Include a space before the trailing / and > of empty elements. eg.
For Empty elements that customarily have content (such as
), do not
use the minimized form (that's the thing explained above, see).
Instead, use an opening and closing tag, eg. use
rather than
Willy-Yam
-------------------
> For Empty elements that customarily have content (such as
), do not
> use the minimized form (that's the thing explained above, see).
> Instead, use an opening and closing tag, eg. use
rather than
>
Sorry, this is completely meaningless. If a paragraph has no content,
it isn't a paragraph: you can't have an empty paragraph not for
syntactic reasons but for semantic ones.
Simon Brooke
--------------------
> Sorry, this is completely meaningless. If a paragraph has no content,
> it isn't a paragraph: you can't have an empty paragraph not for
> syntactic reasons but for semantic ones.
But of course, this is meant to be HTML, which is not really a
semantic markup language any more, but a visual markup language. As
such, empty paragraphs do have meaning (whitespace.)
Sad, but true. I believe this is part of the reason XML is important
(or SGML based things in general, though XML is much easier to
parse)--we can move the visual markup back out.
In my XSLT sheets which map to HTML, for example, I treat HTML as
purely display instructions. Ass-nasty backwards instructions, yes,
but the only thing most browsers deal with yet. When XSL formatting
objects are widely supported, we'll be able to do better.
But xhtml, as an XML means to express HTML, needs to have "empty
paragraphs".
John Prevost
-------------------
> But of course, this is meant to be HTML, ...
I don't agree at all, on two counts.
Firstly, I think XSL-FO is a *huge* retrograde step - all the semantic
content is left behind on the server, and all the client gets is
incomprehensible gobbledegook. It essentially undermines the point of
being able to gateway XML based systems to the Web.
Secondly, I think it's completely unnecessary because CSS already
provides all the styling information we need in a form that is
entirely compatible with passing semantically rich content to the
client. So I use XSLT to generate clean, structural XHTML markup and
then use CSS to apply visual aesthetics for those browsers which can
handle it.
Simon Brooke
------------------
> I don't agree at all, on two counts. ...
I disagree with you completely, as well. :) XSL-FO only results in
gobbledygook being sent to the browser if you assume the browser
cannot actually do the XSLT transformation locally! While current
XSLT based systems use server-side transformation, it is desirable
that this go away. (Especially when you consider that it would be
better to send the relatively small XSLT and source XML documents
rather than the large burdensome XSL-FO result.)
As for unnecessary--HTML may be fine for doing web pages, and it
becomes better with XHTML, because there is a more consistent idea of
what is and is not in each tag, so browsers can be more consistent.
However, adding CSS to HTML is in some ways much more complex than
producing and interpreting fo. (I'm not saying that fo isn't complex,
just that it is in some ways simpler. IN other ways... Well, you're
right. :) In any case, HTML, even with CSS, is *not* appropriate for
creating print documents, and it would be nice to have a consistent
system which works for both print and web documents, even if you use
different stylesheets in different contexts.
Clean, structural XHTML is a kind of ridiculous theory once you
realize that the true goal is that the XML itself is sent, and the XSL
only then used to interpret it. How can turning XML which has precise
semantic meanings into XHTML which has general classes of things and
stylesheets to make them look good be better than this?
John Prevost
--------------------
John Prevost schrieb/wrote:
> I disagree with you completely, as well. :) XSL-FO only results in
> gobbledygook being sent to the browser if you assume the browser
> cannot actually do the XSLT transformation locally! While current
> XSLT based systems use server-side transformation, it is desirable
> that this go away.
But that would not help. Yes, the browser would get the full XML DTD and
document, it would know how to display it (XSL). But it still would not
know what it _means_. This, however, is critical if you want to use the
data in other ways, e.g. in a speech browser or convert it to another
data format.
As a consequence, you would need an XSL stylesheet for every
combination of browsers, media, users and XML applications.
On the other hand, if you have a limited set of languages that are
everywhere, you only have to write style sheets or processors for
exactly this language. Further, new media or processing programmes can
easily be added -- the meaning of the elements is defined.
In other words: If you use (X)HTML, you can make use of hundreds of
prewritten style sheets and logic built into browsers and other
programmes. If you use your own (XML-based) language, you have to write
everything yourself.
> In any case, HTML, even with CSS, is *not* appropriate for
> creating print documents, and it would be nice to have a consistent
> system which works for both print and web documents, even if you use
> different stylesheets in different contexts.
This is simply not true. Just that current browsers do a bad job
printing HTML documents and many authors abuse HTML as a media-dependent
language which results in bad print, does not make HTML unappropriate
for printing.
> Clean, structural XHTML is a kind of ridiculous theory once you
> realize that the true goal is that the XML itself is sent,
XHTML _is_ XML. But XML which has not only a presentation (i.e. bunch of
stylesheets), but a _meaning_.
> and the XSL only then used to interpret it. How can turning XML which
> has precise semantic meanings into XHTML which has general classes of
> things and stylesheets to make them look good be better than this?
XML does not have "precise" semantic meanings. It has _no_ semantic
meanings. It just allows you to specify the _syntax_ of a language, not
the _meaning_ (semantics) of the syntactic elements.
Although the author of an XML application probably had some meaning in
mind when designing the language, this meanings are not exposed anywhere
in machine-usable form.
Claus André Färber
-----------------
(Claus Färber) writes:
> As a consequence, you would need an XSL stylesheet for every
> combination of browsers, media, users and XML applications.
I disagree with this. See below.
> On the other hand, if you have a limited set of languages that are
> everywhere, you only have to write style sheets or processors for
> exactly this language. Further, new media or processing programmes can
> easily be added -- the meaning of the elements is defined.
I somewhat agree with this.
> In other words: If you use (X)HTML, you can make use of hundreds of
> prewritten style sheets and logic built into browsers and other
> programmes. If you use your own (XML-based) language, you have to
> write everything yourself.
I disagree with this conditionally.
> XHTML _is_ XML. But XML which has not only a presentation
> (i.e. bunch of stylesheets), but a _meaning_.
> XML does not have "precise" semantic meanings. It has _no_ semantic
> meanings. It just allows you to specify the _syntax_ of a language,
> not the _meaning_ (semantics) of the syntactic elements.
>
> Although the author of an XML application probably had some meaning
> in mind when designing the language, this meanings are not exposed
> anywhere in machine-usable form.
I suppose I was imprecise in what I said. Individual document types
create the meaning. Without them, there is no meaning. XHTML is an
example of this--but not necessarily a good example. HTML has a
meaning, too, in the context of SGML documents. This meaning, of
course, has been abused.
If everybody and their dog produces their own XML document type, you
do indeed have the problem you describe. On the other hand, standard
document types (which have been around for a while in SGML and are
growing in XML) once created can be used and re-used. And these
markups can be more (or less, as the occasion demands) oriented
towards semantic markup.
XSL remains, however, the appropriate tool for document-producers to
provide visual markup to their semantic markup. The potential ability
to use modules in XHTML is indeed interesting, and I look forward to
see where it goes--but I continue to feel that a markup focused
entirely on display and formatting is appropriate to that area, and
individual markups appropriate to particular applications are
appropriate for semantics. To mix the two (for example with XHTML)
does allow you to do useful things--embedding appropriate semantics in
context--but, once such semantics are defined, it makes more sense to
use XSL to convert these when displayed.
Why? Because I find it very unlikely that every browser will
implement every semantic application. Is either Netscape or IE likely
to support the module for describing Feynman diagrams? What about
proof-trees for constructive logic? Interlinear transliterations and
translations of languages? Some of these, maybe. But not likely all.
One could propose a standard API for allowing programs to do this
work, so that you can plug it into the browsers. But what do you
think an XSLT stylesheet is? It's a program for converting from one
XML document to another, so all that is needed is a standard system
for display.
And then, the American Mathematical Society is free to use a different
format for mathematics than some other group uses.
And surely, producers of standard document types might provide
importable stylesheets for use with XSL:FO (or even, Gods help us,
more conventional parts of XHTML.)
This is what I'm getting at--the ability to both have a standard way
to describe layout, and a standard way to describe conversions to
layout (and, once generalized, to any XML document type.) This is
essentially what XSLT and XSL:FO are. People may disagree with the
way FO works, but I don't think it's reasonable to disagree with the
idea.
John Prevost
---------------------
>Clean, structural XHTML is a kind of ridiculous theory once you
>realize that the true goal is that the XML itself is sent, and the XSL
>only then used to interpret it.
What you all seem to be overlooking is the fact that XHTML 1.0 is not just
about righting the wrongs inflicted by the masses who were all too eager
to turn HTML into a scripting language for controlling the behavior of
Netscape Navigator (and then complaining when other browsers didn't react
to the same code in the same way); it is much more importantly about
paving the way for XHTML 1.1 and 2.0, which modularize HTML and establish
guidelines for capability negotiation, so that it can be used by many more
devices in many more ways. Attempting to do this without realizing the
benefits of XMLizing HTML 4.0 first would be the W3C shooting itself in
the foot.
Of course, one could argue that the W3C obviously didn't learn its lesson
the first time, when it tried to tell people they had to do things the
right way.
Mike Brown
-----------------------
> I disagree with you completely, as well. :) XSL-FO only results in
> gobbledygook being sent to the browser if you assume the browser
> cannot actually do the XSLT transformation locally! While current
> XSLT based systems use server-side transformation, it is desirable
> that this go away. (Especially when you consider that it would be
> better to send the relatively small XSLT and source XML documents
> rather than the large burdensome XSL-FO result.)
It may be desirable, but it isn't likely. I don't know whether you've
yet put much thought into XSLT processor design, but essentially
you're looking at a pattern-matching engine similar to a Prolog
interpreter, and these things are horribly compute-expensive. You
frankly aren't going to be able to do it in reasonable time on your
mobile phone or on your palmpad. With increasing use of very thin
clients FO forces you into a position where either you *just* serve
FO, or you serve two different versions of every document, one
pre-transformed for the clients which you aren't certain can handle
client-side transforms, and one not for those which you are certain
can.
> As for unnecessary--HTML may be fine for doing web pages, and it
> becomes better with XHTML, because there is a more consistent idea of
> what is and is not in each tag, so browsers can be more consistent.
> However, adding CSS to HTML is in some ways much more complex than
> producing and interpreting fo. (I'm not saying that fo isn't complex,
> just that it is in some ways simpler. IN other ways... Well, you're
> right. :)
Let us agree that it is similarly complex. But, and this is the
significant point, an HTML document designed to be decorated with CSS
is usable and readable without. Clients which can't handle CSS can
simply ignore it, and still have semantically rich markup. So, for
example, if the document that is sent is a hybrid between XHTML and an
XML dialect for arranging meetings, that markup is available to the
very thin XML+CSS browser, allowing it to interact directly with the
document to automatically create diary entries. If just FO were sent,
the meaning of the document is lost.
> In any case, HTML, even with CSS, is *not* appropriate for
> creating print documents, and it would be nice to have a consistent
> system which works for both print and web documents, even if you use
> different stylesheets in different contexts.
Tough. (X)HTML and CSS are only delivery mechanisms, and only delivery
mechanisms for Web media. When you set your documents for print media,
you simply choose an appropriate delivery mechanism. One size does not
fit all.
Simon Brooke
-------------------
> Let us agree that it is similarly complex. But, and this is the
> significant point, an HTML document designed to be decorated with
> CSS is usable and readable without. Clients which can't handle CSS
> can simply ignore it, and still have semantically rich markup. So,
> for example, if the document that is sent is a hybrid between XHTML
> and an XML dialect for arranging meetings, that markup is available
> to the very thin XML+CSS browser, allowing it to interact directly
> with the document to automatically create diary entries. If just FO
> were sent, the meaning of the document is lost.
The utility of XSL with very thin clients is a good point. I would
suggest that more specialized document types which the phone knows
from the get-go are appropriate here. Perhaps XHTML is a good choice.
Perhaps not. One thing to note is that a smart FO engine could
produce reasonable output in a different format by distilling the FO
resulting from a document.
Another point to consider is exactly what you intend to be viewing on
your phone. Graphics intensive webpages? Unlikely. (Possible,
though, with things coming down the pipe.) It's more likely little
snippets--perhaps email (in XHTML? In something else suitable for
email?). Here, XHTML is actually a pretty reasonable solution--you
could use it to embed standard style entities for business cards, or
the like.
> Tough. (X)HTML and CSS are only delivery mechanisms, and only
> delivery mechanisms for Web media. When you set your documents for
> print media, you simply choose an appropriate delivery
> mechanism. One size does not fit all.
Too true. :) I think part of my problem is that I am on the one hand
biased towards large documents (scholarly papers, documentation, the
like), and on the other, towards the desires of web publishers I work
with. I believe that these applications are better served by XSLT +
FO than with XSLT + XHTML + CSS. Small systems may be better served
by some other mechanism. Which one should be the default? I'm not
sure there's a good answer to this. Perhaps that's why we have both
XHTML and FO coming down from on-high. In any case, there are most
certainly places where FO *is* appropriate--even if I now admit your
assertion that XHTML is more than just crap and is going to be
replaced. :)
John Prevost
---------------------
> The utility of XSL with very thin clients is a good point. I would
> suggest that more specialized document types which the phone knows
> from the get-go are appropriate here. Perhaps XHTML is a good choice.
> Perhaps not. One thing to note is that a smart FO engine could
> produce reasonable output in a different format by distilling the FO
> resulting from a document.
>
> Another point to consider is exactly what you intend to be viewing on
> your phone. Graphics intensive webpages? Unlikely. (Possible,
> though, with things coming down the pipe.) It's more likely little
> snippets--perhaps email (in XHTML? In something else suitable for
> email?). Here, XHTML is actually a pretty reasonable solution--you
> could use it to embed standard style entities for business cards, or
> the like.
This is a philosophical issue: do you believe that there should be
'just one Web'? If so, you believe that any arbitrary document should
be not merely viewable but usable on any device. If not, then you
gradually erode to a post-babellian position of hundreds of mutually
unintelligible webs, where for any given device the probability that
the page with the needed information won't be available in the format
required for that device is high. This is, in effect, to return to the
situation which existed prior to the Web. In my opinion, the one
single significant breakthrough which Berners-Lee brought to
hyper-media was the doctrine of universality: as in the Highlander
films so with the Web, there *can* be just one.
Back when Netscape 2 emerged and it became clear that some commercial
interests were intent on trying to hegemonise the Web by
introducing non-standard proprietary features I put a lot of naive
effort into a system which I called MetaMark: the idea being to create
a mark-up language which was richer than any conceivable
really-going-to-be-delivered mark-up language, and then write a series
of filters which would dynamically, on the fly, recast the document
into the particular mark-up language for the particular
browser. Currently I'm looking at ways of delivering the same dynamic
content to the Web and to WAP. Consequently I understand a lot about
what the XSL process is trying to achieve and have very considerable
respect for James Clark and the XSLT team. And my view is that if you
are going to have to tailor your output for each different device,
dynamic content just isn't feasible: it's too computationally
expensive, and also it's just too difficult for system maintainers to
track just which user agents will handle just which features.
Consequently I believe that delivering different mark-up to different
user agents is a solution which just won't scale. For static
content which can be cached the scaling problem bites later, but it
still bites.
So: with the Web there can be just one, we can ensure that all content
is available to all clients, but only if we define a content delivery
language which allows for graceful degradation. XML does this; at it's
most basic, XML with no presentational gloss shows the marked up
content without it's mark-up. At one step up the scale, it shows a tree
view which allows both the tags and the content to be viewed in
context. A further step up, and some particular XML dialects (such,
for example, as appointments or payments dialects) can be interpreted
by the user agent to automate user tasks like maintaining a diary or
paying for purchases.
A further step up, and the user agent can request a stylesheet from
the server and apply that stylesheet to produce an aesthetic
presentation of the content -
**BUT**
If you send FO in the first place, all the preceding steps are
lost. The very lightweight client which doesn't have the processor or
display capabilities to handle the complexities of FO cannot display
anything useful. The pay-for-my-purchases and update-my-diary
functions are impossible. The document only becomes useful on a client
with a fair sized display and a fairly powerful processor, which could
probably have handled applying a stylesheet to the document anyway.
Thus if my only objection to FO was that it admits the possibility
of transmitting pre-formatted material from the server to the client,
that in my view would be a sufficient objection. But my objection goes
much further than that. FO is a classic example of what Brooks calls
'Second System Effect': it is gratuitously over-complicated, wantonly
baroque. It is just too big, too complicated, too ugly, and addresses
a problem which had already been solved by a much more elegant solution.
Cheers!
PS: Oh, I didn't address the issue of the life expectancy of
XHTML. Like you, I think it will be short; I believe we will move
moderately rapidly to generic XML+stylesheets clients. This being so,
I believe the important battlefield now is 'which stylesheets' - which
explains some of the force of the opinions I've expressed in this
thread.
Simon Brooke
-------------------
>> For Empty elements that customarily have content (such as
), do not
>> use the minimized form (that's the thing explained above, see).
>> Instead, use an opening and closing tag, eg. use
rather than
>>
>
>Sorry, this is completely meaningless. If a paragraph has no content,
>it isn't a paragraph: you can't have an empty paragraph not for
>syntactic reasons but for semantic ones.
Of course its completely meaningless. I took it from the W3C spec
document, which is semantically and syntactically correct (in English,
I don't read that other languages well enough to comment) but it is
nigh on unreadable. If you want to get up in arms about sematics,
stop looking at HTML, because it will make you unhappy. People use
the mark-up in completely unsanctioned ways. W3C recognizes this to
the extent that they put clarifications like the above in the
appendices of their spec so that the people who use it can adjust
their use. If you actually use HTML, you'd see that the clarification
is both meaningful and specifically useful to anyone hoping to use the
new spec with their old skill-set.
People are always using monkeywrenches to pound nails - calling the
use semantically meaningless is unhelpful. Suggest a hammer, or let
people do what they plainly want to do without your umbrage.
Willy-Yam
---------------------
> If you actually use HTML, you'd see that the clarification
> is both meaningful and specifically useful to anyone hoping to use the
> new spec with their old skill-set.
I've been using HTML, and, more specifically, writing software which
generates HTML, since 1994. In that time I've grown more and more
purist, and the reason is not that I'm a pathological anal retentive
who nitpicks specification documents for light relief. It means I've
learned what you clearly have not yet: that the Web is an open system,
and any hack which 'improves' appearance on one user agent almost
certainly breaks horribly on half a dozen others.
Simon Brooke
---------------------
Arve Bersvendsen wrote:
> [ Timothy A. McDaniel ] skrev:
> >Um, according to
> >http://www.htmlhelp.com/reference/wilbur/special/br.html and
> >http://www.htmlhelp.com/reference/html40/special/br.html , and what I
> >can understand of the XHTML 1.0 DTD at
> >http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd , is an empty
> >tag, and thus has no closing . Did I misunderstand something in
> >the specs, or is " " in the quotes above just referring to some
> >random generic tag (as one might write "" without there actually
> >being a FOO tag)?
>
> All elements in XHTML need to be closed, even empty elements, like
> and . Hence is _not_ legal xhtml, while or is.
> ( and are also equivalent)
This is formally true, but is in practice a bit dangerous: the form
leaves open the option of accidentally inserting "stuff"
between the tags -- which is of course an error. It is far better
form -- and safer -- to use the 'empty-element tag' form, as
in , etc., for elements that are known to be 'empty'.
Ian Graham
-----------------------
It allows HTML to be stored in XML content stores. A simple translator will
convert legacy HTML into XHTML which can then be directly inserted into the
new XML content store systems like Excelon and Tamino.
We use it to store HTML page templates in our content system.
Tim Hawkins
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Internet Exploder, Outlook Depress
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Sander Tekelenburg wrote:
> "Alan J. Flavell" wrote:
> >
> > [...] security hazards described in CA-2000-02
>
> What is "CA-2000-02"?
A CERT advisory, http://www.cert.org/advisories/CA-2000-02.html
explaining hazards from malicious script code, and recommending
steps to be taken both by server admins and by web surfers.
The latter are urged to disable client-side scripting (javascript)
whenever possible, etc.
Warren Steel
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Nervös text
http://www.jasonkester.com/dhtml/
:D:D:D
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Why and how to crosspost
http://www.hut.fi/~jkorpela/usenet/xpost.html
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>Also where can you get up to date statistics on browser use?
Who cares what browsers people were using last week or even this
morning. It's what their using next month or next year that matters.
Aim to create a site that works well in every possible browsing
situation.
Steve Pugh
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
(I *do* hope I'm not feeding a troll by this reply; the questions seem
a tad silly.)
Cooool Schooool wrote:
>How sinful is it if one's page doesn't validate 100%.
According to the Church of HTML Purity and the infallible decrees of
Pope Flavell:
It's a mortal sin if it doesn't work on Lynx. It's a venal sin if it
crashes Microsoft Internet Explorer or Netscape. Minor impurities can
send you to Purgatory Cache for 30,000 megabytes, but can be purged by
uploads to the Version Mary.
>Is there a scale of sins that one should not commit?
Venal, mortal, irredeemably damned, and Internet Explorer.
>What is the worst HTML goof one can make?
Blasphemy of the Holy POST.
>Does Yahoo etc Validate perfectly?
In the Network To Come, the designers of the Yahoo! pages are going to
be forced to create web pages via hand-awling paper tape, and reading
the results on a 30-baud printing terminal with an old ribbon and a
daisy wheel with a broken-off "t".
Of course there are no hard-and-fast rules on validation or standard
conformance. You have to weigh the different non-standardnesses you
have committed versus the application.
For one thing, if you know that it's an internal web page and what the
environment on each machine is, you might be able to get away with
more. But when they install a few new machines, or someone brings in
a laptop with Netscape instead of IE, or whatever, you're scrod. Even
in this case, I think it's better to keep an eye out for standard
conformance, lest you lead yourself down a blind alley.
I think the best approach is
- no gratuitous breakage
- weigh features versus conformance
By "gratuitous breakage", I mean things that aren't standard and
there's no reason at all they shouldn't be. For example, I just tried
to validate a page that started with
(generated by Netscape Composer, I gather. *Those* people will be
using paper tape made out of *toilet paper*. IE developers will be
given *used toilet paper*.) According to
http://www.w3.org/TR/REC-html40/struct/global.html#version-info
and hoping to conform with XHTML et seq, I believe
is a more-correct version. There's no reason not to use the right one.
"Weigh features versus conformance": for some non-standard feature F:
Which browsers support F? Which browsers are likely to support F in
the future? How important is F to what you're doing? If a browser
doesn't support F, will it probably degrade nicely, where the user
will still get much of the functionality? Is there some way to use a
more standard or more common way to accomplish much the same purpose?
How much effort would it be to change existing uses of F? If it's
impractical to change all the existing pages, how much effort would it
be to just resolve to avoid F in the future?
It's just hard to say. State a precise case, and we can argue it.
Tim McDaniel
-------------
Timothy A. McDaniel wrote:
>Of course there are no hard-and-fast rules on validation or standard
>conformance.
Of course there are hard-and-fast rules on validation and standards
conformance. ;-)
For standards compliance, one needs to pick a standard and conform to
it. In terms of Web development, the norm is to choose from the HTTP,
HTML and CSS recommendations at the W3C[1].
For (HTML) validation, it's normal to select a _true_ HTML (sgml
and/or xml) validator[2] and have the documents parsed.
>You have to weigh the different non-standardnesses you
>have committed versus the application.
Many Web developers who care about cross-platform mark-up will allow
some proprietary attributes to creep into their HTML (eg. topmargin,
marginheight), but will be aware of the implications (particularly
graceful fallback). Others will avoid vendor specific mark-up at all
times, as the WWW would be a nicer place if we all pulled together.
Unfortunately there are aspects of Web design where it's a good idea
to be conservative in one's use of valid, standards conforming
constructs, due to browser bugs. :-(
[1] W3C - The World Wide Web Consortium
http://www.w3.org
[2] HTML validators
http://validator.w3.org - W3C
http://www.htmlhelp.com/tools/validator/ - Web Design Group
Calum I Mac Leod
-----------------
Cooool Schooool wrote:
>
> How sinful is it if one's page doesn't validate 100%.
How sinful is it if the guy who runs your HTTP server mistakenly
password-protects your virtual host so no one can access it, or if your
hostmaster makes a zone file typo that sends 25% of your visitors to the
North Korean Central Committee web site instead? I mean, you don't
actually expect a paid professional to write valid stuff, do you? :-)
Thor Kottelin
-----------------
Cooool Schooool writes:
> How sinful is it if one's page doesn't validate 100%.
If you are a professional, it isn't a question. Would you hire a
lawyer who wrote contracts that turned out not to be binding? An
architect whose designs violated the building codes? An accountant
whose figures didn't add up? A Web designer whose site couldn't be
viewed on your best customer's mobile phone?
> Is there a scale of sins that one should not commit?
Text as graphics is pretty near the top of my list, especially
imagemaps which are in fact just images of text; anything browser-
or platform- specific; any navigation which is unavailable to any
group of users; any font less than normal size which users need to
read to understand the content or navigation of the site.
> What is the worst HTML goof one can make?
Ommitting ALT tags on navigation icons.
> Does Yahoo etc Validate perfectly?
No. Just because there are incompetents out there, does that mean you
have to be incompetent?
Simon Brooke
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
"UNIX is user-friendly. It's just selective about who its friends are."
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Nobody wrote:
>Beverly wrote:
>>My partner wants to send HTML email, like WebVan, SiliconAlleyReporter,
>>Lycos Gamesville. . .
...
>Doesn't matter. It appears in my inbox as plain text no matter what.
>
>HTML is for the Web. text/plain is for email.
Well, if she meant "My partner wants to send *me* HTML email", then
it's presumably between consenting adults, and they can strap on
attachments and make each other bold and strong as they like.
In general, though, I too recommend not sending HTML e-mail. The
mailers I generally use don't interpret it and thus show it as a
massive barf on the screen. It also makes the message a lot larger.
Tim McDaniel
-------------
Joe Canon wrote:
> Outlook and Outlook Express don't allow you to directly modify the source of
> the HTML file. Maybe someone knows of a simpler path...
'Tis worse than that. A friend of mine had to send me
a valid HTML 4.0 file that he got from the web, then editied
with vi. He then attached it to an e-mail message and sent
it using Outlook Express. The file was completely mangled: all
(Unix) linebreaks in the source were replaced by &10; and the
file was completely and arbitrarily re-wrapped using MS-DOS
line breaks; required quotes were removed from hex color
attributes, META attributes were re-ordered, and new META
tags were added, including
In other words, the mere attachment of an HTML document to
an OE message resulted in the complete hosing of the HTML
file.
Warren Steel
------------
This reminds me of the default behaviour of IE 5 for Win95 etc
If you use File/Save As... and leave the default Save as type of
"Web Page, complete (*.htm;*.html)" in place the original markup has
"" and "" added together with a whole lot of added
spaces and alterations to the layout.
A simple test on my home page blew out the .html file size from 3.56KB
to 4.51KB, an increase of 26.68%. Another example of MS efficiency?
There is a Save as type labeled "Web Page HTML only (*.htm;*.html)"
which saves the page unaltered. A pity it's not the default Save As
setting.
I also noted an option labeled "Web Archive for email (*.mht)" but was
unable to use it off line. I can't imagine what it does and I really
don't want to either.
Robert G. Eldridge
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Advisors should be smart. Tools should be predictable.
Bill Gates should mind this advice, and stop trying to build smart
tools.
--Turing
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
If I may quote Todd Fahrner :
The font size chosen by the user as a comfortable default (1 em)
provides more truly useful information about the rendering
environment than all the resolution-sniffing, window-querying,
"open-this-wide" logic you can throw at the problem.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
????
2. Optimize yopur images. A 16 color gif using a 4096 color pallette will
be 1/10 th the size of a 256 color gif using a 256k color pallette. (If you
can find an old amiga computer or Atari ST, run your gifs through paint
programs on these machines, your files will shrink incredibly.) Reduce your
JPG quality to 70% or 60% you can halve thse file sizes with no loss of
image quality.
b.p.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Rob Lawrence wrote ...
> Concerning this entire thread: there is a real need for an HTML editor that
> (a) people can use without any HTML training, and (b) nonetheless obeys the
> laws of logical, rather than WYSIWYG, structuring.
>
> Someone said lower down that it could be done with Word. This is actually
> correct -- but to get a truly pure result you have to write VBA code that
> calls the Word object model. You can get Paragraph objects from a document,
> interrogate them about their Style, enclose them in appropriate tags, then
> write the result to an ASCII file. I worked on this with someone on my last
> project (we were tech writers and the dev team was preoccupied with bug
> fixes), but the project ended before we had a chance to finish the thing.
> Does anyone find this interesting? I assure you, the result was pretty cool.
> It created incredible vanilla HTML, and even split Word documents into
> multiple HTML pages. Style was provided by CSS . . .
I was pretty excited on my first reading of your posting, since it seemed to
answer the problem of getting decent Web-directed material from contributors
in a Word-dictated environment. But alas, second thoughts quashed my
enthusiasm.
Converting styled paragraphs to decent HTML is not the problem -- I have
maybe six programs that will that do that with varying degrees of success
(Word-to-Web, Filtrix, Word itself with tidy.exe clean-up, DreamWeaver with
cleanup filter, Author-iIt, FrameMaker, etc...). The problem is getting
decently structured documents in the first place.
I have received documents with all paragraphs styled "Normal", with local
font size and weight overrides to indicate heading levels, and manual tab
adjustments for lists. Some documents have hard-returns at the end of each
line, with tabs and/or spaces at the beginning of the line to set the left
margin. Paragraphs are of course separated by a blank line. Each period is
follwed by two spaces. Tables are built from tabs and spaces and
hard-returns. The litany of crimes against reason extends even down to the
template level. I found the corporate template repository filled with
"model" documents constructed exactly as I just described.
This legacy of idiocy is perpetuated by management who cares only what
something looks like, not how it is produced. "What do you mean, train
people how to use Word? That's a crazy waste of money. I can use it with no
training whatsoever, so why would we have train people who already use it
every day?"
We need an editor that works like FrontPage Express, but with CSS paragraph
and span tagging, and =no= font enhancement options on the menu bar. Then
we'd have a fighting chance to teach how to structure information for
effective use.
Jerry Muelver
----------
Jerry Muelver wrote:
> Converting styled paragraphs to decent HTML is not the problem --
[...]
> The problem is getting
> decently structured documents in the first place.
How true, how true.
> I have received documents with all paragraphs styled "Normal", with local
> font size and weight overrides to indicate heading levels, and manual tab
> adjustments for lists. Some documents have hard-returns at the end of each
> line, with tabs and/or spaces at the beginning of the line to set the left
> margin. Paragraphs are of course separated by a blank line. Each period is
> follwed by two spaces. Tables are built from tabs and spaces and
> hard-returns. The litany of crimes against reason extends even down to the
> template level. I found the corporate template repository filled with
> "model" documents constructed exactly as I just described.
Tell me about it. And you didn't mention the typewriter-like habit of
using a single paragraph break for a linebreak, and a double paragraph
break for a real paragraph break.
> This legacy of idiocy is perpetuated by management who cares only what
> something looks like, not how it is produced. "What do you mean, train
> people how to use Word? That's a crazy waste of money. I can use it with no
> training whatsoever, so why would we have train people who already use it
> every day?"
Yup, that's only too true. However, I have made _some_ progress with
the authors that feed me stuff for web pages. They have to be
reminded at every revision that no, please, we don't want one version
for printing and a different version for the WWW, we want one master
document from which both will be derived.
I found Word's autoformatting tool quite good at making a first cut at
a logically-styled Word document. I have the impression that Office97
Word was worse at doing that than the previous version had been, but
it's still worth a try. Sure, you have to re-apply the desired
formatting to the new styles if you want to preserve the original
"look", but at least then the formatting is applied via the style, not
directly to the content. If you have a house style, then you can make
the result into a template. Use that template for autoformatting
subsequent documents and you've got a headstart.
> We need an editor that works like FrontPage Express, but with CSS paragraph
> and span tagging, and =no= font enhancement options on the menu bar.
Something of the kind, yes. But we don't want every paragraph to get
a different span tag, and then all those tags to get the same format!
> Then
> we'd have a fighting chance to teach how to structure information for
> effective use.
I think I'd take a slightly different tack there, even if my own
efforts haven't been nearly as successful as I'd have hoped. Word
itself[*] is a good motivator of the use of logical styles, once the
participants have understood what they are doing. And then they
become the next round of evangelisers of the technique.
[*]Well, I'm sure any modern wordprocessor would be as good; it's just
that at the home campus, Word is the campus standard, so it's hard not
to make use of it.
The link to the WWW and to the delegation of structure in HTML and
presentation in CSS is a valuable consequence, but I'm not convinced
that it's the key to teaching users the principles. For one thing,
HTML/CSS is just too much of a moving target for them to appreciate
the ground principles of this delegation until much later; whereas
word processors have been going for much longer, and the principle of
style template management is well established.
Of course, YMMV and your situation may make things look different.
Alan J. Flavell
-----------
isoma wrote:
> >word processors have been going for much longer, and the principle of
> >style template management is well established.
>
> ...but almost entirely ignored at schools. I've seen modern IT courses,
> in which style didn't get a look in, either in a www authoring context or
> with respect to wordprocessors and DTP utilities.
Good point. I've just tried a Google search, and it came up with
various things.
http://www.g-foods.com/styles/
(from the folks who brought us W2CSS). At a first glance, this seems
to cover the topic usefully.
It also found
http://www.shsu.edu/~csc_jfb/tutorials/tutorial8.html
which seems to be one of an assorted collection of vaguely relevant
tutorials; however, its HTML is appalling.
A more academic study of the situation was found in a draft here:
http://www.ifi.uio.no/~paalso/artikler/styles/nokobit/nokobit.html
(I've seen this before, but had forgotten about it. Don't be misled
by the URL - the paper _is_ in English).
Many of the other tutorials I found were, as you say, concentrating on
direct formatting, and treating styles as some kind of advanced
speciality, when it would be better all round if the exact opposite
view were to be taken, n'est-ce pas? A particularly extreme example
was http://is.rice.edu/~consult/cross/word/layout_to_converted.html
There are also some journal publisher guidelines that are vaguely
relevant.
If you find anything better, that I had missed, let's hear it? As I
say, I think the best match was that g-foods URL (it's a great shame
that it has to go and muddy the water by defining normal text to be
sized 86% of normal, so I had to re-adjust my browser settings upwards
to comfortably read it. Bleagh. But the content seems good, from
what I have read so far.
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The _Evil_ Test Suite
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
PowerWare « Tools for Power Users » What's the problem with Freeware?
http://rijk.op.het.net/powerware/freeware.html
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
jkm wrote:
>Is it safe to use Verdana as a web page font? I think it's on over 75% of
>the machines out there.
Quite frankly I don't think it is safe.
It is such a large looking font, relative to other fonts of the same
size, that a lot of authors feel they have to suggest a size reduction
to avoid it ugly, in my opinion, look in what otherwise would be a
normal size.
The problem then is when a user doesn't have the font they may still
suffer the size reduction making their chosen font look too small.
For body text the safest option is to not suggest any font type or
size at all. The user can then configure their browser, if it is
possible, to use the font of their choice at their choice of size.
What could be of more assistance to the viewer.
The bottom line is if you like Veranda then make it the default font
on your browser, don't try and foist it on others.
>What does a font default to when the one specified is not on the surfers
>machine?
The default font on the users machine.
Robert G. Eldridge
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
"The only reasonable alternative we can come up
with is to close off the Internet to America Online
users until they have passed an entrance test. But
that would break federal laws that prohibit discrimination
against the intellectually challenged."
- hhahn@boardwatch.com
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
My 2 cents:
The font size problem is basically a balance between how the designer wants
the page to look, and how the user does. It's complicated by the factor that
some default settings are not optimal, and many users don't change the
defaults; so that designers are tempted to try and second-guess them. Throw
in cross-platform and cross-browser compatibility issues, and you have a
recipe for a lovely mess and a near-impossibility of creating a single page
that looks good everywhere.
Basically (IMHO), the designer wants to principally set relative sizes (to
create visual hierarchies for layout purposes) relative to the user's
preferred main font size, with the main body in the default size, and
without the larger/smaller text becoming stupidly large or unreadably small
(which is based on the preference of the user, which the designer doesn't
know).
Perhaps browsers should ask users to specify min/max/default font sizes,
with text examples, when set up, not just leave it as an option to change
(which people typically don't). Then you could rely on "small" meaning
"small" and not "too small", and "medium" meaning "user's preferred body
size", etc.
Robin de la Motte
--------
Robin de la Motte wrote:
> The font size problem is basically a balance between how the designer wants
> the page to look, and how the user does.
In a WWW context, this is an unrealistic aim.
The "designer" does not know what the user's setup looks like, and so
the designer's "wants" have to be formulated in terms that can
actually work. In a WWW context, the "designer" does not have control
of the physical attributes of the display, so anything that they do is
going to be interpreted in relative terms. They'll get no better
results by trying to insist on absolute size units: in fact, the
practical results they'll get will be worse. Read Todd Fahrner on
this topic, for example.
> It's complicated by the factor that
> some default settings are not optimal, and many users don't change the
> defaults; so that designers are tempted to try and second-guess them. Throw
> in cross-platform and cross-browser compatibility issues, and you have a
> recipe for a lovely mess
Now, that I think we can agree with.
> and a near-impossibility of creating a single page
> that looks good everywhere.
Well, you're never going to get a page that "looks good" on a
brailler, but the page can still do its job if it's been properly
designed. Lynx users don't expect to be wowed by your visual design
skills either. But I would energetically dispute your implication
that a single page cannot both adapt well to a wide range of browsing
situations, and be visually attractive in situations where visual
attraction is feasible.
have fun
Alan J. Flavell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
In article <38D340BD.B2DA1121@bother.me>, B.P. wrote:
>A site with a font size set to look comfortable at lower resolutions
>can be too small and unreadable at 1280x1024.
Thank you for one of the shortest and best reasons why web designers
shouldn't be setting fonts and sizes. Let *me* set *my browser's*
fonts to the sizes and shapes that fit *my* needs.
I'm glad you finally came around to our point of view -- since we
can't know the viewer's environment, try to make web pages general.
Tim McDaniel
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
WAP Frequently Asked Questions
http://www.option.com/techno/wap.htm
(wap faq)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Boris wrote:
>Fernando schrieb:
>> I'm having to write html documents that have some common
>> patterns repeated...
>> Instead of copying and pasting, I would like to have a tool
>> that works has an html preprocessor...
>
>I think you want to re-invent CSS.
CSS is fine for presentation of course. Otoh, repeated patterns in
structure is probably best handled with a genuine preprocessor.
Galactus used to plug for this one...
http://www.cinenet.net/users/cberry/orbinfo.html
...I can fully agree on that, it's a goodie ;-)
Jan Roland Eriksson
---------
There are a number of HTML preprocessors. I've used two freeware HTML
preprocessors: Orb and
HTMLPP . I can recommend either of
these two.
Others include
HTP
PPWizard
WML
Site Warrior
Darin McGrew
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Nick Kew wrote:
| > This is from statmarket.com:
|
| Never heard of it.
It isn't worth the trouble to find out, either.
First, there's this:
which, apart from the screaming bogosity of the paragraph titled
"Sample Group", reveals an essential dependence on the so-called
"HitBOX Site Analyzer", hyped here:
where, negotiating the "Learn More" link despite some Javascript
nonsense, brings up this explanation of "how it works":
All the usual usual, ho hum.
Arjun Ray
-----------
Nick Lilavois wrote:
| aray@nmds.com (Arjun Ray) wrote:
| >All the usual usual, ho hum.
| And exactly what is bad about this?
"Attaching meaning to meaningless numbers is worse than not having
the numbers at all. When you lack information, it is best to know
that you lack the information. Web statistics may give the user a
false sense of knowledge which is worse than being knowingly
ignorant." - Jeff Goldberg
| Do you know of any better methodology to get stati[sti]cs?
"The simple fact is that certain data which we would like to know
and which we expect to know are simple not available." - Stephen
Turner
| Do you know of any better statistics sites?
"Seek and Ye Shall Find" - Thomas Gilovich
Arjun Ray
------------
Nick Lilavois wrote:
| In other words, there is absolutely nothing wrong with
| statmarket.com or their methodology
From the paragraph titled "Sample Group" at
: The sheer number of Web sites and Internet users in the sample
: make StatMarket a highly accurate source of data on Internet
: user trends.
You're free to draw comfort from feel-good phrases such as "sheer
number" and "highly accurate". You'll need more than Statistics 101
to learn the problem.
Also from that paragraph:
: Any Web site may join the HitBOX.com community by using the HitBOX
: Site Analyzer. The sample group that StatMarket derives its figures
: from consists of the millions of daily unique visitors that view
: those sites
First, "daily unique visitor" is a bogosity invented to compensate for
some marketers' brains refusing to function at all unless the slot
marked "visitor counts" gets filled somehow. Second, the "HitBOX
community" being representative is *not* a matter of size, but simply
one of assertion. Third, web sites joining the HitBOX system are
*selecting themselves*.
If you don't know about self-selection and sampling bias, there's more
than one search engine ready to help you. But let's assume that you
do. From the paragraph titled "How it works" at
: A HitBOX banner or button is installed on your Web page. Each time
: a visitor accesses that page, the banner image is served from the
: WebSideStory servers.
You must have missed the self-selection by the truckload here.
| you just don't like stats at all.
Actually, I don't care for them one way or the other.
But I just realized that you're totally clueless.
Arjun Ray
----------
> You're free to draw comfort from feel-good phrases such as "sheer
> number" and "highly accurate". You'll need more than Statistics 101
> to learn the problem.
I had an idea [Subject] 101 referred to a first year undergraduate course
in an American university. I should have thought that was just about the
right level of insight to appreciate the worthlessness of the alleged
statistics being quoted.
(Perhaps it's true that a degree from a non-ivy-league american university
isn't worth the paper it's written on, and Statistics 101 would be simple
counting and maybe a curvei or two???)
> But I just realized that you're totally clueless.
An observation strongly supported by his track record.
Nick Kew
----------
Nick Kew wrote:
| I had an idea [Subject] 101 referred to a first year undergraduate
| course in an American university. I should have thought that was
| just about the right level of insight to appreciate the worthlessness
| of the alleged statistics being quoted.
Within my limited experience[1], I'd say that it doesn't rate to be
enough. Statistics 101 courses are mainly about finger exercises,
familiarizing the student with various kinds of calculations (measures
of central tendency, standard deviation, bivariate correlation, and a
dash of hypothesis testing.) "Targeted" courses, such as "Statistics
for economics/psychology/business/etc" tend to be even more rote and
formulaic. The average student comes away with a mass of voodoo.
Perhaps the only "good thing" about this pedagogical approach (leaving
insight to the advanced courses) is the entertainment value. The
student is afforded a sense of accomplishment when the voodoo formula
he cranks actually produces a "result". The older tradition, which
emphasized understanding what sampling was all about, was dreadfully
boring in comparison.
[1] Having taught the subject at an ivy-league school.
Arjun Ray
-----------
Arjun Ray writes:
>| I had an idea [Subject] 101 referred to a first year undergraduate
> Within my limited experience[1], I'd say that it doesn't rate to be
> enough.
As in - it relies on the student's numeracy?
> Statistics 101 courses are mainly about finger exercises,
> familiarizing the student with various kinds of calculations (measures
> of central tendency, standard deviation, bivariate correlation, and a
> dash of hypothesis testing.)
It's a long time since I studied it (in the context of a Maths degree),
but ISTR the formulaic techniques were treated as essentially trivial,
while the derivation of the formulae was rather more interesting.
I'm sure the dangers of simplification and biased sampling were discussed.
We know that sampling is often seriously hard, which is why we undertake
parametric studies to estimate the effects of sampling errors.
I did practice it in the early 1980's - in my first job after graduating.
This was with a large consultancy firm working on a range of government
contracts. We would take some guesses out of thin air, and do the
computations based on those assumptions. We would also vary the
assumptions enough to see what errors we might expect in the results.
Of course, the usual result was "anything between 0% and 100%, depending
on the unknown assumptions". This does not lend itself well to an
executive summary (let alone what the media want if it's a subject they're
interested in), and tends to get ignored in favour of "the baseline
assumptions give 85% with an error of +-5%" - or whatever.
In the course of time, the baseline result of such a study would become
a firm result, cited in other studies and no longer treated as a
variable. Well, it's in the literature, and has never been challenged ...
After a couple of years, the meaningless result - with the caveats
conveniently dropped - becomes the received wisdom.
This is the Real World. I left that job, not least because I really
didn't find it satisfying building a great edifice on sand ...
> "Targeted" courses, such as "Statistics
> for economics/psychology/business/etc" tend to be even more rote and
> formulaic. The average student comes away with a mass of voodoo.
- and believe what they want. Like the human population/stockmarket/
any-other-pyramid-scheme can be unbounded.
> [1] Having taught the subject at an ivy-league school.
- having studied at one, and practiced professionally after graduating.
Nick Kew
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
John wrote:
> What is the best way to promote my site?
> Is there a program I can buy
> or do I have to go to each search engine and manually
> input all the info.
> Also is there a cost to promote to yahoo and Lycos?
Your questions imply to me that search engines are *the* way to promote
your site, and that you want the quick and easy way out. Don't take this
and the rest of it personally, because I have some pent up spam-abuse rage
to vent, and you just came along. Sorry.
Search engines are very useful, but they're not the only way to promote
your site. The newsgroup alt.internet.search-engines deals specifically
with the intricacies of search engines. There are other ways to promote
your site.
Yes, there are programs you can buy that will automatically submit a URL
to databases and directories. I've found it better to manually submit to
ten or twelve popular engines. "Submit to over 10-zillion search
engines!!" The rest are myriad miscellaneous directories that don't
really matter, unless you've looked at them, and seen that they are a good
channel for promotion of your site.
In my opinion, some "auto-submit" programs are useful only when they
feature the ability to automatically track your site's ranking and
presence in the search engine databases; but as far as trying to register
automatically, things change, you have to pay attention to where it's
being registered, etc., so much so that I still recommend taking the time
to deal manually with the directories you want to be listed in.
The old adage that "communication is a two-way street" still applies. The
best way to promote your site is to become involved in communities that
are interested in the same topics. I hate to call auto-submission "lazy",
because it can also be "efficient". Just don't think that you can blast
out your message without considering others' concerns. Nobody gives a
shit who you are, unless there's something in it for them, especially at
the social level.
Here are three tips:
(1) Seek out web sites similar to yours. If they're useful to your
audiences, link to them as alternative sources for information. Contact
the webmasters and ask if they're interested in reciprocal links. "Web
rings" formalize this concept. Look into them.
(2) Don't become so self-absorbed that you take the lazy way out by
blasting your message indiscriminately to email addresses and newsgroups
that you don't even communicate with. Cheap and easy as it seems, it
doesn't establish relationships, other than that the victims view you with
hostility ranging from minor pest, to "who the fuck are you?", up to a
full-scale campaign to prevent you from further using community resources
where you don't contribute anything.
(3) The Internet is a big thing, but not everybody's involved to the same
extent. If you use traditional media to advertise your contribution to
society, don't forget to include the URL for your web site in flyers,
yellow-pages ads, radio and TV commercials, business cards, etc.
> What is the best way to promote my site?
Seriously. Don't sit on your ass, thinking a computer network and
software can do the job of making you known in a community, even a
commercial community of buyers.
Get involved with others who provide the same services and who need those
services. That's the best way to promote your site.
But I ramble...
Willondon Donovan
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> # Is 'click here' acceptable?
Criticism of the phrase, "click here," isn't completely universal. Don
Norman once said this in the CHI-WEB mailing list:
"In my not-very-humble opinion, the prohibition against the phrase 'click
here' is someone's bias against what they perceive as tacky, inelegant
writing. (The prohibition) has no empirical backing. I encounter lots of
websites that say 'click here' (usually in catalogs or other ordering
situations) and I find the text useful. It tells me directly what I need to
do rather than making me infer it from the color of the text and the
underline, neither of which are reliable indicators of clickness."
> # Can you safely change link colors? or turn off underlining?
Marc Green would disagree with Jakob Nielsen's opinion that the decision to
make hyperlinks blue are "mother of bad web design conventions ":
"Blue gets a lot of bad ink, not to mention a lot of bad pixels. Guidelines
often say to avoid blue for text and other objects with fine detail. Many
have adopted this mantra without question or inquiry. But studies generally
find blue to be an excellent color for text and foregrounds in CRT displays.
What causes this discrepancy? "
The rest can be found at http://www.ergogero.com/FAQ/Part6/1IsBlueBad.html
Mark Cidade
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Sometimes in a field like artificial intelligence (AI) you need
to slip your message into the memestream in an irreversible way.
An AI project such as http://www.scn.org/~mentifex/ Mind.Forth
can be so large and unwieldy that it must be bugsplattered onto
the windshield of the 'Net in hopes of catching the attention of
iconoclastic hidden-do-wells who think so differently that normal
hype and Marktschleim never reach them. Their pigeon-like avian
mentality dictates that you never appeal to them directly; rather
you leave bait for them to wingwander and start pecking at.
These nitpicking netpeckers love nothing more than to discover
what they think nobody else has ferreted out. Consequently the
coy McLuhanite will see them coming and design what Virgil long
ago descibed as the "irremeabilis unda" or un-wieder-navigable
wave of the Stygian river Styx in the underworld beneath the Web.
The swamp that sickens lesser minds will nourish and fortify the
post-industrial otaku dweebs who live anaerobically obgyn the Net.
Ergo what better way to zing and zang them than to raise a Heaven
over them and a hellish descent to madness beneath their cosmos?
http://www.geocities.com/Athens/Agora/7256/mind4th.html AI 2000
matter-of-factly litters the Webside with Holy Grails of hot bots
while the safety net lo! the trapeze crusoes The Art of Computer
http://www.geocities.com/Athens/Agora/7256/acm.html Mindmaking.
Arthur T. Murray
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Human-Computer Interaction Resource Network
http://www.hcirn.com/
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
"B.P." wrote:
>"Daniel R. Tobias" wrote:
>> The "purists" have advocated CSS since it was first proposed
>
>A "purist" in CIWAH claiming CSS and javascript may be useful. What
>exactly is the difference between a suggestion and force, you aren't
>asking, so you are "forcing" the presentation on those who do not know
>how to override your "suggestion."
As we're now faced with multiple SMAs I'd like to put forward a
(hopefully) simple description of my _personal_ view of the "purist"
viewpoint. I'm sorry it's a little long, I want it to be a slow and
gentle introduction. "Purists" and "anti-purists" alike are welcome
to correct, comment or disagree (that's why were here?).
I'll start with the IMG element, as it's the easiest example to
explain. "Purists" advocate that all images must have useful alt
text, so that those who don't have access to images can access the
site sensibly. This is called "graceful fallback". Simple.
When it comes to CSS, "purists" advocate that it should be correct
("pure"), and that it should be added in a way that allows for
"graceful fallback". This generally means that the underlying HTML
should be satisfactory in the absence of the CSS support, that in-page
CSS definitions should be commented (to keep it out of the way of
non-CSS browsers) and that if one colour is specified for an element,
all should be.
Particularly relevant to this thread, "purists" advocate that absolute
sizes should be avoided for text, and that absolute widths of block
elements within the page should not prevent the Web pages from
adapting to various screen sizes. This is the sort of thing I had in
mind with my "flexible WWW" comment.
I'm quite keen to see the "elegant solution to make a page look
perfect in any resolution". It may well be that BP's view is the same
as mine, and that his idea of "perfect" refers to a page that gets the
content across well and makes people want to use the site (and if
e-commerce is involved), spend money. I fear that his idea of perfect
has something to do with precise, forced layout. Those Web sites that
specify font sizes in pixels in order to protect their branding tend
to render unacceptably on displays with different settings from those
expected. One obvious solution is to use PDF or Flash, where those
who can't render the content in the "perfect" manner won't get it at
all. "Purists" tend not to like that idea, either because they
concern themselves with disseminating information and don't want to
reduce their audience, or because they concern themselves with selling
products and don't want to reduce their revenue. Of course some
"purists" are just lazy or pressed for time, and they don't want to go
through painful browser testing when they can just write "portable"
pages and publish them.
As for JavaScript, "Purists" generally advocate that scripts should be
included in the HTML in a correct ("pure") manner, and that in-page
script content should be commented to keep it from script-unaware
browsers. "Purists" also advocate that client side Scripts should not
be relied upon for content rendering or navigation. Security requires
that client-side form validation should always be backed up by
server-side form validation. JavaScript 'OnSelect' navigation should
be backed up by a cgi-script for non-JavaScript browsers. Essential
content added to a page with JavaScript should be accompanied by a
useful NOSCRIPT replacement.
It also happens that most "purists" don't like gimmicks, slow loading
pages, or poor navigation. The first of these dislikes is often the
cause of a mistaken view that "purists" decry anything but plain,
boring HTML; with no CSS or JavaScript. I personally dislike pop-up
windows and those little icons that follow the cursor around the
screen. I also happen to dislike music that starts without warning
and animated backgrounds, but I do not dislike music or moving
pictures.
Finally, pure pages need not be plain. Alt text doesn't make the
image disappear, a cgi "Go!" button doesn't stop the OnChange property
of a