support date and time format

[jfrazzano]

We are using date, time and list (list only in shady) for our implementation of paper...radio works less well). We made the choice even unsupported as we are using a crawl through databases to build input sets and displays.

As the data model, If done sensibly will create natural patterns for views and inputs to create views a single input for the generator was a big plus--it limited moving parts. This also causes us to modify paper input to have its own versions of golld tell and email inputs.

Unifying these desperate inputs into the single native input would be great benefit for anyone seeking to have self generating displays and the mets level input views needed to create the displays.

Once the current CSS and slot/content insertion issues are sorted is this the polymer plan as well? It would seem sesible and natural.

[samccone]

cc @notwaldorf any thoughts on if this is within the scope of this element?

[jfrazzano]

It looks like search was added in update we loaded yesterday, and list attr has been bound since the beginning.

I am focused on list, right now, because we first built a dropdown-paper-menu which could be linked to-earlier-form-answers; we then built a generator for it. We could add atts to linked responses to limit or alter other responses and create new menus mid-form, based on responses, which was cool. We styled it pretty nicely and were happy in our tests.

The in-house call center we built the menu selects for, however, was less than pleased. When using keyboard only, DD paper menu has.. let's just has focus, keyboard, alpha-numeric response/select, select on enter, tab and enter/tab related positioning, cohesion and representation issues (you can make it fly all over the screen).

So, we went to list.

List--not as pretty--but it required roughly the same layout as the drop-down-paper-menu, with fewer issues... until yesterday. Then list attr stopped working in shadow dom.

Date and Time still work fine in shadow, list is still bound in our updated version of paper input, but of 5 input lists none appeared in shadow. Any idea why it dropped to only shady support?

It's not a huge deal; I just am going to spend my next two weeks with two employees of mine, using our vacation time to try and push out at least our call center interface. I would feel horrible if I wasted these guys time on an element choice that maybe gone in a month. I can go to a select, lose some styling. I just can't in good conscience ask to guys with families (one had a baby girl last week) to lose family time if I don't at least ask you if list is a bad idea.

And, I wanna make it clear--everyone here who works with Polymer loves it; we think you guys have done an amazing job in an absurdly short amount of time. We also realize that you are not the standards "creators"; it's decision by committee, and not every plays nice, or is aware of the cascading issues created often over some trivial sticking point for a large system like Polymer. It's a beast of a job to try and do this. We get it and are really grateful.

I just had to ask. Thanks,

Jason

[notwaldorf]

@jfrazzano First, I am sorry you are frustrated with changes. For what it's worth, we don't actually take any functionality out, and especially not every month, so if anything, it's an unintended bug.

I'm not sure I follow what is broken, though -- if you have an issue with paper-dropdown-menu, that's a different element, and you should open a bug there (and changes in iron-input should affect it). Also, I didn't 'add' type=search to iron-input; it's always been there, working, and I only fixed a minor styling issue.

Secondly, <input is="iron-input" type="date"> still works for me in the shadow dom and the shady dom . Here are some screenshots where I added type='date'to the input in the demo: Shadow dom:

Shady dom:

I am not sure what you mean by list. Can you post a code snippet with what you're doing and what is broken? Ideally in a new issue, since it seems like it's not related to this PR :(

[cdata]

@jfrazzano I would like to remark about this comment you made:

It's not a huge deal; I just am going to spend my next two weeks with two employees of mine, using our vacation time to try and push out at least our call center interface. I would feel horrible if I wasted these guys time on an element choice that maybe gone in a month. I can go to a select, lose some styling. I just can't in good conscience ask to guys with families (one had a baby girl last week) to lose family time if I don't at least ask you if list is a bad idea.

I appreciate that you may be dealing with a work stress, imminent deadlines and / or scarce resources. As a fellow technology worker, I am familiar with these tensions - they affect all of us.

That said, it's not appropriate to put the weight of these problems on others to coerce them into re-arranging priorities for your sake. Comments like this can be construed as aggressive, and present a condescending attitude.

Please do your best to keep our discussions positive! In return, we'll do our best to help you with your problems. Here is a link to our code of conduct.

[notwaldorf]

This is an old PR, and from my comment in https://github.com/PolymerElements/iron-input/pull/52#issuecomment-145692826, I don't see what this PR is trying to fix (nor is it explained very well). Also it has a bunch of TODOs and //Hackss, which wouldn't be merged. Please re-open this PR with a Jsbin reproducing the bug you are trying to fix, if it's still valid.