The Mandelbear's Musings

Uploading and showing an image on DW

Tue, 04 Sep 2018 03:42:49 GMT

This started out in a comment, but I think enough people may be struggling with DW's relatively new image upload feature that it's worth making it into a post. And it's a good excuse for posting.

(aside: The key to all of this is knowing enough about HTML to be able to identify the correct URL and create the img tag to refer to it -- it probably all looks like black magic to somebody who hasn't been doing this stuff for the last few years. Don't expect to get it all on one reading.)
You might also want to know some terminology. Those things enclosed in angle brackets are commonly called "tags". The things with a name, an equals sign, and something in quotes are called "attributes". And single and double quotes are identical in effect, but have to match: you can't start with a single and end with a double.

So -- I uploaded an image; down at the bottom there's a box labeled Image Code. Copy, paste:

  <a href='https://mdlbear.dreamwidth.org/file/352.jpg'>
     <img src='https://mdlbear.dreamwidth.org/file/100x100/352.jpg'
         title='Cat and mouse'
           alt='Grey tabby cat looking intently at a Logitech mouse.'  /></a>

(That's what it looked like, except that I wrapped the lines to make it clearer.)

Looking at that line of HTML I can see that there's an img tag that, from the /100x100/ in its URL, looks like a thumbnail. It's wrapped in a link -- an <a...> tag. The href attribute is https://mdlbear.dreamwidth.org/file/352.jpg, which ought to be the full-sized image, so I'll get a preview just to make sure...

Then I clicked the "Preview" button, and it looked like this:

Yup. So https://mdlbear.dreamwidth.org/file/352.jpg -- the href attribute of the img tag, is the URL of the actual image. (At that point I could just as well have copied it out of the browser's location bar, since I was already looking at the full-sized image. I didn't think of that, and just copied it out of the comment I was writing.)

I can put that into an img tag that looks like

<:img src="https://mdlbear.dreamwidth.org/file/352.jpg" width="512">

Chrome says (in the page title) that the image is 1024x719, so I'll try cutting it down by adding a width="512" attribute. Here we go:

-- purrfect.

One final aside: if you're following along and using a word processor that automagically turns quotation marks into matching curly quotes, you need to turn that feature off when you're editing HTML, because they won't be recognized as quotes. If you're creating your post in your browser and you want to enter HTML directly, you need to click the "HTML" tab (over on the upper right). The "Rich Text" setting will create HTML automatically and you'll need to click one of its little icons to create an actual image tag.

Happy hacking!

Another fine post from The Computer Curmudgeon.

comments

HTML for Poets: Some simple magic

Tue, 19 Jun 2018 23:26:58 GMT

Here are a couple of little tricks that may keep you from tearing your hair out in frustration, and in any case will make your posts look better.

Tip the first: Make beautiful poetry with no effort.

There are two obvious ways to post poetry: enclose it in <pre>...</pre> tags (which tells the browser that it's preformatted, so it should leave your line breaks alone), or tediously add a line break tag -- <br> -- to the end of every line. Unfortunately, preformatted text uses a monospaced font, which is great for code and concrete poetry, but really doesn't look very good. And adding line breaks is just tedious.

There is a third way: use

<blockquote style="white-space: pre-wrap;" >to wrap your poem. </blockquote>

This tells your browser to keep spaces and line breaks the way you want them, but continue using the same font as the rest of your page.

There's one subtlety: that start tag is pretty long, but if you start your poem on the following line there will be an annoying extra blank line at the top. So do what I did up there, and start a new line before the >. It turns out that you can replace spaces with newlines anywhere outside of quotes.

That brings me to the next tip:

Tip the Second: Don't let your word processor try to help.

A lot of people compose their blog posts using a word processor, and paste them into the "post" form. If you don't, and aren't using some kind of posting client that lets you save your work any time you want to, you should. Especially if you have cats. But there's a problem. Word processors want to help you create great-looking documents. And that's a problem if you're trying to write HTML.

One thing word processors may try to do is to replace all your quotation marks with “curly” quotes (also called “smart” quotes), instead of using "straight" quotes. That's great except for when you're trying to enter a link, or one of style attributes I just showed you up above. A browser won't recognize them. So instead of

<a href="https://steve.savitzky.net">this</a>

you get

<a href=“https://steve.savitzky.net”>this</a>

See the difference? You may have to zoom in a little. Hover over the links. You'll see that your browser thinks that it's looking at a local link, because it doesn't start with https://, it starts with “https://! Oops!

Another thing I've seen word processors and some other programs do is, behind your back, replace "<" and ">" characters with "<" and ">". Those weird things are called "character entities", and they're HTML's way of forcing the browser to show something that looks like "<" without letting it interpret it as part of a tag. That probably isn't what you wanted, unless you're trying to write math inequalities or an article about how to write HTML.

Yet another problem happens because word processors use proportional spacing, so that your post looks to you the way it's going to look in a browser, more or less. The problem happens because some characters are really small in proportional-spaced fonts, so it's hard to select exactly the text you wanted to, and easy to overlook stray spaces and periods if they get pasted into your links by mistake.

That's why programmers use text editors with fixed-width fonts, and rely on programs like web browsers and LaTeX to make their pages look good when you read or print them.

By the way, I did a little searching and found The Mandelbear's Rough Guide to HTML, from back in 2006. It's still mostly good advice.

Another fine post from The Computer Curmudgeon.

comments

HTML for Poets: The Joy of Static Sites

Fri, 04 May 2018 02:41:34 GMT

Recently I read a couple of blog posts that set me thinking in some interesting directions. Like most of the things I find on LinkedIn, they were mostly a little annoying, with a few good points. For example, Why You Should Decisively Reject Using Wix gives a lot of good reasons not to use Wix, which is a free website builder and host that lets you throw together a website in half an hour by simply picking a template and dragging and dropping things into it. What's not to like, right? Well,

You don't own it. It's on their site. It has their ads on it. Say what you like about ad-supported websites, it isn't your website they're supporting.. It's free, so you're the product, not the customer.
But wait! You can pay them to take the ads off! But it's not cheap: plans go from $4-$24 per month. For that you can get a plan from, say, Hawkhost.com, that will give you full control over your site and its content, and a choice of hundreds of different content management systems that you can switch between any time you want.
You don't have many choices in how your site looks. Sure they have 500 site templates. But once you pick one, you're stuck with it. And they have millions of users. Your site is going to look like at least a couple of thousand others.

The site this post is on, CMS2CMS, is in the business of helping you migrate a website from one Content Management System -- CMS -- to another. They'll help you get off of Wix, for example, and onto Wordpress or Joomla or... Interesting thing is, they won't just give you plain old HTML and build your site from scratch. They'll happily get you off of a plain HTML site and onto a CMS. They have this to say about HTML:

To create a static website may not cost you a thing but to maintain such site can be very expensive. You will have to hire programmers each time you want to perform some changes to your web project.
It is possible to develop and add any kind of functionality to your website. It is a well-known fact that you have stricter control over the file structure, design, and SEO. Although it is possible to customise your web project to fit your needs, there is the necessity to have deep coding knowledge. But even then there is the risk to make a mistake and to damage the code.
A static site is lighter than a website built on CMS and this makes it faster. Various plugins or extensions are not available for a static HTML site. In case you want some, then you will have to code every piece of functionality.
If the website is not very big, it is easier to make some changes, modifications and to customise it according to your needs. It is possible to design each page of HTML site in a different way with the available templates. But it will be your job to code in and around the template for each page.

Rubbish.

Let's look at their main points:

You will have to hire programmers each time you want to perform some changes to your web project. Huh? With HTML your content is just text. Nobody programs a web server from the ground up these days. (I've done it -- it's fun.) On a shared-hosting site like HawkHost, it's already there. All you have to do is tell them your site's name.

Your site is just text. HTML and CSS stand for HyperText Markup Language and Cascading Style Sheets, respectively. They are not programming languages, they're markup. HTML tags say what parts of a page mean -- a headline, a paragraph, a link, an emphasized word, and so on. You can print the basic cheat-sheet on a bookmark. There are some more specialized tags, like the ones for images, tables, and audio players. But they're all simple.

[I]t will be your job to code in and around the template for each page. No, if you're writing in HTML, the "code" is already there. CSS is a description of what each part is supposed to look like: a headline in bold sans-serif, a paragraph in Times Roman, a link red when before you click on it and blue afterwards, emphasized text in italics or boldface. You can print that cheat-sheet on the other side of the bookmark.

Yes, there's more advanced CSS, too, and you can do strange and wonderful things with it. (Take a look at the CSS Zen Garden, for example.) You can get one of thousands of the available CSS stylesheets, tweak it with your favorite fonts and layouts, and add it to your site. Complicated multi-column layouts that change to look great on everything from a phone to a wide screen? Easy -- go to Pure CSS, add one line to your basic page template and a few words to some of your tags, and you've got it.

You don't even have to write HTML or CSS if you don't want to -- you can write plain text in any of a variety of markup languages -- Markdown is the most popular at the moment -- and have it translated automatically to HTML. There are also dozens of static site generators that do it for you.

Various plugins or extensions are not available for a static HTML site. In case you want some, then you will have to code every piece of functionality. As a matter of fact, people have already done that coding, and it's available for free in nearly infinite variety on sites like GitHub. And see "static site generators" above. They all have plugins and themes, and templates. Change one template, re-build your site with one command, and deploy it.

You may be wondering where Javascript fits in. That is a programming language, but it runs on the reader's browser. There are thousands of available libraries and pre-built Javascript applications -- plugins, effectively -- that you can add to your site to liven it up with animation and other special effects. About the only thing that you can't do with a completely static site is add interactive features like comments and user logins, and there are ways around that.

But the best thing about static sites is the way you work on them, because you do that on your own computer. Almost every CMS keeps your site content in a database on the server, and I have another whole rant about that. A static site lives on your laptop; you can work on it without having to have an internet connection, and deploy it only when you have one and you're happy with the way it looks.

Not only can you use your favorite text editor (and there are some awesome ones out there -- take a look at Atom for example), but because you have a complete copy of your site on your computer and on your web host, they effectively back each other up. And because you can use git for version control, you not only have backups but a complete history of every change you make to your site.

The next few posts in this series (did I mention that this is a series?) will go into how to write HTML in more detail, including the tiny bit of CSS magic that lets you embed poetry in any page including a DW post, and teach you the basics of git.

comments