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

[Maciej Stachowiak]

On Nov 29, 2007, at 3:16 PM, Nicholas Shanks wrote:

> On 29 Nov 2007, at 10:56, Maciej Stachowiak wrote:
>
>> We may post more details about some of these soon. I'm curious what  
>> is of interest to other WebKit contributors. I'm especially  
>> interested in areas where particular organizations or individuals  
>> might be interested in directly contributing.
>
>
> In reply to Maciej's goals email, I thought more about the features  
> I would like to see in WebKit that are not there for one reason or  
> another, and would like to know how best to add these on a  
> conditional basis such that normal users can remain oblivious, and  
> power users can customise them. For example, an API for Safari,  
> NetNewsWire, Sandvox &c. to hook into, or user defaults that apply  
> to all WebKit clients without the app needing to support them  
> explicitly. In the case of the latter, how should the defaults be  
> named?
>
> Things I would like to see (new features and high priority bugs)  
> include…
>
> • Fixed support for :last-child, :nth-child and related selectors.  
> This is probably the biggest issue.

I agree with complete support for Selectors as a goal. I don't think  
this needs to be conditional in any way. One thing that is important  
is to make sure that support is added in a way that is performant and  
properly handles dynamic updates, so we don't set ourselves up

> • Support for better typography, including kerning, automatic  
> ligatures, true (AAT/OpenType) Small Caps, font-stretch, &c.  (this  
> can be a pref—off by default, if Apple prefers performance to  
> presentation. As I have a fast computer i don't really care about a  
> few milliseconds here or there during layout, i spend much longer  
> reading the text than i spend waiting for it to be drawn. Maybe  
> there should be browser engine tests that examine how easy the  
> screen is to read.)

We're interested in investigating ways to get better typography  
without as much or possibly any perf hit. I'd agree with this as a  
goal. I guess I should have mentioned typography and text support, and  
I think our @font-face support shows our commitment there.

> • 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. Having this as a UI feature in Safari is not a WebKit  
request so I can't comment on that.

> • 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. As for the Safari  
UI feature request, again, this is not the place.

> • Allow user disabling of horrible/clueless author stylesheets   
> (will require API)

Again, already possible at the API level, UI requests should go to the  
relevant browsers.

> • 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, can't comment on it as a  
UI request.

> • 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? Standards mode pages  
already do not trigger quirks mode. But if you really want this at the  
API level, you can do it by preprocessing incoming HTML to force a  
standards mode doctype.

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

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

> • 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 (ever request is sent to the  
ResourceLoadDelegate before hitting the net). Can't comment on it as a  
UI feature request.

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

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

Regards,
Maciej