Re: [webkit-dev] Testing XHR

them. The only reason the W3C is not hosting this test suite at the moment is because they cannot handle server-side scripts on the test server at the moment. PLH is looking into a solution on their side as I understand things. -- Anne van Kesteren http://annevankesteren.nl

Re: [webkit-dev] XHR responseArrayBuffer attribute

on changes to the specification really ought to happen on public-weba...@w3.org. Cheers, -- Anne van Kesteren http://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Vendor Prefixing, was Re: New feature announcement - Implement HTML5 Microdata in WebKit

FWIW, Opera is planning to ship this unprefixed. http://dev.opera.com/articles/view/microdata-and-the-microdata-dom-api/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore and ES6

In general I think versioning is a bad idea, but out-of-band is even worse. We'd have to change Web Workers (both constructors and importScripts() would need to take some kind version-related information) and everyone on the platform would instead of simply using script have to resort back to

[webkit-dev] DOM methods that affect [[Prototype]]

Hi, https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 could use input from the WebKit community, in particular DOM/JavaScript experts. I recommend reading through http://lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg143 and

Re: [webkit-dev] DOM methods that affect [[Prototype]]

On Fri, Jan 25, 2013 at 12:21 AM, Geoffrey Garen gga...@apple.com wrote: Anne, can you help me get those comments sent to the w3 list? I sent them myself, but they seem to be held up or bounced? Hey, I think they did make it, and Boris replied:

Re: [webkit-dev] Enabling HTMLTemplateElement by default

On Wed, Nov 20, 2013 at 9:20 AM, Ryosuke Niwa rn...@webkit.org wrote: HTMLTemplateElement has been shipped by Chrome and Firefox for a while and the specification has been quite stable at this point: http://www.w3.org/TR/html-templates/ That specification has issues and is effectively

Re: [webkit-dev] CORS and user credentials prompting

On Mon, May 19, 2014 at 10:33 AM, youenn fablet youe...@gmail.com wrote: While looking at http://webkit.org/b/126619, a question came to my mind on user credentials prompting for cross-origin resources. WebKit allows prompting users for credentials in case of loading cross-origin resources

Re: [webkit-dev] Implement Geometry Interfaces

On Fri, Jun 13, 2014 at 9:53 AM, Ryosuke Niwa rn...@webkit.org wrote: I think Phil and Ben are suggesting to implement these types in JSC like we did for typed arrays. If you were to do that you probably want to ping TC39 this time around. -- http://annevankesteren.nl/

Re: [webkit-dev] Implement Geometry Interfaces

On Fri, Jun 13, 2014 at 10:12 AM, Ryosuke Niwa rn...@webkit.org wrote: What I'm saying is that we can implement it in JavaScriptCore for performance and we still make it look like a regular DOM object with wrappers to preserve the semantics. I understand that, but given that it is in the

Re: [webkit-dev] Implement Geometry Interfaces

On Fri, Jun 13, 2014 at 10:32 AM, Ryosuke Niwa rn...@webkit.org wrote: I understand your concern and sentiment but I'm having a hard time imagining what kind of problems/concerns would TC39 have with these interfaces that are clearly prefixed with DOM. That if they end up as objects in

Re: [webkit-dev] SIMD support in JavaScript

Could this thread maybe be moved to es-discuss? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Streams API

On Fri, Oct 31, 2014 at 9:07 AM, Benjamin Poulain benja...@webkit.org wrote: Any opinion for or against Streams? Do you know if Mozilla intends to implement it? I'm in favor of having IO streams :-) There's so many features that could be made better by having them. I don't think anyone from

Re: [webkit-dev] Streams API

On Sun, Nov 2, 2014 at 2:56 PM, youenn fablet youe...@gmail.com wrote: Meaning that only the fetch API would at some point support streams? If so, I wonder why we should postpone a small but useful feature to a nice but future API. I suspect there will be many APIs that support streams. It's

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

On Fri, May 22, 2015 at 1:50 PM, Gyuyoung Kim gyuyoung@webkit.org wrote: I also don't want to support the content handler feature at the moment. The feature might be more clear and mature. The patch of Bug 92749 only supports registerProtocolHandler, and unregisterProtocolHandler and

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

On Fri, May 22, 2015 at 6:43 PM, Gyuyoung Kim gyuyoung@webkit.org wrote: Current implementation doesn't hook to HTML's navigation directly. We delegate the html navigation(or call native application) to application. Application is able to decide to navigate the given html page or execute

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

On Fri, May 22, 2015 at 1:25 AM, Anders Carlsson ander...@apple.com wrote: Sam Weinig 2015-05-15 10:12:54 PDT: Support for navigator.registerProtocolHandler/unregisterProtocolHandler is not something we want to support in WebKit2 at this time as we are not confident it is a good Web API.

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

On Fri, May 22, 2015 at 12:26 PM, Maciej Stachowiak m...@apple.com wrote: (I am more dubious of the content handler aspect.) Agreed, especially as it requires the service to download the resource again. For that use case we need something smarter where you can pass along an object/stream of

[webkit-dev] Removal of mediagroup/MediaController from HTML

Hi, The WHATWG is considering removing mediagroup/MediaController from HTML, since other than WebKit no browser project has expressed interest in this feature. https://github.com/whatwg/html/issues/192 is the corresponding issue. I would recommend following up in the issue itself if this is

Re: [webkit-dev] First stab at exporting tests to WPT

On Wed, Mar 22, 2017 at 3:55 PM, Alexandre GOUAILLARD wrote: > that s great to have now chrome AND webkit doing it. I hope mozilla and the > other will follow, as discussed on the side of BlinkOn last year. FWIW, Mozilla already periodically synchronizes with WPT. Think we

Re: [webkit-dev] Another WPT bite

On Tue, May 9, 2017 at 8:27 PM, Simon Fraser wrote: > I'm also concerned that with 4 vendors upstreaming their WPT tests, the WPT > repo will just become a morass of partially overlapping tests that takes 4x > longer to run than a curated repo. Why do you think WPT is not

Re: [webkit-dev] Another WPT bite

On Fri, May 12, 2017 at 11:49 PM, Maciej Stachowiak wrote: > It seems like there's two unusual things about WPT: > - At least according to Alexey, WPT tests are somewhat prone to flakiness in > Safari. Although they haven't always been working perfectly, changes to

Re: [webkit-dev] Another WPT bite

On Fri, May 12, 2017 at 6:46 AM, Simon Fraser wrote: > I was under the impression that tests upstreamed from vendor repositories > would land in WPT tests > with minimal review, based on the fact that they had been reviewed when > landed in the vendor repo. I think

Re: [webkit-dev] Another WPT bite

On Sun, May 14, 2017 at 8:24 AM, Maciej Stachowiak wrote: > For the engineer use case, we can make a command-line tool to launch the > server and load the test. But it's kind of sad that in ~95% of cases, the > only value provided by the server is resolving the path to

Re: [webkit-dev] Another WPT bite

On Tue, May 16, 2017 at 5:45 AM, Ryosuke Niwa wrote: >> I think the main problem with not running a server is that behavior >> for file URLs is not defined. And browsers tend to impose different >> restrictions there. So you might end up debugging something only to >> later

Re: [webkit-dev] Another WPT bite

On Tue, May 16, 2017 at 7:29 AM, Ryosuke Niwa wrote: > Given we're talking about how these tests are ran inside WebKit, > whether there is an agreement about this or not is sort of irrelevant. > If a test doesn't run as expected, we can run it inside a HTTP server. I was just

Re: [webkit-dev] Where do we put WPT tests to be exported

On Fri, May 19, 2017 at 5:11 PM, youenn fablet wrote: > When a spec gets updated, the WPT tests will ideally be updated at the same > time. > The updated tests will no longer ensure non-regression until the browser > implements the new behavior. Ideally if importing test

Re: [webkit-dev] Touch Bar Web API

On Tue, Oct 24, 2017 at 8:46 PM, Aishwarya Nirmal wrote: > I am working on a Touch Bar Web API that would allow websites to customize > touch bar controls. There is currently no web standard for an interface like > the touch bar, so my plan is to experiment with this feature

Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

On Thu, Apr 26, 2018 at 12:30 PM, Ricky Young wrote: > I read the report and still find it hard to understand, if "User Agent > sniffing is a terrible way to determine whether a browser supports certain > features", what is the correct way of doing it?

Re: [webkit-dev] HSTS user tracking

On Thu, Mar 1, 2018 at 7:44 PM, Michael Catanzaro wrote: > It'd still be great to get some details about your strategy for mitigating > user tracking via HSTS. FWIW, some were posted by John Wilander at

Re: [webkit-dev] Request for position on the Origin-Isolation header

On Fri, Aug 21, 2020 at 2:41 AM Ryosuke Niwa wrote: > I feel like I saw some discussions of also differentiating based on > protocol (treating http://webkit.org and https://webkit.org > differently). Do you know you've already had such a discussion and if > so what the outcome of that discussion

Re: [webkit-dev] Request for Position: Cross-Origin-Resource-Blocking (CORB)

On Wed, Mar 23, 2022 at 6:19 PM Patrick Griffis via webkit-dev wrote: > I'd like a position on CORB and intend to implement it in the future. > This is already part of the Fetch Standard[0] and should be relatively > straightforward. > > It effectively blocks cross-origin requests for resources

Re: [webkit-dev] Nicks in contributors.json

On Mon, Oct 24, 2022 at 11:07 PM Darin Adler wrote: > If they were consistently the Slack nicknames. But they often aren’t! The > nicknames currently in there don’t necessarily match the Slack ones and > obviously don’t match the GitHub account names. I wish these were more > explicit about

[webkit-dev] Nicks in contributors.json

Heya, Now that GitHub needs are addressed through a github field in contributors.json and WebKit moved from IRC to Slack, is there still a need for the nicks field? Based on a suggestion on Slack I'm thinking of removing it from https://webkit.org/team/ and I might as well clean up

[webkit-dev] Collaborating on standards-positions

Heya, I would like to propose a lightweight process so we can jointly arrive on position: labels on https://github.com/WebKit/standards-positions that can then be considered somewhat final, modulo new information coming to light. Agreeing on these positions as a community is important as they

Re: [webkit-dev] Unsigned to avoid negative values

On Tue, Jan 24, 2023 at 11:00 AM Myles Maxfield via webkit-dev wrote: > What do you think? What this immediately made me think of is that Web IDL and the web platform at large use unsigned and signed integers of various types. And as those have different value spaces you'd notice if you do

[webkit-dev] Removal of trailing whitespace

To reduce the overhead of switching between projects with different whitespace requirements, I would like to suggest we start being lenient when trailing whitespace is removed. In particular when a file is being changed to fix a bug. I could see going even further and enforcing this via the style

Re: [webkit-dev] Removal of trailing whitespace

On Wed, Apr 12, 2023 at 7:20 PM Yusuke Suzuki via webkit-dev wrote: > I agree that we should not do it because it pollutes change history of files, > git-blame results, and review-diff in PR. > But at the same time, I think there is no reason to add a new trailing > whitespace via a new commit.

Re: [webkit-dev] maybe_unused vs UNUSED_PARAM

I had a [[fallthrough]] patch, but internal C code got in the way: - https://en.cppreference.com/w/c/language/attributes/fallthrough - https://bugs.webkit.org/show_bug.cgi?id=265789 Using them directly where we can seems nice for (new) readers of the code at least. Not sure what a macro for

Re: [webkit-dev] Intent to Ship Sec-CH-UA-Form-Factor client hint in Blink

On Wed, Feb 21, 2024 at 4:19 PM Dustin Mitchell via webkit-dev wrote: > We are working to ship a new client hint, form-factor, in Blink. Please let > us know if you have any questions or comments. > > You can check the following documents for details: > * >