- frak — transforms collections of strings into regular expressions for matching those strings. The primary goal of this library is to generate regular expressions from a known set of inputs which avoid backtracking as much as possible.
- The Boolean Trap — crappy APIs where true/false don’t mean what they seem. None of this is new, but every generation has to learn it anew. (via Pete Warden)
- Gumbo — open source pure C HTML5 parser.
- All Those People With Cheap Android Phones Have Started Buying Apps (Quartz) — revenue generated by the Google Play Store, from which many Android users get their apps, has grown 67% over the past half-year. By contrast, Apple’s App Store revenue grew 15%, according to Distimo estimates, which cover the top 18 countries. That sounds less impressive if you consider that the App Store brought in twice as much revenue in absolute terms. But the numbers are shifting fast. In February, the App Store was generating three times as much revenue, and last November it out-earned Google Play by a factor of four. Google is gaining.
"html" entries
Please nominate for the web platform awards
Recognizing the people who've built the Web
This March, we’ll be announcing the Web Platform Awards at the O’Reilly Fluent Conference. Fluent is all about JavaScript, HTML5, CSS3, and the best practices that make up the Web Platform, and we’d like to recognize the people who’ve made it the powerful ecosystem it is today.
The description is pretty simple, but I think includes a huge number of potentially great awardees:
The awards recognize individual contributors who have demonstrated exceptional leadership, creativity, and collaboration in the development of JavaScript, HTML, CSS, and the supporting Web ecosystem.
We hope to hear about many ways people have “demonstrated exceptional leadership”. It may be standards, it may be coding, it may be explaining, it may be community, or it may well be something I haven’t thought of yet. What matters is that you can tell us why you think they should get an award.
Seduced by Markup
The power of a technology now taken for granted
A friend wanted to show me a great new thing in 1993, this crazy HTML browser called Cello. He knew I was working on hypertext and this seemed like just the thing for it! Sadly, my time in HyperCard and an unfortunate encounter with the HyTime specifications meant that I bounced off of it, because markup couldn’t possibly work.
I was, of course, very very wrong.
Markup with some brilliantly minimal hypertext options was about to launch the World Wide Web. The toolset was approachable, easy to apply to many kinds of information, and laid the foundation for greater things to come.
Sketching in Code
Flexible dreams for a responsive world
Last week’s Artifact Conference focused on the challenges of designing for multiple devices simultaneously. One frequent suggestions on stage and off was rough sketching, on screen or on paper, but it’s tricky to get there. The problem is easiest to see for designers on the Web, but it applies to a wide range of digital projects.
The challenge isn’t just devices – designing for a particular device with its given constraints isn’t (usually) that hard. HTML, CSS, and JavaScript have long had tools for abstracting just far enough away from the device that sites can work even in unexpected places. The challenges come from the multiplicity. I used to spend a lot of time helping designers and clients move from “it looks like this in print” to “it probably looks like this on the Web”. That was largely about surrendering control, which was difficult enough, but this is frequently about controlling just enough to create multiple variations with a single code base.
What does a sketch of a page look like when that page morphs itself to fit differently in different containers? What does a sketch of a site look like when that site may present different content (and different types of content) to different users based on their past encounters with the site? What does a sketch of a program look like when it handles many different kinds of input in many different kinds of circumstances?
One answer – the classic answer for those of us walking around with notebooks full of dot grid paper – is multiple sketches. Breakpoints become critical as “it looks like this when…” becomes a mantra.
At the same time, though, I rarely feel comfortable creating site (or code) details on paper when I know the result will be electronic. I spent way too much time explaining how paper and screens are different to saddened designers to want to inflict that pain on my own projects. My notebooks are largely filled with words, with occasional pictures.
Build Reusable Widgets for the Web with Polymer and Dart
Don't wait for browsers to implement Web Components, try them today
Web Components, the family of new web specifications for reusable and encapsulated widgets, are coming to a browser near you. Thanks to Polymer, a new type of library for the web built on top of Web Components, and Dart, a new structured language and libraries for modern web development, you can build custom HTML elements that encapsulate style, structure, and behavior.
I’m personally a fan of Polymer.dart, a Dart port of Polymer. If you want to use JavaScript, you can use the original Polymer library, though some of the details are different. Both Polymer and Polymer.dart are under heavy development, and the engineers behind the projects are looking for feedback.
In this article, I’ll show you how to build a simple auto-complete widget as a custom element. As a user types into a field, a list is searched by prefix. The user can keep typing for a more exact match, use up and down to select, or use their mouse.
From “Web Development” to the “Web Platform”
Defining a powerful toolkit
The rise of the phrase “web platform” over the past few years makes me very happy.
For years, I’ve been looking for a good term that would cover HTML, CSS, JavaScript, and a few related technologies. The terminology has long been tricky, as the mostly-forgotten “webmaster” broke into smaller pieces: “web designer”, “web developer”, and sometimes “web administrator”. (Some web administration faded into general system administration, while other aspects have grown into their own discipline of web operations.)
Walking Trees and Handling Events
The core of web programming, in JavaScript and beyond
This summer, I’ve seen all kinds of programming approaches as I’ve bounced between the Web, XSLT, Erlang, and XML, with visits to many other environments. As I look through the cool new possibilities for interfaces, for scaling up and down, and for dealing with data, I keep seeing two basic patterns repeating: walking trees (of data or document structure), and handling events.
Walking trees can be annoying, to put it mildy. The Document Object Model (DOM) is famously a headache for JavaScript (and other) developers. There are obvious opportunities for advanced developers to focus on graphs and other more flexible data structures as well. Trees are not necessarily the most efficient way to store information, especially when their content changes regularly.
Four short links: 16 August 2013
Robo Regex, Crappy Code, HTML5 Parsing, and Play v App Numbers
Using XSLT 2.0 as a Web Scripting Language
Stunning JavaScript implementation suggests more is possible
A language built to support event handling, not strictly a functional programming language but fitting that mold. A deep understanding of markup structures. A home in the browser.
That’s JavaScript, all right—but now, thanks to JavaScript, it is also XSLT. After all the discussion I heard about templates and JavaScript at Fluent and OSCON, starting with a language built on templates seems like a better and better option.
Thursday afternoon at Balisage, O’Neil Delpratt and Michael Kay discussed Interactive XSLT [2.0] in the browser, showing not just the usual transformations but a working engine for a graphical interface. Their earlier XML Prague paper also tells the story and shows more code detail, including a chess game.
Read more…
Can Markup Unite?
Getting past the HTML / XML splits
A few years ago, I stopped talking about XML and starting talking about markup. After a few too many conversations with developers who had found XHTML, web services, and various other things that had proudly branded themselves with the “X,” it was clear from hostile responses that XML’s boom was done.
Many of Wednesday’s Balisage talks wrestled with the challenges XML tools face in a world dominated by competitors, especially HTML5. Today opened with a talk on making XForms work in HTML5 with browsers, followed immediately by a talk on replacing DocBook XML with XHTML5 (at O’Reilly). Two more abstract talks looked at filtering and an info space model, but the afternoon asked “Where did all the document kids go?” and then sought world domination by making XML invisible.
A Birds-eye View with Lift
Organize and control content with the Lift web framework
Lift is a web framework built for the Scala programming language, running on the Java Virtual Machine. Version 2.5 recently shipped, and I’m highlighting features of the framework that I find appealing.
Last time it was transforms and REST services, and this time it’s two features around organizing and controlling access to content.
SiteMap
How do you manage the HTML pages on site? Maybe some pages are available to everyone, others require login or some condition for access, and often pages are grouped in some way. Lift has an optional mechanism for expressing all this in one place, and it’s called SiteMap. This is how it looks in code:
lazy val home = Menu.i("home") / "index"
lazy val poets = Menu.i("poets") / "list" submenus (
Menu("Larkin") / "a-z" / "larkin",
Menu("Tennyson") / "a-z" / "tennyson"
)
LiftRules.setSiteMap(SiteMap(home, poets))
We’ve defined a site made up of a home page, and pages for poets we like. Why is this a good thing?
First, it’s a pretty readable representation of the site in (compiler checked) Scala code. You can probably figure out that we have a page called “home” found at /index.html (or / as it’s usually known).
What might not be obvious is that Menu.i is using “home” as a key into your translation resources, meaning the link text will be the localized version—if you’re building an internationalized site. The link to the page can be generated by a Menu.builder, a snippet you can use on pages to give your users navigation of the SiteMap.
The second menu item is called “poets,” served up from a template called list.html. On the home page, the navigation snippet would give you a link to the “poets” page, but by default is smart enough to hide the submenus until you visit the list of poets.
SiteMap also performs access control: if you use SiteMap, HTML pages have to be listed in it to be accessed. It’s a simple line of defense, but you can improve on this by adding location parameters. These are rules for controlling access to a page.
Let’s say we wanted to only offer some content to customers paying for our premium plan:
val PremiumCustomersOnly = If(
() => false,
() => S.redirectTo("https://shop.example.org/") )
This is an if-then-else construct, made up of two functions. The first function is a test for what qualifies as a premium customer. It’s an arbitrary computation, and in this example it’s false, meaning nobody is a premium customer (in reality, we’d perhaps check a property of the logged user). If you nevertheless try to get to the page, the second function kicks in, and you’d be sent to our store front.
We can apply the “premium customer” rule to any part of the site, but we’re going to just restrict Tennyson poems:
Menu("Tennyson") / "a-z" / "tennyson" >> PremiumCustomersOnly
If you don’t like the >> method name, use rule instead. If you just don’t like this domain specific language (DSL), you can construct a SiteMap in longer-form method calls.
What’s great about SiteMap is the flexibility it gives you: if you can’t get the behavior you want out of the box, you can write custom functions and classes, and drop them into the SiteMap. If you want menus displayed in a completely different way, not handled by Menu.builder customization, you can write a different navigation snippet. Location parameter rules allow you to isolate logic, and combine them as needed to parts of your site.