A long long long long long time ago, in Talk.CSS #52, Gao Wei presented a talk on Bézier curves "The Obscurities of Bézier Curves Explained to My Computer Engineer Friends". She showed uses of Bézier curves in user interface animations, some rather interesting history about it and explained the mathematics behind it. Watch the meetup on Engineers.SG!
I prefer to have this with sound, can someone ah please do a [visualisation] using wavelength and then you can like mmm-MMMMM-mmmm. Then ya easier for me to understand I need to hear. (46:06)
So, a long long long long long time later, I forked Lea Verou's repository and added a checkbox to enable sounds. You can try it out here. Should I make a pull request? 😂
Have fun annoying others in your office with the help of Bézier curves!
A lot of our Internet depends on domain names. It's the one source we rely on for verifying authenticity of a website. HTTPS/TLS relies upon users checking the domain of the link they click. I really doubt most users will do so.
This is why Chromium has written guidelines for presenting URLs correctly, to reduce the ability of attacker to present to users a trustworthy-looking URL. There is also an extended document in Chromium source code. However, Chrome hasn't implemented it yet. Disappointing...
Using long URLs that confuse and mislead users is one thing, but someone paying slight attention to the URL may notice. An attacker can go even further by obtaining domains that remove a dot or replace a dot with a dash. Most organisations will not spend the effort to buy up all these variations of their domain, therefore it's possible to register one of them and
Recently, as I was scrolling Twitter, I came across this tweet:
The page he links to demonstrates a very simple vulnerability that is frequently overlooked. This is the source code from his sample modified for brevity:
At first glance, most will dismiss this as secure due to the escaping performed. However, HTML links are able to execute JavaScript with the javascript: prefix. This is perfectly fine text and will not get escaped by htmlspecialchars. An example of attack input in the above code will be when link is set to javascript:alert(1).
This is frequently overlooked because it is uncommon for link
Caddy is a easy-to-use web server and reverse proxy. You can use it to enable HTTPS on your self-hosted app with little effort.
To start off, first download caddy for your platform. Place the executable in a nice folder. We'll call that your working directory.
Now in the same folder, you will need to write a Caddyfile, which is just a text file. Open your text editor and paste this:
:2015 {
proxy / localhost:8080
}
Save it as Caddyfile without any file extension.
This will start a normal HTTP server at port 2015 and proxy all requests to your app at port 8080.
Now, in the terminal or command prompt, cd into the working directory and run Caddy. On Windows you would type caddy.exe and on macOS or Linux ./caddy
You can now visit localhost:2015 to check that everything works.
Next, you have to get a domain to point to your server. You can get free domains from freenom.tk, or use your dynamic DNS provider. You can test that your domain works by visiting your-domain.com:2015 over mobile
SVG line animations are awesome. Having images look as if they are being drawn, live, has a nice effect. CSS-Tricks has a nice article on creating line animations.
While working on a project, I came across this bug in the handling of negative stroke-dashoffset in Safari and Firefox. Here's a pen I forked from Chris Coyier:
The first one is an animation from stroke-dashoffsets: 0; to stroke-dashoffsets: 820; whereas the second animates to stroke-dashoffsets: -820;. Here's how it renders in Chrome:
You'd expect the lines to start undrawn, right? But here's how it renders in Safari (and Firefox):
Pretty unconventional behaviour, right? To make matters worse, let's reduce the dash lengths. Here's Chrome again:
Safari and Firefox doesn't even make the lines continuous, it loops them for every length of the dash:
A quick Google search does not reveal any bug reports, except for multiple stackoverflow.com answers. So I de
When messing with screen blending, I came across a bug in Chrome and Firefox when using screen blending with transform animations. Surprisingly, Safari rendered it right.
This is when you get when applying mix-blending-mode: screen; on an <img> with position: absolute;, so as to stack it on another element. Of course, this doesn't work in Edge.
When using CSS animations, browsers switch to GPU acceleration to provide smooth animations. But when using GPU acceleration, transparent backgrounds are "lost", and the renderer interprets background-color: transparent; as black. Since we are using mix-blend-mode: screen; where black is used to make cutouts, the whole area on the page