Do you have some feature in mind that you'd love to see in Couch? Let us know.
11 posts Page 1 of 2
Couch as of v1.3-RC1 does not allow for the new HTML5 input types to be used in the 'cms:input' tag's 'type' parameter. You can see a full list of these new input types for forms at The client-side 'required' attribute also conflicts with the server-side 'required' parameter for 'cms:input' tags, see Perhaps compatibility can be introduced for these in v1.3 or v1.4?
any news here?
Bumping this one. (I love HTML5)

There are some hurdles which don't allow HTML inputs to be implemented as-is just yet though:

All browsers have their own way of handling these inputs. You will really want to make an example page with all inputs and open them in as many browsers as possible, you'll see the difference. Here I'm not even counting the matter that older browsers will have no clue what to do with these inputs. However, since older browsers will treat the inputs like text inputs, I don't think a major disaster is at hand there. Mobile browsers however, will benefit greatly from these inputs, since they can adjust their keyboard to the type of input.

An example of my first statement are all date/time related inputs. These are the type of inputs you will really want to use date/timepickers with. Some browsers provide these, some don't. One browser which doesn't provide support (yet) is FireFox and that's quite a popular browser. To make sure these inputs work, for each one you need to provide a polyfill (fallback) JavaScript picker, in case the browser doesn't natively support the input field. Then there's the matter of making sure each browser and JS picker gives you the exact same input, so your back-end can handle this.

The following two pages can give you some more information about HTML5 compatibility:
@MHLut, what you said is exactly what holds me back from implementing the new input types.
I think we'll have to wait for the browser situation to stabalize before going for it lest we only succeed in creating confusion for the end-user.
I hold a contrary opinion on this topic. I see it as a rather cut-and-dried matter; these new input types are part of the HTML spec and Couch should provide support for them, and in the least certainly not prevent their usage in cms:input tags.

I would bet a vast majority of people who know these input types exist, are also keenly aware of the browser support issues present at the moment. This is just another choice that a designer/developer must make when assessing what browsers to support. I don't believe Couch should have any role in that decision making process. This is a front-end concern and full browser support is rapidly approaching regardless.
Bumping again. I fully agree with Cheesypoof on this matter.

Is it possible to update the types to reflect new data types offered under html5, e.g:

Code: Select all
<cms:input type='url' />
<cms:input type='email' />
<cms:input type='tel' />
<cms:input type='number' />
<cms:input type='range' />

I believe that the inclusion of these types will better enable the use of couchcms with responsive themes when presented on my mobile devices. Other ones that might be worth including- date, time … but I can see them offering potential problems if special libraries are require to launch pickers.
There are 10 types of people in this world ... Those who can count in binary and …
v1.4RC onwards Couch supports creation of custom input types (similar to custom editable regions and tags).
I think it shouldn't be difficult now to create the new HTML5 types as addons to the core types.

I'll try and get this done as soon as I get some time (that is, if somebody doesn't complete it before me ;) ) .

Quick workaround for those eager to use these new types and the required attribute:
Code: Select all
    <cms:input name='email' required='1' type='text' validator='email'/>

<input name="email" required="required" type="email" value="<cms:gpc method='post' var='email'/>"/>
We hide the Couch-generated input and simply create our own (with the same name). This results in some code duplication, but at least we can use these new HTML5 features right now.
That is some ingenious thinking, my friend :)
11 posts Page 1 of 2