Tags: port

260

sparkline

Thursday, October 22nd, 2020

Accessibility Support

A very handy community project that documents support for ARIA and native HTML accessibility features in screen readers and browsers.

Thursday, July 30th, 2020

Lateral Thinking With Withered Technology · Matthias Ott – User Experience Designer

What web development can learn from the Nintendo Game and Watch.

The Web now consists of an ever-growing number of different frameworks, methodologies, screen sizes, devices, browsers, and connection speeds. “Lateral thinking with withered technology” – progressively enhanced – might actually be an ideal philosophy for building accessible, performant, resilient, and original experiences for a wide audience of users on the Web.

Friday, July 10th, 2020

What is CSS Specificity? Sarah Chima - Front-End Developer

An excellent and clear explanation of specificity in CSS.

Thursday, June 11th, 2020

A Rare Smile Captured in a 19th Century Photograph | Open Culture

I wrote a while back about one of my favourite photographs but this might just give it a run for its money.

It was only near the end of the 19th century that shutter speeds improved, as did emulsions, meaning that spontaneous moments could be captured. Still, smiling was not part of many cultures. It could be seen as unseemly or undignified, and many people rarely sat for photos anyway.

O-o-dee of the Kiowa tribe in traditional dress with a heartwarming smile on her face in a photograph over 100 years old.

Thursday, April 23rd, 2020

Better Image Optimization by Restricting the Color Index – Eric’s Archived Thoughts

A great little mini case-study from Eric—if you’re exporting transparent PNGs from a graphic design tool, double-check the colour-depth settings!

I’d been saving the PNGs with no bit depth restrictions, meaning the color table was holding space for 224 colors. That’s… a lot of colors, roughly 224 of which I wasn’t actually using.

Wednesday, March 11th, 2020

A curl in every port

A few years back, Zach Bloom wrote The History of the URL: Path, Fragment, Query, and Auth. He recently expanded on it and republished it on the Cloudflare blog as The History of the URL. It’s well worth the time to read the whole thing. It’s packed full of fascinating tidbits.

In the section on ports, Zach says:

The timeline of Gopher and HTTP can be evidenced by their default port numbers. Gopher is 70, HTTP 80. The HTTP port was assigned (likely by Jon Postel at the IANA) at the request of Tim Berners-Lee sometime between 1990 and 1992.

Ooh, I can give you an exact date! It was January 24th, 1992. I know this because of the hack week in CERN last year to recreate the first ever web browser.

Kimberly was spelunking down the original source code, when she came across this line in the HTUtils.h file:

#define TCP_PORT 80 /* Allocated to http by Jon Postel/ISI 24-Jan-92 */

We showed this to Jean-François Groff, who worked on the original web technologies like libwww, the forerunner to libcurl. He remembers that day. It felt like they had “made it”, receiving the official blessing of Jon Postel (in the same RFC, incidentally, that gave port 70 to Gopher).

Then he told us something interesting about the next line of code:

#define OLD_TCP_PORT 2784 /* Try the old one if no answer on 80 */

Port 2784? That seems like an odd choice. Most of us would choose something easy to remember.

Well, it turns out that 2784 is easy to remember if you’re Tim Berners-Lee.

Those were the last four digits of his parents’ phone number.

The History of the URL

This is a wonderful deep dive into all the parts of a URL:

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

There’s a lot of great DNS stuff about the host part:

Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularily given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.

Wednesday, January 22nd, 2020

The CSS Cascade

This is a wonderful interactive explanation of the way CSS hierarchy works—beautiful!

Monday, January 6th, 2020

Browser defaults

I’ve been thinking about some of the default behaviours that are built into web browsers.

First off, there’s the decision that a browser makes if you enter a web address without a protocol. Let’s say you type in example.com without specifying whether you’re looking for http://example.com or https://example.com.

Browsers default to HTTP rather than HTTPS. Given that HTTP is older than HTTPS that makes sense. But given that there’s been such a push for TLS on the web, and the huge increase in sites served over HTTPS, I wonder if it’s time to reconsider that default?

Most websites that are served over HTTPS have an automatic redirect from HTTP to HTTPS (enforced with HSTS). There’s an ever so slight performance hit from that, at least for the very first visit. If, when no protocol is specified, browsers were to attempt to reach the HTTPS port first, we’d get a little bit of a speed improvement.

But would that break any existing behaviour? I don’t know. I guess there would be a bit of a performance hit in the other direction. That is, the browser would try HTTPS first, and when that doesn’t exist, go for HTTP. Sites served only over HTTP would suffer that little bit of lag.

Whatever the default behaviour, some sites are going to pay that performance penalty. Right now it’s being paid by sites that are served over HTTPS.

Here’s another browser default that Rob mentioned recently: the viewport meta tag:

I thought I might be able to get away with omitting meta name="viewport". Apparently not! Maybe someday.

This all goes back to the default behaviour of Mobile Safari when the iPhone was first released. Most sites wouldn’t display correctly if one pixel were treated as one pixel. That’s because most sites were built with the assumption that they would be viewed on monitors rather than phones. Only weirdos like me were building sites without that assumption.

So the default behaviour in Mobile Safari is assume a page width of 1024 pixels, and then shrink that down to fit on the screen …unless the developer over-rides that behaviour with a viewport meta tag. That default behaviour was adopted by other mobile browsers. I think it’s a universal default.

But the web has changed since the iPhone was released in 2007. Responsive design has swept the web. What would happen if mobile browsers were to assume width=device-width?

The viewport meta element always felt like a (proprietary) band-aid rather than a long-term solution—for one thing, it’s the kind of presentational information that belongs in CSS rather than HTML. It would be nice if we could bid it farewell.

Sunday, December 8th, 2019

2019 Firefox Flashback

Here’s an end-of-year roundup of all the data that Mozilla have gathered through their Firefox browser—very impressive!

Monday, December 2nd, 2019

Thursday, November 21st, 2019

A Non-Business Case for Supporting Old Browsers « Texte | ovl – code & design

Supporting Internet Explorer 11 doesn’t mean you need to give it the same experience as a modern browser:

Making sure (some of) your code works in older browsers, does not mean all functionality has to work everywhere. But, mind you, ninety percent of web development means putting text and images in boxes.

And to be honest, there is no reason to not enable this everywhere. Same for form submissions. Make it boring. Make it solid. And sprinkle delight on it.

Surveillance giants: How the business model of Google and Facebook threatens human rights | Amnesty International

Amnesty International have released a PDF report on the out-of-control surveillance perpetrated by Google and Facebook:

Google and Facebook’s platforms come at a systemic cost. The companies’ surveillance-based business model forces people to make a Faustian bargain, whereby they are only able to enjoy their human rights online by submitting to a system predicated on human rights abuse. Firstly, an assault on the right to privacy on an unprecedented scale, and then a series of knock-on effects that pose a serious risk to a range of other rights, from freedom of expression and opinion, to freedom of thought and the right to non-discrimination.

However…

This page on the Amnesty International website has six tracking scripts. Also, consent to accept tracking cookies is assumed (check dev tools). It looks like you can reject marketing cookies, but I tried that without any success.

The stone PDF has been thrown from a very badly-performing glass house.

Monday, November 11th, 2019

JavaScript | 2019 | The Web Almanac by HTTP Archive

It’s time for a look at the state of the web when it comes to JavaScript usage. Here’s the report powered by data from HTTP Archive:

JavaScript is the most costly resource we send to browsers; having to be downloaded, parsed, compiled, and finally executed. Although browsers have significantly decreased the time it takes to parse and compile scripts, download and execution have become the most expensive stages when JavaScript is processed by a web page.

Sending smaller JavaScript bundles to the browser is the best way to reduce download times, and in turn improve page performance. But how much JavaScript do we really use?

When it comes to frameworks and UI libraries, there are some interesting numbers. Given the volume of chatter in the dev world, you’d be forgiven for thinking that React is used on the majority of websites today. The real number? 4.6% of websites. That’s less than the number of websites using CSS custom properties.

This is reminding me of what I wrote about dev perception.

Tuesday, October 15th, 2019

Manton Reece - Saying goodbye to Facebook cross-posting

Facebook and even Instagram are at odds with the principles of the open web.

Related: Aaron is playing whack-a-mole with Instagram because he provides a servie to let users export their own photographs to their own websites.

Sunday, October 13th, 2019

The “P” in Progressive Enhancement stands for “Pragmatism” - Andy Bell

With a Progressive Enhancement mindset, support actually means support. We’re not trying to create an identical experience: we’re creating a viable experience instead.

Also with Progressive Enhancement, it’s incredibly likely that your IE11 user, or your user on a low-powered device, or even your user on a poor connection won’t notice that they’re experiencing a “minor” experience because it’ll just work for them. This is the magic, right there. Everyone’s a winner.

Tuesday, October 8th, 2019

You really don’t need all that JavaScript, I promise

The transcript of a fantastic talk by Stuart. The latter half is a demo of Portals, but in the early part of the talk, he absolutely nails the rise in popularity of complex front-end frameworks:

I think the reason people started inventing client-side frameworks is this: that you lose control when you load another page. You click on a link, you say to the browser: navigate to here. And that’s it; it’s now out of your hands and in the browser’s hands. And then the browser gives you back control when the new page loads.

Friday, October 4th, 2019

Why Progressive Web Apps Are The Future of Mobile Web [2019 Research]

PWAs just work better than your typical mobile site. Period.

But bear in mind:

Maybe simply because the “A” in PWA stands for “app,” too much discussion around PWAs focuses on comparing and contrasting to native mobile applications. We believe this comparison (and the accompanying discussion) is misguided.

Saturday, August 24th, 2019

[this is aaronland] #mw19 – the presentation

The web embodies principles of openness and portability and access that best align with the needs, and frankly the purpose, of the cultural heritage sector.

Aaron’s talk from the 2019 Museums and the Web conference.

In 2019 the web is not “sexy” anymore and compared to native platforms it can sometimes seems lacking, but I think that speaks as much to people’s desire for something “new” as it does to any apples to apples comparison. On measure – and that’s the important part: on measure – the web affords a better and more sustainable framework for the cultural heritage to work in than any of the shifting agendas of the various platform vendors.

Tuesday, July 30th, 2019

Don’t build that app! – Luke Jackson - YouTube

This is a fascinating look at how you can get the benefits of React and npm without using React and npm.

Here’s an accompanying article on the same topic.

Don't build that app! – Luke Jackson