Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trialLiam Maclachlan
22,805 PointsCan anyone explain why this statment is written in this fashion?
I am working with some pre-written code and am wondering why
if (location.pathname.replace(/^\//,'') == this.pathname.replace(/^\//,''))
can't be written like this
if (location.pathname == this.pathname)
Any ideas why the extra regular expression in .replace(/^\//,'') is needed?
3 Answers
Daniel Newman
Courses Plus Student 10,715 PointsSomeone decided to share Best Answer option here?
$('a').each(function(){
if( this.pathname[0] !== "/" ) {
console.log( this.pathname );
}
});
On main forum page returned email help@teamtreehouse.com. I've started investigation and found this link saying:
The odd thing about this behavior is that window.location.pathname returns the leading
slash (after the hostname) in all versions of IE, same as all other browsers.
It is only the location object of a hyperlink ('a element') that returns the path without
the slash in IE (and Opera as well).
So, regexp in code about compatibility! Question solved! Have a nice weekend, guys.
Marcus Parsons
15,719 PointsHi Liam,
I recognize that code from CSS Tricks, which is an awesome site that I love myself! All that regular expression does is remove the very beginning / from the path name. I've messed around with that smooth scroll code and couldn't replicate a scenario where it would be necessary to remove the leading / from the path name because the hash links' pathname will always match up with the location pathname.
Liam Maclachlan
22,805 PointsHello again, man. Fancy seeing you here. Haha. That is what I was thinking. It seemed ridiculous to remove the same character on both examples, unless there is a scenario where the leading '/' doesn't appear in one. Think that is possible?
Marcus Parsons
15,719 PointsHahaha howdy stranger! :D
I couldn't set up a scenario where the pathname's wouldn't match. I set up some links and removed that regular expression. Here's a couple links I set up and tested:
<a href="#top">An inside link 1</a>
<a href="test.html#top">An inside link 2</a>
where test.html
was the page I was testing the links on. The pathnames were matching for those regardless of whether that beginning / character was there or not. Most of the time, CSS Tricks gives out great information about the code they post, but this is definitely not one of those times lol.
Liam Maclachlan
22,805 PointsI thought that thread was worth pulling at. You know, when something just doesn't sit right? It was staring at me and needed to be corrected >.>
Anyway! Thanks again man. Much appreciate :p
Marcus Parsons
15,719 PointsThis is one of those times where I would hope someone would come along and provide a scenario where you would need to remove that beginning / character lol If they provide a valid example, you gotta switch the best answer over to them lol :D I really don't mind it. And hey I do what I do man, and that's all I can do haha
Liam Maclachlan
22,805 PointsI actually tried to add a forward slash to the beggining of the id selector in the HTML....funnily enough, it did not work!
Code edited....bytes have been saved =p
Marcus Parsons
15,719 PointsYou saved teh bytes!!! You're a god amongst men, Liam! :D
Daniel Newman
Courses Plus Student 10,715 PointsWelcome to the Opera and IE world. Answer is below.
Daniel Newman
Courses Plus Student 10,715 PointsThe good question will be: "how it possible that location.pathname is not equal to this.pathname"?
To answer your question it will be great to share your code with some tools like treehouse's workspace or codepen or jsfiddle tool. It's not possible to know without whole enviroment what "this" is. All regexp you have is doing remove first trailing slash.
Equation meaning with regexp: "whenever it has trailing slash we will compare them without it".
Liam Maclachlan
22,805 PointsYou can simply ask for the code, man.
$(function() {
$('a[href*=#]:not([href=#])').click(function() {
if (location.pathname.replace(/^\//,'') == this.pathname.replace(/^\//,'') && location.hostname == this.hostname) {
var target = $(this.hash);
target = target.length ? target : $('[name=' + this.hash.slice(1) +']');
if (target.length) {
$('html,body').animate({
scrollTop: target.offset().top
}, 1000);
return false;
}
}
});
});
Marcus Parsons
15,719 PointsMarcus Parsons
15,719 PointsGood one, Daniel! Good catch! Liam, I stand by what I say, and so the best answer should go to Daniel :)
Liam Maclachlan
22,805 PointsLiam Maclachlan
22,805 PointsDon't know if that gives me an answer, though. I get this may be answering the question but it is still not clear in my head why this is happening.
It's checking the location in the browser, which should return the same result, right? Either, both results will return a leading '/', using both 'this.pathname' and 'location.pathname'.
Or is this saying that 'location.pathname' may return the leading slash (in some browsers) and 'this.pathname' will not?
EDIT: Ooh!! Just read the second answer down on stackoverflow. Said the same thing but just made more sense. If it is in the Anchor tag, it won't return a forward slash but pathname will do in certain browser. Get it now. Thanks guys :)
P.S: Dan. You gave some great answers but try not to upvote your own answers before people have a chance to check them out. That can really get people off on the wrong foot. Just a friendly heads up on forum etiquette, man.