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 thingsApplet 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 codeThis 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
