W3C home > Mailing lists > Public > public-html@w3.org > December 2011

Re: HTML Canvas 2D Context Extensions - for review

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Mon, 19 Dec 2011 00:28:08 +0000
Message-ID: <CAEhSh3c6S1qQgN_ut7xe9eP61++1pnHuHGLNhpoKFTtgFbfqvg@mail.gmail.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: Steve Faulkner <faulkner.steve@gmail.com>, HTMLWG WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Sun, Dec 18, 2011 at 10:49 PM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote on 12/18/2011

[snip]

>> Authors are poorly placed to create focus rings matching the user's
>> special requirements. This is why, with CSS, authors can override
>> :focus styles, and users can override them back. If authors draw their
>> own rings when users have special requirement, users will lose that
>> control in the case of <canvas> content.

[snip]

> OK but those user supplied style sheets do not inherit system settings. All
> the CSS system settings were dropped from CSS 3 due to platform
> inconsistencies. Also, users have stopped creating their own style sheets,
> in general, as due to the use of absolute positioning, etc. custom user
> style sheets can get people into trouble - although not necessarily for
> focus rings. I would not want to apply a custom user style sheet on top of
> Google+, Facebook, Lotus Connections, or Flickr.

I was deliberately being vague about whether user preferences are
enforced versus author CSS via user stylesheets or some equivalent
mechanism (e.g. a browser UI), and whether those user preferences were
sourced from system or UA configuration. For me the key point is the
content can be restyled to meet user requirements.

I agree with you that a lot of important sites make it a lot harder
than necessary to do this - but that's a bit of a tangent.

However, forcing a user style to indicate :focus using CSS's outline
feature is fairly safe, even with such sites, because it doesn't have
layout implications.

>> Contrast Step 2 for the two methods carefully:
>>
>> drawSystemFocusRing: "If the user has requested the use of particular
>> focus rings (e.g. high-contrast focus rings), or if the element would
>> have a focus ring drawn around it, then draw a focus ring of the
>> appropriate style along the path, following platform conventions, and
>> abort these steps."
>>
>
>> drawCustomFocusRing: "If the user has requested the use of particular
>> focus rings (e.g. high-contrast focus rings), then draw a focus ring
>> of the appropriate style along the path, return false, and abort these
>> steps."
>>
>> If you just want to let the system draw a focus ring, use
>> drawSystemFocusRing.
>>
>> If you want to draw a custom focus ring, use drawCustomFocusRing but
>> check its return value is true before manually drawing your ring. If
>> the user has special focus ring requirements, the system should draw
>> the ring, the method should return false, and the author should not go
>> on to draw the ring.
>>
> What happens if the ring is a combination of ellipses and stars around it?

Sorry, which ring are we talking about? The system ring, the user's
special ring, or the author's custom ring?

The system ring will be drawn by the system only if
drawSystemFocusRing is called.

The user's special ring will be drawn by the system if
drawCustomFocusRing is called and returns false.

The author's custom ring should be drawn by the author if
drawCustomFocusRing is called and returns true.

> Are you going to pick up the high contrast settings for the stars?

If you are asking whether the author needs to pick up the high
contrast settings when manually drawing a focus ring, then that's not
necessary, as a high contrast focus ring counts as a special ring to
be drawn by the system, so drawCustomFocusRing will return false and
the author won't draw anything.

> I understand your point but I don't think the solution is complete for custom
> focus rings.

Cool, let's unpick that.

> So, if an author needed to draw one they are not going to
> follow conventions.

Sorry? Not sure what you're saying here.

> Also, the convention for high contrast might be a solid
> black line and if you have a black background you may not see it.

So in this scenario, drawCustomFocusRing returns false (since the user
has a special focus ring). Therefore the author does not draw their
ring. But the user's software draws a black line in the path indicated
by the call to drawCustomFocusRing. Unfortunately, it's invisible
against the black pixels of the canvas.

Is this example speculative? Or is this how some high contrast focus
rings are drawn in practice? Can you point to some real examples? It
sounds very brittle.

> I am not saying that Ian's intent is not admirable here. I am simply saying
> that I don't think the extra step will always deliver the desired result so
> should we require it to be there?

I'm not convinced that we can come up with a good API to expose all
the information required for the author to draw a custom focus ring
that both takes account of their canvas and of the user's preferences.
(I'm even less convinced we could get authors to make use of it in
practice.)

In the unlikely event we can even work out what the relevant
information is, I think we'd be better off having user agents use that
information to draw the focus ring. For example, user agents could
draw a focus ring for high contrast that uses a white band with a
black inner ring to ensure there is some contrast round the ring.

Ian's text leaves user agents free to do the best job they can here, I think.

--
Benjamin Hawkes-Lewis
Received on Monday, 19 December 2011 00:28:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:42 GMT