This is a tracking bug for implementing Web Forms 2.0 functionality.

Okay, I have faith that keyboard nav will happen, but who's thinking about accessibility API work that needs to be done?

I am most definitely thinking about a11y, aaronlev, but not a single bug on WF2 has had r+ or sr+. (Actually, no patches have been reviewed yet.) Accessibility is near the front of my list of things to think about, not the back. But I need to lay down some groundwork first.

Should bug 106590 block this bug? /be

It seems at least WeirdAl is workingon WF2 -- so who should own this bug? As I noted in another bug, design before implementation wins. So we should have a wiki page that is more than a stub, sketching the design. /be

(In reply to comment #3) > Should bug 106590 block this bug? Technically speaking, I don't think so. It does block bug 345512 (pattern attribute), though. (In reply to comment #4) > As I > noted in another bug, design before implementation wins. So we should have a > wiki page that is more than a stub, sketching the design. Well, we already have the WF2 spec to follow. The question is what do we need beyond that?

Decide how to implement it?

The spec is not a design specific to Gecko. I have hoped for a long time that we could use XBL, or XBL2, to implement a lot of WF2. A design doc on the wiki should list approaches and trade-offs or hard stops caused by platform limitations, requiring new C++ code. /be

Dean Edwards said that the IE-ready WF2 implementation he wrote, https://sourceforge.net/projects/wf2/, could be ported to Firefox. Can someone try that and see how it performs? It does not include the repeat stuff, Dean said, because he was waiting for another implementation with major market share do ship. Opera has an impl now, too. I would be thrilled if the Mozilla platform could support something like Dean's IE implementation, and it had sufficient performance and other goodness to be usable more or less as is (we'd ship it so it wouldn't have to be downloaded). /be

> and it had sufficient performance And if it doesn't, we should maybe work on that.

(In reply to comment #9) > > and it had sufficient performance > > And if it doesn't, we should maybe work on that. Right! Doing so is likely to have other benefits. Porting Dean's work also makes best use of the skills of the principals here, unless I'm mistaken. Not everyone should grovel through C++ and C hell, and most of Mozilla's platform wins are based on the ability to program with JS, XUL, XBL, CSS, etc. /be

cc'ing Dean Edwards, so he can follow our work here.

The IE implementation uses a bunch of JavaScript classes to represent the various WF2 interfaces. You can browse the class hierarchy here: http://webforms2.org/dev/ide/ I would imagine that each JS class would map directly to an XBL binding? With inheritance handled by XBL's extend attribute. We used a custom "super" method to access overridden methods. Not sure how this translates to XBL. There are obviously a number of IE specific hacks to get around some of IE's annoyances. The XBL version should be simpler as a result.

Whenever the fieldset disabled stuff is implemented, all the places that look at "disabled" attributes (e.g. accessibility, native theme stuff, etc) will need to be fixed to look at content states instead.

No movement for a whole year. Target missed. Wouldn't this be nice for 1.9.1? A word about the status would be nice as this affects my work for WaSP-EduTF's Curriculum project.

The "whole year" we were in feature freeze you mean? And what target? I don't think this is realistic for 1.9.1 given the time frame of that release (locking down in 2 months), but this is definitely a high priority to do. Chances are we want to implement this on top of XBL2, though.

Oops! I did not wish to sound critical. By now I've learned that what distinguishes Mozilla is a desire to fix bugs and implement features in a very robust way. I totally understand that sometimes things like this slow down. (Target? mozilla1.9alpha8...) Anyway, sorry about the noise and keep up the good work!

Oh, that was wishful thinking on the part of the bug reporter. ;)

Web Forms 2.0 has been superseded by HTML 5 forms. This bug should probably be renamed and the URL should point to the new spec.

FWIW, MediaWiki has started using HTML 5 forms as of now (email, required, autofocus, number, max, min), and that's likely to be deployed on Wikipedia within the next week: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/54567 This should be marked parity-opera, since Opera has implemented pretty much all of HTML 5 forms for a while now: http://www.opera.com/docs/specs/presto22/forms/

Are there any update on this? The following site can be used to check which input types is accepted: http://www.miketaylr.com/code/input-type-attr.html I have a hard time believing that this hasn't gone anywhere in the past years. This is one of the more nifty features in HTML5.

The "[parity-IE]" should be removed. IE currently supports the fewest HTML5 forms input attributes of all modern browsers, so I can't see how that got there in the first place.

Removed, Ehsan might want to comment why he added it (because of comment 8?)

(In reply to comment #23) > Removed, Ehsan might want to comment why he added it (because of comment 8?) Yes, that was my mistake. For some reason I though that support has been integrated into IE. :/

As I am going to work full time for at least a few months on HTML5 Forms, I've created a wiki page to explain how I want to do that and to summarize what have been done, what I'm doing and what I'm going to do: https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms Do not hesitate to comment my choices.

The currently supported elements/attributes would make a good addition to https://developer.mozilla.org/en/Upcoming_Firefox_features_for_developers :-)

When I look at https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms I see lots of bugs/patches that have the status "Ready to be landed". Why isn't this being done?

(In reply to comment #27) > When I look at https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms I see > lots of bugs/patches that have the status "Ready to be landed". Why isn't this > being done? That means they need or are related to the constraint validations. Olli and Jonas want to land all the constraint validation related attributes (from elements in the tree) at the same time to prevent having a part-implemented constraint validation mechanism. When the email patch will be r/sr, all these patches should be marked 'checkin-needed'. Btw, in the wiki page, when I set "checkin-needed" status, that means the patch need to be landed. When it's "Ready to be landed", that means it's ready but is waiting for something else.

For information, I've set up a user repository with a mq patch list so anyone can build Firefox with the patches that are not in mozilla-central but ready to be used: http://hg.mozilla.org/users/mlamouri_mozilla.com/html5forms-patchqueue/ If you see a patch missing in this patch queue or if you have trouble with it, feel free to send me an email. For any comment/bug regarding a patch, please, leave a comment on the related bug.

Has progress stalled on this, for now?

I don't know why you think that? There's a ton of action in the dependent bugs. This is just a tracker bug, no actual development will happen in this bug.

(In reply to comment #31) > I don't know why you think that? There's a ton of action in the dependent bugs. > > This is just a tracker bug, no actual development will happen in this bug. I've been subscribed to "all" dependent bugs for a while now, and I'm seeing a lack of updates there. I figured this was the best place to make a post on it, as it is the master bug. There hasn't been any major updates at https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms either for a while, as apparently, some patches are still awaiting a review.

(In reply to comment #30) > Has progress stalled on this, for now? I'm working on bigger elements like <progress> and <input type='number'> that may explain why the progress may sound to have stalled.

Interesting Webkit bug, what if a required element is invisible? https://bugs.webkit.org/show_bug.cgi?id=40908

When will the dom.experimental_forms stuff finally be finished?

We'll use a new bug to track the remainder.

Apologies for not mentioning the new bug, it's bug 1509461.