construct-stylesheets
Playwright
construct-stylesheets | Playwright | |
---|---|---|
7 | 381 | |
138 | 61,799 | |
0.0% | 1.5% | |
0.0 | 9.9 | |
over 1 year ago | 7 days ago | |
Bikeshed | TypeScript | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
construct-stylesheets
-
Safari releases are development hell
> With adoptedStyleSheets they're objecting to making backwards incompatible changes
Which would not be bacwards incompatible if they hadn't shipped something that wasn't agreed on in the first place.
Again, slowly: they literally shipped that to production despite loud and explicit objecitons from both Firefox and Safari they shipped it to production. When asked to hide it back behind the flag, "but backwards incompatible change, the framework we're developing is already depending on it"
And since you're quoting rniwa, here's the relevant quote https://github.com/WICG/construct-stylesheets/issues/45#issu...:
--- start quote ---
I feel like I’ve put so much time & energy into making this feature something sane & useful, and all you did was basically to dismiss many of my feedbacks and go with whatever you like and just ship it. And now you’re saying you can’t make changes because you shipped it?
I’m sorry but that’s just not how standards work.
--- end quote ---
> With WebMIDI they're saying they want to do an announcement before making the change.
Indeed. Once again: because they shipped an API that neither Safari nor Mozilla supported. Now that this issue has surfaced (no thanks to Chrome), they can't just roll it back or fix it because people already rely ono this behaviour, which the implicitly acknowledge.
-
W3C re-launched as a public-interest non-profit organization
It's not true, to w3c's surprising credit.
What Google does, is publish a "draft" which is as far from a standard as their authors are from the Moon. This gives Chrome the leeway to call it an "emerging standard" and just ship it. It doesn't care if there are objections, or that other browser vendors will not implement it. It's now a "standard" in Google's dictionary.
For something to become a W3C standard even in the present world, you need a consensus and at least two independent implementations. None of that exists for stuff Google pushes out (hardware APIs, web transport, constructible stylesheets [1], the list goes on...).
The correct name for those is Chrome-only non-standards.
[1] These one isn't even a draft. It is.... "a collection of interesting ideas" in a working group https://wicg.github.io/construct-stylesheets/ Shipped by default in Chrome, of course
-
SQLite WASM in the Browser Backed by the Origin Private File System
I literally provided just some of the examples. Those are easily verifiable.
Web Transport is shipped by default. What was the input from other browser?
Here's the timeline for HID: https://github.com/mozilla/standards-positions/issues/459#is...
Constructible Stylesheets: the spec contained a trivially reproducible race condition, the API was badly specified. Google shipped against any objections and refused to bring it back under the flag. Full discussion here: https://github.com/WICG/construct-stylesheets/issues/45. Shipped in Chrome https://github.com/WICG/construct-stylesheets/issues/45#issu... (may be hidden on mobile) despite multiple unresolved issues. Two years later Chrome did add a better API that people originally requested, other issues potentially remain.
-
Apple Is Not Defending Browser Engine Choice
> If there are examples of 'Apple ignoring standards' actually meaning Chrome-only features please tell me one.
Easy.
The most obvious/glaring one is WebHID. Enjoy the timeline: https://github.com/mozilla/standards-positions/issues/459
It's not just HID, of course. All/most of the hardware APIs are considered harmful by both Safari and Mozilla. Chrome is shipping them enabled by default, and there's no end to clueless developers maoning about this and calling Safari (mostly) and Firefox (from time to time) too slow in "moving the web forward". Needless to say that all those non-standards are pushed forward by Chrome.
The less obvious one is Constructable Stylesheets.
The spec had an obvious flaw that could lead to easily reproducible deadlocks. And that is on top with other issues with design, API naming etc. A team within Google (lit-html) wanted this feature, so Chrome shipped it against clear objections from both Safari and Firefox. And then refused to move the feature back under a flag because "0.8% of page views in Chrome" were suddenly using this feature. And proceded to gaslight other browsers' developers https://github.com/WICG/construct-stylesheets/issues/45. See e.g. a response to that https://github.com/WICG/construct-stylesheets/issues/45#issu... Of course there's now a "looking ahead" that wants to do exactly what Safari and Mozilla wanted to do in the first place: https://web.dev/constructable-stylesheets/#looking-ahead
In general, Chrome pushes 40 to over 100 new Web APIs with each release (that is, every two months). How many of them are actual standards that had actual input from other browser developers? In how many Chrome actually listened and implemented suggestions? https://web-confluence.appspot.com/#!/confluence
-
“Safari's buggy” is valid criticism. “Safari's behind Chrome in features” is not
> The negatives are often theoretical
They are not theoretical. Too bad webapicontroversy.com has been shut down (it looked like this [1]), but you can scroll down to "defer" and "considered harmful" in Mozilla's positions here: [2]
There are more, of course, but they are not visible unless you're willing to follow thousands of issues across hundreds of GitHub repositories. One that springs to mind is, of course Constructible Stylesheets. Mozilla and Safari: the spec describes an algorithm that leads to deadlock in trivial code, we wont implement it until this is fixed. [3] Chrome: ship it, because lit-html (developed by Google) wants it and is already using it. And then procedes to gaslight people and misrepresent their positions (cant' find the relevant link, but at this point I can't find the will to dive into the cesspool).
[1] https://user-images.githubusercontent.com/32768/108985355-3f...
[2] https://mozilla.github.io/standards-positions/
[3] https://github.com/WICG/construct-stylesheets/issues/45#issu...
Playwright
-
Typed E2E test IDs
We start with a project that was bootstrapped with npx create-next-app. For the E2E test we use Playwright and set it up as described in the testing guide provided by Next.js.
-
Playwright Scraping infinite loading & pagination
Playwright is a powerful tool developed by Microsoft, it allows developers to write reliable end-to-end tests and perform browser automation tasks with ease. What sets Playwright apart is its ability to work seamlessly across multiple browsers (Chrome, Firefox, and WebKit), it provides a consistent and efficient way to interact with web pages, extract data, and automate repetitive tasks. Moreover, it supports various programming languages such as Node.js, Python, Java, and .NET, that’s making it a versatile choice for web scraping projects. Whether you're scraping public data for analysis, building a web crawler, or automating manual workflows, Playwright has you covered.
-
Sometimes things simply don't work
The consensus I could gather is either use playwright or use a workaround to solve it in the puppeteer layer. The root cause of the bug is a websocket size limitation on the CDP protocol for chromium.
-
The best testing strategies for frontends
With the advent of tools like Puppeteer and now Playwright, end-to-end testing has become much easier and more reliable. For anyone who's used Selenium in the past, you know what I'm talking about. Puppeteer has opened the way in terms of E2E tooling, but Playwright has taken it to the next level and made it easier to await for certain selectors or conditions to be fulfilled (via locators), thus making tests more reliable and less flaky. Also, it's a game changer that it introduced a test-runner - this made the integration between the headless browser and the actual test code much smoother.
-
Playwright Web Scraping 2024 - Tutorial
In this tutorial, our main focus will be on Playwright web scraping. So what is Playwright? It’s a handy framework created by Microsoft. It's known for making web interactions more streamlined and works reliably with all the latest browsers like WebKit, Chromium, and Firefox. You can also run tests in headless or headed mode and emulate native mobile environments like Google Chrome for Android and Mobile Safari.
-
The best testing setup for frontends, with Playwright and NextJS
// playwright.config.ts import { defineConfig } from "@playwright/test"; /** * See https://playwright.dev/docs/test-configuration. */ export default defineConfig({ testDir: "./src/pages", reporter: "list", use: { baseURL: "http://localhost:5432/", }, timeout: process.env.CI ? 10000 : 4000, // ... more options });
-
✍️Testing in Storybook
Issues with Playwright
-
Episode 24/14: Angular Query, New Template Syntax
Fast and reliable end-to-end testing for modern web apps | Playwright
-
Adding standalone or "one off" scripts to your Playwright suite
This means you cannot place test files outside of this directory, which was brought up as a question on Github some time ago. Initially, I thought it would be nice to add another folder in the repo called "scripts", but Playwright does not allow multiple testDir values.
-
Learn Automated Testing At Home: A Beginner's Guide
4.Playwright: Playwright is a browser automation library by Microsoft. Key Features: Supports Chromium, Firefox, and WebKit. Provides cross-browser testing capabilities. Allows automating web, mobile, and desktop applications
What are some alternatives?
interop - web-platform-tests Interop project
WebdriverIO - Next-gen browser and mobile automation test framework for Node.js
file-system-access - Expose the file system on the user’s device, so Web apps can interoperate with the user’s native applications.
undetected-chromedriver - Custom Selenium Chromedriver | Zero-Config | Passes ALL bot mitigation systems (like Distil / Imperva/ Datadadome / CloudFlare IUAM)
fs - File System Standard
TestCafe - A Node.js tool to automate end-to-end web testing.
absurd-sql - sqlite3 in ur indexeddb (hopefully a better backend soon)
nightwatch - Integrated end-to-end testing framework written in Node.js and using W3C Webdriver API. Developed at @browserstack
OSX-KVM - Run macOS on QEMU/KVM. With OpenCore + Monterey + Ventura + Sonoma support now! Only commercial (paid) support is available now to avoid spammy issues. No Mac system is required.
Cypress - Fast, easy and reliable testing for anything that runs in a browser.
topics - The Topics API
playwright-python - Python version of the Playwright testing and automation library.