Re: [whatwg] Markup-related feedback
On 10/27/14, Ian Hickson i...@hixie.ch wrote:
On Fri, 24 Jan 2014, Jukka K. Korpela wrote:
2014-01-22 2:28, Ian Hickson wrote:
On Tue, 3 Dec 2013, Jukka K. Korpela wrote:
Thank you for the clarifications. I may have been stuck to an idea
of a submittable element, possibly adopted from some earlier version
or proposal. I think an explicit short note like The output element
is not submittable would be useful.
I am reluctant to add that kind of comment for a couple of reasons.
First, there's the problem of determining when one would add these
notes. Should the spec be explicit about everything it doesn't say?
No, but it should be explicit about things that could easily be
misunderstood.
Fair enough. I've added some text to this effect.
What I would rather do is clarify whatever led to the confusion in the
first place. Do you have any idea what it is in the output section
that might lead you to think that it would be submittable?
Well, it is under the heading 4.10 Forms. As an element for the result
of some scripted operation (which output seems to be meant for),
output need not have anything to do with forms. But when it is under
Forms, a natural idea is oh, this is for some computed value, like a
total, to be submitted.
In the sentence I added, I added a mention of why there's a relationship
to forms.
(A submittable output element would a natural thing to have in many
cases, e.g. in showing some calculated total to the user and
submitting it along with form data, for checking purposes.)
Can you elaborate on this use case? I'm not sure how it would work.
When you calculate the total with JavaScript, mainly to be shown to the
user, you might as well submit it along with the form, as an extra
check. If it does not match the total calculated in the server,
something went very wrong. What you do then is a different question, but
the important thing is that you detect a problem, instead of charging an
amount that differs from what the user saw.
Fair enough. You can do this with type=hidden, for what it's worth.
The main reason for not submitting it so far has been that it would
risk authors relying on the client's computation and thus not doing it
on the server,
Authors often rely too much on checks and computations made client-side
- including new features like @pattern and @required attributes and new
values of the @type attribute. They have always been able to do that
with calculated totals, for example - just using an input element
(possibly with @readonly).
Right. But this makes it easier.
Without name=, the main purpose of output -- making it easy to
update non-form-control values in script -- is lost.
The @name attribute in general, except for submittable controls, is
legacy markup that has caused much confusion. It was introduced long
ago, before @id was added to HTML, for scripting purposes, on @img and
@form, as well as on @a for link destinations, but it was unsuitable
from the beginning. It was not defined to be unique in the document, and
there have been many attempts to phase out/deprecate/obsolete @name
(except for submittable fields, where it need not be unique).
So it looks a bit odd to introduce @name for a new element.
What you say is true for some uses of name=, but in the form API in
particular, name= works pretty well, due to the elements object.
Consider what this would look like without the form.elements API:
form name=main
Result: output name=result/output
script
document.forms.main.elements.result.value = 'Hello World';
/script
/form
With output id=result/output, it would have
document.getElementById('result').value = 'Hello World'
and if jQuery is used (and more than half of the world uses it, or
something similar), it would have
$('#result') = 'Hello World'
I would say that both ways are simpler than the property chain
document.forms.main.elements.result.value and, moreover, a way that can
be used to access any element, not just output.
I guess this is an area where opinions differ.
Well, more or less by definition, [if] output is appropriate for
something, it's more appropriate than span would be, since span is
more generic. span is like the fall back element, it has
essentially no semantics at all.
That's a rather theoretical proposition. You say that output is for a
result of a calculation or user agent and call this semantics.
That's basically how that works, yes. :-)
But how would that be a tangible benefit.
The main benefit is the one I describe above, the way it interacts with
the form elements API. The benefit of the semantics is the same as the
benefits of any semantics, mainly that it makes code maintenance easier,
makes it easier for new authors to enter a project and know what's going
on, etc.
I think the improvement of o relative to
document.getElementById('o') should be
Re: [whatwg] Markup-related feedback
On 12/30/14, Michael Gratton m...@vee.net wrote: On Tue, 30 Dec, 2014 at 5:12 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: [snip] - alerts false This result, in a way, seems to contradict the following:- | The disabled attribute, when specified, causes all | the form control descendants of the fieldset element, | excluding those that are descendants of the fieldset | element's first legend element child, if any, to be disabled. http://www.w3.org/TR/html5/forms.html#the-fieldset-element This behaviour is useful from the user's perspective: If a user first disables then re-enables a fieldset, the disabled state of descendant controls should persist. E.g. if the fieldset contains a control that is not disabled, then on re-enabling the fieldset the control should one again be not disabled. Yes. The behaviour of the disabled attribute you find above makes sense under those circumstances: It reflects the disabled state of the control were its ancestor fieldsets (if any) not disabled - it doesn't reflect if it would included in a submission or not. No. The disabled attribute about is about FIELDSET element. The `disabled` property of the FIELDSET reflects the attribute. And if its value is true - `fieldset.disabled = true` - then the descendant elements of that feildset are not going to be submitted. http://jsfiddle.net/wmu9jg7s/1/ form action=http://www.example.net; target=_blank fieldset id=a tabletrtdinput name=b id=b//table /fieldset input type=submit /form script // Disable the fieldset to make all its form control // descendants to be disabled // [1] // document.getElementById(a).disabled = true; // Are they? Lets see: //alert(document.getElementById(b).disabled); /script If the form is submitted as is, the target location is http://www.example.net/?b= Uncomment [1] and you'll see no ?b= http://www.example.net/ Given the variety of conditions in both the spec and in browser implementations that would make a control eligible for success, maybe it would be useful it have an attribute like 'enabled' - but what's the use case? element.matches(:disabled) - does what I want. The way to determine if a control is disabled has always been to check its disabled property, `el.disabled`. Code that uses this approach instead of matches(:disabled) won't work, and that is most code and most libraries. To determine if a form control is enabled, use: element.matches(:disabled) where supported; `disabled` elsewhere. -- Garrett @xkit ChordCycles.com garretts.github.io
Re: [whatwg] Markup-related feedback
On Tue, 30 Dec, 2014 at 5:12 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: [snip] - alerts false This result, in a way, seems to contradict the following:- | The disabled attribute, when specified, causes all | the form control descendants of the fieldset element, | excluding those that are descendants of the fieldset | element's first legend element child, if any, to be disabled. http://www.w3.org/TR/html5/forms.html#the-fieldset-element This behaviour is useful from the user's perspective: If a user first disables then re-enables a fieldset, the disabled state of descendant controls should persist. E.g. if the fieldset contains a control that is not disabled, then on re-enabling the fieldset the control should one again be not disabled. The behaviour of the disabled attribute you find above makes sense under those circumstances: It reflects the disabled state of the control were its ancestor fieldsets (if any) not disabled - it doesn't reflect if it would included in a submission or not. Given the variety of conditions in both the spec and in browser implementations that would make a control eligible for success, maybe it would be useful it have an attribute like 'enabled' - but what's the use case? //Mike -- ⊨ Michael Gratton, Percept Wrangler. ⚙ http://mjog.vee.net/
Re: [whatwg] Markup-related feedback
On 10/27/14, Ian Hickson i...@hixie.ch wrote: On Fri, 24 Jan 2014, Jukka K. Korpela wrote: 2014-01-22 2:28, Ian Hickson wrote: On Tue, 3 Dec 2013, Jukka K. Korpela wrote: [...] 3. To determine if a form control is eligible for success (see below) `HTMLFormControl.isEnabled` What's the use case? Would an unchecked checkbox be considered eligible by this criteria? That's irrelevant. Successful form controls, as defied in HTML4. [...] Disabling a fieldset disables its descendant controls but does not change their disabled property. Thus, a disabled fieldset's descendant controls won't succeed, however, its descendant controls' `disabled` property can be true. Yeah, the disabled property just reflects the disabled= attribute. From what I understand, the word disabled it appears in HTML5 is overloaded to describe the following three different things: 1) The form control's disabled `property` * The spec prefers the term IDL attribute, but yes. 2) The form control's disabled attribute (content attribute) ** 3) The form control's eligibility for success. *** Right. I propose changing one of these -- the last -- to the positive sense -- isEnabled, and exposing that in the DOM. Because it's not so useful to have a form whose disabled property is false but the form is disabled due to being a descendant of a disabled fieldset. What's the use case? Need to know if a form control is enabled (and if it is, get its value). Is it common enough that it's worth having a convenience API for it? (You can always write a function to determine the state.) Yes, it is very common. And it used to be as simple as:- element.disabled - but now that FIELDSET can be disabled, descendent elements are ineligible for success, yet `element.disabled` is true. A confounding yet glaring detail. It is not so common to disable a FIELDSET because:- 1) It is not widely supported. 2) it is not a commonly needed feature. But when it is needed, `fieldset.disabled` is simpler than looping through its descendant controls manually and setting their respective `disabled` property. But it also means any code that wants to determine if a form control is eligible for success -- and that control is not disabled -- must traverse up the document tree to see if that control is not within a FIELDSET that is disabled. Right? Instead, the code should be able to determine if the control is eligible for success, and this should be possible with a property check. Like isEnabled. To be feature complete, disable-ability of FIELDSET requires a simple way to determine if an element is eligible/enabled -- like element.isEnabled. -- Garrett @xkit ChordCycles.com garretts.github.io
Re: [whatwg] Markup-related feedback
On 12/29/14, Garrett Smith dhtmlkitc...@gmail.com wrote: On 10/27/14, Ian Hickson i...@hixie.ch wrote: On Fri, 24 Jan 2014, Jukka K. Korpela wrote: 2014-01-22 2:28, Ian Hickson wrote: On Tue, 3 Dec 2013, Jukka K. Korpela wrote: [...] - but now that FIELDSET can be disabled, descendent elements are ineligible for success, yet `element.disabled` is true. A confounding yet glaring detail. Let me try that again. ... - now that FIELDSET can be disabled, and when it is disabled, its descendent form control elements are ineligible for success, even their `disabled` property is false. A confounding yet glaring detail. -- Garrett @xkit ChordCycles.com garretts.github.io
Re: [whatwg] Markup-related feedback
Here's a code example to illustrate the confounding problem of a disabled INPUT whose disabled property is false. http://jsfiddle.net/cmsom6jo/2/ form action= fieldset id=a tabletrtdinput name=b id=b//table /fieldset /form script // Disable the fieldset to make all its form control // descendants to be disabled document.getElementById(a).disabled = true; // Are they? Lets see: alert(document.getElementById(b).disabled); /script - alerts false This result, in a way, seems to contradict the following:- | The disabled attribute, when specified, causes all | the form control descendants of the fieldset element, | excluding those that are descendants of the fieldset | element's first legend element child, if any, to be disabled. http://www.w3.org/TR/html5/forms.html#the-fieldset-element On 12/29/14, Garrett Smith dhtmlkitc...@gmail.com wrote: On 12/29/14, Garrett Smith dhtmlkitc...@gmail.com wrote: On 10/27/14, Ian Hickson i...@hixie.ch wrote: On Fri, 24 Jan 2014, Jukka K. Korpela wrote: 2014-01-22 2:28, Ian Hickson wrote: On Tue, 3 Dec 2013, Jukka K. Korpela wrote: [...] - but now that FIELDSET can be disabled, descendent elements are ineligible for success, yet `element.disabled` is true. A confounding yet glaring detail. Let me try that again. ... - now that FIELDSET can be disabled, and when it is disabled, its descendent form control elements are ineligible for success, even their `disabled` property is false. A confounding yet glaring detail. -- Garrett @xkit ChordCycles.com garretts.github.io -- Garrett @xkit ChordCycles.com garretts.github.io
[whatwg] Markup-related feedback
On Fri, 24 Jan 2014, Jukka K. Korpela wrote:
2014-01-22 2:28, Ian Hickson wrote:
On Tue, 3 Dec 2013, Jukka K. Korpela wrote:
Thank you for the clarifications. I may have been stuck to an idea
of a submittable element, possibly adopted from some earlier version
or proposal. I think an explicit short note like The output element
is not submittable would be useful.
I am reluctant to add that kind of comment for a couple of reasons.
First, there's the problem of determining when one would add these
notes. Should the spec be explicit about everything it doesn't say?
No, but it should be explicit about things that could easily be
misunderstood.
Fair enough. I've added some text to this effect.
What I would rather do is clarify whatever led to the confusion in the
first place. Do you have any idea what it is in the output section
that might lead you to think that it would be submittable?
Well, it is under the heading 4.10 Forms. As an element for the result
of some scripted operation (which output seems to be meant for),
output need not have anything to do with forms. But when it is under
Forms, a natural idea is oh, this is for some computed value, like a
total, to be submitted.
In the sentence I added, I added a mention of why there's a relationship
to forms.
(A submittable output element would a natural thing to have in many
cases, e.g. in showing some calculated total to the user and
submitting it along with form data, for checking purposes.)
Can you elaborate on this use case? I'm not sure how it would work.
When you calculate the total with JavaScript, mainly to be shown to the
user, you might as well submit it along with the form, as an extra
check. If it does not match the total calculated in the server,
something went very wrong. What you do then is a different question, but
the important thing is that you detect a problem, instead of charging an
amount that differs from what the user saw.
Fair enough. You can do this with type=hidden, for what it's worth.
The main reason for not submitting it so far has been that it would
risk authors relying on the client's computation and thus not doing it
on the server,
Authors often rely too much on checks and computations made client-side
- including new features like @pattern and @required attributes and new
values of the @type attribute. They have always been able to do that
with calculated totals, for example - just using an input element
(possibly with @readonly).
Right. But this makes it easier.
Without name=, the main purpose of output -- making it easy to
update non-form-control values in script -- is lost.
The @name attribute in general, except for submittable controls, is
legacy markup that has caused much confusion. It was introduced long
ago, before @id was added to HTML, for scripting purposes, on @img and
@form, as well as on @a for link destinations, but it was unsuitable
from the beginning. It was not defined to be unique in the document, and
there have been many attempts to phase out/deprecate/obsolete @name
(except for submittable fields, where it need not be unique).
So it looks a bit odd to introduce @name for a new element.
What you say is true for some uses of name=, but in the form API in
particular, name= works pretty well, due to the elements object.
Consider what this would look like without the form.elements API:
form name=main
Result: output name=result/output
script
document.forms.main.elements.result.value = 'Hello World';
/script
/form
With output id=result/output, it would have
document.getElementById('result').value = 'Hello World'
and if jQuery is used (and more than half of the world uses it, or
something similar), it would have
$('#result') = 'Hello World'
I would say that both ways are simpler than the property chain
document.forms.main.elements.result.value and, moreover, a way that can
be used to access any element, not just output.
I guess this is an area where opinions differ.
Well, more or less by definition, [if] output is appropriate for
something, it's more appropriate than span would be, since span is
more generic. span is like the fall back element, it has
essentially no semantics at all.
That's a rather theoretical proposition. You say that output is for a
result of a calculation or user agent and call this semantics.
That's basically how that works, yes. :-)
But how would that be a tangible benefit.
The main benefit is the one I describe above, the way it interacts with
the form elements API. The benefit of the semantics is the same as the
benefits of any semantics, mainly that it makes code maintenance easier,
makes it easier for new authors to enter a project and know what's going
on, etc.
I think the improvement of o relative to
document.getElementById('o') should be
