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 self-evident; >> >> If you intend to use plain "o" instead of a property chain, I'm afraid >> many people would regard it as poor programming practice. But anyway, if >> you do that, why not use "o" the same way, when id="o" has been used >> (for any element)? > > I'm not sure what you mean. I think this might just be a difference of > opinion, though. > > >> > that libraries like jQuery feel the need to do exactly this kind of >> > simplification is exactly the kind of evidence we use when trying to >> > work out what needs simplifying. >> >> If the verbosity of document.getElementById(...) is really the problem, >> why solve it only for a new, rather specialized element? > > It's not a new solution. We're just using an existing solution, the naming > of form controls, and applying to a new form-related element. > > >> And if it is a problem, it's really a scripting language issue. > > I don't know that I would describe it as a big problem. It's just a > convenience issue, really. > > >> Introducing an entirely new element to a markup language looks like a >> wrong move. > > Introducing new elements is definitely something we should be careful > about, but at the end of the day, that's how a language evolves. > > >> > > And anyone who does not like the length of document.getElementById() >> > > and does not want to load jQuery can write his own function for the >> > > purpose. >> > >> > It's hard to simulate the simplicity achieved by <output>, even with a >> > function. >> >> With just one simple function definition, you can use ...('o').value, >> where ... is a function identifier of your choice, instead of >> document.forms.main.elements.o.value or the risky o.value. > > It's the "('o')" part (vs "o") that's the issue. But again, maybe this is > just a matter of personal preference. If you prefer string arguments to > direct member access, then obviously a solution that prefers direct member > access to string arguments isn't going to look better. > > >> > Adding one for output in forms seems to make sense, since doing the >> > same for input is already possible. Especially given the low cost of >> > doing this. >> >> Even for <input>, it is safer and common to use references based on @id >> rather than @name, partly for uniformity of access, partly for >> uniqueness: you wish to access a specific element, not an element that >> happens to have a particular @name value. > > This doesn't appear to be true. The form.elements.name API is reliable, > uniform, and well-defined. It also has the advantage of special features > to support radio buttons, and so on. > > >> And the cost is not low: there is confusion about what the <output> >> element really is, whether we should use it, and (for many years) if we >> use it, how do we deal with old browsers that do not recognize it. > > To be honest, the confusion about <output> is really minimal. We get very > few questions about it. The confusion caused e.g. by the W3C dropping > <hgroup> in their variant of HTML is far, far greater than any confusion > we've ever seen for <output>. > > >> > > > The output element represents the result of a calculation or user >> > > > action. That's what the spec says. I'm not sure what more you want >> > > > it to say. >> > > >> > > Well, what it really means. Is <output>4</output> OK just because I >> > > got 4 from calculating 2 + 2? >> > >> > Probably. It's hard to say for sure without more context. I mean, if >> > you're just writing a paragraph that starts like: >> > >> > <p>I bought two apples, then I bought two more, and now I have >> > >> > ...then I would say that <output> is probably unnecessary, but if you >> > find it useful to use here, it wouldn't be _wrong_ per se. >> >> I guess what is really meant is that <output> is for data produced by a >> client-side script. > > Not necessarily client-side script. Consider the <output> example in the > spec, with the calculator: > > <form onsubmit="return false" oninput="o.value = a.valueAsNumber + > b.valueAsNumber"> > <input name=a type=number step=any> + > <input name=b type=number step=any> = > <output name=o for="a b"></output> > </form> > > One could imagine this being adjusted so that the addition operation is > actually done on the server. <output> would still be perfectly applicable, > the semantics are the same: the result of a calculation. > > >> And the added example is about data retrieved, by a client-side script, >> from a remote server. It might the result of some calculation (the >> example does not say that), or just data retrieved from a database - >> something that is not "result of a calculation or user action" in any >> normal sense. > > The calculation in this case is that of finding prime numbers. > > >> > > So shouldn't "calculation" be clarified by saying that it is a >> > > calculation performed on the page, i.e. the result of executing some >> > > client-side script? >> > >> > Well, it could be the result of a calculation done by a remote host >> > based on user input, too. Or the result of a calculation done by >> > remote host C based on data from remote hosts A and B. The second >> > example in the <output> section shows an example of that. >> >> Only the word "primes" in some identifiers suggests that there is any >> calculation involved. And the data could well be just retrieved. > > Fixed. > > >> The common factor seems to be that the <output> element value is written >> by a client-side script - how it gets the data is a different issue. > > There's no semantic difference between something being added to the DOM > via script and being added via the parser. Having an element whose > semantic is "this was added by script" doesn't make any sense to me. What > purpose would it solve? > > >> > > This would probably cover "user action" too - it now looks odd, >> > > since the element content is not supposed to change directly due to >> > > user action, the way e.g. <input type=text> works. >> > >> > It can change directly based on user action (indeed the first example >> > of <output> in the <output> element's section does just that), it's >> > just not an actual input control itself. >> >> We have somewhat different meanings for "directly". I would say that an >> <input> element value can normally be directly changed by the user, e.g. >> by typing into a field, whereas e.g. copying, with a client-side script, >> input characters to another field means changing it indirectly. > > I don't understand the difference. In both cases, physical impulse from > the user is being converted into moving bits on the display, where there's > a direct 1:1 relationship between the physical impulses and the bits. > Precisely what machine code runs to map the keyboard interrupt to changes > to the DOM and changes to layout or painting or whatever is rather > irrelevant. The term "directly" here just means that you hit a key, and > the relevant input appears, as opposed to the input being processed in > some less direct way (like adding the digits or working out a hash or > whatever). > > I agree that if you think too hard about this it starts being a little > philosophical. > > >> It's a moot point in some cases, e.g. when you have buttons that add >> characters into an <input> field, perhaps as the only way of entering >> data there. But in at least one meaningful sense, a change of a >> control's value is indirect if it takes place via a client-side script, >> not via user's interaction with controls as implemented in a browser. > > I think you view "client-side script" as more magical than I do. I guess > you mean "author-provided code" as opposed to "UA code", but what > difference does it really make what code is running? > > >> > > > The main practical gain is that it makes outputting data from >> > > > script in a form easier, since <output> is a listed >> > > > form-associated element. >> > > >> > > That statement, in some formulation, might be a useful addition to >> > > the description of <output>. >> > >> > I have made a conscious choice to not include rationales in the >> > specification, to keep the document manageable. >> >> People who read the specification will be puzzled by the <output> >> element when there is no "why". > > There is now effectively a rationale, with the sentence I added earlier. > But in general, the examples are supposed to be sufficient here. > > >> They will probably not read a Wiki but check some online resources or >> maybe books until they find an explanation. So why not give them the >> reason you really mean? > > Because it would easily double or triple the size of the spec if we > explained all the decisions in there, and I don't have the bandwidth to > maintain it. > > If you'd like to maintain it, though, I'd be happy to merge it into the > spec in a way similar to how we merge caniuse.com data in, though. > > >> > Yeah, the <output for> attribute maybe should be dropped. It was >> > initially intended to allow UAs and ATs to let users jump to the >> > relevant controls from the output; in non-visual situations in >> > particular, this can in theory be quite helpful. If nobody implements >> > it, I imagine we'll drop it. >> >> I don't see how it would be helpful even in theory. > > In theory, a user is going through the document, and gets to the part that > says "Total: $1200". The user wonders what contributed to this total, so > hits the "link to sources" key, and the AT jumps the user to the controls > that affect the output. The AT presumably makes some sort of audio cue to > let the user know this is possible. > > In theory. Like I said, If nobody implements it, I imagine we'll drop it. > > > On Sat, 5 Apr 2014, Steve Faulkner wrote: >> >> Currently the implementation(s) of summary/details elements do not match >> the spec. > > That happens a lot with new specs. :-) > > >> In the spec, the details element is interactive content; the summary is >> not, it's a summary, caption, or legend. >> >> In webkit/blink the summary element is the interactive element (when >> pressed it opens/closes the details element). This is good because it >> provides a large default hit region to activate the control. >> >> An issue with current implementations is that when the summary element >> includes other interactive elements (as it is allowed to), clicking on >> them >> results in the details element being opened/closed (although this can be >> overcome via scripting). > >> The interactive part of the details element is the disclosure triangle, >> which is supposed to be an anonymous control in the shadow DOM. >> >> The <summary> itself is not interactive, so only the triangle provides >> the actionable control. the summary text which is effectively the label >> for control does not activate the control. There is no method provided >> to associate a label with the anonymous control that can (a) provide an >> increased hit region and (b) provide an explicitly associated label for >> the anonymous control. > > The spec and the implementations are actually closer than this suggests, > because there's nothing in the spec that prevents the summary from > defaulting to the behaviour you describe. > > > On Tue, 8 Apr 2014, Steve Faulkner wrote: >> >> All controls are expected to have an accessible name and it is expected >> that the author is able to assign one. this is accessibility 101 across >> all platforms. Lack of an accessible name or a generic accessible name >> or an ambiguous accessible name causes issues for users. > > The details element can be given a name using the regular ARIA attributes, > sure. > > >> What's the mechanism by which the anonymous control for details can be >> assigned an accessible name? > > The disclosure triangle is just part of the <details> element. If you want > to give the details element an accessible name, you use the regular ARIA > mechanisms for doin so. > > > On Sun, 18 May 2014, Luis Farzati wrote: >> >> Sorry if this has been discussed already, but I wanted to ask you guys >> if you have considered making the list attribute available for selects. > > On Sun, 18 May 2014, Anne van Kesteren wrote: >> >> I don't think so. What would the use case be? > > On Sun, 18 May 2014, Luis Farzati wrote: >> >> As I see it, list is perfectly fine the way it was designed but it could >> be applied to select elements, thus enabling feeding options to a >> dropdown externally, thus enabling a way to reuse options in dropdowns >> (without redundant nodes). > > Ah, ok. So your underlying request is "can <select> elements share a set > of options", basically? > > >> I am building long immigration forms for USCIS and, for example, a very >> common field is Country. It is asked several times even in the same page >> (for the address of birth, address of residence, address of your >> relative, etc...). Relative kind is another example. >> >> So I think it makes sense to have a single <datalist> and then have >> >> <select name="birth.country" list="countries"></select> >> <select name="residence.country" list="countries"></select> > > We actually tried something like that in the old Web Forms 2.0 proposal, > IIRC. Unfortunately it didn't get much traction. At this point I would > probably say that the way to solve this would be to create a "country > selection" Web Component, and then use that. I'm not exactly sure how you > would hook that into form submission, but presumably that's possible. > > > On Tue, 3 Jun 2014, Daniel Morris wrote: >> >> With existing assistive technology such as screen readers, and more >> recently the pervasiveness of new technologies such as Siri and Google >> Now to name two examples, I have been thinking about the appropriateness >> and potential of having a way to represent the pronunciation of words on >> a web page. >> >> There is currently no other text-level semantic that I know of for >> pronunciation, but we have elements for abbreviation and definition. >> >> As an initial suggestion: >> >> <pronounce ipa=“ˈaɪpæd”>iPad</pronounce> >> >> (Where the `ipa` attribute is the pronunciation using the International >> Phonetic Alphabet.) > > On Tue, 3 Jun 2014, Tab Atkins Jr. wrote: >> >> This is already theoretically addressed by <link rel=pronunciation>, >> linking to a well-defined pronunciation file format. Nobody implements >> that, but nobody implements anything new either, of course. > > What we'd need to make progress on this would be implementor interest. > Without it, it's probably best not to add anything to the spec. > > > On Thu, 5 Jun 2014, Luis Farzati wrote: >> >> I'd like to propose that the select element could be shown either as a) >> a dropdown list (current UI), b) a list of checkboxes c) a list of radio >> buttons. > > The spec allows that today, for browsers. > > In theory, Web Components, probably in a later revision, will let you > override the default rendering of <select> to do this. > > > On Thu, 26 Jun 2014, Tim Marinin wrote: >> >> Most often use for tag <script> is to include external script through >> <script src="somecdn.example/jquery.js">, or alike. May be we could add >> rel="script" to <link> tag with same behaviour as <script> with src. > > If we were designing from scratch, I agree, but at this point that's more > cost than value unfortuntely. > > > On Thu, 10 Jul 2014, Garrett Smith wrote: >> >> 1. Form `dirty` property. Set to false, initially. Set to true when the >> user has interacted with any of the form's controls to make them dirty. > > What's the use case? Can you work around this by just catching 'input' > events on the <form>? > > >> 2. HTMLFormControl. Why is there no HTMLFormControl interface? I see >> HTMLFormControlsCollection but no HTMLFormControl. HTMLElement doesn't >> cover HTMLSelectElement. I see a 'listed' category. Why no interface >> defining HTMLFormControl? > > What would the purpose of this interface be? > > >> 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? > > >> 4. To get the value of a form's enabled controls as a string: >> HTMLFormElement.serialize(type, callbackFunction). `type` can be "json" >> or "query". > `type` is a bad parameter idea. It's better to have a separate method.
> What's the use case? > Sometimes it's necessary to get the values of a FORM or FIELDSET, then filter them before sending them to the server. This is typically done with some sort of Ajax library. Here's an arcane example of doing that with a popup window. And in that situation, I would rather set the target on the form and let the browser take care of it, but to illustrate:– https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement#Examples More examples in jQuery and Prototype serialize methods. And probably Anglebars or what have you. -- Garrett @xkit ChordCycles.com garretts.github.io