| 17:19 | <jugglinmike> | Is there a normative definition for "form control"? |
| 17:20 | <jugglinmike> | I'm looking through 4.10 but haven't come across it yet https://html.spec.whatwg.org/multipage/forms.html#forms |
| 17:20 | <jugglinmike> | In particular, I'm curious if `<meter>` is a form control |
| 17:33 | <MikeSmith> | jugglinmike: there is not |
| 17:33 | <MikeSmith> | but I guess there rightly should be |
| 17:34 | <MikeSmith> | the closest is “labelable element” |
| 17:34 | <MikeSmith> | https://html.spec.whatwg.org/multipage/forms.html#category-label |
| 17:34 | <jugglinmike> | I initially assumed there to be some notion of "input", which tended to disqualify elements like "progress" and "meter" |
| 17:34 | <jugglinmike> | but a more accurate interpretation is probably more like, "controls the data which is submitted" |
| 17:35 | <jugglinmike> | Since that would more logically include "meter" |
| 17:35 | <MikeSmith> | right |
| 17:36 | <jugglinmike> | so maybe a form control is "a labelable element or a hidden input" |
| 17:36 | <MikeSmith> | well <output> does not fit |
| 17:36 | <MikeSmith> | right? |
| 17:37 | <MikeSmith> | <output> is not a form control |
| 17:37 | <jugglinmike> | In the sense of "controls the data which is submitted"? |
| 17:37 | <MikeSmith> | yeah in that sense |
| 17:37 | <MikeSmith> | btw there is also “form-associated elements” |
| 17:37 | <jugglinmike> | I don't know :) |
| 17:37 | <MikeSmith> | https://html.spec.whatwg.org/multipage/forms.html#form-associated-element |
| 17:37 | <jugglinmike> | yeah, I'm looking at those, too |
| 17:38 | <jugglinmike> | It might not be useful to define "form control" in terms of "labelable element" |
| 17:39 | <MikeSmith> | right |
| 17:39 | <MikeSmith> | I think we really need to define “form control” |
| 17:40 | <MikeSmith> | but then it’s still not clear if <meter> is a “form control” |
| 17:42 | <jugglinmike> | I'll file an issue |
| 17:44 | <MikeSmith> | jugglinmike: thanks yeah please |
| 17:44 | <MikeSmith> | btw https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#mutability |
| 17:44 | <MikeSmith> | > A form control can be designated as mutable. |
| 17:45 | <MikeSmith> | so I guess implicitly, if soemthing cannot be designated as mutable, then it is not a form control |
| 17:45 | <jugglinmike> | there's also https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attributes-common-to-form-controls |
| 17:46 | <MikeSmith> | ah yeah |
| 17:47 | <MikeSmith> | https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#a-form-control's-value too |
| 17:47 | <MikeSmith> | > Most form controls have a value and a checkedness. |
| 17:49 | <jugglinmike> | Not the most satisfying definition :P |
| 17:49 | <MikeSmith> | but anyway, yeah, https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attributes-common-to-form-controls seems to already normatively constrain “form control” to a specific set of element |
| 17:50 | <MikeSmith> | jugglinmike: tehre is probably a motto lurking there |
| 17:50 | <MikeSmith> | We Aim for Precision, Not Satisfaction |
| 17:51 | <MikeSmith> | well, though in this case we don’t even yet have precision |
| 17:53 | <jugglinmike> | That's okay, we only aim for it |
| 17:59 | <MikeSmith> | heh |
| 17:59 | <MikeSmith> | new motto: We Fail Sometimes |
| 18:00 | <MikeSmith> | or maybe that could be even more concise: |
| 18:00 | <MikeSmith> | We Fail |
| 18:04 | <jugglinmike> | haha |
| 18:04 | <jugglinmike> | I like it |
| 18:04 | <jugglinmike> | So nothing is a form control |
| 18:04 | <jugglinmike> | according to Firefox and Chrome |
| 18:08 | <MikeSmith> | We Fail Interoperably |
| 18:12 | <jugglinmike> | Well I'm probably wrong |
| 18:12 | <jugglinmike> | MikeSmith: I guess part of the problem is that our working definition is based on a non-observable trait |
| 18:13 | <jugglinmike> | for instance, no element has a `maxlength` property |
| 18:13 | <MikeSmith> | oh |
| 18:13 | <jugglinmike> | many expose that attribute through `maxLength` |
| 18:13 | <MikeSmith> | ah |
| 18:13 | <jugglinmike> | but "has `maxLength`" isn't the same as "has maxlength" |
| 18:17 | <jugglinmike> | MikeSmith: "Form submission" might be misplaced |
| 18:17 | <MikeSmith> | misplaced? |
| 18:17 | <jugglinmike> | since it describes "Attributes for form submission can be specified both on form elements and on submit buttons " |
| 18:18 | <jugglinmike> | i.e. not "Attributes for form submission can be specified both on form elements and on submit buttons " |
| 18:18 | <jugglinmike> | pardon me |
| 18:18 | <jugglinmike> | I mean, not "Attributes common to form controls" |
| 18:21 | <jugglinmike> | oh, how about this https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#control's-data |
| 18:22 | <jugglinmike> | That implies a complete list of "kind of control" |
| 18:22 | <jugglinmike> | input, textarea, select |
| 18:23 | <jugglinmike> | so, not progress or meter or input |
| 18:23 | <jugglinmike> | but not button, either... |
| 18:24 | <jugglinmike> | correction: "so, not progress or meter or **output**" |
| 18:39 | <jugglinmike> | MikeSmith: another candidate: "submitable elements" https://html.spec.whatwg.org/multipage/forms.html#category-submit |
| 18:40 | <MikeSmith> | jugglinmike: embarrassment of riches |
| 18:42 | <jugglinmike> | That's probably closest to our earlier definition of "controls the data which is submitted" |
| 18:42 | <jugglinmike> | but once again does not include meter |
| 18:44 | <Domenic> | What does having a formal definition of "form control" impact? |
| 18:45 | <Domenic> | The actual element categories should be used for any normative text. |
| 18:48 | <jugglinmike> | Domenic: css-ui, at least |
| 18:48 | <Domenic> | They should use the actual element categories :) |
| 18:49 | <jugglinmike> | yeah, that makes sense, too |
| 18:49 | <jugglinmike> | But do you think there's any value in formally defining the term "form control"? |
| 18:49 | <jugglinmike> | Since HTML uses it frequently |
| 18:51 | <Domenic> | Not particularly; I think more discrete categories are more useful. If any uses of "form control" cause confusion for either implementers or readers we should replace them with one of the categories. |
| 18:52 | <jugglinmike> | How about "4.10.18 Attributes common to form controls" |
| 18:52 | <jugglinmike> | working backwards from there, "form controls" are only input and textarea elements |
| 18:54 | <Domenic> | If it's unclear to what elements those attributes apply, then yeah, we should be more precise (by using one of the named categories) |
| 18:54 | <jugglinmike> | It might be best to just name it "Common attributes" |
| 18:55 | <Domenic> | I mean, they're not common to div. |
| 18:55 | <jugglinmike> | that is true, but the context might be sufficient to communicate the limited scope |
| 18:56 | <Domenic> | Well, I'm doubtful that would reduce confusion instead of increasing it. But, I GTG for now :) |
| 18:56 | <jugglinmike> | because the sub-section "Form submission" clearly describes "form elements and [...] submit buttons" |
| 18:56 | <jugglinmike> | got it; thanks for the input |
| 18:57 | <jugglinmike> | I could have avoided that pun but I chose not to |
| 21:42 | <jugglinmike> | botie: tell MikeSmith https://github.com/w3c/csswg-drafts/issues/3990 |
| 21:42 | <botie> | will do |
| 23:29 | <MikeSmith> | jugglinmike: heya |
| 23:29 | <botie> | MikeSmith, at 2019-05-30 21:42 UTC, jugglinmike said: https://github.com/w3c/csswg-drafts/issues/3990 |
| 23:29 | MikeSmith | looks at https://github.com/w3c/csswg-drafts/issues/3990 |
| 23:30 | MikeSmith | adds thumbs up |
| 23:31 | <jugglinmike> | :) |
| 23:32 | <jugglinmike> | Good question from Brian about `<details>` |