Adding docs for non-working uppercase characters when using '=variable' ...

[farolfo]

...in isolation of scope in directives

[farolfo]

If you think this is an issue in angular please tell and I'll open the proper issue ;)

[caitp]

I don't really understand where you're seeing this issue, can you demonstrate it?

plunk I made real quick which uses a camelcased name and works fine

---

I think I see what you're saying, you mean issuing the attribute as fooBar instead of foo-bar doesn't work?

[caitp]

In your update, you didn't change the first two instances of the directive to classes. Fixing that makes it behave identical to the original plunk (http://plnkr.co/edit/D1x2L2?p=preview)

Caitlin Potter
snowball@defpixel.com

On 2013-10-30, at 5:47 PM, Franco Arolfo notifications@github.com wrote:

I'm using restrict: 'C', just also noticed that it's not a best practice.

Also changed restrict A to C in the plunk and the attrs to classes and stopped working.
http://plnkr.co/edit/FJfTm1?p=preview

—
Reply to this email directly or view it on GitHub.

[farolfo]

You wrote:

These won't work --- apparently only snake-cased forms for these attributes work. I'm not really sure if this is a "problem" or not, it seems like it's perfectly fine.

<div test2 itemId="id"></div>
<div test itemId="idTwo"></div>

Right ! what do you mean with 'snake-cased forms for these attributes'? To me a common developer will use camel case in the attr's names and will have a friction point here. To me camelCase should be supported.
If not at least documented ;)

[farolfo]

BTW sorry for the update, my mistake. That was not my point so I deleted that message

[caitp]

I'm not sure it's really a suggested thing to use camelCased attribute names for HTMLElements (or SVGElements or what have you), it is likely that the only reason you can use a directive's camelCased name is because directiveNormalize() would have no effect on it, but otherwise those probably wouldn't work either.

So yeah, I dunno if this is something which really needs to be fixed. I think in general it's encouraged to use snake-cased attributes prefixed with data- for nonstandard attributes.

[farolfo]

I agreed in that snake-cased attributes are very common, data-something-non-stnadar is very common.
But the use of camelCased is not prohibit in attributes' names. So a developer may want to use it in a directive binding attribute, and would have this issue that I had today.
To me is a good thing to make camelCase (or any upper case character) availalbe for this functionality.
I have some friends that had the same issue.

And if angular will still be without it, at least to have it documented ;)

[petebacondarwin]

HTML attributes are case-insensitive, so camelCase is parsed equal to camelcase and CAMELCASE and so on. So it is not possible to use capital letters to delineate word boundaries. Therefore most HTML uses snake-case attributes where the name should be broken into words.

JavaScript is not keen on snake-cased identifiers (you have to use ["strings-in-square-brackets"] and so in most JavaScript programmers use camelCased names.

This is all outside of the scope of AngularJS. To fit with these issues and conventions AngularJS expects that all uses of directives in HTML do not use capital letters and that all uses of directives in JavaScript are "normalized" to camelCase.

It is fair to make a note of this in the directives guide but I don't think the current wording is ideal.

[farolfo]

Fair to me, do you want to re write it or you have a docs team to throw the issue ? I don't know what is the 'protocol' to follow here hehe

As note I liked all that that AngularJS is out of the scope of all that capital letter issues, and so expect the user in HTML not to use capital letters.

Also I'd like to mention that I'd like AngularJS to work with '=aVariableInCamelCase' in a directive's scope, and this could be done by matching to the attr with that name, IT DOESN'T MATTER THE CAPITAL LETTERS;

[petebacondarwin]

@farolfo - can you explain more what you mean by:

Also I'd like to mention that I'd like AngularJS to work with '=aVariableInCamelCase' in a directive's scope, and this could be done by matching to the attr with that name, IT DOESN'T MATTER THE CAPITAL LETTERS;

This paragraph doesn't make sense to me. Inside the JavaScript the capital letters are definitely important and you do indeed use camelCase when defining the scope.

[farolfo]

may be it's a bit incomplete haha
I mean this: If we have

<directive aVariableInCamelCase="itsValue"></directive>

and in the directive code...

scope: {
   aVariable: "=aVariableInCamelCase"
}

this doesn't work (is what this issue is about hehe).

What we can do to fix this, cause capital letters are important in JS but NOT in HTML, is to match the attr name in the HTML with the attr name mentioned in value of the 'scope' JSON field, BUT IGNORING THE CAPITAL LETTERS. Does it make sense?

My goal here is to have that scenario working cause it's a scenario that a regular developer might use.

If you still don't see my point let me know and I'll try to explain it with code ;)

[farolfo]

farolfo@9dd68d7
this is what I meant (this is commented and didn't test it)

[petebacondarwin]

The bottom line is that HTML is case insensitive and so you should not be using capital letters in your attributes. So your HTML must look like:

<directive a-variable-in-camel-case="itsValue"></directive>

or similar. This is a well defined idiom in AngularJS. Perhaps you could identify further places in the documentation that could be improved to make this clearer.

[farolfo]

Ok I'll take a look, for now this is the only place I had troubles with this.
Does my code commit will be on angular docs ? I'm very anxious if so haha

[petebacondarwin]

Added a note in this guide about this at 8f1e360. @farolfo if you have further ideas then please open a new PR.
Thanks

[farolfo]

awesome ! I'll do ;) Thanks !