single page apps, URL hash setting, bookmarking, & the back button.

D

David Mark

Companies where the founders are developers.

Are they supposed to be more believable? Lots of developers are
incompetent (though some manage to overcome that handicap.)
You are a web developer and you give out advice frequently.

Wrong on both counts. I used to give out advice frequently, but I
have never been a Web developer (they don't make enough money to
support my lifestyle.) ;)
Why should
anyone listen to you?

Why are you constantly asking me questions? How often do I
reciprocate? Apply that virtually everybody else in this business.
There you go.
 
P

Peter Michaux

Are they supposed to be more believable?  Lots of developers are
incompetent (though some manage to overcome that handicap.)





Wrong on both counts.  I used to give out advice frequently, but I
have never been a Web developer (they don't make enough money to
support my lifestyle.)  ;)

Posting to Usenet through Google Groups is expensive? Google lets me
do it for free.

Peter
 
P

Peter Michaux

There clearly is a demand for such thing. Fortunately, HTML5 defines
`hashchange` event on body and window:

<http://www.whatwg.org/specs/web-apps/current-work/#handler-window-onhashchange>

Ian Hickson also confirms that HTML5 guarantees setting the
location.hash property does not cause a page reload.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020880.html

So the spec is definitely going in the direction that supports the
hash-setting style of navigation in a page like Yahoo! Maps.

Peter
 
D

David Mark

Ian Hickson also confirms that HTML5 guarantees setting the
location.hash property does not cause a page reload.

How does that help for those who need to build sites *today*? This
new "standard" is not retroactive.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020880....

So the spec is definitely going in the direction that supports the
hash-setting style of navigation in a page like Yahoo! Maps.

And you see this as some sort of validation? It isn't (just as QSA is
not a validation of jQuery or other query-centric libraries.)
 
O

Osmo Saarikumpu

Well there you go! Thanks for posting that link.

I'm not that grateful. Activating that link completely crashed my FF
3.0.11 *and* my IE 6. Then I try my Opera 9, which freezes and reports 9
CSS and 2 JS errors. This is where I loose interest and give up, as I'd
be left only with NN 4.7, which I don't dare to try.

Gee, HTML 5 must be Web 3.0!

No I have to figure out if I should dare to try restore my FF session.

Best wishes,
Osmo
 
G

Garrett Smith

A Location object (window.location) as a publisher of hashchange events
makes sense to me.
There clearly is a demand for such thing. Fortunately, HTML5 defines
`hashchange` event on body and window:

<http://www.whatwg.org/specs/web-apps/current-work/#handler-window-onhashchange>

It looked like it could bubble, from earlier drafts.

| Must be invoked whenever a hashchange event is targeted
| at or bubbles through the element.

In IE8, it bubbles:
http://msdn.microsoft.com/en-us/library/cc288209(VS.85).aspx

[...]

Garrett
 
T

Thomas 'PointedEars' Lahn

kangax said:
There clearly is a demand for such thing. Fortunately, HTML5 defines
`hashchange` event on body and window:

It *might* define that *one day in the future*.

Given that W3C now has announced to commit XHTML 2 resources to HTML 5,
the reference should be <http://www.w3.org/TR/html5/>. There is no such
event defined in that Working Draft.

Neither document qualifies as reference material.
Wouldn't it be possible to use hidden iframe to test hash setter
reloading a document?

I do not understand. Please elaborate.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Osmo said:
I'm not that grateful. Activating that link completely crashed my FF
3.0.11 *and* my IE 6. Then I try my Opera 9, which freezes and reports 9
CSS and 2 JS errors.

When visiting that site (with clean cache), reproducibly something running
slow in <Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11)
Gecko/2009061212 Iceweasel/3.0.11 (Debian-3.0.11-1)> pushes CPU load to 100%
(or more) for some time (ca. 5 to 6 min) here, but I can observe no crash,
and no script or CSS errors in Firebug (there are some CSS warnings, though).

I presume the cause of that to be "Unobtrusive JavaScript" that iterates
over a thousand or so nodes to provide for the "Post-It notes" feature as
those notes are displayed pretty late, and instead of being positioned fix
they are repositioned every time I scroll the document. Scrolling is also
when CPU load goes to 100% peaks again (checked using gkrellm).

Rest assured that a single document that downloads 1013 KiB of mostly
textual data in 1 min 34 s (according to Firebug 1.4X.0b7) is FUBAR.


PointedEars
 
P

Peter Michaux

How does that help for those who need to build sites *today*?

It helps a lot. Since the new versions of major browsers support the
behavior described in HTML5 and the spec that will guide the next
generation(s) of browsers confirms the required behavior that means
there is little chance that using this currently de facto standard
will backfire in new browsers.

As you know, writing browser scripts that you hope will last the test
of time is brittle and a guessing game. We are playing the odds.
This
new "standard" is not retroactive.





And you see this as some sort of validation?

Not absolute validation but it is support in that direction.

Peter
 
D

David Mark

It helps a lot. Since the new versions of major browsers support the
behavior described in HTML5 and the spec that will guide the next
generation(s) of browsers confirms the required behavior that means
there is little chance that using this currently de facto standard
will backfire in new browsers.

You are delirious.

1. It's not a standard.
2. The "new versions of major browsers" are used by a tiny percentage
of visitors.
3. The "next generation of browsers" stuff is worthless speculation.
4. Your proposed end-around is not compatible with the proposed
standard at all.
As you know, writing browser scripts that you hope will last the test
of time is brittle and a guessing game. We are playing the odds.

See above. You've thrown the game away for the present *and* future.
Not absolute validation but it is support in that direction.

Not really (see above.)
 
D

David Mark

Thomas said:
kangax said:
Peter Michaux wrote: [...]
For use on the general web, feature testing is required. I remember
that feature testing for the Safari infinite loading state bug when
setting the location.hash property was at least not obvious to me.
Safari was really breaking a long standing feature of browsers.
Wouldn't it be possible to use hidden iframe to test hash setter
reloading a document?
I do not understand.  Please elaborate.

Something along these lines: (only tested in S2 and FF3)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
   <head>
     <title></title>
   </head>
   <body>
     <script type="text/javascript">
       (function(){

         function createIframeEl() {
           var elIframe = document.createElement('iframe');
           elIframe.src = '';
           elIframe.width = elIframe.height = 1;
           return elIframe;
         }

         var elIframe = createIframeEl();
         document.body.appendChild(elIframe);

         var iframeContext = window.frames[0];
         var uniquePropName = +(new Date());

         iframeContext[uniquePropName] = 'foo';
         iframeContext.location.hash = 'blah';

         setTimeout(function(){
           alert(iframeContext[uniquePropName]);
         }, 100);
       })();
     </script>
   </body>
</html>

That's a Hail Mary. Ultimately, the solution to this "problem" is
very simple. Design a real interface. Then you don't have to worry
about shoehorning a new idea into the old and established browser
interface, which should remain inviolate anyway.

And what would you do when and if HTML5 gets here? Add another test
and another fork to the code? Detecting event support on the location
object is going to be a neat trick.
 
T

Thomas 'PointedEars' Lahn

kangax said:
Thomas said:
I do not understand. Please elaborate.

Something along these lines: (only tested in S2 and FF3)
[...]

Don't. The point of using fragment identifiers for navigation is keeping
Web applicatons accessibile. There is nothing in the iframe solution that
could not work without the iframe (global variables, globally available
properties); there is a lot that could not work with it.


PointedEars
 
D

David Mark

David said:
Thomas 'PointedEars' Lahn wrote:
kangax wrote:
Peter Michaux wrote:
[...]
For use on the general web, feature testing is required. I remember
that feature testing for the Safari infinite loading state bug when
setting the location.hash property was at least not obvious to me.
Safari was really breaking a long standing feature of browsers.
Wouldn't it be possible to use hidden iframe to test hash setter
reloading a document?
I do not understand.  Please elaborate.
Something along these lines: (only tested in S2 and FF3)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
   <head>
     <title></title>
   </head>
   <body>
     <script type="text/javascript">
       (function(){
         function createIframeEl() {
           var elIframe = document.createElement('iframe');
           elIframe.src = '';
           elIframe.width = elIframe.height = 1;
           return elIframe;
         }
         var elIframe = createIframeEl();
         document.body.appendChild(elIframe);
         var iframeContext = window.frames[0];
         var uniquePropName = +(new Date());
         iframeContext[uniquePropName] = 'foo';
         iframeContext.location.hash = 'blah';
         setTimeout(function(){
           alert(iframeContext[uniquePropName]);
         }, 100);
       })();
     </script>
   </body>
</html>
That's a Hail Mary.  Ultimately, the solution to this "problem" is
very simple.  Design a real interface.  Then you don't have to worry
about shoehorning a new idea into the old and established browser
interface, which should remain inviolate anyway.
And what would you do when and if HTML5 gets here?  Add another test
and another fork to the code?  Detecting event support on the location
object is going to be a neat trick.

What exactly from HTML5 "getting here" will break the test or make me
fork it?

I am referring to the "point" that was made previously about this
outlandish scheme being future-proof (as opposed to broken in
innumerable agents today) due to HTML5 offering an event to track hash
changes. My point is that this whole thing falls apart when you
realize there's no way to detect/test the introduction of the new
event (you'd be stuck with the timer-based "solution" until all of the
old agents became extinct.)

As for the IFrame test, it is simply ill-advised (as is virtually
anything that creates an IFrame.) Presumably you wouldn't need it at
some point in the future (it's been asserted that HTML5 will allow
location mutation), but there's really no way to detect when that
occurs (assuming it ever does.)
 
D

David Mark

Something along these lines: (only tested in S2 and FF3)
[...]

Don't.  The point of using fragment identifiers for navigation is keeping
Web applicatons accessibile.

Presumably you mean *real* fragment identifiers. Certainly there's
nothing that these "Web 2.0" scripts are doing to help accessibility
by twiddling with the location. Have to figure most are inherently
inaccessible to start with.

[snip]
 
D

David Mark

David said:
[...]
What exactly from HTML5 "getting here" will break the test or make me
fork it?
I am referring to the "point" that was made previously about this
outlandish scheme being future-proof (as opposed to broken in
innumerable agents today) due to HTML5 offering an event to track hash
changes.  My point is that this whole thing falls apart when you
realize there's no way to detect/test the introduction of the new
event (you'd be stuck with the timer-based "solution" until all of the
old agents became extinct.)

Why do you think there's no way to detect/test that event? A good old
"property inference" works like a charm:

function isHashChangeEventSupported() {
   return typeof document.body.onhashchange ==! 'undefined';

}

I assume the (==!) is a typo. I wouldn't call this a "good old"
anything though. I only came up with it recently. ;)
returns `true` in IE8, which does in fact support that event.

Then it bubbles in IE8. I wouldn't infer too much from *that*.
All that's
left to do now is fork code to use hashchange or polling as a fallback.

So much for future-proof (unless you intend to jump through all of
these hoops starting today.) It's a hard way to go and the
destination isn't desirable (the latter being the main point.)
IIRC, that's what most of the scripts on the web do (including relevant
dojo module, if I'm not mistaken).

What most scripts on the Web do for what?
Fortunately, hashchange was just added to FF nightlies (only 11 days
ago, actually) <https://bugzilla.mozilla.org/show_bug.cgi?id=385434>

Well, that only helps the tiny percentage of the population who
download FF nightlies.
WebKit is obviously aware of it, follows the suite and should probably
have it ready pretty soon <https://bugs.webkit.org/show_bug.cgi?id=21605>

I never said it wasn't coming (of course the browser developers are
aware of it.) Just that it isn't necessary and will be dicey to
detect (if you can detect it at all.)
I suppose Chrome will follow shortly after.

Does this sound like something you would bank on today, even if the
end result were preferable to what I recommended?
I agree, and I as I said in a follow-up, I think it's too fragile and
shouldn't be relied upon.

No question. It's a major performance hit as well (creating a new
window object.)

[snip]
 
D

David Mark

David said:
David Mark wrote:
[...]
What exactly from HTML5 "getting here" will break the test or make me
fork it?
I am referring to the "point" that was made previously about this
outlandish scheme being future-proof (as opposed to broken in
innumerable agents today) due to HTML5 offering an event to track hash
changes.  My point is that this whole thing falls apart when you
realize there's no way to detect/test the introduction of the new
event (you'd be stuck with the timer-based "solution" until all of the
old agents became extinct.)
Why do you think there's no way to detect/test that event? A good old
"property inference" works like a charm:
function isHashChangeEventSupported() {
   return typeof document.body.onhashchange ==! 'undefined';
}
I assume the (==!) is a typo.  I wouldn't call this a "good old"

Typo of course.
anything though.  I only came up with it recently.  ;)

It's pretty stable from what I've seen, but not without its own quirks.
This inference falls short with mutation events, for example.

For the uninitiated, we are talking about this:

http://thinkweb2.com/projects/prototype/detecting-event-support-without-browser-sniffing/

The technique has been in use for no more than six months or so, but
seems to be a solid inference. Certainly it works in the old browsers
and there is no indication that browser developers will abandon DOM0
event properties any time soon.

Which event? Is that your version or mine? Mine uses get/
setAttribute when it is available and tests properly. IIRC, yours
makes a leap of faith at some point (see my comment on the blog
entry.)

Still, it is IE8 and MS documentation isn't exactly reliable either.
Not sure I'm following. How is it hard to perform a trival fork or how
can it be characterized as jumping through hoops?

You don't see creating IFrames, mutating the location object, etc. as
jumping through hoops (especially when simple alternatives are
available and lead to far more impressive results?) If not, try it in
some mobile browsers. I'll bet the list of failures grows
dramatically from the two browsers already listed here.
if (isHashEventSupported) {
   // observe "hashchange" event}

You can't be sure you can detect that.
else {
   // poll hash for changes

So you can't be sure when to do this.
}



Hash change detection. Here's one of them:
<http://bugs.dojotoolkit.org/ticket/7925>

That back button stuff? I'm throwing that module out of my branch at
some point. Shouldn't come as a surprise.
Not so tiny once update is pushed into public.

Well, that doesn't happen nightly. And thank God for that as I get
tired of dismissing those upgrade popups.
How do you know how hard it will be to detect it? Inference works in IE8
so far. It might work in other clients or it might not. Time will show.

Well, so much for "betting on the future" as put forth as an argument
earlier in this thread. More like mortgaging the future for zero
present gain.
You mentioned cookies as an alternative, but I don't see how that
solution is comparable to this one.

No, that was just the start of the discussion. Re-read the thread
(backwards will get you there faster.) There's no great revelation
BTW, just a simple and straightforward solution (those are usually the
best ones.)
 
T

Thomas 'PointedEars' Lahn

kangax said:
Why do you think there's no way to detect/test that event? A good old
"property inference" works like a charm:

function isHashChangeEventSupported() {
return typeof document.body.onhashchange ==! 'undefined';
}

returns `true` in IE8, which does in fact support that event.

When you look further, you will observe that there are instances where it is
not possible to tell apart a proprietary event-handler property that has
never been assigned a value explicitly from a proprietary event-handler
property that is unsupported. Not even the strict comparison (which you
have backwards here) changes that.

As a result, I have removed all feature tests to that end from
dhtml.*EventListener() as they would produce false negatives.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,093
Messages
2,570,607
Members
47,226
Latest member
uatas12

Latest Threads

Top