- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 24 Nov 2010 14:59:18 -0800
On 11/24/2010 2:45 PM, Aryeh Gregor wrote: > On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchard<chuck at jumis.com> wrote: >> I greatly appreciate the value of standards, but I am at the same time, very >> sensitive to the effects that centrally planned restrictions have on groups. >> The aggregate effect is one where tens of millions are harmed by the >> decisions of a few people in authority. I'd rather see the masses harmed by >> themselves than by authority. > There are two "masses" here: authors and users. You advocate giving > total control to authors, but that comes at the expense of taking > control away from users. The web platform is designed to favor users' > needs over authors' needs. Websites are all forced to have a lot in > common: you can zoom the same way, copy and paste the same way, > navigate the same way, and so on. This is part of why the web > platform is better for users than, say, Java applets -- it does *not* > give authors total control. I've not advocated an all-or-nothing approach, and I continue to stand my groun dthere. I'm advocating allowing authors to access two vital bits of information, which could pragmatically be exposed with a minimum of programming hours on the part of browser vendors. You can't zoom in the same way. innerWidth and innerHeight are properties that an author can choose to use or not use. I understand working abstractions, concepts... and making generalizations. I've not advocated allowing an untrusted script to set the zoom level nor "over-ride" the zoom controls which are completely outside of the DOM and window frame. The web platform is better for users than Java because it's more open. There is no "definite" web platform, there are collection of standards, and a growing consensus about which standards are vital to implementation. > So in fact, one of the many little things that makes the web platform > nice is how users can zoom easily. For a small percentage of users, > this is essential. A typical author has few users and will get no > complaints if they mess up zooming, but a browser has tens of millions > to billions of users and will definitely get complaints if the browser > adds a feature that lets even one percent of sites mess up zooming. > It's then up to the few browsers to fix the problem, because you'll > never get millions of authors to all do it. How will the browsers fix > the problem? Probably by making the feature useless, like by making > it do nothing or return false values. Then you're better off having > never added the feature in the first place. Lets? First, the feature is being made available by other browser vendors. Second, "Lets?"... If the browser lets a site crash the window, pop up multiple tabs, or otherwise cause a DOS, that's a big issue. But it is not the UAs responsibility to make sure that a middle school student uses <img alt=""> tags correctly. Lets keep on the topic at hand: exposing a minimum amount of data for authors who want to use that data. There is no existing evidence that masses of programmers reading the Documentation on how to use screen metrics will make mistakes in any substantial number. It's pure conjecture. There are existing use cases, of using the data correctly, and of the data being exposed intentionally. There are also existing cases of zoom being mishandled, through the misapplication of innerWidth and innerHeight. So if we can get off the generalizations, and simply look at the merits of the concept, we can move onto looking at the merits of existing proposals and practices. Until then, we're stuck in arguments which have very little to do with the technical data at hand. > That's the point of the concern over author misuse. If authors misuse > a feature enough to affect even a small percentage of users, browsers > will compete to fix it if possible. Consider pop-up ads -- browsers > now all block those, taking control away from authors for the benefit > of users. Or consider the px unit, which in practice doesn't > necessarily have anything to do with pixels anymore. We don't want to > add a feature to the platform if it will have to just be disabled when > a significant number of authors use it. (Whether this is the case for > some *particular* feature, like exposing zoom info, is of course a > separate question.) We're considering the second item. Right now. And man am I happy with vendors realizing that denial of service IS their responsibility. If mozilla wants to add a permissions setting to say "Reset stylesheets, don't allow access to zoom info", or otherwise "don't run ads, etc etc", that's fantastic. That's a great place to have competition. There's no reasonable case for blocking those of us with mature and experienced judgment, from accessing data which would otherwise be visible, if it weren't for all those "new" programmers who might set themselves aflame. At present, I have not seen an actual argument based on evidence here. We're using prior examples and trying to draw analogies. I'm fine engaging them, but when I have, I've found that they are not sincere to the case at hand. So again, if you want to talk about websites mishandling zoom, as things currently sit, without exposing the data I want --- they do mishandle zoom. I have a poor zoom experience on many websites. There's no evidence that enabling programmers to access CSS pixel data will harm usability. There is evidence that it will enhance usability for programmers who use it properly. Focus. -Charles
Received on Wednesday, 24 November 2010 14:59:18 UTC