Articles for November 2010

When @font-face support was introduced in Firefox 3.5, web authors were suddenly given a way of dramatically enhancing the typography used on their sites.  With all major browsers slated to soon support WOFF fonts offered by many font vendors, the range of fonts available on the web is far wider than it was just two years ago.

The OpenType format has long provided font designers ways of including a rich set of variations in their fonts, from ligatures and swashes to small caps and tabular figures. The OpenType specification describes these features, identifying each with a unique feature tag but they have typically only been available to those using professional publishing applications such as Adobe InDesign. When glyphs are selected for a particular sequence of characters and positioned for rendering, these features affect both glyph selection and positioning. Firefox currently renders using a font’s default feature settings; it would be much more interesting to provide web authors with a way of controlling these font features via CSS.

Included among the many new features in Firefox 4 is the next step, support for controlling OpenType font features directly via CSS.  The -moz-font-feature-settings CSS property permits control over kerning, ligatures, alternates, real small caps and stylistic sets to name just a few.

The CSS3 Fonts specification contains a number of new subproperties of font-variant.  These will eventually provide much better author control over font features but for Firefox 4 only the low-level -moz-font-feature-settings CSS property is supported.  With this authors can enable and disable OpenType font features directly:

.altstyles {
  /* format: feature-tag=[0,1] with 0 to disable, 1 to enable */
  /* dlig = discretionary ligatures, ss01 = stylistic set 1 */
  -moz-font-feature-settings: "dlig=1,ss01=1";
}

For reference, a complete list of registered OpenType features can be found here. The folks at FontFont provide a nice visual guide to OpenType features.

Ligatures and Contextual Alternates

Font designers often include simple ligatures and kerning data in their fonts but some go beyond these and spend a lot of time creating special ligatures and contextual alternate glyphs to enhance a given design. The Bello Pro script font from Underware is a brush-like design that includes many special ligatures (click image to view):

Note the special ligatures for “and” and “by”, the use of all small caps and the use of alternate glyphs to enhance the script connection between the letters in “Smooching”.  Only font styling is used here, all the text can be selected and copied, there are no images used on the example page.

Number styles

Using Minion Pro from Adobe, available via Typekit, the example below illustrates the use of tabular, monospaced number forms to display columns of data in a way that’s easy to read and analyze.  When proportional numbers are used, the width of large figures with the same number of digits will vary. Normally this would require using a different, monospaced font.  But with OpenType fonts that provide number formatting features, authors can use a single font without giving up the readibility of large data sets (click image to view):

Fonts may use either tabular or proportional number forms by default; providing access to these features allows authors to use both proportional figures for inline text and tabular figures for tabular data without the need to switch fonts.

Automatic fractions

Recipes for American dishes often use fractional amounts.  These can easily be rendered using the automatic fraction feature in OpenType (click image to view):

Each of the fractions above is written in simple text form, (e.g. 2 1/2), no special Unicode codepoints are used.  For fonts that support automatic fractions, an OpenType layout engine will automatically generate fractional forms for numbers separated by a slash.  These are typically limited to simple fractions, for more complex math expressions markup languages like MathML should be used instead.

Language sensitivity

Many languages often use a common script and over time differences in usage naturally arise.  Serbian, Macedonian and Bulgarian all use the Cyrillic script but with slightly different glyph forms for some common characters.  OpenType fonts support the ability to specify script-specific and language-specific glyph handling so given the correct lang attribute in the markup of a page, Firefox 4 can now render text in a language-specific way (click image to view):

Arbitrary features

OpenType defines font feature support using an underlying set of primitives. This allows font designers the ability to create their own features, either for a specialized purpose or as a general feature to be included in a future version of the OpenType specification.  Since the syntax of -moz-font-feature-settings allows for the use of arbitrary feature tags, these can be accessed via CSS.

In the example below, font designer Erik van Blokland of LettError uses a custom designed set of feature properties to create an interesting animation effect when hovering over text on the page (click image to view):

HarfBuzz, an OpenType shaping engine

The process of selecting and positioning glyphs used to display text runs has in the past always been done via platform libraries such as Uniscribe on Windows and CoreText on OSX.  To assure more robust and consistent text rendering across platforms, Firefox 4 will use the open source HarfBuzz OpenType shaping engine on all platforms. In the future this will allow us to integrate support for complex Indic and Southeast Asian scripts that have often been ignored or supported inconsistently in the past.

A Note About Typekit Use

All of the Adobe fonts available via the Typekit webfont service provide access to the full range of OpenType features found in the original fonts.  But to access those features you’ll need to explicitly enable “All Characters” under the “Language Support” category in the kit editor dialog before publishing.

Other examples

(Updated from a blog post last year):

• Use of contextual alternates and ornaments
• Another recipe example
• Tabular data example
• Language specific rendering of Turkish
• Rendering historical text

Update: the content of the examples is now editable! Edit the text of each example to experiment with the different font features.

Firefox 4 will come with better support for HTML5 forms. In the latest beta we are experimenting with a set of new features: more inputs types (email, url, tel, search), new attributes (placeholder, autofocus, list), decoupled forms and different validation mechanisms. This is thanks mostly to the hard work of Mounir Lamouri.

Some examples will work in other browsers, but you’ll need Firefox 4 beta to see all of them.

New input field types

In the same fashion as new HTML5 elements, we have new field types to better express what kind of input we want. The look and feel of many of these elements is the same as a text field, but they carry a different semantic meaning. This means that browsers can optimize the experience for users. For example, a mobile browser can provide a specific keyboard for a field. Or the browser can pre-fill phone number fields based on people in your address book. And extensions may even provide some features based on those types.

In this beta, Firefox comes with four new kind of inputs :

<input type="search">
<input type="tel">
<input type="url">
<input type="email">

Of the four new input types, url and email will also validate their content. We’ll talk about that later.

We also have support for a new kind of field:

<output for="i1 i2">

You can use this element to represent an area of the page that reacts to the interaction with a form. Think about the total price in a cart after you’ve changed the quantity of items or the shipping options. It won’t compute anything, you’ll need to do that with JavaScript, but it will give hints to accessibility technologies. The for attribute is a list of IDs of the fields that intervene into the calculation.

Text fields have been improved with <datalist> support. You can easily provide a list of suggestions for a field as the user is typing. You bind the field and the datalist by using the list attribute. It will use every option element inside datalist to populate the list. And for browsers without datalist support, they will display the content of the datalist element. So be sure to provide some valid markup to get a nice fallback.

Enter a city:

<label>Enter a city: <input list="cities"></label>
<datalist id="cities">
  or
  <label>choose one
    <select>
      <option value="Paris">Paris</option>
      <option value="London">London</option>
      <option value="Berlin">Berlin</option>
      <option value="New York">New York</option>
      <option value="Tokyo">Tokyo</option>
      <option value="Sydney">Sydney</option>
      <option value="Johannesburg">Johannesburg</option>
    </select>
  </label>
</datalist>

New input attributes

Autofocus

When you add this to a field, it will receive focus as soon as possible. The direct advantage for the user is that all sites will have the same algorithm for autofocus instead of relying on different JavaScript code. And browsers or extensions could disable this behavior if a user is not interested in it.

<input autofocus>

Placeholder

The value of this attribute will be displayed inside the form when it is empty and not focused. You can put an example of the kind of expected value.

<label>Telephone: <input placeholder="1-800-555-1234"></label>
<label>Comments: <textarea placeholder="Tell us what you think about our service…"></textarea>

Decoupled forms

You have more options to define the interaction between fields and forms.

form attribute

<input> elements don’t need to be children of a <form> element anymore. You can define them anywhere you want and bind them to a form using the new form attribute. It takes the ID of the form it should bind to.

Here’s an example. Let’s say you’re working on a search engine for some blogging software. You want a very simple form for the general use case and some advanced options if the user needs more control.

At the top of the page you could put:

<input type="search" name="search_field" form="search_form">

And at the bottom:

<form id="search_form" action="search.php" method="post">
  <fieldset>
    <legend>Advanced options</legend>
    <input type="checkbox">Private posts
    <!-- Other options -->
  </fieldset>
</form>

This will behave as if the search field was part of the form. And you get the freedom of placing it wherever you want in your HTML.

Form options on fields

All the options that can be defined at the form level can be overridden at the field element. All submit fields (<button> and input type=”submit”) accept four new attributes : formenctype, formaction, formmethod and formtarget.

One use case could be a form with a preview and post buttons. Each one needs all the fields of the form but they perform a different action.

<form action="new_post.php" method="post">
<label>Title: <input type="text"></label>
<label>Content: <textarea></textarea></label>
<input type="submit" formaction="preview.php" formmethod="get" value="Preview">
<input type="submit" value="Post">
</form>

When the user clicks on the Preview button, its attributes will override the form’s attributes. In this case, instead of a POST request to new_post.php, the whole form will be sent to the preview.php script with a GET method.

Validation mechanisms

One of the big area of improvements for forms is validation. To give the best experience, we need to give feedback as soon as possible to the user. So people have written a lot of JavaScript code to do that. Wouldn’t it be nicer if browsers handled that?

required

By adding this attribute, you’ll mark this field as required. For text fields, it means that it shouldn’t be left empty. For checkbox buttons, it means it should be checked. And for radio buttons, it means one of the button for a group should be selected.

Try each of the examples below and you’ll see that they change color when you interact with them.

<input type="text" required>

<input type="checkbox" required>

<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>

url

URL fields are automatically validated.

<input type="url" value="mozilla">
<input type="url" value="http://mozilla.org">

email

Emails are also automatically validated. By passing the multiple attribute (also valid on type=”file”), you can also validate a list of mails separated by commas.

<input type="email" value="foo">
<input type="email" value="foo@bar.org">

<input type="email" multiple value="foo@bar.org, spongebob">
<input type="email" multiple value="foo@bar.org, spongebob@squarepants.org">

pattern

Urls and emails will not be the only type of data you’ll want to validate. Therefore, the pattern attribute will allow you to provide a JavaScript regular expression. This will be matched against the value of the field to determine if it’s valid. You should also provide a title attribute explaining the pattern to the user.

In the example below, try hovering over the text field. You should see a popup that tells you how to fill out the form.

<input pattern="[0-9][A-Z]{3}" title="A part number is a digit followed by three uppercase letters.">

The constraint validation API

If you need even more control over the validation, you can use the setCustomValidity method. If you provide an empty string to this method, the element will be considered valid. Otherwise, it will be marked as invalid and the string will be used as a tooltip to help your user understand the problem.

<label>Password: <input type="password" id="password1" oninput="checkPasswords()"></label>
<label>Confirm password: <input type="password" id="password2" oninput="checkPasswords()"></label>
<script>
function checkPasswords() {
  var password1 = document.getElementById('password1');
  var password2 = document.getElementById('password2');
  if (password1.value != password2.value) {
    password2.setCustomValidity('Passwords should match');
  } else {
    password2.setCustomValidity('');
  }
}
</script>

Password:

Confirm password:

If one of the field of a form is not valid, then submitting the form will be blocked and the first invalid field will be focused with a message explaining the problem. If you want to override this behaviour and send the form anyway, you can add a novalidate attribute on the form or the formnovalidate attribute on the appropriate submit button.

If you want more details on the validation mechanisms, check out Mounir’s blog post.

New CSS selectors

And to go with all this goodness are a few new CSS selectors.

:required, :optional

All fields are marked as :optional by default. If they have the required attribute, they’ll match the :required pseudo-class instead.

:valid, :invalid

These pseudo-classes represent the state of the field regarding validation. You can use :invalid to override the default styling that Firefox 4 provides.

Here’s an example of a text box where the default style has been overridden.

:-moz-placeholder

This pseudo-class targets input fields displaying a placeholder. This is not yet part of CSS, so you’ll need to use a pseudo-element for WebKit based browsers.

<style>
#selectors2 :-moz-placeholder {
  font-style: italic;
}
#selectors2 ::-webkit-placeholder {
  font-style: italic;
}
</style>
<form id="selectors2">
  <input placeholder="Style me">
</form>

Conclusion

Form features in HTML5 are very new, and there’s still a wide difference between browsers. Opera implemented part of the spec (it was called Webforms2 at that time) so it has decent support for HTML5 Forms, along with some quirks since the spec evolved since that implementation. WebKit-based browsers are currently implementing some parts of the spec so you’ll also find some early support there as well.

We will not be adding more form features in Firefox 4, and there is clearly still some work to get full support for HTML5 forms. New field types (numbers, colors, dates), new attributes (step, min, max), new events (onforminput, onformchange) and so on. We’ll be adding support for more of HTML5 forms in later releases.

This was just a rough introduction. To get all the details, you should go to the documentation on Mozilla Developer Network.

Ever wonder which industries have the most web developers? Do you know how many people develop for the web on Linux? Are there more web designers out there than web developers? Where do web developers hang out and what do they think of the resources out there today? Which JavaScript library is the most popular? How many developers use Google Code or visit the MDN for documentation?

We wanted to get answers to those questions and more… so we reached out to our community and beyond. We ended up with a snapshot of the web developers out there to better guide our plans for the Mozilla Developer Network. While we know a lot about Mozilla hackers, add-on developers, and those working on mobile, we wanted to learn more about web developers, who are by far the largest segment that we touch. And while there is data available about their demographics and the technologies they use, we couldn’t find anything that would give us a better understanding of where they hang out and what they think of the companies that are working on the products and technologies they build and use.

We looked at the breakdown of web developers, and of the websites and resources they rely on. We will use the results to improve our documentation on the MDN Doc Center and continue to better engage with web developers. As more mobile app developers adopt the web platform for apps and games we want to encourage web developers to push the limits of web applications. Our demos will showcase what the latest HTML5, CSS3, and JavaScript innovations. We want to use this survey to know what Mozilla can do to help web developers support the open web.

I’ll summarize the results from the 1,331 responses we received from our “Web Developers & the Open Web 2010” (WDATOW 2010) survey, and share the infographic we created to capture some of the key findings.

The Infographic

Our Sample

We reached the greatest number of respondents via our Hacks blog and @mozhacks Twitter account, but we were also able to tap into our global community through our localizers, who helped translate the survey into 9 languages: English, Spanish, German, French, Italian, Hungarian, Portuguese, Japanese, and Indonesian. We also posted requests for responses to various developer forums and websites affiliated with other companies, to ensure we had a broad sample that was as representative as possible. Of course we didn’t get as many responses from some of those channels, so the results should be interpreted with the caveat that active Mozilla community members are likely overrepresented.

However, that does not take away from the value of the information we have gathered. We identified “Mozilla” developers and “Other” developers based on answers to a few questions and found that the cross-over profiles of both categories of people were very similar. You can find out more on page 11 in the full report. We identified both categories based on the overall feedback on Mozilla sites vs other company sites, as well as how often they visited those sites, with those that primarily visited MDN making up the “Mozilla” developers, and those that did not being labeled “Other”. Therefore, while some of the open-ended questions might have a lot of subjective and fairly biased opinions, most of the questions produced fairly consistent responses from both groups when it came to the technologies and resources.

We had a very diverse set of respondents that spans the entire globe. While most other research has large US samples, with only a few other countries represented, for our survey, only 20% of the respondents were in the US. Given the high response rate from Europe, we ended up with a well-balanced international sample. That’s why some of our results may not look like web developer profiles that you have seen elsewhere. And that’s a good thing: we are providing another data point for comparison and further analysis.

Web Developer Profiles

We started the survey with some basic questions that would allow us to segment the developers taking the survey. One interesting finding that didn’t seem to match other research we had looked at was the primary OS used by developers. While we would expect most web developers to be on Mac OS X, followed by Windows and a small percentage on Linux (like in the Web Directions survey), we had a more evenly distributed breakdown. Recent Windows versions combined made up 46%, followed by a strong showing of Linux users at 30%, and Mac OS X with a 24% developer base. I would say that a strong bias towards open source in the sample combined with the fact that we had a lot of responses from outside the US are the reasons for Linux being more popular. Also, while a lot of people self-selected as both a web developer and designer, the sample definitely skews towards web developers, so perhaps that explains the Mac OS X numbers.

It was also interesting to see the years of experience spread out across veterans and newbies, with about 48% of the sample having less than 5 years of experience and 52% having 6 or more years in web development.

For our “What type of a web developer/designer are you?” question, respondents were allowed to choose more than one answer, so it’s not surprising to see that a lot of people work on many aspects of web development. However, it was clear that most of them were in one (or both) of two categories: 89% front-end developers and 75% back-end developers. There were more web architects than I expected at 41%, and designers made up a sizable chunk, at 39% of the sample. And although only 15% of those surveyed selected “Add-on developer”, we expect that number to go up as more web developers start to create Firefox extensions with Add-on Builder, using JavaScript rather than heavier-weight programming languages.

There were no surprises from the industries question, with most web developers working in technology at 38%, followed by media at 18%. And while there were smaller percentages working in other industries, 11% of those surveyed were students who have not yet entered the work force. For more on developer profiles see the full report.

Where Developers Spend Time

Perhaps the most important series of questions in this survey focused on the web resources and communities that developers rely on for their day-to-day work. Whether it was for looking up documentation or asking questions to debug their code, we wanted to get an idea of the most popular websites for web developers.

We picked a list of websites based on initial feedback from web developers during the survey design process, and the results clearly show that all of them are popular and engender a lot of opinions on aspects of those sites.

We not only asked which resource and community was the respondent’s favorite, but also provided a list of attributes for them to rate. PHP.net was the most popular resource at 32%, followed by jQuery.com and w3schools. And Stack Overflow was by far the most popular developer community at 40%, followed by GitHub and Wikipedia.

We intentionally included a diverse set of websites in order to see how developers rated them on our list of criteria. Since MDN supports both resources and communities, we wanted to get data on a broad set of sites. Be sure to take a close look at the ratings to see how all the websites did across a number of important attributes. You can find them starting on page 20 of the full report.

We were looking for a way to find out what works across a variety of site characteristics. For example, our Hacks blog is mostly posts about web technology, the MDN Doc Center is all about documentation, and our various programs and campaigns via Mobile, Add-ons, and Labs provide a more interactive forum for developers to get involved. Based on the ratings and open-ended feedback, we have learned a lot about which existing sites do well in terms of effectiveness, documentation, navigation, aesthetics, etc.

All of this information is valuable for us as we evaluate and prioritize projects that will help us grow and improve our MDN community.

Web Technologies

We also wanted to gauge which technologies developers are using right now. It was no surprise that the web standards trio of HTML, CSS and JavaScript remain the primary set of technologies for most web developers, with usage at over 95% for all three. PHP was also notably still the most popular programming language at 80%, with Python a distant second at 24%, followed by Flash at 22%. To see the complete breakdown of technologies used, as well as what developers identified as “open technologies”, see page 16 in the full report.

Within JavaScript, jQuery remains the most popular library at 82%. Prototype was used by 16% of the respondents, with Mootools next at 12%, and Yahoo’s YUI coming in at 10%. With so many JS libraries to choose from, we expect that those numbers will continue to shift.

We also asked which next-generation technologies were interesting to our respondents, and found out that HTML5 video, canvas, and SVG were all important to developers. 3D using WebGL seemed less interesting to them, but that might be due to the technology being not yet ready for prime time and the lack of examples in the wild. We hope to change that with the capabilities in Firefox 4 and beyond.

Company Affiliated Websites

Although all of the sites in this category serve different purposes and have varying feature sets, it was still important to get a feel for where developers were spending their time and how they viewed the developer sites from companies like Adobe, Apple, Google, Microsoft, Mozilla, Oracle, and Sun.

Given our sample, we expected most developers to have heard of and frequently visited Google’s and Mozilla’s sites. The data clearly shows both as popular destinations for web developers. But it’s important to note that these two sites offer different benefits to developers. Google Code is a great open source code repository and community, while the MDN website remains a very popular web documentation resource.

The other sites are mostly focused on promoting and supporting the company’s products and technologies, so it wasn’t surprising to see that many of our respondents had never, or rarely, visited them. Again, given our audience, we expected to see this and it was nice to confirm our assumptions.

What’s next?

Our survey report, as well as the high-level data reflected in our infographic, give us a snapshot of the web developers we serve through our MDN website and programs. With the insights from this survey, we now know where in the world our audience is, where they go for information and help, and what they think about the companies that help define the web.

A few key areas we need to work on right now are localization, documentation, and developer tools. From the knowledge we have gained, we now have data to back up some of the assumptions we have made to date, the details we need to refine our MDN roadmap, and user feedback to guide our developer engagement efforts from a marketing and communications stand point.

As we kick off the new MDN docs platform project, build out a demo gallery to showcase the latest in HTML5 and CSS3 the web has to offer, and continue to find ways to connect with the web developers that visit us every day, this survey and future developer research will continue to guide us.

Thanks to everyone who participated and we hope that you find the infographic interesting. We tried to capture the major findings in a way that would allow anyone to quickly get a sense of what the web developer community looks like today. If you’re interested in seeing the full report, it is available at: http://www.scribd.com/doc/39278543/Web-Developers-the-Open-Web-Survey-Results.

Thanks!
- Jay & the MDN team

UPDATE: I apologize for anyone that had problems viewing the full report on scribd.com. I did not realize you needed an account to view public slides. The report is now available for download in .pdf, .odp, and .pptx formats.