W3C home > Mailing lists > Public > public-html@w3.org > April 2008

Re: Browser defaults should please the mass of authors

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 21 Apr 2008 13:27:18 +0300
Cc: "public-html@w3.org WG" <public-html@w3.org>
Message-Id: <4ACF7DBE-E8F2-4F45-A6B3-058B92911B89@iki.fi>
To: "L. David Baron" <dbaron@dbaron.org>, Ian Hickson <ian@hixie.ch>

On Apr 21, 2008, at 11:51, L. David Baron wrote:

> On Monday 2008-04-21 11:13 +0300, Henri Sivonen wrote:
>> I think this is a bad recommendation. Browser defaults should  
>> please the
>> mass of *authors*. If this is in conflict with pleasing users,  
>> users should
>> have to opt in by flipping a pref.
>
> But users shouldn't have to become experts on which preferences to  
> modify in order to get the best experience on the Web.

I agree that ideally it would be this way, but I don't know how to  
reconcile this goal with the behavior of a substantial proportion of  
Web authors. (I'm taking the author behavior as constraint that is  
posed by the environment and that is practically unchangeable.)

> We should provide the best experience to new users as much as to  
> experienced ones; this helps keep the Web usable to the masses  
> rather than just experts.

But the problem is that when both a browser vendor whose product has a  
substantial desktop user base and a substantial proportion of authors  
believe that users don't change perfs and the vendor and the authors  
disagree on what's best for the users who don't change the defaults,  
an arms race ensues. So far, this has always lead to making it even  
harder for users to take counter measures. Thus, setting user-oriented  
defaults doesn't lead to the best experience.

This is a long-time pattern:

  * Mosaic and Netscape had a gray default background. Arguably, this  
was a calmer reading background than white on the CRTs of the day.  
Authors felt this was horribly ugly and overrode the colors. The color  
prefs became powerless for users who really would have benefited from  
toning white backgrounds to something less bright.

  * Mosaic and Netscape had a border around linked images. This  
presumably was meant to help the user figure out which images are  
linked. Authors felt this was horribly ugly and overrode the border to  
zero. The border is so unpopular that Opera and Safari can get away  
with not having it without Breaking the Web. (I think it would be nice  
for author if Firefox and IE got rid of it, too.) Now people who don't  
understand visual symbols well have a harder time to figure out which  
images are links than in an alternative reality where the border had  
been an off-by-default pref.

  * Netscape on Windows (and IE on Windows after it) defaulted to 16px  
font size. 16px text is more legible than smaller text. Again, authors  
thought the default was too big and overrode it--sometimes as a factor  
of the default so users can no longer make the pref smaller without  
causing a substantial number of pages to have *really* small text.  
Hence, the font size pref has become almost useless--a user might get  
away with changing it to 18px without Breaking the Web, but that's  
about it. Now browsers have to provide zooming that requires  
repetitive user action.

  * Mac IE 5 had Mac-like focus outlines for links. This was most  
likely done for the benefit of users who use the keyboard over the  
mouse. Unfortunately, the focus outline showed up when a mouse user  
clicked a link before the layout of the old page was torn down.  
Designers thought this looked horrible and sought to make the outline  
go away to the detriment of users who really wanted to use the  
keyboard focus. To the credit of Safari, this is now something that  
Mac-based designers no longer try to defeat as forcefully: Safari  
makes this a pref that keyboard users have to opt into. The dotted 1  
px outline of Firefox and Windows IE also has this problem but to a  
lesser extent, since the outline is less conspicuous. (It's still a  
problem and it's cruel to keyboard users when authors use JS to  
immediately blur things in order to keep the ugliness of the outline  
from interfering with their art.) I think it would be mistake to ship  
with https://bugzilla.mozilla.org/show_bug.cgi?id=53927 fixed by  
default.

So it seems to me that user-oriented do-good defaults no longer work  
once the authors have noticed and retaliated. I don't know how to  
avoid this except by making the defaults author-oriented so that the  
escalation doesn't start and requiring extra effort on the part of  
users to whom particular behavior really matters. In particular, when  
accessibility and prettiness are at odds, I think the defaults should  
always cater to prettiness. The users to whom the more accessible way  
matters will learn to change the pref and learning and changing it is  
less of a burden than having to deal with an arms race.

On Apr 21, 2008, at 12:13, Ian Hickson wrote:

> The text I added to the spec which
> is what Henri is referring to would, if implemented, block _all_ new
> author-requested windows, including those from window.open(). All  
> the ways
> of opening new windows go through this same algorithm, it's the only  
> part
> of the spec that creates a new window.

As Maciej pointed out on IRC, authors would defeat this by emulating  
new windows in the browser content area, which would be even more  
annoying. And counter measures would involve solving the Halting  
Problem. You need to allow authors to annoy users in easily detectable  
declarative ways by default--otherwise things get much, much worse.

As a spec change request, I request that the spec suggest that users  
be offered an option to block new windows but that this feature be  
*off* by default.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Monday, 21 April 2008 10:28:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:54 UTC