It seems like to be the url is not match so the isActive property(option.active) is not set. Then the "font-weight: 600" is not applied properly.

So what do you think the following solutions? @mportiz08

1. We simply make the compare in the vue file to ignore the case so that it will set the isActive properly

2. We redirect all path into lower-case one, so anyone try to access http://localhost:8000/tutorials/slothcreator/CREATING-CUSTOM-SLOTHS or http://localhost:8000/tutorials/slothcreator/CREATING-custom-SLOTHS will be redirected into http://localhost:8000/tutorials/ slothcreator /creating-custom-sloths

@Kyle-Ye I think the first option of making a case insensitive comparison would be preferable to redirecting and enforcing a specific case style in the URL.

The bold issue could easily be fixed by changing some compare from `this.currentOption === section.title` to `this.currentOption.toLowerCase() === section.title.toLowerCase`, but it comes with more issues.
Like if I navigate to `http://localhost:8080/tutorials/slothcreator/creating-custom-slothS` now it can render the bold properly after applying the first fix, but click the navigation bar did nothing, because the URL change to something like this `http://localhost:8080/tutorials/slothcreator/creating-custom-slothS#Add-a-customization-view` which can't be routed.
I think we change the routing rule to redirect the url to a lower_case style is more acceptable and consist with whole design. (Because the "Creating Custom Sloths" was transformed into "creating_custom_sloths" internally) @mportiz08

/src/utils/string.js

export function anchorize(str) {
  return str
    .trim()
    .replace(NON_URL_CHARS_RE, '-')
    .replace(INITIAL_DASH_RE, '')
    .toLowerCase();
}

[Update]: This nav issue seems to be a bug under mobile mode(Which use MobileDropdown.vue internally), irrelevant to this issue. After your confirm we can open a new SR for it.

And I'll make a case-insensitive compare PR to fix the origin issue

Ah, I think I see the new issue you found (which is likely more of an issue than this one). It seems that we're generating the URLs in the mobile dropdown by utilizing the current route URL instead of just directly using the URL provided in the `references` data from the JSON. By relying on the JSON data, we should be able to better control these URLs since they will always be generated in the same way by DocC as opposed to the browser URL where the case can be changed by the user.

I think it would be preferable to avoid using the `anchorize` utility function unless absolutely necessary, because ultimately we want these paths and URLs to be driven by exactly what the compiler is providing. There may be cases where we need to use it to create an anchor/fragment value, but hopefully in most places where that is needed, these values will be provided already by DocC.

As you mentioned, we can still do a case insensitive comparison, but it should be a pretty uncommon situation for end users to hit once we are relying on the JSON data for URLs more completely.

Pull Request in #11