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

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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM 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

9 sources
> 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
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
> 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
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
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
This is a fun learning project, but I don't think it's really a browser except in name. The code seems to implement the behavior someone thinks a browser might have, not what the specs actually say. Ex. https://github.com/danfragoso/thdwb/blob/655eac96e4faa141cb4... That's not an html parser. It's just some code that regexes strings looking for brackets. Projects like this are good ways to learn and have fun, but they're many years away from being a browser, even if we limit the scope to the specs of say 2012. Also fwiw, if you're implementing a browser use the web platform tests instead of writing your own: https://github.com/web-platform-tests/wpt
In The Hotdog web browser and browser engine

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.