Posts Tagged ‘html’


Tuesday, July 6th, 2010

XHTML is barely more than a clone of HTML written in XML. To put it in other words, XHTML is the XML serialization of HTML. There should be no differences in the Document Object Model between two documents written respectively in HTML and XHTML, if both are well-written. There are several polyglot issues, such as XML namespaces, which HTML5 allows for the sake of intercompatibility between the two serializations.

What are the differences, then? What should you use?
As with most things, it depends entirely on your circumstances and goals. I’m a programmer, so cleanliness and predictability is more important than ease-of-writing. When you mark your pages up in XML, you gain certain benefits: the ability to add MathML, SVG, RDF, and other XML technologies (though MathML and SVG are included in HTML5); the ability to use XSL transformations; and the ability to read your files into the browser with JavaScript to parse and display certain pieces.
When writing in plain HTML the browser is watching over you, and your code will work even if something is a bit wrong. You rarely need to test, and can throw whatever garbage you want into your page. In short, you can do the kind of stuff that gives programmers nightmares (and also funds quite a bit of their work).

So that’s where it is. People with no experience can still create content for the web, while anyone who wants to say they know how to code (even if they only code markup, rather than program) must adopt proper coding standards.

Essentially, XHTML is HTML. If a ‘programmer’ is learning HTML, the X can be assumed. There is no reason to even mention XHTML anymore, because (beyond a few quibbles) the markup a programmer writes and the markup someone else writes should build the same DOM.
They are learning to mark up hypertext. The serialization is only a detail, for advanced usage. Even the new doctype is the same for both HTML5 and the XHTML serialization of HTML5. (I’d say XHTML5; but that’s a misnomer, as it is actually XHTML 1.0.)

Now, the argument between text/html and application/text+xhtml is another story (and is XHTML 1.1 rather than 1.0), and one that I should delve deeper into in a later post. But as far as naming goes, for standard code being served to a browser with no special headers being changed, the X in XHTML is little more than a name.

To-Learn (As Opposed to To-Do)

Monday, March 22nd, 2010

I caught up with my reading again.

With nothing on my mental To-Do list (except such vague ideas as ‘work on something’), I’ve had the opportunity to do random stuff. I picked through my To-Read bookmarks, where I put everything when I was swamped with reading. It turns out a lot of that becomes completely useless to me, after reading a thousand other things over the last few months, so most of it can be deleted. Other things required me to have time in abundance, so that I can research some topics and possibly apply a few ideas.

While I was doing that, I decided that the only way I was ever going to learn the stuff I didn’t feel comfortable with was if I spent some time using it.
I want to know absolutely everything about HTML, but I don’t even know about half of the elements and attributes. So, I’m going to use it all; I’m going to memorize the big list of things (199 elements, at the moment).

I’m currently going through a whole smack of W3C specs, and a few Wikipedia articles. I’m going to find every proprietary tag I can, and try to find out which browsers use which.

You see, I constantly feel as if I have nothing to contribute. I don’t have any opinions of my own, and when I’m reading about all sorts of HTML things and the authors of those pages ask questions, I’m never able to add anything they don’t already know.

Things I need to know:

  • How browsers work, on the code-snippet level
  • All the differences between at least the main five browsers
  • All the differences between versions (Firefox 2, for example, doesn’t support display: inline-block)
  • What the heck all these RFCs are
  • The ability to quote an RFC’s requirements
  • The current issues in the HTML5 and WHATWG working groups
  • All the different types of ‘accessibility’ (blind, paraplegic, cognitive)
  • User psychology, UX, and other human-brain things
  • All the different ways to do things (javascript, server-side, different languages)
  • Different ways of coding (lisp-style, queries, procedural)

I need to learn the internals of:

  • JavaScript
  • HTML
  • PHP
  • Perl
  • Java
  • C
  • Ruby
  • Erlang
  • Clojure

Where I’m at right now:

  • I know roughly how browsers do what they do
  • I know some obscure browser trivia
  • I’m part of the W3C HTML5 lists, and am trying to keep up-to-date
  • I’ve got a base in A11y and UX
  • I know a lot about HTML
  • I’ve got some Java, PHP, and JavaScript under my belt
  • I can name a good deal of the more obscure browsers

I’ve still got a long way to go.
I want to teach this stuff, at some point. That means I need to know everything. All the tiny, obscure details. I need to know that the SVG 1.0 spec says that negative attributes are an error, while the 1.1 spec says that negative attributes are ignored.

It’s kind of funny how things go. My whole life, I loved computers. I wanted to design games, when I was young. I went into programming in high-school. I took a computer-based diploma program in college, and graduated in 2007.

I remember my online journal, which I created in 2005. I had no idea how to make links, or emphases, or any other stylization. But I learned how to make links, and then how to embed images. I took a class on HTML, and then one that included CSS, and then I made a couple half-hearted websites.

In 2009, I abandoned almost all that programming stuff and flew headlong into HTML and JavaScript and CSS and websites. I spent a great deal of that time designing, rather than programming.

When you find something you want to do, you’ll notice. But you won’t know what you want to do until you find it.
So try everything. Find what you want to do. Then learn everything you can possibly learn about it.

Photo Gallery

Thursday, May 21st, 2009

I just finished more work on the old Atomicat Photo Gallery.
I was working for him last year, basically, at the same time as I was take what was essentially my first every-twenty-years-vacation. I figured I’ve been going to school since I was four or five, and I’ll probably be working until retirement, so I might as well take a year off to do some other stuff.

The site was the first website I’ve ever designed, and went through a couple drastic redesigns. I created the modern logo, which I’d say is fairly decent, and experimented with things like floats and whatever else.
The CSS on that site is disgusting. I didn’t really ‘get’ the id attribute, and so I had classes in every little thing. Extensibility was fairly unneeded, so I would end up creating a little class to do one thing, and then paste that on whichever element needed to do that. The result was something like HTML with half the semantics of HTML. Is <div class=”floatl”> any better than <div style=”float:left”>? It seems I’d completely ruined the core idea behind CSS.

The gallery was something else: Hours upon hours of hand-crafted goodness, as from a seamstress who turns away the sewing machine to make each careful stitch with her own sure hand.
In short, it was a mess. There were eight pages to be taken care of, each with images that had to be named specifically for that page. Any images you wanted to add had to be specially named for yet another page. Each item had to have the name/description engraved in the html, to be passed in an ugly GET variable.
Tonight, I went through the motions of creating the database and putting everything in it. I took every bit of repetition in the gallery and put it in loops. The gallery went from seven pages to one; the page went from eight individual items to two (I could probably turn that to one); and that item or two is loaded in from SQL.

I guess I’ve still got to do tags, but I’m finished for tonight. I’ll have to eventually upgrade the entire site up to my current standards, and then upgrade it again to the standards I’ll have by the time I’m finished.

This is shaping up to be quite a year.

Designing a Website, Part 1

Thursday, May 14th, 2009

The design of a website is an amazing thing, so I thought I’d share some of my method when it came to developing my new business site, Cozy Cabbage. It’s not complete, yet, but I’ll link when it’s finished.

The first thing I wanted to talk about was the content.
When I was writing about myself, and about the sites I’ve made, and drawing up what it means for someone to employ me (in a much less hokey-sounding way, of course, than it seems as I write these words right now), I realized I hated to use ‘I’ in my sentence structure. I suppose there was just something a bit too personal, in that; something, also, that might suggest very human flaws. On the other hand, I couldn’t exactly say ‘we’ and ‘our’, because it was only me.
In the end, I settled on using none of that at all, and I realized how fun and challenging it is to write something like that. “My services include–” No, I can’t say ‘my’. I say things like, “Work is done on a weekly basis,” instead of, “I do work on a weekly basis.” This shifts the active noun to the work, instead of to me, which I think really brings it out. It’s one of those things I hadn’t consciously noticed until I did it by accident.

The rest of the content is pretty simple: A very brief description of who I am, just in case people want to know. They’re there to find someone to make a webpage for them, so I’ll get right to the details: Samples, to let them know what kind of work I do (nothing great, at the momet — I have to completely redo a site I haven’t touched since last year), then what I’ll do if hired. I’m then adding a longer ‘about’ at the end, which outlines my work ethic and personal co-operation attitudes. There’s a little footer with some legal whatevers. On the top of the page is my logo, title, and three links: The main page, sample sites, and my HTML business card. In place of a contact sheet, I have a buy button. The buy button just won’t do, past this moment. I’ll end up making an actual order form.

On the design end, things were a bit different and mostly mundane. The original idea was to use cabbage and make the site ‘cozy’. I’m not sure how I intended to make it look cozy, but I’ll probably end up trying within the next couple of days. For now, it’s somewhat fresh and not too shabby. The site is very vertical, with improper use of sections below the header, and no sidebar, but I’ll probably get around to that next.
Overall, I just had a bunch of trouble with those floats, which you may have read a few days ago.

Another thing I want to talk about is fluid widths. I haven’t started on grids, yet, but there’s always been something disagreeable with fixed widths. Lately, I’d been keeping my browser at 640 wide, because I can easily set the window to a third or a half of my screen. Once I started looking at all these design blogs, it became quickly apparent that I’d have to switch to 960, though I still have a small horizontal scrollbar.
So I’ve decided that even 800×600 is too large, and it should comfortably fit down to about 300 pixels or so. I end up using variations on max-width and min-width and width percentage, which ends up giving me a great deal of control. If I wanted to use several divs inside each-other, I could even give the box a tremendously flexibly design. I could probaly make it shrink or grow as you increased your browser window. The next step would be to strategically place floats so that you get an extra column if you have a wide enough window. At the moment, you just get some more whitespace, which is always welcome.
I also try to keep my images scaled, because I don’t use full-page zoom, and want to design for others who don’t. The problem with this is images that have percentage width can’t seem to scale with text. I’ve been trying to work my way around it, but I may just have to choose one or the other.I could possibly set a maximum size with an EM-sized div, and then size the actual image with percentage. The max-size on the image, of course, would be set to about 200% of the image’s file dimensions, so it doesn’t become too grainy.

And I haven’t even started on the event layer, or whatever javascripting is called. I’ll also put some server-side stuff in, as well.

I’m researching Python and Django. It looks interesting.

Business Cards

Tuesday, May 5th, 2009

A couple days ago, I saw two business cards laying on my mom’s desk. One was for a dentist, and the other was from some sort of hair salon. A quick look revealed that the dentist’s business card had a logo with simple shapes and soothing colours, a clean finish, dithered CMYK inks, clean-cut edges, a good weight, and well-positioned elements. The hairstylist’s card, meanwhile, had an unmemorable logo, was printed from a poor-quality printer (which left everything slightly smudged-looking), was printed on tear-along-the-lines printer stock from an office supplies store, and had elements of dissimilar style centered down the card. The images also had pixels sticking out.
It’s tremendous how the fine quality and subtle hues of a professionally-made card set it immediately apart from something home-made. I imagine people forget that their printers might print at 300 dpi, even though their images are saved at 72 dpi. Pixels, JPEG artifacts, and smearing are all things that are completely unacceptable, and which are instantly recognised by a great many people.

I’ve designed a few business cards, each one better than the last — and all of them mediocre at best. I also had the job, once, of designing a little 1-inch-by-3-inch advertisement for the local news pamphlet. It started out fine, and I was left with what I saw as an acceptable product, as I viewed the large text on my thousand-pixel-wide photoshop image. I tried to zoom it down to approximately the size it would end up being, but the program would have trouble rendering the fonts into the space of a few pixels — my screen’s density was just far too low. Even with the chopped up characters, though, I could easily see that the text was far too small, and everything was too squished. I scaled everything up, until it looked fine. I sent it off to print, but when I saw it in the paper a few weeks later the text was still smaller than most of the other ads. I had crammed too much content into too small a space, and I wonder if I had missed an older customer because of that.
Lately, too, I was trying to fix up a couple things on my current client’s business card, and was having trouble showing him how it looked. He had designed it in a portrait view, which means only half of it fit on my screen at any given moment. If I shrank it to half size, at which point it fit, some of the smaller details, such as thin lines, would become anti-aliased or disappear.

I decided, then, that there was no reason I had to use an image-editting program. I could created a page in XHTML and style the elements with CSS.
I started, of course, by creating the area of 3.5″ by 2″ at 72 dpi. I sized everything in ems, so that I can change the size to whatever I want and everything will scale. The text, of course, will scale unendingly. I had an extremely large version of my logo, so I used that in an img element. Background-image wouldn’t work, here, because I wanted to be able to set the width and height.

While I was designing my business card, I kept an eye open for lessons. When I started arranging the company name, the tagline, my name, and the contact information within a series of header elements, I quickly realized the pixelated structure of importance denoted by h1, h2, h3, h4, h5, and h6. I’ve always known about them, of course, and used them in my pages, but it wasn’t really until this moment that I truly understood their importance in communicating to the user which piece of information is given priority.
When I saw this, a couple questions came floating along: Which is the most important? My company’s name, obviously. But what about my tagline? Is that more important than my name and job title, or less? Is it alright to decrease the font size of my tagline to keep it the same width as the company’s name, or would that send the message that it’s less important?
Even then, that’s just one facet; The shape and position will also draw certain suggestions around them. I haven’t really played with fonts as much, this early in my career, but I’ve seen how others use them. You can use a font to emphasize an element at the same time as you make it smaller, which helps with positioning. I think that’s one thing that drew me to design: You have such a tremendous range of completely different attributes that you can apply to each element, and each one has the power to change the perception of that element. What you’re left with is the equivalent of tossing spices into a soup: Too much and the soup can’t be tasted through the spice, while too little leaves the soup bland. A tremendous difference is found between cooks who know how to spice their food and cooks who don’t.

I like the spacing on the card, but there was a moment where I decided the city/province/country just wasn’t important enough for the card. I did keep the city and province, but stuffed it in the corner. I find it actually helps balance the elements a bit, too.
Other than that, there were the tricks of getting everything to line up how you want. I saw that my text naturally flowed around the shape of my image, so I kept those nestled.

And now I’ll try to use what I made in that twitter post a few days back:
My very own business card, fitted with hCard.