HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
web-platform-tests
wpt
HTML2013–2026
web-platform-tests / wpt

wpt

Test suites for Web platform specs — including WHATWG, W3C, and others

Web DevelopmentLearning & ReferenceTesting & QualityAutomation & Workflows
Explore on GitHubRead Hacker News discussions
29Distinct people
39Mentions
0Explicit recommenders
6.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Test suites for Web platform specs — including WHATWG, W3C, and others

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year39 dated mentions

Observed mentions: 2013-07-02 16:20:57 UTC to 2026-09-15 06:36:52 UTC.

02468102013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC202
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC202
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC404
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC909
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC404

What Hacker News says

39 sources
byteface·Sep 15, 2026
I'm building a Python Browser and need your help running agents on conformance tests https://github.com/byteface/chromonic/ cd to tests/layout.. git clone --depth=1 https://github.com/web-platform-tests/wpt.git tell it to run the tests and fix any issues with layout and append any issues with domonic into the PLAN.md I'm targetting the CSS2 folder atm.. so you can tell it to switch to any folder within there for now. Thanks,
In Ask HN: What are you working on? (September 2026)
nicoburns·Sep 8, 2026
> what is the process of making a browser engine? what does the requirements look like I second https://browser.engineering as a resource on that. Also consider dropping into the Servo Zulip. > how is an actual html, css and javascript specification implemented at the code level? are we painting an empty canvas or is it more complicated It's more complicated, but conceptually it's painting into an empty canvas > how is backward compatibility implemented? > what test cases do you consider for making something like this? how do you determine if you have handled all the outliers or not? The ~2 million Web Platform Tests https://github.com/web-platform-tests/wpt. They also handle most of the backwards compatibility. The rest is engine developers manually comparing against each other's engines. > is all the code written in c++ or is it rust th
Read the rest
ese days? There's still a lot of C++, but new code is increasingly Rust. To what degree varies by engine: Servo (and Blitz) are almost entirely Rust. Ladybird was 100% C++ in February, but is now 25% Rust. Firefox has significant and actively developed core components in Rust, but isn't actively converting more core modules. Chromium doesn't have any core components in Rust yet, but has invested heavily in converting foundational dependencies like FreeType and HarfBuzz to Rust. Safari is the outlier, I believe it doesn't use any Rust yet. > how many people in a team do you need and how long would it take to write a browser engine from scratch I've heard estimates that Chrome has a team of >1000, Firefox 500-800, Safari 100-200, Servo / Ladybird are more like 5-10. I've been building Blitz by myself for ~3 years. Something like 3-5 years is probably a minimum if you're truly building from scratch unless you have a really large team backing it, and depending on your success criteria. > how is mobile vs desktop handled at the browser engine code level? There are actually surprisingly few differences beyond touch input and screen size handling.
In This Month in Ladybird – August 2026
timhigins·Aug 1, 2026
Acid3 is 100 tests but to have a browser that works on any real percentage of the internet you need to pass the over 52000 tests and nearly two million subtests [1] that make up the Web Platform Tests [2] This is like the difference between a college degree and passing a spelling test. 1. https://servo.org/blog/2023/07/20/servo-web-platform-tests/ 2. https://github.com/web-platform-tests/wpt Not to mention this site is clearly vibe coded and has a vague call to action and no source code available thus indicating possible vaporware.
In Show HN: I worked on a new browser for 2 years, today it passed Acid 3
gsnedders·Mar 22, 2024
To reply mostly with my WPT Core Team hat off, mostly summarising the history of how we've ended up here: A build script used by significant swaths of the test suite is almost certainly out; it turns out people like being able to edit the tests they're actually running. (We _do_ have some build scripts — but they're mostly just mechanically generating lots of similar tests. A lot of the goal of WPT (and the HTML Test Suite, which it effectively grew out of) has been to have a test suite that browsers are actually running in CI: historically, most standards test suites haven't been particularly amenable to automation (often a lot of, or exclusively, manual tests, little concern for flakiness, etc.), and with a lot of policy choices that effectively made browser vendors choose to write tests for themselves and not add new tests to the share
Read the rest
d test suite: if you make it notably harder to write tests for the shared test suite, most engineers at a given vendor are simply going to not bother. As such, there's a lot of hesitancy towards anything that regresses the developer experience for browser engineers (and realistically, browser engineers, by virtue of sheer number, are the ones who are writing the most tests for web technologies). That said, there are probably ways we could make things better: a decent number of tests for things like Grid use check-layout-th.js (e.g., https://github.com/web-platform-tests/wpt/blob/f763dd7d7b7ed...). One could definitely imagine a world in which these are a test type of their own, and the test logic (in check-layout-th.js) can be rewritten in a custom test harness to do the same comparisons in an implementation without any JS support. The other challenge for things like Taffy only targeting flexbox and grid is we're unlikely to add any easy way to distinguish tests which are testing interactions with other layout features (`position: absolute` comes to mind!). My suggestion would probably be to start with an issue at https://github.com/web-platform-tests/rfcs/issues, describing the rough constraints, and potentially with one or two possible solutions.
In Show HN: Dropflow, a CSS layout engine for node or
nicoburns·Apr 11, 2023
We have our own test suite (orginally derived from the test suite of Meta's Yoga layout library [0]) which consists of text fixtures that are small HTML snippets [1] and a test harness [2] that turns those into runnable tests, utilising headless chrome both to parse the HTML and to generate the assertions based on the layout that Chrome renders (so we are effectively comparing our implementation against Chrome). We currently have 686 generated tests (covering both Flexbox and CSS Grid). We would like to run the Web Platform Test suite [3] against Taffy, however these are not in a standard format and many of the tests require JavaScript so we are not currently able to do that. [0]: https://github.com/facebook/yoga [1]: https://github.com/DioxusLabs/taffy/tree/main/test_fixtures [2]: https://github.com/DioxusLabs/taffy/tree/main/scripts/gen
Read the rest
tes... [3]: https://github.com/web-platform-tests/wpt/tree/master/css/cs...
In We're building a browser when it's supposed to be impossible
magicalist·Nov 15, 2021
> due to a bug in the testing framework the "bug" is https://github.com/web-platform-tests/wpt/issues/31147 MacOS 11 isn't allowed(?) to be virtualized, so the Safari TP, which is tied to MacOS updates, couldn't be updated. > That's why there's uproar Was there an uproar? There were some objections from some Safari devs that they understood the difficulty in getting the latest number since the web platform test runner can't run the latest Safari Tech Preview (which they've also known for some time), but since the whole point of this was to show how browsers have improved their compatibility on this set of tests, it was hurtful and counterproductive to leave out their latest work. Chrome devs apologized and now we have this article, and it looks like the test runner will start running WebKitGTK for this set of tests so at least the Compat
Read the rest
2021 dashboard[1] will show the latest results. [1] https://wpt.fyi/compat2021?feature=summary
In Sorry Safari Team
pornel·Aug 1, 2021
HTTP/1 is deceptive, because you think "oh, I'll just read RFC 2616, make a state machine, and I'm done!". But then writing a browser-compatible HTTP/1 client is a whole another bag of problems that weren't even documented until recently. For example, Content-Length isn't just a single header with an integer, like the spec says. You need to support responses with multiple Content-Length headers and comma-separated lists of potentially contradictory lengths, and then perform garbage error-recovery the way Internet Explorer or Chrome did. Getting this wrong will make your client hang, consume garbage, or allow response stuffing. https://github.com/web-platform-tests/wpt/pull/10548/files This problem does not exist in HTTP/2.
In Show HN: Micro HTTP server in 22 lines of C
dmitriid·Jul 31, 2021
> Exactly, it's impossible to describe that in human language which doesn't have precise enough semantics. On the contrary, this implements specs that are defined in a human language. For example, the full semantics of rendering HTML were standardised with HTML5, and now all browsers render HTML the same way. The problem isn't the human language. The problem is the sheer number of these specs. Hundreds, if not thousands. However, good luck understanding these specs by reading code or unit tests (and yes, there's a multitude of tests [1]). How do you know what a piece of code encodes? Or a test tests? You really propose to reverse engineer behaviour from code? Example: here's a test: https://github.com/web-platform-tests/wpt/blob/master/html/s... What exactly does it test? Why? Is this a correct test for this behaviour? Care to pinpoint th
Read the rest
e exact precise location of this spec in Google Chrome's code? [2] It's only 12 or so million lines of code, should be easy to find. > The goal should be to move chromium away from being controlled too much by Google. By doing what exactly? [1] https://web-platform-tests.org [2] https://github.com/chromium/chromium
In Firefox lost 50M users since 2019
jakub_g·Jun 17, 2021
IMO the issue here is that: everything that is not carefully specified as a precise algorithm, will be implemented differently. This is why each browser used to parse HTML differently. This is why you'd have compat or even security issues because some software used \r\n for newlines splitting while other used \n. Luckily the browser vendors formed WHATWG which created pretty precise specs which are maybe convoluted but at least everyone parses HTML in the same way, and each browser pretends to be every other browser for compatibility. 2021 is really great for web compat, maybe not all browsers implement every API, but existing APIs are accompanied by very thorough test suites (Web Platform Tests): https://github.com/web-platform-tests/wpt Live results from nightly builds: https://wpt.fyi/results/?label=experimental&label=master&ali... Ha
Read the rest
ving said that I don't see vendors aligning on definition on word count any soon due to corporate inertia, lack of incentives and lack of "Word editors consortium" (or is there any?) A truly good function for word count might be pretty complex, and perhaps different for every language.
In Boring Problems Need Attention Too
jgraham·Jun 15, 2021
Hi, I work on web-platform-tests. I'm not really sure I follow your complaint, so I wonder if there's a point of misunderstanding. The tests written for DOM APIs certainly require running javascript to execute the test — that's a given — but most of the rendering tests are reftests. These consist of two files, one using the feature under test and one avoiding that feature [1]. The test passes when the two renderings are identical. That does make these tests difficult to run "by hand", but in terms of implementation it's possible to automate in anything that's capable of rendering to an image. Reftests are preferred over comparing rendering to a fixed image because fixed images tend to be invalidated due to unrelated/permitted changes in the rendering (e.g. a different font or different antialiasing choices). These will typically apply to
Read the rest
both test and reference and so are handled automatically. Reftests obviously aren't suitable to bootstrap getting very basic things working, so there are some manual tests; I suppose one could hope to avoid that by inventing a special kind of output inspection automation just for those basic tests, but it's hard to justify. IN general, however, the "the ability to point my software at some .html files, get some failures, add more implementation, get less failures, and repeat" is exactly what wpt offers. There is some work required to stand up the necessary infrastructure to run the tests automatically, but it's common for new implementations of the platform to make use of web-platform-tests (e.g. Servo and Flow have both made use of wpt). In terms of coverage it's very difficult to demonstrate that all the requirements of a spec, and all its interactions with other specs, are completely covered. There have been various proposals for adding test metadata to try to measure coverage, but these have largely proved impractical. Nevertheless some CSS specs have links from the spec to the relevant test cases. And if you find cases that aren't covered by exisitng tests it would be great to get a PR to add new tests [2] [1] https://web-platform-tests.org/writing-tests/reftests.html [2] https://github.com/web-platform-tests/wpt
In IndexedDB is completely broken in latest Safari

Showing the 15 most recent of 39 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.