Re: The arbitrary 80% (Baby Steps)

On Wed, Aug 15, 2007 at 03:29:10AM +0000, Ian Hickson wrote:
 
> It has come to my attention after discussing this on IRC that this concept 
> of 80% may be misunderstood.
> 
> I am not saying that we should only cater for 80% of users. I think it's 
> very important to realise that -- the language should cater for 100% of 
> users, regardless of their abilities. This means catering to people with 
> legacy browsers, people with specialised browsers or with special tools 
> (like accessibility tools) added on top of their browsers, people with 
> cognitive failures, people with extremely large monitors, people who 
> prefer print media, people who prefer to read tiny text, people using 
> mobile devices, people with slow connections, people on connections with 
> multi-second or even multi-minute latencies, etc.
> 
> EVERY USER deserves to be catered for by HTML.
> 
> HOWEVER. While every USER has to be catered for, the same is not true for 
> every possible use case from the content producer side. For example, at 
> the moment it is not in the scope of HTML to handle writing photo editing 
> applications like Photoshop or movie editing applications like Final Cut 
> Pro. While it may be possible to write such applications in HTML today if 
> you are rather masochistic, it is not something that HTML makes easy, and 
> it is not likely that we will make it easy in HTML5.
> 
> The reason for having limits like this is that while the users are finite, 
> the possible types of content that could be written in HTML are infinite. 
> The only way we could cater to every single possible type of document and 
> application in HTML is to make a language so complicated that virtually 
> nobody could understand how to use it.
> 
> We want to keep the language as simple as possible while still catering to 
> the majority of content producers (and while catering to all users).
> 
> Note that the "80" value is arbitrary. It is just meant to symbolise the 
> fact that we don't want to cater to all use cases, we only want to cater 
> to the most common ones.

So stated, the principle is irrelevant to the issues under discussion. In all
instances (form fields, tables, images and other media objects, image maps,
etc.), HTML already supports the use cases for these features, both in the
form of HTML 4 and in the HTML 5 draft. The objections raised against the
omission of certain features (@headers, @for, @longdesc, @usemap, etc.), is
that while continuing to support the use cases for the underlying feature, HTML would
thereby fail to support 100% of the users by offering no (or inadequate) means
of using the feature (a media element, a form, a table etc.) in a way that
enables and facilitates proper accessibility.
> 
> 
> > I don't find 80% in any design principle.
> 
> I have added Baby Steps. Note though that the design principles are not 
> and never will be a complete description of how language design works.

This is out of order as a matter of process: unilaterally deciding to add a
principle to the draft which hasn't been discussed here, and on which
consensus hasn't been reached, oversteps the legitimate role of an editor.
This thread shows that the proposed principle is indeed contentious, and
therefore it should not be added to the design principles until and unless it
has been clarified and agreed to by the working gorup.

Received on Wednesday, 15 August 2007 05:28:45 UTC