Comments (37)
Looking forward to this one - this might be something people should be made aware when using this in conjunction with rewritten URLs though
from history.js.
Will be in v1.6.1.
from history.js.
Would you be forcing the paths to be relative to something in particular i.e. the document loaded and can we still use absolute paths? I thought I'd ask at this point before it gets published
from history.js.
Correct.
The long url:
http://localhost/products/history.js/demo/#/products/history.js/demo/?state=2
Will be shortened to:
http://localhost/products/history.js/demo/#./?state=2
However the long url:
http://localhost/products/history.js/demo/#/pages/about
Cannot be shortened further.
So only hashes which are relative to the parent document location will be shortened further by using a relative path.
from history.js.
Excellent -- I was also hoping for this! Thanks for all the hard work on this library. If it perfectly matches, can it end up with nothing after the hashtag?
For instance, the long URL:
http://localhost/products/history.js/demo/#/products/history.js/demo/
shortened to:
http://localhost/products/history.js/demo/#
from history.js.
This has been added to dev.
from history.js.
v1.7 is now out which resolves this issue :)
from history.js.
Hey guys. Opening this back up for some discussion.
In v1.7 url structure is like so: (option 1)
I'm considering changing it to: (option 2)
Or: (option 3)
Thoughts? As currently in v1.7 the sudden removal of ./
when traversing states from ./bbb
to bbb/ccc
could potentially be confusing in terms of url hierarchy for unfamiliar users. All feedback is appreciated. Option 3 is the most consistent.
The reason for the ./
in the first place is because #bbb
could be a traditional anchor to an element on the page.
from history.js.
+1 for option 3 – as you say, it's the most consistent.
from history.js.
+1 for option 3
and +1 for just /#/ if user starts from homepage :-)
from history.js.
+1 for option 3
from history.js.
I agree a consistent format is nice (option 3). One other thing I would like to see is, if you have a URL like:
http://mysite.com/aaa/filename.html
It will appear in the location bar as:
http://mysite.com/aaa/filename.html#./filename.html
Since it is finding the base directory /aaa/ and then going from there. Is there any chance that if the filename is exactly the same as used in the URL, it just uses an empty hashtag (or something much shorter)? Not being familiar enough with the codebase, that may be a very difficult request, in which case nevermind.
Matt
from history.js.
Thanks everyone for your feedback. I'll make the change to option 3 in the next release :)
@mattwright The issue with having an empty hashtag is that it is ambiguous on whether or not it is a traditional anchor or a state hash. So unfortunately that won't be possible.
from history.js.
Is there any reason why you can't have all those options?
balupton [email protected] wrote:
Thanks everyone for your feedback. I'll make the change to option 3 in the next release :)
@mattwright The issue with having an empty hashtag is that it is ambiguous on whether or not it is a traditional anchor or a state hash. So unfortunately that won't be possible.
Reply to this email directly or view it on GitHub:
#28 (comment)
from history.js.
ok, thanks! I just realized all I need to do is add a trailing slash and it should be closer to what I want...
from history.js.
@marksyzm "Is there any reason why you can't have all those options?"
;-)
In regards to software:
http://gettingreal.37signals.com/ch05_It_Just_Doesnt_Matter.php
http://gettingreal.37signals.com/ch05_Start_With_No.php
http://webappsatwork.blogspot.com/2009/07/system-feature-death-spiral.html
Apple and 37Signals follow this religiously.
In regards to life:
This isn't just applicable to programming but applicable with life too. Ever tried buying an after-shave? Do you want the re-vitalise or the re-energise, or the one with Q10 or the one without, or ... - honestly I would prefer it if there was just one after-shave, no frills, straight to the point like the way of the Gillete Fusion Brand - one way, it works. Nivia gives me a big headache and makes me spend an hour reading the packaging finding out which is "better", leaving me with whichever one I chose it isn't the right one - when really in the end, it just doesn't matter.
http://www.ted.com/talks/dan_gilbert_asks_why_are_we_happy.html
http://www.youtube.com/watch?v=YYOAslBbURI - "too many options may kill a man"
from history.js.
Why don't we just use #!path. The "!" would suggest it's not a normal hashtag plus it is recognisable by google and it's kind of an undocumented standart. So there's no need for "./".
I really like your lib, and I'm looking forward to using it.
from history.js.
Don't start us on that topic... the gist of that is it will be deprecated in a couple of years due to HTML5 history already existing and it's not even that great for seo. It's basically unnecessary.
stormbreakerbg [email protected] wrote:
Why don't we just use #!path. The "!" would suggest it's not a normal hashtag plus it is recognisable by google and it's kind of an undocumented standart. So there's no need for "./".
I really like your lib, and I'm looking forward to using it.
Reply to this email directly or view it on GitHub:
#28 (comment)
from history.js.
It's just that you stated "The reason for the ./ in the first place is because #bbb could be a traditional anchor to an element on the page." and that makes it clear. I don't see what's wrong about using a special character and what's the difference between "#!", "#$", "#%", "#./" or any other that you can choose.
from history.js.
On 28/04/2011 13:48, stormbreakerbg wrote:
It's just that you stated "The reason for the ./ in the first place is because #bbb could be a traditional anchor to an element on the page." and that makes it clear. I don't see what's wrong about using a special character and what's the difference between "#!", "#$", "#%", "#./" or any other that you can choose.
#./ isn't a special character in it's essence though - it's just the
usual nature for linux based directory pathing for current directory?
The point of having those options is merely so you can have absolute and
relative paths
from history.js.
Marksyzm hit it right on, the ./ and / refer to the UNIX standard for relative and absolute file system paths. The hashbang #! refers to the google recommendation for breaking the web by the use of escaped fragments, duplicate state locations, and google only SEO.
from history.js.
Yeah I'm kind of scratching my head wondering why this plugin doesn't use #! which could make it google compatible. I only noticed this bit of wonkyness when I was debugging some IE issues. I'd just sort of assumed it did the "right" thing.
from history.js.
@drewish, for more info on the #! problems - https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
from history.js.
My though is that the history API handles modern browsers so all I need to do is have #! work for IE and old browsers until they die off.
I'm aware of and prepared to work around the issues you identified—I wish I'd seen that list before I had to figure them out myself ;). I hadn't started on the the server side URL rewriting for the escaped_fragment but built a custom ajax page callback to render just the changed portion of the page and pass it back along with meta info like page title and new JS and CSS. In both the full page and partial page callbacks I'm sending back full links that would work for non-JS browsers, the browser rewrites the links to point to the ajax callback.
So given all that what do you think the cleanest way to fork/customize your code to support #! would be?
from history.js.
You can't rewrite hashed URLs on any apache server - it is never read in the request URI as it is regarded by web servers as a comment
drewish [email protected] wrote:
My though is that the history API handles modern browsers so all I need to do is have #! work for IE and old browsers until they die off.
I'm aware of and prepared to work around the issues you identified—I wish I'd seen that list before I had to figure them out myself ;). I hadn't started on the the server side URL rewriting for the escaped_fragment but built a custom ajax page callback to render just the changed portion of the page and pass it back along with meta info like page title and new JS and CSS. In both the full page and partial page callbacks I'm sending back full links that would work for non-JS browsers, the browser rewrites the links to point to the ajax callback.
So given all that what do you think the cleanest way to fork/customize your code to support #! would be?
Reply to this email directly or view it on GitHub:
#28 (comment)
from history.js.
You misunderstood what I was saying. I'm only concerned about rewriting Google's escaped_fragment version of my path back into the proper path that the server expects.
from history.js.
On 21/05/2011 19:12, drewish wrote:
You misunderstood what I was saying. I'm only concerned about rewriting Google's escaped_fragment version of my path back into the proper path that the server expects.
What would you expect an escaped fragment to look like then? (URI please)
from history.js.
@drewish the HTML5 History API deprecates the hashbang. With the HTML5 History API it requires absolutely no effort to achieve SEO, as the HTML5 History API URLs point to traditional urls, traditional urls as in those indexable by ANY search engine. If you are not wanting to use the HTML5 History API with traditional urls, then you should not be using the HTML5 History API. History.js will never support the hashbang, as it does not make any sense, and if you do try, it will kill your SEO in google - as suddenly there are two indexable urls for google (the traditional, and the hashbanged one). Please direct any hashbang queries elsewhere to projects which do not use the HTML5 History API.
from history.js.
I'm either doing a very poor job of explaining myself, or I'm completely misunderstanding something. In either case I appreciate your patience.
I agree that HTML5's history API works great and has no-SEO concerns. It's older browsers and all versions of IE that's I'm not sure how to deal with. My understanding was that Google would let you use the hashbang paths along side clean URLs and that you could use the canonical link to avoid the duplicate content penalty. Based on the comments here and re-reading their docs (http://code.google.com/web/ajaxcrawling/docs/faq.html#linkrelcanonical) I'm less certain this will work.
What's unclear to me now is how you'd avoid loosing all the search value of people using IE who copy paste the hashed link into a link on their site or Facebook. Google won't recognize that as the same as the clean URL, will it? Is there any way to deal with that?
from history.js.
That's a very good point... I'm even less impressed about Google doing that now.
drewish [email protected] wrote:
I'm either doing a very poor job of explaining myself, or I'm completely misunderstanding something. In either case I appreciate your patience.
I agree that HTML5's history API works great and has no-SEO concerns. It's older browsers and all versions of IE that's I'm not sure how to deal with. My understanding was that Google would let you use the hashbang paths along side clean URLs and that you could use the canonical link to avoid the duplicate content penalty. Based on the comments here and re-reading their docs (http://code.google.com/web/ajaxcrawling/docs/faq.html#linkrelcanonical) I'm less certain this will work.
What's unclear to me now is how you'd avoid loosing all the search value of people using IE who copy paste the hashed link into a link on their site or Facebook. Google won't recognize that as the same as the clean URL will it? Is there any way to deal with that?
Reply to this email directly or view it on GitHub:
#28 (comment)
from history.js.
Google won't recognize that as the same as the clean URL will it? Is there any way to deal with that?
Correct, when a user posts a link that contains a hash, it won't (or is extremely unlikely) that it will be recognised by search engines. The only solution to this is to disable html4 support in history.js so hashed are not used. Another solution would be to ensure the user copies the permalink instead of the URL.
from history.js.
You could do that by changing the content the user copies with JavaScript when they right click and copy a URL perhaps.
balupton [email protected] wrote:
Google won't recognize that as the same as the clean URL will it? Is there any way to deal with that?
Correct, when a user posts a link that contains a hash, it won't (or is extremely unlikely) that it will be recognised by search engines. The only solution to this is to disable html4 support in history.js so hashed are not used. Another solution would be to ensure the user copies the permalink instead of the URL.
Reply to this email directly or view it on GitHub:
#28 (comment)
from history.js.
You could do that by changing the content the user copies with JavaScript when they right click and copy a URL perhaps.
Well by default the a.href should link to traditional url, the issue is with copying the url from the url bar.
from history.js.
Could you tell me if possibility to turn it off exists? I rewrite URL if it contain hash and more than domain address before... and I can't rewrite it correctly if there is not full link.
e.g. I turned http://example.pl/Main/Home#Main/AboutMe to http://example.pl/#Main/AboutMe by reloading a page.
from history.js.
@rzepcio not sure what you mean, or why turning it off would solve the problem... can you elaborate further?
from history.js.
Well, I have already worked around this problem (by doing the same as you do but in different direction) but here you go. I don't like solution with shortened links, because it still can have redundant data, so I reload the page and load the shortest possible version of link like I wrote earlier:
http://example.pl/Main/Home#Main/AboutMe to http://example.pl/#Main/AboutMe
or from your shortened version:
http://example.pl/Main/Home#./AboutMe to http://example.pl/#Main/AboutMe
Problem was that I need to turn that "." to "Main" again to have full address which I should load.
$(document).ready(function () {
_hash = window.location.hash;
if ((_hash.length > 0)) {
_hash = _hash.replace('.', '').replace('#', '');
var _link = _hash;
History.pushState(null, null, _link);
load(_link);
}
});
With the code above I reload site if it contains hash, it works for two actions:
- load page which has hash e.g. passing http://example.pl/#Main/AboutMe to browser works well
- load page after reloading if it contains in main address something more than domain e.g. http://example.pl/Main/Home#./AboutMe
For second case I use code in statechange:
if ((_hash.length > 0) && (window.location.pathname.length > 1)) {
var _hashSplitted = _hash.split('/');
var _pathSplitted = window.location.pathname.split('/');
if (_hashSplitted[0] === '#.') {
_hash = '#/' + _pathSplitted[1];
for (var i = 1; i < _hashSplitted.length; i++) {
_hash += '/' + _hashSplitted[i];
}
}
window.location = window.location.protocol + '//' + window.location.host + '/' + _hash;
return;
}
from history.js.
Google won't recognize that as the same as the clean URL will it? Is there any way to deal with that?Correct, when a user posts a link that contains a hash, it won't (or is extremely unlikely) that it will be recognised by search engines. The only solution to this is to disable html4 support in history.js so hashed are not used. Another solution would be to ensure the user copies the permalink instead of the URL.
And what do you think about hashbang + _escaped_fragment= that redirects with a 301 status code to the html5 version of the URL? Would it be the perfect solution for SEO?
from history.js.
Related Issues (20)
- Few test cases are failing on X86. Saying "operation insecure"
- How to use History API State with hash urls?
- IE/Edge pop last saved object irrespective of current URL
- change url cross domain
- native.history.js detected as virus HOT 1
- No default jsDelivr CDN file set
- jquery.history.js breaks the script adn return "History.js Adapter has already been loaded..." error.
- replaceState removes first character of hash (#) when it contains dot "."
- indicating locale code to url
- Problems with webpack encore at page loading
- The Solutions section is missing the hashtag solution
- Change domain "mysite.com/page1" to "mysite.com"
- npm WARN deprecated: Update deprecated dependencies HOT 1
- history.goback() is not working for mozilla firefox
- page is not jump used push HOT 1
- OnPopState calls in case of section change
- Back Button Error while using with VueJs Data
- Revise tests
- How to unbind function from History.Adapter.bind? HOT 1
- security scan result HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from history.js.