Style versus Substance
When web sites first starting popping up in the 1990s, they were mostly text, with some formatting and styling. Truth be known, many of those first websites were pretty ugly (my own among them.) We could choose colors, or make text bold, add a picture, and even (shudder) make words blink. To style our pages we applied formatting instructions to the HTML tags.
For example, if I wanted a sentence to be bold or red I could do this:
<p><b>This part is bold.</b></p>
or
<p><font color="red">This is red</font></p>
The basic approach was to lay out our web page and then apply some styles or formats to it – much like a painter might draw a picture.
As early as the 1970s some programmers understood the importance of separating the content, or substance, of a document from the style. Early web pioneers saw the connection to web pages, but most of us developers were slow to realize the advantages.
Style Definitions
Rather than “painting” a style on each text or other element, we can define how different elements look. For example, I could decide that all my big headlines should be red. I can set this format just once and it will apply to all the uses of the headline tag.
This style looks like this:
h1 {color: #FF0000}
(the #FF0000 is a hex formula for the color red.)
And now anytime I have <h1>This is a Heading</h1> that heading will be in red. And those instructions can apply to more than just appearance. They can lay out portions of the page to float to the left or right, or not be displayed until some action is taken, etc. As you read this post on the ASHMUG site the gray column to the right is defined by some style declarations, rather than being a fixed table.
Style Sheets
Style declarations can be stored in the header of a single web page, but the best way to use them is to create a separate file with nothing but style declarations. This is called a Cascading Style Sheet (CSS). Rather than a long list of style declarations at the top of each web page you can have the following:
<head> <link type="text/css" href="mystyles.css" rel="stylesheet" />
...other header stuff...
</head>
So now the user’s browser finds the mystyles.css file, loads in the instructions, and displays the page. Once the browser loads this page, the information stays in cache, i.e. it is remembered, and saves time when other pages load with the same style sheet. The “cascading” part of the name means that it is possible to have several different style sheets, and that the ones following can inherit the style from the earlier sheet and modify a part of it.
Style versus Substance
This can make web page layout a lot more efficient – saving a lot of coding on a big, complicated page. The real power, though, comes in the mind set of separating out the content of the page, from its style or format. A developer can design a page, using style declarations like the one above, and then decide to change the format, by swapping in different styles.
Zen Garden – a masterful example of different styles. Visit the site, csszengarden.com, and then click on the various style choices in the right hand menu. Even though the page has the same content, the look and feel is entirely different.
This is helpful for more than people with different artistic sensibilities. You can apply different styles for regular browsers versus mobile devices. The web page can detect that a mobile device is being used and adjust the look and feel to accomodate the smaller screen. A visually impaired user can invoke a larger format style or one which works best with a screen reader.
Browser Wars
Today’s modern browsers follow the CSS rules laid down by various consortia fairly well. This wasn’t always the case. The biggest problems came from earlier versions of Internet Explorer (v5 and v6 in particular.) Microsoft and its browser decided to interpret the CSS rules differently, to favor the user experience under Windows. There is an ocean of virtriol spewed by web developers who have had to craft hacks and workarounds for older versions of IE, and today there are subtle differences still.
Learning the CSS Rules
The rules governing CSS are complex and sophisticated, and I can’t begin to teach them here. If you are designing a web page, an investment in a CSS manual would be a wise choice. Or you can do as I often do, and acquire or purchase web page templates that come with CSS style sheets. My favorite source is Project Seven – projectseven.com. They have both free tutorials and commercial templates for sale, and these adjust for idiosyncratic differences among browsers.
Shhh! It’s a Secret.
We’ve been conditioned to worry about the security of our personal information while surfing the web. Perhaps the most important and effective security practice is to be prudent and sparing when sharing important information.
As web site users and web site owners/developers there are some steps we can take to help safeguard information. Today’s post focuses on the secure, encrypted communication offered by some web sites.
Some Background from the Web User’s Perspective
When we go to a typical web site, like ashmug.com, we are sending a simple message out through the Internet asking to display the ASHMUG web site. The ASHMUG web server sends us back the pictures and text and instructions that construct the page. If there is a simple form on one of the pages, like the form on the Contact Us page, any information we type into that form gets sent back to the server in the same way.
By default this exchange of information is in the open. If someone could “listen in” to the flow of information they could read and understand what is being said, including the information we type into the form. In many cases this is no big deal, since the information is generally known by the public anyhow.
If the information requested in the form is sensitive – such as a credit card number - the web site can safeguard it by encrypting, or coding the information before sending it out over the “wires”.
Safari Icon - Encrypted
There are a couple ways to spot if this extra protection is present on a web page you are visiting. If you use Safari as your browser there is a little gray padlock in the upper right corner of your browser window. In some browsers you can also spot that the web page URL/address starts with https: . This indicates a secure page, while http: indicates an open or unsecure page.
Encryption Information in Firefox
If you use a recent version of Firefox , up in the address bar, just to the left of the page address is a box that displays the name of the site owner. Clicking on that shows more information about the encryption.
Let’s look at this information a bit more. There is a note that the site ownership is verified by GoDaddy.com. That means that GoDaddy has taken extra steps to verify the site’s identity, and has given the Intrade.com site a digital certificate supporting the verification.
If you see information like these two examples, then you can be pretty confident that the information on the form will go out on to the Internet in a safeguarded form – encrypted. That reduces, significantly, the chance that an eavesdropper can intercept and see your sensitive information.
This kind of protection is particularly important if you are viewing/using a web site through a public wireless hotspot, like at a coffee shop, the library, or on campus. Your communication in these public places is easier to catch and intercept. If you are home, connected to the Internet by a cable, or sitting behind a password protected wireless hotspot, the actual odds of someone intercepting your information are pretty slim. Still, it is good practice to expect a web site to secure the communication of important, sensitive information. And virtually all good web sites take this precaution. You’ll routinely see it used when shopping online, or banking, or a variety of other functions.
How Does it Work?
As a user you might be mildly interested in this. As an owner or developer of a site, this information is more important.
To offer a secure page and communication the web site needs to register with a security certificate company. There are many, including Network Solutions, GeoTrust, GoDaddy, and more. These companies ask to verify who actually owns/operates the site, and who the key contact is. They then issue a security certificate and a public key. The certificate helps display the kind of information on Intrade we saw above. This certificate is made available to browsers who visit the secure page. The public key is a very long, seemingly random assortment of numbers and letters. This key can be 100s of characters long.
The web site sends this public key to the browser. The browser uses the public key to convert the plain-language information into coded gibberish. If a bad person intercepts a communication that is encrypted, they can find out the public key, but that is not enough information to decrypt, or translate the gibberish into useful information. When the encrypted information comes back to the web server, the server matches the public key to a private key stored on the server. Once the match is made, that private key can unlock the information and make it readable. No one can see that private key, and it is kept in a safe place on the web server.
If you are developing a web site and you want to safeguard the transmission of information, the first thing to do is consult with your web hosting service. They will probably have established procedures to help you get a security certificate, and to install it in your site. It will cost you an extra annual fee to renew the security certificate, and sometimes a one-time set up fee. The process for doing this on your own is pretty complicated, so make use of any service your hosting company offers.
Coding Notes for Your Web Site
Once you have the security things set up with your host, you need to tell the browser when to switch to secure mode. Let’s use the example of a contact form page, and imagine that you want the information on that form to be encrypted when it is submitted. So, we are on the home page of mydomain.com and you have a menu that includes the contact form page. Ordinarily you would link to contact.html, with some HTML like this:
<a href="contact.html">Contact Us</a>
We now need to change this to indicate a secure page. The new code might look like this:
<a href="https://mydomain.com/contact.html">Contact Us</a>
See the https: in the code? For a regular link we don’t have to worry about http: or even the domain name – those are just assumed when linking within a web site. In this case though we are more specific and saving we want the Contact Us page to be displayed and used in secure mode.
So, now the user is taken to contact.html and the page is displayed in secure mode. Good.
The next step is to make sure the form on that page goes to a similarly safeguarded page. Maybe the form tag sends the information to getform.html. That page might have some programming that takes the form information, and does something with it – save it or create an email with it. To be safe your form tag should look like this:
<form action="https://mydomain.com/getform.html" method="post">
...form fields go here...
</form>
One last step… Go to the HTML coding for that original form page and see if any of the images in particular are specified like this:
<img src=”http://mydomain.com/images/image1.jpg” />
This kind of coding should be changed to use secure functions, or else the browser will warn the user that some parts of the page are not secure. In truth this isn’t a security hole, but it will worry your user. So use either of these coding styles for your images.
<img src="images/image1.jpg" /> Your browser will assume the image should be retrieved securely.
<img src="https://mydomain.com/images/image1.jpg" /> This leaves no doubt
Very often we work with page templates where the heading and navigation menus are standard on all pages. That can mean that some images, like a logo, are displayed with the same code, page after page. Generally this isn’t a problem when these templates use the shorter version above, <img src=”images/image1.jpg” />. If this appears on a secure page the browser assumes the image should be retrieved securely, and otherwise not.
Why Bother?
This is actually a fair question. If you are contemplating a web site that will deal with sensitive, personal information it is a good idea to step back and ask yourself if you want to make the effort to secure the site, and also secure any information that you collect and store. Also, if you collect and store sensitive information you assume a legal risk or liability if that information is compromised. This is the beauty of services like Google Checkout (soon to be renamed Google Wallet) and PayPal, or the Yahoo Store. If you set up accounts with one of these services and can then send your site visitors to their secure pages, you can be more comfortable with your user’s security. These services spend tons of money perfecting their security set up. I know a guy who works for PayPal in the security area and he and his colleagues spend practically full time trying to anticipate hackers, and building mechanisms to foil them. Most of us don’t have the resources to match that. Working with a large, legitimate online shopping service is often the best route.
Cookie Monster
Go ahead, admit it - you remember the song… “C is for Cookie, that’s good enough for me.” One of my favorite Sesame Street characters as our children were growing up.
In another use of cookies, a friend exclaimed recently that she had been browsing the Amazon site for some items and later got an email from Amazon suggesting some similar products. Roughly quoting her, “That’s creepy. I felt like I was being stalked.” How did Amazon do this? Through the use of one or more browser cookies, and customer information from logging in. A browser cookie is a little snippet of code that is stored with or near your web browser, usually with a name, a value to go with that name, and an expiration date. Let’s see how this might happen and then turn the tables and ask whether or when cookies might be appropriate on a web site that you produce.
I just removed all of the Amazon cookies in my Firefox browser, and then visited the site. Then I went to Preferences in my browser, clicked on the Privacy tab, clicked on Show Cookies, and found that my arrival at the Amazon site had generated 5 separate cookies. Each cookie had a cryptic name (session-token, apn-user-id, etc.) with an assigned value – most likely something random, but remembered and stored at Amazon. But Amazon doesn’t know who I am. I had erased earlier Amazon cookies, and the home page for Amazon invites me to sign-in. Once I sign in Amazon can associate one of those cookie values with my account, which also includes an email address. Now, I start browsing the Amazon web site, and on each page my unique cookie ID gets recorded. So if I search for books on astronomy, Amazon knows that the customer with this cookie ID is looking for astronomy books, and they can link this preference to my customer information and later send me an email with more astronomy suggestions. Creepy? Maybe. Helpful? Maybe.
Cookies in web sites started out innocuously enough. Storing a tiny bit of information, a unique ID for the visit, allows a web site to improve the user experience. Returning to the Amazon example – if I sign-in at some point, then my checkout procedure will go more smoothly. The only way Amazon can know that I am still signed in is by storing a cookie. Each subsequent page I visit Amazon checks to see if there is an Amazon cookie on my browser, connects that to my signed-in status, and lets me see “Hello Douglas” at the top of each screen.
Not to alarm you, dear reader, but by coming to the ASHMUG web site and reading this blog, you’ve had several cookies set for the ashmug.com domain. These are benign, because we’re a good organization, run by ethical people, without any financial incentives to invade your privacy. Sadly, this is not always the case with other sites.
This early use of cookies has grown into its own form of cookie monster, and frankly I probably don’t know half of the uses and abuses of cookies today. One example of an early idea gone rogue is a persistent cookie that might be used by more than one web site. Let’s say that one site sets a cookie as part of displaying an advertisement. The company that serves up the ad stores a cookie, and remembers that you saw that ad. You then visit another site which is serviced by the same ad company. They spot the cookie set earlier, and combine that information with the newest site you’ve been to, or the kind of product you were seeking. Now, one company is building a shopping preference profile on you. They may not know who you are yet, but if you sign-in on one of your stops and that web site has a joint marketing agreement with the ad company, some information may be shared.
If you are developing a regular web site – some kind of pamphlet site that provides information for others to read – you probably don’t need to set cookies. If you are connecting to or using an e-commerce function, cookies are practically required and either your e-commerce partner or your web developer will build this in. WordPress, the well-known blogging engine (which runs this ASHMUG web site and blog) assigns some cookies on its own – again, perfectly benign. It’s possible to add WordPress plug-ins to set cookies on your own, if that can enhance your users’ experience. Programming languages for web sites, like Javascript, PHP, or Lasso, have streamlined ways to add and read cookies.
My description is not intended to make you swear off websites and logins. While it is possible to adjust your browser (both on Safari and Firefox, go to Preferences, then Privacy) and block cookies, you will find your browsing experience becomes miserable. Just like with many other aspects of the Internet and life in general, we just need to be thoughtful about when we share information with others – particularly contact and financial information. Legitimate users will have carefully designed privacy policies that we can either accept or reject. And in both Safari and Firefox you can go to the same Preferences area, and specifically delete cookies from a particular site. If you don’t want someone else to know that you were looking for volume discounts on Hostess Twinkies, you can wipe that slate relatively clean. There isn’t a wolf behind every tree, but going into the woods without a flashlight is not a good idea.
Bricks and Mortar – HTML
HTML
Web pages have a basic, bricks and mortar, foundation. It’s called HTML – short for HyperText Markup Language.
So, here’s a trivia/history question for fellow Mac enthusiasts. Do you remember an early Mac application called HyperCard? This was pre-Internet, and had some features of web pages as we know them now. The principle feature was that you could link a word or phrase on a card and the user could click on that link and be taken to another card. The only problem was that you had to use the computer where the HyperCard application was running. No one had figured out how to make it run over a network (unless our Alan Oppenheimer had gotten ahead of everyone else when working with AppleTalk.) I actually created a simple marketing game/simulation in HyperCard, and used it for marketing training for Kaiser Permanente reps in the late 1980s. (but I digress….)
Hypertext or linking also predates the Internet. Douglas Engelbart, known mostly for inventing the computer mouse, was talking about hyper-linked information well before then. He was entranced with the idea that thoughts and ideas could be linked together in an intricate web, rather than just linearly like a book. A reader could follow a trail of ideas based on their own instincts and preferences, rather than being captive to a paper or a book produced by an author.
Building a Web Page
Web pages are constructed with HTML. When you type ashmug.com into your Safari or Firefox browser the browser expects that you are looking for a page rendered in http – short for hypertext transfer protocol. As you read this post, look up in the address or location bar and you’ll see http://ashmug.com (or http://www.ashmug.com) which means you are expecting to see a page that uses HTML to present the information on the page.
You can see all of the HTML for any web page by choosing View >> Page Source in Firefox and View >> View Source in Safari. Most web pages have this basic structure: I’ll put little {comments} below just to annotate each line.
<html> {the start of the web page. Notice that this and all HTML “tags” are surrounded by < >.}
<head> {this has information about the web page but most of it doesn’t display, with the exception of…}
<title>The Title of the Page</title> {This is the page title that shows in the very top of the browser window.}
<other stuff…>
</head> {Lots of time an HTML tag that is a container has an opening, like <head> and a closing like </head>}<body> {This is the beginning of the stuff the user sees on the web page.}
</body> {This is the end of the stuff the user sees.}</html> {This is the end of the web page.}
During the first 8-10 years of the world wide web (remember that phrase?) we used HTML both to display content and also to control how that content looked. Here is a simple example:
This is a regular sentence. This is a regular sentence with the bold attribute applied to it.
Underneath this post the HTML code for this last sentence looks like this:
<strong>This is a regular sentence with the bold attribute applied to it.</strong>
A headline might look like this:
<h1>Here is a Headline<h1>
Here is a Headline.
If I wanted that sentence to have color I might have used something like this:
<p style=”color: #ff0000″>This is a regular sentence with color added.</p>
This is a regular sentence with color added.
As web developers we could cheerfully mark-up our HTML, adding colors, font size, left or right alignment and all the rest. This is still done in plenty of web pages, and in fact some of the formatting for this post is styled that way.
Cascading Style Sheets
Cascading Style Sheets (CSS for short) have helped web developers separate content from display. The more modern approach to web sites has the information (text, pictures, video, etc.) presented, with a separate set of instructions on how they might be aligned or formatted. One of the most famous examples is the Zen Garden web site. Go to http://www.csszengarden.com/ and then over on the right see the list under “Select a Design”. Click on any of these and the exact same information will be displayed, but in a very different look. So what we have is content set and established and then the presentation of that content open for change. This is particularly helpful for people with various disabilities, including visual impairment. A screen reading program can easily find the content in a modern web site and verbalize or enunciate that content. Someone who needs larger text can have a setting that automatically increases the size of the font. Someone reading a web page on a small, mobile screen can have it formatted to be readable on that screen.
Most modern web sites have files specified in the <head> </head> section that point to CSS files. If you View Source on this page one of the lines you will see is:
<link rel=”stylesheet” href=”http://ashmug.com/wp-content/themes/TheProfessional-Child/style.css” type=”text/css” media=”screen” />
This line of HTML tells the browser to find some formatting and design instructions in a file with that link. Your browser reads that information and stores the instructions in that file for awhile. Then, when you go from page to page the same instructions are remembered and used to present my pearls of wisdom in an attractive fashion.
HTML Standards
Who decides what each of these <h1> and <p> tags mean, and how HTML will evolve with the times? That’s more than a full time job. This organization, W3C, manages to herd the 1000s of cats involved in developing web standards. A quick description from their web site:
The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards. Led by Web inventor Tim Berners-Lee and CEO Jeffrey Jaffe, W3C’s mission is to lead the Web to its full potential.
More information on this organization here.
In our next post we’ll look at cookies – not the chocolate chip kind.
Home Sweet Home
So, I’m sitting on a dock in the Adirondack Mountains in northern New York state, with my laptop and a semi-reliable wireless connection from a cabin up the hill. I type in ashmug.com in Firefox, and in seconds our nifty web site appears on my computer screen. If we think about it, that’s a pretty extraordinary accomplishment – an instruction sent from one corner of the country that ultimately finds its way to another corner and back again. For our inaugural post on web and related topics, let’s explore the whole idea of Internet addresses and domains. We’ll use ASHMUG.com as an example.
The ASHMUG web site is hosted on a server with this Internet address: 74.220.219.69 (aka an IP address). Our web host, bluehost.com, is located in Provo, UT. They probably have rooms full of servers, each of which has an address like this, and sometimes a single machine may be like an apartment building with a bunch of these numerical addresses. One of those servers in Provo has been assigned our IP address.
I, however, did not type 74.220.219.69 into Firefox. I typed ashmug.com. So, who makes the connection?
We start with ICANN – Internet Corporation for Assigned Names and Numbers. They keep track of and issue both the numerical IP addresses and the high level domains: .com, .org, .us, .tv, etc. They’re technically an international, non-government body, but with heavy support and influence from the United States government.
The ASHMUG.com domain has a top level, .com, as part of its address. That usually refers to commercial enterprises, but there is no scrutiny or checking done when someone registers their domain. In a similar vein, .org, often means a not-for-profit organization, but you don’t have to prove your non-profit status to get a .org domain.
When ASHMUG’s founding fathers, er… parents, wanted to start a web site, they registered the name with one of a large number of domain registrars. In our case ashmug.com is registered with GoDaddy.com, of Danika Patrick infamy. (Not being wild about the misogynistic advertising from GoDaddy, I’ll hold my virtual nose through this paragraph.)
GoDaddy had to 1) make sure that no one else was using the ashmug.com domain name, and 2) that the domain owner had a real email address, street address, etc. We passed! This registration keeps track of the domain’s owner and a few other contact people, and also records where the ashmug.com domain name server (DNS) is located. JARGON/ACRONYMN ALERT: it’s already getting confusing, huh? Don’t worry, there is a glossary at the end of this post.
When we registered GoDaddy sent our domain name and the address of our DNS server to one of about a dozen or so root name servers around the world. These are hosted at various organizations and institutions and they update each other’s information constantly.
So, back to my laptop on the dock – connected via the HughesNet satellite service. Let’s say I type in ashmug.com on my browser and this is the first time HughesNet has had to retrieve this domain. Their servers poll one of the root servers nearby and ask, “Where in the hell is ashmug.com?” The answer they get back is to go to a server at bluehost.com. That server, then, will say, “You want a regular web site for this domain? Then try this address: 74.220.219.69.” HughesNet sends the request to 74.220.219.69 and the web page appears on my browser. Once I do this HughesNet will remember the information it retrieved about ASHMUG and if I go back to the site later today or tomorrow, HughesNet will used the cached(saved) information to speed up the process.
Email works much the same way. If I want to send a message to an ashmug email address, my email service does the same kind of lookup, but at the end the bluehost DNS server will say, “You want to send a message to <something>@ashmug.com? Well, in this case send it to a server called mailx.opendoor.com.” This is a good example of a topic we had on the ASHMUG discussion list recently. Bluehost.com hosts our web site, but Project A/Ashland HomeNet hosts our email accounts when it bought the OpenDoor business recently. Though the web site and email addresses both have ashmug.com it is possible to have the web site hosted in one place and the email someplace else.
There’s another magical process on the Internet that I’ll just mention briefly. We can gawk at it and admire it, but I don’t know enough about how it truly works to explain it well. One of the original design objectives for the Internet is that communication would not flow through a central computer/controller. Instead, the design allows communication to flow on a number of different paths, which makes it less susceptible to foreign attack (this was the Defense Department, after all, who paid for the early research.) There are little packets zinging around the multitude of connections. Sometimes a big message will be broken into several packets and it is theoretically possible that each of those packets goes a different route. How does that happen? I haven’t a clue.
Wrap Up
So, what does this all mean to you, if you want to have your own domain name and web site? Here are some typical steps.
- Choose and register a domain name – probably using either the .com or .org top level. You do this through a domain registrar. Shop around. You should be able to get good service for $10 a year per domain. I use gkg.net, but there are plenty of others. You may have to try several different domain names until you find one that is not taken already.The registrar will ask where your domain name servers are located. You might not know yet, until you do step #2. In that case you can “park” your domain with the registrar, which means the domain name belongs to you, but for the moment, it points to the registrar.
- Choose a web site/email host. There are a gazillion of these. Ask for referrals from friends and on the ASHMUG list. The bluehost.com chosen by our web team may be a good solution but there are lots of others.
- Based on the instructions from your new web site host, go back to the registrar and change the settings so that your name servers are the ones specified by the host.
…or… sometimes you can go to a full service web host, and they will offer to take care of everything for you, including registering the domain name. In this case, just make sure your domain name is registered to you and not to the web host. You need to own that name, so that you can move it whenever you like and not be locked into a single web host.
Using a web developer…. If you are starting a web site from scratch and getting help from a web developer, they may offer to set up your domain for you. Just be sure that they register the domain in your name, and not theirs. They can be listed as a technical contact, but the Registrant/Domain owner needs to be you.
Glossary
Domain Name – your person, unique “English looking” web address. e.g. ashmug.com
Top Level Domain – the various .com, .org, .gov, .tv choices that suggest what kind of organization you are. No guarantees, though – no one checks.
IP Address – the numerical address for either your web hosting server or your email server. e.g. 74.220.219.69
Registrar – a company that is authorized to reserve and register domain names. This is your first step on the process of getting your own domain.
Name Server - this is a special server that is often provided by your web host, and which tells the rest of the Internet where to find your web pages and email boxes. e.g. ns1.bluehost.com
TidBITS: Apple News for the Rest of Us
- TidBITS Watchlist: Notable Software Updates for 20 February 2012 February 20, 2012
- Default Folder X 4.4.9 February 20, 2012
- VLC 2.0 February 20, 2012
Daring Fireball
- MLB Simplifies Pricing for iPhone and iPad Apps February 22, 2012
- Dell’s Predicament February 22, 2012
- Helpful Tip for Messages for Mac Beta Users With Mac.com AIM IDs February 22, 2012