Should automatic node finding convert id names with dashes?

[derek-pavao]

When mapping attribute names to property names, Polymer will convert the attribute some-cool-attr to someCoolAttr when assigning the property.

However, when using automatic node finding if the id has a dash in it Polymer does nothing. I understand these are two different things, but its not how I expected it to work. I was expecting more like

<template>
    <div id="cool-div"></div>
</template

to be referenced

Polymer({
   // ... polymer code
    ready: function () {
        // I expected the following
        this.$.coolDiv;
        // but instead I would have to do the following
        this.$['cool-div'];
    }
});

Have there already been discussions around this sort of thing I'm not aware of? Should I just suck it up and name my ids as camelCase?

Unfortunately this would be a breaking change of course.

[zishanj]

+1 for this enhancement

[jklein24]

+1. It would be nice to lose the brackets and still use dashes in id names.

[danbeam]

see also #150

[jklein24]

That's already done in Polymer 1.0 for attributes.

[pensierinmusica]

+1 agree with @dotDeeka

[NikolayBorisov]

It would be nice, but

<div id="coolDiv"><div id="cool-div"></div></div>

How to choose?

[pensierinmusica]

@kosiasik if I understand correctly HTML attributes are case insensitive, which is why Polymer converts camelCase JS properties in the first place.

So, in your example the outer div has a property id with value cooldiv, whereas the inner div has a property id with value cool-div. Hence they're easily distinguishable by the interpreter.

Does this make sense?

[zoechi]

@pensierinmusica id (the name) is case insensitive coolDiv the value is not.

[pensierinmusica]

I thought so, and was actually looking for an official reference to it but couldn't find it. The closest match I've found is this (which is an old document though, and suggests to treat values as case-insensitive anyways):
https://developer.mozilla.org/en-US/docs/Case_Sensitivity_in_class_and_id_Names

@zoechi do you have a link to official HTML standard docs where it's stated that attribute values are case sensitive, or is it left to browser implementations?

Thanks, cheers!

[zoechi]

@pensierinmusica I don't know an official doc where this is more explicitly stated but the W3C you linked to only talks about attribute names not values and it is also how Polymer treats attribute names and values. See https://www.polymer-project.org/1.0/docs/devguide/events.html#annotated-listeners

[pensierinmusica]

I see, makes sense :)

[derek-pavao]

@kosiasik Good point. I didn't actually think of that.

I'm not sure if this makes sense, but. If this is the sort of thing the component author would have to opt into they would be explicitly stating they want the dashed ids to change to camelCase. It doesn't solve the problem, but the developer is being explicit about the behavior they want.

Also not sure if this makes sense, but if a component author opts in to transforming dashed ids to camel case and then adds an id that is camel case, throw an error?

Thoughts?

[arthurevans]

So, HTML attribute values are DOMStrings, which are case sensitive. There are various places in the spec that require values to be compared in a case-insensitive fashion (such as enumerated attributes), while others require them to be compared in a case-sensitive fashion (like fragment identifiers),

The fact that the browser is required to match IDs in a case-sensitive fashion in fragment identifiers suggests that ... well, IDs must retain their original case.

In fact, if attribute values weren't case sensitive in a given browser, hundreds of Polymer unit tests would fail: anything that uses foo="{{camelCaseProp}} or on-event="camelCaseHandler" or id="camelCaseId". Like these:

https://github.com/Polymer/polymer/blob/master/test/unit/bind.html#L49

If you really want this mapping, you could add it as a behavior, like this:

http://jsbin.com/fuyasah/8/edit?html,console,output

Personally, I think doing this mapping where we don't need to would only add confusion to the library, and the next thing people would be wondering why on-event="event-handler" doesn't work, or even foo="{{camel-case-prop}}". By not munging the ID, we're sticking as close as possible to the platform's native behavior and maintaining a consistent treatment of attribute values.

[pensierinmusica]

@arthurevans yep I agree that sticking as close as possible to the platform's is a good guiding principle for a library like Polymer, that aims to get thinner and thinner as new features are natively integrated by the browser.

[kevinpschaaf]

Closing, as we are electing to not move forward with adding this feature per the above discussion.