Optional HTML, good idea?

ack along the trail I was following in my post on carousels and web design firms I stumbled across Google's HTML and CSS Style Guide. This is, of course, just one resource in a sea of options, and as the name suggests, "more like guidelines, anyway." I found it useful to glance over to get an idea of what to do with my code once I had grasped some of the basic stuff.

The Style Guide has some helpful reminders about indentation (don't mix spaces and tabs, indent child elements), plus general etiquette (stick with the previous author's style, be consistent). The whole thing can be summed up as: optimize as much as possible, made code easy for collaborators to scan through. Somewhere halfway down the page, though, I found a section on optional HTML tags.

In all fairness, both Google and the WhatWG HTML5 spec frame this concept with "you may" and "consider" and other non-mandatory type phrasing. But I thought, hey, here's another way to be kind of minimalist, keep things tidy, not have more clutter than is really needed. And indeed, I could simply be rid of the <html>, <head>, <body> and a whole pile of closing tags. But! the traditionalist and skeptic in me took a pause and said, "Should I really mess with this right now? I haven't noticed this implemented anywhere, and my classes/research have all indicated that closing tags are the basis of a well-formed markup language. Maybe this is best left for another day."

Well ok, inner-skeptic, but I still want to learn a little more. So, some questions:

• What exactly constitutes a valid, well-formed markup language?

A markup language (ML just for now, though not to be confused with ML, the functional programming language I just couldn't deal with) is used to annotate and describe a document. I'm not going to go into the history and fascinating variety of MLs here, so suffice to say that in this case, for HTML or XML, the markup is intended to indicate what each tagged element contains. In HTML this could be a <header> or a <section>, which provide the browser with standard elements to display and style accordingly. XML uses tags to describe content, too, but is best suited to databases (DB). Since it is used in DBs, it is particularly necessary to have both starting and ending tags and to completely conform with the DB definition or else any references to each element would just fail. Not going into that here.

So a well-formed and valid bunch of whicheverML follows all the rules in the relevant specification and passes tests like the W3C validator. Well-formed generally refers to syntax, so elements that are arranged according the rules are syntactically correct. The traditional definition of well-formed includes closing anything that has an opening tag and properly nesting elements. A valid ML also follows its Document Type Definition (DTD), a sort of grammar dictionary for how to apply the language (here's the HTML4 DTD, for example). See the W3C validator's info here.

• How much of a difference in speed does tag omission really confer? 

There's not a ton of this out there on the surface, but again, Google has been implementing, or rather, omitting, the optional tags to decrease file size. When every bit counts, taking out even just a few characters here and there can add up to a big difference. According to the Google Developers article and video on reducing HTML document file size, this can actually result in "5-20% savings" in load time.

There's a conversation on StackOverflow from 2010 about how much of a difference this could actually make. It's hypothesized that especially at Google's size, "</body></html> is 14 characters and at 3 billion searches per day, it amounts to approximately39.12 GB of data per day ignoring compressions, or around 26 GB if we take gzipping into account." And another discussion from about the same time that goes more in depth on the whole issue. 

• Are there any arguments against tag omission on the whole?

Some people argue for tag omission for readability, others argue against tag omission for readability. So either way, people will eventually stumble through your code. The best reason not to omit is probably compatibility. Some browsers might not recognize an unclosed element properly, some scripts may get confused, it really depends what the content is expected to do. It winds up being a personal choice: you can include the superfluous, or you can be hyper meticulous and make sure you are only omitting tags that can be omitted and not getting confused in the process.

• Is this just one of those crazy, Google-is-way-ahead-of-everyone-else-again things?

Hard to say. Tag omission is out there, but most people don't need the speed that badly. The implementation status on the HTML5 spec only suggests that tag omission hasn't been tested on the latest browser builds.

OWW: Tidying up

o, how about that acronym? It is sort of descriptive of how my brain gets to feeling after too many hours staring at the screen. Here's a post on some trouble-shooting of the last two posts, and tidying up any loose ends that I can.

First, the original list post was confused about what element tags to use for embedding HTML content. I started with embed because it sounded like what I wanted to do, but it's actually "for an external (typically non-HTML) application or interactive content." Then I found object, which "will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin." And finally iframe which I had really thought went the way of the dodo for some reason, and which "represents a nested browsing context." Sooo...

Second, hopefully related, the embedded HTML doesn't show up in Google Reader. By switching to object tags, I did get it to at least display alt text. Turns out this is indeed a security problem with RSS feeds.

However, problem B is that the entire embed shows up as an empty frame for at least one reader using (you guessed it) Internet Explorer (IE. Abbreviations will carry into future posts). I suspect this has something to do with cross-site restrictions/same origin policies, or possibly just content blocking. Looked up user agent switching and (yay) Chrome has a built in feature to switch user agents from the developer console. However, everything displayed just fine when I checked the blog through the IE emulators, so I dunno.

The original list has now been tidied up, streamlined, and the stray notes I had in there for my own benefit have been relegated to drafted blog posts. I probably shouldn't blow any time styling it, but it's tempting. I would at least like to standardise some nice classy, plain styling for future documentation purposes.

Also, since this entire blog ought to be transferred to my domain in the near future, I'm not sure how much will be lost in the translation, so I'm not futzing about style too much right now. I did settle on using courier bold to highlight code terms, but then discovered that the code element does the same thing, so will use that henceforth.

Oh yes, and I had intended to use some pre and code elements in my TodoList file, but they didn't display properly on the first two tries. Turns out the < and > are still interpreted as HTML, so substituting in "&lt" and "&gt" respectively was necessary. It's worth noting that all of my HTML/CSS coding is happening using only TextWrangler, having upgraded from TextEdit. Someday fancy software (especially for previewing work) would be nice, but right now I like this basic approach.

Phew. I like fixing all the little problems, but it can certainly get a bit tedious. All my librarian research skills sure are coming in handy!

Gitifying the OneWeekWebsiteList

ote to self: document as I go, not after the fact. It felt a lot like I was running in circles trying to find documentation and n00b help as I was working on this, so I didn't take notes along the way. A lot of the point of this first step was to familiarise myself with a few new systems (Git, GitHub, Terminal, Unix command line, Vim), as well as just publishing my strategy for creating a bigger, better website for myself. The entire project is more about learning than having a finished product (although it would be nice to sell a photo again, someday), so each post is intended as a reference for myself, as you'll note from the links peppered throughout the text below.

I apologise in advance, too, for these posts likely being very dry, incoherent and plentiful. I'm often writing from the top of my head and focusing on developing and documenting rather than fine literary prose. Coincidentally, my horoscope for today:

Once you break down a task into manageable chunks, you'll discover that your challenges are not really that hard. You are absolutely capable of meeting the goal you projected at the beginning.

Essential breakdown of Gitification of The List:

• Wrote project todo list.
• Thought about purpose and use of list- dynamic, changing, updating steps as I go to keep track of overall process.
• Translated list into HTML 
• Created GitHub repository (repo) for new project, cloned repo onto local drive
• Updated and committed ReadMe file on GitHub
• Discovered that this threw my local clone out of sync, figured out basics of git pull.
• Finally figured out how to control the vim editor in Terminal (thanks largely to the patient human who helped me with basic commands) to add messages to merges and commits when I forget to use the -m option .
• At this point, the list was basically done, and pushed to GitHub. 
• Researched how to publish a repo to the web so that it looks like an actual page. I had seen a friend do this with a basic design portfolio, but couldn't find a simple button to push in order to see repo files in anything other than raw code. 
• Turns out I had to create an entire new branch in my repo, move everything, and when it still didn't seem to be working, realised I had left off the obvious !DOCTYPE declaration.  Actually, I could have just left it and popped in a reference or something. oh well.
• Had also found this Google Style Guide, which mentioned that some element tags are optional in HTML5. So I guess my dunderheadedness over formatting my initial list file wasn't actually critical, but I haven't implemented the recommendations yet. Also ran it past a W3C validator. 
• Meanwhile, I just need to get the published OneWeekWebsiteList.html into my blogpost, somehow, in a way that would save me from updating said blogpost every time I modified the original file. I found the embed element in the HTML5 spec to be a simple solution. Presumably there's some way I should have done this with PHP or scripting or one of those things I don't know how to do yet.
• So, one properly sized embed element and a div element with simple border later, the list mostly worked as dynamic content. 

Unfortunately, I couldn't discover until after publishing that the embedded HTML file doesn't display in Google Reader. It's visible in the RSS feed itself, so the problem comes somewhere in the aggregator?

I would love to hear about better solutions to this problem, as I just went for the first option I could find in the interest of moving forward. I've also just now switched to an object element, since embed seems to be intended for non-HTML content. Any thoughts?