On Mon, Oct 14, 2013 at 2:58 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Mon, Oct 14, 2013 at 2:50 PM, Rik Cabanier <caban...@gmail.com> wrote: > >> On Mon, Oct 14, 2013 at 2:38 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >> >>> Sorry, the original email had lots of typos. I've fixed them below: >>> >>> On Mon, Oct 14, 2013 at 2:35 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >>> >>>> On Mon, Oct 14, 2013 at 2:28 PM, Rik Cabanier <caban...@gmail.com>wrote: >>>> >>>>> On Mon, Oct 14, 2013 at 1:31 PM, Timothy Hatcher <timo...@apple.com>wrote: >>>>> >>>>>> On Oct 14, 2013, at 12:43 PM, Rik Cabanier <caban...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Also, how would your suggestion tell the UA about what areas are >>>>>> associated with the elements? What happens if an element is no longer >>>>>> focused? The ring is drawn into the canvas bitmap so those pixels have to >>>>>> be regenerated. >>>>>> >>>>>> >>>>>> Focus rings are usually larger than the control they surround. How is >>>>>> the developer suppose to know the pixel padding needed for each >>>>>> platform's >>>>>> focus ring? Guess and hope for the best? >>>>>> >>>>> >>>>> Why would he need to know this? Is it for the path that describes the >>>>> ring? >>>>> >>>> >>>> Isn't focus ring drawn on the canvas? If so, it's important that the >>>> focus ring fits within the canvas. e.g. consider focusing an element of >>>> 100px by 100px inside a canvas of the same size. If the focus ring were to >>>> be drawn around the element that currently has focus, then the entire focus >>>> ring would be drawn outside of the visible region. >>>> >>> >> True. That sounds like bad design though. >> > > Why? It doesn't seem particularly strange to have an element occupy the > entire canvas momentarily. > No, but I wouldn't never make the focus ring as large as the canvas. > > Wouldn't you have the same problem with focusable content in an >> "overflow:hidden" element that just fits its child? >> > > Even if this was broken, we could fix that because the focus ring is > currently drawn by the UA. On the other hand, we're exposing an API to > manually draw the focus ring on the canvas, then it's much harder to fix it. > > And I'm getting totally confused by this whole discussion because you've > been kept telling us that UA could draw focus ring later to mitigate > issues/concerns we've raised while at the same time telling us that authors > have to call these functions whenever focus changes to redraw the focus > ring. > > It's one or the other. The focus ring should be either drawn by this API, > in which case, all the concerns we've raised thus far stands; or that the > focus ring is drawn by UA at its discretion (potentially synchronously) in > which case the function name should be changed. > Sorry if I was confusing. These API are a bit odd so it could be that some subtleties were lost. For drawSystemFocusRing, the UA will always draw the ring immediately/synchronously when you call drawSystemFocusRing. For drawCustomFocusRing, the UA *could* draw the ring immediately (in case of high contrast), or it returns true so the author should draw it. The author can decide when he draws the ring. > > Would drawing the system focus ring taint the canvas pixels? (Drawing >>>>>> form controls into canvas via SVG images and <foreignObject> has been >>>>>> considered taint worthy because it could leak the user's UI theme.) >>>>>> >>>>> >>>>> I'm unsure if it should taint the canvas. How much information would >>>>> be leaked that isn't already available through other means? >>>>> >>>> >>>> It may, for example, leak information as to whether user's machine is >>>> in high contrast mode, which is another dimension for finger-printing user. >>>> >>> >> Yes, maybe this should taint. Dominic, what do you think? >> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
