Re: [webkit-dev] A Parallel Webkit?
I don't think that question is very pertinent to the list; it's more of a longterm thing. The es committee has little interest in it for the relevant future and I agree with this given the other needs, available slack time, and induced complexity. Luckily, a somewhat parallel browser does not need it, as I've hopefully made clear. On Jul 24, 2010, at 1:51 PM, Oliver Hunt wrote: Shared-state parallel scripting (and concurrent DOM) seem inevitable I don't know why you believe this -- there is no intention of having shared state threading in ES, nor is there any desire in the ES technical committee to add any for of concurrency primitives to the language. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Parallel Webkit?
>> JS compilation is also done lazily in webkit so we don't ever end up with >> multiple pieces of code to compile concurrently. Two of us have been focusing on speeding up bottlenecks like these to allow such synchronous interfaces. However, frameworks like TBB push towards having parallel tasks that are at least 10-100,000 cycles for a good reason; working at such small scales is for people who have the luxury of targeting farther ahead and I wouldn't suggest doing it without help. >> JS execution and DOM manipulation are single threaded, and that thread is >> the UI thread, this fact cannot be changed. > > We could potentially do HTML parsing on off the main thread. Firefox > 4 has support for this. It's unclear how much of a win this would be. What Adam is suggesting applies not only to HTML parsing and has seemed to me to be the pragmatic and likely path for the short-term (next 1-2 years). E.g, create buffers (hidden by synchronous interfaces where possible) -- for example, queueing up calls from the parser to the selector matcher -- and then handle those in bulk. In other places, like Adam's example of a call to the parser itself, it's harder, but still possible (while being clean!) by approaches like passing around forceable futures. In a sense, such an approach is already the norm in terms of the interface between JS and the DOM/layout (at least in Firefox): calls to layout etc. are buffered up to avoid repeated or unnecessary evaluation. While I don't think this approach will expose significant parallelism, I think it would match the available hardware -- if anyone is interested in doing such a limit study, we should talk! Shared-state parallel scripting (and concurrent DOM) seem inevitable, but these sorts of things are the minority in the performance profile. E.g., when loading a page, about half the JavaScript time is spent in non-execution tasks like parsing and code generating. They're still a concern in the sense of Amdahl's law and enabling new types of applications, but for getting the web to work satisfyingly on mobile, there seem to be bigger blockers. Until research catches up with the algorithms in browsers, exposing and exploiting coarse-level concurrency between components would be my recommendation (outside of some more obvious algorithms). Regards, - Leo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Parallel Webkit?
> I wasn't entirely sure what OP was after of if the reply below
> adequately addressed his interests.
WebKit2 seems to have little to do with taking advantage of parallel hardware
in browser algorithms like lexing, parsing, selectors, JS compilation, JS
execution, layout, DOM interactions, fonts, rendering, etc. There is some
benefit: Sam King measured bucketing coarse tasks at the process isolation
level gives maybe 10-20% better utilization of cores (a la Google Chrome or
predecessors like the OP browser, Charles Reis's work, Gazelle, ...) on a good
workload. WebKit2's goal of supporting concurrency might be aimed at
foundations for building parallelism into library code, such as further
cleaning up threading API or introducing lightweight task parallelism, but the
description doesn't talk about such things.
In contrast, we're interested in magnitudes of speedup. Parallelism --- memory
parallelism (hw + sw prefetching to avoid cache misses), SIMD instructions,
multiple cores, etc -- and even sequential stuff (smaller data representation,
balancing incrementalization/memoization, etc.). Parallelization is already
standard for traditional media libraries within browsers (e.g., GPUs & SSE for
painting and rendering); for maybe a third of our work, we're just expanding
the scope of what algorithms should be tuned kernels in the HPC sense.
>
> I guess I would just make a few comments about your considerations and our
> experience.
> A somewhat different strategy than what you are proposing is to offload some
> tasks
> to a more capable device such as a server- simply tokenizing html or compiling
> JS can be a big benefit in phone CPU and bandwidth (aka time and battery
> life).
Opera mini is one stab at this, and the OnLive platform shows some of the
potential here. However, this is for a limited deployment scenario and I'd
actually argue against it from a power, energy, and latency perspective for
handheld devices (... assuming you can get parallelization to work).
> You don't need to dig too deeply into the literature to find non monotonic
> graphs
> of execution time for some task vs number of cores ( more can make things
> slower).
>
I agree -- it's tricky stuff. Worth keeping in mind handhelds will be in the
multicore camp, not manycore, for awhile -- we're only now seeing dualcore
ones: we don't need arbitrary strong scaling. Furthermore, frameworks like TBB
are in a position to automate making the cutoff (which is actually non-obvious
as you might want more threads than cores due to memory effects,
hyperthreading, etc.). OTOH, for the processing style of browsers (sequences of
little tasks), getting speedups isn't easy.
> I have seen this with transcoding and profiling on phone simulators- parsing
> and compiling is a great way to use time and create lots of objects ( and
> these
> in java have lots of overhead and many phones only let you use java but in any
> case we know that temp objects are not free in any case and fragment memory).
I'm actually surprised a project like WebKit doesn't use, as far as I've been
able to tell, many memory pooling etc. optimizations. We've been mindful of
this stuff in our work -- it's fairly standard in the performance community.
> Another rate limiting step has been the round trip delay to housekeep a
> connection
> or do a DNS lookup. Here a proxy with persistent connections properly
> implemented
> is a much bigger issue than optimized rendering or well transcoded web pages
> AFAIK.
>
Both the network and the CPU need work. For laptops, the network is typically
the bottleneck, and only recently has that been shifting in the smart phone
space. Worth noting, even on a fast network and local pages, profilers will
show CPU bottlenecks.
> It may be worth considering making a standard compiled page type rather than
> worry about some of these other issues for example and cached compiled pages
> of course
> greatly reduce problems for everyone.
That's great and actually complementary -- parallel serialization of
machine-generated formats is preferable to formats like HTML5. A lot of
problems lie under the surface here, however: introducing a proxy somewhere
introduces latency, not getting benefits on dynamic component loading, etc. I
actually view making in-browser algorithms faster as the conservative choice.
>
> Its important to remember that most of these things involve tradeoffs and
> there are many resources to consider.
>
> So, maybe you can make various arguments (" but with wifi IO doesn't matter "
> or " CPU's are only getting faster" or "memory is only getting cheaper" ) and
> battle out platittudes to defend a given approach
We have never said any of these things. Mobile browsers take too much time
processing and the hardware is going parallel in multiple ways; we're just
putting 1+1 together.
> but I wouldn't just point to
> one, like parallelism, and assume that will fix everyt
Re: [webkit-dev] strategy for evaluating performance issues related to memory.
I've been doing some memory benchmarking recently (my current interest is layout but am also poking at nearby processes). Generally, data representation seems hard to usefully tweak in a non-invasive way as it's pretty good while being legible (e.g., bit packing), but access patterns (and random allocations) already seem questionable. This especially hurts netbooks/mobiles, but I'm seeing high missrates on my penryn MacBook Pro and it likely surfaces in the new macbook pros with their big L3 but much smaller L2 (though I can't get perf counters w/ Shark to work there). A high-impact and less-painful first step might be to target CSS selectors & default render style creation: -- buffer calls at the end of the parseToken()->insertNode()->attach()->createRender()->styleForRenderer()->styleForElement() pipeline -- once enough are in (or there is nothing else to do), perform matchRules/matchUARules calls: -- in tiles -- ... and in parallel -- ... and with software prefetching -- resume rest of createRender calls (similar tricks may apply, still not sure) A different form of this is now in the firefox mainline but there's room to do more using the above (and I suspect with a bit less implementation complexity). Anyways, this seems inappropriate for this list, but if anybody would be interested in continuing the discussion, you have my email. Also, if there are any resources describing memory layout / instantiation / etc. patterns and how/why recomputation/memoization are traded off, it would be a nice bootstrap: I've been essentially walking through http://webkit.org/blog/114/webcore-rendering-i-the-basics/, seeing how the code deviates or specializes, and profiling it with Shark & Instruments. Regards, - Leo On Jun 21, 2010, at 9:05 PM, Maciej Stachowiak wrote: > > On Jun 21, 2010, at 11:59 AM, Mike Marchywka wrote: > >> >> I was hardly worried about who does anything as much as what would make >> sense to do. I have interest, motivation, >> and multiple copies of the code but not a lot of time to waste of bad >> approaches. There was a prior discussion >> about coding conventions that should be applicable even to those >> contemplating a contribution of just browsing >> the code, I fail to see how this discussion is less relevant to current and >> possible future development concerns. >> >> If there was some piece of this or a related effort that could be aided by >> certain code features that >> would seem to be of interest to everyone and it isn't clear which people >> would have important thoughts >> to contribute ( or I would take it some other place). >> >> So I take it that now you just have factories and smart pointers and just >> make stuff and have it >> allocated wherever without further thought? I guess I could do some >> profiling my self and empirically >> find problems and just assume that no one has specific comments on suspects >> or things they have observed >> as possible problems. > > In my experience with performance work, and specifically in the context of > WebKit, I believe the following are useful approaches to reducing memory use: > > 1) Find and fix memory leaks. There are good tools for this, and memory leaks > contribute considerably to memory growth over a long browsing session. > Long-term memory growth is a bigger concern than one-time costs or per-page > memory that is properly returned to the system. > > 2) Run memory profiling tools under a significant and realistic workload, > such as Mozilla's "membuster" test. We have had great success with this and > in particular you can find some good recent memory use improvements from Sam > Weinig and Anders Carlsson, among others, if you look at the ChangeLog. > > 3) Track memory benchmarks regularly, and identify and fix regressions. > > 4) Run long automated page loads to verify that memory growth stabilizes > eventually, rather than continuing to grow without bound. > > 5) Investigate memory held by caches, and figure out ways to get the same > speed benefits with less overall memory use, for example by discarding > redundant data or better tuning the cache to hold the items most likely to be > reused. > > 6) Find reproducible cases of non-leak repeatable memory growth, and > determine where the extra memory is going. > > > If you are interested in improving WebKit's memory use, I encourage you to > consider one or more of the above approaches. > > 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] Specification of deviations or specializations from CSS standard?
I'm trying to write a (executable and analyzable) model of CSS2.1 (and some of 3). Much of the CSS standard is intentionally undefined to give leeway to browsers; however, that doesn't make it clear what browsers actually do (esp. when features interact). In hopes of tightening the standards etc., I'm trying to build models of what browsers actually do. Are there writeups of how WebKit deviates from the standard or what it picks as an interpretation for unspecified behavior in the standard? In particular, writeups closer to http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm than say the Quirksmode analyses. My process has been to reverse engineer through tests and go through WebKit source code but there is obviously a lot of noise and missed detail this way. I'm not sure what the ideal correspondence between spec and implementation is, but I suspect having an analyzable/queryable non-performance oriented specification of what the WebKit algorithms are doing would help. Thanks in advance, - Leo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] are there any known or suspected memory issues with webkit?
Mike Marchywka wrote: Date: Sun, 21 Feb 2010 15:55:24 +0100 From: supersti...@gmx.de To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] are there any known or suspected memory issues with webkit? On 2010-02-21 at 13:14:59 [+0100], Mike Marchywka wrote: The reason I ask is because I thought there were some concerns about leaks ( probably just stuff I saw skimming various google hits ) and I have seen firefox and iceweasel light up my disk on very simple things ( like typing stuff into forms). As I started looking through the code, one of the first things I saw was something that looked like a hash table of previously used pages- are there static "junk bins" of strong references and stuff like that that could create memory leaks as they accumulate stuff and never get cleaned or pruned? The other thing is that IMO ( opposing views welcome) memory access patterns are often an unappreciated issue on many architectures. The reason I reacted to the threading question as I did is that it seems, again in my opinion on superficial/ anecdotal analysis, that this approach often seems attractive but contains a number of issues, among them those related to memory or other resource allocations, that reduce the effectiveness even with an ideal multi-CPU system I did make this point before with reference to one speed-versus-threads graph from IEEE, http://lists.boost.org/boost-users/2008/11/42263.php Ceratinly " your mileage may vary" but resource allocation and contention is probably already a big deal and it may be a better place to look for optimization. Launching a thread is a general idea that can be used anywhere but digging into code may be more effort and more specialized to a given task however. Thoughts? I don't understand the multi-threading nay-saying. Just as an L2 cache is a technology to speed up memory access, multi-core architecture is a way to increase processing speed of the CPU. Last time I looked, a -j2 build of WebKit runs almost twice as fast as a single job build on my Core2Duo system. So the technology obviously works. Just because improving cache locality is a way to improve the execution speed of a piece of software, it doesn't mean one should try to prevent efforts to make software explore the increased processing performance of additional CPU cores. And designing the software to make proper use of multi-threading and scale well is definitely not easy, or the cheap way out. Not at all. Oh, it is not an attempt to discourage just not take something you happen to have a lot of and put each one into a new thread esp when my personal experiences seem to be related to memory depletion. The multi-core of course does benefit from multiple threads, but it helps if they are doing things that can play well with each other and not step over each other. The OP on the related topic indiciated he hadn't looked much at details, I'm just suggesting looking first. And, of course, once your disk light comes on for VM things do get quite slow. Indeed, maybe the threading model could remove some types of redundancy or thrashing but it won't do that if you just make a lot of copies of things that all become slower. In my experience parallelizing browser algorithms on various hardware configs, much of the benefit of exploiting new architectures is often just getting more cache. Even if you're not CPU bound, as new multicore hardware may work funny at the L1/L2 level, redesigning algorithms to work better at this level not only improves sequential performance but also essentially multiplies how much local cache you have. There don't seem to be any technical questions on this thread, so I'll stop proselytizing ;-) [Obviously why browsers go way beyond L2/L3 is a concern as is the prefetching technology, but those are somewhat orthogonal concerns to speeding up the CPU or arguably bandwidth bound bottlenecks like painting.] I guess from what I've seen personally on my machines the biggest problem with browsing is VM and there are probably other issues with caching well before you get there. I always expected browsing to be IO limited but clearly there are other limitations. Best regards, -Stephan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/201469228/direct/01/ ___ 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] parallel rendering in WebKit
We've been experimenting in our model with various modes of parallel 2D rendering (basic theme: GPU/SMP support rocks) but have a more wide open design space than WebKit's. For a not-too-painful approach, looks like Firefox is doing well, and that's even for D2D (not retained mode): check out the last few posts @ http://www.basschouten.com/ . Flash does a bunch as well, but that's less obviously transferred. Parallelism can be used at multiple levels within the renderer -- SIMD, threads, and/or GPU -- I was actually under the impression that WebKit on the iPhone already uses hardware acceleration for painting. For the latter case, the hardware was made for pushing pixels, so the performance question should be of how much of a speedup, not whether there is one. - Leo [[ A little further out, I've been going over the CSS spec, and found that a lot of the CSS transform stuff maps nicely into OpenGL as it doesn't impact layout; structured extensions like adding shaders to CSS surfaces doesn't sound too crazy at this point. This seems well-beyond the scope of this list, however. ]] Maciej Stachowiak wrote: On Feb 19, 2010, at 2:36 PM, Zoltan Herczeg wrote: Hi, as all of you probably know, smp based systems are getting widespread even in the embedded domain, and we hope we can speed up webkit on these systems. We did some profiling, and seemed the platform dependent rendering took 50% of the total runtime (at least on our test platforms). We are thinking about adding some parallel rendering support for WebKit, probably mostly platform dependent code, but the threading support could be reused by different ports. The plan is opening a rendering thread for each document object. This thread is dedicated to rendering, the resource management is still done by the main thread. In other words, functions like drawRect (in GraphicsContext.h) creates a small object, which contains the arguments of the called function, and passing this object to the thread. The thread would do the painting, and send back the object after it is processed. The main thread can free the memory space of the object later, and dereference the resources (we hope resources like fonts and images are not need to be duplicated). This is still a vague idea, and we are still investigating the possibilities. What is your opinion? Do you know about any major blockers we should know about? I would be worried about correctness - if painting is not complete by the time the paint method returns, then you could get flashes of intermediate states showing up onscreen. I suspect resources like fonts or images *will* need to be duplicated, either that or use thread-safe refcounting and copy-on-write. The internal state of images can be mutated by progress in loading the image, or by ongoing animation. I'm also curious how this will help overall rendering time. Embedded platforms would normally only be displaying one document at a time, so how will one thread per document help? 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
Re: [webkit-dev] GlobalScript API.
Perhaps worth reexamining lessons learned from (PLT?) Scheme's distinction between units and modules. Security, assuming & beyond the SOP, is worth considering. Module loading would be a giant boon for writing secure apps if the loader can specify the load environment (e.g., empty it, share the DOM / prototypes, or stipulate fresh / isolated ones). It's unclear what guarantees the loadee would want (e.g., frame-busting)... perhaps a discussion that could be more informed by the OCaps list that is active in the basic topic. - Leo Patrick Mueller wrote: Patrick Mueller wrote: Dmitry Titov wrote: Here is an actual API: --- Page-level API var globalScript = new webkitGlobalScript(name, url, loadHandler, errorHandler); I've mentioned before that this API turns out to be very similiar to the serverJS notion of a "module". https://wiki.mozilla.org/ServerJS/Modules/SecurableModules Differences are the name: require -> webkitGlobalScript; semantics about sharing across pages (not relevant to the serverJS work); the "exports" variable in the module which provides the reference to the globalScript return value the client sees; and that this is async vs. serverJS's sync model. Of most interest is the notion of the "exports" variable. Instead of exposing the "global" scope of the global script itself as the return value, you actually have to assign something to the exports variable from within the global script for it to be available in the caller. The nice thing about this is that it provides a nice way to create private references within your global script. Another interesting aspect of this is that it easily allows a global script author to use some library without that library infecting the pages' (clients of the global scope) scopes. For instance, one global script could pull in jQuery, another could pull in Prototype, or a different version of jQuery. Since only properties specfically added to "exports" are available to pages' scopes, there's no negative interaction between jQuery and Prototype. They live in the "globals" of each global script, which aren't visible to anyone else. Of course, monkey patching is still a problem - or is it? Does each page scope and global scope get it's own set of globals? eg, only one Object object? I was thinking originally that you'd want to share built in globals like Object and Array, but now I don't see how that would be possible. ___ 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
Likely the ones you considered "trivial". E.g., "nav". - Leo Maciej Stachowiak wrote: On Aug 26, 2009, at 12:04 AM, Leo Meyerovich wrote: These are unnecessary features wrt accessiblity tools and search engines; data mining techniques can easily handle them already. More strongly, for legacy and advanced UI reasons, the data mining should happen anyways, further questioning their merit. That's been my experience in this area (from the analysis side). Features that provide actual functionality would seem more pressing. Can you please clarify what features you have in mind? Most of the new elements I mentioned do provide substantive functionality. Regards, Maciej - Leo Maciej Stachowiak 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 and . - 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 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. - 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. - Sectioning elements: , , , , , , These seem useful - they give a way to represent the semantics of many Web pages nicely, and could work well with accessibility features for navigating around the page, as well as other clever ways of processing Web content. They are also trivial to implement (I already did ). We're fairly interested in doing the rest of these. - element This essentially gives the same behavior as but with appropriate semantics for logs of conversations. It seems useful and easy to implement. - Elements requiring changes to parsing: , These elements seem quite useful, but they will be unusable on the public Web until all browsers are updated to change how they parse and the new versions are widely adopted. Pretty much all current browsers do something idiosyncratic when parsing a element outside of a , which makes it impossible to make or degrade gracefully via script or style. We are hesitant to implement elements that authors would feel they are unable to use, or to lead authors astray, so we are hesitant to implement the new elements until either the parsing issue is widely fixed or HTML5 uses some element other than for the caption on these elements. We will consider fixing our parsing of outside soon, though, so that we're not the blocker. - New media elements: , We love these and have them implemented. We don't see any implementation issues in the current spec. - We like this and we have it implemented. We don't see any implementation issues in the current spec. - Newly standard legacy elements: , We had these for a long time before they were in HTML5. It seems like a good idea to cover them in the spec. - The basic idea for this element seems good, but the suggested UI for exposing it does not seem to entirely match the use cases, and may not be practical to deploy. Having tick marks in the scrollbar for every , and UI to cycle between them, seems too heavyweight for some of the suggested uses. We are interested in implementing the basics of soon, but probably not the requirements. - It seems useful for use cases like Microformats to have a clean, unambiguous way to represent a specific time. It seems odd that there are ways to get Date objects to represent the date, time and time zone separately, but no way to get a Date representing the combination of date/time/timezone. Wouldn't
Re: [webkit-dev] Implementation thoughts on HTML5 elements
These are unnecessary features wrt accessiblity tools and search engines; data mining techniques can easily handle them already. More strongly, for legacy and advanced UI reasons, the data mining should happen anyways, further questioning their merit. That's been my experience in this area (from the analysis side). Features that provide actual functionality would seem more pressing. - Leo Maciej Stachowiak 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 and . - 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 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. - 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. - Sectioning elements: , , , , , , These seem useful - they give a way to represent the semantics of many Web pages nicely, and could work well with accessibility features for navigating around the page, as well as other clever ways of processing Web content. They are also trivial to implement (I already did ). We're fairly interested in doing the rest of these. - element This essentially gives the same behavior as but with appropriate semantics for logs of conversations. It seems useful and easy to implement. - Elements requiring changes to parsing: , These elements seem quite useful, but they will be unusable on the public Web until all browsers are updated to change how they parse and the new versions are widely adopted. Pretty much all current browsers do something idiosyncratic when parsing a element outside of a , which makes it impossible to make or degrade gracefully via script or style. We are hesitant to implement elements that authors would feel they are unable to use, or to lead authors astray, so we are hesitant to implement the new elements until either the parsing issue is widely fixed or HTML5 uses some element other than for the caption on these elements. We will consider fixing our parsing of outside soon, though, so that we're not the blocker. - New media elements: , We love these and have them implemented. We don't see any implementation issues in the current spec. - We like this and we have it implemented. We don't see any implementation issues in the current spec. - Newly standard legacy elements: , We had these for a long time before they were in HTML5. It seems like a good idea to cover them in the spec. - The basic idea for this element seems good, but the suggested UI for exposing it does not seem to entirely match the use cases, and may not be practical to deploy. Having tick marks in the scrollbar for every , and UI to cycle between them, seems too heavyweight for some of the suggested uses. We are interested in implementing the basics of soon, but probably not the requirements. - It seems useful for use cases like Microformats to have a clean, unambiguous way to represent a specific time. It seems odd that there are ways to get Date objects to represent the date, time and time zone separately, but no way to get a Date representing the combination of date/time/timezone. Wouldn't the latter be a common use case, and doesn't the JavaScript Date object give sufficient APIs to unpack a Date into its components as needed? - New interactive controls: , These elements seem useful and a good idea. These controls are useful in native UI and often get hand-rolled by JavaScript libraries. We would like to expose a default native look, but with full author
