Bug 344614 (html5forms)

Implement HTML5 forms (Web Forms 2.0)

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
11 years ago
a month ago

People

(Reporter: WeirdAl, Unassigned)

Tracking

(Depends on: 14 bugs, Blocks: 1 bug, {dev-doc-needed, html5, meta})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-opera] [evang-wanted][docs see comment26], URL)

(Reporter)

Description

11 years ago
This is a tracking bug for implementing Web Forms 2.0 functionality.
(Reporter)

Updated

11 years ago
Depends on: 344615
(Reporter)

Updated

11 years ago
Depends on: 344616
(Reporter)

Updated

11 years ago
Depends on: 344618
(Reporter)

Updated

11 years ago
Depends on: 344629

Updated

11 years ago
No longer depends on: 344629

Updated

11 years ago
Depends on: 344629
(Reporter)

Updated

11 years ago
No longer depends on: 344629
(Reporter)

Updated

11 years ago
Depends on: 344655
(Reporter)

Updated

11 years ago
Depends on: 345512
(Reporter)

Updated

11 years ago
Depends on: 345624
(Reporter)

Updated

11 years ago
Alias: webforms2
(Reporter)

Updated

11 years ago
Depends on: 345822
(Reporter)

Updated

11 years ago
Depends on: 346485

Updated

11 years ago
Depends on: 346908
(Reporter)

Updated

11 years ago
Depends on: 347007
(Reporter)

Updated

11 years ago
Depends on: 347070

Comment 1

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

Comment 2

11 years ago
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
(Reporter)

Comment 5

11 years ago
(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
(Reporter)

Comment 11

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

Comment 12

11 years ago
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.

Updated

10 years ago
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.

Updated

10 years ago
Depends on: 389237

Comment 14

9 years ago
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.

Comment 16

9 years ago
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

Updated

9 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general

Updated

9 years ago
Target Milestone: mozilla1.9alpha8 → ---

Comment 18

8 years ago
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/

Updated

8 years ago
Whiteboard: [parity-opera]
Whiteboard: [parity-opera] → [parity-opera][parity-IE]
Duplicate of this bug: 541192

Comment 21

7 years ago
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.

Comment 22

7 years ago
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.

Comment 23

7 years ago
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

Updated

7 years ago
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

Updated

7 years ago
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

Comment 26

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

Updated

7 years ago
Whiteboard: [parity-opera] [evang-wanted] → [parity-opera] [evang-wanted][docs see comment26]
Keywords: dev-doc-needed
Depends on: 561586
Depends on: 561634
Depends on: 561635
Depends on: 561640
Depends on: 506554
Depends on: 562932

Comment 27

7 years ago
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.

Comment 30

7 years ago
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.

Comment 32

7 years ago
(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

Updated

7 years ago
Depends on: 312971

Comment 34

7 years ago
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
No longer depends on: 344655
Depends on: 595267
No longer depends on: 595267
Depends on: 582248
Depends on: 595282
Depends on: 595429
Depends on: 595447
Depends on: 595449

Updated

7 years ago
Depends on: 595507
No longer depends on: 595507
Depends on: 596511
Depends on: 596681
Depends on: 597650
No longer depends on: 583288

Updated

7 years ago
Depends on: 601061
Depends on: 600155
Depends on: 604673
Depends on: 605124
Depends on: 605125

Updated

7 years ago
Depends on: 605365

Updated

7 years ago
Depends on: 605997
Depends on: 606170
Depends on: 606491

Updated

7 years ago
No longer blocks: 581596
Depends on: 610687
No longer depends on: 558651
Depends on: 613016

Updated

7 years ago
Blocks: 568516
Depends on: 618260
Depends on: 182279

Updated

6 years ago
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

Updated

6 years ago
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

Updated

6 years ago
Depends on: 618876

Updated

5 years ago
Depends on: 711962
No longer depends on: 711962

Updated

5 years ago
Depends on: 717181

Updated

5 years ago
Duplicate of this bug: 725574

Updated

5 years ago
Duplicate of this bug: 753694

Updated

5 years ago
Duplicate of this bug: 810587
Depends on: 825294

Updated

4 years ago
Depends on: 801181

Comment 38

4 years ago
When will the dom.experimental_forms stuff finally be finished?
Depends on: 932755

Updated

3 years ago
Depends on: 961502

Updated

3 years ago
Duplicate of this bug: 1002384
Duplicate of this bug: 1002384

Updated

2 years ago
Depends on: 1203844

Updated

a year ago
Depends on: 1238029

Updated

a year ago
Depends on: 1206616

Updated

10 months ago
Depends on: 1285425
You need to log in before you can comment on or make changes to this bug.