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
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:
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
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
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,
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
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
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
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,
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
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
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
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:
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
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
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
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,
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.
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
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
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
://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
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
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
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
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
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
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
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
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
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;
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
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
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,
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
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
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
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
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
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:
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
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
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
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
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,
45 matches
Mail list logo
