Amphtml: Allow <label> and <input type=checkbox/radio> elements when not descendants of <form>

[tonyruscoe]

It’s possible to create elegant, progressively-enhanced UI components using <label> and <input type=checkbox> or <input type=radio> elements in conjunction with the :checked CSS pseudo-class selector which work without JavaScript.

For example: https://css-tricks.com/functional-css-tabs-revisited/

Including these elements without a <form> ancestor in an AMP page currently fails validation with the following errors:

The tag 'input' may only appear as a descendant of tag 'form'. (see https://www.ampproject.org/docs/reference/extended/amp-form.html)

The tag 'label' may only appear as a descendant of tag 'form'. (see https://www.ampproject.org/docs/reference/extended/amp-form.html)

A simplified example (ignore the 'script' errors): https://output.jsbin.com/panuviloxu#development=1

Since these elements aren’t being used as part of a form, much like some <button> elements, it should be possible to allow them without requiring the amp-form custom element script so that developers who have existing CSS-only implementations of UI components are able to re-use more of their existing HTML and CSS in their AMP pages.

Are there any reasons why the AMP HTML Specification wouldn’t be able to allow these elements to be used in this context?

Thanks for considering this!

[dvoytenko]

/cc @mkhatib @ericlindley-g

[ericlindley-g]

to/ @rudygalfi who worked on the initial component

[mkhatib]

Are there any reasons why the AMP HTML Specification wouldn’t be able to allow these elements to be used in this context?

No specific reason for now. We just like to start in a small use-case and then expand as features requests like these come in or as we see that works or wouldn't introduce any side-effects. For example, for a long time forms were not supported in AMP but we just introduced them.

Another reason was that amp-form would polyfill different missing features of form and related tags like input

This could be ok, will have to do some more research and make sure we don't introduce any side effects here.

@rudygalfi let me know what do you think.

[tonyruscoe]

Thanks Mohammad. Let me know if there’s anything I can do to help with your research.

I might be able to share some more examples confidentially if that would help?

Let me know if you’d like to discuss this 1:1.

[maddoxnelson]

If I could chime in, I'm trying to implement a pure CSS menu in amp, using a checkbox-like system described here: https://codepen.io/surjithctly/pen/pLDwe

Just wanted to post a use case, in the event you were looking for them. I'm running into the exact problem where an "input" box must be the child of a form element.

And just for context, I started by trying to use amp-sidebar and amp-accordion, but my amp-sidebar can't be the child of the body element (required for validation), so I had to go back to this way...

[selfcatering]

I'm too much interested in the same use case as @maddoxnelson
Since custom javascript code is not allowed the only and actually quite neat approach to toggle a css menu is to use a label along with an input checkbox. The requirement to keep both tags as an immediate descendants of a form tag is breaking this nice feature.

[mkhatib]

The only obvious issue that I see with this is whether we still want to enforce the inclusion of amp-form when input is used without a form or not. I vote for not.

For the use-case mentioned in here I don't see a reason to enforce this, since enforcing inclusion of amp-form was to allow us to polyfill some behavior in the browsers submissions (validation, reporting and submitting blocking).

I don't see any other obvious issues. I think we already block the use of form and formaction and other form related attributes on inputs.

[tonyruscoe]

Agreed. As I said in the original issue:

Since these elements aren’t being used as part of a form, much like some <button> elements, it should be possible to allow them without requiring the amp-form custom element script

What are the next steps?

[mkhatib]

Deferring to @rudygalfi to prioritize this, but I think @Gregable said he can start implementing this in the validator. This will most likely not require changes in runtime.

[rudygalfi]

Shifting assignment over to @Gregable and @powdercloud for the validator update.

I'm OK to do this. cc @cramforce as FYI in case he can think of any good reasons not to allow <label> and <input> outside of <form>.

[cramforce]

SGTM

[Gregable]

Fixed. Not live yet.

[tonyruscoe]

Great, thanks everyone!

@Gregable, does your change allow <label> and <input> elements without a form ancestor to be used without the amp-form extension script? (It doesn’t seem to, but I’m not sure whether I’m missing something…)

[Gregable]

Ah, good catch. It does not. It only removes the parent restriction, not the amp-form.js requirement.

[mkhatib]

@Gregable I think this been implemented in the validator, no?

[Gregable]

Yes, this is live everywhere.