can.Component template attributes name case #512

Closed
whitecolor opened this Issue Oct 25, 2013 · 9 comments

Comments

Projects
None yet
3 participants
@whitecolor
Contributor

whitecolor commented Oct 25, 2013

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).

@whitecolor whitecolor referenced this issue Oct 25, 2013

Closed

can.camelize #513

@whitecolor

This comment has been minimized.

Show comment
Hide comment
@whitecolor

whitecolor Oct 29, 2013

Contributor

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

Contributor

whitecolor commented Oct 29, 2013

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

@imjoshdean

This comment has been minimized.

Show comment
Hide comment
@imjoshdean

imjoshdean Oct 29, 2013

Contributor

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).

Contributor

imjoshdean commented Oct 29, 2013

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).

@imjoshdean imjoshdean closed this Oct 29, 2013

@whitecolor

This comment has been minimized.

Show comment
Hide comment
@whitecolor

whitecolor Oct 29, 2013

Contributor

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?

Contributor

whitecolor commented Oct 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@imjoshdean

imjoshdean Oct 29, 2013

Contributor

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.

Contributor

imjoshdean commented Oct 29, 2013

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.

@whitecolor

This comment has been minimized.

Show comment
Hide comment
@whitecolor

whitecolor Oct 29, 2013

Contributor

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)

Contributor

whitecolor commented Oct 29, 2013

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

This comment has been minimized.

Show comment
Hide comment
@imjoshdean

imjoshdean Oct 29, 2013

Contributor

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.

Contributor

imjoshdean commented Oct 29, 2013

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.

@imjoshdean imjoshdean reopened this Oct 29, 2013

@whitecolor

This comment has been minimized.

Show comment
Hide comment
@whitecolor

whitecolor Oct 29, 2013

Contributor

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

Contributor

whitecolor commented Oct 29, 2013

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

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Oct 29, 2013

Contributor

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.

Contributor

justinbmeyer commented Oct 29, 2013

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.

@ghost ghost assigned imjoshdean Oct 30, 2013

@imjoshdean

This comment has been minimized.

Show comment
Hide comment
@imjoshdean

imjoshdean Oct 30, 2013

Contributor

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.

Contributor

imjoshdean commented Oct 30, 2013

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.

imjoshdean added a commit that referenced this issue Oct 30, 2013

Merge pull request #520 from bitovi/512-camelCaseComponent
Fixes #512 #513, sees the glorious return of can.camelize and his trusty sidekick, can.hyphenate
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment