Re: [whatwg] NoDatabase databases

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
> .

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):

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       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 12 September 2013 19:05:51 UTC