Re: [whatwg] Feedback on a variety of elements
On 19 January 2013 01:41, Ian Hickson wrote: > I don't see any useful explanation of how to use aria-haspopup here. suggest you look at definition of aria-haspopup in the ARIA spec HTH SteveF
Re: [whatwg] Feedback on a variety of elements
On Sat, 19 Jan 2013, Steve Faulkner wrote: > On 18 January 2013 23:55, Ian Hickson wrote: > > Doesn't it differ from platform to platform? How is the author supposed to > > know what it is on the user's platform? > > There are some platform differences for some controls. > Design patterns for a range of widgets are provided in the ARIA > authoring guide [1] > > [1] http://www.w3.org/WAI/PF/aria-practices/#aria_ex I don't see any useful explanation of how to use aria-haspopup here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feedback on a variety of elements
On 18 January 2013 23:55, Ian Hickson wrote: > Doesn't it differ from platform to platform? How is the author supposed to > know what it is on the user's platform? There are some platform differences for some controls. Design patterns for a range of widgets are provided in the ARIA authoring guide [1] [1] http://www.w3.org/WAI/PF/aria-practices/#aria_ex -- with regards SteveF
Re: [whatwg] Forms-related feedback
On Mon, 14 Jan 2013, Jonas Sicking wrote: > > > > It's probably simple enough for authors to check valueAsNumber is not > > NaN and then have them set it to the value they want as the default, > > if they're calling the stepUp/stepDown methods. I've left this as > > throwing if the value isn't a number. > > *All* behavior of stepUp/stepDown is easy enough for authors to work > around to cover cases where they don't agree with the spec. > > But if they have to, I don't see why they wouldn't simply not use > stepUp/stepDown and implement whatever functionality that they want. Fair point. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feedback on a variety of elements
On Fri, 18 Jan 2013, Steve Faulkner wrote: > > On 17 January 2013 18:59, Ian Hickson wrote: > > How does the user agent know how the user is to interact with it? > > menus like most controls have a defined standard interaction pattern Doesn't it differ from platform to platform? How is the author supposed to know what it is on the user's platform? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Implementation issue: step mismatch handling for
On Fri, 18 Jan 2013, L. David Baron wrote: > On Thursday 2013-01-17 20:13 +, Ian Hickson wrote: > > On Thu, 17 Jan 2013, Jonathan Watt wrote: > > > If the step base considered the 'minimum' instead of the 'min' > > > content attribute, then the step base would be zero, and thus the > > > value would settle at zero. > > > > Right, but that would be highly unlikely to make sense, because it > > would mean the value the author set was an invalid value. You > > shouldn't be forced to specify the minimum if you're already > > specifying a step and a value and the default minimum of zero is > > adequate. > > That still seems like a surprising behavior (and it entirely disables > step constraints in a peculiar set of cases). > > It would seem better to either: > > * infer the step base from the minimum whenever there is a minimum, >or > > * when inferring the step base from the default value (the value >content attribute), apply the minimum and maximum to the default >value Why? (When does it entirely disable step constraints?) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AllowSeamless feedback
On Fri, Jan 18, 2013 at 5:20 PM, Boris Zbarsky wrote: > except for niggling issues around code that uses location.href to determine > origins. :( Sounds like you'd also have to trust that the page you're seamlessly embedding is not going to do anything malicious on your origin. Seems pretty dangerous. -- http://annevankesteren.nl/
Re: [whatwg] AllowSeamless feedback
On 1/18/13 8:40 AM, Anne van Kesteren wrote: On Tue, Jan 15, 2013 at 2:44 PM, Markus Ernst wrote: The allow-seamless mechanism is to be triggered at the side of the embedded resource, which would also be the one affected by possible security risks (if I get this right). The developer of this resource will have to be aware of these risks, and avoid to expose critical stuff in pages that allow seamless embedding. So, would it be possible to generally treat resources that allow seamless embedding as same-origin from the security POV? No. And "AllowSameOrigin" would not work either. Because of scripting one resource granting such access means exposing the entire origin to attacks. I'm not sure why. It sounded to me like the proposal was that if a resource is flagged as AllowSameOrigin and loaded in an iframe then the origin it gets is an alias for the origin of the ownerDocument of the iframe (basically the way data: or srcdoc work). That seems like it wouldn't expose too much... except for niggling issues around code that uses location.href to determine origins. :( -Boris
Re: [whatwg] AllowSeamless feedback
Am 18.01.2013 14:40 schrieb Anne van Kesteren: On Tue, Jan 15, 2013 at 2:44 PM, Markus Ernst wrote: The allow-seamless mechanism is to be triggered at the side of the embedded resource, which would also be the one affected by possible security risks (if I get this right). The developer of this resource will have to be aware of these risks, and avoid to expose critical stuff in pages that allow seamless embedding. So, would it be possible to generally treat resources that allow seamless embedding as same-origin from the security POV? No. And "AllowSameOrigin" would not work either. Because of scripting one resource granting such access means exposing the entire origin to attacks. I did not mean to merge origins, but to completely detach the included resource from its origin, and allocate it to the origin of the including document: - Document from A domain-A.com includes resource B from domain-B.com - Resource B has set AllowSameOrigin="domain-A.com" -> Document A and resource B can access each other as same-origin - Now Resource B tries to access resource C from domain-B.com - Resource C does not have AllowSameOrigin specified for domain-A.com -> Resource B cannot access resource C, as it would violate the same-origin policy. Resource B is treated as of origin domain-A.com. I don't know whether this is possible, but I think if yes, it would be an elegant solution to this topic.
Re: [whatwg] AllowSeamless feedback
On Tue, Jan 15, 2013 at 2:44 PM, Markus Ernst wrote: > The allow-seamless mechanism is to be triggered at the side of the embedded > resource, which would also be the one affected by possible security risks > (if I get this right). The developer of this resource will have to be aware > of these risks, and avoid to expose critical stuff in pages that allow > seamless embedding. > > So, would it be possible to generally treat resources that allow seamless > embedding as same-origin from the security POV? No. And "AllowSameOrigin" would not work either. Because of scripting one resource granting such access means exposing the entire origin to attacks. -- http://annevankesteren.nl/
Re: [whatwg] AllowSeamless feedback
Am 15.01.2013 00:39 schrieb Nasko Oskov: Hi whatwg, I recently became aware of the proposal to add AllowSeamless attribute that will permit cross-origin seamless iframes ( http://wiki.whatwg.org/wiki/AllowSeamless). We are currently working on a new security policy in Chrome, which will separate each site into its own renderer process. More information can be found at http://www.chromium.org/developers/design-documents/site-isolation. Re-reading this Chromium document, I had the idea that AllowSeamless may be a special case of something which should rather be like "AllowSameOrigin"? A document that allows to be treated as same-origin by the including document would then be removed from the "siteInstance" (or security context) of its own origin, and added to the one of the including document. I think that per-origin control would be necessary in this case, so it would look somehow like: Or: I see the following advantages compared to an AllowSeamless solution: - New spec is only needed for the mechanism itself. All issues that derive from the mechanism are already covered by the same-origin policy. - Authors who decide to use AllowSameOrigin in a resource are more likely to be aware of security risks than they were about an AllowSeamless solution (which actually sounds like something purely design-related) (Excuse me in case this is a silly idea - I am a web author with zero knowledge on browser implementation.)
[whatwg] value sanitization algorithm
In addition to the value sanitization algorithm, some input types specify actions that the user agent must take when the element's value is suffering from underflow/overflow or a step mismatch. To make it clearer that these actions will also be run when the value sanitization algorithm is run, could the text be changed to include each type's underflow/overflow and step mismatch actions under the the respective type's value sanitization algorithm? (Otherwise it's unclear to me why some of the steps that are applied when converting the value content attribute to the input element's value have this special "value sanitization algorithm" label attached to them, while others do not.) Jonathan
Re: [whatwg] Implementation issue: step mismatch handling for
On Thursday 2013-01-17 20:13 +, Ian Hickson wrote: > On Thu, 17 Jan 2013, Jonathan Watt wrote: > > If the step base considered the 'minimum' instead of the 'min' content > > attribute, then the step base would be zero, and thus the value would > > settle at zero. > > Right, but that would be highly unlikely to make sense, because it would > mean the value the author set was an invalid value. You shouldn't be > forced to specify the minimum if you're already specifying a step and a > value and the default minimum of zero is adequate. That still seems like a surprising behavior (and it entirely disables step constraints in a peculiar set of cases). It would seem better to either: * infer the step base from the minimum whenever there is a minimum, or * when inferring the step base from the default value (the value content attribute), apply the minimum and maximum to the default value -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂
Re: [whatwg] Make the files attribute of the input element writable
> Date: Thu, 17 Jan 2013 20:45:59 + > From: i...@hixie.ch ... > > >> 1) This would make it possible to write JavaScript libraries that > > >> seamlessly scan the current page for and add > > >> integration with Dropbox / Google Drive / Sky Drive etc. I claim that > > >> changing the value is the easiest and most robust method of > > >> achieving this without requiring changes to the main application > > >> code. Asides from providing an easy path for developers to integrate > > >> online storage services into their apps, this change would make it > > >> easy to write bookmarklets / browser extensions that add this > > >> functionality to any Web application. > > > > > > It seems like this use case would be better handled by having the > > > sites offer an API to the browser, similar to Web Intents, for picking > > > a file. That way you wouldn't need to update each site -- every site > > > would support all the drive systems you use. > > > > Yes, but that approach would require deeper application changes. I think > > that adding a couple of
Re: [whatwg] Feedback on a variety of elements
On 17 January 2013 18:59, Ian Hickson wrote: > How does the user agent know how the user is to interact with it? menus like most controls have a defined standard interaction pattern -- with regards Steve Faulkner
