Re: upgrading standard browsers UI

Hi Sean,

the short answer is "it depends...". Some is there, but to do more it  
takes a lot of work that is harder than it seems, even taking that into  
account. At least, that is what we have learned over 15-odd years of  
experience...

On Wed, 06 Sep 2017 07:21:58 +0200, Sean Murphy (seanmmur)
<seanmmur@cisco.com> wrote:

> This is a long shot and just a thought. Does anyone know if W3C  
> standards or the browser vendors >are going to expand the current  
> default UI elements from the current one’s? My thinking is >including a   
> menu, treeview, slider, toolbar, etc.?

Some of these things are in HTML already - for example sliders can be made  
with

<input type="range">

and they work reasonably well. There are also date, colour, and time  
pickers, included as standard although implementation is patchy - some  
browsers do and some just present a plain text field.

More of them were put into HTML 5.0, but then browsers didn't implement  
them. To make the HTML specs more like reality, HTML 5.2 (and before it  
HTML 5.1) removed things that don't actually work in at least two common  
browsers. But that doesn't mean all the things that are still there work  
in *your* browser. Different browsers implement different things :S

> I know these are available via third-party libraries. But Just wondering  
> if this could be a direction for w3c/vendors to include them, to  
> simplify the accessibility of these more complex UI >elements. I suppose  
> the HTML 5 standard would have to be updated first to make them a part of
> the core standard. Any thoughts?

I have a bunch of them...

On the one hand it seems pretty clear that there is a lot of value in  
doing this *right*. On the other hand, it is also pretty clear that we  
don't really know how to do that, so we keep experimenting.

Current approaches include trying to make implementation guidance for ARIA  
widgets - which is basically a pre-standardisation step. If we truly get  
interoperability of deployed things, it should be pretty straightforward  
to make them standards, and there are some obvious arguments for browsers  
to implement. Implementing widgets primarily in browser code *should* be  
more efficient and less error-prone than author-supplied javascript+mess.  
This applies especially to getting the accessibility right. So where there  
are standard components used everywhere, it would seem that browsers  
should be racing to take this up.

But there are a few caveats.

Browsers generally do a fair to poor job at making components accessible.  
And many of them seem to regard this in practice as something they would  
like to do rather than something they genuinely treat as a priority. (I  
know there are brilliant people working hard on accessibility teams in  
most browser development groups, who *do* regard it as essential. But I  
don't know of anyone who could honestly claim that they are given the  
resources and authority to make that into reality). So taking on extra  
work might not lead to the hoped-for accessibility gains.

That is a problem because the built in components of browsers often work  
by "magic" rather than being something that can be easily extended or  
fixed. For example, input type="date" is pretty widely supported. But in  
general there is minimal or no ability to change important aspects such as  
what day of the week the calendar starts on, or which calendar to use  
(there are some common ones other than the "standard" Gregorian calendar  
that you are familiar with), or changing font characteristics, or changing  
the amount of calendar displayed at one time.

Developers tend not to use the browser-supplied widgets, in large part  
because there is so little control over rendering that an author cannot  
know how the widget will fit into the site, which makes it hard to sell to  
a client, and because although a lot of them have basic accessibility  
built in it is actually very difficult to improve on that - so it is  
easier to make a mess of javascript and try to clean it up with ARIA, even  
though there are painful limits to what can be done that way.

Currently, it seems that browsers have given up even trying to make these  
things more extensible. Instead, they expect authors to build custom  
components, as the browsers wait until somebody demonstrates that they  
understand how to do it *right* before they build it into their platforms.

Which is a bit sad, in my opinion, but not entirely stupid.

Whenever a couple of browsers start shipping something, websites start  
using it. And generally, that means it is very hard to change without  
breaking stuff - and it is also hard to know how much stuff will get  
broken. Browsers have a long history of having serious mountains of  
complaint - and since this is the web, incredibly rude and insulting, or  
wildly exaggerated complaints - every time they break something.  
Scrambling to fix a browser is a pretty expensive repair job, so they try  
to avoid it.

In conclusion, it would be nice if browsers were a bit more willing to  
experiment - but they are businesses, and there is no reason to expect  
that they do stuff just because it is good for the world if not for them.  
Doing that *is* the mission of W3C, but it doesn't make much sense for W3C  
to produce specs that aren't actually matched by reality, so it can't  
*force* the browsers, or web developers. And developers very often follow  
some cool pattern they have learned, without thinking deeply about where  
it leads them in the long run, only what it does for the project at hand.  
Which is not surprising - it is a standard problem in the universe, for  
obvious reasons.

cheers

Chaals

-- 
Chaals is Charles McCathie Nevile
find more at http://yandex.com

Received on Wednesday, 6 September 2017 10:40:40 UTC