[whatwg] Autofocus readonly Input Elements
Hi, Reference - http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autofocus Here there is mentioned that Queue a task that checks to see if the element is focusable, and if so, runs the focusing steps for that element. User agents may also change the scrolling position of the document, or perform some other action that brings the element to the user's attention. As per this statement, every focus-able element should be autofocus-able. Does this applies to readonly input elements as well? There are no as such concrete use cases though, one use case can be if user want to get the element in focus (may be by scrolling the page on load). Currently, Firefox Opera does focus the readonly elements on autofocus whereas IE Webkit does not. Need to clear the ambiguity. Thanks Regards -- Kaustubh Atrawalkar
Re: [whatwg] window.onerror and cross-origin scripts
On Thu, 22 Sep 2011 16:02:30 +0200, Simon Pieters sim...@opera.com wrote: I was talking about window.onerror. script onerror per spec fires for empty src=, unresolvable URL and network errors (DNS or 404). If we want to make onload always fire for cross-origin, it would make sense for script onerror to not fire for network errors. (Opera doesn't fire error on script, assuming my testing isn't bogus this time.) I don't know if it's worth it to try to plug this hole this way, however. We won't be able to plug it everywhere, e.g. img will expose if an image is loaded. So masking onload/onerror for script just makes the feature less useful without solving the problem. Maybe we should instead focus on implementing the From-Origin header and try to get sites to use that. It was pointed out to me that the following site expects an error event for a cross-origin script (which returns 404): http://www.alvoradafm.com.br/Player/player.html which tries to load http://lp.longtailvideo.com/5/%20gapro/%20gapro.js -- Simon Pieters Opera Software
[whatwg] HTMLForms: Implicit Submission with {display:none} button
Hi, There is an issue regarding form submit button which is little unclear from the specs mentioned in here http://www.whatwg.org/specs/web-apps/cu ... submission If the form has submit button with display property as none, will that form should be implicitly submitted on pressing enter key? This works in Opera Firefox but does not work in IE Safari as of now. What is the expected behavior for this? Thanks Regards - Kaustubh Atrawalkar
Re: [whatwg] Autofocus readonly Input Elements
On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote: Reference - http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autofocus Here there is mentioned that Queue a task that checks to see if the element is focusable, and if so, runs the focusing steps for that element. User agents may also change the scrolling position of the document, or perform some other action that brings the element to the user's attention. As per this statement, every focus-able element should be autofocus-able. Does this applies to readonly input elements as well? Since it doesn't say otherwise, yes. There are no as such concrete use cases though, one use case can be if user want to get the element in focus (may be by scrolling the page on load). Currently, Firefox Opera does focus the readonly elements on autofocus whereas IE Webkit does not. Need to clear the ambiguity. If they're focusable at all, I don't see why they wouldn't be autofocusable. Is there a use case for special-casing read-only ones? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote: There is an issue regarding form submit button which is little unclear from the specs [...] If the form has submit button with display property as none, will that form should be implicitly submitted on pressing enter key? This works in Opera Firefox but does not work in IE Safari as of now. What is the expected behavior for this? The strict answer is that it's up to the browsers; the spec allows browsers to do whatever they think is appropriate per their platform's conventions. So both behaviours are compliant. The guidelines in the spec do not say anything about the behaviour being different for elements that are display:none or otherwise hidden, though, so I don't see any reason to consider the visibility of a button in making the decision as to which button is the default. HTH. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Forms 2 Repetition Model?please reinstate on specification
Matthew Slyman, M.A. Computer Science (Camb) -- Quoting Ian Hickson i...@hixie.ch: We took it out because it was just far too complicated a solution to solve far too narrow a set of use cases. However, there is a lot of ongoing work in this area of research, especially currently in the public-weba...@w3.org group. I encourage you to bring up the suggestion there. Unfortunately, coming up with a declarative solution whose cost-to-usefulness ratio is good enough has proven over the years to be a rather elusive goal. I find this surprising. Unless of course you're trying to create a tool to do everything (in which case you're diving head-first down a rabbit-warren), or otherwise, have already tried that and decided it doesn't work, and therefore decided that it's not worth attempting a solution to any part of this problem. Let's address another potential misconception at the same time. I recently dug up an old archive message from 2004/2005 in which some fellow was talking the repetition model down on the basis that repetition would be programming and declarative models aren't meant to do programming or something to that effect. Repetition isn't truly programming if it isn't Turing-complete. But I get the point, and I would NEVER ask for a declarative solution that would be Turing-complete. Let's look at a case study or two: ===Chemical formulae===: These have had a repetition model for a long time now, which is very simple but very powerful. Like so: Ca(OH)2 [subscript 2 - put superscript figures in for charge if you want.] Nobody has a problem with this. It does the job and it's very powerful. Just powerful enough, yet not so powerful that you end up with 20 different ways to write the same chemical formula (the system is sufficiently restrictive to enforce a common system of notation). It strikes the balance perfectly, and forms a perfect demonstration of the relative advancement of chemistry as compared with many other sciences. The combination of power and simplicity in this system of chemical notation (which closely resembles the basic HTML5 Repetition Model) enables the world of chemistry to get on with their real work without worrying too much about the art of notation, and enable chemists to find prior art easily. ===Linear equations===: A similar case could be made for these. They're a separate class of problems from the much larger set of problems that can be tackled with mathematics in general. You shouldn't put the folks that need real power and freedom in a strait-jacket by forcing them to work with a system designed for linear equations only. Likewise, you shouldn't burden and befuddle the novices and the folks that just need to get a quick linear equation job done, by forcing them to work with a generalised mathematical tool that they're just not trained to handle, and will never be confident using. ===Classes of problems===: For many problems, there is such a thing as too much power. Let's please recognise that we're dealing with two distinct classes of problems here. There is a class of problems that requires a similar approach/solution to what we see in chemical notation (where one only requires a contiguous repetition of a block of HTML, which may or may not include repeatable subgroups), and another separate and much larger class of problems that requires the greater power available in a programming language. The correct solution for the former is a declarative solution like the basic HTML5 Repetition Model. The correct solution for the latter is Javascript or something similar. ===CONCLUSIONS===: We need a declarative solution for HTML repetition, the same way Chemists need a declarative solution for repetition of chemical formulae. Please reinstate the basic HTML5 Repetition Model. The system design as it stood just a few months ago was excellent in my opinion, and not at all in need of major revision if any. -- Matthew Slyman, M.A. Computer Science (Camb)
Re: [whatwg] Autofocus readonly Input Elements
On Fri, Sep 23, 2011 at 11:49 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote: Reference - http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autofocus Here there is mentioned that Queue a task that checks to see if the element is focusable, and if so, runs the focusing steps for that element. User agents may also change the scrolling position of the document, or perform some other action that brings the element to the user's attention. As per this statement, every focus-able element should be autofocus-able. Does this applies to readonly input elements as well? Since it doesn't say otherwise, yes. There are no as such concrete use cases though, one use case can be if user want to get the element in focus (may be by scrolling the page on load). Currently, Firefox Opera does focus the readonly elements on autofocus whereas IE Webkit does not. Need to clear the ambiguity. If they're focusable at all, I don't see why they wouldn't be autofocusable. Is there a use case for special-casing read-only ones? Right. The question is whether read-only/disabled/hidden inputs should be focusable. I don't personally see pros and cons in either direction, but I wanted to make sure there was agreement here before changing WebKit's behavior. Kaustubh, it would help if you could see what the behaviors for disabled/hidden inputs are in various browsers as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The placeholder attribute
Should @placeholder be renamed @eg, and used exclusively for example input? On Thu, Sep 22, 2011 at 11:53 PM, Bjartur Thorlacius svartma...@gmail.com wrote: The semantics of the placeholder and title attributes of inputs overlap slightly; the placeholder attribute may contain a hint to aid the user, while title is to contain other advisory text. I can think of two valid uses of placeholder: example value, and the text click here to type or enter search query here. The latter is obviously user interface that should be implemented by interactive user agents. Then there is the third use, use it as a title attribute (but with richer presentation). Users might want values falling under the first to be prefixed with e.g., for example or equivalent - but by allowing the latter use forces authors to add it to all example values, rather than letting the user's style sheet take care of it. Thus I suggest narrowing the semantics of the attribute to example values, allowing for easier styling by users (or agents, on their behalf). The second one should have no valid representation. Lastly, the specification should make it clearer what the title attribute is appropriate for; a description of the input or format. Also, I see no reason to suggest not rendering the text when the input is focused - in special on 1D devices such as speech - considering that JavaScript dependent sites (such as Hotmail) have placed example values in a small font below the input so that it can be visible while the user is typing, and, more importantly, after the input has been focused (whether automatically or manually), but before the user starts typing. As for the argument against using the title attribute for everything that it would break existing sites, I do believe rendering the title attribute of an empty and unfocused input inside of it is an improvement over displaying a tooltip a second or two after the user positions a cursor over the input (irrespective of focus). How on Earth is anyone to think of doing that? Displaying the title attribute in a floating box in a margin when an input is focused, followed by the example value prefixed with e.g. would be my preferred rendering, but that's just my opinion. P.S. The last paragraph of the section on the pattern attribute links twice to semantics.html#the-title-element. Should it not link to elements.html#the-title-attribute?
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
If the form has submit button with display property as none, will that form should be implicitly submitted on pressing enter key? This works in Opera Firefox but does not work in IE Safari as of now. What is the expected behavior for this? The strict answer is that it's up to the browsers; the spec allows browsers to do whatever they think is appropriate per their platform's conventions. So both behaviours are compliant. But then this might result in website compliance issue. A website having username, password field with hidden submit button expecting to login on enter key using forms implicit submission will work on FF Opera but may not work on IE Safari. The guidelines in the spec do not say anything about the behaviour being different for elements that are display:none or otherwise hidden, though, so I don't see any reason to consider the visibility of a button in making the decision as to which button is the default. Second to your opinion, on the last line of the specs paragraph it says - If the form has no submit button, then the implicit submission mechanism must just submit the form element from the form element itself. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission - Kaustubh
