Working LEGO Combination Safe

I always wondered how these things worked. Nice!

(via @inferis)

Elsewhere , , Leave a comment

CSS Paint API (Houdini’s Paint Worklet) available in Chrome 65!

Oh yeah, the CSS Paint API will be enabled by default in Chrome 65:

CSS Paint API allows you to programmatically generate an image whenever a CSS property expects an image. Properties like background-image or border-image are usually used with url() to load an image file or with CSS built-in functions like linear-gradient(). Instead of using those, you can now use paint(myPainter) to reference a paint worklet.

Inside a paint worklet a CanvasRenderingContext2D has been made available for you to use. Use it like you would draw on a regular <canvas> element. Next to the CanvasRenderingContext2D you can also access the geometry of the element (e.g. get width and height), and can access other CSS properties (including CSS Variables).

There’s a nice demo included which showcases the rendering of a checkerboard pattern, which can be customised via two CSS Variables:

New possibilities in Chrome 65: CSS Paint API →

💁‍♂️ Want to know more about Houdini? Check out Sam Richard’s talk “Magic Tricks with CSS Houdini” (video)

Elsewhere , , , Leave a comment

Fixing iTunes Connect “ERROR ITMS-90717” with ImageMagick

When recently publishing an app to the App Store (or at least trying to get it published back then), I couldn’t upload the app via the Application Loader. I got back ERROR ITMS-90717

“Invalid App Store Icon. The App Store Icon in the asset catalog in ‘Your.app’ can’t be transparent nor contain an alpha channel.”

You can also get a likewise warning later on in iTunes Connect, when uploading the “App Previews and Screenshots”

To easily fix this, you can use ImageMagick’s convert command to remove the alpha:

convert input.png -alpha off output.png

To convert all .png files in a folder, combine the command above with find:

find . -name "*.png" -exec convert "{}" -alpha off "{}" \;

Now replace the assets in your Xcode project file, build your app again, and re-send it to Apple 🙂

Elsewhere , , , Leave a comment

CSSGrid.io – Free Video Series to learning CSS Grid

Great new video series by Wes Bos, this time on learning CSS Grid.

CSS Grid may seem a bit daunting with new syntax and layout ideas, but it’s fairly simple and can be broken down into a handful of powerful concepts that when used together will blow your mind and change the way you create layouts for the web forever.

Ready?! Let’s Learn CSS Grid Together!

Thanks to a sponsorship by Mozilla Firefox the series – all 25 videos – is entirely free.

CSS Grid — Learn all about CSS Grid with Wes Bos in this free video series! →

Elsewhere , , , Leave a comment

On “Secure Contexts” in Firefox, HTTPS for local development, and a potential nice gesture by Chrome

👋 This post also got published on Medium. If you like it, please give it some love a clap over there.

Earlier today, in a post entitled Secure Contexts Everywhere, it was announced on the Mozilla Security Blog that Firefox from now on will only expose new features such as new CSS properties to secure contexts:

Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR. In contrast, a new CSS color keyword would likely not be restricted to secure contexts.

Whilst I somewhat applaud this move, especially in the age of data theft and digital espionage, it’s – pardon my French – quite a ballsy thing to do. CSS Properties, really?

You might not be entirely aware of it, but features like Geolocation, the Payment Request API, Web Bluetooth, Service Workers, etc. are already locked down to secure contexts only.

But what is this secure context they speak of exactly? Is it HTTPS? Or is it more than that?

Let’s take a look at the MDN Web Docs on Secure Contexts:

A context will be considered secure when it’s delivered securely (or locally), and when it cannot be used to provide access to secure APIs to a context that is not secure. In practice, this means that for a page to have a secure context, it and all the pages along its parent and opener chain must have been delivered securely.

Roughly translated: http://localhost/ is considered to be a secure context, so that one will have the latest and greatest. However, the docs aren’t that clear on whether the definition of “local” involves actual DNS resolving or not:

Locally delivered files such as http://localhost and file:// paths are considered to have been delivered securely.

What about development domains – think project.local or project.test – pointing to 127.0.0.1? Right now we’re left in the blue here …

Do note however that Mozilla “will provide developer tools to ease the transition to secure contexts and enable testing without an HTTPS server”, but the related bug is still unassigned.

~

It’s best to have your local web development stack mimic the production environment as closely as possible. Over the years we’ve seen the rise of tools like Vagrant and Docker to easily allow us to do so: you can run the same OS and version with the exact same Apache version with the exact same PHP version with the exact same MySQL version with … oh you get the point.

One of the things that’s still not really frictionless right now for your local development domains is the use of certificates.

Yes, you could use self-signed certificates for this, but that’s:

  • Not always possible: The Fetch API for example doesn’t allow the ignoring of self signed certificates.
  • Asking for potential security problems the moment you go into production: I once read a post about some production code that still had the --insecure flag enabled on the curl requests 🤦‍♂️. It was put there in the first place because of to the self-signed certificates used during development.

Another approach – and one that I am taking – is to use an actual domain for your dev needs. Each project I build is reachable via a subdomain on that dedicated domain, all pointing to 127.0.0.1 thanks to a an entry in my hosts file. Since it’s an actual domain I am using, I can use an actual and correctly signed certificate along with that when it comes to HTTPS.

At the cost of only a domain name (you can get your certificates for free via Let’s Encrypt, which now support wildcards too) that’s quite a nice solution I think.

~

Back in December 2017 version 63 of Google Chrome was released. One of the changes included is that Chrome now requires https for .dev and .foo domains. This was ill-received by quite a lot of developers as most of them – including me before – use(d) the .dev TLD for local development purposes.

And yes, the pain is real … just do a quick search on Twitter on chrome https dev and you’ll see that lots of developer have wasted – and still are wasting – many hours on this breaking change.

Yes, there’s a (lengthy) workaround available to get the green lock in Chrome, but I wouldn’t recommend it really. It would require you to repeat a likewise procedure in all browsers you have running/are testing in, and this per .dev domain you have. Above that it won’t fix any out-of-browser contexts.

Could Google have prevented this .dev debacle? Of course. But I don’t see a reversal of this change coming any time soon though …

Can Google still do something about it? Well … I have an idea about this:

Just imagine if Google were to point all .dev domains to 127.0.0.1, that’d truly be paving the cowpaths! Add free SSL certificates for all .dev domains along with that and we’d jump quite far. With announcements like Secure Contexts Everywhere (referenced at the very top of this page) this idea seems like a real winner:

  1. (Chrome) Us developers can keep using the .dev TLD for projects in development.
  2. Us developers no longer need to use self-signed certificates anymore for projects in development. We could use certificates directly signed by Google’s CA (or by Let’s Encrypt in case Google doesn’t feel like providing certificates)
  3. (Firefox) Domains with the .dev TLD (and with an SSL Certificate) can be considered as a Secure Context, just like any other domain reachable via HTTPS.

One can dream, right?

FIN.

Original Content , , , , Leave a comment

Can (a ==1 && a== 2 && a==3) ever evaluate to true?

Is it ever possible that (a ==1 && a== 2 && a==3) could evaluate to true, in JavaScript?

This is interview question asked by a major tech company. My answer was that it’s impossible. They said nothing is impossible. It happened 2 weeks back, but I’m still trying to find the answer. I know we never write such code in our day to day job, but I’m curious.

Betteridge’s Law of Headlines demands the answer to this question to be no, but given the fact that it’s question about JavaScript the answer – of course – is yes.

Here’s a hint: note the == that’s used, allowing for coercion to happen 😉

StackOverflow: Can (a ==1 && a== 2 && a==3) ever evaluate to true? →

Elsewhere , , 1 Comment

SEDAC Population Estimator

The Population Estimation Service is a Web-based service for estimating population totals and related statistics within a user-defined region. It enables users of a wide variety of map clients and tools to quickly obtain estimates of the number of people residing in specific areas without having to download and analyze large amounts of spatial data.

Tested it by drawing a (rough) polygon around Belgium and it yielded a number of nearly 12 million which is quite correct 🙂

SEDAC Population Estimation Service →
SEDAC Population Estimator Web App →

Elsewhere , , Leave a comment

HTML 5.2: The <dialog> Element

HTML 5.2 has introduced a new <dialog> element to show modal dialog boxes. Here’s a small demo by @bdc (forked version by me, including polyfill):

Already available in Chrome; a polyfill is available for other/older browsers.

Meet the New Dialog Element →
Polyfill for the HTML <dialog> element →

Siderant: I cannot help it, but my inner geek has issues with the language used to control the dialog.

The attribute to indicate whether a modal is open/visible/shown or not is named open, so I’m taking that as the baseline.

Now, say you want to open a modal via JavaScript you don’t call modal.open(), but you have have to call modal.showModal(). Why not open (like the attribute) but show as the verb? And why the Modal suffix?

And now comes the even more inconsistent part: to close it, you don’t call modal.hideModal() (which is the exact opposite of modal.showModal()) nor modal.closeModal(), but modal.close().

Weird … 🤔

Elsewhere , , , 1 Comment

“Understand the Content”

Steve Jobs on Process and Content:

Hear hear!

(via @SvenMunaron)

Elsewhere , , Leave a comment