Disable interactive form validation in the compat mode
Created attachment 57992 [details] Patch
Created attachment 58468 [details] Patch 2
Comment on attachment 58468 [details] Patch 2 ok, but let's clarify ChangeLog a bit more. WebCore/ChangeLog:9 + HTML4, and users and page authors don't expect existing sites work There is no interactive validation in HTML4. "required" is just something developers started throwing on pages without thinking. Right? WebCore/ChangeLog:12 + modes to keep compatibility as possible. Wording suggestion -- "to improve compatibility."
(In reply to comment #3) > (From update of attachment 58468 [details]) > ok, but let's clarify ChangeLog a bit more. > > WebCore/ChangeLog:9 > + HTML4, and users and page authors don't expect existing sites work > There is no interactive validation in HTML4. "required" is just something developers started throwing on pages without thinking. Right? Right. It seems some existing form validation JS libraries have used "required" attribute not for HTML5. > > WebCore/ChangeLog:12 > + modes to keep compatibility as possible. > Wording suggestion -- "to improve compatibility." OK, I'll change so.
Committed: http://trac.webkit.org/changeset/61059
<rdar://problem/8088419>
I’m not sure that compatibility mode vs. strict mode is the way to handle this. Maybe someone made the mistake on a website in strict mode too.
We don’t usually make whole new features work only in strict mode. I don’t have any other suggestion at the moment, but I think doing this may reflect some misunderstanding of how effective “quirks vs. strict” really is. Mainly it’s good for slightly rendering tweaks and seems less good for turning off entire features like this one.
(In reply to comment #7) > I’m not sure that compatibility mode vs. strict mode is the way to handle this. Maybe someone made the mistake on a website in strict mode too. We can say "your website doesn't conform to HTML5" in that case. But we can't say it for existing HTML4 sites. Please look at Bug#40520 too.
(In reply to comment #9) > (In reply to comment #7) > > I’m not sure that compatibility mode vs. strict mode is the way to handle this. Maybe someone made the mistake on a website in strict mode too. > > We can say "your website doesn't conform to HTML5" in that case. But we can't say it for existing HTML4 sites. > > Please look at Bug#40520 too. 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.
This violates the HTML5 spec. HTML5 clearly specifies exactly how UAs are to behave in quirks mode -- conformant UAs are expected to behave interoperably in quirks mode just as in standards mode. If WebKit is going to behave differently in quirks mode here, you should tell this to the WHATWG (or HTMLWG) so that it can be added to the spec if other implementers agree it's a good approach. (I don't think it sounds like a good approach; there are only a few sites with the problem and they'll probably fix themselves when they break in both WebKit and Gecko.)
Oops, I missed the discussion on bug 40520. Never mind me.