On Apr 4, 2013, at 4:54 PM, Per Bothner per.both...@oracle.com wrote:
On 04/04/2013 10:21 AM, Oliver Hunt wrote:
Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the
On Mar 26, 2013, at 2:34 PM, Jarred Nicholls jar...@webkit.org wrote:
On Tue, Mar 26, 2013 at 5:17 PM, Jesus Sanchez-Palencia je...@webkit.org
wrote:
2013/3/26 Ryosuke Niwa rn...@webkit.org:
On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo fpi...@apple.com wrote:
On Mar 26, 2013, at 1:40
On Mar 21, 2013, at 5:38 PM, Glenn Adams gl...@skynav.com wrote:
On Thu, Mar 21, 2013 at 6:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Mar 21, 2013 at 5:10 PM, Glenn Adams gl...@skynav.com wrote:
On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Mar
On Mar 19, 2013, at 11:12 AM, Geoffrey Garen gga...@apple.com wrote:
In case it's not clear from this message (and my previous messages), I
object to this change.
Your objections seem to pertain to CSP. I've excluded CSP from the proposal.
Do you still object in some way? If so, why?
On Mar 15, 2013, at 1:19 AM, Gregg Tavares g...@google.com wrote:
I don't understand the opposition to alpha
You set colors in Canvas2d with rgb or rgba. That 'a' in rgba stands for
alpha.
You can set a global alpha for drawing with context.globalAlpha
You read data from getImageData
An attribute on the canvas element would presumably be equally applicable to
all contexts. Is there a reason that it's better to have opaqueness specified
at context creation time instead of on the canvas? Also, I think opaque is
easier to understand than alpha: false.
- Maciej
On Mar 13,
and it
doesn't make much sense to reinvent the wheel when one context type
has already implemented the functionality.
--Brandon
On Wed, Mar 13, 2013 at 1:02 PM, Maciej Stachowiak m...@apple.com
wrote:
An attribute on the canvas element would presumably be equally
On Mar 13, 2013, at 9:49 PM, Gregg Tavares g...@google.com wrote:
On Wed, Mar 13, 2013 at 9:20 PM, Maciej Stachowiak m...@apple.com wrote:
Two questions/comments:
1) What happens if I do:
gl = canvas.getContext(experimental-webgl, { alpha: false });
and then later
patches before commit.
This topic was discussed on the webkit-security mailing list in May
2010. Unfortunately, the archives of that list are not viewable
publicly. Maciej's concerns at the time are summaries in his message
below:
On Tue, Oct 19, 2010 at 6:16 PM, Maciej Stachowiak m
On Mar 11, 2013, at 9:07 PM, Peter Kasting pkast...@google.com wrote:
On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig shezbaig...@gmail.com wrote:
I feel like I should give some background to this discussion.
Thanks for this context. It's helpful.
So I guess the question boils down to
On Mar 9, 2013, at 3:05 PM, Adam Barth aba...@webkit.org wrote:
In retrospect, I think what I was reacting to was msaboff statement
that an unnamed group of people had decided that the HTML tokenizer
was too unwieldy to have a dedicated 8-bit path. In particular, it's
unclear to me who
Dashboard widgets.
Regards,
Maciej
Thanks,
Adam
On Fri, Mar 1, 2013 at 4:57 PM, Maciej Stachowiak m...@apple.com wrote:
I think we'll want to take these out for Apple ports as soon as we can check
prevalence in older Apple-specific content (e.g. Dashboard widgets).
On Fri, Mar 1
On Mar 9, 2013, at 8:00 PM, Adam Barth aba...@webkit.org wrote:
On Sat, Mar 9, 2013 at 5:02 PM, Maciej Stachowiak m...@apple.com wrote:
My recommendation would be:
* Do one of the following two options:
- Plan A: Rename -webkit-dashboard-region to -apple-dashboard-region
I think we'll want to take these out for Apple ports as soon as we can check
prevalence in older Apple-specific content (e.g. Dashboard widgets).
- Maciej
On Feb 28, 2013, at 6:02 PM, Adam Barth aba...@webkit.org wrote:
I noticed this comment on the Hacker News thread about Paul Irish's
I think Adam's old plan for the Platform directory was to migrate from
WebCore/platform piece-by-piece, starting with related groups of classes that
are already free of layering violations. That seems like a sensible approach to
me as it allows the work to happen incrementally.
- Maciej
On
I support this feature addition.
- Maciej
On Feb 21, 2013, at 10:12 AM, Victor Carbune vcarb...@chromium.org wrote:
Hi everyone,
This is a heads-up that we are starting to extend WebVTT with features
included in the unofficial draft WebVTT Extension: Regions for
rendering cue groups
On Feb 17, 2013, at 1:09 AM, Filip Pizlo fpi...@apple.com wrote:
On Feb 17, 2013, at 1:04 AM, Dirk Schulze dschu...@adobe.com wrote:
The discussion on each single feature let us forget the greater scope of
this problem. That is why I did not start with a concrete example.
What about
On Feb 17, 2013, at 3:02 PM, Dirk Schulze dschu...@adobe.com wrote:
On Feb 17, 2013, at 9:16 AM, Adam Barth aba...@webkit.org wrote:
On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze dschu...@adobe.com wrote:
Then we should face it. Prefixed content for CSS gradients, animation,
later.
I'm also glad to see efforts like
https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing
on a simpler git workflow. :)
Thanks again for running the survey.
On Sat, Apr 7, 2012 at 4:58 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 22, 2012, at 9:16 PM, Adam Barth
On Feb 16, 2013, at 10:16 PM, Dirk Schulze dschu...@adobe.com wrote:
On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org wrote:
It's much easier to discuss a concrete example. Which interface are
you interested in deprecating?
I can understand that it is easier to discuss on a
Welcome to the WebKit community! Opera has a long and impressive history of
pushing the Web platform forward. I look forward to working together to advance
the Web; I think it's a great opportunity for all of us.
Regards,
Maciej
On Feb 13, 2013, at 12:06 AM, Håkon Wium Lie howc...@opera.com
On Feb 12, 2013, at 8:28 AM, Zeno Albisser z...@webkit.org wrote:
On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen kbal...@webkit.org wrote:
You also need IPC because the NetworkProcess serves the needs of the web
process. Could you describe why a network thread in the UI process fit your
On Feb 11, 2013, at 1:34 PM, Kevin Ollivier kev...@theolliviers.com wrote:
On Feb 11, 2013, at 12:27 PM, Benjamin Poulain wrote:
On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.com
wrote:
I actually have recently been working on a patch to get trunk building
Here is a list all iOS-specific changes in WebCore and below that are due to
the iOS WebKit threading model, from an exhaustive review of diffs to the
downstream source. I'm not sure anyone needs this to make a decision any more,
but it may be helpful to people to know what's coming as we
On Feb 10, 2013, at 10:48 AM, Adam Barth aba...@webkit.org wrote:
Ok. I'm sold. I suspect we'll want to move the iOS port off of
USE(WEB_THREAD), but I can see how it's better to do that work in trunk.
We definitely want to get off the web thread over time. There's two paths by
which
On Feb 10, 2013, at 5:14 PM, Brent Fulgham bfulg...@gmail.com wrote:
Hi Maciej,
Thank you for taking the time to clearly enumerate these different tasks. It
must have been a tedious effort, but I think the list is quite helpful in
understanding the changes you are proposing.
1. The
On Feb 9, 2013, at 10:11 AM, Adam Barth aba...@webkit.org wrote:
On Fri, Feb 8, 2013 at 8:19 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 8, 2013, at 2:33 PM, Darin Fisher da...@chromium.org wrote:
I would recommend minimizing the re-architecture of WebCore as you are in
the early
On Feb 9, 2013, at 3:01 PM, James Robinson jam...@google.com wrote:
On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote:
P.S. Running WebCore on interlocking threads is a needlessly scary way to
describe what iOS WebKit does. There is no complex fine-grained
Hi Peter,
On Feb 9, 2013, at 3:48 PM, Peter Kasting pkast...@google.com wrote:
On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote:
There are certainly pros and cons to merging. It would be great get input
from the broader WebKit community on the tradeoff of merging
On Feb 8, 2013, at 4:14 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer ddkil...@webkit.org wrote:
On Feb 8, 2013, at 2:52 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer ddkil...@webkit.org wrote:
The iOS port does
On Feb 8, 2013, at 4:48 PM, Adam Barth aba...@webkit.org wrote:
One simple example is V8, which stores the current v8::Isolate in
thread-local storage.
However, the problem is certainly not limited to V8, nor is it even
limited to the code we're using today. Running WebCore on multiple
On Feb 8, 2013, at 2:33 PM, Darin Fisher da...@chromium.org wrote:
If we'd taken an equally hard line when Google wanted to merge the Chromium
port to trunk, with a number of design choices in place that we didn't agree
with but which were hard to change, it probably still wouldn't be
I think we should continue to use uint8_t instead of char as the primary way to
represent a raw byte in WebKit. First, it's good to distinguish raw data from C
strings at the type system level, and second, the unpredictable signedness of
char is actively bad for byte-oriented processing.
On Feb 5, 2013, at 6:09 AM, Mark Mentovai m...@chromium.org wrote:
The parser (and the grammar) works the way it does because it’s just
Python—the whole thing can be slurped in quickly by the interpreter and made
available to GYP as data. It’s faster than a parser written in Python for a
On Feb 5, 2013, at 2:01 PM, Ryosuke Niwa rn...@webkit.org wrote:
Using a YAML-like syntax, we can rewrite it as:
XMLName:
inputs:
(SHARED_INTERMEDIATE_DIR)/../dom/make_names.pl
(SHARED_INTERMEDIATE_DIR)/../xml/xmlattrs.in
outputs:
XMLNames.cpp
On Feb 4, 2013, at 12:17 AM, Jochen Eisinger joc...@chromium.org wrote:
On Sun, Feb 3, 2013 at 7:29 AM, Benjamin Poulain benja...@webkit.org wrote:
On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel e...@webkit.org wrote:
What I've learned from this thread, is that AppleWin and AppleMac are the
On Feb 4, 2013, at 5:04 AM, Mike West mk...@chromium.org wrote:
Way back in the depths of 2010, Mihai suggested that we begin to throw
exceptions when accessing Location properties across origins[1]. Currently,
we log a Unsafe JavaScript attempt to access... message to the console, and
On Feb 4, 2013, at 10:46 AM, Mark Mentovai m...@chromium.org wrote:
GYP was written in Python to address point (b). Python was already part of
the baseline requirements on all platforms, so we already had Python
available everywhere we needed it. There are no dependencies on external
On Feb 2, 2013, at 10:44 PM, Eric Seidel e...@webkit.org wrote:
On Wed, Jan 30, 2013 at 1:57 PM, Maciej Stachowiak m...@apple.com wrote:
I wish WebCore was not trapped by Mac WebKit1’s legacy designs.
WebKit2 is obviously a step towards the future. But until we can kill the
Widget tree
On Feb 3, 2013, at 11:34 AM, noam.rosent...@nokia.com wrote:
On 2/3/13 7:46 PM, ext Maciej Stachowiak m...@apple.com wrote:
If you're asking about phasing it out entirely, we don't have any
immediate plans to deprecate or remove the WebKit1 mac API. There are
quite a few Apple
On Feb 3, 2013, at 11:58 AM, Adam Barth aba...@webkit.org wrote:
On Sun, Feb 3, 2013 at 11:46 AM, Adam Barth aba...@webkit.org wrote:
Yeah, another example is ResourceHandle, which is theoretically a
platform-agnostic abstraction but in reality is heavily constrained by
the capabilities of
On Feb 3, 2013, at 8:18 PM, Mike Lawther mikelawt...@chromium.org wrote:
Hi Maciej!
On 31 January 2013 11:15, Maciej Stachowiak m...@apple.com wrote:
It's far simplest for us if:
(a) There is an Xcode project (or a Makefile) that builds the Mac port
checked in to source control.
(b
On Jan 31, 2013, at 12:49 AM, Patrick Gansterer par...@paroga.com wrote:
Hi,
Am 31.01.2013 um 09:25 schrieb Mark Rowe:
Regarding (b) The generated project invokes only tools that are part
of the default Mac OS X install: invoking tools that are checked into
the WK repo is also possible,
On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote:
Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org wrote:
Another option is to add a webkit-patch command for modifying the build
files. That way, the
On Jan 30, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote:
On Tue, Jan 29, 2013 at 11:58 PM, Maciej Stachowiak m...@apple.com wrote:
I agree that the regression should be fixed. But before we discuss that...
I am puzzled by the apparent stance of Alexey must immediately fix
Hi Eric,
These are great thoughts. I agree with you on all points. One informative
comment below:
On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
I wish we only had one build system (it were easy to add/remove/move files).
I believe changes like
On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
Thanks for sharing this.
On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
I wish we only had one build system (it were easy to
On Jan 30, 2013, at 5:46 PM, Laszlo Gombos laszlo.gom...@gmail.com wrote:
Hi !
I'd also like to add that I think a key related issue to common build
system is common feature configuration. The many different ways ports
control their feature flags is super confusing. I've long wanted
On Jan 29, 2013, at 6:22 PM, Hajime Morrita morr...@chromium.org wrote:
Hi folks,
I'm going to implement Custom Elements standard behind
ENABLE(CUSTOM_ELEMENTS) flag.
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
For reference: will the feature flag be
On Jan 29, 2013, at 7:17 PM, James Robinson jam...@google.com wrote:
On Tue, Jan 29, 2013 at 6:29 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jan 29, 2013 at 5:46 PM, Adam Barth aba...@webkit.org wrote:
I understand that the new rules of the road for WebKit2 are that
contributors
On Jan 25, 2013, at 4:13 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jan 25, 2013, at 9:14 AM, Adam Barth aba...@webkit.org wrote:
On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze dschu...@adobe.com wrote:
This is a followup
On Jan 24, 2013, at 6:20 PM, Adam Barth aba...@webkit.org wrote:
Note that WebKit re-uses the same Document after a call to
document.open(). I suspect we're unlikely to change that behavior
anytime soon.
We also keep the same Window (which it sounds like IE doesn't, since that's
cited as
On Jan 22, 2013, at 12:17 AM, Sergio Villar Senin svil...@igalia.com wrote:
En 21/01/13 23:07, Maciej Stachowiak escribiu:
On Jan 21, 2013, at 11:23 AM, Adam Barth aba...@webkit.org wrote:
Thanks, Adam. It's fine to pick up the conversation later, and we're
certainly open to iterating
On Jan 22, 2013, at 12:32 AM, TAMURA, Kent tk...@chromium.org wrote:
The two mail threads bounce back and forth between Hixie's opinion and
yours. Was there a conclusion reached anywhere on what to do with datetime
and datetime-local?
We agreed that existing implementations of
On Jan 20, 2013, at 9:55 PM, TAMURA, Kent tk...@chromium.org wrote:
Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input
type=datetimeimplementation in your products.
What do you recommend for products that have shipped it already?
- Maciej
On Jan 21, 2013, at 11:23 AM, Adam Barth aba...@webkit.org wrote:
Some folks have pointed out to me off thread that I'm coming off as
angry and harsh. I would like to apologize for my tone.
My goal here is not to obstruct or block your progress on the
NetworkProcess. My goal is to end up
On Jan 20, 2013, at 1:44 PM, Adam Barth aba...@webkit.org wrote:
On Sun, Jan 20, 2013 at 1:30 PM, Oliver Hunt oli...@apple.com wrote:
I take your word for it that it's not possible on Windows.
Given that Chromium has many users on Windows (and other non-Mac
platforms), you should now
On Jan 19, 2013, at 8:56 AM, Takashi Toyoshima toyos...@chromium.org wrote:
Thank you everyone for your feedback.
We realize that adding a new API is something to be considered very
carefully and know that we need to get general WebKit buy-in before
proceeding with any development here.
On Jan 19, 2013, at 11:20 AM, noam.rosent...@nokia.com wrote:
From: ext Maciej Stachowiak m...@apple.com
Is this API useful in any way for users who do not have specialized and
somewhat uncommon hardware devices?
You don't need a particular hardware to play MIDI; only a sound card
Some questions:
- Are any other browser engines planning to implement this? (I couldn't tell
from looking at the public-au...@w3.org archives).
- Is this API useful in any way for users who do not have specialized and
somewhat uncommon hardware devices?
Regards,
Maciej
On Jan 18, 2013, at
/2013 19:51, Maciej Stachowiak wrote:
Some questions:
- Are any other browser engines planning to implement this? (I couldn't tell
from looking at the public-au...@w3.org archives).
- Is this API useful in any way for users who do not have specialized and
somewhat uncommon hardware devices
Does anyone still object in light of these updates, particularly Mozilla's
support for the feature?
Regards,
Maciej
On Jan 17, 2013, at 5:20 PM, James Craig jcr...@apple.com wrote:
IMO, the following represents enough evidence to land the patch as soon as
the last layout test failure is
I think it's fine to shoot it in the head now. We do still want to come back to
it eventually, but it's now apparent that we won't in the next 1.5 months.
- Maciej
On Jan 17, 2013, at 4:15 PM, Adam Barth aba...@webkit.org wrote:
Maciej has asked that we keep it around until the end of
Hi Adam,
You raise a number of interesting points which I'll try to address.
On Jan 12, 2013, at 1:14 AM, Adam Barth aba...@webkit.org wrote:
On Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak m...@apple.com wrote:
Do you think thread in the UI process vs. completely separate process
Hi Steve,
If you're interested in more complete SVG support, here are some things you can
do:
(1) File bugs for any missing features that don't have bugs already.
(2) Create a meta-bug for complete SVG 1.1 support or what have you that's
blocked by all the relevant feature bugs.
(3) Add
On Jan 11, 2013, at 2:53 PM, Adam Barth aba...@webkit.org wrote:
On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak m...@apple.com wrote:
On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote:
Is that really the case? If so, I'm surprised that the patches for
the shared memory
that I'll split into another thread.
Cheers,
Maciej
On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote:
On Thu, Jan 10, 2013 at 9:19 PM, Maciej Stachowiak m...@apple.com wrote:
On Jan 10, 2013, at 12:07 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jan 10, 2013 at 12:37 AM, Maciej
On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote:
If you're actually planning to make a significant complexity-imposing
architectural change for performance reasons, without any way to test
whether it delivers the claimed performance benefits, or how it compares to
less
I presume from your other comments that the goal of this work is
responsiveness, rather than page load speed as such. I'm excited about the
potential to improve responsiveness during page loading.
One question: what tests are you planning to use to validate whether this
approach achieves its
to be at TPAC and will
advocate for it.
I'll be also going to TPAC. I would appreciate your support.
On Mon, Oct 1, 2012 at 2:11 PM, Maciej Stachowiak m...@apple.com wrote:
Since TPAC is less than a month away, I don't understand why we can't wait
for that discussion. I do support
On Jan 10, 2013, at 12:07 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jan 10, 2013 at 12:37 AM, Maciej Stachowiak m...@apple.com wrote:
I presume from your other comments that the goal of this work is
responsiveness, rather than page load speed as such. I'm excited about
On Dec 21, 2012, at 3:06 PM, Elliott Sprehn espr...@chromium.org wrote:
On Fri, Dec 21, 2012 at 6:09 AM, Antti Koivisto koivi...@iki.fi wrote:
On Fri, Dec 21, 2012 at 3:33 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
No, it's just a refactoring on the CSS side, so we don't have to
repeat
On Dec 11, 2012, at 7:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Dec 11, 2012 at 7:20 PM, Elliott Sprehn espr...@chromium.org wrote:
Do you have an example of when this has occurred? It's good to have examples
if we want to prevent this in the future.
Yes. I'd rather not publicly
On Dec 7, 2012, at 7:30 AM, Rick Byers rby...@chromium.org wrote:
My goal is to have them visually remain the same size (because 1 CSS pixel
should still correspond to 1 device pixel, as DPR==1 for low-density
screens) along with the @media rules and -webkit-image-set elements (and
Would this involve creating a bindingsFoo() for every method foo() that is
exposed to bindings? For example, would we have to add
XMLHttpRequest::bindingsSend(), even though there's no real need for a special
internal XMLHttpRequest::send()? Would getters and setters that map to
JavaScript
On Dec 3, 2012, at 5:18 PM, Michael Nordman micha...@google.com wrote:
About MemCache considerations, you list these options...
* Do not share storage
* Share storage but hits in remote caches are asynchronous
* Share storage and all cache hits are serviced synchronously
Is there a fourth
On Nov 28, 2012, at 8:23 AM, Adam Barth aba...@webkit.org wrote:
It looks like this thread got dropped over Thanksgiving. (Responses inline.)
On Thu, Nov 22, 2012 at 1:43 PM, Benjamin Poulain benja...@webkit.org wrote:
On Wed, Nov 21, 2012 at 2:42 PM, Rick Byers rby...@chromium.org wrote:
On Nov 29, 2012, at 8:35 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Nov 29, 2012 at 7:32 PM, James Craig jcr...@apple.com wrote:
On Nov 29, 2012, at 7:10 PM, Ryosuke Niwa rn...@webkit.org wrote:
I don't see a harm in waiting another couple of weeks or months until
standards
On Nov 29, 2012, at 9:23 PM, Glenn Adams gl...@skynav.com wrote:
On Thu, Nov 29, 2012 at 10:00 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Nov 29, 2012 at 8:55 PM, Glenn Adams gl...@skynav.com wrote:
On Wed, Nov 28, 2012 at 1:31 PM, Rafael Weinstein rafa...@chromium.org
wrote:
On Nov 29, 2012, at 10:00 PM, Steve Faulkner faulkner.st...@gmail.com wrote:
maciej wrote:
The WHATWG has pretty clearly rejected the idea of the main element
can you point to a clear rejection in any of the relevant threads on
the WHATWG apart from hixies?
I would suggest the
without convincing the WHATWG community that the data, use cases etc
do not support the introduction of a feature, then the WHATWG process is
broken.
regards
SteveF
On 30 November 2012 06:18, Maciej Stachowiak m...@apple.com wrote:
On Nov 29, 2012, at 10:00 PM, Steve Faulkner faulkner.st
On Nov 29, 2012, at 10:46 PM, Michael[tm] Smith m...@w3.org wrote:
The only thing I see as likely to change things in the whatwg is
implementations appearing.
Yeah, and Hixie has said as much himself:
http://lists.w3.org/Archives/Public/www-archive/2012Nov/0041.html
as far as main
On Nov 27, 2012, at 8:39 PM, Brendan Eich bren...@mozilla.org wrote:
I'm stunned that people are arguing this on webkit-dev.
Just FYI, Mozillians with whom I have spoken generally agree that main does
not meet the high bar required to add a new element to HTML.
Shopping a patch to
Feature requests are off-topic for this mailing list (at least, if it's not a
feature you plan to implement yourself). This topic for this list is
development of WebKit.
Regards,
Maciej
On Nov 17, 2012, at 7:47 AM, sridharn sridhar.ndr...@gmail.com wrote:
Any updates / plans for this
On Nov 15, 2012, at 12:02 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Nov 14, 2012 at 11:37 PM, Chris Evans cev...@chromium.org wrote:
On Wed, Nov 14, 2012 at 10:29 PM, Ryosuke Niwa rn...@webkit.org wrote:
In other words, why are you interested in using the proposed allocation
On Nov 15, 2012, at 12:22 AM, Chris Evans cev...@chromium.org wrote:
On Wed, Nov 14, 2012 at 11:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 14, 2012, at 11:09 PM, Chris Evans cev...@chromium.org wrote:
On Wed, Nov 14, 2012 at 8:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed
On Nov 15, 2012, at 2:16 PM, Chris Evans cev...@chromium.org wrote:
On Thu, Nov 15, 2012 at 11:49 AM, Geoffrey Garen gga...@apple.com wrote:
On Nov 14, 2012, at 3:19 PM, Chris Evans cev...@chromium.org wrote:
A first step might be to make it a platform define. For the Chromium
platform
I had a few more thoughts on this email besides the fragmentation aspect.
On Nov 15, 2012, at 12:22 AM, Chris Evans cev...@chromium.org wrote:
It still seems to me like the key difference is vtable vs no vtable,
It's an important difference, but if we partitioned in to two based on that
On Nov 15, 2012, at 2:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Nov 15, 2012 at 2:16 PM, Chris Evans cev...@chromium.org wrote:
On Thu, Nov 15, 2012 at 11:49 AM, Geoffrey Garen gga...@apple.com wrote:
On Nov 14, 2012, at 3:19 PM, Chris Evans cev...@chromium.org wrote:
A first
On Nov 15, 2012, at 4:56 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Nov 15, 2012 at 4:28 PM, Mike Lawther mikelawt...@google.com wrote:
On 16 November 2012 09:59, Ryosuke Niwa rn...@webkit.org wrote:
While I don’t want to further agitate the issue or go off on a tangent, and
agree
On Nov 14, 2012, at 5:19 PM, Rik Cabanier caban...@gmail.com wrote:
I send the question to the fx list.
Tab Atkins brought up that we could extend the 'globalCompositeOperator' so
it also takes a comma separate list of a blend and a compositing operation.
Calling:
On Nov 14, 2012, at 9:59 PM, Adam Barth aba...@webkit.org wrote:
On Nov 14, 2012 8:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn espr...@chromium.org
wrote:
I was present for one of the discussions about the exploit and how an
arena
On Nov 14, 2012, at 10:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Nov 14, 2012 at 9:59 PM, Adam Barth aba...@webkit.org wrote:
On Nov 14, 2012 8:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn espr...@chromium.org
wrote:
I was
On Nov 14, 2012, at 10:36 PM, Elliott Sprehn espr...@chromium.org wrote:
On Thu, Nov 15, 2012 at 1:29 AM, Ryosuke Niwa rn...@webkit.org wrote:
...
In other words, why are you interested in using the proposed allocation
mechanism for only DOM nodes/objects instead of everything in
On Nov 14, 2012, at 11:09 PM, Chris Evans cev...@chromium.org wrote:
On Wed, Nov 14, 2012 at 8:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn espr...@chromium.org wrote:
I was present for one of the discussions about the exploit and how an arena
spec.
Regards,
Maciej
Rik
On Mon, Nov 12, 2012 at 3:46 PM, Rik Cabanier caban...@gmail.com wrote:
On Mon, Nov 12, 2012 at 12:14 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 11, 2012, at 9:06 PM, Rik Cabanier caban...@gmail.com wrote:
On Sun, Nov 11, 2012 at 8:43 PM
On Nov 13, 2012, at 10:23 PM, Eric Seidel e...@webkit.org wrote:
We're aware of multiple high-profile past WebKit exploits (including
the last $60,000-winning Pwnium 2 exploit) which would have been
defeated by a Slab-allocated DOM.
Some of RenderArena's basic assumptions are that no
On Nov 11, 2012, at 6:59 PM, Rik Cabanier caban...@gmail.com wrote:
Wouldn't it be better to add a new property to canvas for blending? At the
beginning, implementations are just require to use different blend modes in
combination with 'source-over'.
That could work too.
There
I don't think we should support this API in WebKit at this time, because:
* At least in its current form, it is overengineered and unusable. An animation
API should focus on ease of use, not combining every conceivable animation
concept ever invented.
* It hasn't even reached FPWD yet so it's
On Nov 5, 2012, at 5:07 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak m...@apple.com wrote:
Sounds like a good idea. Three additional thoughts:
(1) It would be best to choose the objects to apply this to in some
data-driven way.
Do you have
301 - 400 of 1378 matches
Mail list logo
