Apple's feature and performance goals for WebKit
In the spirit of greater openness, here are some of the general areas where Apple is interested in improvement in the near to mid term, in no particular order: - Major JavaScript performance improvements. JavaScriptCore improved a lot since the Safari-3-stable branch; we think this is an important area for continuing improvement. We've already had a lot of non-Apple contribution here and welcome more. - Support for offline web applications. We have local SQL storage now. We're also interested in many of the other evolving HTML 5 and Web API features for this. - Better compliance to specifications including CSS 2.1, XMLHttpRequest, and so forth. - Improvements to rich media integration (you can see this with the recent HTML5 <video> and <audio> support). - Improvements to graphics, including more complete support for SVG and for new <canvas> features from HTML5 and other browsers. - Continuing to push the envelope with CSS, with experimental support for advanced CSS features. - HTML5 support generally, as the spec becomes more complete. - Support for features of interest to web developers. - Memory footprint improvements. - Support for more advanced Web API specs of interest, such as possibly Selectors API or XMLHttpRequest v2. - Continuing web compatibility improvements. - Additional performance improvements to page load speed. 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. It might be worth collecting this kind of data on a wiki page. Regards, Maciej
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. • 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.) • Support for the <link> navigation elements in HTML headers and an API to be exposed with Safari implementation. • Alternate stylesheets automatically offered with Safari interface for switching between them (will require API for other WebKit clients) • Allow user disabling of horrible/clueless author stylesheets (will require API) • A means by which to inject CSS and JavaScript into sites I visit, and have those modifications remembered across sessions. • A means by which to disable quirks mode for text/html (i would like this to be a persistent pref) • A means by which to disable <marquee>, <applet> or other arbitrary things • 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) • 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 • 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. 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. - Nicholas.
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
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.
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
On Nov 30, 2007, at 12:27 PM, Rob Napier wrote:
On Nov 29, 2007 8:59 PM, Nicholas Shanks <contact@nickshanks.com> wrote: On 30 Nov 2007, at 00:27, Maciej Stachowiak wrote:
• 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.
The WebKit API on Mac provides some built-in context menu items, but gives applications full customization over the context menu items. So you can either add custom context menu items, for instance to add the feature Nicholas wants, or remove existing items. Regards, Maciej
participants (3)
-
Maciej Stachowiak
-
Nicholas Shanks
-
Rob Napier