Tag Archives: HTML

PNHTagTest Now On GitHub

Posted on by
Reply

Taking a moment away from a truly busy summer of client work and other fun projects to bring you this little announcement:

There’s now a permanent home on GitHub for PNHTagtest, a little piece code that I’ve had floating around for ages as an aid for building and reviewing CSS on a project.

Sample of PNHTagTest contents

I’ve been starting every web site project with a document containing a mix of HTML tags and common markup patterns like nested lists, links found in headings, tables, blockquotes and pre/code blocks. The contents of the test file are meant to be copy & pasted into an html document, added as a page or blog post in the CMS de jour, injected via server side includes.

Meant to sit along side of your style guides, widget inventories or whatever tools you’re using to organize the site build, this document provides a place to go to review the styling, typographic conventions, and readability of a site in ways that standard dummy copy, such as a headline followed by 5 identical paragraphs of Lorem Ipsum text, can’t. Those pesky forgettable tags like sup, dl, and abbr that may not show up in a site’s content until 3 months after launch are all well represented here so you won’t forget to style them!

PNHTagTest was previously posted on this blog way back in 2006.

Pseudo Pseudo-Classes

Posted on by
6

Some of the most powerful CSS2 and CSS3 selectors defined in the specs are avoided by web developers because they’re not supported by commonly used web browsers. Sometimes in order to work around these shortfalls solutions with large overhead such as javascript libraries are used or code becomes littered with many specialized classes and sites become difficult to maintain.

Over time I’ve developed the habit of using specifically named class attributes to represent exactly where a pseudo-class would have applied. To aid in clarity and maintenance these classes are named with the same text as the name of the pseudo-class being represented:

  • :first-child becomes .first-child
  • :last-child becomes .last-child
  • :first-of-type becomes .first-of-type
  • :nth-child(odd) becomes .nth-child-odd
  • :o nly-child becomes .only-child
  • :empty becomes .empty

And so on.

Your Typical List of Links

Some of these classes I use on every site I build. First-child [or last-child] are particularly handy when dealing with horizontal lists or menus where you want different delimiters or padding around the items on the edges vs the items in the middle of the list. A simple example would be to use vertical borders to separate the items. If you put a left border on all of the items you need to find some way to not have a border on the left most item. In a perfect world the HTML and css would looks something like this:

ul li { float:left; padding: 0 1em; border-left: 1px solid black; }
ul li:first-child { border-left: none; }

<ul>
<li><a href="index.html">Home</a></li>
<li><a href="page2.html">Page 2</a></li>
<li><a href="page3.html">Page 3</a></li>
</ul>

Leaving no extra classes in the HTML at all. However, if your project must support browsers that fail rendering the above styles you’d update the HTML and CSS with the following simple additions:

ul li { float:left; padding: 0 1em; border-left: 1px solid black; }
ul li:first-child,
ul li.first-child { border-left: none; }

<ul>
<li class="first-child"><a href="index.html">Home</a></li>
<li><a href="page2.html">Page 2</a></li>
<li><a href="page3.html">Page 3</a></li>
</ul>

Remember, the class you’re adding should always represent exactly how the real pseudo-element behaves and thus the placement of the first-child class is important. For example you would not want to write the following HTML:

<ul>
<li><a class="first-child" href="index.html">Home</a></li>
<li><a href="page2.html">Page 2</a></li>
<li><a href="page3.html">Page 3</a></li>
</ul>

Even if you could style this example and the previous example to appear alike the danger is in the details. If in a later site revision you replaced the class selectors with the real pseudo-class selectors you’d wind up with totally different styling — in fact the pseudo-class version would apply to all the anchors in the list because they’re all first-children of their respective parent list item.

Legibility and Maintenance

Tossing classes into the HTML to have more ‘hooks’ to style with is nothing special. The key to these pseudo pseudo-classes working is the use of established names and established behaviors. Any developer can look at an element with class="first-child" and know exactly what it represents. Usage of words like “first” or “linkA” or “item1” might be used in the same ways, but they might not evoke the exact same meaning. Perhaps the “link1” is the first link, but it may not be the parent elements first child. Or perhaps one project will use an “even” class on alternating list items, where another might call them “off” or “alternate”.

So there’s power in the distinction between “linkA” and “first-class” and there’s time saved by setting coding standards up front.

What about Pseudo-Elements?

CSS3 pseudo-elements are a bit trickier to duplicate by using using class attributes alone. But the principle of standardizing on the use of class names that are similar to the items they’re replacing. If I wanted to stylize the first letter of a paragraph in some special means I’d use a css selector such as p span.first-letter {} and the necessary HTML to match instead of picking some other class name out of thin air.

Remember, the goal of pseudo pseudos is that there is a predefined behavior that you wish you could leverage, and you’re just looking for a way to duplicate that behavior in older browsers with the minimal amount of overhead and maximal amount of clarity and simplicity.

Further Reading

What Does X-UA-Compatible Mean For Me?

Posted on by
2

So here I am a couple weeks after the IE team announced through a variety of different channels their proposal to help cushion the blow of their next browser release through the use of a META declaration and HTTP header, “X-UA-Compatible” describing what browser(s) the page and its associated styles and javascript files target.

I’ve got plenty of thoughts on why vendor extensions and related adjustments to behavior are bad. I also have some concerns over this one in particular. Extensions, and more general workarounds and hacks of all kinds [vendor driven or not] get buried into code, reused, copy and pasted, dropped in application templates, removed by accident, and generally used by people who don’t know why they’re doing it, but instead just because it works. As anything other then a very temporary, one time use solution this doesn’t seem to me to solve any problems that are inherent with either web standards or an ecosystem where content publishers are open to who they let see their content. But let me not get too far off onto that tangent and consider first that the proposed solution goes through.

For the moment I want to focus on the practical — what does the additional rendering mode and the ability to switch to it via META declaration mean to me as a working web developer?

There’s been lots and lots of discussion of the proposals via blogs, mailing lists and other forum, but they’ve focused on either how the proposal was raise and whether its appropriate direction for the technologies web developers work with to take. Through all those discussions however I’m still having trouble wrapping my head around the long term impact of the proposals and how I need to manage my very non-theoretical code and projects. In a search for discussion of these practical examples on how one would start to tailor their code in this new model I’m turning to you all. Can the extensions, and the additional rendering mode they’re implying be worked around with no impact at all, or if it requires new planning on the part of developers, or is it just more of the same planning we’ve been doing for ages.

Right Now

In an XHTML1.0 IE6 & IE7 world my typical structuring of code to ease browser hacking and targeting has been as follows:

  • use an XHTML1.0 [transitional or strict] doctype that triggers “not-quirks-mode”
  • start code with no browser hacks
  • For combined IE6&7 adjustments [hasLayout type stuff usually] use a separate style sheet linked inside conditional comments
  • For IE6 but not IE7 use the * html hack when needing to hide stuff, or remember a few extra rules that anyone can get safely [display:inline; float:left;]
  • Ignore IE5.x and less
  • Keep more complex CSS and other hacks to a bare minimum [e.g. clearfixing, etc.] and instead design and code as ‘universally’ as possible

That has worked for the last 1-2 years in a world that knew nothing about IE8.

With IE8 in our sights

But now we’re in a world that knows IE8 exists which changes things just a little bit if I want to be a responsible web developer. Any document I publish or help a client publish from today on I have to consider [with limited knowledge of details] if and how I want to prepare them for the upcoming browser changes.

  • Do I leave my above solution in place and do nothing? In doing so I have to hope that IE8 will be good enough to not get IE7 hacks but act like Gecko or WebKit — that or reside myself to expecting that some adjustments will have to be made once IE8 lands.
  • Do I prematurely start to include the like-IE7 meta tag so that I don’t have to revisit the site later and just let the site live forever as IE7 compatible? Is it realistic to expect that this will still work, and there will not be any testing when IE8 hits required, and that things will work flawlessly without going through the same motions that should happen with any new browser release?
  • Does it make a difference if I think the site will have regular staffing and updates or if its just a site build to get something published and nobody manages it again until the next redesign in a year or two?

Reasonable approaches all — I may flip flop some while I decide what I think works best and see what others are doing. However, they’re also solutions for the extreme near term. Looking further out the answers and options start getting fuzzier.

After IE8 hits

Shortly after IE8 hits web developers will have to switch from asking themselves how to code for the unknown, isntead having to code for the new known. It is easy to anticipate that a requirement for any new site in this time will be to cover exsiting compatibility [IE6 & IE7] and extend to the new kid on the block. So how might we do that with all these rendering modes floating around? At the pace standards move along, as well as the need to avoid total screwy quirks mode in the older browsers lets presume we’ll need to stick to the same languages that we’re using currently [for some time at least]. So to revisit my current model of structuring code for compatibility’s sake out 2 or 3 years what would that look like?

  • Do we continue to play in IE7-standards-mode, coding down for IE6 and hope IE8 needs no adjustments and get nothing out of the IE8 progress?
  • Do we use no compatibility flag and presume IE7 compatibility mode and then code up or down as needed and cross our fingers?
  • Do we use the use the IE8 compatibility flag and code down to both IE6 and IE7?

What about JavaScript?

One thing we, as web developers, haven’t had to deal much with — ok, I lie, we’ve had to deal a lot with — but anyway, IE8 promises to have some large javascript feature changes and it has been cited [or presumed] that this as a big reason about why the separate “mode” is needed. Though I welcome the progress on the scripting front, the “rendering modes” is not an angle that has yet impacted JavaScript code. What real impact if any will the same browser and version changing javascript behavior based on mode have on our existing or future sites? Will it have any impact at all? Is the last option for browser version management feasible if the JS changes are indeed drastic?

We may not know how to answer this until some concrete information on JavaScript changes in IE8 is posted, or even still not until we see a public beta build released to the public. That said, I’m not sure the question, nor the answers are premature if we’re being asked now to evaluate and embrace the proposal.

Thoughts?

In a roundabout way I’m trying to both air, but also think through, my concern that the middle term outlook [2-3 years, or as long as XHTML 1.0, IE6 and IE7 all live] the additional rendering mode of IE8 and mode switching mechanics will keep developers in a “think like its IE7” mindset and not take real advantage of IE8 because of the difficulty of mixing the IE8 benefits with something that would work reasonably well in IE7.

I think its great to have a handle on the short term solutions, and its certainly enjoyable to envision a future with HTML5, CSS3, SVG, Canvas, DOM3, XML, XSL, and whatever other standards may be in the works. But should I be concerned that we’re setting ourselves up for a /worse/ middle term outlook then we would be if we kept on as we have been? Am I way off base with these concerns? Have I totally missed the point or the timeline?

Are there potential solutions or coding practices I haven’t thought of?

Microformats Hit 2, Entering Maturity

Posted on by
4

I didn’t want to let today go by without a post acknowledging the 2nd birthday of Microformats.org and the related community.

Thought the first year was huge for microformats, the second one has seen additional growth in all areas from format maturity, to huge growth in the community and sites using various markup constructs, to greater support from application vendors.

Here’s a recap of a few recent news items or tidbits incase you missed them.

Released: Textpattern Microformat Plugin v1.2

Posted on by
Reply

I’ve just updated my microformat plugin for the textpattern CMS and blogging tool. This update is a maintenance fix to add support for Textpattern v1.0.4 and some changes made in the way tag helpers are built. Users of older versions of TXP should stick with the 1.0 version of the plugin.

Future updates to the plugin are planned to add additional microformats support, expand the flexibility of the tag helpers and to streamline the underlying PHP code. If you’re using this plugin — or have chosen not to — please help by posting a comment letting me know how well you think it fits into your writing style.