[webkit-dev] Apple's feature and performance goals for WebKit

[Nicholas Shanks]

On 30 Nov 2007, at 00:27, Maciej Stachowiak wrote:

>> • Support for the <link> navigation elements in HTML headers and an  
>> API to be exposed with Safari implementation.
>
> The DOM API is sufficient for WebKit clients to implement this if  
> they choose to.

Well that could lead to incompatible or buggy implementations in some  
clients. I think it would be better if WebKit offered a simple  
dictionary or whatever that everyone can use equivalently. If a client  
wants to write their own and parse the relevant parts of the DOM  
themselves, they're free too, but don't force every implementation to  
reinvent this wheel.

>> • Alternate stylesheets automatically offered with Safari interface  
>> for switching between them  (will require API for other WebKit  
>> clients)
>
> The DOM API exposes alternate stylesheet switching.

Didn't know that. Cool :-)

>> • Allow user disabling of horrible/clueless author stylesheets   
>> (will require API)
>
> Again, already possible at the API level.
>
>> • 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.

>> • A means by which to disable quirks mode for text/html (i would  
>> like this to be a persistent pref)
>
> That does not make sense to me. What possible reason would there be  
> to show a quirks mode page in standards mode?

Mostly to see how horrible it looks. I don't want to grace such sites  
with my patronage, and it would be nice if I could be told, rather  
than having the fact covered up. It's basically for developers and  
standardistas but would also be useful for gauging the competency of  
the author. Not a high priority.

>> • A means by which to disable <marquee>, <applet> or other  
>> arbitrary things
>
> Applet can be disabled by turning off Java. <marquee> can be  
> (effectively) disabled with a user stylesheet.

I meant make them be treated as unrecognised tags. But, other  
'arbitrary' things could include XMLHttpRequest or other areas of  
JavaScript, whilst leaving the rest functional. This isn't a high one  
on my list either :-)

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

>> • Ability to customise one's HTTP headers manually, especially the  
>> Accept-* ones  (another persistent pref)
>> 	• and further, the ability to specify what headers would be  
>> automatically sent in response to a 3xx code
>
> This capability exists at the API level (every request is sent to  
> the ResourceLoadDelegate before hitting the net).

Okay, good to hear.

>>  When rendering a web page aurally, the page should go through a  
>> series of xslt transformations: (HTML to) XHTML to SSML,  which  
>> would then either be sent to a third party TTS (e.g. swift from  
>> cepstral.com) or further transformed to PlainTalk + Applebet and  
>> sent to the Speech Manager.
>
> I think the current VoiceOver architecture works fine for rendering  
> web pages aurally, or at least, any specific issues could be  
> addressed based on the existing architecture. I'm not sure what the  
> basis for your request is.

I want to include pronunciation data in my web pages. The only way to  
do that (that I can see) is with SSML embedded in an XHTML document.  
This would be used for isolate words, whose pronunciation cannot be  
discerned from context, and cases where pronunciation of a word or  
phrase differs from what a person would normally expect (perhaps a  
page discussing phonology or speech impediments). Even if computers  
were as smart as humans at language processing, they'd still get it  
wrong. That's why the pronunciation needs to be explicit.

>> And a developer-only feature:
>> • A means by which to manipulate the current media to something  
>> other than screen (e.g. for previewing tv, handheld, print,  
>> projection) and override various media properties manually (page  
>> dimensions, maximum volume) so media queries can be tested against  
>> them.
>
> This is a case where I don't think we currently have the right API  
> capabilities. I encourage you to file a bug.

another day perhaps, it's 2am now.

- Nicholas.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2427 bytes
Desc: not available
Url : http://lists.webkit.org/pipermail/webkit-dev/attachments/20071130/fec4924c/smime-0001.bin