Re: Method for A? (fwd)

Mike Meyer (mwm@contessa.phone.net)
Thu, 25 Sep 1997 14:47:30 PST


In-Reply-To: <199709252100.OAA15361@server.livingston.com>
From: mwm@contessa.phone.net (Mike Meyer)
To: www-html@w3.org
Date: Thu, 25 Sep 1997 14:47:30 PST
Message-ID: <19970925.78D35D8.D5FF@contessa.phone.net>
Subject: Re: Method for A? (fwd)

> Date: Thu, 25 Sep 1997 14:00:20 -0700 (PDT)
> From: MegaZone <megazone@livingston.com>
> 
> So if you don't like the buttons, perhaps the <BUTTON> element from
> HTML 4.0 and styles will get you the rendering you prefer.

Style sheets will solve part of the problem. All of them? Can I turn a
FORM into a text element with CSS?

> >Basically, the <A> version is better in all ways but one. That one is
> >that popular browsers feel free to reload the displayed page without
> >checking with the user.
> The user clicked on the link thereby providing consent to reload.  If
> they don't want to reload, don't click on the link.

If that were always the case, I would agree. The problem is browsers
reload pages without the user taking an explicit action to indicate
they should do so.

> >In particular, resizing the display after deleting an object caused at
> >least one major browser to reload the page, resulting in the NEXT
> >object also being deleted "accidently". This actually happened once.
> Sounds more like a bug in the browser than a problem with HTML.

I agree with you. Unfortunately, the HTTP/1.1 spec gives the browser
latitude to do just that in this case, so it's sort of hard to justify
calling it a browser bug.

> >The goal is that pages fetched with a POST can not be safely refetched
> >without asking the user would have prevented this from happening.
> Even if POST was added to an A tag I severely doubt browser would change
> behavior.  If you clicked on the A they'd take that to be the same thing
> as clicking SUBMIT on a form and send it.  That's how I'd code it, and
> that's how I hope they'd code it.  Being prompting "IS this ok?" when
> clicking on a link serves no purpose IMHO and would be very annoying.

That's not the behavior I want. It's stopping the GET requests when
the user resizes the window, or wades through the page in the history
list, or simmilar things, that this is designed to deal with.

Basically, HTTP/1.1 gave browser authors latitude to refresh the cache
at will if the cached object was obtained via GET. I want a way to
disable that for objects that are fetched from following an A link.

Possibly you can suggest a way to do that in HTTP, while at the same
time insuring that selecting the link will always result in an actual
fetch being done, and not pulling the object from the cache.

The lack of symmetry between A/FORM and POST/GET bothers me, but
that's a personal issue.

> >> IMHO moot point - I don't think any major vendor would bother with it.
> >In that case, why do we bother with a standards organization at all?
> My point is that to get in approved the actual W3C members would have to
> go with it, which means the vendors, and I don't see a justification to
> this feature.

True, but they certainly aren't going to agree to it if someone
doesn't ask for it.

	<mike