5 ms·

One thing I remembered while reading the section on telephone inputs—what happened to all the HTML5 date and time input types? http://caniuse.com/#search=Date%

by adregan 10y ago

One thing I remembered while reading the section on telephone inputs—what happened to all the HTML5 date and time input types? http://caniuse.com/#search=Date%20and%20time%20input%20types http://caniuse.com/#search=Date%20and%20time%20input%20types All of the other cool new input types appear to be on the way in the modern browsers (http://caniuse.com/#search=input%20type http://caniuse.com/#search=input%20type), but Safari and Firefox don't appear to be budging at all. I would prefer to use the native date pickers across devices, but I feel like I have been waiting on those elements to land for years now. Did I miss something?

cmg 10y ago
A few (maybe 3) years ago I developed an in-house calendaring webapp and aimed to use the date/time/datetime fields on it. Unfortunately the client couldn't guarantee browser consistency across their offices, and of course mobile was a concern as well. I don't remember the details and wish I'd written it up, but the inconsistencies across browsers about required values, bounds - not to mention trying to do "trivial" things invalidating Saturdays and Sundays - were astounding. datetime-local helped a bit, but wasn't fully supported in IE. I spent 4 days working on that, then spent an hour ripping my code apart and adding moment.js and the jQuery UI Datepicker widget. At least it worked.
- dexwiz 10y ago
  +1 for moment.js. Of all the npm modules I have used in the last year, none have been cleaner than moment. It has great docs, all the features you need, and just "works." I am constantly having to come up with workarounds for React, Sequelize, whatever, but momentjs never seems to force me into an awkward position.
  - Waterluvian 10y ago
    I'm curious abiut generally speaking what workarounds you're doing in react. Every workaround I've had to do, eventually revealed itself as a code smell or antipattern. Obviously they are there; no view library is perfect. But I have yet to see what one loons like.
    - dexwiz 10y ago
      I would agree most React workarounds are code smells. At one point I had to advise a teammate to not use jQuery to attach event listeners to DOM elements created by React. My major issue is that everything is a component. Which means it's hard to delineate between View and Logic (Models/Controller) code. React rightfully called itself View only. But in classic JS fashion, the community Frankenstiened it into a full framework. Before someone says it, I think stateless functional components are a bad solution to the logic/view separation. Also I don't think React has figured out a good solution for styling yet. The two major camps seem to be inline styles or css classes. We went with css classes so we could use css "frameworks." But I think both methods have their cons.
      - Waterluvian 10y ago
        I agree totally. I have an app of a few hundred components and sometimes there's a lot of heavy business logic that feels wrong to have in a component. I also have this ugly mess of scss that don't live with the components. What I'd like to see is a component gets to define it's own structure and default look and feel. So styles in the component. Then you can give it class information if you're giving it your own styling or customization. I would love to be able to package an entire calendar widget, for example, into a module that is only .JSX files. And know that no matter where I import it, by default it'll look and behave in a sane manner.
        dexwiz 10y ago
        Using classes as overrides is like how Bootstrap is (was?) customized. Bootstrap had default css classes that applied a default style. To override it, you would create your own css classes with custom attributes targeting the same classes, but with higher specificity [1]. You are still using styling here. Styling can get very verbose. That would just clog up the .JSX file. CSS will be its own entity from React or any templating engine for the foreseeable. Moving it into its own file helps with code organization. The only sane way to link them right now is css classes. Althought the argument for inline versus class css extends beyond the React world. But you have to do things like prefixing to make sure your css [1] https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
gtk40 10y ago
They're available on mobile Firefox and Safari (well partially on the latter) but not the desktop versions. I wonder if it's because they're not implemented at the OS level?
blowski 10y ago
Seems that Firefox are planning to support it. Latest discussion on Bugzilla was in May of this year (https://bugzilla.mozilla.org/show_bug.cgi?id=888320 https://bugzilla.mozilla.org/show_bug.cgi?id=888320) where they were discussing implementation details. No news from Safari.
mintplant 10y ago
Those are on their way to Firefox. I remember seeing them in someone's intern presentation this year. I'll try to dig up the video in a bit.

by adregan 10y ago

cmg 10y ago

A few (maybe 3) years ago I developed an in-house calendaring webapp and aimed to use the date/time/datetime fields on it. Unfortunately the client couldn't guarantee browser consistency across their offices, and of course mobile was a concern as well. I don't remember the details and wish I'd written it up, but the inconsistencies across browsers about required values, bounds - not to mention trying to do "trivial" things invalidating Saturdays and Sundays - were astounding. datetime-local helped a bit, but wasn't fully supported in IE. I spent 4 days working on that, then spent an hour ripping my code apart and adding moment.js and the jQuery UI Datepicker widget. At least it worked.

dexwiz 10y ago
+1 for moment.js. Of all the npm modules I have used in the last year, none have been cleaner than moment. It has great docs, all the features you need, and just "works." I am constantly having to come up with workarounds for React, Sequelize, whatever, but momentjs never seems to force me into an awkward position.
- Waterluvian 10y ago
  I'm curious abiut generally speaking what workarounds you're doing in react. Every workaround I've had to do, eventually revealed itself as a code smell or antipattern. Obviously they are there; no view library is perfect. But I have yet to see what one loons like.
  - dexwiz 10y ago
    I would agree most React workarounds are code smells. At one point I had to advise a teammate to not use jQuery to attach event listeners to DOM elements created by React. My major issue is that everything is a component. Which means it's hard to delineate between View and Logic (Models/Controller) code. React rightfully called itself View only. But in classic JS fashion, the community Frankenstiened it into a full framework. Before someone says it, I think stateless functional components are a bad solution to the logic/view separation. Also I don't think React has figured out a good solution for styling yet. The two major camps seem to be inline styles or css classes. We went with css classes so we could use css "frameworks." But I think both methods have their cons.
    - Waterluvian 10y ago
      I agree totally. I have an app of a few hundred components and sometimes there's a lot of heavy business logic that feels wrong to have in a component. I also have this ugly mess of scss that don't live with the components. What I'd like to see is a component gets to define it's own structure and default look and feel. So styles in the component. Then you can give it class information if you're giving it your own styling or customization. I would love to be able to package an entire calendar widget, for example, into a module that is only .JSX files. And know that no matter where I import it, by default it'll look and behave in a sane manner.
      - dexwiz 10y ago
        Using classes as overrides is like how Bootstrap is (was?) customized. Bootstrap had default css classes that applied a default style. To override it, you would create your own css classes with custom attributes targeting the same classes, but with higher specificity [1]. You are still using styling here. Styling can get very verbose. That would just clog up the .JSX file. CSS will be its own entity from React or any templating engine for the foreseeable. Moving it into its own file helps with code organization. The only sane way to link them right now is css classes. Althought the argument for inline versus class css extends beyond the React world. But you have to do things like prefixing to make sure your css [1] https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

gtk40 10y ago

They're available on mobile Firefox and Safari (well partially on the latter) but not the desktop versions. I wonder if it's because they're not implemented at the OS level?

blowski 10y ago

Seems that Firefox are planning to support it. Latest discussion on Bugzilla was in May of this year (https://bugzilla.mozilla.org/show_bug.cgi?id=888320 https://bugzilla.mozilla.org/show_bug.cgi?id=888320) where they were discussing implementation details. No news from Safari.

mintplant 10y ago

Those are on their way to Firefox. I remember seeing them in someone's intern presentation this year. I'll try to dig up the video in a bit.