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

[David Mark]

The use of hash-setting is not counter to the idea of progressive
enhancements.

You are definitely at the other end of the spectrum. Simply put, good
ideas vs. lousy ones.

Yahoo Maps!

Yes, I take it you like that site.

You are not saying why it is a ludicrous design. Just saying so has no
influence on me.

You need to read more carefully. Perhaps somebody else will now
explain it further. I think I've put enough time into this for one
lifetime. And you should know by now that I know what I am talking
about in this area. You should put more effort into understanding
what I said.

I mentioned Yahoo! Maps much earlier in this thread as the example I
found most compelling. I've been on the fence about GMail and
Facebook. Facebook strikes me as the weakest of the three use cases.

This may come as a surprise, but I'm no fan of Yahoo! Maps (or any of
those other miserable map sites.) They are the worst. Scroll bars
everywhere, scripted balloon tips that scroll the destination off
screen. Doesn't surprise me they use faux hashes. I hadn't even
noticed (see what I mean.)

 

[David Mark]

Wow.

You know I hate that.

[snip irrelevance]

And you know exactly what I meant. If not, read it again.

 

[Thomas 'PointedEars' Lahn]

Broken by design (try using the back button)

OK, the Back button doesn't work as supposed. That's a shame, indeed.

and that site is a crock anyway

I beg your pardon?

(what sort of reality check is that?)

Apparently I picked a bad example. However, it is possible to make the
Back/Forward feature work with this, and there are sites that do that.
Given that changing and preserving a document's state can work more
seamlessly if client-side scripting and DOM features are supported,
I cannot find anything wrong with this approach.


PointedEars

 

[Peter Michaux]

Apparently I picked a bad example. However, it is possible to make the
Back/Forward feature work with this, and there are sites that do that.

The only way I know to do this is to poll the window.location property
for changes. This polling is easy to do but it is unfortunate there is
not a native window.onlocationchange event. I think that event will
appear eventually.

What other ways do you see?

Given that changing and preserving a document's state can work more
seamlessly if client-side scripting and DOM features are supported,
I cannot find anything wrong with this approach.

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.

Peter

 

[Peter Michaux]

Which we both know carries no weight at all.

No. I've always thought it carries a lot of weight. What works for
"most" of the web is an important property of any technique. If
feature testing can be layered on top then the technique can work well
for a slightly higher group of people.

It is almost assured that no script of even modest size, regardless of
feature testing, will work in all browsers. It will work in the
browsers where that script has been tested. It is unknown if it will
work elsewhere as browser bugs come in a wide variety of strange
flavors...some even you have never tasted.

I thought this case was
closed years ago.  Odd end-around gimmick, something you don't need,
known to cause problems, frequently mixed with browser sniffing, etc.
Why are we discussing this again?

Because URL hash-setting navigation appears to add value to the user
experience. As a user it has improved my user experience at least on
Yahoo! Maps.

Because if a technically sound approach exists to implement URL hash-
setting then that is at least interesting.

Peter

 

[Peter Michaux]

Just so happens it was irrelevant unless you were trying to prove my
point.

You write "nobody would", I give you a counterexample of people who
would, and you blow my example off as irrelevant. You could
alternately acknowledge the counterexample and refine your statement.

OMFG. I'll pretend you didn't write that.

Why pretend I didn't write that? Because I'm right and it is contrary
to your previous statement?

Again, that's a *fragment*, which is what hashes are for.

I don't understand why you are so worried that hashes were originally
used for anchors. Many advances on the web have been made by using
features for purposes that were not the original intent. Often this
turns out to be bad but sometimes it turns out to be a great advance.

I've
mentioned this six times already. The containing document would have
state preserved as cookies as the hash is obviously *taken*.

I think a cookie is a really awful way to preserve UI state. I've
already mentioned why: can't bookmark or email it, can loose it by
clearing or loosing cookies, loose it by changing browsers, etc.

But that's the case we've been discussing all along.

No. Primarily we've been discussing setting the URL hash as the state
of the page changes.

Do you now want
to replace the current entry instead? What possible good would that
do? It could certainly do some bad (i.e. reload the whole document),
but I can't think of anything to be gained from such an operation.
Cookies are what you want here. There's even SQL now in WebKit-based
browsers. Leave the hash alone.

Is your objection to hash-setting simply the history issues? They are
not connected. Setting the URL hash does not imply adding to the
history.

That's completely untrue. I've described in detail how the design is
flawed, why it isn't needed and demonstrated that every example design
posted thus far is flawed and/or broken.

You haven't made any demonstration of why the Yahoo Maps! design (not
implementation) is broken. You've said it is not necessary which is
true but not why it is broken.

Peter

 

[Peter Michaux]

And you should know by now that I know what I am talking
about in this area.

I know you have some technical knowledge about browser scripting.
Because you have some knowledge, I am certainly interested in any
technical experience you have; however, just because you know and have
shared some things you've learned about browser scripting, it doesn't
mean I'll take your unjustified declarations of what is bad as truth.
That would be unreasonable on my part.

Peter

 

[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>

Well there you go! Thanks for posting that link.

Peter

 

[David Mark]

OK, the Back button doesn't work as supposed.  That's a shame, indeed.

Yeah, a real shame. Been like that forever. I considered using it as
a (bad) example here, but it really doesn't apply, does it? It has
actual fragments, so rearranging them into a tabbed dialog is trivial
(and certainly shouldn't break the back button!)

I beg your pardon?

As in, a crock of shit. Have a look at the source. It's cutting edge
for 1999.

Apparently I picked a bad example.  However, it is possible to make the
Back/Forward feature work with this, and there are sites that do that.

Of course there are. That is hardly an innovative design. We've
discussed such issues here many times (seems I'm the only one that
remembers the discussions.)

Given that changing and preserving a document's state can work more
seamlessly if client-side scripting and DOM features are supported,
I cannot find anything wrong with this approach.

Except that it has nothing to do with this discussion and they blew it
anyway. Find a more appropriate example (and make sure it works.)

 

[David Mark]

The only way I know to do this is to poll the window.location property
for changes. This polling is easy to do but it is unfortunate there is
not a native window.onlocationchange event. I think that event will
appear eventually.

If you are talking about that W3C tabbed dialog, you aren't thinking
at all. Look closer. It's not like the other "innovations" discussed
in this thread. It's much closer to the tabs discussed in one of your
blog posts.

It's obvious what they did wrong. It's not that they set the location
(they are clearly averse to doing that.) It's that they didn't
prevent the default action (navigating to the fragment.) Of course,
you have to do some feature testing before doing that, else you will
break the document in cases where the tabs won't fly (or don't make
sense.) I didn't look at their script, but I doubt they did that
either.

What other ways do you see?

The same way such enhancements have been done (and discussed here) for
years. Tabs for fragments isn't a new concept.

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.

Why are you stuck on *setting* the location. Never needed that
before. Certainly don't need it here.

 

[Peter Michaux]

If you are talking about that W3C tabbed dialog,

I wasn't.

Why are you stuck on *setting* the location.

I'm not stuck on it. I'm exploring it as an option to enhance the user
experience.

Never needed that
before. Certainly don't need it here.

No you don't need to set the location hash. (You don't need JavaScript
to do most things on the web.) The ability to set the location has is
there and it seems that for some applications, like Yahoo! Maps, doing
so enhances the user experience.

Peter

 

[David Mark]

No. I've always thought it carries a lot of weight. What works for
"most" of the web is an important property of any technique. If
feature testing can be layered on top then the technique can work well
for a slightly higher group of people.

Of course, but this "technique" cannot be feature tested and there are
no tests for bad design decisions.

It is almost assured that no script of even modest size, regardless of
feature testing, will work in all browsers. It will work in the
browsers where that script has been tested. It is unknown if it will
work elsewhere as browser bugs come in a wide variety of strange
flavors...some even you have never tasted.

That's ridiculous. I write mammoth scripts for a living (and
occasionally for the public) and am constantly and pleasantly
surprised when these beasts move cleanly from one agent (or
configuration) to the next (year after year.) That's what cross-
browser scripting is about. "It will work in the browsers where that
script has been tested" is a loser's mantra, more appropriate for the
old-style multi-browser scripts. And for even modest sized scripts?
When did you become such a defeatist?

Because URL hash-setting navigation appears to add value to the user
experience. As a user it has improved my user experience at least on
Yahoo! Maps.

There are lots of other ways they could have improved your experience
in this area and remained competent. They chose not to and that is
their problem. Don't copy their blunder.

Because if a technically sound approach exists to implement URL hash-
setting then that is at least interesting.

How much can you analyze setting a property? And the end result is a
bad idea anyway.

 

[David Mark]

You write "nobody would", I give you a counterexample of people who
would, and you blow my example off as irrelevant. You could
alternately acknowledge the counterexample and refine your statement.

No, because your example of Web developers writing to please
themselves is silly and I'm tired of going around in circles regarding
such nonsense.

Why pretend I didn't write that? Because I'm right and it is contrary
to your previous statement?

You sound like a child. The previous "argument" was also silly and
childish nonsense.

I don't understand why you are so worried that hashes were originally
used for anchors. Many advances on the web have been made by using
features for purposes that were not the original intent. Often this
turns out to be bad but sometimes it turns out to be a great advance.

I'm not worried about a damned thing.

I think a cookie is a really awful way to preserve UI state. I've
already mentioned why: can't bookmark or email it, can loose it by
clearing or loosing cookies, loose it by changing browsers, etc.



No. Primarily we've been discussing setting the URL hash as the state
of the page changes.


Is your objection to hash-setting simply the history issues? They are
not connected. Setting the URL hash does not imply adding to the
history.

You've said that three times. Still carries no weight as I mentioned
that replacing the history entry doesn't help you simulate navigation,
which is apparently one of your main design goals. If you are
strictly trying to stash a string in the hash, use a #$%! cookie (for
the last time.)

You haven't made any demonstration of why the Yahoo Maps! design (not
implementation) is broken. You've said it is not necessary which is
true but not why it is broken.

They are the odd man out there, aren't they? Finally a point. I
haven't looked at it, but off the top of my head:

1. Breaks older (but not ancient) browsers
2. Users YUI, so your loser anthem applies (works only in browsers
where it has been tested.)

BTW, how many of the billion or so configurations of IE do you test?
What about the others? Where do you find the time?

 

[David Mark]

I know you have some technical knowledge about browser scripting.

I think that goes without saying.

Because you have some knowledge, I am certainly interested in any
technical experience you have; however, just because you know and have
shared some things you've learned about browser scripting, it doesn't
mean I'll take your unjustified declarations of what is bad as truth.
That would be unreasonable on my part.

Whatever. You said much the same thing during previous discussions
and eventually realized you were wrong. I don't have time to write a
book about this one issue. You've got enough to go on at this point.

 

[David Mark]

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-onh...>





Wouldn't it be possible to use hidden iframe to test hash setter
reloading a document? I'm not very happy with such solution, of course,
but it would most definitely be more reliable than sniffing (and might
detect similarly faulty browsers).

Creative, but the design isn't worth it.

On the other hand, one shouldn't really need to detect this behavior, as
  the faulty browser would simply degrade gracefully.

Not exactly.

 

[Peter Michaux]

I write mammoth scripts

How large is a "mammoth script"?

for a living (and
occasionally for the public) and am constantly and pleasantly
surprised when these beasts move cleanly from one agent (or
configuration) to the next (year after year.)

You never encounter any problems? *Never*?

That's what cross-
browser scripting is about. "It will work in the browsers where that
script has been tested" is a loser's mantra,

No. It is true.

If I test a script in a browser and see that it works there then I am
sure that script works in that browser. That is pretty clear.

If I don't test script in a particular browser then I don't know that
it works there. The *only* way to know for sure is to test it.

more appropriate for the
old-style multi-browser scripts. And for even modest sized scripts?
When did you become such a defeatist?



There are lots of other ways they could have improved your experience
in this area and remained competent. They chose not to and that is
their problem. Don't copy their blunder.

You have avoided stating what is wrong with the *design* of the Yahoo!
Maps page with regard to setting the URL hash.

How much can you analyze setting a property?

Are you implying the feature testing is completely possible? When did
you become such a defeatist? ;-)

Also all scripts are not destined for the general web. Some scripts
are used only on intranets and so feature testing is not necessarily
required or even desired.

And the end result is a
bad idea anyway.

Why do you find it offensive that the URL hash is changing as you
manipulate the state of a single page web-app? (I'm not asking about
modifying the history stack.)

Peter

 

[Peter Michaux]

On Jul 8, 12:32 pm, Peter Michaux <[email protected]> wrote:

No, because your example of Web developers writing to please
themselves is silly and I'm tired of going around in circles regarding
such nonsense.

It is common advice from successful companies of developers to write
applications that you would like to use yourself.

They are the odd man out there, aren't they? Finally a point. I
haven't looked at it, but off the top of my head:

1. Breaks older (but not ancient) browsers

Have you ever thought that by using new features that break a page in
older browsers, the number of user's might actually increase? I think
that is definitely the case.

2. Users YUI, so your loser anthem applies (works only in browsers
where it has been tested.)

The use of YUI in the implementation has nothing to do the quality of
the design.

BTW, how many of the billion or so configurations of IE do you test?
What about the others? Where do you find the time?

I'm not sure if these are rhetorical questions or not. I don't test
many configurations. I test in some configurations.

In another message you were implying your scripts work in browsers
where you do not test the scripts. These questions imply other scripts
cannot be known to work in a give browser without testing in the given
browser.

Peter

 

[David Mark]

Well there you go! Thanks for posting that link.

They are doing it for the same reason as QSA (which wasn't a good idea
either.) If enough people do something stupid, other people will
eventually feel the urge to accommodate them (often to make money, but
not always.)

 

[David Mark]

On Jul 8, 1:28 am, David Mark wrote:

[snip]

I've
mentioned this six times already.  The containing document would have
state preserved as cookies as the hash is obviously *taken*.

I think a cookie is a really awful way to preserve UI state.

Works great (and always has.)

I've
already mentioned why: can't bookmark or email it, can loose it by
clearing or loosing cookies, loose it by changing browsers, etc.

"Lose" I assume. And it is irrelevant that the user is allowed to
clear the states of some or all visited documents. Don't be a control
freak. Also irrelevant regarding email. I told you how to do that.
The only competition for your "send a link to this very thing" is the
file menu, which most users couldn't find with a map.

[snip]

 

[David Mark]

It is common advice from successful companies of developers to write
applications that you would like to use yourself.




Have you ever thought that by using new features that break a page in
older browsers, the number of user's might actually increase? I think
that is definitely the case.

As you well know, I do that all the time. It's called progressive
enhancement. That's what feature testing is for (and it's not
warranted here, even if a practical test could be found.)

The use of YUI in the implementation has nothing to do the quality of
the design.

It demonstrates that the design is strictly multi-browser, which is
yesterday's news now (thank God.)

I'm not sure if these are rhetorical questions or not. I don't test
many configurations. I test in some configurations.

That doesn't jibe with your theory about scripts working only where
they've been tested. How do you sleep at night?

In another message you were implying your scripts work in browsers
where you do not test the scripts.

It's an easily demonstrable fact.

These questions imply other scripts
cannot be known to work in a give browser without testing in the given
browser.

That was *your* implication (and I've heard it before from others,
usually advocates of browser sniffing.)