Posts Tagged 'html'

defending terrible things

I’m sure all this has been said before, but it’s a minor obsession of mine. Ignore HTML5 for a second, and all the interesting things happening with Javascript and CSS. I’d like to discuss the kids in leather jackets smoking cigarettes behind the gymnasium of web development: <b> and <i>.

And WordPress is going to make my first point for me. I’m typing this in their WYSIWYG and the buttons for bold and italic are a little b and a little i. When I toggle one on, it becomes /b or /i. And yet the HTML that gets inserted is <strong> or <em>. Why?

Point 1: The bold and italic tags do exactly what the fuck it says on the tin.

If you want something in a division on a page, there’s a tag for that. If you want something to be a heading, there’s a tag for that, too. These tags, like all others, accomplish what they do only through conventions of browser manufacturers, but can nonetheless be relied upon to get you some semblance of what you want even if your CSS should be mysteriously and tragically abducted in the middle of the night. Like the bold and italic tags, they tell you very little about text they contain. But nothing in HTML tells you about the text it contains. It does, however, sort of tell you what it’s going to look like in a webpage and describe the role it will play in the page’s structure.

Point 2: If you want semantic markup, use XML.

XML is a very handy little language that will let you describe your precious digitized text as precisely as you want. You can style it and present it on the web and get exactly the same thing you would from a document full of non-semantic <div>s and <span>s. Or, hey, put even more <span>s in and give them all seventeen class names and call it a microformat. I hope you have a really, really fun time doing that. If, on the other hand, you’re willing to consider that your consumable data and your pretty website need not be the same beast, you could just keep the XML somewhere else and if anyone ever actually wants to scrape all the air dates and titles of the Buffy the Vampire Slayer episodes you recorded on VHS, let ’em just grab that.

Point 3: Why this webpage is shouting at me!!

You know what strong and emphasis refer to? They refer to verbal inflections. You know what most peoples’ web browsers don’t do? Talk to them. You know what would annoy the shit out of me if I were using a screen reader to read a bibliography on the internet? Listening to a goofy-sounding computer voice try to emphasize every single word of Journal of the Study of Obscure and Mostly-in-Latin Canine Diseases Affecting Generally the Respiratory System but Also Sometimes the Lymph Nodes or something. I don’t know that this is still a problem, but the idea is ridiculous in and of itself. Italic does not always mean emphasis, nor does bold always mean MAKE THIS LOUD. Certain conventions of formatting require the use of bold or italics, but actual writing rarely does. If you need to place emphasis on something, you can do that with word choice. (Or anyway I hear it’s possible..)

Point 4: Character count

When I first started doing professional web development, lots of things weren’t digitized. Therefore I spent a lot of time marking things up, enough that I began to have those horrible almost-nightmares where you’re doing the same task over and over and you can’t stop doing it or thinking about it. If semantic markup had been a buzzword back then and every <b> had to be a <span style="font-weight:bold;">, I probably would have gone back to working at Chevron. The bold and italic tags are short. The emphasis tag isn’t bad, but the strong tag is way too long to be a good value per keystroke. This is to say nothing of what you should actually be doing if you want to keep your presentation and your tags altogether separate, using a span with a CSS class describing the content and not merely the fact that you want it extra heavy. I mean, sure, I will always use CSS to bold or italicize something if there’s already a tag around it. Nine times out of ten a bold or italic tag would be inappropriate there anyway as the font weight or style is purely decorative. On the other hand, if something needs to be weighted or styled differently and has no containing HTML element, fuck it, I’m using <b> and <i>. They’re shorter.

Point 5: Dirty tricks

I add <b> and <i> to things I don’t necessarily want bolded or italicized. I do it because they’re some of the shortest elements available and they provide a hook to style child elements in larger repeated widgets with very precise, complex layouts. If I have to wrap every word of text in a tag just to accomplish some goofy layout, I’m using the smallest thing available. Especially if the widget in question is something I’m inserting dynamically and I want to keep it in a string without spaces and still be able to sort of recognize what’s in it without needing four monitors just to view the whole thing at once. Again, if Something Better exists, I always do that first. But there are times when nothing you can do is going to be semantic, screen-reader friendly, or anything you’d want your mother finding out you’d done.

One of the most beautiful things about the web is its imperfections. We don’t write firmware for missile guidance systems, we write applications that let you pretend to steal your friends’ cartoon cows. There are places for flawlessness and obsessive semantic control, but this isn’t one. When you can write elegant code, it’s awesome, and I think most of the time everyone tries to. But it’s important to realize that at the end of the day, this is all kind a series of epic hacks, and sometimes the most sane thing to do is just embrace it.


forms without lists

This is the most recent product in a continuing attempt at making a flexible form that doesn’t require lists:

<fieldset id="floatlabel">
	<legend>Floated Labels</legend>
	<div onmouseover="this.className='hilite';" onmouseout="this.className='';">
		<label>Lorem ipsum</label>
			<div class="optionGroup">
				<label for="Radio1">
				<input type="radio" name="radMenut" id="Radio1" value="1" /> Omnivorous</label>
				<label for="Radio2">
				<input type="radio" name="radMenut" id="Radio2" value="2" /> Vegetarian</label>
				<label for="Radio3">
				<input type="radio" name="radMenut" id="Radio3" value="3" /> Vegan</label>
			</div><hr /><!-- if div not needed for styling, etc., h-rule can be used here to create structure without css, fix for ie6 -->
	<div onmouseover="this.className='hilite';" onmouseout="this.className='';">
		<label for="txtMiddle0">dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Why the absurdly long label? Good to test in case of dynamic or translated text.</label>
			<p><b>Note:</b> Investigationes demonstraverunt lectores legere me lius quod ii legunt saepius.</p>
			<input type="text" id="txtMiddle0" />
			<i>ex: Typi non habent claritatem insitam;</i><hr /></div>
	<div onmouseover="this.className='hilite';" onmouseout="this.className='';">
		<label>Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, </label>
			<div class="optionStack">
				<label for="Checkbox1">
				<input type="checkbox" name="chkSeatingt" id="Checkbox1" value="1" /> Stage</label>
				<label for="Checkbox2">
				<input type="checkbox" name="chkSeatingt" id="Checkbox2" value="2" /> Dancefloor</label>
				<label for="Checkbox3">
				<input type="checkbox" name="chkSeatingt" id="Checkbox3" value="3" /> Balcony</label>
			</div><hr /></div>
	<div onmouseover="this.className='hilite';" onmouseout="this.className='';">
		<label for="txtFirst">First Name</label>
			<input type="text" id="Text1" /><hr /></div>
	<div onmouseover="this.className='hilite';" onmouseout="this.className='';">
		<label for="txtMiddle">Middle Name</label>
			<input type="text" id="Text2" /><hr /></div>
	<div onmouseover="this.className='hilite';" onmouseout="this.className='';">
		<label for="txtLast">Last Name</label>
			<input type="text" id="Text3" /><hr /></div>
	<div onmouseover="this.className='hilite';" onmouseout="this.className='';">
		<label for="selSuffix0">vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.</label>
			<select id="Select1"><option>(none)</option><option>Sr.</option><option>Jr.</option></select>
			<i>ex: Typi non habent claritatem insitam;</i><hr /></div>
	<div onmouseover="this.className='hilite';" onmouseout="this.className='';">
		<label for="btnSubmit" class="buttonLabel">Submit this:</label>
			<input type="button" id="btnSubmit" value="Go Ahead" />
			<input type="button" id="btnCancel" value="Nevermind" /><hr /></div>

It’s heavier than it needs to be because it has both a div wrapping each item and a horizontal rule after. One or the other does the trick. I’m pleased that it manages, even with both tags, to have fewer tags than you’d need for a form with the same elements nestled in a list, which seems to be the cool thing to do these days (myself, I’m in the not every collection is a list camp). I’m curious what a list would offer it that it doesn’t have now. I think this looks better with the CSS stripped out than it would if everything had excess bullets next to it, as well.

The CSS is like so:

.example, .note, i, p { color: #999; font-style: italic; line-height: 1em; }
.example, i { white-space: nowrap; }
.note, p { background-color: #f6f6f6; padding: 10px; }
input, select { line-height: 1em; font-size: inherit; margin-bottom: .8em; position: relative; }
hr { display: none; }
.hilite { clear: both; position: relative; overflow: hidden; height: 100%; }
.buttonLabel { visibility: hidden; }
.optionStack *, .optionStack label *, .optionGroup label *, .optionGroup * , .optionLabel * { vertical-align: middle; }
#floatlabel { position: relative; border: 1px solid #999; padding: 10px; margin: 10px 0px; font-family: Garamond; font-size: 1.1em; }
#floatlabel div { margin: 5px 0px 0px; padding: 0px; clear: both; position: relative; overflow: hidden; height: 100%; }
#floatlabel .hilite { background-color: #f3f3ee; border: none; padding: 0px; margin: 5px 0px 0px; }
#floatlabel label { margin-bottom: .8em; border-bottom: solid #999 1px; position: relative; float: left; width: 300px; clear: both; display: block; line-height: 1.5em !important; margin-right: 10px; }
#floatlabel input, #floatlabel select, #floatlabel .optionGroup, #floatlabel .optionStack {
	float: left; display: block; position: relative; top: 0px; margin-bottom: .8em; margin-right: 10px; font-family: Garamond; font-size: 1em; }
#floatlabel input, #floatlabel select { border: double #999 3px; }
#floatlabel .hilite input, #floatlabel .hilite select { border: double #cc8 3px; }
#floatlabel i, #floatlabel p { position: relative; float: left; }
#floatlabel i { width: 200px; white-space: normal; left: 0px; }
#floatlabel p { background: transparent url(/newsletters/img/flourish.jpg) center 95% no-repeat; padding-bottom: 20px; width: 200px; float: right; display: inline; margin: 0px; border: double #999 3px; }
#floatlabel .optionGroup, #floatlabel .optionStack { overflow: hidden; margin: 0px 0px .8em; clear: none; }
#floatlabel .optionGroup label, #floatlabel .optionStack label { border: none; width: auto; margin-bottom: 0px !important; vertical-align: center; }
#floatlabel .optionGroup, #floatlabel .optionGroup label { clear: none; }

I’m still working on it – the CSS could be cleaned up – but it’s nice to know that it can be done. The important things, to me, are that it allows for infinitely expanding labels, as well as notes and examples.

Screenshot of the finished product

Screenshot of the finished product

RSS Recent posts on the live version of this blog

  • An error has occurred; the feed is probably down. Try again later.