Bug 40520 - Support interactive form validation in quirks mode
: Support interactive form validation in quirks mode
Status: RESOLVED FIXED
: WebKit
HTML DOM
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
:
:
: 40218
: 28649
  Show dependency treegraph
 
Reported: 2010-06-12 04:47 PST by
Modified: 2011-05-05 15:08 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2010-06-12 04:47:29 PST
HTML5 requires interactive form validation in all modes.
------- Comment #1 From 2010-06-13 18:52:26 PST -------
(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 From 2010-06-13 20:07:32 PST -------
> > 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 From 2010-06-13 21:38:23 PST -------
(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 From 2010-06-14 15:21:25 PST -------
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 From 2010-06-14 18:50:20 PST -------
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 From 2010-06-29 17:44:30 PST -------
(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 From 2010-06-29 17:49:38 PST -------
(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 From 2010-07-01 03:02:11 PST -------
Created an attachment (id=60218) [details]
Patch
------- Comment #9 From 2010-07-22 16:54:22 PST -------
(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
------- Comment #10 From 2010-07-27 00:17:01 PST -------
(In reply to comment #9)
> (From update of attachment 60218 [details] [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 From 2010-07-27 00:32:16 PST -------
Landed as r64110.
------- Comment #12 From 2011-05-05 14:26:40 PST -------
(From update of attachment 60218 [details])
Attachment 92436 [details] did not pass cr-mac-ews (chromium):
Output: http://queues.webkit.org/results/8571537
------- Comment #13 From 2011-05-05 15:08:14 PST -------
(From update of attachment 60218 [details])
Attachment 92436 [details] did not pass cr-mac-ews (chromium):
Output: http://queues.webkit.org/results/8589039