Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores
On 4/16/2012 12:55 PM, Maciej Stachowiak wrote: On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote: Could this be an opportunity to design an asynchronous API for fetching the pixel buffer? It seems like many implementations are GPU backed now, and fetching the pixel buffer is an expensive (blocking) operation. Had you considered making such a change? Adding async support was suggested on the whatwg thread about this. I think async support is useful, but should not be tied to high DPI support. In particular, we shouldn't, in my opinion, require authors to rewrite their existing sync code to an async model just to properly support higher resolutions. TL;DR: Canvas authors will largely be using web workers (thus async) regardless of this proposal. Oliver Hunt is suggests that an async fetch would be of significant additional complexity for content authors; Maciej, you're also saying that authors [would have] to rewrite their existing sync code. ImageData operations are very much a niche, a very small niche, inside of yet another very small niche. Canvas is an expensive low-level API to work with. Cheaper than SVG support, but still expensive. Authors working with Canvas have taken on complexity already. All authors working with Canvas ImageData are looking at it from an async perspective because they'd like to offload the work to another thread. We've had to wait awhile for it but webkitPostMessage and Uint8ClampedArray are coming along. Those are already an async pairing. Further, we can do little optimizations to treat the typed array as a Float32. Once we're knee-deep in ImageData, everything is on the table. The code complexity of async vs sync on ImageData is minor. Authors are looking at using async anyway so that they have the option to move the heavy lifting off-thread so as not to block the UI. I just have to disagree with Oliver and Maciej here on the complexity and rewrite portions. 1) It's already being done as common practice so as not to block the UI, 2) It's not complex nor a rewrite, it's just a simple layer of code, and 3) we're already looking at far more complex things in Canvas such as simply supporting requestAnimationFrame. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores
On 4/16/2012 3:34 PM, Maciej Stachowiak wrote: On Apr 16, 2012, at 1:44 PM, Darin Fisher wrote: On Mon, Apr 16, 2012 at 1:42 PM, Oliver Hunt oli...@apple.com mailto:oli...@apple.com wrote: On Apr 16, 2012, at 1:00 PM, Darin Fisher da...@chromium.org mailto:da...@chromium.org wrote: On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com wrote: On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote: Could this be an opportunity to design an asynchronous API for fetching the pixel buffer? It seems like many implementations are GPU backed now, and fetching the pixel buffer is an expensive (blocking) operation. Had you considered making such a change? Adding async support was suggested on the whatwg thread about this. I think async support is useful, but should not be tied to high DPI support. In particular, we shouldn't, in my opinion, require authors to rewrite their existing sync code to an async model just to properly support higher resolutions. In addition, the whatwg thread revealed that there are many hidden complexities in the design of get/putImageData, in particular designing how they work in the face of sychronous drawing operations to the same canvas. The HiDPI problem is much more straightforward and does not need to be gated on resolving the async design issues. I think you are giving up a good opportunity. The barriers to an async API are more readily overcome when there are extra benefits to developers. HiDPI could be a great way to attract developers to a better API. I've addressed those other concerns on the WhatWG thread. No, gating HiDPI on rewriting your code into a more complex, and generally slower model seems like a great way to encourage developers to ignore high dpi. --Oliver I'm not sure why developers would choose to ignore HiDPI. It seems like it helps their apps/pages look better! You really feel like you need to kowtow to developers to get them to adopt HiDPI? Different developers will have different priorities. HD image data and async readback both have potential benefits in image quality and nonblocking responsiveness respectively. Here is an example of an application using getImageData which would clearly benefit from HD, but it's not obvious that async would be useful: http://mudcu.be/sketchpad/ Developers are rarely targeting existing HiDPI with iOS via window.devicePixelRatio. They have learned though, word spreads around. That's just an issue of project and community maturity. Canvas on iOS requires a lot of advanced techniques for good operation. I was heavily involved in Sketchpad as well as a Canvas-based image editor, Darkroom. http://www.youtube.com/watch?v=4MrEtsplano#t=2m In a subsequent version we did enable arbitrary blend modes in drawing. Michael put together several dozen modes. Blocking was and is a big issue. Especially with high resolution devices like Wacom pen-tablets. If there's any blocking due to heavy computations, we end up losing a lot of precision of movement and pen pressure. Some drawing applications have a quick render, which is then followed up by a high quality composite (running on pixels). The actual getImageData call is not a big deal, but regardless, we already face the need of an async loop, of possibly dropping frames and of keeping various state data around. In the sketchpad project as you are looking at it, it is not using getImageData. It's using a lot of drawImage calls. Here is another where HD helps but benefits of async are unclear, since it does a pixel read-write-modify cycle: http://nerget.com/pressure/pressure.html Tying HD to async may hurt the adoption of both by requiring developers to take two different code change hits when they only care about one. In particular, the async change is likely to be more invasive to code structure. If developers are discouraged, they may end up using neither. Thus, in my opinion, these two enhancements to ImageData should stand and fall on their own merits. That project has one getImageData call, it's kept in memory and it's initialized from a blank canvas. It would only need an additional line of code (and argument) to support async getHD. It's not a separate code path. I am trying to say this: an async getImageDataHD will not hurt developers nor discourage them. The fluid dynamics demo would benefit from using requestAnimationFrame instead of setInterval, and using webkitPostMessage to do the heavy lifting in the displayDensity method. It could benefit from multiple-cores (in theory) by using several buffers. I think there are excellent points to discuss; points that have been discussed in this thread. There were calls for benchmarking, weighing up the technical overhead. I want
Re: [webkit-dev] Upstreaming Support for W3C Sensor API
Maciej, I've been trying to find a home for Ink data for some time. The one inroad I've made was to make the case in the touch events 2 proposal: https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html Is that what I should move forward with, with Ink? I've been following the Sensor API because the structure works for the raw data of a pen, monitoring pen pressure, tilt and rotation, resolution and other items, to the standard serialization format now recommended by the W3C: Raw sensor data: http://www.wacomeng.com/web/WebPluginReleaseNotes.htm#_Toc293867182 Sensor API: http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html Serialization format: http://www.w3.org/TR/InkML/ The whole of the Sensor API can be serialized without losing information or breaking the file; it allows arbitrary units in addition to the base: http://www.w3.org/TR/InkML/#units The Gamepad API itself has shown resolution issues: http://code.google.com/p/chromium/issues/detail?id=79050 Do we want to move forward with device-specific APIs, such as Gamepad and Touch Events 2, or do we want to have a more general mechanism? The Sensor API is a more low level API than the gloss and sheen of Touch 2 or Gamepad. When you've got a high fidelity sensor, such as a Wacom pen, those things can sure burst a whole lot of information. Wikipedia says up to 200 times per second. That's where the Sensor API could work well for a very reasonable use case (high fidelity ink). -Charles On 3/16/2012 3:26 PM, Maciej Stachowiak wrote: I think this feature is pretty far out relative to WebKit project goals, even independent of spec maturity level. We've had controversy (though ultimately tentative agreement on adding) APIs for hardware found in some but not all classes of mainstream hardware that runs a browser. For example, Vibration API was pretty specific to the phone. Gamepad API seems specific to game consoles or those relatively rate PCs that have a game pad attached. The types of sensors in this API (Temperature, Air Pressure, Humidity, Magnetic Field Strength...) strike me as not common I/O devices on any mainstream class of hardware. Therefore I would class this whole feature area as experimental and not in line with WebKit project goals. Therefore, I think this work is not appropriate for the WebKit repository at this time, even as a WebCore Module. Of course, implementing the feature outside the main repository, e.g. via GitHub, is ok, and may be an opportunity to demonstrate its general usefulness. Regards, Maciej On Mar 16, 2012, at 2:15 PM, Adam Barth wrote: Historically, the WebKit project hasn't had the warmest relationship with the DAP working group, and we've tended to be conservative about which DAP APIs we merge into trunk. The Sensor API appears to be fairly early in its lifecycle. As far as I can tell, it hasn't even reached FPWD, which means, among other things, that the W3C patent process hasn't started. These factors lead me to think that we should wait a bit before landing the feature in trunk. You might consider implementing this feature as a WebCore Module https://trac.webkit.org/wiki/Modules. If you go that route, the implementation should be fairly loosely coupled with the rest of WebCore, which means implementing the feature first on GitHub (a la https://trac.webkit.org/wiki/UsingGitHub) might be a good choice. This approach will give you a chance to experiment with an implementation and receive feedback from the WebKit community without being blocked on merging your feature into trunk. Adam 2012/3/16 Adam Barthaba...@webkit.org: The specification appears to be here: http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html Has this specification reached FPWD yet? http://www.w3.org/TR/sensor/ returns a 404. Adam 2012/3/16 Dominik Röttschesdominik.rottsc...@linux.intel.com: Hello webkit-dev, We would like to upstream our implementation of W3C Sensor API [1]. As we are aware that this is a young specification, we propose to have it default #ifdef-disabled. However, we believe it could be useful for certain ports or useful for being accessed by Chrome extensions. Your feedback is welcome. For reference, we created meta bug https://bugs.webkit.org/show_bug.cgi?id=81352 Regards, Dominik Röttsches ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is Skia enabled by default on wincairo?
They are mutually exclusive. Cairo is a rendering backend; skia is a rendering backend. On Feb 7, 2012, at 10:23 AM, Tim Stowell stowe...@gmail.com wrote: Hello, Is Skia used in the wincairo port of webkit by default, or do I need to set a compile argument? I looked and I can see Skia support seems to be there but it looks like it might only be for Chromium? 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] ProgressEvents for Images
On 1/23/12 2:55 PM, Dean Jackson wrote: On 17/01/2012, at 10:41 AM, Bear Travis wrote: img id=image src=sample.jpg onloadstart=showProgressBar() onprogress=updateProgressBar(event) onloadend=hideProgressBar()/ Developers have taken various tacks to enable progress reporting, for example in some cases XHR can be used to download image files. Max Vujovic just published a blog about the practicalities of doing so: http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We think it would be preferable to provide support for image progress events directly. I think this would be extremely useful. It would require a proposal to W3C or WHATWG though. Seems like this would need to follow CORS. Even disclosing the file size is going too far for cross-domain without CORS. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks in rendering, was: Re: Timing attacks on CSS Shaders
http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0227.html I appreciate the redirect, and the comments on this thread. I've taken this to FX, specifically about rendering. FX previously discussed what amounts to a11y issues on the CSS Shaders proposal. I intend to take the topic to webapps as well, given the variety and ease of use of various non-rendering timing tricks. I'm feeling quite confident that CSS Shaders will move forward, though slowly, toward reproduction of the proof of concept. -Charles On 12/8/11 3:30 PM, Adam Barth wrote: Your message is somewhat off-topic for this mailing list, which is about the development of the WebKit engine. Would you be willing to re-send your message to the FX task force: http://www.w3.org/Graphics/fx/ That's the appropriate venue to discuss use cases and the like for CSS Shaders. That way we can get feedback from a variety of implementors instead of just WebKit. Adam On Thu, Dec 8, 2011 at 1:51 PM, Charles Pritchardch...@jumis.com wrote: On 12/3/11 11:37 PM, Dean Jackson wrote: On 04/12/2011, at 6:06 PM, Adam Barth wrote: On Mon, Oct 24, 2011 at 9:51 PM, Adam Barthaba...@webkit.orgwrote: Personally, I don't believe it's possible to implement this feature securely, at least not using the approach prototyped by Adobe. I spent some more time looking into timing attacks on CSS Shaders. I haven't created a proof-of-concept exploit, but I believe the current design is vulnerable to timing attacks. I've written up blog post explaining the issue: http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html Thanks for writing this up. I'm still interested to know what the potential rate of data leakage is. Like I mentioned before, there are plenty of existing techniques that could expose information to a timing attack. For example, SVG Filters can manipulate the color channels of cross-domain images, and using CSS overflow on an iframe could potentially detect rendering slowdowns as particular colors/elements/images come into view. CSS shaders increase the rate of leakage because they execute fast and can be tweaked to exaggerate the timing, but one could imagine that the GPU renderers now being used in many of WebKit's ports could be exploited in the same manner (e.g. discover a CSS trick that drops the renderer into software mode). ... Is there something we can do to make rendering-based timing attacks less feasible? ... Or maybe rAF is inherently insecure? Is there an active interest in investigating these issues? I understand that CSS Shaders is bringing them to the forefront. I am confident we can move Shaders forward in a limited and safe manner, by starting first on CORS Media elements, essentially bringing them to parity with WebGL Canvas. That is to say:canvas/canvas -- with WebGL is up on the web and tested as a means to apply filters toimg andvideo. Surely we can provide a CSS short-cut. But back to my concern: Sometimes a new idea or use case brings up real engineering issues that get pushed-back as people push-back on the use case or broader implications. I experienced that phenomenon to a large degree with thecanvas tag in Canvas 2d. I'd like to do better with pixel shaders. Is there an objection to CSS Shaders for media elements, origin safe video, img and canvas? They work in WebGL, they should work fine in CSS. Is there reasonable support for investigating timing issues inside of the browser? We have baseline issues from latency in network requests: If I request an image from a site you've already visited, it's likely to load quicker than a subsequent request for a random 404 page from that site. I feel that this baseline issues can help us take some of the controversy away from future studies on timing issues. They already exist, they're accepted and acceptable for consumer-grade browsers. I'm getting the feeling that these very interesting and important cases brought up by Dean Jackson, are not being evaluated. Webkit vendors, and many w3c vendors, should have an interest in seeing them analyzed. So I'm reaching out here and saying, does anyone think this is a worthwhile avenue for serious study? Is it simply not important for this generation of browsers? Though webkit has a bias against scientific experiment on the code base, being that it's an engineering project, it seems to me like engineering and science as well as security and quality, benefit from asking these questions and doing focused research. -Charles ___ 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] Reg. Direct DOM access without getElementById fails....
They're accessed via the window object in the global scope.
I believe there is a slight compatibility issue between webkit
distributions for
scriptwindow.myvar = function() {}/script!-- followed by --
div id=window.myvar/div, given that it would map to
window.window.myvar.
But nobody does that... And for good reason, it's too tricky.
The use of the window global to access IDs in the DOM ought just be
considered a tool for easy and quick debugging. Any properly written app
should use standard DOM methods in deployment.
-Charles
On 12/8/11 1:02 AM, Vicky Tux wrote:
Thanks for your response. But it was not a typical web stuff, it is
compatibility issue. Some web applications written to access the
elements without getElementById.
Is there any way to implement this stuff on Webkit..? Please give
hints regarding this.
-Vicky
On Wed, Dec 7, 2011 at 9:36 PM, Ariya Hidayat ariya.hida...@gmail.com
mailto:ariya.hida...@gmail.com wrote:
I have facing an issue with Direct DOM access via document
object.
Because it is not part of the DOM standard.
This is elementary web stuff, it would be helpful if you would have
done some basic research first as this mailing list is not to teach
people about browser scripting and incompatibilities.
--
Ariya Hidayat, http://ariya.ofilabs.com
___
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] WebKit branch to support multiple VMs (e.g., Dart)
On 12/6/11 4:23 AM, Zoltan Herczeg wrote: I am sorry if it didn't sound clear enough in our original message, but we're not proposing a new language support, but we're proposing a patch which allows others runtimes to run along with JS in the browser. and they mostly replied to that (including some solution ideas like converting your language to JS. You might even see some speedup They're already in that position with Dart, translating source code into JS. I think there's some real benefit long term going down this route, working on WebKit's flexibility, because LLVM is turning into a real option for the web. Taking this back to the engineering purpose. LLVM works. It's not complete yet, but it works. There are two very workable targets: PNaCl and Emscripten. emscripten as a target is pure JS and supported by modern browsers. https://github.com/kripken/emscripten http://src.chromium.org/viewvc/native_client/trunk/src/native_client/pnacl/ There is good reason to consider native code execution: it will run faster than emscripten. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
Oliver, I could say the same about GLSL, but it's a huge help in my work, so I won't. The proposal is to better enable multiple VMs. Their work would lower the costs of introducing Python. It -may- help with LLVM integration to the DOM. I can hope. -Charles On Dec 5, 2011, at 1:36 PM, Oliver Hunt oli...@apple.com wrote: What is the benefit to the project in exposing an additional (non standardized) language to the web? All the bindings that webkit currently provides to are either standardized EcmaScript or platform specific bindings used by native code developers embedding webkit. Adding an additional web facing language (that isn't standardized) doesn't seem beneficial to the project, if anything it seems harmful (cf. VBScript in IE). Anyway if we were to add an additional language the language people have been asking for for years is Python which is already extremely popular and well known so it seems that it would be a much better choice to expose, but even then it seems like a bad idea. --Oliver On Dec 5, 2011, at 1:22 PM, Vijay Menon wrote: Hi Per, At a high-level, the idea is pretty simple. We want to be able to run another VM along a JS one. For example, if we see a Dart script on a web page, we want the Dart VM to be able to handle it. If we see a JS script, we want the JS one to handle it. Similarly, if an event listener on a page is triggered, we want to forward to the appropriate VM to run the user listener code. The changes here are mostly about refactoring some classes (e.g., ScriptController, ScheduledAction) to add that extra dispatch. I'm not familiar enough with the JavaFX model, but this may be useful if you want to provide direct access from Java to the DOM via Java bindings. Do you have a pointer on how you're handling multiple VMs in WebKit today? Cheers, Vijay On Mon, Dec 5, 2011 at 12:50 PM, Per Bothner per.both...@oracle.com wrote: On 12/05/2011 09:26 AM, Vijay Menon wrote: We’re planning to create a multi-vm branch on webkit.org http://webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. What is there to provide feedback on? Asking people to provide feedback on a huge patch dump seems unreasonable. Why did you choose the approach you did? Is there a planning document or white-paper? What changes did you make at a *high* level - not a set of patches? Did you run into problems or have to decide between alternative solutions? This may be interesting to the webnode portion of Oracle's JavaFX. We already have to deal with multiple VMs: The JSC JavaScript VM and the Java VM. Having a standard and more efficient way of combining them might be helpful. Likewise more direct access from Java to the WebKit core might be helpful, though the standard DOM bindings don't require JavaScript. I don't know if a WebKit port using Nashorn (Oracle's next-generation JavaScript implementation on the JVM) will be helped by a multi-VM WebKit, or make it irrelevant (from Oracle's point of view, of course). -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ 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] WebKit branch to support multiple VMs (e.g., Dart)
On 12/5/11 3:18 PM, Brent Fulgham wrote: As I've matured (or perhaps become more curmudgeonly), I now find greater satisfaction in systems that just work. Minimizing the number of variables that come into play when rendering pages just seems like a smart approach. Consider also the massive shift currently underway in the mobile space. Flash has been abandoned in favor of standardized tools available on multiple platforms with no need for the user to locate, install, and maintain external VMs or other infrastructure. Adobe's Air has reasonably tight integration with WebKit. Not to the extent being proposed here, but it is an active example. I think this issue is better examined from the scope of webkit than from the realm of universal web technologies. Unless I'm misunderstanding something, the proposal here is that webkit support script type in a sufficient manner. What individual webkit vendors do with that is up to them. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)
On 12/5/11 3:34 PM, Chris Marrin wrote: On Dec 5, 2011, at 11:32 AM, Adam Barth wrote: On Mon, Dec 5, 2011 at 10:53 AM, Chris Marrincmar...@apple.com wrote: To be clear, it's not the difference between white and black pixels, it's the difference between pixels with transparency and those without. Can you explain why the attack is limited to distinguishing between black and transparent pixels? My understanding is that these attacks are capable of distinguishing arbitrary pixel values. This is my misunderstanding. I was referring to the attacks using WebGL, which measure the difference between rendering alpha and non-alpha pixels. But I think there is another, more dangerous attack vector specific to CSS shaders. Shaders have the source image (the image of that part of the page) available. So it is an easy thing to make a certain color pixel take a lot longer to render (your 1000x slower case). So you can easily and quickly detect, for instance, the color of a link. Can this proposal be moved forward on CORS + HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? The proposal would really benefit users and authors on those media types, even if it falls short of applying to general HTML elements and CSS urls in the first draft. I realize that it falls short of the lofty goals of the presentation, but it would make a good impact and set the stage for further work. It seems entirely do-able to disable a:visited on elements that have custom filters applied, but, like the timing issues, there needs to be some empirical data on risks before moving forward on them. So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! As I've said many times (with many more expletives), I hate the Internet. I think the solution is clear. We should create a whole new internet where we only let in people we trust. :-) - ~Chris cmar...@apple.com I still love my iPhone. ;-) -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)
On 12/3/11 11:06 PM, Adam Barth wrote: On Mon, Oct 24, 2011 at 9:51 PM, Adam Barthaba...@webkit.org wrote: Personally, I don't believe it's possible to implement this feature securely, at least not using the approach prototyped by Adobe. However, I would love to be proven wrong because this is certainly a powerful primitive with many use cases. I spent some more time looking into timing attacks on CSS Shaders. I haven't created a proof-of-concept exploit, but I believe the current design is vulnerable to timing attacks. I've written up blog post explaining the issue: http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html Jonas Sicking seems to have a similar concern: https://twitter.com/#!/SickingJ/status/143161375823380480 It's probably worth addressing this concern sooner rather than later. Ignoring it certainly won't cause the vulnerability to go away. What was the verdict on CORS + Web Fonts? As I understood things, they were introduced for cross domain use (much like WebGL) and that's been an issue that I think vendors are peddling back on. I'm fully supportive of discovering just what the relative security issues are here... While that's going on: it seems like this feature can be made CORS-aware in subsequent prototypes while we wait on a verdict about timing issues. I'm bringing up fonts, as they'd be the first [that I'm aware of] technology where CSS has integrated CORS. There are many -many-many- quirks that authors will have to deal with, with programmable shaders. If everything were restricted to the CPU, we'd know that well, low end systems run with 1ghz and high end systems have multiple cores, but the performance and compatibility spread is something reasonable. Once GPUs are in the mix, we're talking about a 100x difference, we're talking about all sorts of visual glitches, it's a mess. I'm very much for getting this CSS shader proposal through. Between object-fit (and some other values) and custom shaders, I could rid myself of a thousand lines of code handling some basic image manipulation tasks. There are benefits to developers to weigh with the risks. I would be willing to accept CORS+CSS shaders as a compromise. There are good opt-out mechanisms for secure sites; HTTP headers for nosniff and the like. I do think the security issues that Dean Jackson has brought up are fascinating. It does seem to me that documenting attacks of various sorts is a worthwhile venture. I see it happening in a manner similar to how WCAG-TECHS exists. I don't think that those documented attacks spell doom. Anecdote: I brought up Web Storage to the postgresql hackers mailing list awhile back. At least one developer was absolutely aghast that sites could launch attacks by creating thousands of 5 megabyte storage entries. The 5 meg per-origin limit works in practice, but explaining that fact was difficult. There seems to be broad consensus/desire for facts about known attack vectors. I think it'd benefit all interested parties if something were created, in the style of WCAG-TECHS. http://www.w3.org/TR/WCAG-TECHS/ Such as, Techniques and Failures for Web Security. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] About the Video conferencing and peer-to-peer communication implementation
On 11/10/11 12:32 AM, Kalle Vahlman wrote: 2011/11/10 Victor LIrtj...@hotmail.com: Hi， Does the webkit implements the chapter Video conferencing and peer-to-peer communication now? if it doesn't , is there any plan to support it? There are people working on it: https://lists.webkit.org/pipermail/webkit-dev/2011-November/018445.html I suppose bugzilla has bugs for this, although they are not mentioned in the announcement. Would probably be a good idea to have a tracking bug for this though? Seems like there's need for consensus; a tracking bug might help webkit-devs develop an internal consensus. From the spec, data section: there is currently not enough agreement on the data channel to write it up. http://www.w3.org/TR/webrtc/#the-data-stream Also, on the p2p communication side: Seems like the only means of passing arbitrary binary data over P2P in this spec is to flash a QR code in front of a web cam. I don't want to see P2P implemented so conservatively in browsers that it's restricted to webcams and pre-recorded audio-video files. The spec mentions a signaling channel but that channel is coordinated via the server, e.g. using XMLHttpRequest.. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
On 11/4/11 7:23 AM, Chris Marrin wrote: On Nov 3, 2011, at 7:00 PM, Charles Pritchard wrote: In my experience, implementing filters leads to writing them multiple times for various targets. I suggest starting with the lowest common denominator before targeting platforms like webgl. I understand that Google is working on an in-software webgl implementation (angle is just a conversion lib); at some point LLVM may have sufficient semantics-- it's certainly been attempted (there's a polyhedron article somewhere on the site). You're saying you believe Google is developing a version of WebGL that runs completely in the CPU? I haven't heard of such a thing and I would be surprised if it were true. Running a GLSL shader in software is possible, in fact OSX has a software renderer that does just that. And while it can get a few fps with a simple shader, it's not practical for serious realtime 3D graphics. http://code.google.com/p/chromium/issues/detail?id=91445 a software fallback is in the works Similarly, here's WebGL implemented in Canvas 2d and ECMAScript: http://code.google.com/p/cwebgl/ It's certainly the case that CPU rendering will not be practical for serious realtime 3D graphics. There's absolutely a divide between computers that have sufficient GPUs and ones that do not. The initial WebKit implementation of CSS filters will use the filter code already in the SVG implementation. This does use vector optimizations on some platforms for some shaders. So it will be fully CPU based. From there several options exist for hardware acceleration, some platform specific and others more generic, based on WebGL or some other GPU based acceleration. I'm a bit behind on the bleeding edge: Is there work / a foundation for running these rendering process across multiple cores? In https://bugs.webkit.org/show_bug.cgi?id=68479 I plan on adding some filter infrastructure at the GraphicsLayer level to make it simpler to implement layer-based hardware accelerated filters. Much appreciated. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Starting implementation on W3C Filter Effects
In my experience, implementing filters leads to writing them multiple times for various targets. I suggest starting with the lowest common denominator before targeting platforms like webgl. I understand that Google is working on an in-software webgl implementation (angle is just a conversion lib); at some point LLVM may have sufficient semantics-- it's certainly been attempted (there's a polyhedron article somewhere on the site). Anyway, my two cents. Best of luck! -Charles On Nov 3, 2011, at 5:02 PM, Rik Cabanier caban...@gmail.com wrote: Dean, could you implement the filters on top of shaders if the target has WEBGL acceleration? Doing animated filters in software will be slow unless you spend a significant amount of time on coding SSE or NEON instructions. Rik On Mon, Oct 24, 2011 at 9:02 PM, Dean Jackson d...@apple.com wrote: On 22/09/2011, at 11:30 AM, Dean Jackson wrote: Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification. https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe. A followup: we're going to start work on the CSS Shaders proposal [1] soon. Adobe have published their implementation which was specific to Chromium, and we'll be working with them to split it into small patches that can land in the coming weeks. A good introduction to the technology is [2]. This will be done behind the ENABLE_CSS_FILTERS macro, but also with the guards for ENABLE_WEBGL since the implementation (and security) requirements are so similar. Dean [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html [2] www.adobe.com/devnet/html5/articles/css-shaders.html ___ 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] New feature announcement - Implement HTML5 Microdata in WebKit
On 10/12/2011 4:12 PM, Ryosuke Niwa wrote: Given that Gecko is implementing the unprefixed getItems (see https://bugzilla.mozilla.org/show_bug.cgi?id=591467), I don't see benefits in implementing with webkit prefix. Also, it's still under a compile-time flag so we can prefix it before enabling the flag by default if we strongly feel like it. - Ryosuke I've no objection. I'd like to hear from Microsoft and Opera. I'll go solicit their feedback. -Charles ___ 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
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. -Charles On 9/22/2011 8:00 AM, Adam Barth wrote: Just so I understand, you're talking about the DOM APIs for interacting with microdata, right? I know there was some controversy in the HTML working group about Microdata versus RDFa. It's not 100% clear to me which of those technologies will win out in the end, but it seems valuable to implement this feature behind an ENABLE flag. Adam On Thu, Sep 22, 2011 at 4:48 AM, Arko Sahangh...@motorola.com wrote: Hi, I have been looking at HTML5 Microdata implementation in Webkit. Microdata is a specification used to nest semantics within existing content on web pages. Search engines, web crawlers, and browsers can extract and process Microdata from a web page and use it to provide a richer browsing experience for users. Microdata helps technologies such as search engines and web crawlers better understand what information is contained in a web page, providing better search results. Here is the spec : http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata I have logged a bug for this and also attached a basic implementation patch for the same. Master bug: https://bugs.webkit.org/show_bug.cgi?id=68609 Please let me know your suggestions/views regarding this. Thanks in advance. Arko Saha ___ 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] New feature announcement - Implement HTML5 Microdata in WebKit
On 9/22/2011 2:13 PM, Ian Hickson wrote: 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. I would like some kind of fast track method for these kind of issues. Something like a Request for dropping prefix RfDP protocol would be super. RfDP: Microdata. First the spec editor would have to vouch for it, then, if Moz, MS, Opera, Apple and Google reps can give a nod within a few weeks, we've got something. I'd really like to avoid repeats of the CSS -vnd-transform baggage, when possible. WebKit went back and forth on BlobBuilder. Now it's at: WebKitBlobBuilder. That was not so fun. That's another situation I'd like to avoid. For this particular method, the microdata section, I'm happy enough hearing that the spec editor will vouch for it. If that's the precedent, I'll take it. I'd like to learn how we can build on that precedent. Reps from the major vendors have been quite responsive this year. I know they can't commit to supporting an API in a short time frame (such as the File API), but they have been great about voicing issues. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Vendor Prefixing, was Re: New feature announcement - Implement HTML5 Microdata in WebKit
On 9/22/2011 2:42 PM, James Robinson wrote: On Thu, Sep 22, 2011 at 2:32 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 9/22/2011 2:13 PM, Ian Hickson wrote: 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. I would like some kind of fast track method for these kind of issues. Something like a Request for dropping prefix RfDP protocol would be super. Please post this feedback to some thread where it's relevant, not on a WebKit development mailing list discussion about a specific feature. James Robinson, this thread is about introducing a specific feature, Microdata, into the WebKit code base. ENABLE flags are present, vendor prefixing is absent. https://bugs.webkit.org/attachment.cgi?id=108313action=review https://bugs.webkit.org/attachment.cgi?id=108313action=review I have no intention of sending irrelevant e-mails to your inbox, nor derailing this conversation. I think we can all agree that Arko Saha's work is welcome. The patch is quite simple, it's easy to review. I do not believe I've stepped outside the thread, nor do I believe Dean Jackson was being counter-productive when he pointed out that vendor prefixing is not an issue particular to this feature. Dean Jackson and Ian Hickson spoke about whether or not the vendor prefix should be included. Ian suggested that vendors should skip vendor prefixing. Dean is a bit more cautious, and has good reason to be. WebKit's experience with File API encountered quite a bit of criticism from other vendors. Both Adam Barth and Dean would like to avoid controversy with other vendors. That's the impression I'm getting. My concern, on this WebKit development mailing list, is that introducing another method -without- vendor prefixing may create some tension that WebKit developers would like to avoid. It simple patch. As far as I can tell, vendor prefixing is exactly what should be discussed. The patch can be approved by one person, the decision on whether or not to prefix the method name should be discussed by multiple vendors. WebKit serves multiple vendors. Again, I'm not trying to get in your inbox, James. If this still makes no sense to you, or I've misunderstood other WebKit developers, I do apologize. I'm trying to contribute, I'm not always successful at it. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Media Element ie: Audio or video, without tabindex cannot be selected with keyboard (TAB Key). BUG: 67190
On 9/14/11 2:02 PM, Antonio Gomes wrote: What would script see as focused if we allow subcontrols be focusable? Since controls are part of shadow DOM, scripts wont be able to see that. In this case then they would probably end up with respective media element. Well, then that should be layout tested as well. Does the accessibility tree contain appropriate information about the text description and role of the shadow elements? Is the shadow DOM something that may be exposed publicly, the future? Such that a script can interact with those control elements. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] innerWidth Behavior and webkit transform
Related to my work on innerWidth, outerWidth and devicePixelRatio: https://lists.webkit.org/pipermail/webkit-dev/2011-April/016412.html https://bugs.webkit.org/show_bug.cgi?id=51190 It seems that running -webkit-transform on an iframe now sets the innerWidth of that iframe to the post-transformation value. e.g.: iframe style=width: 100px; -webkit-transform: scale(.5,.5) will result in innerWidth = outerWidth / 2 (approximately). (innerWidth == 25) document.body.width is still 100px. I believe this is new behavior (I'm not sure). I'm not sure that this is correct behavior. From what I recall, webkit-transform should not be exposing itself to the iframe's environment. To get the actual width for painting, within the iframe, I now have to run something like: document.body.width. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Considering a Touchhover
Checking in on this old issue. We have drawFocusRing(element) in the Canvas 2d spec for keyboard accessibility, we're looking to add setClickableRegion(element) for pointer event/spatial accessibility. Primarily, for apps like VoiceOver on Mobile Safari, and ZoomText on windows, we need the a11y tree to stash bounding box information for interactive elements in the shadow dom, and it needs to be done in a way that's efficient. That information is shared by drawFocusRing, only applies when an element has active focus. setClickableRegion would apply to an element as long as it is in the canvas shadow dom; using an empty path could also reset the bounding information. As part of encouraging Canvas developers (and as requested by several canvas developers) to use the method, we've discussed using the method on the UA side as well, to capture and forward pointer events. I've found some precedent for delegating click events/using an onclick handler, though most developers would like to see all pointer events bubble up from the canvas shadow dom. The highest priority is to fill in the bounding box information for the accessibility tree; and when the shadow dom in webkit is activated, this should be a trivial task. This is not retained mode canvas, as the scripting environment has no access to that information, it simply passes that info to the accessibility API. Links galore: Precedent for .click(), the pointer-event analogue similar to .focus(): https://dev.mozilla.jp/localmdc/localmdc_6373.html#Using_hidden_file_input_elements_using_the_click%28%29_method I believe click() is passed to shadow dom elements in IE9 with focus() events, as part of an obligation to the ARIA specs. Proposals for something like setClickableRegion: Charles Pritchard (me): http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0187.html Jonas Sickling: http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html Richard Schwerdtfeger: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0081.html More abstract: David Singer: http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0179.html Edward O'Connor: http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0024.html More concrete: WebIDL demonstrating Edward's proposal, as well as options for Richard/Jonas proposals: (search for Supplemental) http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0047.html Richard's earlier proposal: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0090.html http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0090/Canvas2DClickableRegion.html#focus-management CanvasRenderingContext2D implementations: http://trac.webkit.org/browser/trunk/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp https://hg.mozilla.org/mozilla-central/file/ec809c159ad2/content/canvas/src/nsCanvasRenderingContext2D.cpp Please let me know if there's anything I can clear up about this issue. The list of links and discussion is rather lengthy, but the issue itself is quite simple. My original thread was about adding a touchhover event, which would allow the scripting environment to manage hit testing for VoiceOver on Mobile Safari. Though it's a relatively easy to implement, it does not solve the underlying issue that VoiceOver and other ATs would do better to have bounding box information ahead of time. At some point, touch screens may benefit from a touchhover event; tablets are capable of penpressure and penhover events, though they simply pass them as mouse events (see Wacom's Bamboo as an example) with a serial interface to pressure. -Charles On 3/21/2011 12:06 PM, James Craig wrote: The canvas sub-DOM proposal should allow some of this, but AFAIK, it is not implemented in WebKit yet. I believe we were the first to propose it, though to date I think it is only implemented in IE9. I have not checked IE to verify support, but they have claimed support in IE9. Basically the ARIA-enhanced subtree is accessible to the keyboard and assistive technology, and the DOM structure mimics the UI visible in the canvas. It requires a focus model change to WebKit because the canvas subtree was not originally intended to be accessible in any modality. http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0026.html I'm not sure I agree with the need for a touchhover event, but I'd be interested to hear how you think it should work. James On Mar 11, 2011, at 3:30 PM, Chris Fleizach wrote: There's no established API to handle this, but we are working on a W3C proposal http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html to address this. In the meantime, VoiceOver on iOS will call .focus() every time it hovers on an item, so you can use that monitor where VO is at any moment. If that doesn't work withcanvas tags please file bugs at bugs.webkit.org and CC me
Re: [webkit-dev] Considering a Touchhover
I neglected to include the two relevant bug reports: Fallback content in canvas element not focusable https://bugs.webkit.org/show_bug.cgi?id=50126 VoiceOver does not work well with Canvas in mobile safari https://bugs.webkit.org/show_bug.cgi?id=63463 -Charles On 3/21/2011 12:06 PM, James Craig wrote: The canvas sub-DOM proposal should allow some of this, but AFAIK, it is not implemented in WebKit yet. I believe we were the first to propose it, though to date I think it is only implemented in IE9. I have not checked IE to verify support, but they have claimed support in IE9. Basically the ARIA-enhanced subtree is accessible to the keyboard and assistive technology, and the DOM structure mimics the UI visible in the canvas. It requires a focus model change to WebKit because the canvas subtree was not originally intended to be accessible in any modality. http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0026.html I'm not sure I agree with the need for a touchhover event, but I'd be interested to hear how you think it should work. James On Mar 11, 2011, at 3:30 PM, Chris Fleizach wrote: There's no established API to handle this, but we are working on a W3C proposal http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html to address this. In the meantime, VoiceOver on iOS will call .focus() every time it hovers on an item, so you can use that monitor where VO is at any moment. If that doesn't work withcanvas tags please file bugs at bugs.webkit.org and CC me On Mar 11, 2011, at 9:43 AM, Charles Pritchard wrote: Recently, while working on code review / accessibility for a large canvas application, I found that the iOS VoiceOver AT does not play well with the html canvas element. It can work, but it's not a natural transition from html to canvas (with buttons in it). Using transparent [button] tags work, but it is rather awkward. It occurred to me that, when VoiceOver is on, on these mobile devices, that a new touch type is active. For the time being, I'm proposing calling it touchhover. Currently, VoiceOver AT captures touch events, waiting until the user has set virtual focus to an element, then tapped twice, to set event focus on that element. It works quite well for html elements. My thinking is that this state, where it's not passing touchstart/touchmove/touchend events, is very much like the traditional hover events we've used with mice. If touchhover events were passed through Mobile Safari, I'd be able to use hit detection on canvas elements, and set the canvas element to the appropriate title matching whatever the user has focus upon. Does this make sense? Should I provide more examples? The purpose here is to enable UI elements in Canvas to work appropriately with touch-based AT, such as the iOS VoiceOver extension. -Charles ___ 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] Is vendor-prefixing JavaScript APIs a waste of time?
ArrayBuffer has gone [mostly?] without vendor prefixing,
CSS transforms and RAF (requestAnimationFrames) went with.
createObjectUrl has been touch-and-go.
As a dev, I look at RAF and CSS transforms and wonder why vendors couldn't
agree to those two ahead of time.
Then there is createObjectUrl and ArrayBuffer, which
have had their unexpected changes in (WebIDL) specs and prefixing.
It'd be nice to see a -fast track- decision process which might be tapped
upon for future methods. If the four large vendors agree on a method name
through a fast track process, perhaps devs could skip some vendor prefixing.
The issue there, of course, is that vendors would be tacitly agreeing
to implement such methods. And while they may agree internally
and add it to their road-map, company policy may prohibit
public acknowledgment.
For example, I doubt any vendors object to the basic Typed Array types,
and those types are not currently prefixed.
-Charles
On 7/9/2011 1:33 PM, Ojan Vafai wrote:
I share this concern, but I don't think there's anything special here
with respect to JavaScript APIs. The same argument applies to how
people are often encouraged to use CSS property vendor prefixing.
div {
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}
I'm fairly ambivalent on this. It's not clear to me how much it buys
us, but I can think of examples where it has worked well (e.g.
gradients) because we were able to push the code out and get just
enough usage to get useful feedback, but the usage wasn't so
widespread that our hands were tied for the final API.
There's been an immense uproar about vendor-prefixing on a number of
w3c and whatwg mailing lists in the past year or two. Noone seems
especially happy with the current tradeoffs, but noone has made a
better proposal yet either.
Ojan
On Sat, Jul 9, 2011 at 12:56 PM, Adam Barth aba...@webkit.org
mailto:aba...@webkit.org wrote:
The IE blog has had a couple posts recently about new JavaScript APIs
that are vendor prefixed:
http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-1.aspx
http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx
Here's one of their code examples:
8
// Future-proof: when feature is fully standardized
if (window.requestAnimationFrame) window.requestAnimationFrame(draw);
// IE implementation
else if (window.msRequestAnimationFrame)
window.msRequestAnimationFrame(draw);
// Firefox implementation
else if (window.mozRequestAnimationFrame)
window.mozRequestAnimationFrame(draw);
// Chrome implementation
else if (window.webkitRequestAnimationFrame)
window.webkitRequestAnimationFrame(draw);
// Other browsers that do not yet support feature
else setTimeout(draw, PERIOD);
8
There are a couple things to notice:
1) The requestAnimationFrame API has a vendor prefix in all of these
implementations, making this code ugly.
2) The vendor prefix isn't buying us anything because this code
assumes that the final, non-prefixed version of the API will work the
same way that the vendor prefixed version works!
If web developers are going to assume that future, non-prefixed
versions of the APIs work the same way as current prefixed versions of
the APIs anyway, we shouldn't bother with prefixed versions because
we're already locked in to the current behavior, even without the
prefix.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org mailto: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] Implementing new WebSocket protocol
That said, you're all lucky that the rest of us developers have no idea when the current round of specification flux will settle down. Security vulnerabilities will always trump the specs. Thanks for keeping on top of things. -Charles On 6/23/2011 5:16 PM, Ian Fette (イアンフェッティ) wrote: That said, I don't think the intent should be to support any old versions for any protracted amount of time. -00 has security vulnerabilities brought up by people on webkit-dev@ so from the Chrome side, we intend not to support -00 at all once we have -09 support available. All the makers of server-side code have already published versions compatibile with the latest draft, and IETF drafts are intended to expire after a fixed amount of time (-00 is already well past its expiration date). -Ian On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke julian.resc...@gmx.de mailto:julian.resc...@gmx.de wrote: On 2011-06-23 17:15, Simon Fraser wrote: I'm surprised that the protocol has no facility for versioning. Is that really he case? Should it be considered for future versions of the spec? It does. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.11 ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto: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] Accessibility Object Searching
On Jun 21, 2011, at 4:30 PM, Samuel White samuel_wh...@apple.com wrote: Hey everybody, I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information. I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out. Thanks Sam While you're rooting around in there, I'd love to see the tree exposed to WebKit inspector at some point. It might make ARIA a little easier to use. I'm still months away from being a contributor-- I'm hoping to see the canvas shadow DOM made accessible, and subsequently, see paths supported by assistive technology, like Apple's gesture-based eyes-free mode in Mobile Safari/iOS. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree vs. Render tree
On Jun 16, 2011, at 8:53 AM, Darin Adler da...@apple.com wrote: On Jun 16, 2011, at 7:21 AM, song.7@nokia.com wrote: Could some share what’s the design consideration about the DOM tree and Render tree separation? CSS styling makes it easy for almost any DOM node to render as almost anything. To give one trivial example, a paragraph element can be turned into a table cell with display: table-cell or removed from rendering entirely with display: none. The main reason to have a separate render tree is that the structure and classes of the render tree nodes can reflect the post-style-computation decisions of what will actually be rendered, which can be quite a bit different from the structure of the document itself. The DOM tree nodes represent the document’s structure. -- Darin On the topic of trees: I've used the canvas to swap out and use my own render tree. The ARIA spec has attributed like aria-owns which in some manner, allow one to set an accessibility tree that differs from the Dom tree. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
On 6/9/2011 8:24 PM, Pierre-Antoine LaFayette wrote: Android uses a retain mode rendering approach as well; where paint operations are recorded on a WebCore thread and painting is actually done on the UI thread. It isn't necessarily the best approach. But I suppose it depends the platform whether or not there is much to gain. You still need to worry about synchronization. ... On 6 April 2010 03:24, Eric Seidel e...@webkit.org mailto:e...@webkit.org wrote: Parallel painting would only be useful if the graphics layer is incredibly slow. In most WebKit ports we do not see very much time ... On Sat, Apr 3, 2010 at 10:32 PM, Zoltan Herczeg zherc...@inf.u-szeged.hu mailto:zherc...@inf.u-szeged.hu wrote: Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation Is this something that could be used to duplicate painting commands? I'm very interested in enabling secondary painting contexts, to enable better representation of Zoom, and other common assistive techniques. Example: If the recording is used, prefixed with scale and crop, a user could be presented with a crisp and clear magnification of a focused region or other sub-region. Such techniques could also be useful for remote viewing, via serialization, and for efficient screen dumps [assuming the render works, of course]. It'd be great, if some time, secondary user agents, like the popular ZoomText Magnifier, were able to interact with WebKit and request regions to be painted at a higher resolution, so as to display the magnified image at native resolution. Does that make sense? Is that something that this technique might eventually provide? I suspect that screen mirroring and other forms of screen sharing will become more common in use, as more and more physical screens become common in our common lives. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On 5/18/11 2:09 PM, Peter Kasting wrote: On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham bfulg...@webkit.org mailto:bfulg...@webkit.org wrote: Google used this same approach with their Chromium port, the side effects of which find us in year two (or three?) of the effort to merge those changes back into the core WebKit archive. Um, what? The Chromium port is fully upstreamed and has been for some time. I'm not sure what you're saying here. We are not forked and in fact have no support for building Chromium with anything other than upstream WebKit. And as a web app developer, I've been happy to push bug fixes into WebKit via Chromium bug reports. I heard from RIM that they're working hard to get their fork back in line with WebKit upstream; they've contributed a lot of work to WebKit upstream, but are not yet merged back in... That's what I heard. I think Brent's question to the list may have some merit if looked at from a different perspective. Let me try it... Peter: Are there any lessons learned about that process Chromium went through? As a coder, I certainly see that fork and merge process as a normal process -- a company forks from the upstream, works on the code base within their own product, and at some point their use becomes mature and they're able to merge back in with the upstream. Are there any insights to that process -- or even estimates -- such as -- it took us x months once we had WebKit working for us, to get back to building directly with the upstream. Little bits of information like that may be helpful to some WebKit vendors. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
On 4/6/2011 12:32 PM, David Hyatt wrote: He wants a way to detect Desktop zoom (which is done two different ways in WebKit). It's difficult to figure out how to expose these, since Desktop zoom is ultimately just the CSS zoom property, which can be applied to any element (so folding it into a global makes little sense). The other kind of Desktop zoom that involves a fixed scale factor applies a transform. Again, transforms can be applied to descendant elements as well, so relying solely on what happened to be specified at the document level makes little sense. The descendant elements are under the control of the author. That is, if I decide to use body.style.webkitTransform, in my scripting environment, I'm going to know that, because I initiated the request, and I'll add that to my calculations. Worst case, I can always walk the DOM, grab the transform style, and use CSSMatrix to calculate values. With desktop zoom, the user initiates through the UA, which sends a resize event through to window, but the scale is not directly exposed to the scripting environment in WebKit. I am simply looking for the scale factor; this is an accessibility issue, for users who are using the UA zoom. I'm not really sure how to easily solve this problem. I suppose we could just mix in document-level zoom and transform state into devicePixelRatio, but that feels inelegant to me given that individual child elements can change the zoom and transform. It wouldn't necessarily be accurate. I also don't like the idea of having to re-resolve style just because the zoom level changed. That would just slow things down. Current use of window.devicePixelRatio is static, we might as well keep it that way. On mobile devices, authors disable UA scaling and handle the entire process themselves. I see adding a pixel ratio property to window.screen as the cleanest solution. CSS checks work, they're not slow, but they're extra work on the author, and in-elegant, as media matches return booleans, not float values. They're inefficient, but not slow in any practical sense. I'm really open to any kind of help I can give here. I've full experience implementing the stack, from multi-level descendant transforms starting at document.body, to the hacks necessary to get window.screen.pixelRatio, and still support an additional magnification AT, such as ZoomText or the OS magnifier. I also have experience with transform3d/webgl, but that's a different issue. I've spoken to reps from both Google (re: TV) and Microsoft about having distinct X and Y ratios, as MS currently does in screen. Robert O suggested that tracking horizontal and vertical scaling separately was unnecessary (non square pixels) on modern displays. Both reps agreed. It doesn't harm anything, to have both X and Y scale values, but it does not seem to be necessary. http://msdn.microsoft.com/en-us/library/ms535868(v=vs.85).aspx Netscape exposes the value to trusted scripts as screenPixelsPerCSSPixel through their Utils Components interface. https://developer.mozilla.org/en/NsIDOMWindowUtils -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
Did this move anywhere? http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328 https://bugs.webkit.org/show_bug.cgi?id=51190 http://code.google.com/p/chromium/issues/detail?id=66656 Firefox is a nasty CSS hack, but it does work, and that's something to be happy about. Microsoft makes it easy; Firefox developers have said they do not want it to be easy. http://msdn.microsoft.com/en-us/library/ms535868(v=vs.85).aspx https://bugzilla.mozilla.org/show_bug.cgi?id=486200 From Robert O, reflecting Mozilla's policy: I don't want Web authors to have easy access to information about screen pixels. They'll try to defeat our zooming or size things to screen pixels, which we don't want. WebKit and MS already diverge from Firefox in handling of window.innerWidth/innerHeight and window.screen properties. That's not news. I'd really like to see a resolution to this issue. The hacks I'm using just aren't stable in the long term. I'd prefer the property were just exposed to the DOM via window.screen, as MS has done it, but I'm ok doing CSS media queries. It's just that media queries require something of a brute-force of case statements; I have about ~12 media queries to handle Firefox, all just repeating min media query, trying to narrow down the resolution. Long-story-short, can we please expose some of the CSS pixel scaling, either through window.devicePixelRatio, through CSS media queries on device-pixel-ratio, or through the window.screen object, in a way similar to how MS has done it Anything will work.. I just need one. -Charles On 3/4/2011 12:02 PM, Kenneth Rohde Christiansen wrote: Hi Simon, I guess you could use the media query listener defined in http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface We support that on trunk now. This of course means that we will need to reevaluate the CSS when a pinch zoom ends, which we might be doing already given media queries such as @media all and (min-width: 200px). Cheers Kenneth On Fri, Mar 4, 2011 at 8:47 PM, Simon Frasersimon.fra...@apple.com wrote: On Mar 4, 2011, at 11:24 AM, Kenneth Rohde Christiansen wrote: Hey Oliver! If you are saying that device-pixel-ratio should include the user scaling, then I can push that for Qt, but I would really like seeing it supported by iOS as well for compatibility reasons. If you create a bug for that, please cc me. There's a problem with that, which is that the author can assume (possibly erroneously) that device-pixel-ratio doesn't change for the life of the page. However, the zoom level can change often, and there's no notification that the author can register for that will tell them when the zoom level changes, and thus when they'll need to redraw their canvas contents. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Page Visibility API
requestAnimationFrame may provide a method for 'pausing', when following a window blur event. It was recently added. -Charles On Mar 8, 2011, at 11:35 AM, Shishir Agrawal shis...@chromium.org wrote: Hi All, We would like to implement a Page Visibility API in webkit. The corresponding bug is at: https://bugs.webkit.org/show_bug.cgi?id=54181 . The bug has details of the proposal, link to the whatwg discussion as well as a patch. The proposal is also pasted below for convenience. Please let me know if you have any questions / concerns. Thanks Shishir Proposal details Hi all, There is currently no good way for a web page to detect that it is completely invisible to the user (for example, that it is a background tab), although some imperfect heuristics do exist. In the future, there may be cases where such detection is even more important, for example in the prerendering feature that Chromium is currently in the early stages of experimentation with. Note that an earlier version of this proposal was sent to the what-wg mailing list for comment earlier ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029382.html), and received comments that led to several revisions. The following proposal introduces only a minor change on top of the result of that discussion (specifically, renaming document.visibility to document.visibilityState and document.isVisible to document.visible, in order to encourage developers to prefer using the simpler boolean property). Use cases * A page wants to detect when it is being prerendered so it can behave appropriately. * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. * A streaming video site doesn’t want to start the video until the user actually views the tab for the first time (i.e. video shouldn’t start automatically if a user opens the tab in the background). * An in-browser collaborative editing environment wants to update a user’s status to away when the editing surface is not visible to the user. With these use-cases in mind, there are a number of requirements. Requirements * Easy for developers to write scripts that fall back on old behaviors for browsers that do not implement this API * Ability to query the document’s current visibility state * Events fired when the document transitions between visibility states * Ability for browser vendors to add new visibility states in the future Proposed API document.visible Returns true if document.visibilityState’s current value is in the set of visibility states considered to be visible (see the next section for information on document.visibilityState). In practice document.visible is merely a convenience property that is well-suited to simple uses. In most implementations, only the “visible” state is considered visible--although some implementations may consider other values to be visible as well (for example, an implementation that makes use of nearly-full-size thumbnail previews may consider “preview” to be a visible state). document.visibilityState A read-only property that returns a string, one of the values described in the next section. Developers can use the existence of this property to know that they can rely on the rest of this API, too. * Values returned by all conforming implementations * “visible” : the full-size page content may be at least partially visible on at least one screen. * “hidden” : the full-size page content is not visible to the user at all. * Additional values potentially returned by some implementations in some cases * “prerender” : the page is currently being loaded off-screen and might never be shown to the user. * “cache” : the page is currently “frozen” in a cache and not displayed on screen (e.g. the back-forward cache). * “preview” : the page is currently visible only in a lower-resolution thumbnail. States in the second set are not guaranteed to be returned in all cases where they might otherwise appear to apply--it is left to the discretion of the implementation. Additional return values may be added to this API in the future. It is up to the implementation to interpret what these values mean in the precise context of interface and platform. As an example, a current-generation desktop browser might interpret the values the following way: “visible” : the tab is focused in its non-minimized window (regardless of the focus state of the containing window). “hidden” : the tab is backgrounded within its window, or the containing window is minimized. visibilitychange A simple event, fired at the document object immediately after document.visibilityState transitions between visibility
Re: [webkit-dev] Canvas backing resolution
On 3/5/2011 5:41 AM, Benjamin wrote: On Fri, Mar 4, 2011 at 8:16 AM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: I'm hoping for a resolution to this issue, as we do use the canvas tag, and our canvas elements appear a little blurry on some devices: without a solution, some of our users will have to manually adjust the sharpness of the site... adjusting a website until it comes into focus seems a bit strange. For reference: in November, there was a thread on the whatwg mailing list regarding this problem: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029072.html If that is something we want to solve, that should go through standardisation in my opinion. There are already too many methods available, let's not create a new one :) As with applying css to things like scroll bars, Mozilla is immovable in their position. WebKit and Mozilla currently take different routes on items like css on scroll bars and on window screen units. You can simply compare the MS/WebKit window.outerWidth/innerWidth and window.screen objects to Mozilla's to see that divide. Mozilla's current requirement of using CSS selectors falls within existing practice. And I posted their method at the start of this thread. -webkit-min-device-pixel-ratio and -moz-device-pixel-ratio Microsoft's extended window.screen does not use any existing standards: http://msdn.microsoft.com/en-us/library/ms535868(v=vs.85).aspx Internally, to trusted scripts, Mozilla exposes window.screenPixelsPerCSSPixel: https://developer.mozilla.org/en/NsIDOMWindowUtils I'm all for standardization here, but like other UI items, Mozilla has as a policy, obfuscated their access. As CSS selectors are working in FF4, and WebKit supports a similar selector that seems a good place for consensus. Canvas has been in for some five years now, and this issue has still not been addressed. I'm a bit frustrated, as it truly is a matter of exposing a single floating point value to the scripting environment. The consensus response at whatwg seems to be that the value should never be exposed to the scripting environment [though the css selector inadvertently does so], and that in the long-term, the resolution will be managed by the UA/implementation. Again.. this issue could have been fixed five years ago. I'd like to see it addressed this year. My current webkit hack will not work in the long term. IE9 [intentionally] and FF4 [inadvertently] expose the value I need. Let's do something for WebKit. I'm fine with: window.webkitPixelRatio, or any other manner to address this accessibility issue in the short term. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
On 3/4/2011 12:21 AM, Kenneth Rohde Christiansen wrote:
Hi there,
I do not exactly understand what you are trying to do (you want the
canvas to cover the whole view?), but for me
I'm trying to keep the canvas bitmap at the same pixel resolution as the
device,
otherwise it is blurry.
This, for example, works if the pixel ratio is 2.
canvas style=width: 100px; height: 100px; width=200
height=200/canvas
This returns true, always, on non-mobile platforms, it seems:
window.matchMedia('(-webkit-min-device-pixel-ratio: 1)');
makes perfect sense on the desktop, as the content isn't scaled up in
any way (except user zooming). It means that one css pixel should
correspond to one screen pixel given your current screen resolution.
Yes, when the user has a zoom level set, I'd like to paint to match the
pixel ratio,
so that, a zoomed in user still receives crisp output, instead of blurry
output.
On the other hand on many Android devices (most 240 DPI) the web
contents using a viewport meta tag is scaled up with 1.5 due to most
mobile pages being designed for a DPI of 160, and so the
-webkit-device-pixel-ratio reports 1.5. On the iPhone 4, the contents
is scaled up by 2.0 due to the retina display and the
-webkit-device-pixel-ration will report 2.0.
Yes, Android and Mobile Safari distributions work fine.
-Charles
Cheers
Kenneth
On Fri, Mar 4, 2011 at 8:16 AM, Charles Pritchardch...@jumis.com wrote:
Is there currently an accepted way within webkit to get the resolution which
should be used for an HTML canvas backing store?
Currently, on Mobile Safari and Android, I can use window.devicePixelRatio,
on the desktop, I use window.outerWidth / window.innerWidth and on FF4, I
use
a big string of CSS min-pixel-device-ratio CSS selectors, as fall through
case statements,
and on IE9, its exposed through window.screen.
I noticed over at the bookstore, as I pawed a color kindle, that I didn't
get the mixture right,
for that device. Time is running out for me on some distros, as Sidebars
come into use,
as they'll break the inner/outerWidth hack.
Anyway, that's the story. Is there a method to get the current, proper pixel
ratio, between CSS and device pixels,
across webkit distributions?
---
FF4 hack, example:
#canvas.CompatibilityMozScreen { width: 1px; }
@media all and (min--moz-device-pixel-ratio: .3) {
#canvas.CompatibilityMozScreen { width: .3px; }
}
@media all and (min--moz-device-pixel-ratio: .5) {
#canvas.CompatibilityMozScreen { width: .5px; }
}
... continued many times, based on:
http://kb.mozillazine.org/Toolkit.zoomManager.zoomValues
This trick does not seem to with webkit, or it is otherwise restricted to
mobile devices:
This returns true, always, on non-mobile platforms, it seems:
window.matchMedia('(-webkit-min-device-pixel-ratio: 1)');
---
I'm hoping for a resolution to this issue, as we do use the canvas tag, and
our canvas elements appear a little blurry on some devices:
without a solution, some of our users will have to manually adjust the
sharpness of the site... adjusting a website until it
comes into focus seems a bit strange.
-Charles
___
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] Canvas backing resolution
On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote: Hi again, I'm trying to keep the canvas bitmap at the same pixel resolution as the device, otherwise it is blurry. OK, I see. This, for example, works if the pixel ratio is 2. canvas style=width: 100px; height: 100px; width=200 height=200/canvas Yes, when the user has a zoom level set, I'd like to paint to match the pixel ratio, so that, a zoomed in user still receives crisp output, instead of blurry output. -webkit-device-pixel-ratio does not change when the user scaled the content; it is a device value. On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5 depending on it being a low, medium (160) or high dpi (240) device. On the iPhone 4 and the new iPod Touch it is 2.0. On Android devices, with for instance, a device-pixel-ratio of 1.5, you can disable the upscaling by adding target-densitydpi=device-dpi to the viewport meta tag. What you can do is to disable user scaling (add user-scaling=no to the viewport meta tag) and then handle zooming in your app using the touch events. This only works on mobile devices though. I haven't debugged with enough tablet devices, such as the color kindle, to know how many webkit distros it works with. What should I do about user zoom on the desktop (and possibly, the kindle) ? Drawing in high res, just-in-case, makes for a poorer experience for users at a 1.0 ratio, and asking users to slide a sharpen slider is a little awkward. Mozilla, in their implementation, has setup device-pixel-ratio to scale when the user scales content; they directly expose window css pixel ratio value to trusted scripts, but not to web content; requiring web content to use css device-pixel-ratio. Microsoft has exposed the values through window.screen. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
In the future? On Mar 4, 2011, at 8:51 AM, Oliver Hunt oli...@apple.com wrote: For reference desktop webkit implementations will automatically increase the canvas backing store resolution as the device:css pixel ratio increases. --Oliver On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote: On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote: Hi again, I'm trying to keep the canvas bitmap at the same pixel resolution as the device, otherwise it is blurry. OK, I see. This, for example, works if the pixel ratio is 2. canvas style=width: 100px; height: 100px; width=200 height=200/canvas Yes, when the user has a zoom level set, I'd like to paint to match the pixel ratio, so that, a zoomed in user still receives crisp output, instead of blurry output. -webkit-device-pixel-ratio does not change when the user scaled the content; it is a device value. On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5 depending on it being a low, medium (160) or high dpi (240) device. On the iPhone 4 and the new iPod Touch it is 2.0. On Android devices, with for instance, a device-pixel-ratio of 1.5, you can disable the upscaling by adding target-densitydpi=device-dpi to the viewport meta tag. What you can do is to disable user scaling (add user-scaling=no to the viewport meta tag) and then handle zooming in your app using the touch events. This only works on mobile devices though. I haven't debugged with enough tablet devices, such as the color kindle, to know how many webkit distros it works with. What should I do about user zoom on the desktop (and possibly, the kindle) ? Drawing in high res, just-in-case, makes for a poorer experience for users at a 1.0 ratio, and asking users to slide a sharpen slider is a little awkward. Mozilla, in their implementation, has setup device-pixel-ratio to scale when the user scales content; they directly expose window css pixel ratio value to trusted scripts, but not to web content; requiring web content to use css device-pixel-ratio. Microsoft has exposed the values through window.screen. -Charles ___ 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] Canvas backing resolution
We do receive a resize event when zoom happens. That's what I'm currently hooked into. On Mar 4, 2011, at 12:29 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I guess that is not even possible, as I would need to subscribe to something like (-min-webkit-device-pixel-ratio: 1.0) and will only be notified in case the evaluation of that exact expression changes. Maybe that spec is lacking a way to subscribe to arbitrary changes in say device-pixel-ratio. It does feel a bit expensive, but then again we are only reevaluation after pinch end, so I guess that would be fully OK. Kenneth On Fri, Mar 4, 2011 at 9:02 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Hi Simon, I guess you could use the media query listener defined in http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface We support that on trunk now. This of course means that we will need to reevaluate the CSS when a pinch zoom ends, which we might be doing already given media queries such as @media all and (min-width: 200px). Cheers Kenneth On Fri, Mar 4, 2011 at 8:47 PM, Simon Fraser simon.fra...@apple.com wrote: On Mar 4, 2011, at 11:24 AM, Kenneth Rohde Christiansen wrote: Hey Oliver! If you are saying that device-pixel-ratio should include the user scaling, then I can push that for Qt, but I would really like seeing it supported by iOS as well for compatibility reasons. If you create a bug for that, please cc me. There's a problem with that, which is that the author can assume (possibly erroneously) that device-pixel-ratio doesn't change for the life of the page. However, the zoom level can change often, and there's no notification that the author can register for that will tell them when the zoom level changes, and thus when they'll need to redraw their canvas contents. Simon -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆ -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆ ___ 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] WebKit Inspector - Working with Breakpoints
On 3/3/2011 6:23 AM, Patrick Mueller wrote: On 3/2/11 4:25 PM, Charles Pritchard wrote: By enriched I mean: I'd like to be able to save and/or load breakpoints. So, you'd like to be able to save some set of breakpoints (all the ones currently enabled?) into a file, and be able to reload it later? This seems like a good candidate for a debugger extension, whenever that facility comes on line. Doesn't seem like it would be useful enough function to build into the base. And I'd like to be able to inject code into a breakpoint. Have you looked at the existing conditional breakpoint support? Right click over a breakpoint. I think this facility can be abused to do what you want. BTW, feel free to open bugs on these, of course: http://webkit.org/new-inspector-bug Thanks for pointing out the conditional breakpoints, I hadn't looked at them. They can be abused well enough -- I don't think I can inject a return; statement, but I can certainly fiddle with things. I'd like to be able to expose the breakpoints to the scripting environment, don't need to save it to a file if I can expose JSON to js. I'll keep an eye out for the debug extension facility. I'm happy with the progress webkit inspector has made. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit Inspector - Working with Breakpoints
I've used fiddler2 in some special cases, and it's really come in handy with experimenting on live sites. Fiddler2 just acts as a simple http proxy, to hijack requests to particular resources and redirect them to another location and/or local file. The breakpoints mechanism in WebKit inspector would actually serve me, for the majority of cases I've used fiddler2, if it were enriched. By enriched I mean: I'd like to be able to save and/or load breakpoints. And I'd like to be able to inject code into a breakpoint. That'd do it for me. With that option, I could easily put in callmyNewCode(); return; where'ever I need to do my code hacking. And I could also save that work, between sessions, so I can work with it later. Are there any interested parties/ideas/or prior discussions about this technique? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Bug 50126 - Fallback content in canvas element not focusable
It's been about two months, this bug is still unconfirmed. What's the appropriate venue for highlighting the issue? https://bugs.webkit.org/show_bug.cgi?id=50126 It's critical to accessibility within the Canvas shadow dom, and is required by ARIA. Also required in 7.3 of WAI-ARIA: http://www.w3.org/TR/wai-aria/host_languages . 1. Create an input type=form tag inside of a canvas tag. 2. Access it through getElementById and run .focus() on the element. [canvas] [input type=checkbox id=test /] [/canvas] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Canvas Issues: Ping
There are two canvas issues I'd like to see resolved ASAP: 1. Failing Philip's Canvas test: toDataURL.jpeg.alpha https://bugs.webkit.org/show_bug.cgi?id=40147 Related: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11431 http://trac.webkit.org/changeset/73173 This is a tricky issue, as mentioned by the comments in trac. No response from Mozilla: does apple have an opinion on this? IE9 seems to follow the spec. 2. Fallback content in canvas element not focusable https://bugs.webkit.org/show_bug.cgi?id=50126 An [input] tag inside of a canvas element: [canvas][input /][/canvas] should be able to receive .focus events and tabindex navigation. This is currently working in IE9, and likely works FF4. Thought I'd send up a flare. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment
Yes, I certainly understand that. Still hoping its something we could talk about here, and that Mozilla may have a change of mind. Currently, within WebKit Chromium, there's a very hackish way of calculating the zoom ratio, by comparing innerWidth and outerWidth . This only works when there is no side bar present. The innerWidth is returned in CSS pixels, the outerWidth in device pixels. I don't know if that's a bug or not. I've not been able to bring any discussion about unity in window.*Width implementations, as we're still stuck on CSS metrics. Here's the reasoning Mozilla has behind disallowing this information: https://bugzilla.mozilla.org/show_bug.cgi?id=486200 Their refusal is not about the feature itself, but about whether that feature would be exposed to untrusted scripts outside of an extension context. I don't want Web authors to have easy access to information about screen pixels. They'll try to defeat our zooming or size things to screen pixels, which we don't want. ( Robert O'Callahan ). The accessibility costs of withholding this information are very real. Mozilla's plan is to limit such information to media queries in CSS: the very hackish result of this would mean a dozen or so css declarations, calibrated for the Mozilla browser environment, then some JS to pull through and see which media queries were active. A proprietary, ugly, approach in itself. I find it hard to accept that one man's decision to intentionally make things difficult would have such reaching and lasting consequences. On 11/27/2010 8:15 AM, Adam Barth wrote: As a general rule, if Mozilla refuses to implement a feature, we're unlikely to implement the feature unless there is a very compelling reason to do so. Proprietary features are harmful to the web, which is why we prefer to discuss new features in standards bodies. Adam On Sat, Nov 27, 2010 at 3:08 AM, Charles Pritchardch...@jumis.com wrote: The whatwg thread had no outcome other than the response of Mozilla reiterating their prior conclusion. I've posted to WebKit for further feedback. I don't see what broad base might develop within whatwg. In all pragmatic aspects, webkit-dev seems to me the appropriate forum. Moz has stated clearly, repeatedly, that they do not wish to make the information easily accessible. This conclusion was made prior to my defect report and was unaltered by it. As of this date, I do not believe any webkit contributors have voiced their opinion. I'd prefer to focus on the technical aspects and likelihood of adoption. I'm posting to webkit, as I like to see this issue resolved within the webkit code base. -Charles On Nov 26, 2010, at 10:13 PM, James Robinsonjam...@google.com wrote: Are you posting here because there is something specific to WebKit in your query or because you dislike the outcome of the WHATWG thread? Most of us follow the WHATWG closely and generally prefer to discuss standardization issues such as this in that forum to get a broader feedback base. - James On Friday, November 26, 2010, Charles Pritchardch...@jumis.com wrote: Recently I brought this issue up to the WHATWG mailing list, without much luck. Currently, mobile devices are given access to window.devicePixelRatio, used for managing what are essentially higher resolution displays. See the iPhone, Android, etc. Within the desktop environment, devicePixelRatio is not updated on zoom events. I don't think it should be, but it's something to consider. Such information is critical to adjusting the resolution of bitmaps, be they from an image source or a canvas source, to be as crisp as can be. Microsoft has gone ahead in IE9 and just exposed a collection of metrics data: deviceXDPI, logicalXDPI, systemXDPI and Y counterparts. Source: http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspxhttp://msdn.microsoft.com/en-us/library/ms535868%28VS.85%29.aspx The task at hand is deciding whether or not to expose this information, and where. Technically, it's quite simple, as it's only a few floating point values which are already available to the WebKit environment. Zoom events always trigger a 'resize' event for window, as they alter the innerWidth and innerHeight of the layout. That resize event is the point in which the scripting environment would check to see if CSS pixel metrics have changed, and adjust the page accordingly. I want to note, that I am not speaking at all about changing how zoom works, or in any way suggesting that zoom be controlled by the scripting environment / web authors. I am recommending that we take a look at Microsoft's .screen extensions, and decide whether they hold merit, and may be included in WebKit. Doing so would mean that an independent implementation has picked up the extension, and it may be on the fast track for standardization. I had a rough time bringing this up with Mozilla. I'm hoping for a little more focus here, on this mailing list. Again,
Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment
I agree, it's a power struggle, not a technical issue, at this point. The use cases/defect is technical, but the solution is stuck entirely on politics. Circling back to rendering... Roc's suggestion of altering the standard behavior of the Canvas element is on topic: he'd like to resize the canvas backing store to match css pixels when a canvas element is reinitialized. I believe this would be a non-standard behavior, one which would change how ImageData works. I'm certainly participating in the standard bodies. I'll keep pushing the issue there. I am trying to develop some consensus between vendors to unify some existing API behaviors. At this point, I don't have the bandwidth to directly fix bugs, but I've been doing my best to file them and draw developers attention to them. It's been working very well, which has led me to greater enthusiasm toward WebKit. -Charles On 11/27/2010 10:34 AM, Adam Barth wrote: I usually avoid issues related to rendering, but this discussion sounds more like a power struggle than a technical issue. Roc's comments sound like he doesn't think web sites should have zoom-specific behaviors, whereas you seem interested in implementing zoom-specific behavior. One of the benefits of the standards process is that they sort out these kinds of arm-wrestling matches. This list is more focused on the nuts and bolts of WebKit development. For example, the recent thread about how, architecturally, we should use mock objects for testing is more on-topic than a thread about a specific feature request. I don't mean to be off-putting. I'm glad that you share our enthusiasm for WebKit specifically and the web more generally. If you're interested in contributing to WebKit, a good place to start is by fixing bugs. If you're interested in shaping the direction of the web platform, I'd encourage you to do that by participating in standards bodies. Adam On Sat, Nov 27, 2010 at 10:19 AM, Charles Pritchardch...@jumis.com wrote: Yes, I certainly understand that. Still hoping its something we could talk about here, and that Mozilla may have a change of mind. Currently, within WebKit Chromium, there's a very hackish way of calculating the zoom ratio, by comparing innerWidth and outerWidth . This only works when there is no side bar present. The innerWidth is returned in CSS pixels, the outerWidth in device pixels. I don't know if that's a bug or not. I've not been able to bring any discussion about unity in window.*Width implementations, as we're still stuck on CSS metrics. Here's the reasoning Mozilla has behind disallowing this information: https://bugzilla.mozilla.org/show_bug.cgi?id=486200 Their refusal is not about the feature itself, but about whether that feature would be exposed to untrusted scripts outside of an extension context. I don't want Web authors to have easy access to information about screen pixels. They'll try to defeat our zooming or size things to screen pixels, which we don't want. ( Robert O'Callahan ). The accessibility costs of withholding this information are very real. Mozilla's plan is to limit such information to media queries in CSS: the very hackish result of this would mean a dozen or so css declarations, calibrated for the Mozilla browser environment, then some JS to pull through and see which media queries were active. A proprietary, ugly, approach in itself. I find it hard to accept that one man's decision to intentionally make things difficult would have such reaching and lasting consequences. On 11/27/2010 8:15 AM, Adam Barth wrote: As a general rule, if Mozilla refuses to implement a feature, we're unlikely to implement the feature unless there is a very compelling reason to do so. Proprietary features are harmful to the web, which is why we prefer to discuss new features in standards bodies. Adam On Sat, Nov 27, 2010 at 3:08 AM, Charles Pritchardch...@jumis.com wrote: The whatwg thread had no outcome other than the response of Mozilla reiterating their prior conclusion. I've posted to WebKit for further feedback. I don't see what broad base might develop within whatwg. In all pragmatic aspects, webkit-dev seems to me the appropriate forum. Moz has stated clearly, repeatedly, that they do not wish to make the information easily accessible. This conclusion was made prior to my defect report and was unaltered by it. As of this date, I do not believe any webkit contributors have voiced their opinion. I'd prefer to focus on the technical aspects and likelihood of adoption. I'm posting to webkit, as I like to see this issue resolved within the webkit code base. -Charles On Nov 26, 2010, at 10:13 PM, James Robinsonjam...@google.comwrote: Are you posting here because there is something specific to WebKit in your query or because you dislike the outcome of the WHATWG thread? Most of us follow the WHATWG closely and generally prefer to discuss standardization issues such as this in that forum to get a
Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment
Looks like I'm digging myself deeper into a hole here. I'm running this issue through the W3C per your suggestions. I'll open up an item in the bug tracker if / when there's movement in the specs. Thanks all. -Charles On 11/27/2010 10:46 AM, Julian Reschke wrote: Charles, I recommend that you follow up in a W3C mailing list/issue tracker. Best regards, Julian On 27.11.2010 02:16, Charles Pritchard wrote: Recently I brought this issue up to the WHATWG mailing list, without much luck. Currently, mobile devices are given access to window.devicePixelRatio, used for managing what are essentially higher resolution displays. See the iPhone, Android, etc. Within the desktop environment, devicePixelRatio is not updated on zoom events. I don't think it should be, but it's something to consider. Such information is critical to adjusting the resolution of bitmaps, be they from an image source or a canvas source, to be as crisp as can be. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Exposing CSS pixel metrics to the scripting environment
Recently I brought this issue up to the WHATWG mailing list, without much luck. Currently, mobile devices are given access to window.devicePixelRatio, used for managing what are essentially higher resolution displays. See the iPhone, Android, etc. Within the desktop environment, devicePixelRatio is not updated on zoom events. I don't think it should be, but it's something to consider. Such information is critical to adjusting the resolution of bitmaps, be they from an image source or a canvas source, to be as crisp as can be. Microsoft has gone ahead in IE9 and just exposed a collection of metrics data: deviceXDPI, logicalXDPI, systemXDPI and Y counterparts. Source: http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms535868%28VS.85%29.aspx The task at hand is deciding whether or not to expose this information, and where. Technically, it's quite simple, as it's only a few floating point values which are already available to the WebKit environment. Zoom events always trigger a 'resize' event for window, as they alter the innerWidth and innerHeight of the layout. That resize event is the point in which the scripting environment would check to see if CSS pixel metrics have changed, and adjust the page accordingly. I want to note, that I am not speaking at all about changing how zoom works, or in any way suggesting that zoom be controlled by the scripting environment / web authors. I am recommending that we take a look at Microsoft's .screen extensions, and decide whether they hold merit, and may be included in WebKit. Doing so would mean that an independent implementation has picked up the extension, and it may be on the fast track for standardization. I had a rough time bringing this up with Mozilla. I'm hoping for a little more focus here, on this mailing list. Again, I'm merely looking to have CSS pixel metrics exposed, and I'm suggesting the MS proposal as it's certain to exist in their upcoming IE9 release. Their proposal exposes six floating point variables in the window.screen object, and is sufficient for current needs. Please let me know thoughts on the matter, and try to keep focused on the fact that we're just looking to expose a few floating points to the scripting environment, we're not looking to change any existing behaviors in any existing elements. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
