Tags: fix

34

sparkline

Tuesday, April 3rd, 2018

Everything You Know About Web Design Just Changed by Jen Simmons

Alright! It’s time for the final talk of the day at An Event Apart Seattle (Special Edition). Jen is wrapping up a CSStastic afternoon with her talk Everything You Know About Web Design Just Changed. These are my notes…

Ready for another hour of layout in CSS? Well, Jen will be showing no code in this talk. She’s actually nervous about this particular talk. Is she really planning to say “Everything about web design just changed”? That sounds so clickbaity! But she really believes we’re at an inflection point. This may be the sixth such point in the history of the web. One of those points where everything changes and we swap out our techniques.

For the last few years, we’ve been saying that everything changed when mobile came along. But actually, the real fight has been going on for longer than that. It’s the battle between wanting art and dealing with how the web works.

There’s a seminal book called Creating Killer Websites by David Siegel from 1996. In it, he describes the first time he saw the same site in two different browsers. His reaction was panic. The web gave control to the user. David Siegel wanted more control. And that’s how we got spacer gifs and tables for layout.

What are the five major changes in the history of web design?

  1. Simple HTML. There was only one kind of layout: flow layout. There’s no CSS, but the browser is still thinking of everything has having a box. Text takes up as much space as it needs. Images take up as much space as their size. This is flow. There wasn’t much you could do until tables came along. They were created for tabular content but abused for layouts. The “We need art!” crowd used what was available to them at the time. Lots of slicing and dicing.
  2. Flash. It was hard to get HTML tables to work in multiple browsers. Flash seemed like an amazing chance to start over. And we could do things that were previously only possible in CD-ROMs. As a designer, you take an element and place it where you want to go on the stage (the UI tradition that goes all the way back to Xerox PARC). We made some crazy sites, explored a lot of possibilities, and got a lot of control. But the downside was the lack of accessibility. We went back to getting to grips with the web as its own medium. Jeffrey’s book, Designing With Web Standards, was a rallying cry to allow HTML to return to doing what it was meant to.
  3. Fluid Layouts. This was a return to the way the web always behaved—content takes up as much room as it needs to. But this time there’s a certain amount of control over how things are laid out. Still, we pretended that nobody has screens smaller than 640 pixels or bigger than 1024 pixels. We still live with the idea of fluid columns today.
  4. Fixed-Width Layouts. The “We need art!” crowd wanted more control than fluid layouts offered. We pretended that everyone’s screen was at least 640 pixels, or later 800 pixels, or later 1024 pixels.
  5. Responsive Web Design. Unveiled by Ethan at An Event Apart Seattle in 2011: flexible grid; flexible images; media queries. It’s a return to fluid layouts, but the addition of media queries gives us more control. The idea of fluid image was a bit radical. Up until that point, we thought of images as always being their intrinsic size. But something Ethan said that day was “It’s not just about layout.” And it’s true. For the last eight years, it’s been about more than layout. You set out to redesign your website and end up redesigning your whole business. Responsive web design is, frankly, what the web is now.

But let’s talk about layout. What’s next? Intrinsic Web Design.

Why a new name? Why bother? Well, it was helpful to debate fluid vs. fixed, or table-based layouts: having words really helps. Over the past few years, Jen has needed a term for “responsive web design +”.

Responsive web design has flexible images. Intrinsic web design has flexible images …or fixed images. Whichever you want.

Responsive web design has a fluid columns. Intrinsic web design has fluid columns and rows.

Responsive web design uses media queries. Intrinsic web design doesn’t necessarily need them.

The name comes from words that have been floating in the ether. In Rachel’s talk, the words “sizing” and “intrinsic” came up a lot. This is about the nature of the web.

Let’s look at images specifically. Before responsive web design, images overflow their container if they are bigger than the container. Fluid images (as used in responsive web design) shrink and grow depending on the size of their container. You can also make images fluid in a vertical direction. If we make the image fluid vertically and horizontally, the image looks distorted. But now if we use object-fit: cover we can specify how we want the image to react.

Fixed or fluid? With grid layout, you can mix fixed and fluid. You can make a layout fluid until it hits a minimum size, at which point it stays fixed.

There are four stages of squishiness:

  1. fixed
  2. fr units (fluid)
  3. minmax()(fluid until fixed)
  4. auto (a return to flow)

That’s a powerful set of tools that may take us years to explore.

We can do truly two-dimensional layouts: rows and columns. Every one of those four stages of squishiness works for rows as well as columns. This means we can create intentional white space. Jen made a video about this and got the response that this was always possible, but it’s different now: it’s more intentional. You can set heights and widths.

We can have nested contexts now:

  1. Flow
  2. Flexbox (formatting context)
  3. Grid (formatting context)
  4. Multicolumn (formatting context)

Floats never created a new formatting context, which is why used clearfix. Now we don’t need hacks. You can mix and match, choosing the best layout tool for the job at hand. You can have a grid layout that has flexbox items within it. The Firefox dev tools allow you to inspect each layout type separately. You can use the nightly build to get the latest tools.

Then we’ve got ways to contract and expand content. We have more options now. For a while, we’ve had the option to squish and grow (e.g. with fluid images). Another is wrapping and reflowing (like we can do with text). Another option now is to add and remove whitespace. Maybe the content size doesn’t need to change; the whitespace shrinks and grows instead. An even more radical option now is to have things slide behind one another and overlap deliberately.

Sometimes you don’t even need to use media queries (meaning we’ve effectively got container queries). But we can still use media queries, as needed, to tweak the details.

So intrinsic web design is:

  1. Fluid and fixed
  2. Stages of squishiness
  3. Truly two-dimensional layouts
  4. Nested contexts
  5. Expand and contract content
  6. Media queries, as needed

We have a whole new sandbox that we can play in. You can find examples at labs.jensimmons.com.

See also:

Tuesday, February 27th, 2018

Moving Slowly and Fixing Things / Paul Robert Lloyd

Although design gets conflated with creation, its the act of improving what already exists — organising a room, editing a text, refining an interface, refactoring a codebase — that I enjoy the most.

Thursday, February 15th, 2018

Progressive Web App for FixMyStreet · Issue #1996 · mysociety/fixmystreet

Here’s a Github issue that turned into a good philosophical debate on how to build a progressive web app: should you enhance your existing site or creating a separate URL?

(For the record: I’m in favour of enhancing.)

Thursday, February 8th, 2018

Progressive enhancement and the things that are here to stay, with Jeremy Keith | Fixate

I enjoyed chatting to Larry Botha on the Fixate On Code podcast—I hope you’ll enjoy hearing it.

Available for your huffduffing pleasure.

Sunday, July 2nd, 2017

Sticky headers

A three-part series by Remy looking at one interface pattern (a sticky header) and how his code evolved and changed:

  1. Sticky headers
  2. Smooth scroll & sticky navigation
  3. CSS sticky nav & smooth scroll

Monday, September 12th, 2016

Oh, shit, git!

Bookmark this page! Who knew that so much knowledge could be condensed into one document? In this case, it’s life-saving git commands, explained in a user-centred way.

So here are some bad situations I’ve gotten myself into, and how I eventually got myself out of them in plain english.

Tuesday, April 26th, 2016

Updating Our Prefixing Policy | WebKit

Ted has snuck a blog post out from behind Apple’s wall of silence, and it’s good news: WebKit is not going to use vendor prefixes for new features.

Saturday, December 19th, 2015

Photo upload and progressive enhancement for FixMyStreet / mySociety

Matthew describes a very nice bit of progressive enhancement for drag’n’drop file uploads (similar to the CSS Tricks article I linked to recently).

It uses the Dropzone JS which looks like it aligns nicely with the progressive enhancement approach.

Tuesday, August 25th, 2015

Doing Science On The Web – Infrequently Noted

Alex recounts the sordid history of vendor prefixes and looks to new ways of allowing browsers to ship experimental features without causing long-term harm.

Monday, August 4th, 2014

The Mobile Web should just work for everyone - IEBlog

One more reason why you should never sniff user-agent strings: Internet Explorer is going to lie some more. Can’t really blame them though—if developers didn’t insist on making spurious conclusions based on information in the user-agent string, then browsers wouldn’t have to lie.

Oh, and Internet Explorer is going to parse -webkit prefixed styles. Again, if developers hadn’t abused vendor prefixes, we wouldn’t be in this mess.

Wednesday, April 23rd, 2014

webcompat.com

I like this idea. It would be nice to see it catch on…

  1. Report a bug for any website or browser.
  2. Our team of volunteers diagnoses the bug.
  3. We send a fix to the site owner or browser.

Wednesday, April 16th, 2014

The Sticky Pagination Fixer

If you insist on having a fixed header on your site, please, please, please add this script to your site. I often use the spacebar to page down so this would be a life-saver.

Monday, December 16th, 2013

xkcd: Syllable Planning

This is called expletive infixation.

I’ll always remember the “Phila-fucking-delphia” example from Steven Pinker’s The Language Instinct:

If you said “Philadel-fucking-phia”, you’d be laughed out of the pool hall.

Friday, October 5th, 2012

iOS Six Fix

Last Christmas I gave you my bug report. Well, more of a whinge really. Scott put together a much better bug report and test page:

When the meta viewport tag is set to content=”width=device-width,initial-scale=1”, or any value that allows user-scaling, changing the device to landscape orientation causes the page to scale larger than 1.0. As a result, a portion of the page is cropped off the right, and the user must double-tap (sometimes more than once) to get the page to zoom properly into view.

Yes, it’s the old orientation and scale bug in Mobile Safari.

I’m pleased to report that as of iOS version 6, this bug seems to have finally been squashed. Hallelujah!

Given the relatively rapid upgrade path for iPhone, iPod Touch and iPad users, it won’t be long until we can remove our clever solutions for working around this problem.

Stand down, hackers, stand down. This bug has been taken care of.

Jeremy caught the mantis

Friday, June 1st, 2012

FixMyStreet

Not only is FixMyStreet responsive, it’s using the “display: table-caption” trick I documented for adjustable “content first/navigation second” source order.

Tuesday, May 8th, 2012

Proposition to change the prefixing policy from Florian Rivoal on 2012-05-04 (www-style@w3.org from May 2012)

This seems like a sensible way for browsers to approach implementing vendor-prefixed CSS properties.

Thursday, March 15th, 2012

South by CSS

South by Southwest has become a vast, sprawling festival with a preponderance of panels pitched at marketers, start-ups and people that use the words “social media” in their job title without irony. But there were also some great design and development talks if you looked for them.

Samantha gave a presentation on style tiles, which I unfortunately missed but I’ll be eagerly awaiting the release of the audio. I also missed some good meaty JavaScript talks but I did manage to make it along to Jen’s excellent introduction to HTML5 APIs.

Andy’s talk on CSS best practices was one of the best presentations I’ve ever seen. He did a fantastic job of tackling some really important topics. It’s a presentation (and a presenter) that deserves a wider audience, so if you’re involved in putting together the line-up for any front-end conferences, I highly recommend that you nab him.

Divya put together an absolutely killer panel called CSS.next, all about how CSS gets specced and shipped, and what’s coming down the line. All of the panelists were smart, articulate, and well-informed. The panel was very enlightening, as well as being thoroughly enjoyable.

And then there was the Browser Wars panel.

This is something of a SXSW tradition. Arun assembles a line-up of representatives from browser makers—Mozilla, Google, Microsoft, and Opera—and then peppers them with some hardball questions. Apple is invited to send a representative every year, and every year, Apple declines.

There was no shortage of contentious topics this year. The subject of Google Dart was raised (“Good luck with that,” said Brendan). There was also plenty of discussion about the recent DRM proposal submitted to the HTML working group. There was a disturbing level of agreement amongst all the panelists that some form of DRM for video was needed because, hey, that’s just the way things go…

As an aside, I must say I found the lack of imagination on display to be pretty disheartening. Two years ago, Chris was on the Browser Wars panel representing Microsoft, defending the EOT format because, hey, that’s just the way things go. Without some form of DRM, he argued, we couldn’t have fonts on the web. Well, the web found a way. Now Chris is representing Google but the argument remains the same. DRM, so the argument goes, is the only way we’ll get video on the web because that’s what the “rights holders” demand. And yet, if you are a photographer, no such special consideration is afforded to you. The img element has no DRM and people are managing just fine, thank you. Video, apparently, is a special case …just like fonts. ahem

Anyway…

The subject of vendor prefixes also came up. Specifically, the looming prospect of non-webkit browsers parsing -webkit prefixed properties was raised.

I saw a pattern amongst all three subjects: the DRM proposal, Dart, and browsers implementing another browser’s vendor prefix. All three proposals were made to address a genuine problem. The proposals all suffer from varying degrees of batshit craziness but they certainly galvanised a lot of discussion.

For example, Brendan said that while Google Dart may not stand a hope in hell of supplanting JavaScript, some of the ideas it contains may well end up influencing the development of ECMAScript.

Similarly, Mozilla’s plan for vendor-prefixing certainly caused all parties to admit the problem: the W3C was moving too slow; Apple should have submitted proprietary properties for standardisation sooner; Mozilla, Microsoft, and Opera should have been innovating faster; and web developers should have been treating vendor-prefixed properties as experimental features, not stable parts of a spec.

So the proposal to do something batshit crazy and implement -webkit-prefixed CSS properties has actually had some very positive effects …but there’s no reason to actually go ahead and do it!

I tried to make this point during the audience participation part of the panel, but it was like banging my head against a brick wall. Chaals kept repeating the problem case, but I wasn’t disputing the problem; I was trying to point out that the proposed solution wouldn’t fix the problem.

It was a classic case of the same kind of thinking we saw in the SOPA proposal:

  1. Something must be done!
  2. Implementing -webkit prefixes is something.
  3. Something has been done.

The problem is that it won’t work. Adding “like Webkit” to the user-agent string will probably have much more of an effect and frankly, I don’t care if any of the browsers do that. At this point, a little bit more pissing into the bloated cesspool of user-agent strings is hardly going to matter. A browser’s user-agent string isn’t an identifier, it’s a reverse-chronological history of the web. Why not update the history booklet to include the current predilection amongst developers for Webkit browsers on mobile?

But implementing -webkit vendor prefixes? Pointless! If a developer is only building and testing their sites for one class of device or browser, simply implementing that browser’s prefixed CSS is just putting a band aid on a decapitation.

So I was kind of hoping that Mozilla would just come right out and say that maybe they wouldn’t actually go ahead and do this but hey, look at all the great discussion it generated (just like Dart, just like the DRM proposal). But sadly, no. Brendan categorically stated that the proposal was not presented in order to foment discussion. And in follow-up tweets, he wrote that he actually expected it to level the mobile browser playing field. That’s an admirably optimistic viewpoint but it’s sadly self-delusional.

And what will happen when implementing -webkit prefixes fails to level the playing field? We’ll be left with deliberately broken browsers.

Once something ships in a browser, it’s very, very hard to ever remove it. During the Dart discussion, Chris talked about the possibility of removing Dart from Chrome if developers don’t take to it. Turning to the Microsoft representative he asked rhetorically, “I mean, do you guys still ship VBScript?”

The answer?

“Yes.”

Wednesday, March 7th, 2012

Prix Fixe

A year and a half ago, Eric wrote a great article in A List Apart called Prefix or Posthack. It’s a balanced look at vendor prefixes in CSS that concludes in their favour:

If the history of web standards has shown us anything, it’s that hacks will be necessary. By front-loading the hacks using vendor prefixes and enshrining them in the standards process, we can actually fix some of the potential problems with the process and possibly accelerate CSS development.

So the next time you find yourself grumbling about declaring the same thing four times, once for each browser, remember that the pain is temporary. It’s a little like a vaccine—the shot hurts now, true, but it’s really not that bad in comparison to the disease it prevents.

Henri disagrees. He wrote a post called Vendor Prefixes Are Hurting the Web:

In practice, vendor prefixes lead to a situation where Web author have to say the same thing in a different way to each browser. That’s the antithesis of having Web standards. Standards should enable authors to write to a standard and have it work in implementations from multiple vendors.

Daniel Glazman wrote a point-by-point rebuttal to Henri’s post called CSS vendor prefixes, an answer to Henri Sivonen that’s well worth a read. Alex also wrote a counter-argument to Henri’s post called Vendor Prefixes Are A Rousing Success that echoes some of the points Eric made in his ALA article:

The standards process needs to lag implementations, which means that we need spaces for implementations to lead in. CSS vendor prefixes are one of the few shining examples of this working in practice.

Alex’s co-worker Paul disagrees. He recently wrote Vendor Prefixes Are Not Developer-friendly:

  1. Prefixes are not developer-friendly.
  2. Recent features would have been in a much better state without prefixes.
  3. Implementor maneuverability is not hampered without prefixes.

All of this would have remained a fairly academic discussion but for a bombshell dropped by Tantek at a face-to-face meeting of the CSS Working Group in Paris:

At this point we’re trying to figure out which and how many -webkit- prefix properties to actually implement support for in Mozilla.

The superficial issue is that web developers have been implementing -webkit- properties without then adding the non-prefixed standardised version (and without adding the corresponding prefixes of other vendors). The more fundamental problem is that while vendor prefixes were intended to introduce experimental features until those features became standardised, the reality is that the prefixed version ends up being supported in perpetuity. Nobody is happy about this situation but that’s the unfortunate reality.

Among the unhappy voices are:

Once again, Eric sought to bring clarity to the situation in the form of an article on A List Apart, this time publishing an interview with Tantek. Alex also popped up again, writing a post called Misdirection which addresses what he feels are some fundamental assumptions being made in the interview.

Finally, Mozilla engineer Robert O’Callahan—who I chatted with briefly at Kiwi Foo Camp about the vendor prefix situation—wrote about Alternatives To Supporting -webkit Prefixes In Other Engines in which he makes clear that evangelism efforts like Christian’s, while entirely laudable, aren’t a realistic solution to the problem.

It’s all a bit of a mess really, with lots of angry finger-pointing: at Apple, at Mozilla, at web developers, at the W3C…

My own feelings match those of Eric, who wrote:

I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. … I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship.

Thursday, December 29th, 2011

The ‘trouble’ with Android | Stephanie Rieger

Stephanie focuses on Android but this is a cautionary tale about trying to impose control over what you’re sending to the multitude of mobile devices out there.

Designing to fixed screen sizes is in fact never a good idea…there is just too much variation, even amongst ‘popular’ devices.

Wednesday, December 21st, 2011

Position: fixed revisited - QuirksBlog

PPK tests the various ways that mobile browsers handle position:fixed, complete with videos.