philipwalton

The assumption is that without rent control, average prices would be lower. Therefore someone who couldn't afford to move previously now could.

Honestly, at my previous company I worked as the sole front-end engineer on a team with mostly classically trained programmer types (all CS majors), and it started to become very obvious that the "traditional front-end best practices" for CSS weren't going to cut it for us.

Most of the recommendations I make came from learning things the hard way.

As a concrete example, early in my time at this job I needed to make a small CSS change in some template. I made the change, checked it in, and then like 50 tests started failing. I found it absolutely crazy that my changing such a trivial, visual thing would break so many functional tests, so I started suggesting that we not use the same classes for styling as we did for local hooks. I didn't know the word for it at the time, but there was clear coupling between our style and functional classes.

Anyway, it was little things like that, over time, that helped be develop much of my philosophy on this stuff.

This topic interests me as well, and I've written about many of these ideas in the past. They're not necessarily analogous to the GoF design patterns, but I think they're similar in spirit. I hope you find them helpful.

CSS Architecture http://philipwalton.com/articles/css-architecture/

Side Effects in CSS http://philipwalton.com/articles/side-effects-in-css/

Decoupling Your HTML, CSS, and JavaScript http://philipwalton.com/articles/decoupling-html-css-and-jav...

Flexbugs creator here. For what it's worth, all of these bugs have been fixed in the tech preview of Internet Explorer 12. Also, my co-maintainer (Greg Whitworth) is a member of the IE team, and he's been as adamant as anyone that we educate people on the shortcomings of older IE versions, so we can all build better websites.

This isn't about assigning blame, it's about empowering developers to be able to use flexbox today.

I've also created a Github repository called Flexbugs: a community curated list of cross-browser flexbox issues and their known workarounds. https://github.com/philipwalton/flexbugs

The goals is if you’re building a website using flexbox, and something isn’t working as you’d expect, you can find the solution there.

As a Google employee, the reasons I hear is that we'd like the diversity of our workforce to more accurately reflect the diversity of our users, so we can serve them better.

This is great. So is Josh Duck's period table of elements, which is mentioned in the footnotes:

http://joshduck.com/periodic-table.html

Post author here. I agree 100% that HTML and CSS are not programming languages. However, any application that you build on the front-end is going to require your JavaScript code to interact with the HTML and CSS, so a solid understanding of how all the pieces fit together is crucial.

I can't tell you how many times I've seen back-end engineers hack together a 100+ line JavaScript solution to a problem when one line of CSS would have fixed it.

If you don't know CSS, HTML and DOM very well, then you're probably going to be over-engineering your front-end apps.

Yes, I provided a detailed resume as well as my Github account for all of these. The problem is it didn't seem like the individual interviewers had taken much time to actually look at what I'd done.

If they had, then maybe I'd agree with you, but it seemed like many of them were just going through the motions. It seemed like they interview people all the time.

Related, I just found out that Darcy Clarke put this list together of good front-end interview questions. I would have included it in the article if I'd known about it ahead of time.

https://github.com/darcyclarke/Front-end-Developer-Interview...

To be honest, I was actually having a good time. I'm one of the crazy people who likes interviewing. I think it's kind of thrilling.

Also, they flew me up there, so what was I gonna do?

Maybe offline. I'm not interested in publicly calling out any companies. I mainly wanted to shed light on the process and my experience.

I will say that when interviewing for previous jobs in the past (at smaller companies), I got asked a lot more front-end questions. Maybe it's just a big company problem.

I agree 100% with Ian. I came here to say the exact thing, but he beat me to it.

In the what's new it says everything has been rewritten. Does this mean the icon vector files themselves or just the CSS?

CSS Grid Layout is definitely not a dead end, it just didn't have enough support to showcase (yet).

As for the difference, Flexbox is for one-dimensional layout and Grids are for two-dimensional layout.

Grids will eventually be able to do what you now need a flexbox within a flexbox to do, and much more. They'll be especially helpful for layouts that need to be dramatically different across media breakpoints.

Hope that helps!

You're quite welcome. It was a fun project to work on.

Perhaps if you were my customer, but you're just consuming the free content I've spent a good deal of time putting together :)

I disagree.

In classes that are supposed to be global helpers/modifiers, it makes absolute sense to use `!important`. For example, if I have the utility class `.u-hidden`, that selector has very low specificity. But if want to be damn sure that anything I put that class on gets hidden. There's no way to use specificity in this case because it's generalized for use on any website.

This is a common pattern seen in most well architected CSS libraries today.

BTW, I am the they you were referring to :)

There's absolutely nothing wrong with `!important` if used correctly.

The problem is when people use `!important` because they don't understand CSS specificity.

It depends on your company and your audience.

I know my company would never support a browser that wasn't even supported by its maker, and I'm sure a lot of companies wouldn't either.

If you have "customers" you'll probably drop IE8 support quickly in 2014. If you just have "visitors", and if those visitors are international, it might take longer.

I mention that in the site; however, in my testing their implementation isn't as good as I'd like it to be. To be honest, neither is IE11s :(

http://www.browserstack.com/screenshots/78ef12e58dd1ba200600...

That's a good point. I suppose I could try to detect if the click was accompanied by a CTRL/CMD keypress and open in a new tab accordingly.

Still, the 100ms delay isn't ideal, and the open in a new tab paradigm greatly simplifies things.

It's actually not as bad as you think. IE updates are now being released as critical so they're being included in OS updates.

That means that most IE users will be upgrading to the latest IE of whatever OS they're using. So when Window XP is officially abandoned (scheduled for spring 2014), it won't be long until most IE users are on the latest version.

Great question.

I use Google Analytics to track where users are clicking, specifically, when users click on external links that aren't otherwise tracked by the GA tracking code.

The problem is that if you click on a link that opens a new page, the functionality in the click handler may or may not run depending on how long it takes to redirect the request. That means that if I'm tracking clicks, I very well may be losing a good deal of data.

The alternative is to hijack the click event, wait for say 100ms, and then load the new page via JavaScript, but that also break the open in a new tab functionality.

In other words, there are no good options to track external click events via Google Analytics and still give users complete control over where the links go.

The best option I could come up with is to always open external links in a new tab, because that way the click handling code always has time to run. If you're curious as to what I'm doing, here is the code: https://github.com/philipwalton/solved-by-flexbox/blob/maste...

Anyway, it has nothing to do with wanting users to stay on my site. But I can't speak for why other people do this.

This is in development: https://github.com/doctyper/reflexie

Flexie provides a polyfill for the outdated syntax `display:box`. The library's creator (@doctyper) is working on a new polyfill for the new syntax `display:flex`, but as far as I know it's still in development.

https://github.com/doctyper/reflexie

I tend to be pretty picky in following the spec and only use HTML data-* attributes for actually passing data. That being said, I think it’s mainly a matter of personal preference. If the data-* attributes method makes more sense to you and your team, by all means use it.

I should note, though, that if performance is a concern, traversing the DOM for classes is significantly faster than for attributes. Here’s a jsperf example I put together a while back comparing the two: http://jsperf.com/class-vs-data-attribute-selector-performan...

Lastly, it's worth pointing out that it is still possible to style elements with attributes in CSS, so the data-* attribute approach doesn't actually prevent coupling between style and behavior, it's just another convention (like js-* prefixed classes). In both cases it's still up to you to enforce the convention.

Yes, you are correct. It's impossible to validate HTML from DOM traversal alone because the browser has already parsed it and forgiven any errors it was able to. (I didn't choose this title and agree that it's a little misleading.)

Technically, you could validate the markup if you did an AJAX request for the current URL and parsed the result yourself; however, if your app is generated dynamically and rendered primarily client side, you'd be missing a lot of the alterations done by your JavaScript in that validation.

This is why I think both tools have their place.

I try address this issue in my blog post introducing HTML Inspector under the section "How is HTML Inspector different than the W3C Validator?" http://philipwalton.com/articles/introducing-html-inspector/

That would certainly be cool. But part of the value of this tool is its ability to customize it yourself.

The project repo can be round here: https://github.com/philipwalton/html-inspector/