Coherence Labs

Category: TypeMetal

  • TypeMetal and Semantic Markup

    Posted yesterday and well worth contemplating if you write HTML: a Smashing Magazine article on HTML/CSS philosophy. Author Heydon Pickering briefly touches on one of the main issues that drove me to develop TypeMetal and make snippets-as-first-class-completions a key feature — the difficulty of remembering and consistently applying one’s own CSS “class” names — even as he proposes a strongly “class”-averse approach to markup and styling. Pickering’s objection to use or overuse of class attributes is a philosophical one, that’s well worth giving some thought to. My interest has been in solving the practical problem of how one can apply class-element pairings more easily and consistently, in cases where they’re an appropriate tool for the job.

    I find a lot to recommend in Pickering’s discussion, actually, even though I take a less strict approach to coinage and use of “class” attributes. I agree substantially with the general premise — it makes a great deal of sense to leverage HTML’s existing semantics, in preference to reinventing the wheel, wherever a suitable element exists for a given purpose. (Among other significant benefits, doing so tends to make your content more intelligible to screen readers.) And Pickering’s article does a great job showing just how far one can get, styling-wise, using CSS descendant and attribute selectors alone. I tend to favor that approach whenever it seems reasonable, but there are cases where I think it’s useful and appropriate to leverage the extensibility that HTML provides for, by developing and applying a consistent vocabulary of “class” names. The best approach to doing so, in fact, incorporates a respect for appropriate usage of HTML’s element set — employing “class” identifiers to add further semantic specificity to an appropriately chosen element that’s already in the right neighborhood of meaning. This means avoiding the generic <span> and <div> whenever possible, in favor of more meaning-infused elements such as <code>, <kbd>, <article>, and <section> (to name just a few). While I think the lofty goal of class-free or nearly-class-free markup is in great measure worth striving for, I also think there are inevitably places where it’s useful to be able to express concepts that HTML’s standard vocabulary doesn’t, and can’t be expected to, intrinsically provide for.

    In TypeMetal’s User Guide, for example, I wanted a convention for marking up the names of menu items — in large part, so that I could style them all consistently, and later restyle them at will, but also because being able to find or index menu item references might come in handy someday. HTML’s <menuitem> element being unsuitable, despite a name that might seem to suggest otherwise (<menuitem> is for commands that a page visitor can choose), I went with <strong> (to make menu items likely to stand out from surrounding text, even if one views a User Guide page without its accompanying stylesheet), annotated with a “class” attribute of “menuitem”.

    When you apply class-based styling like this, it’s a given that the class names you’ve chosen, while meaningful to you, are unlikely to mean much at all to Web crawlers and other software that isn’t versed in your particular custom styling vocabulary. That’s part of the tradeoff. My use of <strong class=“menuitem”> is an imperfect choice, but preferable, I think, to not annotating menu item names at all.

    There are many such cases one can readily think of, especially when you get into writing about specialized areas of knowledge. Each has its own objects of interest, that can be useful to identify with formal markup. When you have a writing tool that helps you develop and remember your styling vocabulary, and apply it easily and consistently across a body of work, the potential to do such things becomes much more feasible to realize in actual practice. That’s been a substantial part of my goal in developing TypeMetal, and an area where it’s become tremendously helpful to me. I’m excited to finally have it out in the world, where it can help other HTML authors to achieve the same productivity boost.

    I’d love to hear about cases where people find TypeMetal’s approach helpful, and how it might be improved to provide even more convenience and agility. Please feel welcome to tweet @CoherenceLabs, email “support” at coherencelabs.com, or post in the TypeMetal Support Forum! — Thanks!

  • Try TypeMetal for Free!

    We realize it can be hard to judge an editor without trying it firsthand. So have at it. We’ve just released a free evaluation version of TypeMetal.

  • TypeMetal 1.1

    …is now live on the App Store! This update adds a feature that I’ve understandably had many requests for: spelling and grammar checking! Let’s just say that in the course of living without spell-check, I’ve learned that I’m a much less consistent typist than I believed myself to be. If you’re in the same boat as me, or if you inherit documents from people like me, TypeMetal 1.1 will be a welcome update. (Not coincidentally, this update also brings spelling fixes to nearly every page of TypeMetal’s in-app Help / User Guide.)

    An interesting aspect of HTML is that it’s set up to allow for mixed-language documents, in which the language of each text run can be explicitly indicated using a “lang” or “xml:lang” attribute on an element that wraps it. You aren’t required to annotate your documents with these attributes, but when they’re present, TypeMetal 1.1 uses the language identification they provide to ensure that each part of your document is checked against a language-appropriate dictionary and grammar rule set. When explicit language identification isn’t present, TypeMetal can still usually make a good best guess based on the document’s content and your OS X language preferences. But if you’re writing mixed-language content, you might want to make a practice of applying “lang” or “xml:lang” attributes where appropriate, to assist browsers and Web-crawlers that might be able to take advantage of such language info. (Per the HTML 5 spec, by the way, the value for either of these attributes is a “BCP 47” language tag, which in common practice just means an abbreviation with optional region qualifier, such as “en” for English, “fr” for French, “pt-PT” for Portuguese as spoken in Portugal, “pt-BR” for Brazilian Portuguese, etc.)

    Grammar checking is mostly working in this build, with one glitch to watch out for: If you begin a grammar-check operation from a mid-sentence insertion point or selection, grammar-check may falsely indicate that you have a sentence fragment. Either disregard such indications or position the insertion point at the start of a sentence before initiating grammar checking for now. I’ll be fixing this in a future update, and I didn’t want to delay the release of spell-checking because of it.

    One thing I haven’t yet implemented in 1.1 is the red-underlining, continuous spell-checking that you’re probably accustomed to using in other writing apps. For now, you’ll want to remember to hit Cmd+; once in a while (especially before publishing), to check your document for suspected misspellings.

    Adding that nifty red underlining requires character-/glyph-level line layout information that the public WebKit API doesn’t currently provide. To date, I’ve managed to achieve a great deal without having to embed a custom WebKit build in TypeMetal, and there are numerous worthwhile benefits to sticking with OS X’s WebKit if I possibly can, but there are also things I’d like to do that seemingly can’t be done otherwise. So I face a decision point, that’s going to take a little longer to sort out. Manually-invoked spelling and grammar checking seemed worth releasing in the meantime, and I hope users won’t find it too inconvenient to revive the old Cmd+; habit as I have, while I do some further work on this.

    I hope you’ll enjoy this newest version of TypeMetal! As always, please feel welcome to bring questions and feedback to the TypeMetal Support Forum! — Thanks again for your support!