Tags: browsers

432

sparkline

Sunday, April 16th, 2017

Phishing with Unicode Domains - Xudong Zheng

Domains registered with punycode names (and then given TLS certificates) are worryingly indistinguishable from their ASCII counterparts.

Can you spot the difference between the URLs https://adactio.com and https://аdаctіо.com?

Saturday, April 15th, 2017

The invisible parts of CSS · MadebyMike

This is a really clear explanation of how CSS works.

Friday, April 14th, 2017

Think you know the top web browsers? – Samsung Internet Developers – Medium

So do you really know which are the top browsers, both amongst your existing customers and your potential audience? Perhaps it’s worth taking a closer look; it might just be time to check your site in some of the lesser-known, yet popular browsers like UC, Yandex and Samsung Internet.

Tuesday, April 4th, 2017

Jeremy Keith Interview

I had a chat with Toby Osbourn over Skype. He’s writing a book all about print stylesheets so that’s we talked about.

Friday, March 24th, 2017

Scrolling on the web: A primer - Microsoft Edge Dev BlogMicrosoft Edge Dev Blog

A ludicrously deep dive by Nolan into how scrolling works in web browsers. No, wait, come back! It’s more interesting than it sounds …and it certainly isn’t as simple as you might think.

For instance, do you know the difference between the following scenarios?

  • User scrolls with two fingers on a touch pad
  • User scrolls with one finger on a touch screen
  • User scrolls with a mouse wheel on a physical mouse
  • User clicks the sidebar and drags it up and down
  • User presses up, down, PageUp, PageDown, or spacebar keys on a keyboard

If you ask the average web user (or even the average web developer!) they might tell you that these interactions are all equivalent. The truth is far more interesting.

This comes complete with lovely animated illustrations by Rachel.

Tuesday, March 21st, 2017

The web share API | Phil Nash

I really need to have a play with this API. I think it could potentially be a useful indie web building block …if the web share target API also gets implemented.

Monday, March 20th, 2017

World Wide Web, Not Wealthy Western Web (Part 2) – Smashing Magazine

The second part of Bruce’s excellent series begins by focusing on the usage of proxy browsers around the world:

Therefore, to make websites work in Opera Mini’s extreme mode, treat JavaScript as an enhancement, and ensure that your core functionality works without it. Of course, it will probably be clunkier without scripts, but if your website works and your competitors’ don’t work for Opera Mini’s quarter of a billion users, you’ll get the business.

But how!? Well, Bruce has the answer:

The best way to ensure that everyone gets your content is to write real, semantic HTML, to style it with CSS and ensure sensible fallbacks for CSS gradients, to use SVG for icons, and to treat JavaScript as an enhancement, ensuring that core functionality works without scripts. Package up your website with a manifest file and associated icons, add a service worker, and you’ll have a progressive web app in conforming browsers and a normal website everywhere else.

I call this amazing new technique “progressive enhancement.”

You heard it here first, folks!

Monday, March 6th, 2017

PushCrew Push Notifications for HTTP websites

A nasty service that Harry noticed in his role as chronicler of dark patterns—this exploits the way that browser permissions are presented below the line of death.

W3C and EME: it isn’t about preventing DRM but saving the W3C – Baldur Bjarnason

A damning assessment of Tim Berners-Lee’s defeatist portrayal of the W3C:

No matter which side is right, the W3C faces an existential crisis.

Either:

  1. The W3C is a shepherd of the web for all, the web on everything, and a web of trust. But now it is fundamentally compromising its own principles in the name of maintaining industry relevance.
  2. Or, the W3C is merely an industry body for browser vendors to collaborate and its mission statement is nothing more than PR to increase buy-in from the smaller, largely powerless, members.

Both can’t be true. Neither is good news for the organisation.

Friday, March 3rd, 2017

On EME in HTML5 | W3C Blog

Much as I respect Tim Berners-Lee, his logic here is completely flawed. First of all, treating DRM as though it’s an implacable force of nature is a category error. Secondly, EME doesn’t in any provide a standardised solution: it provides a sandbox for each DRM vendor to inject their own proprietary solution.

Wednesday, March 1st, 2017

State of Responsive Images 2017 - Cloud Four

Jason revisits responsive images. On the whole, things are looking good when it comes to browser support, but he points out that scrset’s precursor in CSS—image-set seems to have dropped off the radar of most browser makers, which is a real shame.

Tuesday, February 21st, 2017

Variable fonts

We have a tradition here at Clearleft of having the occasional lunchtime braindump. They’re somewhat sporadic, but it’s always a good day when there’s a “brown bag” gathering.

When Google’s AMP format came out and I had done some investigating, I led a brown bag playback on that. Recently Mark did one on Fractal so that everyone knew how work on that was progressing.

Today Richard gave us a quick brown bag talk on variable web fonts. He talked us through how these will work on the web and in operating systems. We got a good explanation of how these fonts would get designed—the type designer designs the “extreme” edges of size, weight, or whatever, and then the file format itself can extrapolate all the in-between stages. So, in theory, one single font file can hold hundreds, thousands, or hundreds of thousands of potential variations. It feels like switching from bitmap images to SVG—there’s suddenly much greater flexibility.

A variable font is a single font file that behaves like multiple fonts.

There were a couple of interesting tidbits that Rich pointed out…

While this is a new file format, there isn’t going to be a new file extension. These will be .ttf files, and so by extension, they can be .woff and .woff2 files too.

This isn’t some proposed theoretical standard: an unprecedented amount of co-operation has gone into the creation of this format. Adobe, Apple, Google, and Microsoft have all contributed. Agreement is the hardest part of any standards process. Once that’s taken care of, the technical solution follows quickly. So you can expect this to land very quickly and widely.

This technology is landing in web browsers before it lands in operating systems. It’s already available in the Safari Technology Preview. That means that for a while, the very best on-screen typography will be delivered not in eBook readers, but in web browsers. So if you want to deliver the absolute best reading experience, look to the web.

And here’s the part that I found fascinating…

We can currently use numbers for the font-weight property in CSS. Those number values increment in hundreds: 100, 200, 300, etc. Now with variable fonts, we can start using integers: 321, 417, 183, etc. How fortuitous that we have 99 free slots between our current set of values!

Well, that’s no accident. The reason why the numbers were originally specced in increments of 100 back in 1996 was precisely so that some future sci-fi technology could make use of the ranges in between. That’s some future-friendly thinking! And as Håkon wrote:

One of the reasons we chose to use three-digit numbers was to support intermediate values in the future. And the future is now :)

Needless to say, variable fonts will be covered in Richard’s forthcoming book.

Monday, February 20th, 2017

Do we need a new heading element? We don’t know - JakeArchibald.com

Jake is absolutely spot-on here. There’s been a lot of excited talk about adding an h element to HTML but it all seems to miss the question of why the currently-specced outline algorithm hasn’t been implemented.

This is a common mistake in standards discussion — a mistake I’ve made many times before. You cannot compare the current state of things, beholden to reality, with a utopian implementation of some currently non-existent thing.

If you’re proposing something almost identical to something that failed, you better know why your proposal will succeed where the other didn’t.

Jake rightly points out that the first step isn’t to propose a whole new element; it’s to ask “Why haven’t browsers implemented the outline for sectioned headings?”

(I added a small historical note in the comments pointing to the first occurrence of this proposal way back in 1991.)

Sunday, February 19th, 2017

Thursday, February 16th, 2017

Teaching in Porto, day three

Day two ended with a bit of a cliffhanger as I had the students mark up a document, but not yet style it. In the morning of day three, the styling began.

Rather than just treat “styling” as one big monolithic task, I broke it down into typography, colour, negative space, and so on. We time-boxed each one of those parts of the visual design. So everyone got, say, fifteen minutes to write styles relating to font families and sizes, then another fifteen minutes to write styles for colours and background colours. Bit by bit, the styles were layered on.

When it came to layout, we closed the laptops and returned to paper. Everyone did a quick round of 6-up sketching so that there was plenty of fast iteration on layout ideas. That was followed by some critique and dot-voting of the sketches.

Rather than diving into the CSS for layout—which can get quite complex—I instead walked through the approach for layout; namely putting all your layout styles inside media queries. To explain media queries, I first explained media types and then introduced the query part.

I felt pretty confident that I could skip over the nitty-gritty of media queries and cross-device layout because the next masterclass that will be taught at the New Digital School will be a week of responsive design, taught by Vitaly. I just gave them a taster—Vitaly can dive deeper.

By lunch time, I felt that we had covered CSS pretty well. After lunch it was time for the really challenging part: JavaScript.

The reason why I think JavaScript is challenging is that it’s inherently more complex than HTML or CSS. Those are declarative languages with fairly basic concepts at heart (elements, attributes, selectors, etc.), whereas an imperative language like JavaScript means entering the territory of logic, loops, variables, arrays, objects, and so on. I really didn’t want to get stuck in the weeds with that stuff.

I focused on the combination of JavaScript and the Document Object Model as a way of manipulating the HTML and CSS that’s already inside a browser. A lot of that boils down to this pattern:

When (some event happens), then (take this action).

We brainstormed some examples of this e.g. “When the user submits a form, then show a modal dialogue with an acknowledgement.” I then encouraged them to write a script …but I don’t mean a script in the JavaScript sense; I mean a script in the screenwriting or theatre sense. Line by line, write out each step that you want to accomplish. Once you’ve done that, translate each line of your English (or Portuguese) script into JavaScript.

I did quick demo as a proof of concept (which, much to my surprise, actually worked first time), but I was at pains to point out that they didn’t need to remember the syntax or vocabulary of the script; it was much more important to have a clear understanding of the thinking behind it.

With the remaining time left in the day, we ran through the many browser APIs available to JavaScript, from the relatively simple—like querySelector and Ajax—right up to the latest device APIs. I think I got the message across that, using JavaScript, there’s practically no limit to what you can do on the web these days …but the trick is to use that power responsibly.

At this point, we’ve had three days and we’ve covered three layers of web technologies: HTML, CSS, and JavaScript. Tomorrow we’ll take a step back from the nitty-gritty of the code. It’s going to be all about how to plan and think about building for the web before a single line of code gets written.

Sunday, February 12th, 2017

Accessibility and Performance | MarcySutton.com

When I heard about Universal JavaScript apps (a.k.a. isomorphic JavaScript), despite the “framework hotness”, I saw real value for accessibility and performance together. With this technique, a JavaScript app is rendered as a complete HTML payload from the server using Node.js, which is then upgraded as client resources download and execute. All of a sudden your Angular app could be usable a lot sooner, even without browser JS. Bells started going off in my head: “this could help accessible user experience, too!”

Sunday, January 22nd, 2017

Opera Neon – The future of web browsers? | Opera

Under the hood it’s the same Blink engine that power’s the regular Opera browser (and Chrome) but I really like the interface on this experiment. It’s described as being a “concept browser”, much like a “concept car”, which is a nice way of framing experiments like this. More concept browsers please!

Thursday, January 19th, 2017

Understanding the Critical Rendering Path

A nice and clear description of how browsers parse and render web pages.

Certified Malice – text/plain

Following from that great post about the “zone of death” in browsers, Eric Law looks at security and trust in a world where certificates are free and easily available …even to the bad guys.

Making input type=date complicated – Samsung Internet Developers – Medium

PPK has posted some excellent thinking on calendar widgets to Ev’s blog.