Re: HTML Canvas 2D Context Extensions - for review

Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote on 12/18/2011
06:28:08 PM:

> From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
> Cc: Steve Faulkner <faulkner.steve@gmail.com>, HTMLWG WG <public-
> html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
> Date: 12/18/2011 06:28 PM
> Subject: Re: HTML Canvas 2D Context Extensions - for review
>
> 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.
>
I would agree that it is fairly safe but I am concerned about how that will
work with the rich set of GUI widgets in Dojo.


> >> 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?
>
That would be the customFocusRing.

> 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.
>
You do notice that the part of optionally informing the user of the focus
ring does not happen in that situation - it simply draws using the style
selected by the user. Now if we had paths bound to elements then we would
be safe.

> 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.
>
What I am saying if there is a high contrast focus ring style chosen the
stars would never get the benefit of the system setting. Perhaps that type
of focus ring conveyed special semantics related to the application.

> > I understand your point but I don't think the solution is completefor
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.
>
If you see my last clarification about semantics the author will most
likely skip the method altogether to create a custom focus ring as when the
user puts the desktop in high contrast mode they would not get the desired
effect.

> > 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.
>
Well, let me say that it was fixed in Dojo through a CSS workaround that
could detect that the user was in high contrast mode and make adjustments
for more things than just the focus. This included things like the bounds
of text boxes, grid cells, and so on.

> > 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.
>
It is far better than what was there before the last drawCustomFocusRing
was accepted. That much I agree. I simply think it has some holes. If we
were able to get setElementPath accepted for fallback content then I could
probably live with the gaps. Although, I do think we will be revisiting
this again for the reasons I mention.
> --
> Benjamin Hawkes-Lewis
>