Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
On Sat, 13 Apr 2013, Filip Pizlo wrote: Actually, you can't. We very specifically designed workers (and even more importantly the API on the main thread) so that you cannot block on waiting for a message. You can also design lock APIs this way: Sure. Lots of APIs do it this way. Anyway, apologies for getting into semantics, but web workers don't eliminate deadlock - they just ensure that the main thread doesn't block if it happens. They do eliminate deadlock in the sense of two threads that cannot receive any messages because they are blocked on each other. They don't eliminate soft deadlock in the sense of an application that no longer progresses because it's waiting for a message that'll never come, but that's no worse than many kinds of logic errors where code stops progressing. Certainly you can have a logic error that causes the application to stop progressing, but you cannot have a deadlock that blocks the event loop of the main thread. You can already block the main thread by having a runaway script, so this could be viewed as an overly harsh goal when picking concurrency models. Actually you can't have runaway scripts on the main thread on the Web. Browsers will just abort the scripts after a brief timeout. Web APIs have different constraints than non-Web platforms that may help explain why the Web sometimes seems dumb from the perspective of professional programers or computer scientists. Specifically, the Web platform's design assumes the following: 1. Every Web author is potentially hostile and very clever, Threads do not make the Web author any more hostile, but I appreciate that this should be a serious goal. Right, this aspect is not especially relevant to Web workers. I included it just for completeness because these two reasons really do underlie most of the decisions that people coming from other platforms find weird. 2. Every Web author is potentially a bumbling fool. I don't disagree with this, but I'm not sure that I'm convinced that the application of this ethos implies that we cannot have locks It doesn't imply you can't have locks, it implies you can't have unprotected shared state. We _can_ have shared state that can only be accessed in a safe way. IndexDB, for instance, allows shared state accessed from workers, because you can only get to the state via a transaction-like deadlock-free API. Responsive UI is a good argument for having concurrency, and making it easier to use. So long as it doesn't sacrifice the two higher priorities of making the API safe against attackers, and being simple enough to be used by bumbling fools, sure. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
On Wed, 9 Jan 2013, Eric Seidel wrote: The core goal is to reduce latency -- to free up the main thread for JavaScript and UI interaction -- which as you correctly note, cannot be moved off of the main thread due to the single thread of execution model of the web. Parsing and (maybe to a lesser extent) compiling JS can be moved off the main thread, though, right? That's probably worth examining too, if it hasn't already been done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, 4 Jan 2013, Rik Cabanier wrote: I think this feature was rushed in the spec. The specing is usually the first step. You can't rush to spec. :-) In this particular case, though, it was the third or fourth step. The discussion has been open since June 2011. It's not like people didn't have time to comment. It's been shipping in a browser for over a year. Any solution we come up with to the issues that were raised regarding Path will almost certainly be done in a way that builds on context.fillRule, not in a way that removes context.fillRule. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Fri, 4 Jan 2013, Rik Cabanier wrote: How about EOClip? That is a construct that is far more used than eofill. Will that get its own parameter too? As specced it uses the same parameter. How about the interaction of stroking and this parameter (if you follow the spec's wording for stroking)? https://www.w3.org/Bugs/Public/show_bug.cgi?id=20569 How about ispointinpath? Will that follow the winding rule in the graphic state? That's what the spec says currently, yes. How about hit regions? How can you specify the winding there? https://www.w3.org/Bugs/Public/show_bug.cgi?id=20558 It's better to follow what almost every other graphics library has done: Add an EOFill and an EOClip. This is the wrong mailing list to argue this, but in general I don't see why it's better. Just asserting that it is, or that other platforms do it, is not compelling. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Wed, 2 Jan 2013, James Ascroft-Leigh wrote: There has been a proposal that a new property is added to the canvas 2D drawing context called fillRule with values nonzero (default) and evenodd. This is compatible with the mozFillRule already implemented in Mozilla Firefox and would be on track to become a web standard. If you are interested in knowing more I suggest you start with the bug I raised and take a look at the patch. https://bugs.webkit.org/show_bug.cgi?id=105508 This is now in the spec. http://whatwg.org/html/#dom-context-2d-fillrule -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fwd: Adding main element to WebCore
On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: I've not seen any place where @role=main was misused and I think the same would be the case for main. ARIA is used by very few authors, and those authors are, by and large, much more competent than average. ARIA therefore tends to be used to a much higher level of quality than most elements. At least I don't see why it would be misused any more than the other semantic elements that were introduced such as article, header and aside It would probably be used about as well, maybe a little less well than them because the idea of what is main varies from author to author (e.g. in the sites you analysed on the WHATWG list, as well as in many that others have mentioned before, id=main and id=content often include things like some navigation, some headers, some sidebars, some footers). so I don't see why they would make sense to be supported while main doesn't. The use case for e.g. header is mainly one of maintenance and styling: lots of people style their headers very specifically. In general it doesn't matter if one author marks his navigation as being part of his header and another marks his navigation using nav; the result is the same: they are clearly marked in the source, they can be styled, and they can be skipped. If one author doesn't use it, or even if most authors use it incorrectly, it doesn't mean that other authors can't use it. The use case for main is accessibility navigation. If authors use it incorrectly, the feature *doesn't work*. The element becomes pointless. Combined with the way that the concept of main varies from author to author, you dramatically increase the likelihood that the element won't satisfy its stated purpose. Also, since few authors ever test how their page works in ATs, they won't know that there's a problem. This is like the difference between a href= and img longdesc=. If many authors don't use a href= right, big deal; their pages don't work well, but it doesn't stop other authors from using it. If many authors use longdesc= incorrectly, however, it means users who try to use the feature quickly stop expecting it to work and they give up and even pages that use it correctly lose out. And, since few authors ever test how their page works in ATs, they don't know that there's a problem, and so the feature is _more_ likely to be broken than a href=. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fwd: Adding main element to WebCore
On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: On Wed, Nov 28, 2012 at 11:22 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: I've not seen any place where @role=main was misused and I think the same would be the case for main. ARIA is used by very few authors, and those authors are, by and large, much more competent than average. ARIA therefore tends to be used to a much higher level of quality than most elements. Agreed. I think that having this as an explicit element would make it easier for the Web Developer community at large to become aware of this problem and to provide this very valuable feature to users in need. Well first of all, what problem? How big of an issue is the accessibility problem here anyway? It's not at all clear to me that it's a big issue at all. Sites have been quite happily working with a skip past navigation link, and HTML has an explicit nav element that makes this more likely to happen even for sites that don't provide a link, and ATs have all kinds of page navigation tools for users that let them jump around looking for whatever it is they want to read (which isn't necessarily the main content; e.g. on youtube.com you probably want the search box, not the stream, in many cases). But secondly, how do you think main will do anything to make authors aware of anything? To authors who hear about the element, it's just going to be met with ah, a way to replace my id=main element ID with an element instead, just like header and nav. And thirdly, since when are awareness campaigns appropriate ways to do language design? We design to solve real problems, we try to make the platform intuitive. We don't design the language to teach people. That's the job of tutorials, advocacy, etc. At least I don't see why it would be misused any more than the other semantic elements that were introduced such as article, header and aside It would probably be used about as well, maybe a little less well than them because the idea of what is main varies from author to author (e.g. in the sites you analysed on the WHATWG list, as well as in many that others have mentioned before, id=main and id=content often include things like some navigation, some headers, some sidebars, some footers). Agreed. The analysis in my article came to the same conclusion. This is the opposite conclusion than you drew in your earlier e-mail, so I'm confused now. (You said I don't see why it would be misused any more than the other semantic elements.) Note that if it's misused even as much as the other semantic elements, that's enough to make it useless, unlike with those other elements. That's an important distinction. It's like labels on foods. If many stores misuse a label that says where the food is stored in their warehouse, well, those stores have trouble using their warehouse, but it doesn't really affect other stores, and the stores that use it correctly have no trouble. On the other hand, a label that says Only Organic Ingredients!, if use incorrectly by many stores, stops being useful at all, because even in stores that use it correctly, shoppers won't know if it's right, and so won't trust it. The label loses all its value. It actually doesn't even take a big fraction of stores to misuse the label for consumer trust in the label to be fatally undermined. I think we need to let go of the idea that main will replace id=main and id=content, because it's not the point of main. That's how authors will use it. That it's not the point of main is *exactly* the reason main is a bad design. The use case for main is accessibility navigation. If authors use it incorrectly, the feature *doesn't work*. The element becomes pointless. That's a good thing, right? No, it's a terrible thing. It essentially means we shouldn't add the element. Because then Web developers have a means to find out that they've made the wrong markup. Uh, no? It doesn't teach authors anything at all. Authors have basically no way to find out if they've used it correctly (given that they're not going to use -- or in most cases, even know about -- ATs). Combined with the way that the concept of main varies from author to author, you dramatically increase the likelihood that the element won't satisfy its stated purpose. If it is clearly specified, why would there be a difference in understanding what main means? You seem to be under the assumption that authors read the spec. The number of authors who read the spec is absolutely insignificant compared to the number of authors who will use the element. Also, since few authors ever test how their page works in ATs, they won't know that there's a problem. Right, that's why introducing a keyboard shortcut for main would be useful: it would enable every user to test their page. Very few authors are going to do that. (Barely anyone
Re: [webkit-dev] Feature Request: Dynamic Application Cache
On Sat, 17 Nov 2012, Brady Eidson wrote: On Nov 17, 2012, at 2:40 PM, Brendan Eich bren...@mozilla.org wrote: Brady Eidson wrote: On Nov 17, 2012, at 7:47 AM, sridharnsridhar.ndr...@gmail.com wrote: Any updates / plans for this feature ?? What feature? https://lists.webkit.org/pipermail/webkit-dev/2012-April/020455.html Mozilla Firefox supports dynamic adding of resources into the application cache for offline use with the function: window.applicationCache.mozAdd(URI String) https://developer.mozilla.org/en/nsIDOMOfflineResourceList This is great for persistent storage of assets via javascipt. Instead of predefining those assets in the manifest file one can use javascript to cache the needed assets. Is there something similar planed? Like window.applicationCache.webkitAdd(URI String) ? I knew about that, and we'll likely be interested in taking a look after HTML or WebApps takes it up and gets it into a standard, which I know there's interest in but it hasn't happened yet… Current status is: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17974 ...which is looking for feedback from potential authors and implementors. In particular, the current idea doesn't involve an add/remove API, but something more involved, and it would be good to get feedback on whether that's overkill for some or all use cases. (Knowing exactly what the use cases are would help.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] new APIs for strokes with dash in Canvas
On Fri, 23 Sep 2011, Young Han Lee wrote: I spent some time trying to find it, but couldn't. This bugzilla seems to be the only place we can get information at the moment. https://bugzilla.mozilla.org/show_bug.cgi?id=662038 On Fri, 23 Sep 2011, Dirk Schulze wrote: The WebCore patch of Young is basically using the specified behavior of stroke-dasharray and stroke-dashoffset in the SVG specification [1]. But we wouldn't support units or percentages, just floating point numbers. I've added something along these lines to the HTML specification. It's not quite the same API; see my e-mail to WHATWG (which I'll be sending in the next few days) for more discussion on the design decisions behind it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Quo vadis style scoped?
On Mon, 14 Nov 2011, Roland Steiner wrote: A while ago there we had a discussion which direction style scoped should take, whether selectors should be scoped to the scoping element, or be global. At that time it was felt that 'scoped' should be prefixed until the discussion is resolved. Now, I have had implementation patches ready for a while already, and with Hixie agreeing that the spec should be changed in this regard ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/07.html), I wondered if it's ok for me to re-upload them in an un-prefixed 'scoped' version, or whether folks would still prefer a '-webkit-' prefix after all. I've updaed the spec now. http://www.whatwg.org/specs/web-apps/current-work/#attr-style-scoped -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature: Implement command API in webkit
On Thu, 24 Nov 2011, Ryosuke Niwa wrote: For example, the current design doesn't allow a single command be associated with multiple UI components such as toolbar, pane, and context menu because a command is defined at wherever UI component that triggers the command. However, in practice, many web apps share the same command state across multiple UI widgets such as toolbars and context menu. Take, bold command as an example. bold command can be disabled or checked (i.e. the selected text is in bold) and this state needs to shared across many UI elements. Correct, though that is only a temporary limitation. I avoided adding this because I figured adding too much at once would cause implementors to avoid it. I'm happy to add it already if that is what it takes to get it implemented. :-) The idea is to add a command= attribute which takes an ID and would then make the element defer to the element with that ID, so that you only need define the command once and then refer to it from the various places in the UI where you want to refer to it. I also don't think UA should auto-generate toolbars as most of web apps want to have a fine-grain control over the look and feel of their toolbars. Agreed with the fine-grained control issue. I figured we would do that using pseudo-elements and component decorators, but I haven't specced anything out yet because those aren't ready yet. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Quo vadis style scoped?
On Tue, 15 Nov 2011, Ryosuke Niwa wrote: On Sun, Nov 13, 2011 at 5:58 PM, Roland Steiner rolandstei...@google.comwrote: A while ago there we had a discussion which direction style scoped should take, whether selectors should be scoped to the scoping element, or be global. At that time it was felt that 'scoped' should be prefixed until the discussion is resolved. Now, I have had implementation patches ready for a while already, and with Hixie agreeing that the spec should be changed in this regard ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/07.html), I wondered if it's ok for me to re-upload them in an un-prefixed 'scoped' version, or whether folks would still prefer a '-webkit-' prefix after all. Has the spec changed and expected to be stable (i.e. no behavioral change in any foreseeable future)? I'm not aware of any new information coming to light since the e-mail in September. I haven't updated the spec yet, but forsee no reason why I would not do so in due course. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
On Thu, 22 Sep 2011, Charles Pritchard wrote: Regardless of an ENABLE flag, be certain to use the webkit prefix. document.getItems(typeNames) turns into document.webkitGetItems(typeNames) Note that it's easy to implement this in pure javascript as a prototype. Assuming the patch implements the spec correctly, no need to use a prefix -- I'll track the implementations and ensure no conflicts. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
On Fri, 23 Sep 2011, Dean Jackson wrote: However, isn't prefixing designed to avoid incompatibilities in spec changes, not incompatibilities between implementations? Ensuring no conflicts in implementations doesn't matter too much if the spec changes. It's designed to ensure that authors can reliably use a name and expect to get the same result in any UA that supports that name. I'm not going to change the spec in a way that conflicts with that -- if the spec has to change, it'll change either in a compatible way (e.g. to match what was actually implemented), or in a way that doesn't conflict (e.g. by changing the name in the spec). Note I'm not talking about Microdata in particular. I don't even know what that spec is :) I'm just talking about the general approach. If the world can guarantee that this spec will never change, then I guess your technique works. FWIW, there is an in-between approach, which is the one used by WebGL. It defines a prefix that all implementations share. canvas.getContext(experimental-webgl); That'll just result in that name becoming the standard. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] starting implementation of postMessage tranferables
On Thu, 22 Sep 2011, David Levin wrote: *Summary*: Implementing postMessage with transferable support as webkitPostMessage. *Details*: *Spec*: http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages This describes window.postMessage and the same is true for Message Ports and Worker Context. It doesn't mention Array Buffers but that will be mentioned soon and is in the spec that talks about Array Buffers. Tracking bug: https://bugs.webkit.org/show_bug.cgi?id=64629 *Plan*: 1. Add webkitPostMessage to all of these places to isolate us from possible spec changes. It will have the same functionality as postMessage. 2. Add the ability to transfer Message Ports. 3. Add the ability to transfer Array Buffers. After step 2, webkitPostMessage can be renamed to postMessage quite safely. The spec isn't going to change in a way that breaks you. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] starting implementation of postMessage tranferables
On Thu, 22 Sep 2011, Oliver Hunt wrote: There is not any substantive harm in prefixing, whereas there can be real problems down the road if we don't prefix. The harm in prefixing is that people can't use the feature for years after it's implemented; q.v. CSS. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] new APIs for strokes with dash in Canvas
On Thu, 22 Sep 2011, Darin Fisher wrote: Do you know if anyone is working to add this to the spec for Canvas? It seems like it may not take much to get it added, given that FF already has an implementation. Dashed lines are on my list but were not a high priority. If there are implementations then I'm happy to add it -- the only reason I hadn't added it is because the moment I add anything to canvas, everyone implements it, dropping whatever else they were working on, and so if I keep adding canvas features nothing else gets done... :-) Is there any documentation on how this patch and Gecko's implementation work and what they support? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing HTML5 time element
On Thu, 15 Sep 2011, Vineet Chaudhary wrote: I am intending to implement the HTML5 time tag. Could you elaborate on what your use case is? The reason I ask is that we are thinking of dropping time from the spec. If there's a good reason to keep it, that would be good to know. With Reference to Specification on : http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element Please note that the above is an obsolete out-of-date link. I strongly encourage you to use this spec: http://www.whatwg.org/specs/web-apps/current-work/complete/text-level-semantics.html#the-time-element ...or, if you must use the W3C copy, this one: http://dev.w3.org/html5/spec/text-level-semantics.html#the-time-element You should always exercise great care when looking at the TR/ page as drafts on the TR/ page are almost always out of date. (There's a big warning to that effect on the page you cited above -- was the warning not clear enough? That would be good to know.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing HTML5 menu element
On Tue, 6 Sep 2011, Antaryami Pandia wrote:
We are intending to implement the HTML5 menu tag.
The related specs can be found at:-
- http://www.whatwg.org/specs/web-apps/current-work/#the-menu-element
-
http://dev.w3.org/html5/spec/interactive-elements.html#the-menu-element .
A bug for the purpose is already logged at webkit bugzilla (
https://bugs.webkit.org/show_bug.cgi?id=58454).
Currently webkit does have a support for menu tag (not html5) with below
interface:-
interface HTMLMenuElement : HTMLElement {
attribute [Reflect] boolean compact;
};
Where as the proposed new implementation will have the interface as:-
interface HTMLMenuElement : HTMLElement {
attribute DOMString type;
attribute DOMString label;
};
So my question is should we also support the earlier menu tag
implementation?
The HTML spec still requires compact to be supported, look for partial
interface HTMLMenuElement around here:
http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-link-charset
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement – Video conferencing and peer-to-peer communication
On Fri, 13 May 2011, Eric Seidel wrote: On the surface peer to peer video conferencing does not seem like something appropriate to add to WebCore/WebKit. Just like an API for reading my email is out of scope for the project. (But certainly lots of people build such things on top of WebKit.) :) What people are talking about as video conferencing and peer-to-peer communication here really are the building blocks for letting people build such things on top of the Web platform. The relevant part of the HTML spec is basically just these features: - A way to get input from the system camera(s) and microphone(s). - A way for two peers to connect and exchange data and audio/video streams directly, reusing the widely used ICE, STUN, TURN, and SDP technologies, assuming they have an existing indirect channel. - A way to record or display these streams. Actually deploying a video conferencing system would need far more than this. For example, you need identity and presence, which are not part of the Web platform but have to be built on top of it. You also need to actually implement the existing indirect channel mentioned above (e.g. using XHR or WebSockets), and you need to provide the STUN and TURN servers in the cloud. The components that are provided by this part of the HTML spec have other purposes beyond video conferencing; for example you can use the access to local camera and microphones for augmented reality tools, you can use the peer-to-peer component for exchanging real-time game state data in a video game, and you can use the recording component for recording video blogs. The parallel to e-mail apps is apt: it is much like how the platform provides XHR, input controls, and local storage, all necessary components for an e-mail app, but does not provide an e-mail app component; and the components it does provide can be similarly reused in other contexts. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit
On Fri, 4 Mar 2011, Dimitri Glazkov wrote: Today, we happily use -webkit-appearance to apply platform-specific appearance to the controls. The trouble is, the value of -webkit-appearance is going to be different depending on the value of logical width. Why not have a value of 'appearance' that automatically uses the right orientation, instead of having orientation-specific values? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding Blob support to event.dataTransfer
On Mon, 18 Oct 2010, Daniel Cheng wrote: I'm planning on adding experimental blob support to DataTransfer. I emailed WHATWG awhile back, and no one replied, so I picked what looked like the most appropriate option and I've implemented it. Does anyone have objections or comments on landing https://bugs.webkit.org/show_bug.cgi?id=47482 (once I fix the Windows build problem) Make sure that you vendor-prefix anything that isn't in the spec, so it won't conflict with the spec when it's added there. As it happens, I'm working on drag and drop hopefully this week. I'll probably be adding the new way to expose the types that was discussed a few months ago. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Leading new-line in dataTransfer.setData
On Tue, 23 Mar 2010, Roland Steiner wrote: Hm, but the first line could also be a comment (starting with '#') which Mozilla also skips. IOW, I read the spec as return the first line that is a (valid) URL. But of course I could be convinced otherwise... The empty string is a valid URL. However, I agree that RFC2483 doesn't define the parsing very well. I regret trying to be clever by reusing that type instead of just punting on the whole MIME type thing and allowing URL to be a single URL as in IE. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Video feature request
On Thu, 14 Jan 2010, Adam Barth wrote: I'm not sure if we've implemented it yet, but we could let video providers opt out of these protections using CORS. That will be specified in HTML5 around the same time that the cross-site subtitle stuff is added (since that has the same problem). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] localStorage quota limit
On Wed, 2 Dec 2009, Michael Nordman wrote: Arguably, seems like a bug that invalid string values are let thru the door to start with? Yeah, I should make the spec through SYNTAX_ERR if there are any unpaired surrogates, the same way WebSocket does. I'll file a bug. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] localStorage quota limit
On Wed, 2 Dec 2009, Maciej Stachowiak wrote: On Dec 2, 2009, at 8:14 PM, Darin Fisher wrote: What about Maciej's comment. JS strings are often use to store binary values. Obviously, if people stick to octets, then it should be fine, but perhaps some folks leverage all 16 bits? I think some people do use JavaScript strings this way, though not necessarily with LocalStorage. This kind of use will probably become obsolete when we add a proper way to store binary data from the platform. Most Web-related APIs are fully accepting of JavaScript strings that are not proper UTF-16. I don't see a strong reason to make LocalStorage an exception. I recommend raising these points on: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8425 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On Tue, 1 Dec 2009, Michael Davidson wrote: On Mon, Nov 30, 2009 at 8:08 PM, Maciej Stachowiak m...@apple.com wrote: Would it be fair to say the goal for SharedScript is just to share code and data (to reduce memory use of multiple instances of GMail), and not network connections, timers, or other APIs based on async callbacks (assuming those either remain per-Window or are in the SharedWorker)? If so, then it would pretty much completely be handled by sharing of some arbitrary JavaScript object, possibly arranged by SharedWorker. No, we definitely want to share network connections. We'd like users to be able to have an arbitrary number of Gmail windows open without running into the browser connection limit. SharedScript doesn't give you that. Only a singleton mechanism can give you that. Always-shared vs. opportunistically-sometimes-shared seems like a big difference, more than just implementation details. It has a direct impact on how to correctly author content using this mechanism. I'm not sure that this is true. Users can always run multiple browsers with different profiles, or run browsers on different machines. Using different machines, different browsers, or different profiles has some pretty major differences with using different tabs (processes) in Chrome: only in the latter would one common database, storage, and cookie infrastructure be shared, only in the latter would the HTTP per-origin connection limit be shared, only in the latter would application caches and HTTP caches be shared, etc. In a perfect world, we'd like to be able to hint that a toplevel navigation belongs to a set of pages that should share a process. That way if the user navigates to, say, http://mail.google.com, we can tell the browser that we'd like it to be rendered in an existing process if one exists. That would lead to maximal sharing. Since iframes have to share a process even across origins, and since window.open() from an iframe has to share the process of the opener, it is trivial to engineer a situation where it's not possible to share the process. This kind of situation would commonly arise with pages like iGoogle that embed a GMail gadget. (I ask because windows with a pre-existing relationship like parent/opener could already share code and data if they chose to, without any new browser features. Just pass the functions or objects of your choice to the newly opened window. As mentioned elsewhere on this thread, this isn't a great solution. XHRs and timers, specifically, need to find a new parent window when one window closes. I do have this working for Gmail tearoffs right now, but all windows have to close when the main window closes. It seems that you could just create an iframe instead of the SharedScript, and pass it around onunload. A third improvement: When we adopt the HTML5 notification API for showing users new mail or incoming chat notifications we will only show one notification regardless of the number of Gmail tabs that are open. You can't do that with SharedScript, since it's not guaranteed to be unique across the browser. However, SharedScript misleads people into thinking that they can do that, which is one reason that I am skeptical that it is a good idea. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On Tue, 1 Dec 2009, Michael Davidson wrote: On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 1 Dec 2009, Michael Davidson wrote: No, we definitely want to share network connections. We'd like users to be able to have an arbitrary number of Gmail windows open without running into the browser connection limit. SharedScript doesn't give you that. Only a singleton mechanism can give you that. Assuming that the same-process hinting works, it will give us that. The process hinting is not a guarantee. It is trivial to come up with situations where different documents from the same origin are required to end up in different processes. Furthermore, as a user, I would personally much rather every GMail instance I open end up in a different process, for the same reason that I'd like GMail and Google Calendar in different instances, and Google Calendar and Google Search in different processes, and Search and pages I get to from Search in different processes. At the very least, it will vastly improve the situation we have today. Either you definitely want to share network connections, in which case it doesn't give you what you want, or you don't need to share network connections, in which case it seems no better than an iframe. The iGoogle gadget that you mention later would not use SharedScript, FWIW. Sure, but if it opens a true GMail window, that GMail window would have to end up in the same process as the parent (so that the opener can be accessed), which means it wouldn't be the same process as other GMail tabs. It doesn't have to be an iGoogle gadget; any page that window.open()s GMail would be in this situation as far as I can tell. I agree that anything that lives in an iframe is going to cause problems for SharedScript, but Gmail (like many webapps where having the URL exposed to the user is very important) doesn't allow itself to be in an iframe. It prevents it using script, which is too late since the process selection happens long before the script runs. It seems that you could just create an iframe instead of the SharedScript, and pass it around onunload. Can an iframe live independently of its creating document? Per spec, yes, so long as it is owned by a living document it'll keep existing. It should even work in browsers so long as you actually keep the iframe grafted to an existing Window's Document -- hence the pass it around onunload to keep it alive. The goal is not to mislead people into thinking that SharedScript is bulletproof sharing, which is why the spec says that sharing might fail. Yes, but people will think that's what it does, regardless of what it does, because in most testing that's what it will do. It's like the localStorage debacle -- we have to offer consistency guarantees because people will assume them regardless of what the spec says. Anyway, I'm not trying to discourage experimentation here; I just wanted to make it clear that SharedScript doesn't solve the shared networking problem, because it can never be guarenteed to be a singleton -- indeed, from the user's perspective, it would be undesireable for it to be possible to make the browser always put all tabs from one origin into the same process even if it was possible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On Mon, 30 Nov 2009, Dmitry Titov wrote: That also pretty much means if we won't do SharedScript, we'll need to explore other opportunities toward efficient sharing of code and data which does not make people to write a multithreaded UI as SharedWorker solution would do. We have practically zero positive response to SharedWorkers being used this way. Granted, this is just one company but the limited unscientific poll kind of shows the direction... The pushback on SharedWorkers at Google is because Google teams don't want to rewrite their apps to work with workers -- SharedScript lets them handle some of the cases SharedWorkers would get them, without having to rewrite as much code. However, we should not be basing the platform's progress on transition cost avoidance of one company. Google can afford to rewrite GMail if it comes down to that. It is not in the Web's long term interests for us to design features that are optimised for the transition phase at the cost of the long-term health of the Web. What we should be looking at is what API do teams prefer to work with when starting from scratch, because on the long term that will be the far more common case than transitioning from a legacy codebase. I don't think that our (Google's) response is representative here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Sun, 15 Nov 2009, Adam Barth wrote: On Fri, Nov 13, 2009 at 6:01 PM, Adam Barth aba...@webkit.org wrote: Does the IETF WG have a timeline? My understanding is that IETF WG take at least a year to do anything. Here's the timeline for the HyBi WG: http://trac.tools.ietf.org/bof/trac/wiki/HyBi Goals and Milestones: - Mar-2010: WGLC on the Design Space characterization (Informational) May-2010: WGLC on Requirements document on Short term solution Jul-2010: WGLC on Requirements document on Long term solution Nov-2010: Requirements to IESG Mar-2011: WGLC on Short term solution improvements Nov-2011: WGLC on Long term solution protocol I read this as one year for requirements and another year for a protocol assuming the WG stays on schedule. Then I guess WebSockets will be a WHATWG spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, 13 Nov 2009, Jeremy Orlow wrote: I don't buy that at all. There's plenty of features with the webkit- prefix and I think it's pretty clear to developers what that means. IMHO it makes no difference to authors if they have to use webkit-ws: or ws: -- either way, they might come to depend on it, and either way if other browsers want to be compatible with code written for us, they have to use the same value. The features where we have the webkit- prefix are CSS properties and values. There, there's no problem with each browser vendor doing their own extension, since you can list multiple properties. This doesn't apply to URLs like here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, 13 Nov 2009, Adam Barth wrote: Does the IETF WG have a timeline? The IETF WG doesn't event exist yet. My understanding is that IETF WG take at least a year to do anything. They take as long as we (the community) let them take. As far as I'm concerned, the WebSocket feature is very mature. The IETF is late to this party; WebSocket has been under development since 2005. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, 13 Nov 2009, Jeremy Orlow wrote: I'm not very familiar with the IETF's efforts, but my understanding is that they were creating a competing protocol. Are they in fact creating something that they want to submit as a replacement to WebSockets? If so, why is WebSockets moving to last call? The IETF is just a bunch of open mailing lists, there's no they that doesn't include us. The WebSocket protocol is pretty stable at this point. I doubt it will change much. The recent IETF meeting indicated that most people agree that we want something like WebSockets, and it has already received several years of public review. I wouldn't worry about changing the schemes or anything like that; if the protocol _does_ change in non-backwards-compatible ways, then we'll just change the protocol to not step on this code. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Staging WebSocket protocol deployment
On Fri, 13 Nov 2009, Jeremy Orlow wrote: By using webkit-ws/webkit-wss we're giving ourselves some wiggle-room until we're sure we're happy with the protocol. Not really. It just means that we might end up stuck with webkit-ws: instead of ws:. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API
On Thu, 21 May 2009, John Gregg wrote: On the security question, a substantial amount of thought has gone into how to prevent unwanted popups (and in general how to control access to HTML5 application features). We think user opt-in on an origin-basis is the best policy and it's what we plan to do in Chromium; the WebKit interfaces are structured so that the policy is up to the user agent via a NotificationProvider interface. Could you elaborate on what you mean by user opt-in? A prompt or installation step seems like a poor user experience given that any site could start asking for this, and we don't want users to click yes to make the message go away (consider a porn site that just does while notifications are not allowed, try to notify). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ASYNC attribute for script?
On Tue, 28 Apr 2009, Peter Kasting wrote: It's great that WebKit has parallel script **downloading**. But... this still blocks page rendering of all elements below the script and still blocks all execution of subsequent JavaScript. I'd like an ASYNC attribute to the SCRIPT tag that implied WebKit should go ahead and render subsequent page elements and go ahead executing subsequent JavaScript. This would make it easy for developers deploying standalone features (carousel, widgets, etc.) to get better page behavior. This is esp. important for ads. It's unlikely that we can make much progress amongst ad services to adopt performance improvements that require even a small amount of extra JS coding. It is more likely that we could make inroads in getting them to add a simple async attribute. The key to accomplish this is that the async-loaded scripts must be able to preserve document.write. This opens up a lot of scenarios - I certainly haven't thought them all through. But Opera has this capability, and in my testing it works (see http://www.stevesouders.com/blog/2008/09/11/delayed-script-execution-in-opera/ ). HTML5 has script async but it doesn't preserve document.write() behaviour. I don't understand how that is possible given that a document.write() could change the meaning of subsequent tokens, but that processing subsequent tokens can have side-effects. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTMLSelectElement and namedItem()
On Thu, 9 Apr 2009, David Moore wrote: I've looked at FF, IE and Opera. FF doesn't support named item access from an HTMLSelectElement. It does support it from HTMLOptionsCollection, and returns 1 element even if there are multiple options with the same name. IE doesn't support named item access from either HTMLSelectElement or HTMLOptionsCollection. Opera supports named item access from both HTMLSelectElements and HTMLOptionsCollections. In both cases it returns a single element if there are duplicate names. Note that HTML5 defines the expected behaviour here in some detail. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] audio/source and the type attribute
On Tue, 31 Mar 2009, Harold, John-Paul wrote: in my HTML5 audio markup, I have the following audio source src=/media/audio/ogg/9001_1/9807.ogg type=audio/ogg; codecs=vorbis/ source src=/media/audio/m4a/9001_1/9807.m4a/ /audio but I'm unsure what the equivalent type attribute for an m4a file should be. Can someone advise? Does this help?: http://www.whatwg.org/specs/web-apps/current-work/#attr-source-type -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Workers and Database
On Thu, 26 Mar 2009, Husam Senussi wrote: Does workers have access to thing like localstorage and database Per spec, localstorage:no, databases:yes. (Not sure about the implementation, though.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
