Archive for the 'CSS3' Category

Reading List

A bumper reading list for those long holidays (and because I’ve been away conferencing for a few weeks and need to spurt out my backlog).

HTML5, CSS and NEWT

Industry

Conference videos

Misc

  • Cry-Baby of the Year – a list of ten previous winners of Cry-Baby of the Week who have been shortlisted by me as nominees for Cry-Baby of the Year
  • Dalkey Archive Press seeks unpaid interns -” Any of the following will be grounds for immediate dismissal during the probationary period: coming in late or leaving early without prior permission; being unavailable at night or on the weekends; failing to meet any goals; giving unsolicited advice about how to run things; taking personal phone calls during work hours; gossiping; misusing company property, including surfing the internet while at work; submission of poorly written materials; creating an atmosphere of complaint or argument; failing to respond to emails in a timely way; not showing an interest in other aspects of publishing beyond editorial; making repeated mistakes; violating company policies. DO NOT APPLY if you have a work history containing any of the above.”

And finally, here’s Kim Wilde, pissed on a train after the Magic FM Xmas party, singing “Kids in America” and “Rocking Around the Christmas Tree”.

Thoughts on Adobe Edge

Last week, I dragged my snot-filled carcass down to London for a day-long presentation by Adobe called Create The Web.

I’m an occasional user of Adobe products: I used Dreamweaver in my last job (and was a beta tester for a previous version), and use Photoshop from time-to-time, although use about 2% of its capabilities. I also have some chums at Adobe, but they’re weedier than me so didn’t try to threaten me to be nice to them.

In passing, it’s interesting to note that while Twitter has lots of griping about Adobe products, they managed to get about 800 people into a Leicester Square cinema for a full-day product pitch. That suggests Adobe retains significant mindshare.

I was there because I wanted to see their new Edge range, as the tools that authors use to make websites directly affect the quality of the code of those sites, which directly affects the interoperability of the Web. I was therefore watching the day from two occasionally opposing perspectives: firstly, as the representative of a browser vendor that is sometimes disadvantaged by developers not using the correct prefixes etc, but also as a web author who, all other things being equal, prefers to use IDEs than type in code.

The decline of Flash has not diminished the appetite of site owners and developers for eye-candy and movie-like effects. That’s why Adobe is pushing for lots of new effects in CSS: cool stuff like CSS Filters and CSS Compositing and Blending and also anachronistic “we wish the Web were print” specs like CSS Regions.

Regardless of your opinions on Flash as a technology or plug-in, there’s no denying that the Flash Pro development IDE beats coding canvas in raw JavaScript. It’s also true (according to my good chum and co-author, Remington Sharp) that those developers just coming to canvas and motion graphics now are bumping up against problems that the Flash developers solved decade ago.

Therefore, Adobe has made a very smart move by making the new tools for animating stuff feel familiar to Flash developers. This was explicitly called out: Flash devs, your skills are not dead; the technology might be, but your experience and creativity are still in demand. This is true, and a shrewd business strategy.

(A word about product nomenclature and confusion: the DHTML tool that was called Adobe Edge is now called “Edge Animate”. “Edge” now refers to the whole suite of new Adobe tools. Animate seems to produce DHTML, flying <div>s around with CSS and JavaScript. Apparently, the Flash IDE can produce “HTML5″ output, but that’s <canvas>. If your stuff involves text, use Animate so the text remains text and is therefore accessible.)

I haven’t had a chance to download my copy of Edge Animate yet. Lee Brimelow gave an excellent and entertaining developer-focussed presentation building up an animation and there were a few nasties in the code produced.

For example, it seemed that, by default, the code is simply empty <div>s with everything else injected by JavaScript. This means that someone without JS sees nothing at all. The “static HTML” export (which ought to be the default, in my opinion) at least puts the images in the markup, so a browser without JS sees *something*, albeit it unanimated. That code, however, was invalid: it produced <img>…</img>, and there is no closing </img> tag in HTML5 (or any previus incarnation of HTML, for that matter).

Encouragingly, Ryan from Adobe contacted me after I tweeted about this, asking for further feedback which I gave.

Other products that interested me were PhoneGap Build which allows you to upload a PhoneGap project and receive all the different packages through The Cloud™. I’d definitely use this. Who wants to dick around with all the different SDKs?

Edge Code is built on top of an open-source project started by Adobe called Brackets. Some hard-core developers (eg, those who wouldn’t pee on Dreamweaver if it were on fire) I spoke to seemed impressed. It seems they’re very serious about getting external developers involved; pull requests are reviewed daily; Agile sprints mean a quick iteration time, so your contributed code doesn’t languish interminably, and priority is given to external contributions.

The last product that interested me is Reflow, which isn’t out yet. It’s a drag-and-drop visual editor, which allows you to shrink the “stage” and, when your design starts to fall apart, set a breakpoint (which writes a Media Query) after which you re-design the page for the new page width. I haven’t seen the code that’s produced, but it feels to me an intuitive way for a designer to work.

Overall, it was exciting to see a company working hard to come up with a new strategy. The jury is out on the code it produces; Adobe is very heavily investing in WebKit and one of the presenters’ saying “this also works in old browsers like IE9 and Firefox” makes me uneasy. But it doesn’t have to be bad: Microsoft’s Web Essentials Visual Studio extension does an excellent job of adding all the vendor prefixes, even though Microsoft are heavily investing in IE.

The success of the product will ultimately depend on the price. And I’m curious to see how they’ll integrate with Dreamweaver, which is pricey and currently lacks many of the Edge features.

(Note: this is a personal post and doesn’t reflect the opinion of my employer).

Give Paul Robert Lloyd’s Thoughts on Adobe Edge a read, which prompted me to write this up. Fellow HTML5 Doctor Ian Devlin says PhoneGap Build is Awesome.

Reading list

CSS

Standards

Industry

Super-NSFW Corner

  • Fifty Shades Generator – Traditionally, print and web designers had to make use of placeholder text known as Lorem Ipsum. Now, creatives can excite clients in more ways than one with Fifty Shades of Grey-inspired filler text.”

Reading List

NEWT

Sublime Text 2

I haven’t actually enjoyed using an editor since VAX EDT in my old programming days, but Sublime Text 2 is an excellent program that not only doesn’t get in the way but has lots of utilities and features.

Industry

Dell Extends Ubuntu Retail into India – Unreported, of course, because it’s about FOREIGNERS, but Dell have been featuring Ubuntu on a wide range of Dell computers in China, starting at 220 stores and expanding to 350. They’re also expanding in to 850 stores across India.

misc

Reading List

Web Standards, innit?

Industry

Misc

  • Dear Einstein, do scientists pray? A 1936 letter from a Sunday school pupil to Einstein, and his reply.
  • The Beatles Never Existed – There was never just one group of 4 individuals calling themselves “The Beatles”. There were multiples of each character performing as “John”, “Paul”, “George” and “Ringo”. They all looked identical to each other except for a few features here and there.
  • Fuck Yeah Hotel Hallway – A tribute to the artistry of hotel carpet patterns. Scroll up and down fast and the pictures do weird things to your eyes.

Holiday

That’s it from me for a few weeks. I’m off to take my mum, uncle, cousin and powdered Grandmother to Cambodia (my Nan had always wanted to visit Angkor Wat so we’re scattering her ashes there). Kisses!

Reading List

Web Standards

Web Industry

Misc

Heartwarming corner

“Raising an Olympian” – a 3 minute video from Kavita Raut’s rural Indian mum. Even though it’s an ad and I’m a cynical old bastard I found it quite touching.

Reading List

Apps: Web vs Native – swinging towards Web?

Last week I linked to a piece about Financial Times turning its iOS app off, to concentrate on the Web instead.

Technology Review wrote of their experience “The future of media on mobile devices isn’t with applications but with the Web.” in Why Publishers Don’t Like Apps.”Like almost all publishers, I was badly disappointed. What went wrong? Everything … We sold 353 subscriptions through the iPad. We wasted $124,000 on outsourced software development. We fought amongst ourselves, and people left the company. There was untold expense of spirit. I hated every moment of our experiment with apps, because it tried to impose something closed, old, and printlike on something open, new, and digital.”

Also How NSFW Corp Dodged The Newsstand Bullet And Lucked Into HTML5″ “when Not Safe For Work Corporation finally launched a few hours ago, there was no Newsstand edition, and no Kindle store edition. Instead, it’s HTML5 all the way.”

Mobilism mobile browser panel with Jeremy Keith and reps of RIM, Google, Nokia and Opera on

Standardsy stuff

  • Lea Verou on Text masking — The standards way. I have a lot of sympathy with the view expressed by Matt Wilcox – SVG is much harder to write than a line of CSS (and I feel a bit ewww at mixing presentational SVG with my HTML). But at least this works everywhere, which is Lea’s point.
  • Jake Archibald’s funny and finely-researched article Application Cache is a Douchebag is vital for those thinking of offlinerifying a site, the and Fixing Application Cache Community Group want to, er, fix the AppCache spec.
  • Opera’s representative on the CSS Working Group, Florian Rivoal, has a proposal to fix the vendor prefixing system:

    When a browser vendor implements a new css feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.

    Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.

    If a large amount of content accumulates using the a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.

  • A proposal from Edward O’Connor of Apple for <img srcset> for responsive bitmapped content images
  • How browser engines work – a video presentation by Anthony Ricaud
  • Research shows adhering to WCAG doesn’t solve blind users’ problems

Legal stuff

Misc

Reading List

Simplicity and simplification

Vendor Prefixes

Please add -o- prefixes to your CSS keyframe animations, as we at Opera have released a build containing prefixed support (and also HTML5 Drag and Drop and other goodies) so it’ll be in the wild soon.

Note too that CSS Gradients is soon going to be standardised and so will drop prefixes. This doesn’t mean you should take out your prefixed rules, but rather add non-prefixed rules eg linear-gradient, radial-gradient, repeating-linear-gradient, repeating-radial-gradient.

If you’re the owner of one of those very useful gradient generators that I use all the time, could you please add non-prefixed rules to the output, and retire any creaky old pre-standardised webkit-only output?

Misc

Reading List

The last reading list of the year is a bumper one, so you have plenty to read over the hols. Enjoy!

Me

HTML

CSS

JavaScript

Multimedia

Data

Mobile

Kerrrazy Shit!

Notes on Adaptive Images (yet again!)

All the cool kids are doing responsive design, it seems. This means fluid designs, having some hot media query action to reformat your layout depending on screen size, and ensuring your images are flexible so they don’t break out of container, generally by setting them to {max-width:100%;}.

Having images scaling down presents a problem though, if you’re a performance-minded sort of chap(ette). Why send a 300K 400 x 800 image that would look lovely on tablet device attached to wifi, but which takes ages to download on a 3G phone, and which gets resized by the browser to fit a 320px wide screen? Not only are you wasting your user’s bandwidth and time, but not every browser is created equal and not every resize algorithm makes pleasing end results. The CSS 4(!) image-rendering property can help with this but it only hints to the browser.

Sending the right-sized image to devices without wasting bandwidth is one of the knottiest problems in cross-device and responsive design at the moment. In the 24ways advent calendar series of articles, the subject has been discussed twice in eight articles (by Matt Wilcox and Jake Archibald). There are numerous other techniques, as well, such as tinySrc and the Filament Group’s Responsive Images.

All these are very clever, different solutions to solve the same problem, and they all rely on scripts, or cookies, or server-side cleverness or (in the case of Jake’s ideas) dirty hacks and spacer GIFs. I’m reminded of Image Replacement techniques from more than 6 years ago, which were over-engineered solutions to the problem better solved by CSS web fonts.

Let’s recap. We have several images, of different sizes, and want to send only the most appropriately-sized image to the browser. The circumstances differ. The canonical use case is to send smaller, lower-resolution images to smaller screen-sizes on the assumption that connection speed is slow and they have low-resolution displays. This isn’t the case, though. Some people are using retina displays on fast wifi networks. SO, while currently CSS Media Queries allow us to detect screen width and pixel density, we need new media features such as network speed/ bandwidth.

The DAP is working on a Network Information API, there’s a Phonegap version for native apps, and a Modernizr detect, but using script for this seems much harder than being able to access it via Media Queries, and if you just want to rearrange CSS layout, CSS is the place to detect it. (Purists may argue that network connection isn’t a characteristic of device, but in your face, purists!)

Once you have a media query, you can swap images in and out using the CSS content property:

<img id=thingy src=picture.png alt="a mankini">
…
@media all and (max-width:600px) {
 #thingy {content: url(medium-res.png);}
 }

@media all and (max-width:320px) {
 #thingy {content: url(low-res.png);}
 }

@media all and (network-speed:3g) {
 #thingy {content: attr(alt);}
 }


A browser that doesn’t support Media Queries, or doesn’t report “true” for any of the Media Queries shows the picture.png, which is the src of the img. A browser that is less than 600px replaces picture.png with medium-res.png. A 320px or narrower browser replaces picture.png with low-res.png. A browser that is only connected via 3g replaces the image with its alt text.

I first researched this technique in 2008 as a way of doing image replacement without extra markup (ironically enough). The first two media queries only works in Opera and Chrome at the moment, as they’re the only browsers that fully support content without :before or :after. (The network-speed media query works nowhere as I just made it up).

Recently, Nicolas Gallagher experimented with generated content for responsive images, and unfortunately discovered that there are no advantages to the technique because browsers always download picture.png, even if they never show it because they immediately replace it. Perhaps this could be optimised away by browsers, but there would still be the double-download problem with current browsers.

My mind turned to HTML5 video. Here we have an element that has the ability to specify multiple sources (because of different codecs) and can also switch sources according to media characteristics. It borrows syntax from Media Queries but puts them in the HTML:

<video> 
<source src=high-res.webm media="min-width:800px"> 
<source src=low-res.webm> 
<!-- fallback content --> 
</video>

I firmly believe that if something as new-fangled as video can be responsive in a declarative manner (without needing script, APIs, cookies or server magic) then responsive images should be similarly simple.

Previously, on the mailing list, a new <picture> element was proposed. I mashed up that idea with the already-proven video code above and came up with a strawman:

<picture alt="angry pirate">
<source src=hires.png media="min-width:800px">
<source src=midres.png media="network-speed:3g">
<source src=lores.png>
   <!-- fallback for browsers without support -->
   <img src=midres.png alt="angry pirate"> 
</picture>

This would show a different source image for different situations. Old (=current) browsers get the fallback img element. As I said, this is a strawman; it ain’t pretty. But it would work. (It’s discussed in my recent Smashing Magazine article HTML5 Semantics.)

I prefer the media queries to be in the HTML for two reasons: you don’t need to have ids or complex selectors to target a particular image, and (more importantly) many content authors use a CMS and have no ability to edit the CSS. (Although the nasty <style scoped> could solve this.)

On the other hand, I might be over-engineering the whole problem. I chatted informally with my colleague Anne van Kesteren, glamorous Dutch WHATWG inner circle member. There’s a school of thought that says everything will be 300ppi and networks will be fast enough, so this is really an intermediate problem until everyone starts using highres graphics and all displays go from 150 to 300. Standards are long term, and by the time we have a standardised version, the problem might have gone away.

What do you think?

(Matt Machell pithily pointed out “if only browsers hadn’t forgotten the old school lowsrc attribute for images“.)

Looks like our chums at WHATWG are discussing this too.