XFN™ (XHTML Friends Network) is a simple way to represent human relationships using hyperlinks. In recent years, blogs and blogrolls
have become the fastest growing area of the Web. XFN enables web
authors to indicate their relationship(s) to the people in their
blogrolls simply by adding a 'rel' attribute to their <a href> tags.
Version 1.1 of the XFN meta data profile: the list of the values used in XFN with their significance. See the XMDP home page for more information on XHTML Meta Data Profiles.
A collection of tools, templates, editors, communities, and other resources that let you edit XFN information. Includes the XFN Creator, among many others.
For too long HTML email has been the ugly step-child of the web. It's time for a change, so we teamed up with some seriously talented designers to bring their skills to the world of HTML email.
Every template has been thoroughly tested in more than 20 of the most popular email clients like Outlook 2010, Gmail, Lotus Notes, Apple Mail, the iPhone, and more. They're ready to roll and are completely free.
Draw on any webpage. Share your ideas
Capture your thoughts quickly and easily by drawing on any webpage. Share your ideas with coworkers, colleagues, and friends. MarkUp works in your browser, so there’s nothing to download and install; just drag the Get MarkUp icon into your bookmarks bar. When you want to make notes on a webpage, click your bookmarklet to load the MarkUp toolbar. Publish when you’re ready to share your thoughts.
Generating HTML with JavaScript has always been ugly. Hella ugly. It usually involves writing streams of hard-to-maintain code which just concatenates a bunch of strings together and spits them out in an ugly mess.
With Jaml, we can do exactly that. Jaml is a simple library inspired by the excellent Haml library for Ruby. It works by first defining a template using an intuitive set of tag functions, and then rendering it to appear as pretty HTML.
All we need to do is call Jaml.register with a template name and the template source. Jaml then stores this for later use, allowing us to render it later using Jaml.render(). Rendering with Jaml gives us the nicely formatted, indented HTML displayed above.
Jaml currently sports a few hacks and is not particularly efficient. It is presented as a proof of concept, though all the output above is true output from the library. As always, all of the code is up on Github, and contributions are welcome
Jaml would be suitable for emulating a Rails-style directory structure inside a server side JavaScript framework – each Jaml template could occupy its own file, with the template name coming from the file name. This is roughly how Rails and other MVC frameworks work currently, and it eliminates the need for the Jaml.register lines. Alternatively, the templates could still be stored server side and simply pulled down and evaluated for client side rendering.
Safari and Safari for the iPhone support all HTML elements, including deprecated elements and even some proprietary elements that were never part of any W3C specifications. In addtion, Safari supports some HTML5 elements, even though the HTML5 specifications have not been finalized.
SlickMap CSS is a simple stylesheet for displaying finished sitemaps directly from HTML unordered list navigation. It’s suitable for most web sites – accommodating up to three levels of page navigation and additional utility links – and can easily be customized to meet your own individual needs, branding, or style preferences.
The general idea of SlickMap CSS is to streamline the web design process by automating the illustration of sitemaps while at the same time allowing for the predevelopment of functional HTML navigation.
MHTML is MIME HTML, or if you insist on me spelling it out completely is like "Multipurpose Internet Mail Extensions HyperText Markup Language". In short it's HTML but like email with attachments. In one "multipart" email you can have several... hm, things - HTML version of the email, text-only version, attachment, another attachment...
MHTML is the same but for HTML. In one file you put a bunch of stuff (e.g. image files) and you save on the precious HTTP requests.
Editorial note: If you’ve been following my tweets in the past 12 hours you’d have seen me hinting at something very cool for web developers coming out of Microsoft’s MIX09 event today. Well, it’s still at least 3 hours until MIX but it appears Microsoft’s own Expression Web team blog has let the dogs out early (their server is set to to New York time, not Las Vegas time), so consider the NDA broken
“Expression Web SuperPreview”, the name is typical of Microsoft products, it’s technically self-explanatory but mind-numbingly bland and ridiculously long.
To make matters worse, the beta being released today - a subset of the full release coming with Expression Web 3 - is called “Expression Web SuperPreview for Windows Internet Explorer”. Granted the name is not that important for a developer tool, a kickass one at that.
Every web developer today faces the challenge of checking website compatibility across a large pool of browsers and browser versions in the marketplace. Up and until now, either you could install every browser, verify the website via a visual inspection and debug with tools specialized to that browser, or you could send a URL to a third-party screenshotting service like BrowserShots for an all-in-one visual inspection. The former is messy and tedious but gives you more control and an opportunity to diagnose problems, whilst the latter is simple but slow and useless to fix the problem. Needless to say, SuperPreview is the best of both worlds.
Note: The following screenshots come from a newer unreleased internal build of the application and does not reflect accurately what you can do in Expression Web SuperPreview today. Please don’t hurt me. I like kittens.
SuperPreview as a tool allows you to compare different rendering engines in a single unified interface. Simple clicks gives you comparisons between Internet Explorer 6, the native version of Internet Explorer installed, other browsers you may have installed locally - Firefox 3.5, Safari 3, Safari 4 - and even an bitmap images of website prototypes.
Pushing the envelopes a little, Microsoft is also building in support for remote rendering, such as those on different operating systems even. Details about this feature is not entirely clear at the moment, but I would expect this to be more advanced than just an image rendering.
On top of just a visual inspection, you have a standard set of modern HTML debugging tools like a DOM inspector, CSS inspector, element highlighting, pixel rulers and guides.
And perhaps what I think is the coolest feature, an overlay mode to compare exactly what’s different for pixel-perfect alignment. Or if you cross your eyes, the web in 3D.
Finally, how you can get your dirty web developer paws on this awesome tool, and it’s a little complicated to say the least. The beta of this software available right now is downloadable from Microsoft.com (250MB). The catch being it only supports renderings between IE6 and versions of IE installed on your computer already, but it should ease the pain of testing for IE6/7/8 compatibility for a lot of devs.
The full and final version of this product will be bundled together with Expression Web 3, sometime later this year and will run as a separate standalone application. Unfortunately for the many Mac web developers out there, because Expression Web is not an application part of the Expression Mac suite, SuperPreview will not be available.
How do you scale CSS for millions of visitors or thousands of pages? Nicole first presented Object Oriented CSS at Web Directions North in Denver. Since then, the response has been overwhelming. OOCSS allows you to write fast, maintainable, standards-based front end code. It adds much needed predictability to CSS so that even beginners can participate in writing beautiful websites.
Two main principles
Separate structure and skin
Separate container and content
Getting Started
Download all the files and set up a local directory
Open template.html (this is the basic template you will modify to create all other pages).
Set your left and right column widths by extending the column objects
Use grids to break the page up further into smaller sections.
Test your site functionality by adding content objects from the content.css file. These can also be found in library.html.
Ryan Doherty has one of those really nice articles that walk you through how to do something that should be easy in CSS but isn't, until you know how: Cross Browser Inline Block.
Until some future version of HTML gives us new native controls to use in a browser, at Google, we’ve been playing and experimenting with controls we call “custom buttons” in our apps (among other custom controls). These buttons just launched in Gmail yesterday, and they’ve been in Google Reader for two months now. The buttons are designed to look very similar to basic HTML input buttons. But they can handle multiple interactions with one basic design. The buttons we’re using are imageless, and they’re created entirely using HTML and CSS, plus some JavaScript to manage the behavior. They’re also easily skinnable with a few lines of CSS, which was a key factor now that Gmail has themes.
I thought it would be interesting to provide a portion of the background on our buttons here, and discuss some of the iterations we’ve been through so far to get to the current state.
Background
Today’s web apps allow increasingly complex interactions. Users can view, create, manage, and manipulate all kinds of data, from email messages to feeds to photos to blog posts, or even choosing what their DVR records on any given night. We’re at the point where these apps need something beyond standard HTML form controls and basic hypertext links to represent the actions a user can take.
A basic could be used for single actions, a could be used for selecting mutually exclusive options. But we’re left with no way to represent other interactions common in desktop apps. Such as a checkbox that represents more than just on or off. Or the use of auto-complete to refine or narrow the options in a drop-down menu. On top of this, the controls we can render have significantly different appearances across browsers and platforms. Even within a single browser, buttons and select menus have quite different designs.
Enter: the concept of custom buttons.
The first iteration
Not long after I started at Google, I remember seeing mockups for a new product that eventually become Google Spreadsheets. The mockups I saw used simple buttons that looked similar to default HTML buttons in certain browsers. But they were subtly different than any default buttons I had ever seen before. The giveaway was seeing three buttons sandwiched together to make a pill button:
At first, I thought they were just generic browser-agnostic representations — and wishful thinking for the appearance — of actual HTML buttons. But once we started using an internal-only version of the product, I realized this button design actually got built into the product. That was fine. But I cringed when I realized how the buttons had been implemented. Each button was set up with a nine-cell table so they could place each corner image, and still allow the button to expand in all four directions according to the width and height of the text inside:
Eliminating the table and corner images
I knew there had to be a better way to render these buttons than using tables, and especially nine-cell tables just for the tiny little corners. So I tried creating a few prototypes to improve our button code. My first button attempt, which I named Custom Buttons 2.0, (version 1.0 would be the nine-cell tabled version done by one of our engineers) used a similar trick that I used for event chips in Google Calendar: the top border was one element with 1px left and right margins, the middle of the button was another element with left and right borders, and the bottom border recycled the styles of the top border with 1px left and right margins. This created a one-pixel notch in each of the four corners, giving the subtle illusion of a small rounded corner.
That 2.0 attempt was fine, and worked pretty well (as I expected) in almost all browsers. But it required that each button as a whole either be floated or positioned absolutely with a width. I wanted a set of buttons that could be treated as inline elements, and that would take up as much horizontal space as the text inside each button needed.
Going inline
My 3.0 attempt relied on treating the buttons and everything inside them as inline elements. The top/bottom borders still needed to be rendered separately from the left/right borders to get 1px-notched corners. The left/right borders were rendered on the outer element. The top/bottom borders were rendered on the inner element. Because borders don’t compound and add to the width or height of an inline element, we get the 1px notches in each corner. I ran into a lot of frustration with this inline approach until I remembered display: inline-block. That seemed to solve everything at once.
A demo page for Custom Buttons 3.0 shows my progress to this point. As you can see there, I built in affordances for changing the border color on hover, and for reversing the gradient direction for the active/click state to make it feel like the button is actually pressable. I also attempted to show how we could sandwich multiple buttons together to form a pill button. The pill button wasn’t perfect — I didn’t want gaps in the top/bottom borders between each button. But it was a start.
The magical inline-block solved everything, except in IE. That’s where the genius of Google engineers came in. They knew how to get tricks working in all browsers, and this technique interested a couple of them enough that they dedicated the time to make it work.
So 3.0 buttons were fine. After some modifications by our engineers, they made it into live production code. I believe 3.0 buttons are currently still in use for edit buttons in Google Sites, and in editor modes for Google Docs. (As of this writing. Expect those to change in the near future to buttons described below.) But I was still bothered by the requirement of a background gradient image. Not only was this an extra request to the server, but if anyone wanted to change the colors of a button, they’d be required to create a new gradient image. This wasn’t flexible enough, in my opinion, and I thought we could push further.
Eliminating the gradient image
Instead of rendering the gradient with an image, I thought we might be able to simulate a gradient with a few bands of color. With a few light grays laid beside each other that were close enough in value, we’d get something that looked like a gradient. With only two bands of color, I got a glossy-looking button with a sharp division between the two bands of color. Not what I wanted. Adding a third band of color between the first two colors blended each color together better. So three color bands it had to be.
To get that band of color and fake the gradient, I had to insert one more element in the button code. I chose because it was short, and semantically, it didn’t mean anything. That element was absolutely positioned, so it could live inside the button and behind the text without affecting anything else. For the button itself, I used the almost-white #f9f9f9. For the element I used #e3e3e3. The element was absolutely positioned to the bottom of the button, and given a height of 40%. To get the middle band of color, I added a top border of #eee to the element.
Another demo page for Custom Buttons 3.1 shows my attempt at getting this pseudo-gradient to work. It works in Firefox and Safari, and probably a few other modern browsers. But not everywhere. It was never perfect, and I don’t recommend using it in production code. Again, I couldn’t get this working right in IE. Google eng to the rescue again. To see the final code we ended up using in Gmail and Reader, you’ll have to reverse engineer the button code in one of those products.
Sweating the details
If we were going to undertake the task of recreating basic HTML form controls, we knew there were a lot of details that need to be accounted for and thought through. Like all the possible states of a button: resting, hover, focus, active, toggled-on, and disabled. There are also the accessibility ramifications of creating non-standard controls. I’m sure we haven’t factored in or solved every access issue yet. But engineers are working on that. Here’s a glimpse of the many states and types of buttons, along with the visual specs we had to think about and create if we were really going to replace default buttons and menus:
Major credit
I certainly didn’t create the concept of custom buttons at Google. Nor did I write the final code that made it into production. I merely initiated a couple steps to improve the methods we use to render custom buttons. My portion of the iteration is what’s documented here. There were many other steps in making these buttons a reality.
These buttons never would have made it into production code without the help of several Google engineers. One of the primary aids, Emil Eklund, helped fix a lot of my code for these custom buttons, and got it working in the browsers Gmail supports. He just posted an entry on the Official Gmail Blog yesterday about the label and folder-like functionality behind the new buttons in Gmail. Two developers (no longer at Google) also contributed heavily to the original button code: Ryan Carver and Greg Veen. They deserve huge props too.
Even more credit for the launch of these buttons in Gmail goes to one of the Gmail designers, Michael Leggett, who dreamed up all the fancy new functionality and interactions behind applying labels. Michael gave me lots of feedback and suggestions as we were building the original specs for 3.0 and 3.1 buttons. He also created countless iterations of the button interactions for Gmail, and endured numerous reviews and feedback cycles to finally get them launched in the product. If you like the new labeling menus in Gmail, Michael is the one to thank. The menus are especially slick if you use the new v and l keyboard shortcuts, along with auto-complete to apply labels (and even archive at the same time) without ever touching your mouse.
There are numerous other designers, developers, and engineers at Google who touched these buttons at one point or another. They all deserve credit too. I’ve only given props to four of the most prolific people who made these buttons a reality.
These buttons don’t permeate the entire Gmail or Reader interfaces yet for all browsers. (e.g. Compose view is still using default buttons for older WebKit browsers.) But now that these buttons are reusable components, expect to see us using them in more places throughout Google as we find good uses for them.
An Explanation of the DOCTYPE Identifier A typical DOCTYPE you might see on an HTML document is the HTML 4.01 transitional DOCTYPE. The DOCTYPE isn't exactly an HTML tag or XHTML element. Instead it is a declaration and always appears at the very top of your documents.
A DOCTYPE is made up of the following parts:
!DOCTYPE The identifier. It indicates to the user-agent that the enclosed information will define the type of document of the page.
HTML The Top Element. This tells the browser what element to expect as the top-level element. For HTML and XHTML documents this element would be <html>
PUBLIC The Availability. The most common DOCTYPES you will use will be publicly available - "PUBLIC". But you can also specify a local DTD with the "SYSTEM" key word.
"-//W3C//DTD HTML 4.01 Transitional//EN" The Formal Public Identifier. This entire string is what identifies the DOCTYPE.
The FPI is made up of these parts:
- Registration. If there is a plus-sign (+) here, that means that the organization is registered with the ISO. A minus-sign (-) indicates that it is not registered.
W3C The Organization. This is the group that owns and maintains the DOCTYPE being used.
DTD The Type. This defines the type of DOCTYPE used.
HTML 4.01 Transitional The Human-Readable Label. This is the label that tells you what DTD is being used. It is written so that humans, rather than computers, can understand it.
EN The Language. This is the language that the DTD is written in. It is not the language of the content of the page.
The rest of the DOCTYPE identifier is optional:
"http://www.w3.org/TR/html4/loose.dtd" The URI. This is an optional URL indicating where the DTD for this DOCTYPE can be found.
To disable the image toolbar for a particular page on your website, simply add the following META tag to the HEAD section of your HTML document:
< meta_equiv="imagetoolbar" content="no">
The "no" setting disallows the toolbar.
Disabling the Toolbar on an Image by Image Basis
If you only want to prevent the toolbar from appearing for certain graphics on your page, you can disable it on an image by image basis.
For example, if you have a picture called "proprietary.gif", you can add a GALLERYIMG attribute to the image tag that you used to display it:
< img_src="proprietary.gif" galleryimg="no">
The "no" prevents the toolbar from showing. Setting it to "yes" allows the toolbar, and is useful if you have set the entire page to default to not showing the toolbar, and only want to enable it on an image by image basis.
Limitations
Note that disabling the image toolbar does not actually prevent visitors from saving your images, sending them to others or printing them. It merely disables the toolbar. Period. It is not a solution to theft of your graphics. Visitors can still right click the mouse on your pictures and save them from the right click menu, or save the entire page with all the images to their disk, etc (the list of ways to do this is very long). However, it is still useful for people who prefer not to have the toolbar pop out on the pictures appearing on their website. In fact, judging by the response of one very irritated IE user, who called the toolbar "that stupid IE image popup", you may even be doing your visitors a service.
“Expression Web SuperPreview”, the name is typical of Microsoft products, it’s technically self-explanatory but mind-numbingly bland and ridiculously long.
I knew there had to be a better way to render these buttons than using tables, and especially nine-cell tables just for the tiny little corners. So I tried creating a few prototypes to improve our button code. My first button attempt, which I named Custom Buttons 2.0, (version 1.0 would be the nine-cell tabled version done by one of our engineers) used a similar trick that I used for event chips in 
