Re: [whatwg] Markup-related feedback

On 10/27/14, Ian Hickson <ian@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

Received on Thursday, 1 January 2015 20:33:56 UTC