Chris Beall wrote:
> On Mon, 25 Apr 2011 14:57:48 -0400, pete <pete
...@yahoo.com> wrote:
>> Everything goes in cycles, they say, and I wonder if perhaps it's time
>> to revive the Refresh header, to give it a new place in Web2.0
>> operations.
JFTR: "Web 2.0 operations" by definition includes server-side scripting, and
even "AJAX" (as in XHR) as well.
>> That would work well for one of my sites IFF some user/visitor state
>> could be sent with the browser's automatic-refresh GET request, the one
>> that's issued as it periodically honors the page's Refresh header.
No, it would not. But see below.
>> Imagine for a moment that AJAX does not exist. Then:
>> Consider a site
http://www.all-the-headlines.com/. It serves a web page
>> full of headlines from three newspapers. These headlines are literally
>> current to the minute because the page carries a Refresh header, perhaps
>> instigated by:
>> <meta http-equiv="refresh"
>> content="60;url=http://www.all-the-
headlines.com?source=nytimes,wallstjournal,washingtonpost">
>> in the page's <head> section. The effect of the header is that every 60
>> seconds the browser automatically, on its own, issues a GET request with
>> a query string that I assume (haven't found an example yet) must look
>> something like:
>> source=nytimes,wallstjournal,washingtonpost
>> Now imagine that a user is tired of seeing Wall Street Journal
>> headlines, and he says so by clearing a checkbox on the page.
>> Script on the page now wants to modify browser's GET-request query
>> string such that, instead of
>> source=nytimes,wallstjournal,washingtonpost
>> it becomes
>> source=nytimes,washingtonpost
>> Question: What's a way for the script to change the query string so that
>> it reflects the user's new preferences?
> You said to assume that AJAX does not exist. OK. But AJAX is just a
> mashup of several technologies, so I'm also going to assume that HTML and
> JavaScript are still available.
> The refresh is part of a META element.
Or it is not happening at all. META-refresh can be disabled. In
particular, it can be disabled in Opera, the browser which mail plugin you
(Chris) are apparently using to post to Usenet. One reason why it is a
Really Bad Idea to try to revive it (the other is that it breaks navigation
when it works[1]).
[1] <http://www.w3.org/QA/Tips/reback>
> That element appears in the DOM, which can be accessed by JavaScript.
> Within the element, the url= attribute carries the data you want to
> modify.
No, there is no `url' attribute there. There is a `content' attribute,
which value contains a `url' part.
> In the DOM, that's a separate node named 'url'.
There is not. There is an attribute node named `content' though, which
value can be more easily accessed with the `content' property of the element
object (an implementation of the property attribute of the implemented
HTMLMetaElement interface):
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-37041454>
You have covered the issues with that approach rather well, but you have not
provided any solutions so far. Let me provide one:
As you have noticed, assuming that browsers would evaluate the URI not
before the timeout occurred (I have not tested yet), after the automatic
refresh was done, iff it was done, the markup would be the same as before.
Unless you would store the information in a client-side cookie and the like,
and you would generate the META element with the modified preference
(client-side or server-side).
However, a public Web application should never depend on support for client-
side scripting. So server-side scripting should be used for this in the
first place, and then there is no good reason why "AJAX" (better: XHR) could
not be used (but not be depended on either).
But even with server-side scripting it is still a Really Bad Idea to try to
revive META-refresh (for that).
BTW, presenting external content like original headlines from several
newspapers on one's Web site can easily lead to copyright infringement. If
it is not a public service by an official data provider, getting written
approval from the original author is strongly recommended (IANAL).
> Documentation on using JavaScipt to modify the DOM in a way that works
> cross-browser is scanty. (I would be delighted to be corrected by
> someone).
Both <
http://jibbering.com/faq/> (or its cached copy; it is offline again at
the time of writing) and <
http://developer.mozilla.org/> can give you some
clue.
> All of this is off-topic for an HTML group.
ACK
It is not; that newsgroup apparently is for reviews of existing Web sites,
not discussions about hypothetical ones (and it appears to be quite dead on
top of that). Please read both the tagline and (if available) the charter
of a newsgroup before you crosspost or set followup-to it.
> I've attempted to cross-post this and set followups there, but I've never
> done that before, so I may have fumbled it.
It worked, but I am ignoring your Followup-To and correcting the crosspost
nevertheless.
Please trim your quotes to the relevant minimum, even when crossposting
(where the minimum would be greater than usual, but still not a full quote).
F'up2 ciwa.misc
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
