Along with the great content, that we providing to the audience of our web pages, there are particular occasions when we also need the people actually viewing the pages to take some kind of action like providing the way they see the topic, subscribe to a newsletter list, register or whatever. That's right! We are talking about some forms here – it is a great way for adding some interactivity to the page content often improving the user experience a lot.
With that, as we well know, the number of mobile devices used for accessing the Internet raises every year and at this point it is possible about half of the visits to a particular web page with an AMP Menu to be done via mobiles which means along with the great content our pages should also provide speed and stability when viewed from a device with relatively low resources, bandwidth limitations and so on. One of the approaches to achieve that (and it comes with some extras – like the pages implementing it are highly rated by Google) is using Accelerated Mobile Pages as mirrors to the regular ones we create. This way the users get access much faster even in cases of limited resources.
So we have forms we can create with HTML Form Builder on one side, and AMP – on the other, and over here we're going to take a glimpse on how the first get implemented in the second. It all pretty much narrows down to creating a regular form elements but following the strict AMP limitations and including the required custom AMP element handling them.
Now the amp-form is not an actual tag replacing some of the ones we are used to in regular HTML but rather a script component allowing the AMP pages to handle our forms as long these are consisting of the permitted by AMP components. In order to have the amp-form component working in our pages we first need to include it by placing an extra <script> tag in our page's header – like this:
<script async custom-element="amp-form" src="https://cdn.ampproject.org/v0/amp-form-0.1.js"></script>
If you omit that tag and do have a form on the other valid AMP page the validation will fail.
What you can and what can't have as form elements in a valid AMP page:
- The form elements which are considered valid and therefore – allowed by AMP validation are <input type=submit>, <input type=text>, <label>, <textarea>, <option>, <select>, <fieldset> along with the amp-selector element.
- The forms in AMP should not have <input type=file>, <input type=password>, <input type=image> , <input type=button> and pretty much all the attributes regarding forms like formtarget, form, formmethod, formaction and so on.
These rules are rather even more strict than the regular AMP restrictions and probably will be reconsidered in the future so it might be a good idea checking the official page of AMP form restriction rules to see if any changes have been done in the process.
https://github.com/ampproject/amphtml/blob/master/validator/validator-main.protoascii
The forms working with amp-form should have either _top or _blank values of their target attribute – everything else is prohibited by the validation rules.
If your method is set to get you also would want to provide either an action or action-xhr attribute. If action is the one you would go for – do note the URL you are providing must also be https. If action-xhr is your choice (which is actually mandatory for method = "post") the form will be submitted with a XHR (or AJAX – pretty much the same thing) request and the current page will not get fully reloaded. No new page will be opened as well.
What can you do with your forms? – submit them – that's it. submit is the only action exposed by amp-form and it can be triggered by a few events – like changing the active form field or tapping on a particular link.
Once the amp form has been submitted you can send your visitors some feedback if the submission has been processed successfully or not by using the special marker attributes submit-error or submit-success. These should be assigned to the direct children of the form element and should contain an extended <template> should be included wrapping some data arranged as a valid JSON object.
After all this waterfall of technical details how nice it would be if there were some ready-made snippets for usage – isn't it? A good news - there is such thing available. So instead of creating your forms from the scratch, you could also consider taking some of the examples provided on the start page of the official AMP site which has quite a few form elements showcased along with the markup making them happen.
The amp-form expansion admits the usage of forms to put input fields inside of an AMP file.
The amp-form extension MUST be activated supposing that you're employing <form>, or else your documentation will definitely be wrong! Usage of input tags for aims apart from sending their values (e.g. inputs not actually within a <form>) is legitimate with no loading amp-form amplification.
<form method="post"
action-xhr="https://example.com/subscribe"
target="_top">
<fieldset>
<label>
<span>Name:</span>
<input type="text"
name="name"
required>
</label>
<br>
<input type="submit"
value="Subscribe">
</fieldset>
<div submit-success>
<template type="amp-mustache">
Subscription successful!
</template>
</div>
<div submit-error>
<template type="amp-mustache">
Subscription failed!
</template>
</div>
</form>target
The value for the target feature should be possibly _ blank or alternatively _ top.
action (optional for GET, invalid for POST)
For GET submissions, at least one of action or else action-xhr need to be presented.
This feature is requested for method=GET. The value must be an https WEBSITE ADDRESS and must not be a link to a CDN (does NOT connected to https://cdn.ampproject.org). For method=POST, the action property is out of action, employ action-xhr as a substitute.
action-xhr
This property is simply involved for method=POST, and is optional for method=GET. Assuming that produced, the form will be provided in an XHR fashion.
An XHR request ( often times termed as an AJAX request) is where the internet browser would certainly develop the inquiry without a full load of the webpage or else launching a new webpage. Internet browsers will provide the inquiry in the background applying Fetch API if obtainable and fallback to XMLHttpRequest API for old web browsers.
The value for action-xhr can easily be the identical or else a varying endpoint compared to action and has the same activity needs that were mentioned earlier.
other form attributes
All other form properties are not required.
custom-validation-reporting (optional)
AMP Form validation allows and chooses a custom-made verification reporting practice, valid values are one of: show-first-on-submit, show-all-on-submit or else as-you-go.
Admitted:
- Other form-related items, incorporating: <textarea>, <select>, <option>, <fieldset>, <label>, <input type=text>, <input type=submit>, etc.
- amp-selector
Certainly not Enabled:
- <input type=button>, <input type=file>, <input type=image> and <input type=password>
- A lot of the form-related characteristics regarding inputs featuring : form, formaction, formtarget, formmethod and others.
( Easing several of these standards might be re-thinked eventually).
amp-form reveals just one action: submit. This permits you to launch the form entry on a certain action, for instance, utilizing a url, or submitting a form regarding input change.
Amp Form presents the following activities:
- submit: Emitted whenever the form is proposed and just before the submission is accomplished.
- submit-success: Produced whenever the form submission is really worked on and the reply is a success.
- submit-error: Produced whenever the form submission is done and the result is an error.
These particular events can certainly be employed with the on characteristic. As an example, the following pays attention to either submit-success and submit-error and demonstrates various lightboxes depending on the circumstance.
<form ... on="submit-success:success-lightbox;submit-error:error-lightbox" ...>
</form>AMP displays change activities at inputs. This allows you to employ the on characteristic to do an act on any element as soon as an input value updates.
For an example, a standard use case is actually to provide a form on input change (selecting a radio switch to reply to a poll, selecting a language from a select input to translate a web page, and so on).
<form id="myform"
method="post"
action-xhr="https://example.com/myform"
target="_blank">
<fieldset>
<label>
<input name="answer1"
value="Value 1"
type="radio"
on="change:myform.submit">Value 1
</label>
<label>
<input name="answer1"
value="Value 2"
type="radio"
on="change:myform.submit">Value 2
</label>
</fieldset>
</form>amp-form cause three events you can track inside of your amp-analytics config: amp-form-submit, amp-form-submit-success, and amp-form-submit-error.
You can set up your analytics to provide these particular events functioning as in the example shown below.
<amp-analytics>
<script type="application/json">
"requests":
"event": "https://www.example.com/analytics/event?eid=$eventId",
"searchEvent": "https://www.example.com/analytics/search?formId=$formId&query=$formFields[query]"
,
"triggers":
"formSubmit":
"on": "amp-form-submit",
"request": "searchEvent"
,
"formSubmitSuccess":
"on": "amp-form-submit-success",
"request": "event",
"vars":
"eventId": "form-submit-success"
,
"formSubmitError":
"on": "amp-form-submit-error",
"request": "event",
"vars":
"eventId": "form-submit-error"
</script>
</amp-analytics>The amp-form-submit activity fires as soon as a form inquiry is simply initiated. The amp-form-submit function generates a package of variables that correlate to the unique form and also the sectors located in the form. These variables can be used for analytics.
For an example, the following form contains one area:
<form action-xhr="/comment" method="POST" id="submit_form">
<input type="text" name="comment" />
<input type="submit" value="Comment" />
</form>In case the amp-form-submit event fires, it generates the following variables consisting of the values that were certainly specified in the form:
- formId
- formFields[comment]
amp-form helps founders to render the feedbacks using Extended Templates.
Employing submit-success and also submit-error specific signal attributes, publishers can certainly note any kind of straight child component of form and include a <template></template> tag in it to deliver the reply in it.
The feedback is assumed to be actually a credible JSON Object. For instance, in the case that the founder's action-xhr endpoint returns the presented responses:
Success Response Rendering
"name": "Jane Miller",
"interests": ["name": "Basketball", "name": "Swimming", "name": "Reading"],
"email": "email@example.com"Error Response
"name": "Jane Miller",
"message": "The email (email@example.com) you used is already subscribed."Equally success and error responds ought to feature a Content-Type: application/json header. submit-success are going to render for all responses which possesses a status of 2XX, all of the various other conditions are going to deliver submit-error.
Publishers can certainly deliver these in a template inside their forms functioning as considers.
<form ...>
<fieldset>
...
</fieldset>
<div submit-success>
<template type="amp-mustache">
Success! Thanks name for subscribing! Please make sure to check your email email
to confirm! After that we'll start sending you weekly articles on #interests<b>name</b> /interests.
</template>
</div>
<div submit-error>
<template type="amp-mustache">
Oops! name, message.
</template>
</div>
</form>amp-form equally allows founders to direct clients to a new web page with AMP image once a submitting takes place with AMP-Redirect-To action header.
Consider that you 'd in addition have to improve your Access-Control-Expose-Headers action header to involve AMP-Redirect-To to the listing of authorized headers.
The redirect web link must be complete HTTPS URL or else AMP are going to send an error and redirection won't occur.
Determined Problem: A result of an issue in Safari iOS redirecting to deep attached URLs ( Addresses that might really finish up opening an original app) might stop working the moment the AMP data is actually set. This is actually tracked within this issue.
AMP-Redirect-To: https://example.com/forms/thank-you
Access-Control-Expose-Headers: AMP-Redirect-To, Another-Header, And-Some-Moreamp-form provide polyfills for behaviors and functionality missing from some browsers or being implemented in the next version of CSS.
Browsers that apply webkit-based programs do not actually provide null form submissions. These include Safari on all systems plus all iOS web browsers. amp-form polyfills this specific behavior to stop any sort of null entries and present validation message bubbles concerning null elements.
Keep in mind: Notifications are in some cases restricted to a handful of words such as " demanded field", these kinds of notices are offered by the browser utilization. We'll be dealing with permitting publisher-provided custom made verification messages along with custom-made approval UIs ( in place of the built-in/polyfill 'd bubbles).
:user-invalid/:user-valid
Such quasi classes belong the CSS Selectors 4 spec and are actually presented to empower more desirable hooks for forming invalid/valid fields founded on a few standards.
Some of the essential differences between : invalid and : user-invalid is simply when they are placeded on the feature. : user-invalid is employed right after a considerable communication coming from the visitor with the field (e.g. user types in a field, or blur from the field).
amp-form grants classes ( check out listed below) to polyfill these types of pseudo-classes. amp-form also provides these to ancestors fieldset-s plus form.
The amp-form extension allows you to create your unique custom-made affirmation UI by employing the custom-validation-reporting characteristic together with one the following reporting methods: show-first-on-submit, show-all-on-submit or as-you-go.
To point out custom verification on your form:
1. Set the custom-validation-reporting feature at your form to 1 of the validation revealing strategies.
2. Supply your very own approval UI increased utilizing exclusive features. AMP will certainly discover the special properties and state them at the correct time depending upon the reporting strategy you defined.
Here is actually an example:
<form method="post"
action-xhr="https://example.com/subscribe"
custom-validation-reporting="show-all-on-submit"
target="_blank">
<fieldset>
<label>
<span>Name:</span>
<input type="text"
name="name"
id="name5"
required
pattern="\w+\s\w+">
<span visible-when-invalid="valueMissing"
validation-for="name5"></span>
<span visible-when-invalid="patternMismatch"
validation-for="name5">
Please enter your first and last name separated by a space (e.g. Jane Miller)
</span>
</label>
<br>
<label>
<span>Email:</span>
<input type="email"
name="email"
id="email5"
required>
<span visible-when-invalid="valueMissing"
validation-for="email5"></span>
<span visible-when-invalid="typeMismatch"
validation-for="email5"></span>
</label>
<br>
<input type="submit"
value="Subscribe">
</fieldset>
</form>For approval text messages, in case your element features no text web content within, AMP will certainly fill it out together with the internet browser's default approval message. Here in the example above, when the name5 input is undoubtedly clear and verification is simply started ( such as, client aimed to affirm the form) AMP will certainly fill <span visible-when-invalid="valueMissing" validation-for="name5"></span> <span visible-when-invalid = "valueMissing" validation-for = "name5" > with the web browser's verification notification and demonstrate this span to the site visitor.
Establish 1 of the following reporting choices for the custom-validation-reporting attribute:
The show-first-on-submit reporting option mimics the web browser's default behavior once default validation starts. It demonstrates the initial verification glitch it discovers and stops there.
The show-all-on-submit reporting possibility demonstrates all approval errors upon all null inputs as soon as the form is forwarded. This is handy if you 'd like to reveal a summary of recognitions.
The as-you-go reporting opportunity helps your visitor to see approval notifications as they are actually interacting with the input. For some example, supposing that the user writes an invalid mail address, the customer will see the error immediately. The minute they fix the value, the error leaves.
This particular component is still experimental, and so you ought to permit the experiment to operate form confirmation.
HTML5 approval supplies feedback established purely on related information easily available on the web page, such as if a value matches a certain style. With amp-form affirmation you have the ability to present the user response that HTML5 affirmation on its own can not really. For example, a form can certainly utilize affirmation to check out if an email address has definitely been registered. One more use-case is determining that a city field and a zip code field match each other.
Here's an example:
<h4>Verification example</h4>
<form
method="post"
action-xhr="/form/verify-json/post"
verify-xhr="/form/verify-json/post"
target="_blank"
>
<fieldset>
<label>
<span>Email</span>
<input type="text" name="email" required>
</label>
<label>
<span>Zip Code</span>
<input type="tel" name="zip" required pattern="[0-9]5(-[0-9]4)?">
</label>
<label>
<span>City</span>
<input type="text" name="city" required>
</label>
<div class="spinner"></div>
<input type="submit" value="Submit">
</fieldset>
<div submit-success>
<template type="amp-mustache">
<p>Congratulations! You are registered with email</p>
</template>
</div>
<div submit-error>
<template type="amp-mustache">
#verifyErrors
<p>message</p>
/verifyErrors
^verifyErrors
<p>Something went wrong. Try again later?</p>
/verifyErrors
</template>
</div>
</form>
The form sends a `__amp_form_verify` field as part of the form data to let the server know the request is a verify request and not a formal submit.Here is actually just how an error feedback should seek confirmation:
"verifyErrors": [
"name": "email", "message": "That email is already taken.",
"name": "zip", "message": "The city and zip do not match."
]amp-form empowers system adaptable alternatives for inputs that are concealed and which have the data-amp-replace feature. On every form submission , amp-form identifies all input [type= hidden] [data-amp-replace] within the form and utilizes variable replacements to its value feature and switches it with the result of the replacement.
You ought to deliver the variables you are using for each replacement on each and every input through defining a space-separated string of the variables used in data-amp-replace ( observe example listed here). AMP will not change variables which are not clearly determined.
Here's an illustration of precisely how inputs are just before and after substitutions (note that you must employ system syntax of variable changes and not analytics ones):
<!-- Initial Load -->
<form ...>
<input name="canonicalUrl" type="hidden"
value="The canonical URL is: CANONICAL_URL - RANDOM - CANONICAL_HOSTNAME"
data-amp-replace="CANONICAL_URL RANDOM">
<input name="clientId" type="hidden"
value="CLIENT_ID(myid)"
data-amp-replace="CLIENT_ID">
...
</form>When the user considers to submit the form, AMP will definitely aim to deal with the variables and improve the fields' value characteristic of all fields with the relevant alternatives. Regarding XHR submittings, all of the variables are likely to become replaced and settled . Yet, in non-XHR GET submissions, values that necessitates async-resolution might not be accessible because of having not been resolved before. CLIENT_ID, for example, would certainly not resolve, supposing that it wasn't worked out and cached earlier.
<!-- User submits the form, variables values are resolved into fields' value -->
<form ...>
<input name="canonicalUrl" type="hidden"
value="The canonical URL is: https://example.com/hello - 0.242513759125 - CANONICAL_HOSTNAME"
data-amp-replace="CANONICAL_URL RANDOM">
<input name="clientId" type="hidden"
value="amp:asqar893yfaiufhbas9g879ab9cha0cja0sga87scgas9ocnas0ch"
data-amp-replace="CLIENT_ID">
...
</form>Note precisely how CANONICAL_HOSTNAME mentioned above did not get switched out because it was not really in the whitelist through data-amp-replace feature on the primary field.
Apart from keeping the information within the AMP CORS specification, please provide extra care to the area on "Verifying state changing requests" to preserve against XSRF attacks precisely where an attacker are able to implement unauthorized commands using the recent user session free from the user expertise.
Generally, take note the following aspects when approving input from the visitor:
- Only apply POST for state altering asks.
- Utilize non-XHR GET for navigating objectives only, e.g. Search.
* non-XHR GET demands are not planning to gain precise origin/headers and backends won't have the capacity to guard against XSRF along with the aforementioned feature.
* Generally work with XHR/non-XHR GET asks for navigational or else information retrieval only.
- non-XHR POST inquiries are not actually allowed in AMP files. This is due to inconsistencies of determining Origin header on these inquiries across browsers. And the issues assisting it would certainly present in protecting from XSRF. This might possibly be rethinked and presented after.
So that's generally the way the form elements come to take place in the AMP pages we are about to create. It's not the simplest process out there but still, it is a way combining the so needed interactive functionality with what Google claims to be the next speed up standard in the world of web. Luckily there are some ready-made snippets and templates out there which could eventually make the process easier.