Answering FEE Interview Questions - Part 2: HTML

Thursday February 1, 2018 by Timothy Lynn
~7 minute read

Welcome to part 2 in my series of inarticulate ramblings where I’m working through a worthy collection of potential interview questions. In part 1 I worked through some general questions about security, accessibility and development style. Today’s questions will be more targeted to HTML.

Q. What does a doctype do?

The doctype is the very first tag a browser encounters when rendering a page. It tells the browser what version of HTML follows (which DTD the page adheres to, if any). Since the introduction of HTML5, doctype's value has gotten ridiculously simple: 

1

<!doctype html>

IE used to have a fun bug where if you had any content prior to the doctype (white space, comments), it would render the page in quirks mode, often screwing up your page layout in fun and exciting ways.

Since previous HTML standards relied upon a DTD to define the grammar allowed, there were several doctype variants available to us, depending on what sort of page was being authored, and to what level of standards we wanted to adhere to: 

1
2
3
4
5
6
7
8
9
10
11

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Q. How do you serve a page with content in multiple languages?

This requires a few details, both in the UI and in the implementation. The biggest UI consideration is to provide a clear and commonly-used widget to prompt the user to change languages. Something like a dropdown with flags and translated language names is something that's seen on many websites.

Another nice feature is to honor the user's Accept-Language HTTP header, which can contain a comma-separated list in order of preference of languages. So if the user's request comes with Accept-Language: de, en, then attempt to serve the page in German first, and fallback to English. In this case, it's important to give precedence to an explicit user choice if that's provided. For example, the first time that user visits the page, provide its content in German. But if he uses your selection widget, then allow that choice to take precedence in subsequent requests.

Some servers will also attempt to determine locale by IP and automatically serve the page in that language. This is a nice convenience if it can be done accurately, but it's not always ideal (e.g., accessing a site through a VPN in another country).

On the markup side, it's important to instruct the browser which language is being displayed by using the lang attribute on the page's <html> tag, for example <html lang="en">. For languages in any direction other than left-to-right, you need to add the dir attribute, e.g. <html lang="ar" dir="rtl>. Finally, you need make sure that your page has a charset defined that will provide all the necessary characters for that language.

Q. What are data- attributes good for?

It's like the crust in stuffed-crust pizza, you can put anything you want in there.

The main uses I've had in the past are through JS, where, if you're a rational person and not worried about IE<11, you can use the really sweet dataset property:

1

<div id="example" data-value="3" data-is-dirty="false"></div>
1
2
3
4
5

var el = document.getElementById( 'example' );
if ( el.dataset.isDirty == 'true' ) {
  el.dataset.value++;
  el.dataset.isDirty = false;
}

The downside is that things like boolean evaluations need to be done as literals, because the values of data- attributes are treated as strings.

Data attributes can also be used as styling hooks, using the attribute selectors.

1
2
3
4
5
6

div[data-is-dirty='true'] {
  color: #f00;
}
div[data-is-dirty='false'] {
  color: #0f0;
}
Q. Describe the difference between a cookie, sessionStorage and localStorage.

Starting with sessionStorage and localStorage is easiest, because they are very similar, differing in that localStorage persists even after the tab or window is closed. The interface is super simple, setting or getting key:value pairs through the desired property:

1
2
3
4

localStorage.setItem( 'name', 'Tim' );
sessionStorage.setItem( 'name', 'Tim' );
alert( localStorage.getItem( 'name' ) + ' '
       + sessionStorage.getItem( 'name' ) );

Cookies are also key:value pairs, comprised of text strings and with an overall size limit of 4K per cookie. Cookies are sent with every request to the server, and are often used for authentication purposes. The implementor can set expiry times on cookies, so they may expire during an inactive user session (e.g., your banking site).

Q. Describe the difference between <script>, <script async> and <script defer>.
<script>: Since the document is parsed in order, as the script tag is encountered, it's downloaded and executed immediately. This can cause delays as a synchronous request is made for the resource (meaning the download of the rest of the resources is paused) and the script executes, after which, HTML parsing continues.
With the async attribute, the script is fetched during HTML parsing, and then executed as soon as it's available. The execution will pause the document parser if it's still running, and scripts downloaded asynchronously could be executed out of order. This is the recommended attribute to use for non-essential scripts, like analytics and advertising.
defer will download as the document is being parsed and will be executed in order after the document has been parsed, but prior to DOMContentLoaded.
Q. Why is it generally a good idea to position CSS <link>s between <head></head> and JS <script>s just before </body>? Do you know any exceptions?

While researching this answer, there are a lot of folks saying that the HTML spec says that's the only valid place for a link element, but if I'm reading this right, it can appear anywhere:

Keywords that are body-ok affect whether link elements are allowed in the body. The body-ok keyword defined by this specification is stylesheet. Other specifications can also define body-ok keywords.

Pragmatically speaking, stylesheets belong in the head so that their rules can be applied to the document that will be immediately parsed below it. Imagine having a document fetched and parsed, and then suddenly applying a massive CSS file to it. You'd get a nasty FOUC, as well as performance issues while the page is redrawn.

As for loading <script> tags just before the body, this is very similar to using a defer attribute. As the document is parsed top-to-bottom, putting scripts down below will allow the document to be parsed prior to any scripts downloading and executing. Since defer achieves a similar effect (in addition to downloading while the HTML is also downloading), you can keep scripts in the <head> of your document with that attribute.

The requirement for defer scripts though is that they must not contain document.write(); as this will affect the document parsing.

Q. Why you would use a srcset attribute in an <img> tag? Explain the process the browser uses when evaluating the content of this attribute.

This is one of the cool new things I learned about last week. The srcset attribute allows you to provide responsive images to the browser, allowing it determine the best image source to use. When used with the sizes attribute, you can define breakpoints the browser can use to determine which image source to use for a particular element.

srcset is also useful for resolution switching. That is, the same sized image element, but providing a higher-res image for devices with higher pixel densities. This doesn't require the corresponding sizes attribute.

Posted under: HTML