Re: [whatwg] Context help in Web Forms
Adding HTML-WG so people know what's going on and can comment if necessary. On Wed, 22 Oct 2008 14:42:48 +0700, Ian Hickson [EMAIL PROTECTED] wrote: [in the context of a request for a way to identify context-specific help, e.g. some further information about a given form field that can be made available without requiring the user to read it]. ... I don't understand how inline text is inaccessible. Could you elaborate? An example would be useful. Large quantities of text reduce the overall accessibility of a page in a couple of ways. The most common is actually making the page harder to read - and reading difficulties are very common as a type of disability. The effect can be very mild (it is a bit slower) or very severe (many people actually find it incredibly difficult to read something if there is too much text there). (For this reason, designers will often look for ways not to have the text present in the page's default view...) The other common problem it introduces is reducing the ability of users to navigate efficiently. This applies especially to screen reader users who are scanning text by skipping through it. One of the benefits HTML provides over plain text is the various navgiable structures to improve this situation - having a lot of inline text can negate some of that improvement, especially if it is not marked in a way that makes it clear that it is ancillary to the main content. (One of the problems with visible metadata is that people assume that since it is visible it doesn't really need more markup...) Hixie had said... Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Chaals replied: Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. Thanks, this seems sound to me. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] 'input' event interpretation
On Fri, 7 Nov 2008, Rimvydas wrote: Are you talking about section 4.2. The change and input events ? It still concentrates mostly on entering text with keyboard. But what another forms of input i've mentioned? They are still popular among UAs but are not mentioned here. However I think, as I've mentioned, they change the value of an input field due to input from the user (mouse click). My apologies, I meant in the HTML5 spec: http://www.whatwg.org/specs/web-apps/current-work/ There are various places that discuss 'input' and 'change', but in particular: http://www.whatwg.org/specs/web-apps/current-work/#common-event-behaviors -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 'input' event interpretation
Are you talking about section 4.2. The change and input events ? It still concentrates mostly on entering text with keyboard. But what another forms of input i've mentioned? They are still popular among UAs but are not mentioned here. However I think, as I've mentioned, they change the value of an input field due to input from the user (mouse click). 2008/11/7 Ian Hickson [EMAIL PROTECTED]: On Fri, 2 May 2008, Rimvydas wrote: The question is related to the 'input' event on Web Forms 2.0. The WF2 specification says: This [input] event must be fired on a control whenever the value of the control changes due to input from the user, and is otherwise identical to the change event. However, there are a few problems with current interpretation of this sentence. The first one - what is considered an input from the user? I just check on opera and firefox3 - they fire the event when I enter something, but if i select an entry from autocomplete list or browser fills some forms for me - it is not fired. When I select a value from a list I usually want the value in the field to change - it is like typing, just faster. I have filed a bug for ff. Maybe a specification could be more precise on what is an input from the user... I've tried to be clearer. Let me know if this is still ambiguous. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Rimvydas Naktinis
