Bug 40520 – Support interactive form validation in quirks mode

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Ms2ger (he/him; ⌚ UTC+1/+2)]

HTML5 requires interactive form validation in all modes.

[Kent Tamura]

(In reply to comment #0)

As you know, I disabled the interactive validation in non-strict modes in http://trac.webkit.org/changeset/61059

> HTML5 requires interactive form validation in all modes.

I don't think so.

If the specification asked to do so, we would violate it in WebKit.  Safari 5 and Chrome 5 support the interactive validation in all modes for now, but it made multiple compatibility issues or users faced form validation bugs unnecessarily.

http://crbug.com/44048
http://crbug.com/45640
http://crbug.com/45831
http://crbug.com/46335
http://crbug.com/46358
https://bugs.webkit.org/show_bug.cgi?id=40429

[Ian 'Hixie' Hickson]

> > HTML5 requires interactive form validation in all modes.
> 
> I don't think so.

Where does it say otherwise?


> If the specification asked to do so, we would violate it in WebKit.

That's not how standards work. When you find something in the spec you don't like, you bring it up with the working group, you don't just unilaterally get to ignore the spec. Otherwise, you're no better than Microsoft. Send an e-mail to [e-mail] saying what the problems were, and we'll fix the spec. It won't be by adding yet more quirks differences.

Note that Chrome is very buggy if it is just blocking form submission without telling the user why.

[Kent Tamura]

(In reply to comment #2)
> > > HTML5 requires interactive form validation in all modes.
> > 
> > I don't think so.
> 
> Where does it say otherwise?

[1] says:
Note: DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.

The interactive form validation is incompatible with prior HTMLs.  So browsers may disable it for non-HTML5 modes to follow prior HTML specifications.

> That's not how standards work. When you find something in the spec you don't like, you bring it up with the working group, you don't just unilaterally get to ignore the spec. Otherwise, you're no better than Microsoft. Send an e-mail to [e-mail] saying what the problems were, and we'll fix the spec. It won't be by adding yet more quirks differences.

I posted a part of issues to whatwg.  See the thread with subject "Form validation against invisible controls", and my conclusion is to disable the interactive validation in non-HTML5 modes. I'll post this conclusion soon.

> Note that Chrome is very buggy if it is just blocking form submission without telling the user why.

yeah, I understand it.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#the-doctype

[Maciej Stachowiak]

I think the fix for bug 40218 was wrong. Limiting a new feature to strict mode is not an appropriate way to deal with Web compatibility problems. Instead, we should get the standard changed. Here are my comments from that bug:

---------
Existing HTML4 sites can also be in strict mode. In fact, a fair number of HTML4 sites have a standards mode or almost standards mode doctype. I don't think we should make new features be based on a  modeswitch. The philosophy of HTML5 is to make new features backwards-compatible so they can be progressively deployed on existing sites. If HTML5 @required causes too much compatibility fallout, then we should:

(a) Remove HTML5 @required support entirely for now.
(b) Report our findings to the HTML WG and proposed renaming the attribute.

I don't think making the feature strict-mode only is an appropriate fix.
----------

[Kent Tamura]

ok, I'll revert r61059 when
 - The current whatwg discussion makes an agreement and a WebKit change for it is landed if needed, and
 - Bug#31718 and some platform implementation are completed.
  I have received some complaints about no validation message when form submission is blocked.

Make sense?

[Maciej Stachowiak]

(In reply to comment #5)
> ok, I'll revert r61059 when
>  - The current whatwg discussion makes an agreement and a WebKit change for it is landed if needed, and
>  - Bug#31718 and some platform implementation are completed.
>   I have received some complaints about no validation message when form submission is blocked.
> 
> Make sense?

I think the right thing to do in the short term would be to disable @required entirely, or to make it a non-default runtime switch, rather than to disable it only in quirks mode. Making it a standards-mode-only feature is worse than disabling it entirely, in my opinion.

[Darin Adler]

(In reply to comment #6)
> I think the right thing to do in the short term would be to disable @required entirely, or to make it a non-default runtime switch, rather than to disable it only in quirks mode. Making it a standards-mode-only feature is worse than disabling it entirely, in my opinion.

I agree with Maciej about the short term.

[Kent Tamura]

Created attachment 60218 [details]
Patch

[Ojan Vafai]

Comment on attachment 60218 [details]
Patch

> +        // This setting will be removed when an HTML5 compatibility issue is
> +        // resolvled and WebKit implementation of interactive validation is

Typo: resolved

[Kent Tamura]

(In reply to comment #9)
> (From update of attachment 60218 [details])
> > +        // This setting will be removed when an HTML5 compatibility issue is
> > +        // resolvled and WebKit implementation of interactive validation is
> 
> Typo: resolved

Fixed.

[Kent Tamura]

Landed as r64110.

[WebKit Review Bot]

Comment on attachment 60218 [details]
Patch

Attachment 92436 [details] did not pass cr-mac-ews (chromium):
Output: http://queues.webkit.org/results/8571537

[WebKit Review Bot]

Comment on attachment 60218 [details]
Patch

Attachment 92436 [details] did not pass cr-mac-ews (chromium):
Output: http://queues.webkit.org/results/8589039