W3C home > Mailing lists > Public > www-international@w3.org > January to March 2014

Re: Encoding: Referring people to a list of labels

From: Andrew Cunningham <lang.support@gmail.com>
Date: Wed, 29 Jan 2014 23:18:11 +1100
Message-ID: <CAGJ7U-V7UCA4RsfBAuNVD-4+vF27=QH5aejuUzDB7mNxXHJpKA@mail.gmail.com>
To: Henri Sivonen <hsivonen@hsivonen.fi>
Cc: Anne van Kesteren <annevk@annevk.nl>, WWW International <www-international@w3.org>, John Cowan <cowan@mercury.ccil.org>, Asmus Freytag <asmusf@ix.netcom.com>

On 29/01/2014 9:31 PM, "Henri Sivonen" <hsivonen@hsivonen.fi> wrote:

> There's a big difference between no browser support and support in
> only one major browser. Authors using those scripts should use
> Graphite fonts and tell their users to use Firefox. As content
> published in these scripts using the pure Unicode representation
> increases, other browsers will have a reason to support these scripts
> as well.

Easier said that done,  especially when users may have limited IT skills.

Firefox provides no UI to switch graphite support on and off.

An added complication is that some of the graphite fonts I use
are both graphite and opentype fonts with the graphite support being both
more flexible and more powerful than the openrype implementations.

Unfortunately the CSS folks chose to only support opentype fonts explicitly
in the font modules. Some rules will work others will not.

It is pot luck whether graphite is supported or unsupported. There is
nothing the web developer can do.

They have no control.

Maybe the CSS cascade can be used to provide both rules for opentype and
graphite features. But such an approach is problematic and awkward.

Saying that a web developer is responsible for educating end users is a
cope out;  it is poor UX design.

> If you want browsers to support these scripts, working around the
> shortcomings of non-Firefox browsers is strategically terrible, since
> that gives them no incentive to match Firefox and doesn't reward
> Firefox for being the first mover (making Firefox devs less interested
> in being the first movers on stuff like this in the future).

The reality is that the browser developers choose what they want to
implement.  There are lots of useful and crucial components in CSS that
have not been implemented or widely implemented.
Both Firefox and blink use hb-ng.  So both could use graphite shapers,  but
blink developers are not interested.

Come to think of it,  hb-ng is far from up to date in blink.

There is a reluctance to address these issuses within specs,  and there is
a reluctance to extend multilingual web support among web developers.

At the moment guidelines are being developed here for the development and
deployment of multilingual government information. Some of the languages
our government publishes in are languages that either need pseudo-unicode
fonts or graphite Unicode fonts.

I am really tempted to take your comments at face value and make a
recomendation that government websites in our juristIction only support

Begs the question should governments do that.

If it was one website...  or a small community....  maybe....

But...  even Firefox has a fair way to go before it is an ideal tool for
multilingual web typography.

Received on Wednesday, 29 January 2014 12:18:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:04 UTC