Upcoming events
Friday, 18 May 2012 to Sunday, 20 May 2012
Thursday, 24 May 2012 to Saturday, 26 May 2012
User login
Planet
brvty++ ?
Discussion. Responsive images. Picture too much? Srcset weird syntax? Brevity argument. Typing hard. People lazy. Let’s go shopping?
In other, more human, words: in the wake of the current discussion about responsive images and solutions using a picture element or the srcset attribute I came across an argument that always annoys me. And I fear that the more we use that argument the more we alienate ourselves from what the web is and how it became what it is now.
It is the argument for brevity in code above everything, especially markup. Shorter is better as it means people can type more and faster and there is less opportunity for doing things wrong. I call shenanigans on this.
XHTML’s failure was not the amount of code
The argument is based on the assumption that XHTML failed because it was far too much to type and too much work. HTML5 is considered superior as we only type what we need and we can even omit a lot of “optional” code as browsers are superb and will fix our omissions for us. We write much less and it still works. We call this pragmatism. Except it isn’t. It is laziness and the arrogant assumption that we write code for browsers to execute instead of people to read.
XHTML did not fail because of the amount of things you had to write. It failed because of the redundant things you had to write, its over-complexity and that it wasn’t supported the way it was meant to in the most used browser at the time.
And even that wasn’t the issue as nobody wrote all these overly complex constructs by hand – we have editors, templates and snippets for that. Code autocompletion is quite common. We were happy adding truckloads of Object/Embed code for movies until video came around and we never typed any of that by hand. We had tools for that.
Be productively lazy
Good developers are lazy in the sense that they don’t want to repeat themselves. Instead of doing the same boring and tedious task over and over again by hand we write a script to do it for us. This is what programming is for: allow humans to do better things than the repetitive tasks computers were made for.
If you write a lot of code and it never gets used that is frustrating. Very much so. It is also pointless work. However, the mistakes of XHTML should not push us into the other extreme of writing code for computers instead of writing code that executes and is easy to understand for people who want to learn or people who will have to maintain what we wrote.
Markup is different to other code
I love markup. I love the idea of – get this – marking up a document. Adding those funky bracket things around text and URLs is not about shifting bytes, accessing a chipset or setting an interrupt. They are there to give meaning to the texts and to the URLs they contain.
Think of them as highlighting texts with a marker and writing lots of explanations in the margins explaining the meaning of the highlighted texts. Think of them as the little booklet you get with Shakespeare’s Julius Caesar explaining to you what political, social or historical tidbits the author talks about that you would never get as you don’t live in that time.
Good markup brings meaning to text. Don’t take that away from the web for the sake of brevity and technical use cases that are possibly very short-lived.
The web we all work in right now isn’t the result of writing very clever and beautiful code nor is it the result of squeezing the last byte out of our documents to make them work perfect in a certain environment. Most of the atomic micro-optimisations and performance testing and tweaking we do can be undone by a single, badly coached and still well-meaning maintainer.
The web is easy to get into – let’s start with a clean slate
The web we have right now is the result of it being the most accessible media out there. You wouldn’t know how to put your photo and a big heading with your name in the newspaper or TV. But you can learn in a few minutes flat how to write a:
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Chris' page</title> </head> <body> <h1>Chris rules!</h1> <img src="http://example.com/chris.jpg" alt="Photo of Chris" title="that's me, that is"> </body> </html>
Why the doctype, the head, the charset definition and the body? Surely the browser will do that for us?
Because the code above should be the result of someone caring about the web telling you that:
- The doctype ensures predictability in displaying your page
- Defining the language means search engines have it easier to index the page and blind users don’t suffer hearing text pronounced in a different language
- The UTF-8 means that if you need international characters they will show up instead of rectangles or question marks and
- The head and body makes a clear distinction where your visible content and the instructions for the browser go.
All of this can be violated with intelligent and amazing tricks and still be valid HTML5 and cool. I am quite sure that a few people twitched at the last point and disagreed as you can style title to be visible and scripts can go in the body and there are use cases for inline styles and so on.
The point though is that none of the above hurts a web developer to write and all of it has a purpose. A structure like that makes it easier for people to learn the basics of what we do. It makes our work predictable, clean, maintainable and – at least to me – professional workmanship instead of crazy and cool geek stuff. We get tied up in the latter and one-up each other showing just what is possible and we forget that people are watching and don’t spend the time to learn the basics. Case in point? The excellent learning resource Codecademy lately added a HTML 101 course, omitting the doctype and alternative text for images in the first steps. We start to see teaching as “showing the quickest way” rather than “showing the cleanest way that explains and yields results”.
We value instant gratification over working for achieving a goal. And the gratification you feel when you achieve something you had to work for lasts longer and feels better than the fast variant. This includes making mistakes and learning from them. Giving people an environment that is incredibly forgiving as the first barrier to entry doesn’t help people grow or reach the goal on their own terms.
Fostering a new generation of webmakers
At Mozilla we have a very interesting thing going: we set a goal for ourselves to foster a community of web makers. We do workshops with journalists on how to use the web as a platform for news and entertainment. We show Popcorn as a way to produce news items that can be maintained without re-shooting. We talk to children and find playful ways to get them into making the web rather than ploughing through apps buying them, playing them for a day or so and discarding them to buy the next one. For this, we use markup and a live editor in the browser. Check out the web arcade to see what I mean.
The next generation of people coming into our market should not be virtual couch potatoes who want everything to work magically and discard it when it breaks or gets slow. Tinkering with the web is what got us where we are. Playing with the open technologies and learning from what others did made us the developers we are now. The next generation should be allowed to feel the same excitement about making that we feel now.
Be brief, but stay comprehensible
Writing not much to achieve something isn’t cool. Writing the least amount possible, getting your message across and making it easy for others to build on what you did is. It means you are free to do other, better, and – for you – much more interesting things.
Let’s focus on tools instead of muddling the basics
If you really want people to write less and achieve more, help improve and build tools for creating in a way that shortens the distance between creation and seeing the result. There is a lot of exciting work being done in this field and we need something for those who don’t want to write code. As people in the know we scoff at the Dreamweavers out there, but it is also our fault when bad code ends up on the web as we were too arrogant to help those who simply want to get their content onto the web.
Mobile Market Reports
“thinkinsights” and Google have released some fascinating data about smartphone usage, gathered from detailed consumer surveys.
All the presentation reports (right hand column) have roughly the same format. Why not download the report for your country, and the one for Brazil (the launch country for B2G) and see how different things are there compared to where you live?
Compared to the UK, in Brazil:
- Far fewer people have smartphones (14% vs 51%)
- Smartphones are used less often (40% vs 59% daily)
- They are used on-the-go less often (64% vs 86%) – poorer network coverage?
- Social networking is proportionately more popular than email
- Smartphone gaming is significantly less popular (39% vs 62%)
- They use fewer apps, even free ones (14 vs 23 installed)
- Almost all smartphone users are urban
- Cohabitation is significantly less common (20% vs 11%)
Thoughts: reading between the lines, network coverage is poorer and data-on-the-go is harder to find. We need to make sure B2G phones and apps are solid in absence of a good network connection. Also, the phone will be the only computing device for many users.
On the Way to 100%, Revamping Firefox Mobile for Android and more…
about:mozilla is a weekly round-up of news and contribution opportunities. Here’s what’s happening this week.
Firefox support questions: On the Way to 100%
If you ever need help with Firefox, the Firefox Support Forum is the place to go. In the community-powered support forum, everyone can help, including you. And everybody should be helped too. That’s why last year, the SUMO team set a goal for this year to achieve a 100% response rate, which means that every user who asked a question in our forum should get a response. But how close are we to the 100%? Find it out by reading David Tenser’s blog post or help by answering questions on the forums.
Visual Reboot of Firefox Mobile for Android
Firefox has always been a different browser, but with a recent strong wave of competitive browsers, all with similar features; design and product identity has become the differentiator. That’s why the Mozilla User Experience team revamped the design of the Firefox Mobile application for Android, and the results are stunning. Every single detail has carefully been elaborated, that’s why the new design isn’t just fluid, organic and unique to Firefox, but it also speaks strongly to the Firefox brand. Check out Patryk Adamczyk’s blog post to see what it looks like.
Windows on ARM Users Need Browser Choice Too
For the past eight years, Windows offered users a choice of browsers to navigate their digital lives. Prior to the launch of Firefox in 2004, Internet Explorer was really the only browser for Windows. Unfortunately, the upcoming release of Windows for the ARM processor could bring the digital dark ages back where users and developers didn’t have browser choices. But why does this matter to users? Check out Harvey Anderson’s blog post to find the answer.
The Web Will Connect our Future
Gary Kovacs, CEO of Mozilla, had the honor of delivering the opening keynote at a big event with a presentation titled “The Web Will Connect our Future.”. He shared with the audience that not only has the Web changed our lives once, but in mobile, the open Web is about to do it again. Check out his blog post to find out why he thinks that we all need to work together to stress the Web as a platform and to push over a few remaining hurdles like graphics and video and native device API access.
Desktop Apps with HTML5
One of the best things about HTML is that it’s never “done”. It’s been with us longer than most of the development technologies that we consider commonplace. Recently the Mozilla Apps Native Install Experience was introduced to the Firefox Nightly Channel. This functionality lets you install an HTML5 application with a native launching experience on your computer. All you need to do is to go to the Market Store, download an application and it will automatically show up in your Launchpad or in your program list. If you’re a developer, check out Joe Stagner’s blog post to see how it works.
Meet Some Mozillians
Bonjour Mozilla says bonjour to Poland, Ludovic & Zola and Janet Swisher. Read more about how these people are contributing to Mozilla.
Upcoming events
* May 16, Hotel San Marco, Via longena 42, Verona, Italy jsDay 2012
* May 16, London, England Geek Bowling
* May 19, Taipei, Taiwan JSDC.tw 2012
* May 20, Chicago (Rosemont), IL Society for Technical Communication Summit
* May 23, Melbourne, Australia Web Directions Code
* See more on the Mozilla Community Calendar
Get Involved
These are just some of the available contribution opportunities. Learn more about other ways to get involved and find other Mozillians in our community who share your interests.
About about:mozilla
The newsletter is written by Mozilla’s contributor engagement team and is published every Tuesday. For more on what has been happening this week also checkout the Mozilla Project Meeting. If you have anything you would like to include in our next issue,
please contact: about-mozilla[at]mozilla[dot]com or send us a status message on mozilla.status.net or a tweet @aboutmozilla. You can also subscribe to the email version.
Have a good week folks and keep rocking the Web!
The ‘other-licenses’ Directory: Don’t Use It
This is a public service announcement. There is a top-level directory in mozilla-central (and similar repos) called “other-licenses”. Don’t put any more code in it. Really. There’s now even a README saying so.
Longer version: this directory is not for non-MPLed code, it’s for non-MPL-compatible code, of which we have very little. There is some stuff in there which shouldn’t be, but let’s not make it worse, OK? :-) Keep your code where it logically lives; don’t make your life harder than it needs to be. If you really think you are importing code which needs to be in there, you should be talking to licensing@mozilla.org first (as with any code import) and explicitly saying you think that this is where it should go, so they can tell you that you’re wrong ;-)
To hell with browser wars panels
Summary: Browser War panels have become predictable and non-informative. Instead they are there to entertain the audience but cause much more drama than good.
I go to a lot of conferences. I organised events, a conference and a few unconferences and I spoke at a lot of them. Lately I also stepped back a bit to coach people to speak instead of me going everywhere.
I think conferences should do a few things: educate, entertain, allow people to network and make speakers and experts available to attendees.
You don’t need to go to conferences to learn things – all the information is on the internet and signing up to a few good feeds, groups and lists will get you all the info you want.
What conferences do is bring the human factor into it. A good speaker can make a topic come to life and show you an angle you had not thought about and inspire you to play with it. A good workshop gives you guidance how to use a technology and gives you a way in without being overwhelmed by a big scary topic. A conference gives you time out from the day to day delivery and allows you to do things that are not yet on the radar of your company but might be soon.
And then there are “browser war panels”. The original premise of the browser war panels was that an audience could hear the latest and coolest about different browsers and ask questions. The first ones were held at Yahoo and had lead engineers from the different browsers to show how the different products work as that was dark magic back then.
HTML5 defines how a browser should deal with the content it gets – we have a lot more predictability already in the standard. A lot of great information on this topic is out on the web and the accelerated speed of delivery of browsers makes the appearance of platform engineers not happening much. There is no need to repeat the standards, instead the discussions are much more about what makes which browser stand out and in a lot of cases this means what the company wants to promote – not what developers want to use now and get stuck as it doesn’t work.
Browser panels these days get people from companies who are either product evangelists of the browsers or general tech evangelists, advocates, or – in the worst case – sales people. This could be good, they can point out features that are in the browsers people don’t know about and they can show some of the plans for the future of the browser. It can also be awful. As browsers are interesting to the media out of a sudden you see a lot of patterns being followed. Instead of giving information about the browsers, dealing with concerns of developers and implementers or showing changes panelists begin to fall into predefined roles and repeat the messages of the companies they represent.
It becomes predictable to see which company representative will value speed over everything else, which one will praise a great experience in the browser as part of a bigger OS experience, which one will talk about following standards and complain about sites blocking out browsers and which one will point out that the browser is the choice of the user and should keep them in control by being open about everything whilst following standards.
The bigger focus on browsers we have these days makes a panel much less of an educational part of the conference (many a time you will get “I have to go back to the engineering team for this”) but pushes it into the entertainment part of a conference. It is a veiled sales pitch.
Everybody loves a good drama. You could go as far as saying that we have a whole tech journalism market that lives on drama. It is fun to see people disagree on topics and make good arguments about one side or another.
A quite open, unscripted and unplanned format like a panel makes for great drama. It is easy to take potshots at each other and score browny points with the audience with pointing out flaws of the other browsers in a glib fashion. It also gives browny points with the audience to make sweeping statements or deliver soundbites.
Soundbites, being witty and fast are becoming the most important part. If you look at the Twitter stream of a browser panel you will hardly ever find a “oh feature $x will ship in browser $y – so cool” but you will get more “$x of browser $y just called $z out on the $a issue”.
Soundbites are also loved by the press. And as drama brings headlines many a time you will find a sarcastic remark or glib retort show up as “Company representative $x said $y about the competition”. A quick shot to get a giggle out of the audience can cause the communications team of a company to get a lot of unnecessary work. Is that worth it?
I’ve even been on panels where the organisers deliberately asked panelists to find topics to disagree on or seen panel moderators throw out one loaded question after another to entice people to disagree and get the drama going. We call this trolling or baiting, and not a way for conference participants to learn about what is going on in the browser world.
It is not hard to find what is going on in the browser world when you look at the open source engines. You hear much less about the closed ones and to me a panel that has no participant of Apple on it is not a “browser wars” panel as it lacks a massive player who should answer quite a few questions web developers have.
There are exceptions. I thoroughly enjoyed being on the panel at State of the Browser 2 in London and I think as there were no egos and no artificial drama we managed to answer quite a few questions from the audience. But on the whole, these are few and far between and many a “Browser Wars” panel is entertainment and cheap laughs or “wow, did he just say that” moments.
This, in the long run, is not fair to the audience who paid good money (and should get real comedians or entertainers if entertainment is the goal), it is not fair to the platform engineers (as they are misrepresented instead of allowing people to peek under the hood with them) and it does not get us anywhere in the real “browser wars”.
As developers you should not be tempted to build for one browser only and you should not have to build different versions for different browsers. Keeping it all about drama and who shouts the loudest and comes across as most witty doesn’t make that happen. It is a waste of time.
Tracking the trackers, become a Mobile Test Driver and more…
about:mozilla is a weekly round-up of news and contribution opportunities. Here’s what’s happening this week.
Tracking the trackers
Gary Kovacs, the CEO of Mozilla, has given an interesting presentation on a contemporary topic, “Tracking the trackers”, at the TED university. TED is a nonprofit devoted to “Ideas Worth Spreading” and they make the best talks and performances available to the world – for free. During that, he has shown the crowd a demo of Collusion, a tool that shows you who’s tracking your bahaviour on the internet. Make sure to check out his talk.
Firefox Flicks at the San Francisco International Film Festival
The big Firefox Flicks contest which allowed people to submit videos that tell our stories has come to an end and the jury is now choosing the best videos. The winner will be announced in nine days and to give a few impressions of the videos, the Firefox Flicks team hosted a part at the San Francisco International Film Festival and showed a teaser reel with some outstanding submissions. You can also watch all of the entries on the Firefox Flicks website and check back for more updates. May the best video win!
Become a Mobile Test Driver
Firefox for Android is extremely important to our mission, because we want to deliver an exceptional mobile web experience for users. That’s why the developers are trying to re-architect Firefox by using a native Android user interface. But we need your help to test daily builds of Firefox and file bugs if you run into them. The Mobile Test Drivers are fighting for a better Web, and you can become one too. If you don’t have an Android smartphone, you can be provided with a loaner phone. Go to the Testdrivers Program page for more information.
How do browser engines work?
Have you ever heard something about browsers’ internals? If not, then Anthony Ricaud can explain it to you! He gave a talk about what’s inside a browser to give web developers a better understanding of the internals of the “black box”. You can find a video of his speech right in his blog post, but if you prefer to read everything for yourself, you can also just take a look at the slides.
MDN Hack Day Tour
It was a whirlwind week for the Mozilla Developers in Latin America, who visited four cities over the course of 10 days in the southern part of South America to meet up with developers and Mozillians. The crew talked about HTML5, Boot To Gecko and the soon-to-be-launched Mozilla Marketplace for HTML 5 apps. Read more about the tour in the blog post by Havi Hoffman, the content curator at Mozilla Labs.
Meet Some Mozillians
Bonjour Mozilla says bonjour to Thierno Ndiaye, the Gaia team, the Firefox Flicks actors and our new flowers. Read more about how these people are contributing to Mozilla.
Upcoming events
* May 11, New Brunswick, NJ Professional IT Community Conference
* May 14, San Francisco, California AnDevCon
* May 16, Hotel San Marco, Via longena 42, Verona, Italy jsDay 2012
* May 19, Taipei, Taiwan JSDC.tw 2012
* May 20, Chicago (Rosemont), IL Society for Technical Communication Summit
* May 20, Buenos Aires MDN Hack Day
* See more on the Mozilla Community Calendar
Upcoming events in London, England
* May 9 Open House
* May 10 Geek Quiz
* May 12 MDN Hackday
* May 14 Monday Mobile Madness
* May 15 Open House 2
* May 16 Geek Bowling
Get Involved
These are just some of the available contribution opportunities. Learn more about other ways to get involved and find other Mozillians in our community who share your interests.
About about:mozilla
The newsletter is written by Mozilla’s contributor engagement team and is published every Tuesday. For more on what has been happening this week also checkout the Mozilla Project Meeting. If you have anything you would like to include in our next issue, please contact: about-mozilla[at]mozilla[dot]com or send us a status message on mozilla.status.net or a tweet @aboutmozilla. You can also subscribe to the email version.
Have a good week folks and keep rocking the Web!
WikiProject Mozilla: Help Wanted
A week ago I lamented the sad state of the Mozilla-related articles on Wikipedia, and suggested it would be good to form a “WikiProject Mozilla” to clean them up. Robert McKay was kind enough to write a proposal on Wikipedia for such a project. If you are an existing regular or semi-regular Wikipedia editor and would like to help Mozilla by working on this, please add your “~~~~” to the Support section of that page, and keep an eye on its progress.
Demoing and displaying JavaScript at the same time using CSS
When writing documentation or doing examples you constantly run into the same issue: how do you display and demo the code at the same time? You don’t want to have a code display and live code as they will get out of sync (on the other hand I always found that when copying code into a document I also cleaned it up and optimised it).
The easiest way for this are all the “new” services like JSFiddle, JSBin, Dabblet, Tinker.io and others (there seems to be a new one every month now) and you can even embed them into other documents, but it means you need an iframe and load content from another service (which might go down or get forgotten in the future).
The other way of course is to use Ajax/JavaScript to load the code into the page. Back in 2008, I wrote the Ajax Code Display script for that (and subsequently I never used it much).
I was wondering how you can simply demo and show inline JavaScript in a document without needing any extra libraries. The simplest way seemed to read out the innerHTML of the SCRIPT element and write it out into a PRE using textContent (innerHTML would render HTML or greater signs in the script, which isn’t the idea).
However, you can do a simple demo and display of the same script much easier these days using CSS. Check out this demo page for an upcoming Smashingmag article:
If you do a view-source you find no other script in use, yet it displays in the page. What is this sourcery*? Simple, and it was Mathias Bynens who got me onto it: just display script elements as block and add some generated content to show the “Source” text:
script { display: block; white-space: pre; text-shadow:none; background: #333; color: #fff; font-family: monaco, courier, monospace; padding: 10px; } script::before{ content: 'Source:'; color: #0f0; }
Mathias has much more detailed explanations on why that works but I for one am once again amazed just how much easier things are these days with the awesome browsers that we have.
* Sourcery = magical code that does (seemingly) unexpected things.
Mozilla Grows Too Big For Summit
A quick Public Service Announcement, just in case anyone still has their summer plans on hold: Mozilla is now too large (yay!) to get us all in one physical location. So there won’t be a Mozilla Summit this year. Instead, the hard-working Contributor Engagement team is stepping up the pace on regional MozCamps – we’ve already had one in Latin America, and they are planning one for Europe, one for Asia and one for Africa/The Middle East before the end of the year. I won’t steal their thunder; look for more details very soon :-)
GSoC 2012 Project List
The Google Summer of Code kicked off two weeks ago, and I am pleased to list the 18 projects being done under the Mozilla banner. This is a 50% increase on last year; we are very grateful to Google for being so generous with slots. The name of each student is linked to the location where they will be posting weekly updates on their progress, if you want to follow along with a project you are interested in. (Apart from those students who have not yet sent me this information; consider this a public reminder.) I’m sure they would appreciate any help or advice you have :-) Please make them feel welcome!
| Project | Student | Mentor |
|---|---|---|
| Thunderbird: ‘No Reply’ Reminder | Han Lin | Jonathan Protzenko |
| Thunderbird: App Tabs | Nguyen Ngoc Trung | Mike Conley |
| Calendar: Improve Invitation Support | Christian Kulpa | Ludovic Marcotte |
| Dynamic MathML – Support <maction> | Andrii Zui | Fred Wang |
| HTML5 and CSS3 Examples on MDN | Vikash Agrawal | Jean-Yves Perrier |
| Get ISPDB Into Production | Sergio Charpinel | Blake Winton |
| Graphical Timeline of Browser Events | Girish Sharma | Panos Astithas |
| Improve Gmail Interoperability | Atul Jangra | David Bienvenu |
| Instantbird: Account Import Wizard | Will Nayes | Florian Quèze |
| L10n Tool for Standardization of Terms | Gautam Akiwate | Philippe Dessante |
| Meemoo Improvements | Vilson Vieira | Forrest Oliphant |
| Native Webapps Support on Linux | Marco Castelluccio | Felipe Gomes |
| Networking Dashboard | Jiten Thakkar | Patrick McManus |
| OpenBadges Back End Improvements | Matthew Ramir | Chris McAvoy |
| Port SuperTux to the Web | Xingxing Pan | Alon Zakai |
| Slide Drive Improvements | Jeremy Banks | Greg Wilson |
| User-Specified Content Security Policy | Kailas Ravsaheb Patil | Tanvi Vyas |
| WebSocket Testing Tool | Robert Koch | Yvan Boily |
Pages
