Wandering Thoughts archives

2016-12-28

The HTML IMG attributes and styling that I think I want

Once upon a long time ago, I put very basic support for inline images into DWikiText (the wikitext dialect used here). At the time I felt I had both simple needs and a simple understanding of the IMG element, so I just specified the image's width and height and called it a day, putting them in as width= and height= attributes in the IMG element.

Much later on, on my personal site, I found that I wanted to include some images and make them as large as would fit in my layout. So I did a hack; I carefully worked out the rough largest image width that would fit in my own browser window in the relatively narrow width I normally keep it at, resized my images to be that wide, and called it a day. This worked for a while (as far as I could see) but then I got an iPhone and looked at my own site with it. The results were not appealing; with my nominally responsive CSS my fixed-width images somehow had tha paradoxical effect of forcing the text content to be narrower (and in a smaller font size) than it could be.

So I did some fiddling to see if I could do better. I decided that I wanted my inlined images to have the following behavior:

  1. never push the natural (text) content width wider (much like how I now want all <pre> content to behave)
  2. shrink down in size instead of getting truncated as the content width shrinks
  3. preserve their aspect ratio as the content width shrinks or grows
  4. don't enlarge themselves beyond their full size, because my inlined images don't necessarily look good zoomed up

Based on both experimentation and reading the MDN page on <img>, what I seem to want is <img> tags that specify a width= value (in pixels) but not a height=, combined with the CSS style of 'max-width=100%'. The CSS max-width gets me my first two things, specifying width appears to mean that browsers won't enlarge the image, and not specifying height appears to make browsers preserve the image aspect ratio if and as they shrink the image. Specifying height as well as width caused at least some browsers to not preserve the aspect ratio, which sort of vaguely makes sense if I squint at it enough.

(You can also put in invalid values for height, like 'x', and get the same effect.)

This feels a bit like a hack, especially the bit about omitting height=, but it also appears to work. Probably there are some less than desirable effects on page layout on slow networks, but I'll live with them unless I can find a better way.

(Some sources suggest that I should set the CSS height to 'auto' as well. The whole area of scaling images to fit in content areas appears to be rather complicated, based on some Internet searches, or perhaps most everyone is over-engineering it with Javascript and lots of CSS and so on. I'm pretty ignorant about the modern state of CSS, so I'm definitely working by superstition.)

HTMLImageSetupIWant written at 01:46:31; Add Comment

2016-12-19

Don't assume you can renew TLS certificates whenever you want to

We currently have one of our web sites using Let's Encrypt despite us not planning to switch it to a LE certificate. And there lies a short story.

We (collectively) were planning to renew the existing non-LE certificate for this site a week or so in advance of it expiring. But things came up, and renewal slipped, and then suddenly the certificate was expiring in less than 24 hours and it was November 25th.

(November 25th was a normal work day in Canada.)

Did you know that commercial Certificate Authorities get kind of busy on Black Friday, in fact so busy that they're overwhelmed? We certainly didn't (and I'm honestly a little surprised by it), but apparently they do. So we couldn't renew our certificate at our normal CA, and the next CA or two that was tried was overwhelmed too. But Let's Encrypt was humming along fine, and there are self-contained clients that make it entirely trivial to get a one-shot Let's Encrypt certificate.

I don't know if this particular website will stick with Let's Encrypt (which would require setting up a client to automate things) or go back to a one or two year TLS certificate from our normal commercial CA. But I have my suspicions.

The broad moral here is in the title: don't assume that you can renew your TLS certificates whenever you want to, whether they're from Let's Encrypt or a commercial CA. Sure, almost all of the time you can, but things can happen (and not just in the CA; imagine if there is a problem with the credit card that you use to pay for stuff).

PS: Let's Encrypt helps here because you can renew well in advance without any drawbacks, unlike many commercial CAs. Early renewal means that you have lots of time to deal with things going wrong, instead of having to scramble on the last day the way we did. And obviously an automated process helps too, since automation removes the need for people to remember to do things.

CertificateRenewalCanHitProblems written at 01:39:23; Add Comment

The great thing about using Let's Encrypt is the automation

When I started using TLS certificates from Let's Encrypt, the obvious attraction was that the certificates were free. I could have certificates for as many different names as I wanted and I'd never have to worry about either the cost or the whole mechanical hassle of paying for them.

(You'd think that TLS certificate vendors would make it really easy to give them money either for new certificates or to renew ones you already have. In my limited experience, this is not the case; the one vendor's website I had to use seemed deliberately designed to make the process hard and opaque.)

It's funny that I should mention 'hassle', because that's turned out to be the great thing about switching my certificates over to Let's Encrypt. The only thing that's a hassle with Let's Encrypt is picking out a LE client and getting it set up properly on your system (I recommend acmetool). Once you've done that the LE and client automation takes over, everything just works, and you can stop even thinking about it.

(One of my TLS certificates renewed yesterday and the only reason I know is that I go out of my way to monitor our certificate expiry times, so I saw that site's time jump back to 90 days.)

Up until Let's Encrypt came along, both getting renewed certificates and deploying them was a hassle; the last time I went through it for our sites was basically a day of work. A properly operating Let's Encrypt client setup turns both into things that you can entirely forget about because it all just works and keeps on working with no by-hand care or attention. This is a great thing, since grinding through all of this by hand is just pointless work.

One somewhat subtle appeal of this automation is that it also basically removes the need to carefully keep track of and worry about certificate expiry times. Your monitoring system should still watch this, just in case, but you no longer need a note in your calendar about 'certificate X needs to be renewed now' and you don't need to worry about what happens if it slips through the cracks.

(The appeal of LE's automation is sufficiently great that it's started to make my co-workers enthused about switching to Let's Encrypt. We're okay with paying money for certificates, more or less, but we all really like the idea of never having to worry about certificate expiration or do work to roll over certificates.)

LetsEncryptAutomationGreat written at 01:20:43; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.