Hello - Not sure if this has been discussed before but it would be great to specify my own casing for custom variables defined in frontmatter. This will help with readability. The documentation states “All Params are only accessible using all lowercase characters.” http://gohugo.io/templates/variables/.
Consider I have a variable called
mycustomfrontmattervariable. This would be much easier to read as
myCustomFrontmatterVariable. I think I should be able to use the same casing that hugo uses for consistency too. Eg:
I agree, I think Hugo should keep the capitalisation as specified by the user in the front matter.
If the user deliberately named his category
MyCustomCategory, then I think Hugo should assume the reader had a good reason to do so and keep the capitalisation intact.
Personally, all my categories are ‘product’ names, and with those the capitalisation matters. For instance,
.NET, and so on all need to be capitalised by convention.
Should hugo treat the tags “Docker” and “docker” as two different tags? I think the answer here should be no. This seems very odd to me that tags would be case sensitive.
If no, then how does Hugo know which one is the preferred display?
Perhaps Hugo could have a map in the configuration that takes a key and maps it to a preferred display format, but I’d prefer less configuration and more intelligent behavior.
I think it should be case sensitive. It’s case sensitive in everything else I program (java, js, php, css, python, c#, etc). I think html requires an uppercase opening
<P> tag to close an uppercase
</P> tag as well. It’s pretty standard behavior.
In the case of
docker, if it’s case sensitive then you no longer have to worry about which one is the preferred way to display.
If you must lowercase the string then I think camelCase is the best thing to do because lowercasing
dockercontainer seems like a bad idea because no one is accustomed to doing this. This would be a weird thing that ONLY happens in hugo and nothing else a programmer uses.
However, I agree with less configuration thus using strict case is best. If a user writes
DockerContainer in the config then they are likely to try and use it as
DockerContainer. That’s what I tried to do and then it didn’t work and I struggled googling the answer.
If you really want to be flexible then I think the second best idea is to be case-insenstive.
DockerContainer can then be written as
dockercontainer or however they want and always resolved the definition of
DockerContainer but it sounds like a nightmare to implement IMO.
It would be nice to clear up what term we are discussing.
I see facematter variables …? What is that? Then the discussion goes on into Taxonomies … Confused.
Agree with the confusion. I was responding to taxonomies only.
I think facematter == frontmatter.
HTML is totally case insensitive. So is css. Modern languages are primarily case sensitive when it comes to variable names, but many aren’t for method / function names.
I think the intent here was to normalize all variables to be stored in a case insensitive manner (all lowercase) so they could be both stored and retrieved without respect to case.
Sorry for the confusion. Facematter = Frontmatter hahaha! It’s a new term for me.
I support the idea of retrieving the variables in a case insensitive manner. +1
I ran into this a while back too…
I use a 3-letter uppercase prefix on all my user vars in most projects [not just Hugo ones] I work on, to make it easy for me to see later what was boilerplate and what was added by me.
…and being a ‘documentation skimmer’] only found out why my frontmatter vars weren’t behaving, by trial and error.
Since some folks want case sensitivity and some don’t, maybe the convention used by a lot of text editors in their Find/Replace function would keep everyone happy:
- If the variable name is defined as all lowercase, assume case insensitivity and treat
VARNAME the same elsewhere in the code.
- If the variable name is defined in upper or mixed case, assume it’s been done that way for a reason and assume case sensitivity elsewhere in the code.
I ran into this today. It took me a while to figure out, what’s wrong, because I used camelCase in the config.yaml for global params (works) but my camelCase page params are converted to lowercase (I just forgot about that part of the docs).
That’s not very intuitive behavior, at least for me.
@rsumilang I agree that
myCustomFrontmatterVariable is easier to read than
mycustomfrontmattervariable. I would also argue that
my_custom_front_matter_variable is the easiest to read of all three. I believe this is still considered valid yaml and shouldn’t cause errors in your yaml config file, no @spf13?
Maybe the confusion is just between the page and site level params? Ie, a matter of consistency rather than one being better than the other…