HAT DOES IT MEAN???
This is a Daily Drop Cap from Jessica Hische. I encourage you to take a look at her typographical wonders.
Archive for the ‘New’ Category
Home
Web Design
Programs
Writing
Nintendo DS
Cozy Cabbage
-
You are currently browsing the archives for the New category.
Archives
Drop-Caps
Friday, August 6th, 2010XHTML vs HTML
Tuesday, July 6th, 2010XHTML 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.
On Curation
Tuesday, June 22nd, 2010As website owners and content creators, we have a duty toward the users of our content. When we blog about something, the information we throw to the world could very well become dated and wrong.
What Can We Do?
When you write about a modern topic, that post is almost guaranteed to become stale and useless, if it sits the way it is. As such, there are a few things you might do:
- Keep a clear separation between posts you’re willing to curate, and those that are simply snapshots of life (real blog posts)
- Set a kill-time for each (curated) post when you create it; after which it is no longer viewable by the public, and becomes hidden until you can revisit it and freshen it up
- Allow errata to be submitted to curated pieces, so that readers can help you improve the article
- Keep a list of the curated pieces, possibly by listing links to those pieces on a separate page
I’m thinking of doing the above with this blog. Some of the posts I’ve written won’t be useful in the near future, and others should be upkept so they always provide correct information. Perhaps I’ll implement these steps in the next iteration of my design.
The Awesome Foundation
Friday, June 18th, 2010I’ve started the wheels turning on this, so it’s time I talked here at length about my ideas.
The Awesome Foundation is an organization founded in Boston in 2009 to make things awesome. The idea is simple and powerful: Ten people come together, each donates $100/month, and the resulting $1000 grant goes to whichever applicant was judged to have the most awesome project.
To date, there have been grants given for microbial laser tractor-beams, a materials petting-zoo, bio-inks, peer-to-peer cellphone networks, grassroots mapping, and more, from chapters created in San Francisco, Providence, New York City, Boston, Ottawa, and London.
Now: I want to create one in Winnipeg. I’ve notified the Foundation, I’ve created a Twitter account, I’ve talked to the local creatives, and I’m writing this here. Things are falling into place, and I hope we’ll be able to give our first grant within the next two months.
There’s lots to do!
Pixies per Inch
Monday, June 7th, 2010Since the Apple event, everyone has been going mad over resolutions. The main difficulty, as far as I can tell, is that the subject has never been broached, and so people haven’t been told what to think.
“I’ve been using 100 dpi (or less) for ever years, and it’s suited me fine,” they say.
So, what is the resolution of the human eye? It’s hotly contested, of course, and there doesn’t appear to be a standard way of measuring. In general, though, you would measure a line pair to find the distance or the print size at which those lines blend together.
A quick test on my 100dpi monitor puts it at about three feet, for me. Other research has shown various measurements, such as about 125 line-pairs per inch at about foot. The important thing to realize is that those are line-pairs, not rows of pixels. You would need two pixels to render parallel lines, so the resolution is more like 250 dpi. This is the realm where the average human eye starts having problems, but there are, of course, many different edge cases where people could see individual pixels even at this resolution and this distance. 300 dpi has been accepted in popular belief as the general limit of human eye-graininess. If you want high fidelity, of course, 600 dpi is good. If someone were examining a material at close range, 1200 is better, though 2400 is probably what you’d want for anything of truly high quality.
So, as far as monitors go, 200 dpi is just fine at a length of two or three feet. Once you get one foot away or closer, as mobile devices usually are held, you’ll want something higher; at 400-600 dpi.
If you got a huge 1920×1200 display at only 200 pixels per inch, it would measure 2,264 pixels diagonally, which works out to 11.32″. At 224 pixels per inch, you could fit that into a netbook.
Of course, such technology could be prohibitively expensive, so we’re likely to stick with increasing the density of smaller mobile screens, for now. Besides; I don’t believe we have the infrastructure to be shuttling movies around in quad-HD.
Communication Design
Wednesday, June 2nd, 2010I was reading something Dave Seah wrote (davidseah.com; you may want to subscribe to him), and that got me thinking about basic things and definitions.
We’re all familiar with copywriters and editors. But what are they, really? In general, copy is text, though it’s usually used in a promotional manner. ‘Editing’ has a better description:
Editing is the process of selecting and preparing language, images, sound, video, or film through processes of correction, condensation, organization, and other modifications in various media.
A person who edits is called an editor.
Let’s boil that down:
Editing is the process of designing communication.
When you edit something, you’re designing it to fit objectives and requirements. What do you edit? Language, images, sound, video, or film? That’s all communication. As Wikipedia puts it:
Communication is a process of transferring information from one entity to another. Communication processes are sign-mediated interactions between at least two agents which share a repertoire of signs and semiotic rules. Communication is commonly defined as “the imparting or interchange of thoughts, opinions, or information by speech, writing, or signs”.
There are things we share with each-other: memes, shapes, sights, smells; other sensory stimuli. These can be wrapped as a whole and called ‘signs’. Some, like language, are incredibly rich and complex, while others are base and are shared by most humans. Some people have no access to certain signs.
A communication designer takes a message and designs it—readies it for a large, diverse audience and makes the message clear and understandable by encoding it with a variety of shared signs.
Zeldman’s ‘Three-Legged Stool’ Approach to Web Standards
Wednesday, May 19th, 2010Zeldman’s ‘Three-Legged Stool’ Approach to Web Standards
Introduction
Anyone who’s spent time in web design/development, and who belives in the magical (some would say ‘fairie-induced’) nature of web standards, knows about Jeffrey Zeldman. As one of the original standardistas, he’s given much thought to good content and correct markup.
The three-legged stool approach goes like this: First, you write your content. This is the stuff that the people are coming to your site to visit. Then, you support that content base with the three legs: Use HTML to structurize your content, to differentiate between emphases, titles, lists, paragraphs, and other important indicators of the content’s purpose. Use CSS to target each element and give your page its presentation with colour, depth, shape, layout, and uncannily-fabulous taste. Finally, use JavaScript to add behaviour to the site, so that it reacts dynamically to the needs of its users.
So there’s your introduction. It’s a well-thought-out approach to building your websites in a modular fashion, so that the pieces are easy to update and can be used across pages to reduce bandwidth.
This separation results in websites that are adaptable across many different browsers, platforms, and devices.
And then it gets tricky
There is no such thing as black or white. Using the <em> element to mark up emphases automatically styles it, as with most other elements. Some CSS pseudo-selectors change the page based on user input, as scripts should. JavaScript can very well do anything, which puts developers at risk of using it to set things that should have gone into HTML or CSS.
Where are the lines? Does it matter?
Practical Examples
In the HTML5 Working Group, there’s been a lot of fuss over some of the new elements being thought up. Accordion-style content? Progress bars? Calendar widgets? “Don’t those belong in jQuery?”
In CSS3, there’s also a bit of hubbub over the animations and transformations. When you can effectively code a movie using only CSS and a bit of HTML, are you going too far?
My Own Thoughts
Obviously, it would be snobbish to ban any cross-over between the three pillars. The question, then, becomes “why do we cross?” and “how much can we cross?”
Why use features in an unrelated stool-leg? Why, indeed. Hover effects or the like could be triggered with script, except that takes programming skill. The greatest argument I can think off the top of my head is that CSS is much simpler, in both syntax and complexity. Making simple animation loops is far easier in CSS3 than it is with JavaScript.
As well, those seemingly-action-based animations or hover or transformations may be entirely presentational, so it makes sense to put them in CSS.
When you get right down to it, the question is one of intent: Why is this element doing that thing? “Because it looks pretty.” Or, more realistically, “Because it fulfills a design requirement.”
So how much can we cross the streams? As designers and developers, it really isn’t up to us. Use class changes in your JavaScript to change the styles of elements, and use :hover if it fulfills an objective, but there’s little else to keep in mind. For the working groups, though, it’s an entirely different question.
Really, it comes back to the question of needs and uses. Canvas is a prime example; it’s only a big graphic, which makes it presentational, but it’ll likely hold valuable content, so it’s a main part of your page, but it’s implemented entirely with JavaScript.
And you can do so much with it.
Conclusion
We should be very careful when adding new mixes to the specification, but there’s no reason to ban that outright. Meanwhile, developers need only keep mindful of their reasons for implementing things the way they are.
To-Learn (As Opposed to To-Do)
Monday, March 22nd, 2010I 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.
Internet Explorer Drama… 9.0!
Saturday, March 20th, 2010With the latest IE9 announcements, designers and developers have been going mad with what one might call Internet Explosion.
Stuff like the following: (not real quotes; just paraphrasings)
“No!!11 Just stop developing IE!”
“Only Acid3 score of 55/100? Other browsers did that YEARS ago!”
“It’ll be five years behind!”
“We’ll have to support FOUR browsers!”
“I REALLY HATE MS”
“Why don’t you use webkit; Trident is dead.”
People are proving to be extremely closed-minded about IE. What I find very ironic is that a lot of them say things like, “MS, stop developing IE!”
That happened. They stopped after IE6, right at the end of the Dark Ages. And you see what life became?
About five years later, they picked up the pieces and race to bring IE into the future. IE7 is still annoying, but IE8 (released in early 2009) is a perfectly good browser for its time. IE9 should be competitive, with basically everything being clamoured for today.
A few misconceptions
There have been a host of ill-conceived arguments. I’m just going to list every correction I can think of:
- Acid3 has little to do with compatibility. It tests edge cases, in a sort of wish-list for developers. It can be important for high-level cross-browser online applications, but you really wouldn’t tell a difference between browsers in a regular web-page.
- Firefox has historically had a fairly ‘low’ Acid3 score, with 71 in Fx 3.0. The Firefox team has even said something like, “We aren’t going to bend over backwards for it, because it’s not really what we’re aiming for.”
- IE8 is soaking up both IE6 and IE7; and you don’t have to ‘support’ IE8 in the same ways as IE6 and IE7, any more than you have to ‘support’ Firefox or Safari or Chrome. Things tend to test pretty well in them, by default. IE9 will be similar.
- There is a non-negligible percentage of users on Firefox 2, Firefox 3, and Firefox 3.5. Nobody is complaining about supporting four different versions of Firefox. Thankfully, Fx2 is almost dead.
- Even two years ago, CSS3 was nearly unheard of, and nothing had HTML5 features. Now a browser with border-radius and HTML5 video is five years behind?
The things we’ll be deciding in the next year likely won’t find their way into the final release of IE9; but CSS3, HTML5, SVG, and various other standards we never ever expected to find in IE are already there, with more to be added. It’s coming along. - Actually, IE9′s current compatibility score, as counted by the When Can I Use charts, is similar right now to Firefox 3.0′s July 2008 release — less than two years behind, in the context of every toy we’re asking for as developers.
- Trident is fine. When we speak of the Trident layout engine today, and we’re talking about IE9, then we’re talking about Trident in IE9, and that’s a perfectly fine engine. Overall, it’ll be lacking some features, but will not be holding itself together with duct-tape and paper-clips. There’s a difference.
- As a company, Microsoft has gone through some huge changes in its history. The Internet Explorer development team isn’t the same team who gave us IE6. Don’t harass them (the development team) for things they couldn’t have possibly helped.
Almost every current browser team has its demons to face. IE is no different, but we should look to the future with optimism. Help where we can, and condemn where we must, but don’t frivolously argue about things that aren’t relevant to today.
And maybe help IE6 along by preaching Progressive Enrichment, hmm?
Art, Design, and Inspiration
Friday, February 5th, 2010I went to school as a computer programmer (and analyst); and yet, when I started creating websites, I found that design was integral to anything I had to do.
When most people think of ‘design’, they think of art and imagery. They imagine a creative spout of inspiration that makes something ‘edgy’ and new and good-looking.
That’s not design.
Design is the intelligent application of goals around limitations and road-blocks. When you design a page, you’re finding a host of different needs and working with what you have to fulfill those needs.
In this way, design is inherently different than art. Artistic expression is all about reaching into your mind and somehow sharing that with the world. Design, in contrast, is about studying every facet of your work to determine what needs to be done, and how to make it work the best it can. It requires intuition and intelligence and an uncanny knack for seeing every connection.
Next time you’re making something, take a moment to think about how it’ll be used, and who’ll be using it. A good design will take you to whole new heights.