> This is the way Lynx (and possibly other browsers) improperly displays hidden
> fields on forms. My workaround for that was to put what I would have
That's been fixed, BTW, in the latest version of Lynx.
Hooray for small miracles.
...
If it's really the same page, then there's nothing much "Universal" about
your "Universal Resource Locator," is there? :-)
It depends what you mean "Universal" I always interpreted that to
mean that since the protocol is part of the identifier, it is
universal in the sense that it tells you everything you need to do to
get the resource. In that sense there's nothing about my suggestion
that is "non-universal". Your suggested meaning of "Univeral" implies you
think it defines an injective map. OK, but that just seems a little
counter-intuitive to me.
> caching is not based on the identity of the displayed page, but on the
> identity of the requesting URL.
Should be the same. That's why they're called "Universal".
> header field which, if present (and it's of course optional!) should be
> used as the document identifier in the client's cache, instead of the
> requestor's URL.
Ick! Let's hide more information from the user so it's *completely*
impossible to figure out what's going wrong. Good idea.
Well, I hate to disappoint you, but there's already an optional "uri:"
header field defined in the spec. My suggestion boils down to how browsers
should use the information in this field, I think, in addition to the
URL by which they requested the document. (The intended use
of this header field isn't too clearly spelled out in the HTTP2 spec.)
What if they really do want to go back to an empty shopping basket?
--Darren
Well, then presumably they want it to really BE empty, which means the
server (which may be keeping persistent state on the user's behalf)
and the browser need to agree. Having the user just be able to view
obsolete data won't help with anything.
--Shel