Re: [whatwg] The legend element
On Tue, 13 Oct 2009, Markus Ernst wrote:
> Ian Hickson schrieb:
> >
> > I would recommend not using and for rows 2 and 3.
> >
> > As in:
> >
> > Placeholder outputs of 2nd row:
> >
> > {label}: What is favourite pet?
> >
> > {input-html}:
> > Cat
> > Dog
> > Ant
> >
> >
> > Placeholder outputs of 3rd row:
> >
> > {label}: When are you born?
> >
> > {input-html}:
> > Month:
> >
> >January
> >...
> >
> >
> > Year:
> >
> > Why isn't that satisfactory?
>
> It is, if omitting does not do any harm, such as lower the
> accessibility of the form.
I don't see why it would, especially in your example where everything is
in a cell anyway.
> If this is the case, and I read paragraph 4.10.2 of the spec correctly,
> serves exactly 2 purposes:
> - Adds possibility to group-disable it's descendants
> - Can assign it's descendants to a form, when they are placed outside the form
> element in the code
It also adds the possibility of grouping form controls under a single
name, and of providing groups of controls for understanding the form.
> Is this correct? Then it might be nice to clarify this with a few words
> in the spec, as "The fieldset element represents a set of form controls
> optionally grouped under a common name" can be read as implying
> structuring and thus accessibility matters.
The element does add structure and help with accessibility, but that
doesn't mean it's always necessary.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The legend element
Ian Hickson schrieb:
[...]
I would recommend not using and for rows 2 and 3.
As in:
Placeholder outputs of 2nd row:
{label}: What is favourite pet?
{input-html}:
Cat
Dog
Ant
Placeholder outputs of 3rd row:
{label}: When are you born?
{input-html}:
Month:
January
...
Year:
Why isn't that satisfactory?
It is, if omitting does not do any harm, such as lower the
accessibility of the form. If this is the case, and I read paragraph
4.10.2 of the spec correctly, serves exactly 2 purposes:
- Adds possibility to group-disable it's descendants
- Can assign it's descendants to a form, when they are placed outside
the form element in the code
Is this correct? Then it might be nice to clarify this with a few words
in the spec, as "The fieldset element represents a set of form controls
optionally grouped under a common name" can be read as implying
structuring and thus accessibility matters.
Re: [whatwg] The legend element
On Mon, 12 Oct 2009, Markus Ernst wrote:
>
> My use case is a template system with separate placeholders for labels
> and input fields, where input fields can be fieldsets in some cases,
> e.g.:
>
> Relevant part of the template:
>
>
>
> {label}
> {input-html}
>
>
>
> Placeholder outputs of first row:
>
> {label}: What is your name?
>
> {input-html}:
>
>
>
> Placeholder outputs of 2nd row:
>
> {label}: What is favourite pet?
>
> {input-html}:
>
> Cat
> Dog
> Ant
>
>
>
> Placeholder outputs of 3rd row:
>
> {label}: When are you born?
>
> {input-html}:
>
> Month:
>
> January
> ...
>
>
> Year:
>
>
>
> Rows 2 and 3 illustrate the use case. For my original suggestion replace
> with in those rows.
Ah, I see.
I would recommend not using and for rows 2 and 3.
As in:
Placeholder outputs of 2nd row:
{label}: What is favourite pet?
{input-html}:
Cat
Dog
Ant
Placeholder outputs of 3rd row:
{label}: When are you born?
{input-html}:
Month:
January
...
Year:
Why isn't that satisfactory?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The legend element
Ian Hickson schrieb:
On Mon, 12 Oct 2009, Markus Ernst wrote:
Ian Hickson schrieb:
Additionnally I want to suggest to make it possible to place the
legend element outside the fieldset element, providing a "for"
attribute (just as it is possible to place the label element apart
from it's form field element).
This is significantly harder to pull off, for the same reason that we
haven't been able to use for . I recommend we wait
for the next version of HTML before doing this.
Would it be possible and easy to allow for fieldsets?
I don't understand the use case.
I am sorry I seem to have missed to make the use case really
transparent. My use case is a template system with separate placeholders
for labels and input fields, where input fields can be fieldsets in some
cases, e.g.:
Relevant part of the template:
{label}
{input-html}
Placeholder outputs of first row:
{label}: What is your name?
{input-html}:
Placeholder outputs of 2nd row:
{label}: What is favourite pet?
{input-html}:
Cat
Dog
Ant
Placeholder outputs of 3rd row:
{label}: When are you born?
{input-html}:
Month:
January
...
Year:
Rows 2 and 3 illustrate the use case. For my original suggestion replace
with in those rows.
This looks somehow consistent to me:
Favorite pet?
Cat
Dog
Ant
Why is this preferable to:
Favorite pet?
Cat
Dog
Ant
It is in a case where you want to output the label/legend separate from
the fieldset HTML, as in the above example.
or:
Favorite pet?
Cat
Dog
Ant
Why is this preferable to the above?
This is not preferable, I just mentioned this as it is the other way
can be applied.
I don't understand why the and can't be in the
template.
That is how I do it now. The downside of it is the fact that some
themplate authors might forget it - a relevant number of web designers
in fact don't even know about fieldsets, as forms usually "work" with or
without them. Anyway it is not a big problem; it would just be a nice
enhancement of consistency if the template engine were able to output
*all* form structuring elements.
I don't understand the problem, but if it's not a big problem, then I
would suggest we punt on it until the next version.
I know the HTML5 spec is quite advanced already. Having for
(or outside it) would make things easier in some
special cases, and maybe also promote the use of fieldsets. If this is a
non-trivial change or even possibly introduces new problems, of course
it might be better to schedule it for later versions.
Re: [whatwg] The legend element
On Mon, 12 Oct 2009, Markus Ernst wrote: > Ian Hickson schrieb: > > > > > Additionnally I want to suggest to make it possible to place the > > > legend element outside the fieldset element, providing a "for" > > > attribute (just as it is possible to place the label element apart > > > from it's form field element). > > > > This is significantly harder to pull off, for the same reason that we > > haven't been able to use for . I recommend we wait > > for the next version of HTML before doing this. > > Would it be possible and easy to allow for fieldsets? I don't understand the use case. > This looks somehow consistent to me: > > Favorite pet? > > Cat > Dog > Ant > Why is this preferable to: Favorite pet? Cat Dog Ant ...? > or: > > > Favorite pet? > > Cat > Dog > Ant > > Why is this preferable to the above? > > I don't understand why the and can't be in the > > template. > > That is how I do it now. The downside of it is the fact that some > themplate authors might forget it - a relevant number of web designers > in fact don't even know about fieldsets, as forms usually "work" with or > without them. Anyway it is not a big problem; it would just be a nice > enhancement of consistency if the template engine were able to output > *all* form structuring elements. I don't understand the problem, but if it's not a big problem, then I would suggest we punt on it until the next version. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The legend element
Ian Hickson schrieb:
Additionnally I want to suggest to make it possible to place the legend
element outside the fieldset element, providing a "for" attribute (just
as it is possible to place the label element apart from it's form field
element).
This is significantly harder to pull off, for the same reason that we
haven't been able to use for . I recommend we wait for
the next version of HTML before doing this.
Would it be possible and easy to allow for fieldsets? This looks
somehow consistent to me:
Favorite pet?
Cat
Dog
Ant
or:
Favorite pet?
Cat
Dog
Ant
Background: When writing template based applications, it can be useful
to provide a placeholder for the whole fieldset, and another one for the
legend, as template authors might want to place or style them
individually.
Example - a questionnaire:
Template Variable {question} outputs:
What ist your favorite Pet?
Template Variable {answers} outputs:
Cat
Dog
Ant
One author might want to use this template:
{question}
{answers}
The other one prefers:
{question}
{answers}
While the desired results can be easily achieved with the current legend
specification when coding manually, it is quite hard to implement with a
template system, needing separate template variables for both the
fieldset start and end tags, and a loop for the questions. With the
focus of making an application as easy to use as possible (which
includes template authoring), application authors might rather go
without fieldset and legend, and accept the loss of structural
consistency and accessibility as a trade-off.
I am sure this change would not break legacy content in new browsers;
anyway I have no Idea how far it would break HTML5 content in legacy
browsers.
I don't understand why the and can't be in the
template.
That is how I do it now. The downside of it is the fact that some
themplate authors might forget it - a relevant number of web designers
in fact don't even know about fieldsets, as forms usually "work" with or
without them. Anyway it is not a big problem; it would just be a nice
enhancement of consistency if the template engine were able to output
*all* form structuring elements.
Re: [whatwg] The legend element
On Thu, 8 Oct 2009, Markus Ernst wrote:
>
> I found this post by Ian Hickson from August 15, 2006 in the list
> archive:
>
> > On Sat, 1 Apr 2006, Henri Sivonen wrote:
> > >
> > > Since the omission of does not cause any horrible effects,
> > > I suggest making optional and reaffirming that if it
> > > appears, it can appear only once per and only as the
> > > first child (ignoring whitespace).
> >
> > I agree, and I will do this as part of HTML5, where I am defining
> > content models. If you don't object, I'll leave this change out of WF2
> > for now. (If you do object, then let me know, and I'll shoehorn it in
> > somehow.)
>
> It looks like this change has not made it into the HTML5 spec so far.
Oops. Done.
> Additionnally I want to suggest to make it possible to place the legend
> element outside the fieldset element, providing a "for" attribute (just
> as it is possible to place the label element apart from it's form field
> element).
This is significantly harder to pull off, for the same reason that we
haven't been able to use for . I recommend we wait for
the next version of HTML before doing this.
> Background: When writing template based applications, it can be useful
> to provide a placeholder for the whole fieldset, and another one for the
> legend, as template authors might want to place or style them
> individually.
>
> Example - a questionnaire:
>
> Template Variable {question} outputs:
> What ist your favorite Pet?
>
> Template Variable {answers} outputs:
>
> Cat
> Dog
> Ant
>
>
> One author might want to use this template:
> {question}
> {answers}
>
> The other one prefers:
>
>
> {question}
> {answers}
>
>
>
> While the desired results can be easily achieved with the current legend
> specification when coding manually, it is quite hard to implement with a
> template system, needing separate template variables for both the
> fieldset start and end tags, and a loop for the questions. With the
> focus of making an application as easy to use as possible (which
> includes template authoring), application authors might rather go
> without fieldset and legend, and accept the loss of structural
> consistency and accessibility as a trade-off.
>
> I am sure this change would not break legacy content in new browsers;
> anyway I have no Idea how far it would break HTML5 content in legacy
> browsers.
I don't understand why the and can't be in the
template.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] The legend element
I found this post by Ian Hickson from August 15, 2006 in the list archive:
> On Sat, 1 Apr 2006, Henri Sivonen wrote:
> >
> > Since the omission of does not cause any horrible effects,
> > I suggest making optional and reaffirming that if it
> > appears, it can appear only once per and only as the
> > first child (ignoring whitespace).
>
> I agree, and I will do this as part of HTML5, where I am defining
> content models. If you don't object, I'll leave this change out of WF2
> for now. (If you do object, then let me know, and I'll shoehorn it in
> somehow.)
It looks like this change has not made it into the HTML5 spec so far.
Additionnally I want to suggest to make it possible to place the legend
element outside the fieldset element, providing a "for" attribute (just
as it is possible to place the label element apart from it's form field
element).
Background: When writing template based applications, it can be useful
to provide a placeholder for the whole fieldset, and another one for the
legend, as template authors might want to place or style them individually.
Example - a questionnaire:
Template Variable {question} outputs:
What ist your favorite Pet?
Template Variable {answers} outputs:
Cat
Dog
Ant
One author might want to use this template:
{question}
{answers}
The other one prefers:
{question}
{answers}
While the desired results can be easily achieved with the current legend
specification when coding manually, it is quite hard to implement with a
template system, needing separate template variables for both the
fieldset start and end tags, and a loop for the questions. With the
focus of making an application as easy to use as possible (which
includes template authoring), application authors might rather go
without fieldset and legend, and accept the loss of structural
consistency and accessibility as a trade-off.
I am sure this change would not break legacy content in new browsers;
anyway I have no Idea how far it would break HTML5 content in legacy
browsers.
