can.Component template attributes name case

[wclr]

It seems not possible to pass camel cased attributes to child's scope:
someAttribute will be converted to lower case.

and some-attribute is not converted to camel case. Though it seems to be a common need, not always properties in child scope is simple words (or moreover dash separated).

[wclr]

Any comments on this? Maybe it should arrive in 2.0.1 if applicable.

[imjoshdean]

The spec for attributes in HTML5 is that they have at least one character after the hyphen, is XML-compatible, and contains no uppercase ASCII letters. In addition, all attribute names get automatically ASCII-lower cased.

I'm going to have to say this is a Won't Fix, in my opinion, because this is the intended behavior of the browser. Check out http://canjs.com/can/component/examples/paginate.html for an example of what we do with camelCase: (Ctrl + F + deferreddata).

[wclr]

Well I don't get your point.

In template you type deferredData as attribute name (which is not compliant with HTML5 scpec), while component's init it is converted to deferreddata for scope attribute name which is a bad name for JS attribute/property, camel cased deferredData is good.

Why not do

<grid deferred-data="websitesDeferred"> ....</grid>

and then while component init convert it to camel cased scope's attribute name deferredData?

[imjoshdean]

The point is that the browser will automatically convert attributes to lower case for you.

You certainly COULD do

<grid deferred-data="websitesDeferred"> ....</grid>

and update the grid's can.Compontent internals to look like

...
    "{deferred-data} change": "update",
    update: function () {
      var deferred = this.scope.attr('deferred-data'),
...

and it would work just fine.

[wclr]

Yes, I understand about attribute case in HTML. That was not the point of my original post.

I'm talking about that in this case "deferred-data" and deferreddata are both bad names for scopes attribute. defferredData is good. And such cases are not rare when you have to provide complex attribute name (for scope)

I think it is quite logical convention about the way of converting HTML attribute names to JS attribute names (and vice versa).

deferred-data (HTML) <--> deferredData (JS)

[imjoshdean]

That's fair. As someone just pointed out to me the HTML spec has hyphened elements converted to camel case on the JavaScript side.

I'll reopen.

[wclr]

Great, interesting what HTML spec says about converting colon (:) in HTML attribute on JS side.

[justinbmeyer]

Yes, we should camel case hyphenated attrs.

Sent from my iPhone

On Oct 29, 2013, at 4:00 PM, Alex Osh notifications@github.com wrote:

Great, interesting what HTML spec says about converting colon (:) in HTML attribute on JS side.

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

[imjoshdean]

I approached this two ways: first I considered treating can.Map the same way as $.prototype.data so you could do something along the lines of:

var x = new can.Map({'foo-bar': true})
x.attr('foo-bar') // true
x.attr('fooBar') // true
x.attr('fooBar', false)
x.attr('foo-bar') // false
x.attr('foo-bar', true)

which solved the problem pretty quickly; however @dispatchrabbi convinced me that this would probably do more harm than good. So I scrapped it, and chalked it up to "it seemed like a good idea at the time."

The second way, which I am finishing testing, is a lot less intrusive and will only effect can.Component. It just auto camelCases all hyphenated attributes.

Expect this, accompanied by a test for it, in 2.0.1.