Hi there Steve - thanks for the suggestion, but Web Components don't fit
in with our preferred development idiom in our communities. Our emphasis
is on accessibility and openness - whereas by design, the markup and
implementation for web components is hidden behind an impenetrable boundary.
We will need to make sure that we only make use of components which work
on the standard web - that is, based on the use of a standard, open DOM
in which the component's markup remains accessible. This means, for
example, that accessibility and markup can be tweaked after the fact, as
well as allowing for other transformations of the user interface. A
cornerstone of our approach to accessibility is that interfaces are
adaptible - and by definition, Web Components are not adaptible since
all of their markup and behaviour has been baked in by the originator.
Cheers,
Antranig
On 14/08/2014 17:43, Steve Lee wrote:
Did you look at web components? I know Mozilla X-tags includes a drop
down but I've not idea if it is accessible or indeed any good. Brick
and Polymer may also have useful items. I've not played with them but
this is on my short term roadmap for P4A
Of course Web components aren't *there* yet in browsers [1] and
require polyfills. Custom elements are fairly well supported by
browsers with sane polyfills (at least on desktop). The polyfils are
platform.js (polymer and X-tags), and document-register-element.js
Contributing accessibility to as custom element in an existing
collection strikes me as a great use of efforrt.
Here are couple of useful articles on thestate of Web components [2]
1: http://jonrimmer.github.io/are-we-componentized-yet/
2: http://developer.telerik.com/featured/web-components-ready-production/
Steve Lee
OpenDirective http://opendirective.com
On 14 August 2014 08:59, Tony Atkins <[email protected]> wrote:
Hi, All:
In order to implement the reviewer interface for the Common Terms Registry,
I need an accessible drop-down menu that I can wire into my data model, for
example to allow the user to select their language. This would also be used
in an alternate form as a simple drop-down menu (logout links in a "user"
menu). If you want to see it in situ, here are the mockups.
My preference is to start with a select box, as it comes with decent
keyboard arrow support for free. However, there are serious limitations on
how well you can style selects, as most browsers strongly impose their
implicit styling on them. Most sane approaches seem to hide the select
itself and present an alternate control in its place.
Last week, Antranig and I did a brief review of libraries that follow this
approach. We talked about starting with jquery-selectbox:
http://marcj.github.io/jquery-selectBox/
There are some bugs with multi-selects and Firefox (I've filed issues for
both), but it seems as good a starting point as any.
I wanted to check in with the group and make sure that:
No one has already created a fluid component that addresses the general need
for drop-down menus and upstyled select boxes. I haven't seen one in our
demos or code repo.
There are no other better starting points for this work.
Please comment.
Thanks,
Tony
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
