Bug 40520 - Support interactive form validation in quirks mode
Summary: Support interactive form validation in quirks mode
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 40218
Blocks: 28649
  Show dependency treegraph
 
Reported: 2010-06-12 04:47 PDT by Ms2ger (he/him; ⌚ UTC+1/+2)
Modified: 2011-05-05 15:08 PDT (History)
8 users (show)

See Also:


Attachments
Patch (13.16 KB, patch)
2010-07-01 03:02 PDT, Kent Tamura
webkit.review.bot: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ms2ger (he/him; ⌚ UTC+1/+2) 2010-06-12 04:47:29 PDT
HTML5 requires interactive form validation in all modes.
Comment 1 Kent Tamura 2010-06-13 18:52:26 PDT
(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
Comment 2 Ian 'Hixie' Hickson 2010-06-13 20:07:32 PDT
> > 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 whatwg@whatwg.org 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.
Comment 3 Kent Tamura 2010-06-13 21:38:23 PDT
(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 whatwg@whatwg.org 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
Comment 4 Maciej Stachowiak 2010-06-14 15:21:25 PDT
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.
----------
Comment 5 Kent Tamura 2010-06-14 18:50:20 PDT
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?
Comment 6 Maciej Stachowiak 2010-06-29 17:44:30 PDT
(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.
Comment 7 Darin Adler 2010-06-29 17:49:38 PDT
(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.
Comment 8 Kent Tamura 2010-07-01 03:02:11 PDT
Created attachment 60218 [details]
Patch
Comment 9 Ojan Vafai 2010-07-22 16:54:22 PDT
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
Comment 10 Kent Tamura 2010-07-27 00:17:01 PDT
(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.
Comment 11 Kent Tamura 2010-07-27 00:32:16 PDT
Landed as r64110.
Comment 12 WebKit Review Bot 2011-05-05 14:26:40 PDT
Comment on attachment 60218 [details]
Patch

Attachment 92436 [details] did not pass cr-mac-ews (chromium):
Output: http://queues.webkit.org/results/8571537
Comment 13 WebKit Review Bot 2011-05-05 15:08:14 PDT
Comment on attachment 60218 [details]
Patch

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