- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 12 Sep 2013 19:05:26 +0000 (UTC)
- To: Brett Zamir <brettz9@yahoo.com>
- Cc: whatwg <whatwg@whatwg.org>
On Mon, 19 Aug 2013, Brett Zamir wrote: > > As far as a user-facing application, for the first case, I have some very > preliminary (but usable) proof-of-concept work for a Firefox add-on (along > with not-yet-reusable Node.js and PHP implementations) at > https://github.com/brettz9/httpquery . Generally speaking, browser add-ons aren't use cases for Web features, they're use cases for browser features. I've ignored anything in your e-mail that wasn't a solution to a specific user problem (i.e. that wasn't a use case). That leaves: > The use case here is the same as why someone would want to use the find > bar Users want to use the find-in-page feature because they have loaded a page that contains some text, but they don't know where in the text it is, so they search for it. Doesn't the find bar already solve that problem pretty completely? > use Firebug Firebug is a feature for debugging sites during development. While certainly that can be made better, it doesn't require standard features to be implemented -- it's a browser feature, needing only hooks into the browser to provide all its features. > apply user scripts to a page A user would do this to change a page to do what the user wanted rather than what the author wanted. It seems like HTML already provides plenty of ways for a browser to implement such features. > use a Microdata-aware search engine A user would do this to find data on the Web. There's certainly plenty more work to be done in this area, but it's not clear how your proposal helps improve this. Can you elaborate on how exactly your proposal helps search engines help users find materials better? Fundamentally, I don't think you've described the problem you're trying to solve succintly enough for any proposal to be evaluated. I recommend putting aside the solution you have, and first trying to completely describe the problem. This should be something you can do in a few short sentences. > > I think that in practice we're going to reach practical limits in user > > agents rendering tables long before we're going to reach practical > > limits of document size. A multimegabyte table is going to cause > > layout problems before it takes appreciable time to download. > > How is that possible? Try it. Downloading a megabyte of succint HTML takes a few seconds. Try rendering it in a browser. Try manipulating it (e.g. changing font sizes): http://damowmow.com/playground/demos/tables/004.html Even today, the page loads in a few seconds, but hovering around that page drops the frame rate of the page to single digits. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 12 September 2013 19:05:51 UTC