Re: Method for A? (fwd)

> Date: Thu, 25 Sep 1997 16:12:00 -0700 (PDT)
> From: MegaZone <megazone@livingston.com>
> Once upon a time Mike Meyer shaped the electrons to say...
> >> There is also IMG, LINK, META, ISINDEX, BASE, and FIG in HTML3,
> >> and BGSOUND, APPLET, OBJECT, and EMBED in other clothing.
> >Possibly I misused the terminology, but the rest are not what I'd call
> >sources for hyperlinks. They are references to objects related to the
> 
> But they are.
> 
> ISINDEX generates a text box for the user to enter and submit.

Not on all browsers. Personally, I prefer those where it doesn't
generate such boxes in the page, as that means it's accessible no
matter where on the pgae you're looking.

> LINK and IMG can call in data.  META can do 'refresh' in some browsers
> and load a new page.

Right.  But those aren't sources for hyperlinks - there is nothing on
the page the user can push to fetch them. A few browsers provider
elements in THER guis for some LINK tags, but that's about it.

Those things aren't what I'd call sources of hyperlinks. I used those
words purposely, as I wanted to distinguish them from things that the
browser fetches as part of loading a page without the user selecting a
link/button in the HTML.

> >Of course, IMG gets regularly abused to GET a hit counter. That
> >doesn't change the correctness of the data on the server, though -
> >it's wrong either way.  I do wonder how POST would change that, though
> 
> Why is it wrong??

Um - the count presented by the silly inline image counters is wrong.
That's wht I was referring to as "wrong either way".

> It is a perfectly legitimate use.  No one said that
> images MUST be static files.  So what if the counter is being generated
> dynamically by a program - it is still an image.  End of story.

That depends on whether you consider incrementing the counter to be a
"safe" action or not. If you don't consider an incorrect increment to
be a bad thing, then you're fine. If you do consider such an increment
to be bad, then fetching the object is unsafe, and hence you should be
using the POST method to get it.

> HTML is commonly generated dynamically.  You have no way to know if any
> page you are calling is stored as a file or coming from a program.

Yup. However, if fetching the object isn't "safe", then the spec says
you're supposed to use POST to get it. POST can only be used from
FORM's. This means that all "unsafe" dynamic objects have to be
fetched from a FORM, which is what I'm trying to fix.

Of course, the reason for FIXING this is that browsers are fetching
objects they think of as safe without checking with the user.

> >But yeah - it'd be nice if authors were allowed to specify that all of
> >those were dynamic, and should be fetched only by explicit action by
> >the user.
> I think that would be horrible.  A real step backwards since most of
> these are used for new features that enhance accessibility and design
> options.

How is the giving the author more power to give the user more control
of their browser a step backwards? Sure, REQUIRING that kind of
behavior would be a major step backwards.  Allowing authors to say
that fetching those objects may cause unsafe actions and so should be
checked with the user is surely a step forward.

> >I specifically chose *not* to propose alterations to the 4.0 DTD to
> >deal with this, as some of them have multiple attributes that take
> 
> Adding method to A is a DTD alteration.

I know that. I didn't propose an alteration; I proposed something that
required one. The alteration for just this is trivial. However, it
might be better done in another way if it's going to be more global
than this.

	<mike

Received on Thursday, 25 September 1997 20:03:35 UTC