[webkit-dev] Apple's feature and performance goals for WebKit
contact at nickshanks.com
Thu Nov 29 17:59:25 PST 2007
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
> 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.
>> 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
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
> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2427 bytes
Desc: not available
Url : http://lists.webkit.org/pipermail/webkit-dev/attachments/20071130/fec4924c/smime-0001.bin
More information about the webkit-dev