Slides on New CSS Features

I spoke with Ray Camden at the Grand Rapids Web Developer/Designer Meetup this week on some of the new CSS features that Adobe has been working on. The event went well, Ray did an awesome job and hopefully I didn’t stumble through the CSS parts too much.

I’ve posted my presentation on GitHub for anyone who is interested. It’s high-level but shows off how to use some of the new features and shows them in action. To view the demos you’ll have to have Google Chrome Canary with the Experimental Webkit Features flag enabled. And the last part requires a prototype Webkit build from Adobe. If you have any feedback, let me know.

Dealing with “fatal: https://github.com/adobe/Source-Code-Pro.git/info/refs not found:”

We recently changed the name of the Source Code Pro repository to follow the typical naming conventions of Github. Because of that you may get the following error when you try to update the code from git:

fatal: https://github.com/adobe/Source-Code-Pro.git/info/refs not found: did you run git update-server-info on the server?

If you get that, it means you need to update your local copy of the repository to point to the new URL. You can see all of your remote repositories by running:

git remote -v

You’ll probably see something like this:

origin	https://github.com/adobe/Source-Code-Pro.git (fetch)
origin	https://github.com/adobe/Source-Code-Pro.git (push)

Then you can run another git remote command to update the URLs to the new lower-case versions:

git remote set-url origin https://github.com/adobe/source-code-pro.git

Run git remote -v again to make sure your origin is set to the new lower-case URL and you’re all set.

Forks

If you’ve forked the repo and added an “upstream” link to the original source so you can track it, instead of origin you’ll want to set-url on the repository pointing to the Adobe source. Usually that’s called upstream but you may have named it something else when you set it up.

Join Us on the Create the Web Tour

Today we announced the Create the Web tour, a series of events that we will be doing around the world to talk about all the things Adobe has been doing with the web including new tools, new features in CSS, and services for web developers.

The tour is going to be in two parts, the first part is a full day event in four cities (San Francisco, London, Tokyo, and Sydney) that covers the full gamut of Adobe web tools and technologies. The second part is a much wider tour where the Adobe evangelist team will be spreading out across the globe to talk in more detail about specific tools and technologies at user groups, hack-a-thons, and other events.

We’ll have more information about that bigger tour soon, but in the meantime, if you’re in one of the 4 cities for the full day event, we’d love to see you.

Even for Companies: Github is your Resume

I caught a post by James Governor that resonated because I think Adobe is doing it right. The premise of the post is that your code is all you need for PR. Sometimes that’s releasing code, but more importantly, when you control a project, it’s about making your code easy to access and to take contributions for. As Don says, measure success by merges, not by forks.

The two awesome examples of that? PhoneGap and Brackets. PhoneGap/Cordova has an active and long established community. It’s not really an “Adobe” project at all, but a project that Adobe contributes heavily too in the form of engineering resources and we submitted the project to Apache when we acquired Nitobi last fall. That said, one of the strong points of the project is that the barrier to entry for commits is pretty damn low (in a good way). But the perfect example in my mind is Brackets. We’re all excited about the number of watchers and forks that Brackets has had. But using Don’s metric above, I think Brackets could be judged as being even more successful than those numbers show. According to the Github Impact Graph we’ve had 39 different committers over the 37 weeks of the project. Considering the team at Adobe that’s working on brackets is about 10 people, that’s a fantastic number.

It speaks to the team, the quality of the code, and the vision behind the project, but it also tells me Adobe is doing it right. That’s awesome. And to that end, major props to the Source Sans Pro team who put that font up on Github this morning.

Code Hinting in Brackets (And the Design Process)

I’m back from sabbatical and feeling antsy to get back to work so it was kick ass to see that the latest code checkins to Brackets have added a basic implementation of code hinting. This was always part of the Brackets plan and I’m glad to see it get in.

What was even cooler though was to see that Garth, who is design lead on the project, posted about the process and also laid out the specification. A great combination of open source for code and open source for design. Garth posted some of his ideas about what the plan is as well as some screenshots but he also started up a thread on the Google Groups in case anyone has suggestions or ideas. So if you have thoughts about how you would like to see code hinting implemented, drop by and chime in.

Presenting PhoneGap at the AT&T Hackathon – Seattle, April 14th

I’m going to be presenting/talking about PhoneGap at the AT&T Hackathon here in Seattle on Saturday, April 14th. The hackathon actually starts on Friday night, and the last one I was at was a really fun event. If you’re in the area I encourage you to come check it out, build an app, and win some prizes. I’ll be there in and out (not totally sure when I’m speaking) but I’m hoping to see some cool PhoneGap projects and chat with developers. Here are the details:

F5 Networks HQ
401 Elliott Avenue West
Seattle, WA 98119

Friday, April 13, 2012 at 6:00 PM – Saturday, April 14, 2012 at 9:00 PM (PT)

The PhoneGap Starter Project

As I’ve been digging more and more into PhoneGap Build I’ve also been discovering that there are some gaps in the workflow and that it’s not always easy to go from a feature I want to use to a cross-platform implementation for it. Most of the time I’ll use the PhoneGap documentation as a starter point and then try to wrangle it into a local project and then make that local project work with PhoneGap Build. One of my favorite features of PhoneGap Build is that it can pull directly from a git/svn repository and build binaries from that repo. So last night I did a little bit of work to pull a couple of features/code from the documentation into GitHub projects that can be quickly loaded into PhoneGap Build and turned into binaries. Fueled by some NW Peaks beer last night I built some initial ideas for the PhoneGap Starter Project. As you can see it’s pretty sparse but there are a few goals I have in mind.

  • Showing how to structure projects for use in PhoneGap build. I struggled with this a bit–with things like making the config.xml file work, setting the files up correctly (in a www folder, and referencing cordova.js in the script tag but not including it), etc. Each one of these projects works with PhoneGap Build out of the box.
  • Linking documentation to a real project. The documentation for PhoneGap is pretty good and I wanted an easy, out-of-the-box way for people to see the features in action. So I took the code from the documentation and turned them into projects. Load them into PhoneGap Build and you can see them in action on your device in a matter of seconds.
  • Helping fix documentation! I’m looking for ways to contribute to the Cordova project and some of the documentation code is a bit out of date. What better way than to go through that code, make sure it works, fix bugs, and then submit them back?
  • Showing how kick ass PhoneGap Build is. I really, really like PhoneGap Build and once you get a good workflow down I think it’s a great help in creating binaries quickly. This shows it in action.

To use the project in PhoneGap Build, just create a new app from SVN and put in the URL of the repo.

Adding an App to PhoneGap Build

Creating a new app based on Git/SVN project

I’m going to be filling out some of other documented features over the week as well as doing an example for the ChildBrowser plugin. I’m curious to hear if this seems useful for people or solves any kind of pain point. Since it helps me find the gaps/issues in the documentation, it serves a higher purpose for me, but if it seems useful then I’ll work on keeping it up to date.

Experimenting with CSS Exclusions

Okay, this is going to be scattered and on the cutting edge side, so buckle in. Adobe has been hard at work making the web a little bit richer when it comes to how type is displayed. A great example of that is CSS Regions, which let you create linked islands that text can flow between so you have a lot of control over how text gets laid out on the screen. That’s currently in the “Canary” builds of Chrome and if you go to about://flags and turn on “CSS Regions” you’ll be able to view the demos. The other thing we’ve been working on is a bit further out, but it’s in the same vein. It’s called CSS exclusions. It essentially lets you create more interesting islands of text in the form of shapes that text will flow around. At this stage it’s still very, very early. In fact, the only way to test CSS exclusions content is with a special build of WebKit that’s available on Adobe Labs.

The Backstory

A lot of the demos associated with these features are associated with magazines, and especially with the iPad 3 coming out, it’s going to be critical to be able to build expressive content that scales. Since magazines are mostly text, expressive text will be a big deal. I’ve been mulling over doing a beer-related magazine and figured it would be cool to try out some of the CSS demos to create something that might look unique and fit in a beer magazine. So I thought “hey, I could create shapes of different beer glasses and run text through those!” That was the basic premise. As I dug in, I found a couple of caveats. Most I’ll get to throughout the post, but the biggest one is that there currently isn’t a version of WebKit that has both CSS Exclusions and support for flowing across CSS Regions. So my original idea ran into a small roadblock but I’ll be able to fix that down the road.

Creating regions

The CSS Exclusions spec supports SVG’s basic shapes. That includes circles, rectangles, and polygons. At this point it can’t do arbitrary path data but you will be able to use SVG data according to the spec. So I started with creating the various types of beer glasses in Illustrator with the polygon tool. Then I had to set up the glasses on the page and make text flow correctly. The standard method seems to be to create two CSS classes, one for the properties that every region or shape will have, and another class for the specific region, in this case, glass type. I called my main region container and it looks like this:

     .container{
          position:absolute;
          height:500px;
          width:300px;
          text-align:justify;
          margin-top:0px;
          font-size:10px;
 
          -webkit-wrap-shape-mode: content;
          -webkit-render-wrap-shape: none;
          -webkit-hyphens:auto;
     }

The main properties are those three on the bottom. The first one tells the browser what I’m doing, and that’s wrapping the content within a shape. I think the other option here is around, which would make the shape an exclusion but I don’t think that’s working in my build of WebKit (or I’m doing it wrong). The render-wrap-shape is good for debugging as it shows you an outline of the shape so you can see how it’s appearing. I found this incredibly helpful as I laid objects out on the page. The last one, hyphens, lets you tell the browser how you want it to break up text. If you go for none there, it will only flow full words within the content. Otherwise it fills the content as much as it can before breaking words with a hyphen. For fuller-looking shapes, go with hyphens set to auto.

Next I had to set up the specific glass shapes. The hardest part for me was lining things up correctly. The way I created the polygons I think made it tougher to lay out. It also doesn’t change as you resize the page because I’m not using percentages (if that’s even possible with polygon objects). It looks kind of ugly but to define a shape we just have to use webkit-wrap-shape and give it the values. Here are a couple I did.

     #irishpint1 {
          padding-left:0px;
     }
 
    .irishpint {
          -webkit-wrap-shape: polygon(157px,473px 106px,472px 93px,453px 91px,432px 87px,401px 84px,368px 78px,332px 70px,294px 61px,255px 57px,225px 55px,191px 55px,165px 57px,128px 63px,118px 165px,118px 274px,120px 279px,128px 282px,164px 282px,190px 282px,226px 274px,263px 267px,296px 257px,337px 253px,368px 250px,397px 246px,427px 244px,453px 233px,473px 173px,473px);
     }
 
 
     #weissbierflute1 {
          padding-left:250px;    
     }
 
     .weissbierflute {
          -webkit-wrap-shape:  polygon(104px,470px 82px,459px 81px,439px 89px,400px 105px,344px 102px,294px 86px,238px 72px,183px 66px,128px 62px,77px 59px,39px 58px,17px 57px,0 280px,0 279px,17px 278px,41px 276px,74px 271px,128px 265px,182px 251px,238px 234px,299px 232px,344px 248px,400px 255px,434px 252px,463px 215px,473px);
     }

So they’re some semi-complex polygons. I also used the div tags to set up padding and lay things out. One of the things I learned is that CSS regions/shapes can only be applied through classes, you can’t define the properties based on id’s. But that may change.

So with all of those glass polygons, it looks like this:

What the page looks like in a browser that supports CSS Exclusions

What the page looks like in a browser that supports CSS Exclusions

That page is up on GitHub but you won’t be able to view it in your browser so you’ll have to be looking at it with the special browser from Adobe labs.

Making it More Interesting

After this I thought it would be cool to do a bit more with the shapes. Beer has a rating scale for color called the SRM scale. Types of beer have a general range of SRM scales and since some glasses roughly correspond to specific types of beers I wanted to see about creating a background for each shape that would correspond to the SRM scale. But even more than that I wanted it to change with the glass so as the glass got narrower, the background would become more transparent just like a real beer glass. Unfortunately it didn’t work quite the way I wanted, but I learned a bit about using CSS shapes along the way. Originally I just started by giving the div a background:

     #irishpint1 {
          padding-left:0px;
          background: -webkit-gradient(linear, left top, left bottom,
                                             color-stop(.8, rgba(152,83,54,1)),
                                             color-stop(.2, rgba(152,83,54,.7)));
     }

But the CSS shapes/exclusions don’t actually change the shape of the div, they’re only worried about wrapping the text within the div. So my page just looked like this:

What the div tag looked like when trying to set the background

What the div tag looked like when trying to set the background

Luckily webkit-mask-image came to the rescue. With that, I could create a mask based on a file, in my case an SVG file, and use that to mask a block element like a div tag. So I went through and created an SVG file for every glass shape and then used those as the mask and set the background accordingly with rbga() properties in a gradient. The final version looks like this:

And here’s a clean(ish) version without the backgrounds. I kind of like this one better.

Update: If you have a browser that supports exclusions you can check out the demo here.

Final Thoughts

It’s really, really early for CSS Exclusions but there is a LOT of potential there and even the stuff that works now is a lot of fun to use. This was just an initial dive into the feature to kick the tires, and because it’s so new, there are a lot of gaps both in my knowledge and what I was able to do. One of the things I tried was using CSS3 transitions to animate the -webkit-wrap-shape property. That didn’t seem to work, it could be on the roadmap.

It’s a fun feature and it’s really fun to be able to give it a shot while it’s still in the early stages. For magazines or any kind of rich text content, exclusions are going to be a fantastic way to make stuff pop. If you want, you can check out the project on Github. I’ll probably be modifying it and improving it as the spec evolves.

Speaking at the LA PhoneGap Meetup on Wednesday, February 15th

I’m doing a presentation in conjunction with HTC at the LA PhoneGap meetup on Wednesday, February 15th, so if you’re in the area, come by. I’m going to be covering Debugging and Deploying with PhoneGap, which includes talking about using the debug tools like weinre and using PhoneGap Build to deploy it across a bunch of platforms. From the site:

AGENDA:

1. Android Tablet Development (Lance Nanek & Michael Ludden, HTC)

2. Debugging and Deploying with PhoneGap (Ryan Stewart, Adobe)

===============================

Android Tablet Development. HTCdev has created a PhoneGap plugin for their Scribe Pen enabled tablets, one of which they will be giving away to a lucky developer. Check out www.htcdev.com for details.

Two of their lead developer evangelists will be demonstrating how HTCdev can help apps gain visibility, and how to easily program apps that let you create using Pen-based input.

Presenters:

Michael Ludden (twitter.com/Michael_Ludden) is a Developer Evangelist at HTC. Tasked with developer enablement, Michael is focusing on how best to help developers differentiate without fragmenting on HTC devices – creating great, unique user experiences that widen appeal of apps and catch that all important user’s attention. He will be showing how developers can take advantages of HTC’s app promotional programs, support, co marketing and robust toolsets to maximize an app’s influence. He has a bachelor’s degree from UCLA and has been working in development and with developers for years.

Lance Nanek (http://nanek.name) is a Developer Evangelist at HTC. He has ten years of experience in information technology: implementing web metrics for ibm.com at IBM, writing Java web applications at State University of New York System Administration, and working on Android apps for many companies, including CardioTrainer by WorkSmart Labs with over three million downloads. He has a master’s degree in Computer Science from State University of New York University at Albany.

Debugging and Deploying with PhoneGap. In this session, Ryan Stewart, a web developer evangelist from Adobe, will cover how to debug and deploy PhoneGap applications. He will talk about how to use Winere to get some insight into how your PhoneGap application is behaving on the device and how to set up the application so that it can easily be debugged. He will also cover some of the deployment options, including a deep dive on the ways to use PhoneGap Build to deploy quickly across multiple devices and operating systems. You’ll learn about things to be aware of, and things you can do to streamline the process.

HTML/JS/CSS and Tooling

I enjoyed this post by Grant Skinner that walks through his view of the evolution of technology and where/how/when tooling starts to come in. Adobe makes tools for web professionals. That’s what we’ve always done and that’s what we’ll do for a long time. You could even paint a broader brush that we make tools for creative people to share their creations. Watching our own evolution over the past year or so with regards to HTML tooling has been very interesting. We got some flack for not moving in earlier, but as Grant rightly points out, tools are a major investment and only once you have stability can you make that investment. It was never a matter of momentum around HTML or a focus on Flash, it was just the fact that things weren’t quite ready for tools.

In fact, I’d argue they still aren’t. But we’ve taken that as something that comes with the web. It’s always evolving, always moving, and while things will start to coalesce more and more, in the end, you have to get in and be ready to move. That’s kind of the approach we’ve taken with Adobe Edge. We just released Preview 4 of Edge which incorporates a lot of features that people have been asking for. Some of it I’m not even sure if it was on the original roadmap. But the Edge team made a conscious decision to be very agile, to build Edge in such a way that it could incorporate customer feedback quickly, and then getting product management on board to do lots of versions very quickly. I think it’s worked out very well and despite being on the earlier side of Grant’s curves, I think Edge will be a very helpful tool for a lot of people because of it.

Developer tools are a bit of a different story in terms of both ecosystem and readiness in my mind. There isn’t one, big, HTML IDE that people seem to like (akin to Flash Builder, Eclipse or Visual Studio). Instead people seem to be using a lot of different things and experimenting. What actually seems to be most popular right now are the basic text editors like TextMate or Sublime (my favorite). These seem to be focused on helping smart people work faster. Lots of shortcuts, lots of snippets, but not a lot in terms of helping along the learning process. And I think that’s just where we are now as far as HTML/JS/CSS tooling. But I’m excited to see that evolution as well and see what happens when frameworks get a bit more standardized and more general web developers start jumping into JS more and more. Will those people need a more robust HTML/CSS/JS editor that’s still developer centric? And I think the answer is yes, but I think it’s also tough to really see what that would look like until the JS/HTML/CSS stack is a bit more solid. But I’m excited to watch it and find out. And from what I’ve seen of Adobe’s HTML tooling side, we’re taking a good approach and I’m excited to see what people think as the PMs share more and more of it.