Closed Bug 344614 Opened 18 years ago Closed 5 years ago

[meta] Implement HTML5 forms (Web Forms 2.0)

Categories

(Core :: DOM: Core & HTML, defect, P2)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: WeirdAl, Unassigned)

References

(Depends on 11 open bugs, )

Details

(Keywords: html5, meta, Whiteboard: [evang-wanted][docs see comment26])

This is a tracking bug for implementing Web Forms 2.0 functionality.
Depends on: 344615
Depends on: 344616
Depends on: 344618
Depends on: 344629
No longer depends on: 344629
Depends on: 344629
No longer depends on: 344629
Depends on: 344655
Depends on: 345512
Depends on: 345624
Alias: webforms2
Depends on: 345822
Depends on: 346485
Depends on: 346908
Depends on: 347007
Depends on: 347070
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.
Depends on: 377624
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.
Depends on: html5a11y
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.  ;)
Depends on: 446510
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
Target Milestone: mozilla1.9alpha8 → ---
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.
Keywords: html5
OS: Windows XP → All
Hardware: x86 → All
Summary: Implement Web Forms 2.0 → Implement HTML5 forms (Web Forms 2.0)
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/
Whiteboard: [parity-opera]
Whiteboard: [parity-opera] → [parity-opera][parity-IE]
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?)
Whiteboard: [parity-opera][parity-IE] → [parity-opera]
(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.  :/
Depends on: 546995
Depends on: 547004
Blocks: 457800
No longer blocks: 457800
Depends on: 457800
Depends on: 456229
Depends on: 535043
Depends on: 536891
Depends on: 536895
Depends on: 549475
Depends on: 551670
Depends on: 551846
Depends on: 555559
Depends on: 555567
Assignee: general → nobody
Depends on: 555840
Depends on: 514437
Depends on: 555985
Depends on: 556007
Depends on: 556009
Depends on: 556010
Depends on: 556013
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.
Depends on: 556743
Depends on: 557087
Whiteboard: [parity-opera] → [parity-opera] [evang-wanted]
Depends on: 557620
Depends on: 557628
Depends on: 558063
Depends on: 558593
Depends on: 558594
Depends on: 558651
Depends on: 559463
The currently supported elements/attributes would make a good addition to https://developer.mozilla.org/en/Upcoming_Firefox_features_for_developers :-)
Whiteboard: [parity-opera] [evang-wanted] → [parity-opera] [evang-wanted][docs see comment26]
Depends on: 561586
Depends on: 561634
Depends on: 561635
Depends on: 561640
Depends on: 506554
Depends on: 562932
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.
Depends on: 565272
Depends on: 565274
Depends on: 566064
Alias: webforms2 → html5forms
Depends on: 566160
Depends on: 567740
Depends on: 567872
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.
Depends on: 572145
Depends on: 312971
Interesting Webkit bug, what if a required element is invisible? https://bugs.webkit.org/show_bug.cgi?id=40908
Depends on: 558788
Depends on: 561636
Blocks: 581596
Depends on: 582412
Depends on: 583586
Depends on: 583610
Depends on: 585508
Depends on: 588683
Depends on: 583289
Depends on: 583288
Depends on: 589490
Depends on: 589696
Depends on: 595267
No longer depends on: 595267
Depends on: 582248
Depends on: 595282
Depends on: 595429
Depends on: 595447
Depends on: 595449
Depends on: 595507
No longer depends on: 595507
Depends on: 596511
Depends on: 596681
Depends on: 597650
No longer depends on: 583288
Depends on: 601061
Depends on: 600155
Depends on: 604673
Depends on: 605124
Depends on: 605125
Depends on: 605365
Depends on: 605997
Depends on: 606170
Depends on: 606491
No longer blocks: 581596
Depends on: 610687
No longer depends on: 558651
Depends on: 613016
Blocks: html
Depends on: 618260
Depends on: 182279
Depends on: 619278
No longer depends on: 619278
No longer depends on: 618260
Depends on: 623153
Depends on: 623538
Depends on: 624174
Depends on: 627409
Depends on: 627657
Depends on: 633207
No longer depends on: 514437
No longer depends on: 567872
No longer depends on: 556010
No longer depends on: 556009
Depends on: 639656
Depends on: 639660
Depends on: 640953
Depends on: 596515
Depends on: 618876
Depends on: 711962
No longer depends on: 711962
Depends on: 717181
Depends on: 825294
Depends on: 801181
When will the dom.experimental_forms stuff finally be finished?
Depends on: 932755
Depends on: 961502
Depends on: 1203844
Depends on: 1238029
Depends on: 1206616
Depends on: 1285425
Whiteboard: [parity-opera] [evang-wanted][docs see comment26] → [evang-wanted][docs see comment26]
Depends on: 1445061
Priority: -- → P2
We'll use a new bug to track the remainder.
Alias: html5forms
No longer blocks: html
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Apologies for not mentioning the new bug, it's bug 1509461.
Summary: Implement HTML5 forms (Web Forms 2.0) → [meta] Implement HTML5 forms (Web Forms 2.0)
You need to log in before you can comment on or make changes to this bug.