[webkit-dev] Proposal: Add support for focus rings in Canvas 2d

[Rik Cabanier]

On Mon, Oct 14, 2013 at 2:58 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Mon, Oct 14, 2013 at 2:50 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> On Mon, Oct 14, 2013 at 2:38 PM, Ryosuke Niwa <rniwa at 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 <rniwa at webkit.org> wrote:
>>>
>>>> On Mon, Oct 14, 2013 at 2:28 PM, Rik Cabanier <cabanier at gmail.com>wrote:
>>>>
>>>>> On Mon, Oct 14, 2013 at 1:31 PM, Timothy Hatcher <timothy at apple.com>wrote:
>>>>>
>>>>>> On Oct 14, 2013, at 12:43 PM, Rik Cabanier <cabanier at 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?
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131014/4bfac49b/attachment-0001.html>