On Nov 29, 2007 8:59 PM, Nicholas Shanks <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>><br></div>> Same thing - I think the needed API is there.<br><br>Okay, this is good. I'm not too sure where the lines are drawn between<br>what should be done in the client and what should be done in the<br>
engine. I wanted the latter one to apply wherever WebKit was used<br>though, not just in one client browser or another.<br><div class="Ih2E3d"><br>[...]</div><div class="Ih2E3d"><br>>> • Ability to right-click on an element and remove it from flow
<br>>> (probably by adding a display: none attribute; so the DOM tree is<br>>> intact)<br>><br>> The API capabilities needed for this are there. Can't comment on it<br>> as a UI feature request.<br>
<br></div>I thought contextual menus were handled by WebKit. Again, this isn't<br>something that should only be in one client app, but ought to be<br>everywhere HTML is rendered, so that the user experience is consistent
<br>and the feature doesn't get mis-implemented or simply left missing<br>from some client.<br></blockquote></div><br>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.