Re: [webkit-dev] Position on new syntax in mediaqueries-4

We are supportive. Much of the needed code was already written for the container queries (as you know) so implementation should be relatively easy. antti On Mon, Apr 11, 2022 at 1:57 PM Anders Hartvoll Ruud via webkit-dev < webkit-dev@lists.webkit.org> wrote: > For example, in

Re: [webkit-dev] in WebKit?

I landed the updated behavior. antti On Mon, Oct 19, 2020 at 11:29 AM Anders Hartvoll Ruud wrote: > Yes, there's css/selectors/is-where-error-recovery.tentative.html > > (.tentative tag to be dropped momentarily). > > On Sat, Oct 17, 2020 at 10:17 AM Antti Koivisto wrote:

Re: [webkit-dev] in WebKit?

Seems like a sensible change. Are there WPT tests for this behavior already? antti On Fri, Oct 16, 2020 at 8:06 PM Anders Hartvoll Ruud wrote: > Hi, > > We are about to ship support for :is() and :where() in Chromium, including > support for . >

Re: [webkit-dev] WebKit's position on @property

We like declarative @property and will definitely consider implementing it. We like CSS.registerProperty less since it is a performance footgun. antti On Fri, Apr 24, 2020 at 10:25 AM Anders Hartvoll Ruud wrote: > Thanks for the response. I did read through that issue at some point, but >

Re: [webkit-dev] [Styling] Space between [] and () in C++ lambdas

On Fri, Nov 1, 2019 at 10:50 PM Yusuke Suzuki wrote: > > > On Nov 1, 2019, at 11:53, Michael Catanzaro > wrote: > > > > On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa wrote: > >> Namely, some people write a lambda as: > >> auto x = [] () { } > >> with a space between [] and () while others

Re: [webkit-dev] Introducing WTF::makeUnique and WTF::makeUniqueWithoutFastMallocCheck

On Mon, Aug 19, 2019 at 10:25 AM Yusuke Suzuki wrote: > Hello WebKit folks! > > I would like to announce that I’ve just landed the patch which introduces > `WTF::makeUnique` and `WTF::makeUniqueWithoutFastMallocCheck` in > https://trac.webkit.org/changeset/248846. > They are drop-in-replacement

Re: [webkit-dev] Is anyone maintaining Nicosia scrolling code?

On Sat, Feb 23, 2019 at 1:30 PM wrote: > On Sat, Feb 23, 2019, at 2:47 AM, Simon Fraser wrote: > > There’s a bunch of code in Source/WebCore/page/scrolling/nicosia/ that > > I keep breaking with scrolling tree refactoring. Most of it it stubs. > > Is anyone maintaining this code, because it

Re: [webkit-dev] Rename AtomicString to AtomString

Sounds good to me. antti On Wed, Jan 30, 2019 at 6:33 PM Darin Adler wrote: > So, did we reach consensus that we should rename AtomicString to > AtomString? > > — Darin > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org >

Re: [webkit-dev] Watch out for std::optional's move constructor

On Tue, Dec 18, 2018 at 3:18 AM Geoffrey Garen wrote: > Again, the C++ standard does not say that moving from an object leaves the > object in an undefined state. > > The C++ standard does say: > > Objects of types defined in the C++ standard library may be moved from > (12.8). Move operations

Re: [webkit-dev] Removing support for CSS regions

This is a blocker for making the render tree more secure and for architectural progress there in general. The feature is extremely invasive and has design issues. I think the security benefits of removing it alone are worth taking a small regression risk. antti On Wed, Aug 2, 2017 at 10:00

Re: [webkit-dev] !!Tests for equality comparison

This is a good change as long as we are just relaxing the rule rather than mandating ==. I think ! makes a lot of sense when testing for emptiness: if (!container.size()) ... if (!count) ... but == should be used for testing things where 0 is just another number, like indexes: if (index

[webkit-dev] SVN trouble

Hi, Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some sort of SVN problem. Please hold commits until this is resolved. antti ___ webkit-dev mailing list webkit-dev@lists.webkit.org

Re: [webkit-dev] WebCore/platform standalone library

Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a top-level namespace (even if it currently happens to live in the WebCore project)? #include would be more consistent with existing headers than . antti On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield

Re: [webkit-dev] Naming preference: SetForScope vs. TemporaryChange

On Mon, Dec 26, 2016 at 5:29 AM, Maciej Stachowiak wrote: > > ScopedChange(tachyonFlux, 2.0); > I wish there was a compiler warning against this. I have caused at least one bug by doing this exact thing. (a temporary gets deleted at the end of the expression) antti

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

I think the actual issue here was that std::chrono::duration can't represent infinite duration and some of our code has been hacking around that with std::chrono::duration::max(). Clock time + duration is not going to overflow if the duration is natural (a finite constant or produced by diffing

Re: [webkit-dev] Windows Build Now on VS2015

Does this mean we can start using (most) C++14 features? antti On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham bfulg...@apple.com wrote: Hi Floks, We’ve finished updating the various Windows builds to VS2015. Full regression tests are now completing on these new builds, and seem to be

Re: [webkit-dev] Filling the features.json files

On Wed, Apr 8, 2015 at 7:09 AM, Benjamin Poulain benja...@webkit.org wrote: Hi WebKit, The two features.json files are in the tree (WebCore/features.json and JavaScriptCore/features.json). The style checker now checks the basic structure of the files. Could you also explain what these

Re: [webkit-dev] WebCore/platform standalone library

Reusable Os Fitting Layer antti On Fri, Mar 20, 2015 at 11:26 AM, Simon Fraser simon.fra...@apple.com wrote: On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of

Re: [webkit-dev] WebKit Meeting: Network Cache session

I added link to the slide to https://trac.webkit.org/wiki/March%202015%20Meeting . antti On Tue, Mar 17, 2015 at 8:28 AM, Adam Bergkvist adam.bergkv...@ericsson.com wrote: Hi Perhaps I should have posted this to the webkit-meeting list, but it seems pretty dead. Anyways.. does anyone

Re: [webkit-dev] WorkQueue for Windows?

). - Anders On Mar 6, 2015, at 10:46 AM, Antti Koivisto koivi...@iki.fi wrote: Hi, I'd like to start using WTF::WorkQueue abstraction in WebCore code. However we are currently missing a Windows implementation (WorkQueue used to be part of WK2). Anyone interested in making one? I assume

[webkit-dev] WorkQueue for Windows?

Hi, I'd like to start using WTF::WorkQueue abstraction in WebCore code. However we are currently missing a Windows implementation (WorkQueue used to be part of WK2). Anyone interested in making one? I assume it wouldn't be a difficult task for someone who knows the platform. antti

[webkit-dev] virtual and override

We have traditionally marked virtual overrides with the 'virtual' keyword for documentation purposes. Nowadays we also have the compiler checked 'override'. Using both at the same time seems redundant. Should we change the coding style so that exactly one of the 'virtual' and 'override' must be

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

I don't think this is really 32bit vs 64bit platform issue. The vast majority of 64bit systems our users have (that is iOS devices) can't use memory buffers sized anywhere near the 32bit limit even in theory. Also when using Vector auto-grow capabilities (which is really the point of using a

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

Or Vector and ByteBuffer. All these cases requiring very large buffers seem to be about untyped data. antti On Thu, Nov 20, 2014 at 9:40 PM, Filip Pizlo fpi...@apple.com wrote: That looks like a pretty good performance win. I'd advocate for SmallVector and Vector, then. -Filip On

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

I agree with Phil, we should just use unsigned consistently. For very large memory allocations Vector is probably not the right type to use. antti On Wed, Nov 19, 2014 at 10:32 PM, Filip Pizlo fpi...@apple.com wrote: Whatever we do, the clients of Vector should be consistent about what type

Re: [webkit-dev] Networking process scope

On Mon, Nov 10, 2014 at 12:28 PM, youenn fablet youe...@gmail.com wrote: Hi, I looked at the Networking process recently and am wondering what is in scope/out of scope of this process. Currently, the networking process is used to load resources from: - URLs resolved using platform specific

Re: [webkit-dev] Disk cache

compiling it out requires no action. antti Alex On Oct 31, 2014, at 11:02 AM, Antti Koivisto koivi...@iki.fi wrote: Hello, I'm planning to add an experimental HTTP cache implementation to WebKit ( https://bugs.webkit.org/show_bug.cgi?id=30322). The main motivations are: - Improving

Re: [webkit-dev] Disk cache

On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos carlo...@webkit.org wrote: El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió: Hello, I'm planning to add an experimental HTTP cache implementation to WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322). Great news

[webkit-dev] Disk cache

Hello, I'm planning to add an experimental HTTP cache implementation to WebKit ( https://bugs.webkit.org/show_bug.cgi?id=30322). The main motivations are: - Improving performance by bringing the cache closer. For example we can serialize WebKit response objects directly instead of converting

Re: [webkit-dev] Keep ResourceBuffer?

Note that ResourceBuffer is virtual and wraps a ShareableResource on WebKit2 side. ShareableResource exists to do memory mapped IPC. The current factoring is confusing and cleaning this up is definitely a good idea. However it will require a bit more than just changing ResourceBuffers to

Re: [webkit-dev] Keep ResourceBuffer?

In that case remove away. Did I mention this code is confusing? antti On Thu, Oct 23, 2014 at 8:11 PM, Darin Adler da...@apple.com wrote: On Oct 23, 2014, at 10:13 AM, Antti Koivisto koivi...@iki.fi wrote: Note that ResourceBuffer is virtual and wraps a ShareableResource on WebKit2

[webkit-dev] Please avoid inheriting concrete types over WebCore/WebKit boundary

Hi, To make callbacks from WebCore to WebKit(2) we have generally used approach where WebCore exports an abstract client interface which is then implemented on the WebKit side. More recently there has been some proliferation of a pattern where we inherit directly from a concrete WebCore type and

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

Yes, let's remove the flag. It is too easy to break the no-SVG build and the guards uglify the code. antti On Wed, Jan 29, 2014 at 2:13 AM, Sam Weinig wei...@apple.com wrote: Hi Everyone, While we are discussing removing #ifdefs that everyone has enabled, I'd like to propose removing

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

On Mon, Jan 6, 2014 at 11:49 PM, Geoffrey Garen gga...@apple.com wrote: (2) ApplyStyleCommand.cpp: auto children = elementChildren(*dummySpanAncestor); for (auto child = children.begin(), end = children.end(); child != end; ++child) { *if

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

On Fri, Jan 3, 2014 at 9:28 PM, Geoffrey Garen gga...@apple.com wrote: I strongly object to varying coding style arbitrarily based on author or project file. That's a recipe for an unreadable polyglot codebase. I wasn't advocating a general coding style free-for-all. I imagine there could be

Re: [webkit-dev] When to use auto? (I usually consider it harmful)

On Thu, Jan 2, 2014 at 11:12 PM, Geoffrey Garen gga...@apple.com wrote: Hi folks. Recently, I’ve seen patches go by using the C++11 “auto” keyword. For example, let me pick on Andreas: http://trac.webkit.org/changeset/161143 +auto newRenderer = textNode.createTextRenderer(style);

Re: [webkit-dev] The SrcN responsive images proposal

On Tue, Oct 22, 2013 at 11:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of data-* attributes are not parsed. attributes on the element to look for things

Re: [webkit-dev] The SrcN responsive images proposal

Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. antti On Sun, Oct 20, 2013 at 4:00 AM, Maciej Stachowiak m...@apple.com wrote:

Re: [webkit-dev] The SrcN responsive images proposal

On Sun, Oct 20, 2013 at 11:08 PM, Benjamin Poulain benja...@webkit.orgwrote: On 10/20/13, 9:07 AM, Antti Koivisto wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty

Re: [webkit-dev] Proposal: remove style scoped

I think it is a feature that we may want to have sooner or later. We will probably want to change the implementation quite a bit though and removing the dead code for now makes sense. antti On Thu, Sep 26, 2013 at 3:42 PM, Benjamin Poulain benja...@webkit.orgwrote: Dear WebKit, We have

[webkit-dev] Removing DIALOG_ELEMENT for now

We current have an incomplete, unmaintained implementation of the HTML5 dialog element in our code base. No one is building it as far as I can see and it has bit-rotted to the point it probably wouldn't work anyway. I think we should remove the code for now. It should be possible to come up with

Re: [webkit-dev] Ref counting questions

TreeShared is essentially an implementation detail of the DOM tree (the only other client besides Node is SVGElementInstance). It shouldn't be used for anything else. TreeShared keeps Nodes alive when they are part of a tree (have a parent node) even when they have zero refcount. This way nodes

Re: [webkit-dev] We should delete ENABLE_SHADOW_DOM

I think it would be better to remove this code in controlled pieces along with all the underlying implementation (which is mostly not behind the flag) rather than removing it wholesale. It is good to understand what we are removing and that gets difficult if the API level (the only thing

Re: [webkit-dev] What do we do with various Web component features?

I agree that we should remove most of the Shadow DOM related code (the portions supporting distribution especially). It is invasive, has significant architectural issues (including use of a confusing mutating iterator) and forces generic code many places where it would not be needed otherwise. It

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

On Sat, Apr 13, 2013 at 8:26 AM, Filip Pizlo fpi...@apple.com wrote: Also, you could do a libdispatch style, where there is no lock per se but instead you just have queues that you put tasks on. I like that, too. It's also formally equivalent to both locks and message queues, but much more

Re: [webkit-dev] StyleBuilder vs StyleResolver

On Fri, Apr 12, 2013 at 7:36 AM, Dirk Schulze dschu...@adobe.com wrote: Hi, The style of CSS properties is either set in StyleBuilder/CSSProperty or in StyleResolver (alias CSSStyleSelector). StyleResolver has a giant switch statement to handle all CSS property values and set the style. It

Re: [webkit-dev] StyleBuilder vs StyleResolver

On Fri, Apr 12, 2013 at 4:50 PM, Dirk Schulze dschu...@adobe.com wrote: On Apr 12, 2013, at 1:08 AM, Antti Koivisto koivi...@iki.fi wrote: On Fri, Apr 12, 2013 at 7:36 AM, Dirk Schulze dschu...@adobe.com wrote: Hi, The style of CSS properties is either set in StyleBuilder/CSSProperty

Re: [webkit-dev] AncestorChainWalker substance and style thoughts

The purpose of the NodeTraversal refactoring was simply to move the existing traversal functions off the (rather bloated) Node and add Element specific functions. I think longer term iterators are the way to go as they allow decoupling our internal document tree data structures from the DOM API.

Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

When loading web pages we are very frequently in a situation where we already have the source data (HTML text here but the same applies to preloaded Javascript, CSS, images, ...) and know we are likely to need it in soon, but can't actually utilize it for indeterminate time. This happens because

Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?

On Fri, Dec 21, 2012 at 3:33 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: No, it's just a refactoring on the CSS side, so we don't have to repeat a bunch of stuff every time we have an at-rule that contains other rules. It just makes the WebIDL easier and less error-prone. It seems bit

Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?

We already have internal type corresponding to the new CSSGroupingRule, StyleRuleBlock. Technically refactoring the CSSOM like this would be fairly trivial. It is not clear to me what value this new type adds though. In JS you don't really care if types have a common base as long as they share

Re: [webkit-dev] Prefix naming scheme for DOM-exposed functions

than for C++. Antti Koivisto and I have been discussing how to best communicate this to WebKit contributors so they don’t end up using inefficient idioms just because they are familiar with them from use in JavaScript code on websites. So far, our best idea for this is to add a prefix to function

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

On Wed, Oct 31, 2012 at 12:05 AM, Alexey Proskuryakov a...@apple.com wrote: This will mean that cache is always almost empty, and all resources in it are extremely fresh. I don't know if this would provide substantial additional test coverage over cleaning the cache all the time, or just

Re: [webkit-dev] On returning mutable pointers from const methods

I don't think the original proposal was meant to apply to the basic container types. Would this be a sensible rule to adopt for WebCore only for example? Like all our blanket rules, this one should be ignored when it doesn't make sense. If that kind of cases are expected to be very rare then

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

We could clear the cache between tests but run each test twice in a row. Second run will then happen with deterministically pre-populated cache. That would both make things more predictable and improve our test coverage for cached cases. Unfortunately it would also slow down testing significantly,

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

On Wed, Aug 8, 2012 at 9:54 PM, Eric U er...@google.com wrote: On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov a...@webkit.org wrote: I can see some downsides to emptying the cache before each test: - we won't be getting any test coverage for cache behavior when it hits non-trivial

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

On Fri, Oct 26, 2012 at 6:09 PM, Ami Fischman fisch...@chromium.org wrote: The reality is that this test coverage today shows up as flakiness and so is ignored anyway, meaning we don't actually have useful coverage here. Even when flakiness is investigated, the fix is to cache-bust using

Re: [webkit-dev] On returning mutable pointers from const methods

On Thu, Oct 25, 2012 at 1:48 PM, Andreas Kling kl...@webkit.org wrote: So, I propose that we allow only these two signature formats for raw pointers: - const Foo* foo() const; - Foo* foo(); I think this would be an excellent rule to adopt for new code. The mutable/immutable state pattern

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

On Tue, Oct 9, 2012 at 4:21 AM, Maciej Stachowiak m...@apple.com wrote: One preliminary finding of ours is that different web pages fairly often load identical resource bodies from different URLs. We expect possible benefits from sharing the body data of resources in memory even if we cannot

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth aba...@webkit.org wrote: This is interesting data, but it seems to be related to whether we should make the MemoryCache content addressable rather than whether we should use shared memory to back the MemoryCache when there are multiple WebProcesses.

Re: [webkit-dev] Eliminate potential null pointer dereference?

Sat, Apr 21, 2012 at 8:13 AM, John Yani van...@gmail.com wrote: 2316if (selector-relation() != CSSSelector::SubSelector) 2317break; 2318selector = selector-tagHistory(); 2319}; Now selector is null and we are trying to call tagHistory():

Re: [webkit-dev] How to use ASSERT_NO_EXCEPTION

On Thu, Dec 15, 2011 at 8:36 AM, Darin Adler da...@apple.com wrote: ExceptionCode ec; appendChild(newChild, ec); ASSERT(!ec); Often code like this indicates misuse of DOM API functions for internal purposes. This is inefficient (due to exception related checking and other spec

Re: [webkit-dev] Using C++ constant local variables in WebKit

On Thu, Dec 1, 2011 at 4:26 AM, Ojan Vafai o...@chromium.org wrote: I don't mind using const in some cases, but I share Darin's concern of littering the code with consts. I'd prefer that we come up with a fairly conservative guideline about when to use it. I'm not sure what that would look

Re: [webkit-dev] old-run-webkit-tests is officially deprecated.

On Fri, Oct 28, 2011 at 1:00 AM, Eric Seidel e...@webkit.org wrote: If you're still using old-run-webkit-tests for your work, I would *love* to know and fix any issues you may have with NRWT. The lack of locale independence is a showstopper for me,

Re: [webkit-dev] Compile-time assertions for object sizes

On Thu, Sep 29, 2011 at 9:40 PM, Andreas Kling kl...@webkit.org wrote: One idea is to add a file that would only be built on (for example) 64-bit Mac and then at least that bot would break if an object changes size. That's obviously not ideal though. I like that approach as it allows you to

Re: [webkit-dev] Implementing style scoped

On Fri, Sep 9, 2011 at 12:28 AM, Roland Steiner rolandstei...@chromium.orgwrote: ad 3.) Implementation of scoped selector matching works as follows: .) scoped style sheet rules are contained in a separate map scoping element address - RuleSet .) add a field to ParentStackFrame that

Re: [webkit-dev] Preload Scanner in WebKit

On Fri, Feb 11, 2011 at 9:11 AM, Adam Barth aba...@webkit.org wrote: We run the preload scanner when the regular parser is blocked on the network.  CSS and other sub-resources don't block the main parser whereas scripts do. If the main parser encounters an script tag (including inline scripts)

Re: [webkit-dev] beforeload link (esp rel prefetch)

2011/1/13 Darin Fisher da...@chromium.org: Supporting the Link header enables web servers to inject link tags without modifying the document, which can be useful, especially for intermediaries. That sounds like a great reason not to support this feature. Why would we want to make the web more

Re: [webkit-dev] HTML5 Web Links (RFC 5988)

Even for prefetching this seem rather worthless as it won't allow prefetching start significantly earlier over the resources specified in the document source. There is also (based on the experience in similar things) a high chance that whatever is listed in the Link header won't match what the

Re: [webkit-dev] Tightening up smart pointer usage rules

Is the plan also to banish the std::auto_ptr? It seems pointless and confusing to allow both the OwnPtr and the auto_ptr. antti (who wants PwnPtr too) On Mon, Jun 28, 2010 at 11:39 PM, Darin Adler da...@apple.com wrote: Hi folks. I’d like to use our smart pointers more consistently to

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt hy...@apple.com wrote: I really don't think hit testing needs to be modified to get what you want.   You can do a scattershot sampling using multiple candidate points within the rect and apply whatever heuristics you want to choose a node.  I'm

Re: [webkit-dev] PreloadScanner aggressiveness

On Fri, Jan 8, 2010 at 3:00 AM, Mike Belshe m...@belshe.com wrote: Nice testing! But for HTTP; the key seems to the pre-rendering-ready escape hatch in DocLoader::preload. Removing this gives me most all of the benefit. The comment says it pretty clearly: Don't preload images or body

Re: [webkit-dev] http cache support - rfc2616

WebKit implements significant parts of RFC 2616 caching logic for it's internal memory cache and will implement more. See https://bugs.webkit.org/show_bug.cgi?id=17998 for details. antti 2008/11/15 Darin Fisher [EMAIL PROTECTED]: The http caching logic for chromium lives here:

[webkit-dev] Windows build now requires QuickTime SDK

Hi, I just checked in the timed media support (video and audio) for Windows. This means that Windows build now depends on the QuickTime SDK which can be downloaded from here: http://developer.apple.com/quicktime/download/ Note that QuickTime itself is not required to build, just the SDK.