Author Archive

Six CSS Layout Features To Look Forward To





 



 


A few concerns keep bobbing up now and then for Web developers, one of which relates to how to lay out a given design. Developers have made numerous attempts to do so with existing solutions. Several articles have been written on finding the holy grail of CSS layouts, but to date, not a single solution works without major caveats. At the W3Conf, I gave a talk on how the CSS Working Group is attempting to solve the concerns of Web developers with multiple proposals. There are six layout proposals that are relevant to us, all of which I described in the talk:

Here is a little more about these proposals and how they will help you in developing websites in the future.

Generated Content For Paged Media

This proposal outlines a set of features that would modify the contents of any element to flow as pages, like in a book. A video demonstration shows how to use paged media to generate HTML5 slideshows (look at the demos for GCPM in the Opera Labs Build to play with the features more). To make the content of an element be paged, you would use this syntax:

@media paged {
  html {
    height: 100%;
    overflow-style: paged-x;
    padding: 5%;
    height: 100%;
    box-sizing: border-box;
  }
}

This would make the content look something like this:

screenshot

Here, @media paged indicates that the browser understands paged media and that all of the selectors specified for it should have their styles applied when paged media is supported. Then, you indicate which selector you want to be paged (in the above example, the selector is the html element itself) by specifying the property overflow-style: paged-x. This will simply make the content paged; if you want paged controls to be visible, you need to specify overflow-style: paged-x-controls.

The properties break-before, break-after break-inside can be used to control where the content falls within the pages. For example, if you want headings to only appear with their corresponding content and never at the end of the page or standing alone, you can specify that:

h3, h2 {
break-after: avoid;
}

This ensures that if a heading occurs on the last line of a page, it will be pushed to the next page with the content that it introduces.

API

Two properties are available on an element whose content is paged: currentPage and pageCount. You can set the currentPage property via JavaScript, which would trigger a page change on that element. This would then trigger an onpagechange event on that element, which you could use to run other scripts that are required when the page changes. The pageCount property stores the total number of pages in the paged element. These properties are useful for implementing callbacks that should be triggered on page change; for example, to render notes for a particular slide in a slide deck.

Multiple Columns

Multiple columns are now available in most browsers (including IE10!), which makes them pretty much ready to use on production websites. You can render the content of any element into multiple columns simply by using column-width: <length unit> or column-count: <number>. As with paged content, you can use break-before, break-after or break-inside to control how the content displays within each column. You can also make one of the child elements span the whole set of columns by using column-span: all. Here is how that would look:

screenshot

Columns are balanced out with content by default. If you would prefer that columns not be balanced, you can set that by using column-fill: auto property. Here is an example of the default behaviour (i.e. column-fill: balanced):

screenshot

And here is an example of the column-fill: auto behavior:

screenshot

Note that the last column is empty, and each column is filled one after the other.

Regions

The closest equivalent to regions would be InDesign’s linking of text frames. With the properties in this proposal, you can make the content of selected elements flow throw another set of elements. In other words, your content need not be tied to the document flow any longer.

To begin, you need to select elements whose content will be part of a “named flow,� like this:

article.news { flow-into: article_flow; }

Here, all of the content in the article element with the class name news will belong to the flow named article_flow.

Then, you select elements that will render the contents that are part of this named flow:

#main {
flow-from: article_flow;
}

Here, the element with the ID main will be used to display the content in the flow named article_flow. This element has now become a region that renders the content of a named flow. Note that any element that is a region establishes new “block-formatting contexts� and “stacking contexts.� For example, if a child element is part of a flow and is absolutely positioned, it will now only be absolutely positioned with respect to the region it belongs to, and not to the whole viewport.

You can also tweak the styles of content that flows through a region:

@region #main {
  p { color: indianred; }
}

screenshot

API

An interface named getNamedFlow and an event named regionLayoutUpdate are available for elements that are regions.

getNamedFlow

This returns the flow that that particular region is associated with. The properties available are:

  • overflowA read-only boolean that tells you whether all of the content of the named flow fits within the regions that are part of the flow or whether it overflows.
  • contentNodesA NodeList of all the content elements that belong to the flow.
  • getRegionsByContentNodeThis returns all of the regions that a particular content element would flow through. A very long paragraph might flow through more than one region; with this method, you can retrieve all of the regions that that paragraph element flows through.
  • regionLayoutUpdateThis event gets triggered every time an update is made to the layout of a region. If the region’s dimensions are altered, then the child content elements that are part of that region might alter, too (for example, a few might move to another region, or more child elements might become part of the region).

Exclusions

  • Draft specification (a combination of two proposals: “Exclusionsâ€� and “Positioned Floatsâ€�)
  • Demo
  • Browser support: IE 10+

Exclusions allow inline content to be wrapped around or within custom shapes using CSS properties. An element becomes an “exclusion element� when wrap-flow is set to a value that is not auto. It can then set the “wrapping area� for inline text outside or within it, according to various CSS properties. The wrap-flow can take the following values: left, right, maximum,both, clear or the default value of auto. Here is how each of these values would affect the inline content around the exclusion element:

screenshot

wrap-flow: auto

screenshot

wrap-flow: right

screenshot

wrap-flow: both

screenshot

wrap-flow: clear

screenshot

wrap-flow: maximum

The wrap-margin property can be used to offset the space between the boundary of the exclusion element and the inline text outside of it. The wrap-padding property is used to offset the space between the boundary of the exclusion element and the inline text inside it.

screenshot

In the above image, the space between the content outside of the red dashed circular border and the black text outside of it is determined by the wrap-margin, while the space between the red dashed circular border and the blue text within it is determined by the wrap-padding.

Now comes the fun part: specifying custom shapes for the wrapping area. You can use two properties: shape-outside lets you set the wrapping area for inline text outside of the exclusion element, while shape-inside lets you set the wrapping area for inline text inside the exclusion element.

screenshot

Both of these properties can take SVG-like syntax (circle(50%, 50%, 100px);) or image URLs to set the wrapping area.

Exclusions make magazine-like layouts on the Web a trivial matter and could spark the kind of creative use of content that we are used to seeing in print!

Grid

Grid properties allow you to throw block-level elements into a grid cell, irrespective of the flow of content within the grid parent element. An element becomes a grid when display is set to grid. You can then set the number of columns and rows with the grid-columns and grid-rows properties, respectively. You can then declare each child selector itself as part of a grid cell, like so:

#title {
grid-column: 1; grid-row: 1;
}

#score {
grid-column: 2; grid-row: 1;
}

You can also use a template to plan the grid:

body {
  grid-template: "ta"
                 "sa"
                 "bb"
                 "cc";
}

In this syntax, each string refers to a row, and each character refers to a grid cell. In this case, the content of grid cell represented by the character a spans two rows but just one column, and the content represented by b spans two columns but just one row.

Now you can set any of the child element’s grid-cell position:

#title {
grid-cell: 't';
}

This will make the element with the ID title within the body element to be positioned in the grid cell represented by the character t in the grid-template property.

If you are not using grid-template, you can also declare how many columns or rows a particular element should occupy with the grid-row-span and grid-column-span properties.

Flexbox

Flexbox allows you to distribute child elements anywhere in the box (giving us the much-needed vertical centering), along with flexible units that let you control the fluidity of the child elements’ dimensions.

Note that this specification has changed substantially since it was first proposed. Previously, you would invoke Flexbox for an element with display: box, but now you would use display: Flexbox to do so. Child elements can be vertically aligned to the center with flex-pack: center and horizontally aligned to the center with flex-align: center. Also note that all elements that obey the Flexbox need to be block-level elements.

How Do Various Properties Interact With Each Other?

You might wonder how to use these properties in combination. The following table shows which of these features can be combined.

Paged Media Multiple Columns Regions Exclusions Grid Flexbox
Paged Media ✓
Multiple Columns ✓ ✓ ✓ ✓
Regions ✓ ✓ ✓
Exclusions ✓ ✓ ✓
Grid ✓
Flexbox ✓

As you can see, the multiple-column properties can be used in conjunction with generated content for paged media, regions and exclusions. But grid, Flexbox and regions are mutually exclusive (i.e. if an element is a grid, it cannot be a Flexbox or region).

A Note Before You Rush Out To Use Them In Client Projects

The specifications are always changing, so be careful with them. Except for multiple columns, I would recommend using these strictly in personal projects and demos. The syntaxes and properties used in some of the demos are different from what you would find in the actual specifications, because they have changed since the builds that support a previous version of the specification came out. Also, because they are still unstable, all of these properties are vendor-prefixed, which means you have to add support for each prefix as support is added.

If you do use these features, just make sure that the content is readable in browsers that do not support them. The easiest way to do this would be to use feature detection and then use CSS to make the content readable when the feature is unsupported.

Help The Working Group!

Do these layout proposals sound exciting to you? Jump on the www-style mailing list to provide feedback on them! Just note that the mailing list will flood your inbox, and you should carefully filter the emails so that you pay attention only to the drafts you are interested in.

Write demos and test how these work, and if you find bugs in the builds that have these properties, provide feedback to the browser vendors and submit bug reports. If you have suggestions for changing or adding properties to these proposals, do write in in the mailing list (or you can bug me on Twitter)!

These are exciting times, and within a few years the way we lay out Web pages will have changed dramatically! Perhaps this will finally sound the death knell of print. (Just kidding.)

(al)


© Divya Manian for Smashing Magazine, 2011.


Our Pointless Pursuit Of Semantic Value





 



 


Update (November 12th 2011): Read a reply by Jeremy Keith to this article in which he strongly argues about the importance of pursuing semantic value and addresses issues discussed in the article as well as in the comments here on Smashing Magazine.

Disclaimer: This article is published in the Opinion column section in which we provide active members of the community with the opportunity to share their thoughts and ideas publicly. Do you agree with the author? Please leave a comment. And if you disagree, would you like to write a rebuttal or counter piece? Leave a comment, too, and we will get back to you! Thank you.

Meta-utopia is a world of reliable meta data. When poisoning the well confers benefits to the poisoners, the meta-waters get awfully toxic in short order.

– Cory Doctorow

Allow me to paint a picture:

  1. You are busy creating a website.
  2. You have a thought, “Oh, now I have to add an element.�
  3. Then another thought, “I feel so guilty adding a div. Div-itis is terrible, I hear.�
  4. Then, “I should use something else. The aside element might be appropriate.�
  5. Three searches and five articles later, you’re fairly confident that
    aside is not semantically correct.
  6. You decide on article, because at least it’s not a div.
  7. You’ve wasted 40 minutes, with no tangible benefit to show for it.

This Just Straight Up Sucks

This is not the first time this topic has been broached. In 2004, Andy Budd wrote on semantic purity versus semantic realism.

If your biggest problem with HTML5 is the distinction between an aside and a blockquote or the right way to mark up addresses, then you are not using HTML5 the way it was intended.

Mark-up structures content, but your choice of tags matters a lot less than we’ve been taught for a while. Let’s go through some of the reasons why.

The Web No Longer Consists Of Structured Content

In the golden days of the Web, Web pages were supposed to be repositories of information and meaning, nothing more. Today, the Web has content, but meaning is derived from users’ interactions with it.

XML, RDFA, Dublin Core and other structured specifications have very solid use cases, but those use cases do not account for the majority of interactions on the Web. Heck, no website really has the purity of semantic mark-up that such specifications demand. Mark Pilgrim writes about this much better than I do.

If you have content that demands semantic purity — such as a library database, a document that needs a table of contents, or an online book (i.e. anything for which semantic purity makes sense) — then by all means stick to the HTML5 outlining algorithm, and split hairs on which element should be an article and which a section. No customer-facing tool exists that takes advantage of this algorithm by producing a table of contents. No browser seems to exploit such tools either.

Is It Really Accessible?

If accessibility is your reason for using semantic mark-up, then understand that accessibility and semantic mark-up have very little correlation, due to the massive abuse of HTML mark-up on the Web. (I would love to link to Mark Pilgrim’s post on this, but it is dead, so this will have to do.)

The b, strong, i and em tags are equivalent to the span tag as far as the specification is concerned. And so are some of HTML5’s tags.

As stated on HTML5 Accessibility, almost every new HTML5 element currently provides to assistive technology only as much semantic information as a div element. So, if you thought that using HTML5 elements would make your website more accessible, think again. (How much additional information do <figure> and <figcaption> bring? None.)

The recent debate (or debacle?) on the <time> element is just more proof of the impermanence of the semantic meanings associated with elements.

Is It Really Searchable?

If SEO is your grand purpose for using semantic mark-up, then know that most search engines do not give more credence to a page just because of its mark-up. The only thing recommended in this SEO guide from Google is to use relevant headings and anchor links (other search engines work similarly). Your use of HTML5 elements or of strong or span tags will not affect how your content is read by them.

There is another way to provide rich data to search engines, and that is via micro-data. In no way does this make your website rank better on search engines; it simply adds value to the search result when a relevant one is found for your website.

Is It Really Portable?

Another much-touted advantage of the semantic Web is data portability. Miraculously, all devices are supposed to understand the semantic mark-up used everywhere and be able to parse the information therein with no effort. Aryeh Gregor puts that myth to sleep:

… +Manu Sporny said that semantic Web people had received feedback that out-of-band data was harder to keep in sync with content. I can attest that in MediaWiki’s case this isn’t true, though… The only times I can see where you’d want to use RDFa or microdata instead of separate RDF is if either you don’t have good enough page-generation tools, or you want the metadata to be consumed by specific known clients that only support inline metadata (e.g. search engines supporting schema.org or such). If the page is being processed by a script anyway, and if the script author has ready access to server-side tools that can extract the metadata into a separate RDF stream, then it’s normally going to be just as easy to publish as a separate stream as to publish inline. And it saves a lot of bloat on every page view.

What Now, Then?

  • There is no harm using div elements; you can continue using them instead of section and article. I believe we should use the new elements to make your mark-up readable, not for any inherent semantic advantage. If you want to use HTML5 section and article tags to enhance some particular textual documentation for a future document reader, do it.
  • Tools exist today that take advantage of the nav, header and footer elements. NVDA now assigns implied semantics with these elements. The elements are straightforward to understand and use.
  • There is good support for ARIA landmarks in screen readers, but be careful when using them with HTML5 elements.
  • HTML5 has a host of new features. Learn about them, use them, give feedback. Make these features more robust and stable. Yes, most of these features require that you understand and write JavaScript and expose features that create a richer experience for your audience. If that task sounds formidable to you, then start learning how to code, particularly JavaScript.

(al)


© Divya Manian for Smashing Magazine, 2011.


  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress