meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 'Web' Category

The Survey, 2010

I TOOK IT! And so should you—THe Survey For People Who Make Websites, 2010

It’s that time again: the 2010 edition of The Survey For People Who Make Websites is open and taking your input.  If you’re someone who creates web sites,  whether all the time or some of the time or even just occasionally, please take just a little bit of your day (as I write this, the average time-to-completion is just over 10 minutes) to let us know about you.  Furthermore, please spread the word to any groups to which you belong—local SIGs, mailing lists, newsgroups, forums, message boards, and so on.  I truly believe it’s important to the profession as a whole to have as many web folks as possible participate.

I was asked a little while back why we do the survey, and my answer surprised me not just for its content but also for how much passion I felt.  I said:

I think it’s a vital investigation, a look into our profession that nobody else is even attempting and is… essential if we’re going to be taken at all seriously by anyone other than ourselves.

And even more vital than that, it tells us who we are, collectively speaking. We’re scattered. Many of us are solo. We don’t even know what kind of community we’ve joined. The Survey, though limited and imperfect, tells us something profound and essential about us.

That’s why I’ve wholeheartedly supported this effort from its very outset, putting in hours upon hours of thought and effort into its operation and approving the use of [funds] to pay for professional analysis. This matters.

Other professions have it easy: they require certification or degrees or membership in a professional organization before you can take part.  Because of that, they can often estimate to a reasonable degree, or even count directly, how many of them there are.  They can go to their membership rolls and survey a few thousand randomly picked members to find out their age, location, experience, salary, and anything else that seems interesting to know.

We who build the web don’t have that luxury.  Our profession, just like the medium it serves, has no gatekeepers, no central organization, no clear boundaries.  The Survey is our attempt to disambiguate ourselves.

So please, if you’re someone who makes web sites, take ten minutes to tell us about yourself.  If you know people who make web sites, please point them to the survey and ask them the same.  Thank you.

Vendor Prefix Lists

At the prompting of an inquiry from a respected software vendor, I asked The Twitters for pointers to “canonical” lists of vendor-prefixed properties, values, and selectors.  Here’s what the crowd sourced at me:

Lists more than just prefixed properties, values, and so on.

While there’s no guarantee of completeness or accuracy, these are at least what the vendors themselves provide and so we can cling to some hope of both.  I was also pointed to the following third-party lists:

If you know of great vendor-prefix lists that aren’t listed here, particularly anything from the vendors themselves, please let us know in the comments!

Somewhat if not obviously related: does anyone know of a way to add full Textile support to BBEdit 9.x?  Having it be a Unix filter is fine.  I know BBEdit already supports Markdown, but since Basecamp uses Textile and lots of people I work with use Basecamp, I’d like stick to one syntax rather than confuse myself trying to switch between two similar syntaxes.

In Defense of Vendor Prefixes

…that having been the original working title for “Prefix or Posthack“, my latest article for A List Apart.  (Sort of like Return of the Jedi had a working title of Blue Harvest.)  In a fairly quick read, I make the case that vendor prefixes are not only good, they have the potential to be great and to deliver greater interoperability and advancement of CSS.

So far the reaction has been overwhelmingly positive, which frankly came as a bit of a surprise.  The annoyance factor of prefixes is undeniable, and it’s been my experience that annoyance dramatically hardens opposition regardless of whether or not there are good reasons to oppose.  I could flatter myself that the agreement is due to the Obvious Rightness of my argument, but I suspect it’s actually that I merely articulated what most people had already instinctively decided for themselves.  Which isn’t a bad place to be.

Anyway, if you haven’t already, feel free to decide for yourself by reading the article—which, I feel like mentioning for no clear reason, is only the fourth piece I’ve ever written for ALA.

App Shopping

While I agree with Neven Mrgan’s Walled Gardens, I feel like the whole imagery of walled gardens is a bit of a metaphorical stretch—not because it’s inaccurate, but because it’s fundamentally unnecessary.  We don’t need metaphors here.

That’s because the iTunes App Store is just what its name states: it is a store.  That has a fairly specific and intentional meaning in the world of commerce.  It means that the stock is not infinite and that someone has screened it.

Think of visiting a store in the real world.  Not a small shop, but a store.  Something large (or at least largish) with lots of things to buy.  Macy’s.  Target.  Wal-Mart.  Or even the local hardware and general store in a small town, where there’s more than just tools and nails and bags of cement mix.

You go there to buy things because it’s a central location for buying a lot of things.  But inherent in the experience is that what you find on the shelves has been selected and vetted by the person or people running the store.  That doesn’t just mean favoring one brand of soap over another, but also deciding what to carry at all.  Your hardware store doesn’t sell flat-panel HDTVs.  Macy’s doesn’t stock six-inch PVC pipe.  Target doesn’t offer porn.  They have all selected some things to carry and rejected, if only implicitly, others.  Certain brands are not carried because their quality didn’t meet the proprietor’s standards, didn’t fit the store’s audience and brand, or weren’t sufficiently profitable to claim valuable shelf space.

This is an assumption about stores that we hardly notice except when it’s clearly not so.  If you’ve ever stepped into a store where it’s fairly obvious that everything, and I mean everything, the owner has ever come across in their life has been thrown onto the shelves on the theory that hell, it might look like junk but you never know what might be valuable to somebody, and you know what I mean.  We subconsciously expect that a store will offer wares which have been screened for quality and price, all conveniently collected in one place for our purchase.

So it is with the App Store.  It’s a central location for iPhone and iPad owners to go shop for apps.  The stock is large—too large for any physical store to handle—but it is still screened.  You may not like the screening criteria, just as you may not like the screening criteria exercised at Wal-Mart, but it exists nonetheless.

In the desktop computing world, of course, no such control exists.  There you find and collect applications wherever you find them, whether in a store or somewhere on the internet.  This is much the same as doing your shopping by driving around to garage sales and flea markets.  Taken as an aggregate, there’s no quality control, no screening, no organization.  It’s catch as catch can.

There’s room in the world for both models, of course.  Some people avoid stores in favor of flea markets and yard sales and the like because that’s what they prefer.  Others go to stores and avoid garage sales because they prefer the more controlled experience.  In fact, think about everyone you know.  How many prefer store shopping, and how many prefer flea market shopping?  In that light, the iTunes Store’s success is really no mystery.  It’s not just curated computing, which some have derided.  It’s curated shopping, a model which has already proven wildly popular.  More than that, it’s simple and cheap curated shopping, which is approximately the square of two wildly popular models.

You may say that there’s a significant difference between the physical world and the iTunes App Store.  If the real world were like iPhone/iPad ecosystem, there would only be one store in the whole world.  Everyone would have to shop there, and any merchant who couldn’t get in would be out of business for lack of customers.  In the real world, we can go to any store we like:  each is curated, but we can shop at the stores that offer what we like (read: that curate in a manner we find pleasing) and not the ones that don’t.  The App Store is the only place to shop.

But that’s only true if you believe that the iPhone/iPad is the only mobile ecosystem in town, which is an assumption a weirdly large number of Apple’s critics seem to make.  In fact, you’re perfectly free to join other ecosystems and shop at other stores.  Android has one, for example.  There are others.  If you don’t like what Apple offers you, then you can shop somewhere else, as many people do.

But let’s assume that you’re personally invested in the iPhone/iPad ecosystem and can’t for some reason avoid or leave it.  In that case, you’re stuck with that one single store, the App Store.

Except that’s only true because until now, nobody has launched an alternate store that offers web stack applications (WSAs).  Maybe that’s because nobody is really building WSAs yet, at least not in numbers large enough to justify building a store to sell them.  But then, maybe developers aren’t building WSAs because there’s no central place to sell them.  The centralization of stores is at least as attractive to sellers as to shoppers.  That’s a driver behind the recent announcements from Google and Mozilla, though as yet they’re just announcements.

A WSA store organized along lines similar to the App Store could do very, very well.  It would need to make the shopping and, more importantly, purchasing experiences as frictionless as possible; this is something the iTunes Store has definitely gotten right.  But suppose someone built a great WSA store and sold WSAs on a 20% commission.  How many developers might look at that and figure that the extra 10% was worth making a shift?

It certainly wouldn’t be as easy as just setting up a store and building a Scrooge McDuck vault; no, there would be many challenges, but nothing truly insurmountable.  Of that I am certain.  And the great thing is that, just like in the physical world, there’s room for multiple stores—boutique app shops, if you like.  Maybe one specializes in games; another in parent- and kid-centric apps; another in productivity apps; yet another in the “naughty” apps Apple booted out of its ecosystem a while back.  (I call them “fapps” for obvious reasons.)  Maybe these are app shops instead of app stores, but then, any large population can support a whole lot of shops.  They can coexist with any number of other stores, including those from Apple and Google and Mozilla and anyone else.

None of these WSA stores and shops would be able to sell native apps, but that’s less of an obstacle than many seem to think.  The window between native app behavior and WSA behavior has narrowed at an astonishing rate recently, and will continue to do so.  I’m not saying that you can do absolutely anything with a WSA that you can do in native code, of course, but a lot of native apps could have been done as WSAs.  Could still be done that way, in fact.

That points to the other advantage of a WSA store: it’s not limited to the iPhone/iPad ecosystem.  A well-written WSA can run in multiple ecosystems.  Being based on web technologies, they can (for the most part) go where the web goes.  The market is suddenly much bigger than the iTunes Store, much bigger than people carrying around Apple devices.  Much bigger than the people carrying around Droids, for that matter.  With WSAs, developers can sell in multiple ecosystems at once, using the most successful cross-platform technology since ones and zeros.

Besides which, in a very real sense, WSAs are not cross-platform apps.  They’re web platform apps that run in a native app that provides a window from a mobile ecosystem into the web.  We call that app a web browser, but it’s becoming more than that, and faster than many would have credited even six months ago.  The opportunities are beyond enormous.

For starters, imagine this: you have bought a number of apps at your favorite WSA store and installed them on your iPhone.  Then you find out you can finally get the hell off AT&T and move to a Verizon iPhone.  When you do that, the WSA store lets you install the apps you’ve already bought on your new ViPhone.  If it’s sufficiently smart, it will even migrate their data for you by way of the store itself.  Then, two years later, you decide you’ve had enough of Apple and want to move to another smartphone.  Once again, your apps and data go with you.

This is what the web stack makes possible.  If you thought mobile number portability was cool, imagine what you’ll think of mobile app portability.

The Web Stack

Following on my “HTML5 vs. Flash” talk of a couple of weeks ago, I’m hoping to do a bit of blogging about HTML5, Flash, mobile apps, and more.  But first I need to get some terminology straight.

As I did in my talk, I’m going to refer to the collection of front-end web-standards technologies—(X)HTML (of any flavor), CSS, and JavaScript—as “the web stack”.  I’ve seen the term used here and there and it makes the most sense to me as a condensed verbal shorthand.  It beats writing out the specific technologies every time or trying to use similarly clumsy constructions like “front-end tech”.  If you like, think of “web stack” as a rough equivalent to “Ajax”—a term that was invented because continually saying “asynchronous JavaScript + CSS + DOM + XMLHttpRequest” was unworkable.

The web stack sort of includes downloadable fonts, but only in the same sense that images or any other external resource is part of the stack.  SImilarly, it encompasses frameworks like jQuery in the sense that they’re built out of the components of the web stack.

When I use the term “web stack”, though, I’m not referring to back-end technologies.  Those things are important, certainly, but not from the front-end point of view.  A browser doesn’t care if your page was generated by PHP, Django, Rails, Perl, or what have you.  It doesn’t even care if the server runs on Apache or something else.

Furthermore, it doesn’t refer to plugins.  Yes, that means Flash, but it also means QuickTime, Real, ActiveX, and so forth.  What I need to make clear is that I’m not doing this in an attempt to imply that plugins don’t belong on the web at all.  They’re just not part of that core web stack any more than the web stack is part of them.  That doesn’t stop them working together, obviously.

Okay, so that’s out of the way, and I hope my meaning is sufficiently clear to everyone.  Please do leave a comment if it isn’t.  Onward!

Web 2.0 Talk: HTML5 vs. Flash

Earlier this week I presented a talk at the Web 2.0 Expo titled “HTML5 vs. Flash: Webpocalypse Now?” which seemed to be pretty well received.  That might be because I did my best to be unbiased about the situation both now and into the future, and also that the audience was very heavily weighted toward web stack practitioners.  Seriously, out of 100-150 audience members, about six raised their hand when I asked who was developing with Flash.

Many people have asked if the slides will be available.  Indeed so:  head on over to the session page, which I encourage attendees of the talk to visit so that you can leave a rating or comment on the session.  The 5.4MB PDF of my Keynote slides is available there whether you attended or not.

While I was at the conference I was also interviewed by Mac Slocum on the topics of the HTML and Flash, and that’s been put up on YouTube along with interviews with Brady Forrest and Ge Wang (both of whom are awesome).  I haven’t watched it so I don’t know how dorky I come off but I’ll bet it’s pretty dorky.

I indulged in a little good-natured ribbing of Adobe at the front of the interview (I kid because I love!) but the rest of it is, as best I recall, a decent distillation of my views.  I’m hoping to get a few more detailed thoughts written and published here in the next week or two.

Many thanks to Brady Forrest and the entire Web 2.0 crew for having me on stage and getting me out to San Francisco.  It’s always a great place to visit.

Seeking Hosting Advice

A friend and I have decided to build a web service/site/whatever the kids are calling them these days.  A thing on the web to help you out from time to time.

As a result, we’re looking for a web host with great service, reliability, and scalability, and I was curious about your experiences.  Here are a few details on what we need:

  • A managed server where patches are applied automatically.  Neither of us are Linux experts, and we want something secured for us without us having to worry about whether some patch breaks the system. 
  • mySQL with phpMyAdmin.  (Don’t judge.)
  • PHP w/cURL, mySQLi, and mCrypt, as well as an editable php.ini file.
  • Apache!
  • Some sort of CVS (Subversion and the like) built in.
  • Bonus: some experience on the hosting side with the ability to escalate to Memcached and other noSQL techniques.

The mySQL and PHP bits are of course incredibly common, but still, no point not mentioning those requirements.  In our case, the bigger issue is really “Who can we trust to provide support for what may turn out to be a reasonably large-scale service?”  So the features aren’t nearly as important as the reliability and trust.

Thus: what say you, friends?  Who rates as a great place to plant a web service seed that could one day grow into a mighty forest?  Let me know!

Inspector Scrutiny

It’s been said before that web inspectors—Firebug, Dragonfly, the inspectors in Safari and Chrome, and so forth—are not always entirely accurate.  A less charitable characterization is that they lie to us, but that’s not exactly right.  The real truth is that web inspectors repeat to us the lies they are told, which are the same lies we can be told to our faces if we ask directly.

Here’s how I know this to be so:

body {font-size: medium;}

Just that.  Apply it to a test page.  Inspect the body element in any web inspector you care to fire up.  Have it tell you the computed styles for the body element.  Assuming you haven’t changed your browser’s font sizing preferences, the reported value will be 16px.

You might say that that makes sense, since an unaltered browser equates medium with “16”.  But as we saw in “Fixed Monospace Sizing“, the 16px value is not what is inherited by child elements.  What is inherited is medium, but web inspectors will never show you that as a computed style.  You can see it in the list of declared styles, which so far as I can tell lists “specific values” (as per section 6.1 of CSS2.1).  When you look to see what’s actually applied to the element in the “Computed Styles” view, you are being misled.

We can’t totally blame the inspectors, because what they list as computed styles is what they are given by the browser.  The inspectors take what the browser returns and prettify it for us, and give us ways to easily alter those values on the fly, but in the end they’re just DOM inspectors.  They don’t have a special line into the browser’s internal data.  Everything they report comes straight from the same DOM that any of us can query.  If you invoke:

var obj = document.getElementsByTagName('body')[0];
alert(getComputedStyle(obj,null).getPropertyValue('font-size'));

…on a document being given the rule I mentioned above, you will get back 16px, not medium.

This fact of inspector life was also demonstrated in “Rounding Off“.  As we saw there, browsers whose inspectors report integer pixel values also return them when queried directly from the DOM.  This despite the fact that it can be conclusively shown that those same browsers are internally storing non-integer values.

Yes, it might be possible for an inspector to do its own analysis of properties like font-size by checking the element’s specified values (which it knows) and then crawling up the document tree to do the same to all of the element’s ancestors to try to figure out a more accurate computed style.  But what bothers me is that the browser reported computed values that simply aren’t accurate in the first place.  it seems to me that they’re really “actual values”, not “computed values”, again in the sense of CSS2.1:6.1.  This makes getComputedStyle() fairly misleading as a method name; it should really be getActualStyle().

No, I don’t expect the DOM or browsers to change this, which is why it’s all the more important for us to keep these facts in mind.  Web inspectors are very powerful, useful, and convenient DOM viewers and editors, essentially souped-up interfaces to what we could collect ourselves with JavaScript.  They are thus limited by what they can get the browser to report to them.  There are steps they might take to compensate for known limitations, but that requires them to second-guess both what the browser does now and what it might do in the future.

The point, if I may be so bold, is this:  never place all your trust in what a web inspector tells you.  There may be things it cannot tell you because it does not know them, and thus what it does tell you may on occasion mislead or confuse you.  Be wary of what you are told—because even though all of it is correct, not quite all of it is true, and those are always the lies that are easiest to believe.

August 2015
SMTWTFS
July  
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Archives

Feeds

Extras