On Nov 29, 2007 8:59 PM, Nicholas Shanks <contact@nickshanks.com> wrote:
On 30 Nov 2007, at 00:27, Maciej Stachowiak wrote:

>> • A means by which to inject CSS and JavaScript into sites I visit,
>> and have those modifications remembered across sessions.
>
> Same thing - I think the needed API is there.

Okay, this is good. I'm not too sure where the lines are drawn between
what should be done in the client and what should be done in the
engine. I wanted the latter one to apply wherever WebKit was used
though, not just in one client browser or another.

[...]

>> • Ability to right-click on an element and remove it from flow
>> (probably by adding a display: none attribute; so the DOM tree is
>> intact)
>
> The API capabilities needed for this are there. Can't comment on it
> as a UI feature request.

I thought contextual menus were handled by WebKit. Again, this isn't
something that should only be in one client app, but ought to be
everywhere HTML is rendered, so that the user experience is consistent
and the feature doesn't get mis-implemented or simply left missing
from some client.

As a developer using WebKit, I definitely don't want my rendering to magically change just because the user wanted to change something in Safari. Some of the places I use WebKit aren't obviously "HTML" to the user (in an IM chat window for instance), so the fact that we would then render incorrectly would be exceedingly confusing. There's no way he would think "oh, that's a WebKit configuration I made." I'm very appreciative that WebKit keeps this stuff out of the Framework so my non-browser apps don't become dependent on Safari or any other web browser.

-Rob