This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 17210 as part of operation convergence. Originally filed: 2012-05-27 10:06:00 +0000 Original reporter: Mounir Lamouri <mounir.lamouri@gmail.com> ================================================================================ #0 Mounir Lamouri 2012-05-27 10:06:02 +0000 -------------------------------------------------------------------------------- In other word, if we have: <form id='a'></form> <fieldset form='a'> <input> </fieldset> The input element should be associated the form 'a'. I'm not sure if we should ignore <input form='b'> or allow it. See this Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=755215 ================================================================================
I looked into doing this, but the changes required at the parser level are gnarly. We'd have to have a separate fieldset element pointer, which overrode the form element pointer when it's not null, etc. Are we sure we want to do that?
Yuck. Why not just put the input element inside the form element?
Adam: Not sure what you mean. Can you elaborate?
> Adam: Not sure what you mean. Can you elaborate? I don't remember what I was thinking exactly, but I would guess I was asking about the use case. It seems much easier to just make the input element a child of the form element.
(In reply to comment #4) > > Adam: Not sure what you mean. Can you elaborate? > > I don't remember what I was thinking exactly, but I would guess I was asking > about the use case. It seems much easier to just make the input element a > child of the form element. The entire idea of @form is to not do that. So I'm not sure what your point is.
Mounir: How strongly do you feel about your original request? Any ideas on how to do this without the parser pain? I agree that it makes sense, but right now I'm thinking the cost is too high...
Marking this WONTFIX for now. If you disagree, even in the light of the parser cost, please reopen the bug and elaborate on why this is important. Thanks!
Spec writing cost and implementation cost are worth it if it eases author's life. In that case, the original bug report was genuinely someone believing that he was allowed to do: <form id='a'> </form> <fieldset form='a'> <input> </fieldset> And have the fieldset and the input inside the form a (which is honestly the behaviour I would except by reading the snippet without knowing much about the fieldset's spec). The fieldset behaves like a container and I think authors are eager to make that happen more. From Gecko's input, fieldset can now disable all form controls inside itself. We got some author's feedback to have fieldsets marked as invalid when they contain invalid form controls and we had this feedback to have form control's @form inheriting from their fieldset's @form. I think we should continue in that direction and put more logic inside fieldset to have the element be more than an ugly grey rectangle in the page. I understand that it wouldn't be easy to specify (nor to implement) but it would with no doubt make author's life easier.
If something is really hard to implement (and spec), it's likely to be full of bugs. Authors like buggy browsers even less than the lack of a feature. So that's why implementation complexity is a relevant concern. Doing this in the simplest manner would mean making the following changes: 1. "If an element created by the insert an HTML element algorithm is a form- associated element, and the form element pointer is not null, and the newly created element doesn't have a form attribute," INSERT: and neither the current element nor any of its ancestors are <code>fieldset</code> elements with a <code title="attr-fieldset-form">form</code> attribute, "the user agent must associate the newly created element with the form element pointed to by the form element pointer when the element is inserted, instead of running the reset the form owner algorithm." 2. Update "reset the form owner" by prepending a step that determines the owner via fieldset elements, defaulting to "its nearest form element ancestor after the change to the ancestor chain", then replace that string with a reference to the owner determined by that new step, and fix step 4 in a similar fashion. 2. Define the "form" attribute on <fieldset>. This attempts to minimise risk by doing nothing if there's no form="" attributes, but I don't know if that's enough. Is the above ok?
I will let Henri gives his opinion on the matter. I do not know the parser spec/code well enough to review this proposal.
(In reply to comment #10) > I will let Henri gives his opinion on the matter. I do not know the parser > spec/code well enough to review this proposal. I concur with Hixie. I think we shouldn't complicate things by allowing a form attribute with inheritance on <fieldset> due to the reasons of complexity when it comes to interaction with legacy craziness.
It looks like there's no implementor interest, assuming Henri overrides Mounir here. :-) Should I mark this WONTFIX then?
I'd be happy with WONTFIX.
Given the lack of interest from browser vendors for supporting this, I'm going back to WONTFIX to get this off my radar. If a browser vendor wants to implement this, please do so and reopen the bug.