prop: naming inconsistencies

[slimsag]

Creating this as an issue and not a PR because I'm not sure we should do anything about it..

We might consider renaming these to match the elem and style naming schemes (of not using short-hand versions or acronyms):

1. prop.Href -> prop.HypertextReference
2. prop.Id -> prop.Identity
3. prop.Src -> prop.Source

The first two are by far much less digestible to me as an end-user.

[dmitshur]

How does the recent Element -> Elem and Property -> Prop change tie in here?

I might be missing contedxt, but Href, Id are much more readable to me (being familiar with HTML lingo) than HypertextReference and Identity... Unless they're supposed to represent something else?

[slimsag]

For example, we rename the <h1> tag to become elem.Header1 here: https://github.com/gopherjs/vecty/blob/master/elem/generate.go#L34

I agree that Href and Id are more readable.. and that makes me uncertain of the naming scheme/remapping used by the elem event and style packages.

[neelance]

Rob Pike: Length is not a virtue in a name; clarity of expression is.

For example Header1 instead of H1 conveys a lot more information. But what the heck does a HypertextReference do? ;-) I think href is so common, everyone knows it.
However, it might be good to stay consistent, at least inside of each package. I opted for longer element names because the acronyms of HTML tags are really bad and some of them already have longer class names in the DOM API. Properties and styles however already have proper names in the DOM API, so I think we should keep them.

[bep]

Go's vet tool will complain about Id and suggest ID, at least in vars like elementID.

[slimsag]

@neelance thanks for clearing this up :) I think what you said makes sense, and from creating this issue that is exactly what I wanted to find out: what exactly is the name remapping pattern? I think you answered that clearly and I'm happy with it 👍

@neelance @bep maybe we should Id -> ID and Href -> HRef ?

[bep]

I watch this repo with interest as this is something I need and want, so I have no strong meaning about this. But getting the names right before people start using it saves a lot of trouble in the long run. I did a major naming cleanup of the API of Hugo a couple of months ago ... A lot of work with all the themes etc ...

[dmitshur]

Id -> ID

Definitely. Consider honnef.co/go/js/dom a good example (/cc @dominikh). It has GetElementByID not getElementById.

About Href, I'm unsure that HRef is better. I consider "href" to be one weird word. Also see https://godoc.org/honnef.co/go/js/dom#HTMLLinkElement.Href.

[slimsag]

About Href, I'm unsure that HRef is better. I consider "href" to be one weird word. Also see https://godoc.org/honnef.co/go/js/dom#HTMLLinkElement.Href.

FWIW I agree with your stance and think that Href reads better than HRef. But, we're being inconsistent, because href does stand for Hypertext Reference (two words), so... maybe we can blame HTML naming horror 😱

[neelance]

I also consider Href as a weird word, same as @shurcooL.

[dominikh]

Generally speaking, I'm 👍 for ID and Href. Yes, Href technically stands for two words. However, ID technically stands for one word, yet is treated like an acronym. We have some freedom in mangling names ;)

[slimsag]

Sounds like we all agree to go with ID and Href, I've created #32 to switch to ID. PTAL.