"html" entries

Parsing HTML with Perl

Efficiently manipulate documents on the Web

The need to extract interesting bits of an HTML document comes up often enough that by now we have all seen many ways of doing it wrong and some ways of doing it right for some values of “right”.

One might think that one of the most fascinating answers on Stackoverflow has put an end to the desire to parse HTML using regular expressions, but time and again such a desire proves too tempting.

Let’s say you want to check all the links on a page to identify stale ones, using regular expressions:

In this self-contained example, I put a small document in the __DATA__ section. This example corresponds to a situation where the maintainer of the page commented out a previously broken link, and replaced it with the correct link.

When run, this script produces the output:

Read more…

Comments: 6

Building rich web UIs with knockout.js

Live coding a shopping cart and other rich web UI goodness

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Microsoft’s Steve Sanderson gave a tight 20 minute introductory tour of Knockout.js, a popular JavaScript UI library built around declarative bindings and the Model-View ViewModel (MVVM) pattern.

In his talk, Rich Web UIs with Knockout.js, Steve quickly summarized the problems Knockout solves and why Knockout is a particularly strong candidate to solve those problems, before working on a shopping cart example to show off how bindings, including custom bindings, work within Knockout.

Some key parts of Todd’s talk include:

  • A description of the problem Knockout solves [at 00:41]
  • What is Knockout and MVVM? [at 01:38]
  • 4 unique things about Knockout [at 03:12]
  • Live coding a shopping cart [at 06:02]
  • Summary [at 20:15]

Anyone with a further interest in Knockout should check out the project’s homepage and particularly the live Hello World example and interactive online tutorial which guides you through building a Web UI using the MVVM pattern with Knockout.js in an interactive sandbox-style environment.

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment

Web application development is different (and better)

On both front and back end, the Web challenges conventional wisdom

The Web became the most ubiquitous distributed application system because it didn’t have to think of itself as a programming environment. Almost every day I see comments or complaints from programmers (even brilliant programmers) muttering about how many strange and inferior parts they have to deal with, how they’d like to fix a historical accident by ripping out HTML completely and replacing it with Canvas, and how separation of concerns is an inconvenience. Everything should be JavaScript.

(Apologies to Tom Dale, who tweeted a perfect series of counterpoints just as I was writing. He has visions of rebuilding the rendering stack in JavaScript, but those tweets are not unusual opinions.)

The Web is different, and I can see why programmers might have little tolerance for the paths it chose, but this time the programmers are wrong. It’s not that the Web is perfect – it certainly has glitches. It’s not that success means something is better. Many terrible things have found broad audiences, and there are infinite levels to the Worse is Better conversations. And of course, the Web doesn’t solve every programming need. Many problems just don’t fit, and that’s fine.

So why is the Web better?

Read more…

Comments: 2

HTML and CSS performance

Efficient, reusable markup reduces development work while boosting page load time

[Ed note: This is the third in a series of posts on web design and performance. You can see the first two posts here and here.]

Optimizing your markup can have a substantial impact on your site’s page load time. Bloated HTML leads to bloated CSS, and vice-versa. For example, during a semantics and reusability template cleanup, I was able to significantly reduce the file size of site-wide HTML, CSS, and stylesheet images.

site-cleanup

I achieved this by simply renaming existing elements to have more semantic meaning and then removed unnecessary elements in the HTML (also known as divitis) to focus on reusability. Later in the same cleanup effort, I was able to cut CSS by 39% by removing unused selectors, combining and condensing styles, and normalizing the colors used across the site.

Read more…

Comment

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.

Read more…

Comment

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.

Read more…

Comment

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.

Read more…

Comment

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.

fig_1

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.

fig_2
Read more…

Comments: 2

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.)

Read more…

Comments: 4

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.

Read more…

Comment