Re: [webkit-dev] Adding main element to WebCore
My object is somewhat different. I think it's useful for the readability
use-case (and the other proposed solutions are mostly bad jokes), but it
doesn't strike me that this give you much default UI and doesn't plumb
through any new low-level capability.
In that vein, I wonder why it's not being proposed as an ARIA role instead?
On Tuesday, November 27, 2012, Ojan Vafai wrote:
As I said on the thread you link to, I don't think this element addresses
any real use-cases. I think people are far too likely to misuse this for it
to be useful for things like readability to use.
If Apple really wants this, I won't object, but my preference would be to
not implement this.
On Mon, Nov 26, 2012 at 2:01 PM, Steve Faulkner
faulkner.st...@gmail.comjavascript:_e({}, 'cvml',
'faulkner.st...@gmail.com');
wrote:
Hi all,
this is my first post to the list.
I have submitted a patch [1] to add main element support to webkit and
would appreciate your consideration.
the main element is defined here:
http://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
current
status unofficial draft, CFC [2] to publish as a first working draft via
HTML WG ends today.
Rationale and use cases:
http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction
details of data set and data analysis conducted during development of
feature:
http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html
There has been discussion and feedback provided on the WHATWG list [3]
and IRC and at TPAC 2012 HTML WG meeting.
I look forward to your comments!
[1] https://bugs.webkit.org/show_bug.cgi?id=103172
[2]
http://lists.w3.org/Archives/Public/public-html/2012Nov/thread.html#msg129
[3] threads start here:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/thread.html#msg55
--
with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
http://www.paciellogroup.com/resources/wat-ie-about.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org javascript:_e({}, 'cvml',
'webkit-dev@lists.webkit.org');
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Wed, Aug 24, 2011 at 8:36 AM, Scott Graham scot...@chromium.org wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. The API they're advocating for over in mozilla-land is strange. Why not an input type or other element with DOM events firing from it? Handling connection/disconnection seems like it shouldn't be necessary in the common case. Further API can be then hung off of the element, avoiding warts like permission prompts in most cases. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Thu, Jun 30, 2011 at 4:22 PM, John J. Barton johnjbar...@johnjbarton.com wrote: From: Alex Russell slightly...@chromium.org We observe that web developers are attempting to use DOM in both structural (semantic or component-oriented) and visual ways inside the same document. I would like to understand what you mean here: can you suggest an example or other place to read? In particular I imagine the DOM as a tree of visual components which can be interpreted in multiple ways, some of which cause the tree to become a graph. I don't understand the split between visual and components. This creates tension and requires unnatural levels of discipline. Notably: - Understanding your DOM as a retained-mode component tree is confounded by the presence of visual nodes in the document. - It's currently impossible to build new components which can be added to the tree in a native way. Instead, systems like Closure, Dojo, YUI, etc. build parallel trees of components in script which manage chunks of visual DOM. Anyone who attempts to script this visual DOM risks blowing up the entire world as ownership becomes confused. By parallel trees of components do you mean logical or conceptual components managed by Closure/Dojo et al rather than DOM? Yes. The DOM is semantic instinct leads this reality for large apps to create serious cognitive overhead. In using a new component, you must be aware of (and know the rules for) this parallel tree as well as its relationship to other DOM which, for all intents and purposes, might be just fine for *some* bits of your app. Forms are a great example of this, wherein you want a regular input type=text in one place and a constrained date picker in the next. Mixing and matching these today requires feats of discipline that custom, real DOM components could help alleviate. - The parallel trees that these toolkits create are non-interoperable. The low-level bits of these toolkits are generally interoperable to the extent that they agree on DOM, therefore, allowing components to be expressed with a DOM interface would bolster interoperability. - Working with DOM as a visual representation for components is made difficult because of tension between the desire to add structure to enable visual controls and the markup is semantic ideal. This last phrase is the one that really caught my interest, but I don't understand the sentence. How can one work with the DOM as a visual representation without adding structure? That's exactly the problem. Re-arranging elements visually often requires re-parenting them with respect to ne structure. That structure isn't there to convey meaning in terms of the tree of components, only their layout. Having to wade through this sea of formatting nodes makes working with DOM-as-component-tree less than satisfying. How can this be in tension with markup is semantic? By markup is semantic ideal do you mean gee it would be awesome if markup exactly expressed my full-formed, universally understood, perfect Web page which can't possibly exist? No. It just seems odd to juxtapose a practical thing with something that is impossible. I'm not trying to. I used lower-case s and quotes around semantic to (unsuccessfully) avoid that. Custom components will only ever have local or probabilistic non-local meaning, but my view is that's the best you'll do in any casethe Meta Crap argument, if you will. DOM is confused on many levels, and I'm only trying to explain how the desire to express the relationships between components is currently in tension with the desire to use HTML/CSS/DOM for rapid creation of component view and layout. A shadow or view axis for components can alleviate this tension. Sorry if my questions are naive. I've worked quite a lot with XBL and now we are planning to get rid of it in our code so I'm puzzled by arguments between two groups who want to improve it (or so that is how I interpret this thread). Assume that my position from here on out is this: - XBL and XBL2 contain many good ideas - These ideas may have more leverage as small additions to HTML/CSS/DOM than as a large, coordinated and interdependent spec - Many of the use-cases that XBL and XBL2 handle are not primary in the toolkits that are being used widely on the web today. As far as suitability for inclusion in the web platform goes, I argue that we should pay more attention to common practice than to un-implemented standards. One of the two has a test function for utility, and it isn't the one without users. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 5:01 AM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. This falls into the broad bucket of things that webdevs are exposed to that tend to be unnecessarily long (querySelectorAll vs. query) for no good reason. Meaning comes with use. My bias as a webdev is to want the shortest thing that means something close. In particular, since you'll be scripting through this property a LOT, having it be short is a serious win. With those preferences, is there something we can do that's better *and* shorter than shadow? Element.webkitShadowTree Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() window.WebKitShadowTreeConstructor // all trees begin at a root, right? window.WebKitShadowTreeScopeConstructor // assuming this can only be used inside the shadow tree Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
On Mon, Jun 27, 2011 at 5:49 PM, Ojan Vafai o...@chromium.org wrote: Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just on the browser side to make the UI good instead of on the web developer side. This has lots of follow-on advantages too: - Browser-provided UI is consistent for the user WRT the OS (see file pickers). Your app would need to guess to match the visual and interaction style. - Browsers can handle all of this with much less code on your part. The latency involved in building and sending the custom UI makes for a bad experience, and is it work you really want to be biting off for your app? - A11y, focus management, and all the rest with Just Work (TM). On Mon, Jun 27, 2011 at 3:37 AM, Alex Nicolaou anico...@google.comwrote: A user agent defined solution will make apps like mail, chat, Facebook, and so on all feel awful in safari versus installing a native app. It's like j2me all over again unless the website can provide a smooth ui. Alex On Friday, June 24, 2011, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Ojan On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- -- Try Gmail Offline for Chrome http://goto.ext.google.com/fastgmail-chrome , and send me your complaints! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
On Fri, Jun 24, 2011 at 7:27 PM, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Seconded. On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit editing rewrite?
On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen gga...@apple.com wrote: Some of us had a somewhat crazy idea to rewrite much of the editing code (e.g. document.execCommand) in JavaScript. Pros: -Ensures that the APIs we expose to the web are at least good enough for our own editing code I don't think this necessarily follows. Not everything exposed to the internal editing implementation would necessarily be exposed to the web. If we required that everything exposed to the internal editing implementation be exposed to the web, that would substantially slow development, since every new API would need to be vetted and possibly standardized. So this is either not true or a substantial con. It's not like that's a serial process. More to the point, assuming the current command API is the result (as proposed) and that DOM ranges are supported, it's unclear that standardization is a major risk. In any case, we won't get better APIs if we don't try and the current APIs suck hard. -Ensures that editing code never crashes (outside of JSC/V8 bugs) JavaScript can still crash -- you just get an unhandled exception instead of a segfault. It's not clear to me why that would be better. I can think of reasons why it would be worse: These crashes are much less likely to be exploitable security issues. That's one (major) plus. - Can't use standard OS tools like CrashReporter to detect problem areas. - Harder to debug, since you need to use the Web Inspector, which: - doesn't have all the features of modern C++ debuggers, like watchpoints and breakpoint commands - creates a circular dependency - Sometimes, instead of an unhandled exception, you'll just get incorrect behavior that's very hard to track down. A similar set of cons pertains to performance issues. I'm not sure that's clearly true. -Gives a clean slate for starting the editing code anew This is an argument for a rewrite, not an argument for JavaScript. A rewrite can happen in any language. A rewrite is not self-evidently a good thing. Nobody suggested it was? The basis for the suggestion is: * today's JS APIs are not fit for the tasks that are being asked of them * the command system isn't extensible from JS, causing incredible amounts of hackery and rework in every JS wrapper for editors * when things go south in the current system, crashes are potentially exploitable -Moves code out of WebCore Changing the language doesn't move the code out of WebCore. Moving code out of WebCore is not self-evidently a good thing. -If other browser vendors choose to expose the same APIs, then we can share the editing library and make the world better for web developers That's a big if. Do you have any evidence that other vendors are interested? Are there vendors specifically interested in adopting WebKit's editing library, but not WebKit as a whole? That would surprise me. Fair enough, but consider the case of a rich text editing system as exists in products like GMail and Mobile Me where the current infrastructure is as much a liability as an asset. For those systems, having better plumbing and being able to operate on more deterministic, low-level APIs for editing would be a serious plus. Cons: -Potentially slower since DOM calls are now JS--C++ -Potential for regressions due to holes in the layout test coverage -Not statically typed I notice that you don't mention the added complexity of gluing two languages together for core DOM operations. I think that's probably the main con. The bindings are already opaque. How is this really worse? I'm not too concerned about the perf hit. It should be no more than a constant-factor and, historically, the editing perf problems have been order-of-magnitude issues. You're not considering the hurt that the editing JavaScript code could put on website code. If the editing memory footprint is large, the GC hit on other websites could be substantial. JavaScript's scoping rules also have a nasty tendency to introduce accidental memory references that keep large object graphs alive, exacerbating this problem. Luckily Ojan et. al. happen to be very good at JavaScript ;-) Regards For security reasons, we might need to instantiate a new copy of the editing code for every webpage. That could be a substantial memory use regression. As for the functionality regressions, I think they're inevitable. We'd hit most of the same issues trying to refactor the existing C++ code on top of better APIs. I agree that a rewrite inevitably introduces a large number of bugs, regardless of whether it happens in C++ or JavaScript. However, I don't agree that refactoring inevitably introduces just as many bugs as rewriting. I would submit that the entire history of the WebKit project demonstrates the value of refactoring over rewriting. Geoff ___ webkit-dev mailing list
Re: [webkit-dev] MD5 in WebCore
Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
a secure hash? New protocols should be avoiding it.
On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman micha...@google.com wrote:
In webcore, should we use the same impl on all platforms rather than use
cryptdll on windows and md5.cc elsewhere?
For chrome, I don't think we can have a dependency between
WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
doesn't work. How can we avoid replicating the code? I guess having
webcore's MD5 be platform specific could help us along those lines?
On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
I'm implementing new protocol of WebSocket
( http://www.whatwg.org/specs/web-socket-protocol/ ).
Since it now requires MD5 in handshake, I wonder how I could add MD5 in
WebCore. For now, there is no MD5 in WebCore. It is in
WebKitTools/DumpRenderTree to get message digest of image file.
I'm thinking to add new header file as WebCore/platform/MD5.h, which
provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
In Windows platform, it is implemented using Cryptdll.dll. Is it ok to
copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
or move?
In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
#define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this in
WebCore/platform/chromium, or add dependency to base from WebCore?
How about other ports? is it ok to link openssl or some other library?
(or use implementation used in chromium?)
I'm also wonder I need to put these functions in namespace WebCore.
If you put this code in WebCore, it should go in the WebCore namespace. I
think it would also be a good idea to turn the API into something more
WebCore-ish, something like:
namespace WebCore {
class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
or maybe this should take a Vectoruint8_t?
Vectoruint8_t, 16 checksum(); // what was MD5_Final
};
}
(The key point being to match the coding style guidelines for names, but
it also seems better to use a class here instead of a struct and functions
that take a pointer to it.)
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Join the URL hackathon (already in progress)!
On Tue, Apr 13, 2010 at 11:39 PM, David Levin le...@google.com wrote: On Tue, Apr 13, 2010 at 11:35 PM, Adam Barth aba...@webkit.org wrote: Ah, sorry, I meant to the point where the library was integrated with the various build systems, etc. Maybe that's already possible today. I haven't investigated it in detail. It probably also makes sense to talk about correctness between steps (1) and (2), once we have the tests and their results to compare across browsers. Adam On Tue, Apr 13, 2010 at 11:28 PM, Darin Fisher da...@chromium.org wrote: #4 is already basically done. See USE(GOOGLEURL). -Darin On Tue, Apr 13, 2010 at 11:17 PM, Adam Barth aba...@webkit.org wrote: I think Maciej took notes, but my recollection is as follows: 1) Convert as many of the unit tests to LayoutTests as possible. 2) Land GURL in svn.webkit.org as is. I think there was: 2.5 Change the name from GoogleURL to something else. (WebKitUrl?) In the long tradition of first-letter-then-URL, we had also jokingly suggested BURL in reference to Brett's parentage of the library. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 3:00 PM, James Robinson jam...@google.com wrote: On Tue, Nov 17, 2009 at 2:19 PM, Alexander Limi l...@mozilla.com wrote: Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal — it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. It seems like a browser will have to essentially stop rendering until it has finished downloading the entire .zip and examined it. I think that's not entirely true. In zip archives the manifest comes first and can be examined while the rest of the body is still downloading. This will most likely slow down the time taken to render parts of the page as they arrive. From the blog post: A given browser will probably block downloading any resources until the lists of files that are available in resource packages have been accounted for — or there may be a way to do opportunistic requests or similar, we leave this up to the browser vendor unless there’s a compelling reason to specify how this should work. This also means that a browser would have to stop tokenizing the HTML when it hits the next script src= tag, since it would be unable to know if the javascript was in the bundled zip or not. This seems to go against the idea that as much of the page be rendered as fast as possible. - James Thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
On Wed, Aug 26, 2009 at 10:47 AM, Ojan Vafaio...@chromium.org wrote: On Tue, Aug 25, 2009 at 11:45 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote: Hi everyone, Recently at Apple we've been considering our plans to implement new HTML elements from HTML5. I'd like to share our thoughts with the WebKit community and see if we are in sync before passing this on to the HTML Working Group. Does anyone have thoughts to add to the below: -- I realized I forgot to cover command and menu. - menu The list form of a menu seems straightforward enough, it is good to have a list type specifically for popup menus. The toolbar form does not seem fully baked. First, it seems weird to think of a toolbar as a kind of menu. Second, the rendering is too inflexible and underspecified for the real Web content authoring use cases for toolbars. And finally, an important point of toolbars in many applications is that they can embed custom controls in a flexible layout that also includes some standard buttons, but menu type=toolbar does not seem flexible enough to handle this. The context menu form does seem genuinely useful. But it also seems like a lot of complexity for the somewhat marginal case of overriding the context menu. It seems like about a dozen different elements are allowed, all with different processing requirements. This seems like overkill for the use case of a context menu. It doesn't even make much semantic sense for a context menu to contain a button. Overall, it doesn't seem like the cases of menu list, toolbar and context menu really share enough behavior or appropriate content model to make them use the same element. - command It's unclear if this element is worth having without the use cases for toolbars or menus, and it also has 0 implementations so far and seems like it might not be fully baked. While I don't disagree, I'm a little sad to see these not move forward in some form. JS libraries currently use a ridiculous amount of code to create simple flexible toolbars and menus that are keyboard accessible. Would be nice if someone with experience here (looking at you Hyatt) could chime in on whatwg with what a better design would look like so progress can be made. +1. Menus (menu strips, lists, what have you) and toolbars that share keyboard accelerators are a huge burden today, particularly in rich-text editing where focus constraints mean that in order to implement a11y for toolbars, you need to do lots of magical focus/selection saving in order to service the ad-hoc toolbar for things like keyboard navigation. Even if WebKit decides against the current HTML 5 spec for this stuff, having a toolbar and menu system that's sufficient for implementing the states needed for a rich text editor (think drop-down menus from a toolbar, toggle-buttons corresponding to style application, button-sets for multiple state toggles, e.g. alignment, etc.) would go a very long way to making a lot of UIs load faster and suck less (since, hopefully, a browser-provided UI would remove the ad-hoc nature of much of these UIs). Regards ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
Lots of stuff on the web is best-effort, particularly when system integration is the point. I'm not sure that saying the experience will be different changes what semantics should be available to authors in any way. Regards On Wed, Aug 26, 2009 at 3:25 PM, Peter Kastingpkast...@google.com wrote: On Wed, Aug 26, 2009 at 3:23 PM, Michelangelo De Simone micde...@gmail.com wrote: 2009/8/27 Peter Kasting pkast...@google.com: Consider that if the user uses a web mail app (e.g. Gmail) the UA will have no way of getting that data. In fact, the UA may not even know what mail client the user prefers to use, especially if he uses several different ones. Implementing such functionality in a port-specific way may address this My main point is that it's clearly not possible to offer an identical experience for all users in all UAs, so I can't see how a web author could be relying on such a thing, and thus I can't see how _not_ having it in the current WebKit implementation is somehow harming web authors. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] parallel layout research
After a discussion this morning about the potential for parallel CSS layout with Erik Aarvidson, he pointed out a group at Berkeley doing research in this area: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/ The bits that jumped out to me were: * the source is available [0] * they've implemented an abstract language for describing the CSS spec for parameterizing layout. It reminds me a lot of the work Badros did circa 2000 [1]. They suggest that this model does layout of the CSS 2.1 spec in time similar to the hand-tuned sequential engine in Gecko [2] * using Cilk++ to handle low-level paralleism, they've seen significant speedups beyond that for multi-core [2] It's exciting to me to see this kind of parallelism being extracted from CSS layout operations, which have shown up in profiling of Google apps as a serious bottleneck. I hesitate to ask about the WebKit community's interest in this since I assume that if patches show up and can prove their value, they'll be accepted, but I would like to know where people are either supportive or skeptical about such an approach. Regards [0]: http://code.google.com/p/pbrowser/source/browse/#svn/trunk [1]: http://www.badros.com/greg/papers/gjbadros-dissertation.pdf [2]: http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/retreatwinter2009/playout.pdf , slide #19 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Need help in understanding how webkit handles clicks event
The PDF handling stuff is related to a mimetype filter. The web server sends a particular mime type along with each document, and if it's not something that the browser knows how to deal with directly, it'll interrogate all of its plugins to see if they want to handle it. When plugins are registered they provide a list of types they'll handle. See: http://developer.apple.com/DOCUMENTATION/InternetWeb/Conceptual/WebKit_PluginProgTopic/Concepts/AboutPlugins.html And: http://trac.webkit.org/browser/trunk/WebCore/plugins Regards On Jan 28, 2009, at 5:25 PM, Meryl Silverburgh wrote: Hi, Can you please how webkit handles a mouse click from a user? For example, when user clicks an anchor, it will load the web page. But if the links points to a pdf document, it will load the document using pdf reader. Can you please tell me where in the code handles that? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
