Re: [whatwg] Canvas normalize rect() and strokeRect()
On Mon, Apr 7, 2014 at 10:47 AM, Rik Cabanier caban...@gmail.com wrote: On Mon, Apr 7, 2014 at 7:29 AM, Justin Novosad ju...@google.com wrote: Putting myself the the web devs shoes... If I negate the height of a rect, what would I expect? My first though: a horizontally flipped mirror image of the rect. Now, what does the spec say? a) rect(): respect the flipped vertex order yes, except it doesn't explicitly say in that order so a UA could implement it in a different one. Okay. Nonetheless the spec already does define the order, it just does not insist that it must be respected. b) strokeRect(): respect the flipped vertex order c) fillRect(): unaffected by vertex order. Where do you see that fillRect is not affected? It does not say so explicitly, but it is implied. The coloring of pixels is governed by the fillStyle, which is not affected vertex order. d) fillStyle and strokeStyle style application is independent of the primitive, mapping is controlled by CTM (and a pattern matrix) I find the spec is consistent with itself as it is currently worded. If you want to flip a rect (or any other geometry for that matter), you can either flip everything together using the CTM, or flip its parts (the vertices and the styles) individually. I think that having the styles automatically flip when the rect is inverted would have an undesirable consequence: It would break consistency with path rendering (how do you define the notion inverted geometry for a general, possibly self-intersecting, path?) I'm unsure why we would switch geometry. Are you referring to the dashing? Dashing is one thing that would be affected. I think some implementations are currently in a non-compliant state probably because the line dashing feature was added recently. Back when strokeRect was originally implemented, we could get away with blindly normalizing rectangles because there was no impact on the rendering result. The other thing that is affected is fill rule application. For example, if you have a path that contains two intersecting rectangles and you are filling in with the nonzero rule. If one of the two rectangles is flipped, then the intersection region should be unfilled. If the rectangles are normalized internally by the implementation, then you will get the wrong (non spec compliant) result. On Sun, Apr 6, 2014 at 3:04 AM, Dirk Schulze dschu...@adobe.com wrote: On Apr 6, 2014, at 8:24 AM, Rik Cabanier caban...@gmail.com wrote: On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze dschu...@adobe.com wrote: On Apr 6, 2014, at 3:23 AM, Rik Cabanier caban...@gmail.com wrote: On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze dschu...@adobe.com wrote: Hi, I looked at the behavior of negative width or height for the rect() and strokeRect() functions. All browsers normalize the passed parameters for strokeRect() to have positive width and height. strokeRect(90,10,-80,80) — strokeRect(10,10,80,80) http://jsfiddle.net/za945/ It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ I'm unsure why such a rectangle is defined as a straight line. You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? yes That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ Just WebKit seems to normalize for rect() as well: http://jsfiddle.net/VT4MG/ The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don’t do it for all IMO. Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. yes, the spec needs to say in that order as it does for fillRect and strokeRect. Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw “in that order” for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) Firefox has a strange different behavior if dash = gap. If the gap is smaller it behaves like IE, Blink and WebKit. This also answers your question: Your example renders in IE the same as in WebKit and Blink. Greetings, Dirk I would be in favor to change the blink/webkit behavior as the specified one makes more sense.
Re: [whatwg] Media sink device selection on audio/video
On 04/02/2014 07:52 PM, Ian Hickson wrote: On Mon, 3 Mar 2014, Ami Fischman wrote: Looks like we're back in business: Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. Would it make sense to group the access to sinks in with access to sources - that is, this page wants access to your cameras, microphones and audio output devices? (either on a per-device basis or as an all-or-nothing prompting)
Re: [whatwg] Media sink device selection on audio/video
Thanks Ian. I pinged public-media-capture about this and https://www.w3.org/Bugs/Public/show_bug.cgi?id=25245 is now tracking making that spec better specified. On Wed, Apr 2, 2014 at 10:52 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Mar 2014, Ami Fischman wrote: Looks like we're back in business: Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Mon, 7 Apr 2014, Harald Alvestrand wrote: On 04/02/2014 07:52 PM, Ian Hickson wrote: On Mon, 3 Mar 2014, Ami Fischman wrote: Looks like we're back in business: Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. Would it make sense to group the access to sinks in with access to sources - that is, this page wants access to your cameras, microphones and audio output devices? (either on a per-device basis or as an all-or-nothing prompting) Wouldn't that be an implementation detail? When I was first desigining the API for WebRTC (years ago, before it got rather unceremoniously forked by the W3C), the security design I had come up with was basically that the UA would show a panel of devices, and the user would drag-and-drop them into the page to give the page access to them. (Or equivalent UI, e.g. tapping on the relevant device icons to activate them for the page.) This would let me, as a user, specify that on my laptop YouTube can play video on my TV (assuming we extend this stuff to support video over Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send audio to my bedroom, while simultaneously having Amazon's Cloud Player sending its music to my bedroom, but not allowing it to use my microphone. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On 04/07/2014 06:20 PM, Ian Hickson wrote: On Mon, 7 Apr 2014, Harald Alvestrand wrote: On 04/02/2014 07:52 PM, Ian Hickson wrote: On Mon, 3 Mar 2014, Ami Fischman wrote: Looks like we're back in business: Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. Would it make sense to group the access to sinks in with access to sources - that is, this page wants access to your cameras, microphones and audio output devices? (either on a per-device basis or as an all-or-nothing prompting) Wouldn't that be an implementation detail? The details are an implementation detail. Whether sinks should be treated at the same level as sources, higher level or lower level of protection is probably a somewhat higher level issue. When I was first desigining the API for WebRTC (years ago, before it got rather unceremoniously forked by the W3C), the security design I had come up with was basically that the UA would show a panel of devices, and the user would drag-and-drop them into the page to give the page access to them. (Or equivalent UI, e.g. tapping on the relevant device icons to activate them for the page.) This was considered, but rejected. The consensus opinion at WebRTC and MediaCapture seemed to be that the ability to let an app say which of these 5 microphones do you want? is more amenable to creating good apps than leaving this UI to the browser chrome. This would let me, as a user, specify that on my laptop YouTube can play video on my TV (assuming we extend this stuff to support video over Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send audio to my bedroom, while simultaneously having Amazon's Cloud Player sending its music to my bedroom, but not allowing it to use my microphone.
Re: [whatwg] summary/details - proposal
-- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 6 April 2014 05:11, Ian Hickson i...@hixie.ch wrote: On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. It also provides the best choice for users, large click area and focus ring, Its also simple for authors in the majority of use cases. while on Mac OSX only the disclosure triangle (approx 13X13px) itself is clickable and has a focus rectangle. details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, how so? with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? not to mention all the problems it would cause with the existing label definitions. may be making the details element a labelable control would be simpler, as its be definition an interactive control. would it cause problems for existing label definitions? details id=x summary label for=xFoo/label /summary ... /details -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Mon, 7 Apr 2014, Harald Alvestrand wrote: The consensus opinion at WebRTC and MediaCapture seemed to be that the ability to let an app say which of these 5 microphones do you want? is more amenable to creating good apps than leaving this UI to the browser chrome. Seems to me that the privacy aspects (the fingerprinting vulnerabilities from exposing this data), and the abuse aspects (giving hostile sites the ability to access all the user's devices if any are made available) would trump this. Surely we can rely on user agents to provide nice UIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
On Sun, 6 Apr 2014, Steve Faulkner wrote: On 6 April 2014 05:11, Ian Hickson i...@hixie.ch wrote: On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, how so? All that should be necessary is: details summary Foo /summary ... /details Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? If doing so matches the platform conventions, any non-interactive text in the summary would open the widget. in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
-- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 6 April 2014 21:08, Ian Hickson i...@hixie.ch wrote: On Sun, 6 Apr 2014, Steve Faulkner wrote: On 6 April 2014 05:11, Ian Hickson i...@hixie.ch wrote: On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed Not what I said, but the current implementations use of summary as the interactive element matches, the first example under usage patterns http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx#patterns details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, how so? All that should be necessary is: details summary Foo /summary ... /details Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. for the case details summary Foo input Bar /summary ... /details whats the disclosure label? what about? details summary labelinput Bar /label/summary ... /details in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. does this also extend to the author being able to provide an accessible name for the control? Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
On Mon, 7 Apr 2014, Steve Faulkner wrote: All that should be necessary is: details summary Foo /summary ... /details Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. for the case details summary Foo input Bar /summary ... /details whats the disclosure label? The text Foo, a text field, and the text Bar. If by disclosure label you mean the parts which, on certain platforms, when clicked, would toggle the open state, then that depends on the platform, but I would expect the Foo and Bar text to be good candidates, since they're otherwise inert. what about? details summary labelinput Bar /label/summary ... /details Here there's no non-interactive text, so there's no text to target. in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. does this also extend to the author being able to provide an accessible name for the control? Should there be a particular need for an accessible name for the details control, ARIA can be used to set the name. But I must admit to not understanding why you would need that in practice, if the page is well written. (I find most pages that use accessible labels in situations such as this tend to be poorly written for non-AT users.) Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Mon, Apr 07, 2014 at 07:28:45PM +0200, Harald Alvestrand wrote: On 04/07/2014 06:20 PM, Ian Hickson wrote: When I was first desigining the API for WebRTC (years ago, before it got rather unceremoniously forked by the W3C), the security design I had come up with was basically that the UA would show a panel of devices, and the user would drag-and-drop them into the page to give the page access to them. (Or equivalent UI, e.g. tapping on the relevant device icons to activate them for the page.) This was considered, but rejected. The consensus opinion at WebRTC and MediaCapture seemed to be that the ability to let an app say which of these 5 microphones do you want? is more amenable to creating good apps than leaving this UI to the browser chrome. If the app disregards or misunderstands the user's input, what keeps it from using the wrong microphone? How do I disconnect a microphone from an app? How do I know which microphones are connected to which apps? Ian's proposal seems to offer this visibility and control to the user. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
