Planet Mozilla — Mozilla Hacks Weekly, May 24th 2012

It’s Thursday and time for us in Mozilla’s Developer Engagement Team to share some great links!

At the end of this blog post, you also have all the Developer Engagement team members and what they work on. If you are interested in discussing more, contributing or taking part of our work, don’t hesitate to contact us or follow us on Twitter!

Weekly links

If there is anything you think we should read or know about, don’t hesitate to post a comment, contact us on Twitter or through any other means.
The picks this week are:

The Developer Engagement team

Mozilla’s Developer Engagement team work with writing articles, documentation – such as MDN (Mozilla Developer Network) – public speaking and generally helping and informing about open technologies and Mozilla products. If you are interested in following our work, here are the team members:

<section class="hw-team">

Christian Heilmann

Christian is Mozilla’s Principal Evangelist and is working with HTML5, Open Web, BrowserID and Developer Tools in Firefox. He is also maintaining the @mozhacks account together with Robert Nyman.

Blog: http://christianheilmann.com/
Twitter: @codepo8

Eric “Sheppy” Shepherd

Eric is the Developer Documentation Lead for the MDN documentation and everything surrounding it.

Blog: http://www.bitstampede.com/
Twitter: @sheppy

Havi Hoffman

Havi works with Mozilla Labs and WebFWD, and maintains the @mozlabs account.

Twitter: @freshelectrons.

Janet Swisher

Janet is working on MDN documentation and is organizing doc sprints to ensure we have premium quality on MDN.

Blog: http://www.janetswisher.com/
Twitter: @jmswisher.

Jean-Yves Perrier

Jean-Yves is another one of our technical writers working on MDN documentation.

Twitter: @teoli2003.

Jeff Griffiths

Jeff is working with the Add-ons SDK (Jetpack).

Blog: http://canuckistani.ca/
Twitter: @canuckistani

Joe Stagner

Joe is working with Web Apps Developer Ecosystem & Partner Engagement, HTML5 and the Open Web.

Blog: http://www.misfitgeek.com/
Twitter: @MisfitGeek

John Karahalis

John is working on Dev Derby.

Twitter: @openjck

Rob Hawkes

Rob is working on HTML5 games and the Open Web.

Blog: http://rawkes.com/
Twitter: @robhawkes

Robert Nyman

Robert is working with HTML5, Open Web, Firefox, WebAPI and maintains the @mozhacks account.

Blog: http://robertnyman.com
Twitter: @robertnyman

Shezmeen Prasad

Shezmeen is working on everything regarding events, organization and connecting conferences with Mozilla speakers.

Stormy Peters

Stormy is the Team Lead for the Developer Engagement team. managing it and evaluating our objectives.

Blog: http://stormyscorner.com/
Twitter: @storming

Tristan Nitot

Tristan is our Mission Evangelist and is focusing on the bigger picture of Mozilla.

Blog: http://standblog.org/blog/en
Twitter: @nitot

Will Bamberg

A picture of Will Bamberg Will is working on documentation for the Add-ons SDK (Jetpack).

</section>

WHATWG blog — The Future of the Web: My Vision (May 23, 2012)

I apologize for the longer than expected wait for this article, but now, we may continue.

The article below will pick up where Part 1 left off.



<section>

Article 1: Websites and Sectioning
Part 2: Styling


<warning>Warning: This article discusses the topic of <semantics>semantics</semantics></warning>

As we began with previously, we now have the basics down as to how to properly divide information into sections. This time, we will be looking into the second aspect of sectioning: Styling.

When a search engine or screen reader scans a website, it does so by evaluating the markup of the page. Humans however, view by way of sight. If we were to use absolutely no form of styling, it would be difficult, if not impossible, to logically divide an article into sections.

</section><section>

When we read through a webpage, several common features are used to guide us in logically separating it out:

<figure class="list">
  • Bolded text defining headings.
  • Heading text larger than the content below it.
  • Logical heading levels which decrease in size as it gets deeper.
  • Ocasionally indenting subsections and subheadings within their parents.
</figure>

Web browsers of today will often do much of this work for you, but this is not always enough. Below, I will show you at most basic, the heading layout I choose to use when building a website.


<article>


<header><h1>Main Heading</h1></header>


<section class="topsection">


<h1>Top Heading</h1>


<p>Section Content</p>


<section class="subsection">


<h1>Heading</h1>


<p>Section Content</p>


<section class="subsection">


<h1>Heading</h1>


<p>Section Content</p>


<section class="subsection">


<h1>Heading</h1>


<p>Section Content</p>


<section class="subsection">


<h1>Heading</h1>


<p>Section Content</p>


<section class="subsection">


<h1>Heading</h1>


<p>Section Content</p>


</section>


</section>


</section>


</section>


</section>


</section>


</article>

<figure> <iframe height="425" seamless="seamless" src="http://chrisbright.net/future/c1p2f1.html" style="border: 0; overflow: visible;" width="100%"></iframe> <figcaption>Output of Example 1</figcaption> </figure>

Now obviously, this is more compact than any site would naturally be, and wouldn't use such simplified text. However, this perfectly demonstrates the decreasing levels of the font size of the heading. With each level, it gradually scales downward, starting from nearly 3 times larger than the content at highest, to the same size as the content at lowest.

To achieve this, we use the following CSS Code.


article header h1 { font-size: 2.75em; }
section.topsection h1 { font-size: 2em; }
section.subsection h1 { font-size: 1.75em; }
section.subsection section.subsection h1 { font-size: 1.5em; }
section.subsection section.subsection section.subsection h1 { font-size: 1.25em; }
section.subsection section.subsection section.subsection section.subsection h1 { font-size: 1.125em; }
section.subsection section.subsection section.subsection section.subsection section.subsection h1 { font-size: 1em; }
section h1, section p { margin: 0; }
Note: I admit I am not absolutely perfect with styling, so if anyone knows a more efficient way of styling this same result, please mention so in the comments.

As you can see, the above code generates a much more aethetically pleasing, and far more understandable result than one without styling.

</section>

At this point, you are probably asking: How can this actually apply to real life?

Well, below this I will explain.


<section>

Use in Practical Design

As mentioned above, the true power of this method is revealed when used in practical application.

In the figure below, I will demonstrate said power by use of the first chapter of the book Alice's Adventures in Wonderland by Lewis Carroll.


<figure> <iframe height="425" src="http://chrisbright.net/future/c1p2f2.html" style="border: 0; overflow: visible;" width="100%"></iframe> <figcaption>Styling used in Practical Application</figcaption> </figure>

In the above sample, you can easily see the logically broken down structure of the chapter. You have the main article with its heading, the major logical division (the chapter), and two minor logical divisions (the sections). Although the subsections lack heading text, you can still tell that they are seperated. Even if you were to remove the row of stars, the spacing alone would be able to divide them.


And now, to show the code that makes it work:


HTML:
<article>


<header>


<hgroup>


<h1>ALICE'S ADVENTURES IN WONDERLAND</h1>


<h2>By Lewis Carroll</h2>


<h3>THE MILLENNIUM FULCRUM EDITION 3.0</h3>


</hgroup>


</header>


<section class="topsection">


<h1>CHAPTER I. Down the Rabbit-Hole</h1>


<section class="subsection">


<p>...</p>


<p>...</p>


<p>...</p>


<p>...</p>


<p>...</p>


</section>


<div class="sep">* * * * * * * * * * * * * * * * * * * *</div>


<section class="subsection">


<p>...</p>


<p>...</p>


<p>...</p>


</section>


</section>


</article>


Note: Text removed to prevent overcluttering.


CSS:
hgroup * { margin: 0; }
hgroup h1 { font-size: 2em; }
hgroup h2 { font-size: 1.5em; }
hgroup h3 { font-size: 1em; }
section { margin-bottom: 2em; }
section h1 { margin: 0.5em 0; }
p { text-indent: 1em; margin: 1em 0; }
p:first-of-type { margin-top: 0; }
.sep { font-weight: bold; margin: 0 1em 2em; }
Note: To show the full extent of the sample, this example uses a multi-tier heading for the article. This will be explained further in Part 3.

And here we have it. Together, the markup and the styling provides a neat, clean look which greatly improves readability. As well, it is written in semantic code which allows computers to properly understand its meaning.

</section>

In conclusion of this section, we have now learned the importance of sectioning, as well as how to properly style sections. These two concepts, when applied properly, could help create a much richer and more consistantly appealing world wide web in the coming future.

Next time, we will be discussing more advanced ascpets of this layout principle, such as multi-tiered headings and asides.

Until then, I hope that you have learned something new from this subject.

-Christopher Bright

<section>

Notes

  • Starting from now, if this article does not thoroughly desribe something for you, please leave a comment detailing your problem. I will do my best to update it.
  • I will soon be working out a method to rate the usefulness of this article, for future reference.
  • Any comments made will be taken into consideration for the future. I intend to make this beneficial for everyone, so all comments are accepted.
  • Examples will now be made within iframes, due to the possible large size of the content.
</section> <section>

References

Alice's Adventures in Wonderland
Written by Lewis Carroll
Converted to ebook by David Widger of Project Gutenberg.
www.gutenberg.org/files/11/11-h/11-h.htm#2HCH0001
All rights go to their respective owners.
</section>

Planet Mozilla — Recap of my South America tour

The last 12 days of April, I was part of doing a MDN Tour of Argentina, Uruguay, Brazil and Chile and also attending the MozCamp in Argentina.

Pictures!

There’s going to be a lot of text below – and I’d love for you to read it! – but if you want the pretty pictures, they’re available at:

MDN Hack Day, Buenos Aires, Argentina

We had a little over 150 attendees showing up, and gave presentations on:

  • Dev tools (Kevin Dangoor)
  • Persona (Dan Mills)
  • Web Apps/Privacy (Shane Caraveo)
  • Add-ons SDK (I believe Hernan Colmeiro, community member, gave the talk, supported by Jorge Villalobos)
  • A talk by Telefonica/BlueVia who were sponsoring our tour
  • Philipp von Weitershausen also gave a quick demo of Boot to Gecko
  • JavaScript APIs – The web is the platform (Robert Nyman)

After having been on a plane all night, I arrived at the hotel, took a shower and got up on stage to give my presentation (which might also explain if my recollection of the speakers above isn’t a 100% correct). It went down well, and the crowd seemed to be very focused and interested in all the talks and what was going on. After lunch the afternoon was dedicated to hacking away on whatever people were interested in, and I noticed Jorge was hosting a big group directly on Add-ons.

The other crowd bringer was the Boot to Gecko part where I and Philip demoed B2G phones and showed how they could hack around with things, and we were later helped in an excellent manner by John Hammink (working with QA for mobile). People stuck around for a good time after the event was actually finished and were really dedicated, so that made me really happy!

Overall, a very successful event and a great start to our tour!

In the evening there was a pre-party before the MozCamp event, and poor Jeff Beatty (who looks more Swedish than I do) were walking through the streets of Buenos Aires in the Firefox costume, greeting people and children alike. After 8 blocks or so, finally at the venue, he was drenched with sweat.

Buenos Aires, Argentina

That evening ended with a special moment for me, having a revelation about what I spend my time doing: Why I Do What I Do.

MozCamp, Buenos Aires, Argentina

The good parts were hanging out with an awesome and excited community, and the hallway talks and general mingling. The less good parts were, from what I heard from people, not any proper food to eat during the event, just small snacks/dishes. Personally I think they were tasty, but I see their concern. WiFi access was also really bad.

I have to say, though, that the speaking itself at MozCamp for me was the low point of this tour. And the reason for that is that during my talk (my slides from MozCamp) there was about 20 people altogether (at least a third Mozilla employees), with maybe 4 of them actually looking at me – the rest of them were deeply entrenched with their laptops. And this wasn’t just for my talk, this seemed to be the norm for all the talks in the technology track (I can’t say for the other tracks). The problem here is that while you have those 4 dedicated persons, the rest of them are, at best, listening with just one ear, only looking up at times.

Personally, I’m used to giving a lot of presentations, so having people less interested or occupied with other things is something you get used to; but if only a minority of the people actually pay attention to you, your presentation will not be as engaged and lively as it would be with people taking part. And imagine people not used to giving talks (both Mozilla people as wells as community members): if this were to be their first speaking experience, I’m sure a majority of them would refrain from doing it again. And that’s far from what we want.

For me, I think I could have used that time a lot better, and we’ve also had an internal e-mail discussion about this and Kevin Dangoor also blogged about it in The Two-Way Conference (MozCamp and more). Where I agree with Kevin is that a MozCamp with presentations is mostly just about preaching to the choir, people who are already onboard and share the same values. For future MozCamps, I’d rather see short presentations or just open discussion forums where people can delve into the details of things.

Personal upside is that in my talk I showed how you could combine various APIs to create things, something that inspired Philipp von Weitershausen for how MMS might be implemented in Boot to Gecko. So, that’s pretty cool. :-)

Another great event to build community and relations was that Gary Kovacs, Mozilla employees and community members met early Sunday morning to play football. Just looking at the smiles on peoples’ faces and seeing which people spoke to each other who normally never would, it was a very successful event!

(Personally, I probably shot my career to pieces when I did a tunnel on Gary, but hey, the moment was RIGHT there! :-) )

Playing football

Last day, Kevin Dangoor and I had a very nice walk around Buenos Aires, looking at Evita’s grave and other things before it was time to leave.

Buenos Aires, Argentina

MDN Hack Day, Montevideo, Uruguay

After a boat trip to Montevideo from Buenos Aires, we got settled in the very nice city. Went to the hotel gym and realized they had an entire running track inside the building! Pretty cool. :-)
Had a decent sleep, and then me, Shane Caraveo and Victor Prasad had a good walk around Montevideo, and then later met up with Shezmeen Prasad and Dan Mills for lunch, followed by some sightseeing together.

Montevideo, Uruguay

The MDN event was held at Café la diaria, a local place with a lot of chairs, a bar and a small little stage with the slides projected directly on the wall – felt like a mix of old-school and stand-up. We had a lot of help from local company Cubox and Evan Henshaw-Plath, which I’m sure contributed to both good organization and high attendance level.

We had about 100 attendees, and the presentations were:

  • Persona (Dan Mills)
  • Web Apps (Shane Caraveo)
  • A talk by Telefonica/BlueVia who were sponsoring our tour
  • Responsive Web Design (Nicolas Barrer, local talent)
  • Social Change through the web (Fernando Briano, local talent)
  • JavaScript APIs – The web is the platform (Robert Nyman)
  • Lightning talks

The event went down really well, and from what I understood with the little Spanish I know, Nicolas Barrer gave a talk that was both entertaining and full of good information, which was really appreciated.

Overall, a really nice vibe in Uruguay and exciting talks with the developers there!

(pretty picture to ease the reading, if you have made it this far)

Montevideo, Uruguay

MDN Hack Day, Sao Paulo, Brazil

Being Swedish, as opposed to my American friends on this tour, I didn’t need a visa to go to Brazil. Therefore, the next leg of the tour, helpfully organized by local company Caelum, were to be a Mozilla one-man show from me giving two talks in Sao Paulo. But before that, Fábio Magnoni and Clauber Stipkovic met up with me and we had a nice lunch together. After that, Fábio took me all around Sao Paulo and the number of places we crammed into seeing in one day was impressive! One of the highlights was going to the Estádio Municipal Paulo Machado de Carvalho and the football museum where we, amongst other things, got to see the shirt Pelé wore when Brazil won the World Cup in 1970.

Sao Paulo, Brazil

The talks I gave at the event in the evening were:

In addition to that, local developer Gabriel Oliveira spoke about CSS3, and from what I could understand, he showed some really interesting things!
There were about 40+ attendees this very rainy night in Sao Paulo, and while there weren’t many people, I was really happy to see the nods of approval in the audience during my talk, when I expressed Mozilla’s values and approach to the web and moving forward. After my presentations, we stood around for a long time discussing the web, -webkit prefixes, H.264 support and more. People seemed to be understanding and pragmatic, and I believe there were some really talented people there.

It was also the first time I had to hush two people talking during my talk (it was a small room, so any noise bounced around). That’s a hard thing to do for a Swede, but I think they understood where I was coming from and listened attentively during the rest of the talks. :-)

Sao Paulo, Brazil

MDN Hack Day, Santiago, Chile

Meeting up with the team again in Chile, we spent Saturday with my local friends Rodrigo Ayala and his girlfriend Paulina, that I met first time during my last visit in November, speaking at the StarTechConf. Joining us wereHernán Rodríguez Colmeiro and Shane Caraveo, and later on Victor Prasad met up with us. It was a great day with lots of fun, where we got to eat lunch with lots of interesting local dishes at the El Rincon de Los Lanallas restaurant. We also walked up the small hill in the city named Cerro Santa Lucia, and had a great view from there!

Santiago, Chile

The evening event was held at a local university and there were maybe 50 people there.

The talks were:

Good event, and the time and effort that had gone into preparing the lightning talks was impressive! I’d also like to say that Hernan gave a really good talk and interacted quite well with the local people. I’d love to see us work more with him, as an Evangelism Rep or employee of any kind. He used to be an intern for Mozilla, and I do hope we will move forward to some kind of future collaboration.

(And, well, Santiago has all kinds of people:)

Santiago, Chile

Summary

First of all, I’m so happy to see all team members and speakers I traveled and worked with during trip be so happy, dedicated and engaged all the time! Except for the speakers mentioned above (Shane, Dan, Kevin), Shezmeen Prasad and Havi Hoffman worked so hard on organizing everything and making it happen.

This was the first MDN Tour approach that we tried – something I suggested a few months back to to utilize time and effort for maximum results – and I think it worked out quite well. When you are in a certain region, it makes so much more sense to travel around and do a few local events than spending the majority of our time on airports and planes just for 45-minute presentations and then go home again. It also meant that we didn’t have to sit through days of conferences (which can be good at times, don’t get me wrong), but instead having our own focused event to build relations and community. And we got better and better at our own presentations, dealing with common questions and getting new input from new places.

All in all, it was a great experience, and my biggest thanks to everyone who made it happen and to all those wonderful persons I met!

Planet Mozilla — Mozilla at the JS Day 2012 in Verona

Last week I was in Verona, along with Paolo Amadini and Tim Taubert, to represent Mozilla at this italian javascript event. Matteo Ferretti was also there with us, as a Mozilla speaker, presenting an interesting talk about the add-ons sdk.

I must admit the event overcame my expectations and that's really amazing! Many attendees came from all over Europe to participate to the JS Day, since this is one of the few european events really focused on javascript. Moreover, the success of the event perfectly represented the major increase of attention on javascript, and especially on HTML5 applications, from the italian community and enterprises.

keynote room

We had a really warm welcome, both from the staff and from all the people coming to our booth.  We discussed about our mission with the many persons who stopped asking questions and looking at the demos we brought and we got largely positive feedback.  Our mission is positively understood and embraced by who cares about the future of the Web.

Firefox banner

The most common arguments we got questions about were Boot2Gecko, the new Web APIs, Web Apps, the Marketplace and DevTools. We had some live demos about all of them, to actually show this is not just "future", but something they can start using soon. Everyone is really excited about the incoming products and features, so the most common question we got was "When will I be able to use it?" :)

Booth

Apart from the booth, that took most of the time, we were able to see a couple great talks (among which the Douglas Crockford keynote on programming style), get in touch with with persons looking forward to have Mozilla at future italian events, share arguments with other companies putting large efforts in HTML5 apps, frameworks and markets.

Social event

As a final thought, Verona is a really nice city, perfect place to spend some days hacking and learning about javascript, so I'm definitely looking forward for the next year.

Verona

Planet Mozilla — FOSS Spotlight: Spotcommander

This is the first in hopefully a monthly to bi-monthly update I will provide on interesting and notable new FOSS projects and without further ado…

Spotcommander is a nifty web-based remote control project for Spotify that allows Linux users who have a quality sound system to remotely control their Spotify for Linux client remotely.

Spotcommander is based on HTML5 and PHP with a dash of jQuery and a nice icon set and is developed by Ole Jon Bjørkum of Norway.

Screenshots:

screenshot2 large 180x300 FOSS Spotlight: Spotcommander  screenshot3 large 180x300 FOSS Spotlight: Spotcommander  screenshot8 large 180x300 FOSS Spotlight: Spotcommander

Grab the source here: http://www.olejon.net/code/spotcommander/?download_page

Planet Mozilla — Testing the Firefox browser on mobile websites: Are you game?

Friends and hackers, we have a challenge

Are you a developer who’s passionate about Mozilla’s mission on the open Web? We need your help: We’re looking for someone to build a game to help keep the Web open as it goes mobile. There’s a Firefox mobile website testing app which we think would make a nice little HTML5 game — with scoring, achievement, levels, leaderboards — and we think you have the chops to make it fun. We’ve had some success making a game of the activity within our team, but we think you could do it better.

Here’s some context. We need lots of people looking at lots of frequently visited websites to see if they look good and work well on mobile. And if they don’t, we need to figure out how to make them better: by finding the bugs and fixing our browser or by working with the developer who built the site to make it work on the open Web. Testing Fennec matters for the future of the open Web:

Fennec, Mozilla’s mobile browser, just landed in Google Play (you may remember it as the Android Marketplace). Firefox Beta for Android is better than ever! You can download it now, use it on your Android phone or tablet and share your feedback. If you get hooked on testing, you’ll want to create a bugzilla account (if you don’t have one) and start filing bugs. By

If you’d like to do a little more directed testing, check out Aaron Train’s most excellent testing app, which sends you to some of the world’s leading websites to share your feedback. This is the app we’d like to gamify, to motivate more people in the Mozilla community to help us keep improving the Firefox mobile web experience for everyone.

What matters is mobile

It’s an interesting exercise to start viewing and interacting with the world’s most frequently used websites in a mobile browser. Any mobile browser. You realize the mobile Web has a ways to go. But there’s more to it than that. David Slater, who leads Product Marketing at Mozilla put it so well that I’m just going to share a note that he sent out internally earlier this week:

The mobile Web is under threat. For 8 years Mozilla has fought to make the Web open on desktop – and won. On mobile, it’s different – the battle is underway. In order to win, we will have to make the Web on mobile devices as compelling for developers and users as native mobile apps are today. Marketplace is about doing that. Boot-to-Gecko, ultimately, is about doing that. But first, we have to break open the mobile web and expose the issues.

Today, Apple and Google – and therefore browsers based on Webkit – are dominating the mobile Web, and as a result developers are coding for a single rendering engine. Like we did with desktop, we have to ensure developers have access to truly open standards. And that means that we need to do whatever it takes to establish Gecko‘s presence on mobile – and specifically, on the Android platform which is widely forecast to grow more than any other in the next 5 years.

There are many ways you can join us in this battle, but if you’ve been wanting to test your skills by building a Web game, there’s never been a better time to try, and never for a better cause. And if you need a little help, there are many places you can ask, like our IRC channel, #devrel, the engagement-developers mailing list, or simply @mozhacks on Twitter. And, of course, if you do, we’ll make you MDN-famous, and treat you like a hero. Thank you.

Heroes Wanted

Planet Mozilla — Weekly Status Report, W20/2012

Here's a short summary of Mozilla-related work I've done in week 20/2012 (May 14 - 20, 2012):
  • CSI:Mozilla / CrashKill:
    Lots of discussions around blocklisting old Java versions, we'll go for an extra soft approach as a first step due to the high usage of Flash.
    Following an error of Adobe that we found out about, there was an interesting couple of Flash reprocessing events that we needed and I pushed through.
    As we shipped our first beta of the new Firefox for Android, I helped a lot in monitoring and looking into the crashes we are seeing there.
    On the weekend, pinged people on a heavily explosive Nightly crasher introduced by JS code landed on Friday. People were responsive even on a Sunday to look into the issue, review and land a fix.
    Stayed involved in the discussion for Java signature improvements.
    Reworked my Flash and explosiveness reports to fetch their data from the Socorro database instead of the CSV files.
    Just like every week, watched new/rising crashes, caring that bugs are filed where needed.
  • German L10n:
    I synched up a few strings in core and DOMi L10n to trunk again.
  • Various Discussions/Topics:
    SeaMonkey build system work and website infrastructure problems, Android XUL Fennec display problems, stability work week planning, plans for moving merge/uplift day, HTML forms and mobile, web apps on Linux, HTML5 Mario prototype, etc.

The new Firefox for Android is in Beta now, and for phones it's a really huge step, it launches faster than most other apps, and still has all the Firefox power on websites - even including Flash. Yes, we needed to sacrifice our "webby" technologies for UI design to get there, but we'll go even farther with those on our future phone OS.

If you have an Android phone, help testing this beta (that is, if it has an ARMv7 processor, we're still working on a version for ARMv6). We know about a couple of crashes, but we need more reported, including steps to reproduce if possible, to get this one to be as stable as one would expect from a browser baring the "Firefox" brand. Everything we catch now in beta and we can fix here, will not hit the masses when we go to release.

That said, I hear it's pretty good already (I don't have an Android phone by choice, wanted something even more open), so you can feel good about trusting it with your everyday browsing tasks on your Android phone. And at the same time, you'll be doing good by testing it and - in case you crash it - by sending a report we can then look at and fix! :)

Planet Mozilla — Wrong marketing approach from Comodo and ActiveState.

I have downloaded a free version of Comodo IDE, called Comodo Edit. It’s fucking good IDE for HTML5, PHP, JS and [put your own language here].

So far so good. I gave my email address to them, because I like the product and the team. After 12 seconds I receive this “help material”.

They don’t want to provide me help how to get started, but to sell me the pro-edition:

<figure class="full-width-mobile alignnone thick" style="width: 651px;"></figure>

 


I understand that approach, but please first give me what I need – links and materials to help me to understand “Comodo EDIT” better and 1 month after that send me an offer for the better IDE.

 

Planet Mozilla — Mozilla supports the Liberated Pixel Cup for open games

We’re excited to announce that Mozilla is supporting the Liberated Pixel Cup, a fantastic competition aiming to spark the creation of artwork and code for games that are free and available for others to use.

The Liberated Pixel Cup is the brainchild of OpenGameArt, a long-standing community of artists that provide graphics and sound effects for others to use in their games. Joining us in supporting the competition are the Creative Commons, Free Software Foundation, as well as the hundreds of everyday supporters who donated to the prize fund.

Getting involved with the Liberated Pixel Cup was an obvious choice for us. Over the past year we’ve vastly improved our performance for games in Firefox, we’ve added new features for games, we’ve hosted a work week to discuss the future of games, we’ve attended and represented the open Web at important game-related events like GDC, as well as much, much more. To put it simply, we think games are pretty darn important to the future of the Web!

As part of our involvement, we’ll be:

  • Supporting the HTML5 category of the competition
  • Using our various spaces around the world to host Liberated Pixel Cup events
  • Donating funds to support the running of the competition

The art side of the competition starts in June, with the code side starting in July; so mark those dates in your diary and get ready to create some game-related goodness!

Check out the Liberated Pixel Cup website for more information.

Bruce Lawson — Reading List

Standards

  • Once again, discussion of installable/ packaged web app thingies. Major points:
    • Mozilla doesn’t want to reuse the W3C Widget spec because they want hosted, not installable apps. And the name “widget” is rubbish.
    • Hosted web apps are .. er .. web sites. But wrapped up, with a manifest, they can be monetized in a synergy of micropayment leverage.
    • “Installing” packaged apps can give them greater permissions than web sites. Hixie responded

      The “installation” security model of asking the user up-front to grant trust just doesn’t work because users don’t understand the question, and the “installation” security model of curating apps and trying to determine by empirical examination whether an application is trustworthy or not just doesn’t scale.

  • Two New Proposals to Solve the CSS3 Vendor Prefix Crisis
  • Last week I linked to an article that claimed adherence to WCAG didn’t magically solve all blind users’ problems. Here’s a rebuttal Methodological flaws put question mark on study of the impact of WCAG on user problems. It seems to me obvious that, while WCAG is very useful, it doesn’t replace brain, or testing.

Mobile and devices

Web Biz

Misc

Web Standards Song

“Like A Rounded Corner”, by Bruce and The Standardettes

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="369" src="http://www.youtube.com/embed/oGZ9tVu4Ahs?rel=0" width="500"></iframe>

Planet Mozilla — 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.


Planet Mozilla — Mozilla Hacks Weekly, May 17th 2012

It’s that time of the week – some great link suggestions from us in Mozilla’s Developer Engagement Team!

At the end of this blog post, you also have all the Developer Engagement team members and what they work on. If you are interested in discussing more, contributing or taking part of our work, don’t hesitate to contact us or follow us on Twitter!

Weekly links

If there is anything you think we should read or know about, don’t hesitate to post a comment, contact us on Twitter or through any other means.
The picks this week are:

The Developer Engagement team

Mozilla’s Developer Engagement team work with writing articles, documentation – such as MDN (Mozilla Developer Network) – public speaking and generally helping and informing about open technologies and Mozilla products. If you are interested in following our work, here are the team members:

<section class="hw-team">

Christian Heilmann

Christian is Mozilla’s Principal Evangelist and is working with HTML5, Open Web, BrowserID and Developer Tools in Firefox. He is also maintaining the @mozhacks account together with Robert Nyman.

Blog: http://christianheilmann.com/
Twitter: @codepo8

Eric “Sheppy” Shepherd

Eric is the Developer Documentation Lead for the MDN documentation and everything surrounding it.

Blog: http://www.bitstampede.com/
Twitter: @sheppy

Havi Hoffman

Havi works with Mozilla Labs and WebFWD, and maintains the @mozlabs account.

Twitter: @freshelectrons.

Janet Swisher

Janet is working on MDN documentation and is organizing doc sprints to ensure we have premium quality on MDN.

Blog: http://www.janetswisher.com/
Twitter: @jmswisher.

Jean-Yves Perrier

Jean-Yves is another one of our technical writers working on MDN documentation.

Twitter: @teoli2003.

Jeff Griffiths

Jeff is working with the Add-ons SDK (Jetpack).

Blog: http://canuckistani.ca/
Twitter: @canuckistani

Joe Stagner

Joe is working with Web Apps Developer Ecosystem & Partner Engagement, HTML5 and the Open Web.

Blog: http://www.misfitgeek.com/
Twitter: @MisfitGeek

John Karahalis

John is working on Dev Derby.

Twitter: @openjck

Rob Hawkes

Rob is working on HTML5 games and the Open Web.

Blog: http://rawkes.com/
Twitter: @robhawkes

Robert Nyman

Robert is working with HTML5, Open Web, Firefox, WebAPI and maintains the @mozhacks account.

Blog: http://robertnyman.com
Twitter: @robertnyman

Shezmeen Prasad

Shezmeen is working on everything regarding events, organization and connecting conferences with Mozilla speakers.

Stormy Peters

Stormy is the Team Lead for the Developer Engagement team. managing it and evaluating our objectives.

Blog: http://stormyscorner.com/
Twitter: @storming

Tristan Nitot

Tristan is our Mission Evangelist and is focusing on the bigger picture of Mozilla.

Blog: http://standblog.org/blog/en
Twitter: @nitot

Will Bamberg

A picture of Will Bamberg Will is working on documentation for the Add-ons SDK (Jetpack).

</section>

Planet Mozilla — Firefox/Gecko Delivery Meeting Minutes: 2012-05-16

Firefox/Planning/2012-05-16

« previous week | index | next week »

Planning Meeting Details

  • Wednesdays – 11:00am PDT, 18:00 UTC

  • Mountain View Offices: Warp Core Conference Room
  • Toronto Offices: Finch Conference Room
  • irc.mozilla.org #planning for backchannel
  • (the developer meeting takes place on Tuesdays)

Video/Teleconference Details – NEW

  • 650-903-0800 or 650-215-1282 x92 Conf# 95312 (US/INTL)

  • 1-800-707-2533 (pin 369) Conf# 95312 (US)
  • Vidyo Room: Warp Core
  • Vidyo Guest URL
REMEMBER

These notes are read by people who weren’t able to attend the meeting. Please make sure to include links and context so they can be understood.

Contents

Actions from Last Week

Schedule & Progress on Upcoming Releases

Kilimanjaro
  • Product team working on defining all the “basecamp” requirements.

  • Basecamp is a subset of the k9o work.
  • Planning to have something ready to communicate in the next few days.
  • Work on larger k9o goals proceeding.
  • Triage 2x a week but looking at moving times for better participation. Announcement will go out on the list.
Firefox Desktop
Release (12, 10esr, 3.6)
  • Merge day may move one day earlier than ship date to decouple necessary work and meet our Aurora/Beta target ship by the end of the week. See dev.planning thread. This will not affect any release dates.
Beta (13)
  • FF13 beta 4 will be released on Friday
Aurora (14)
Nightly (15)

Bug 754133 – Set background of standalone images (the image itself, not the whole page) to white

Firefox Mobile
  • Fennec Native 14 beta 1 is now live on Google Play

  • We expect our next beta of Fennec Native (released as early as 5/17) to be multi-locale with the same 13 localizations as XUL Fennec previously
  • Day 1 Adoption
    • Installs: 785,103 (+3.45% from yesterday)

    • Active installs: 209,076 (+14.32%)
    • Total Beta ADIs: 39,224 (+66.34%)
    • ADIs on 14.0: 15,345 (39% of total ADIs)
Services
Firefox Sync
  • Beta is out! \o/

  • Please remember you can have only 1 native sync per android device, so no you cannot have Aurora & Beta syncing at the same time. Read Why Here
Apps In the Cloud Server
  • Regular deployment happening.
Add-on SDK

Release (1.7 -> Firefox 12, 13)

  • Released SDK 1.7 yesterday

    • mixed bouquet of new features and important bug fixes

    • css-only page-mods, l10n pluralization goodness
    • configurable contentURL property for panel and widget!
    • many bug fixes

Stabilization (1.8 -> Firefox 13, 14)

  • on-track for release Tuesday June 26th

  • first beta release either today or tomorrow?

Development (1.9 -> Firefox 14, 15)

  • Firefox 15 / memory leak issues mitigated by latest khuey patch

    • still planning to spin up a campaign to get older extensions re-packed, because its the right thing to do

    • more plannig for this will happen at the Addons work week, June 4.
  • started landing ‘Spring Cleaning’ items yesterday, aiming to land loader in Firefox
Identity
  • Focused on Basecamp

  • Other work still proceeding, but some of it is pushed back: Persona beta moved to July. Should have no impact on other products.
Apps
  • Firefox Desktop 14 (Aurora) – landed

    • Looking to back out this functionality – bug 750936

    • Native Install
    • Chromeless launch of apps
  • Mozillian Marketplace Release is out! Thanks for the feedback so far!

    • Please be mindful that this is an internal release and of alpha quality. Early access is limited to Mozillians and partners for testing, so please do not tweet, communicate or share screenshots, features or details about the Marketplace for now.

    • Download Firefox Desktop Nightly (Fx15)
    • Have a look at the wiki to learn more about the testing procedure.
    • If you run into any hiccups, you can report them to apps-feedback@mozilla.com.
    • Once you’re done, there’s also an online survey for you to fill out.
  • Firefox Desktop 15 (Nightly)

    • Working on fixing bugs – mostly fit and polish to fit Kilimanjaro requirements
  • Firefox Mobile 15 (Nightly) – in progress

    • Work started in Fx14 continues in 15.

    • The team is shoring up the bugs to be in better shape for K9o implementation.
    • Proposed marketplace bundling with Fennec is an open issue. See bug 738545
  • Apps in the Cloud

    • AITC client continues

    • AITC Server – Completed

Feedback Summary

Desktop

Firefox 12 issues summary:

We currently have a 5% increase in issues over Firefox 11. This seems to be a combination of issues including:

Firefox 12 is slow – Thread was originally about a gfx card issue, but I think it turned into a pile on thread https://support.mozilla.org/en-US/questions/926621
[1]
[2]

Foxit Reader causing Hotmail issues: Solution is to rollback to an older version of Foxit. This combined with the Adobe Reader issue is sticky.
[3]
https://support.mozilla.org/en-US/questions/926740
[4]
[5]

PDF Issues on Mac – Reader update https://support.mozilla.org/en-US/questions/775819
[6]
[7]
[8]

Firefox 12 consumes too much memory – https://support.mozilla.org/en-US/questions/927004
[9]
[10]
[11]

Copy/Paste Image – Fixed – https://bugzilla.mozilla.org/show_bug.cgi?id=749527
[12]
[13]

Firefox 12 incorrectly caching pages – Bug filed – https://bugzilla.mozilla.org/show_bug.cgi?id=748647
[14]

Incompatible Norton Toolbar: Need to update norton 360 and norton internet security suite.
[15]
[16]

FF12 praise summary, down 6% from FF11:

fast:
[17]
[18]
[19]

ui:
[20]
[21]

stable:
[22]
[23]
[24]

Mobile
  • Top three dissatisfiers (startup speed, flash support, and memory consumption) are now fixed in Firefox for Android Beta!!

  • Google Play reviews summary, 330 reviews of Beta in first 24 hours; our rating based on those reviews is a solid 4.0 stars. 160 5-star reviews already!
    • Themes: fast, wow, flash, memory, smooth, scrolling, sexy, this is now my default browser

    • “This is now the fastest, smoothest browser in AndroidLand.”
    • “I absolutely love FF Sync, uploaded to my phone in seconds.”
    • “Great Improvement I thought firefox will never support flash. It is the only reason that I didn’t use as my default browser. At first look it’s amazing. Definitely deserve five stars. And finally thanks for dev team for your hard work.”
    • “Beautiful This update is simply amazing! I am thoroughly impressed. Firefox just beat out dolphin for my go to mobile browsing.”

UX & User Research

UX Design

Market Insights

Desktop / Platform
Adobe
  • After initially requiring users to pay hundreds of dollars to receive security fixes for vulnerabilities in Flash Professional, Illustrator, and other products, Adobe has relented and will now provide them for free
Apple
  • A fairly significant security issue was found in Safari’s handling of input in the URL bar; a fix is expected shortly
Google
Microsoft
  • Microsoft posted a detailed summary, with video of how social sharing of links and other content from IE10 will work on Windows 8.

  • Senate Judiciary Committee staffers plan to take a look at allegations that Microsoft has made it difficult for competing Web browsers to run on a certain version of Windows, an aide told a political blog
  • A leaked version of the upcoming Preview Release of IE10 shows an improved score on html5test.com
Opera
  • There are rumours that Opera will be porting its Opera Mobile browser to the upcoming Windows Phone platform

  • Opera Mini was also released for the Samsung Bada platform
WebKit
  • CSS Variables are coming to WebKit

  • The tab-size property is now supported, and work has begun on the Media Capture API
Mobile

Summary below, full update here and in your inbox.

  • Updated Android version distribution numbers are available

  • Google’s Motorola acquisition expected to be completed soon
  • Android 5.0, code-named Jelly Bean, rumoured to be released in fall with multiple flagship devices
  • Baidu to be releasing Yi-based devices
  • 56.1% of smartphone shipments in Q1 featured Android
  • Samsung confirmed as top mobile phone vendor by shipments in Q1

Marketing, Press & Public Reaction

Marketing
  • Transition: Laura Forrest will be the new PMM for Desktop, with full transition by 6/18. Desktop is in excellent hands!

    • In the meantime, Laura Mesa and Grace will continue leading through the next Desktop updates, including Aurora & Beta.

    • Working through how this may/may not effect Beta and Aurora outbound.
  • Otherwise, materials and blog posts on schedule for next update.

Press

Firefox for Android Preps for Prime Time

Mozilla updates Firefox for Android with Adobe Flash support

Firefox 14 beta for Android released

Hands on with Mozilla Firefox OS Boot to Gecko[25]

Questions, Comments, FYI

  • myk: I keep hearing people talk about this thing called “Basecamp”, and I’m pretending to be a volunteer contributor; where/when can I find out more information about it?

    • Response: Basecamp details are being defined right now and the working team will send out an update on dev.planning by the end of next week. For any immediate questions, feel free to message me. (clee@mozilla.com)

Actions this week

  • ally/jen to come back with an answer on how we feel about AitC as a blocker to the FF15 apps work

  • matt/alex to figure out why our adobe blocklist didn’t eliminate the reader bustage
Retrieved from “https://wiki.mozilla.org/Firefox/Planning/2012-05-16“

Jeremy Keith — Secret src

There’s been quite a brouhaha over the past couple of days around the subject of standardising responsive images. There are two different matters here: the process and the technical details. I’d like to address both of them.

Ill communication

First of all, there’s a number of very smart developers who feel that they’ve been sidelined by the WHATWG. Tim has put together a timeline of what happened:

  1. Developers got involved in trying to standardize a solution to a common and important problem.
  2. The WHATWG told them to move the discussion to a community group.
  3. The discussion was moved (back in February), a general consenus (not unanimous, but a majority) was reached about the picture element.
  4. Another (partial) solution was proposed directly on the WHATWG list by an Apple employee.
  5. A discussion ensued regarding the two methods, where they overlapped, and how the general opinions of each. The majority of developers favored the picture element and the majority of implementors favored the srcset attribute.
  6. While the discussion was still taking place, and only 5 days after it was originally proposed, the srcset attribute (but not the picture element) was added to the draft.

A few points in that timeline have since been clarified. That second step—“The WHATWG told them to move the discussion to a community group”—turns out to be untrue. Some random person on the WHATWG mailing list (which is open to everyone) suggested forming a Community Group at the W3C. Alas, nobody else on the WHATWG mailing list corrected that suggestion.

Then there’s apparent causality between step 4 and 6. Initially, I also assumed that this was what happened: that Ted had proposed the srcset solution without even being aware of the picture solution that the Community Group had independently come up with it. It turns out that’s not the case. Ted had another email about the picture proposal but he never ended up sending it. In fact, his email about srcset had been sitting in draft for quite a while and he only sent it out when he saw that Hixie was finally collating feedback on responsive images.

So from the outside it looked like there was preferential treatment being given to Ted’s proposal because it came from within the WHATWG. That’s not the case, but it must be said: the fact that srcset was so quickly added to the spec (albeit in a different form) doesn’t look good. It’s easy to understand why the smart folks in the Responsive Images Community Group felt miffed.

But let’s be clear: this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is best solution gets put in the spec, regardless of how popular or unpopular it is.

Now, if that sounds abhorrent to you, I completely understand. A dictatorship should cause us to recoil.

That’s where the W3C come in. Their model is completely different. Everything is done by committee there.

Steve Faulkner chimed in on Tim’s post with his take on the two groups:

It seems like the development of HTML has turned full circle, the WHATWG was formed to overthrow the hegemony of the W3C, now the W3C acts as a counter to the hegemony of the WHATWG.

I think he’s right. The W3C keeps the rapid, sometimes anarchic approach of the WHATWG in check. But the opposite is also true. Without the impetus provided by the WHATWG, I’m not sure that the W3C HTML Working Group would ever get anything done. There’s a balance that actually works quite well in practice.

Back to the situation with responsive images…

Unfortunately, it appears to people within the Responsive Images Community Group that all their effort was wasted because their proposed solution was summarily rejected. In actuality all the use-cases they gathered were immensely valuable. But it’s certainly true that the WHATWG didn’t make it clearer how and where developers could best contribute.

Community Groups are a W3C creation. They don’t have anything to do with the WHATWG, who do all their work on their own mailing list, their own wiki and their own IRC channel.

I do think that the W3C Community Groups offer a good place to go bike-shedding on problems. That’s a term that’s usually used derisively but sometimes it’s good to have a good ol’ bike-shedding without clogging up the mailing list for everyone. But it needs to be clear that there’s a big difference between a Community Group and a Working Group.

I wish the WHATWG had done a better job of communicating to newcomers how best to contribute. It would have avoided a lot of the frustrations articulated by Wilto:

Unfortunately, we were laboring under the impression that Community Groups shared a deeper inherent connection with the standards bodies than it actually does.

But in any case, as Doctor Bruce writes at least now there’s a proposed solution for responsive images in HTML: The Living Standard:

I don’t really care which syntax makes the spec, as long as it addresses the majority of use cases and it is usable by authors. I’m just glad we’re discussing the adaptive image problem at all.

So let’s take a look at the technical details.

src code

The Responsive Images Community Group came up with a proposal based off the idea of minting a new element, called say picture, that mimics the behaviour of video

<picture alt="image description">
  <source src="/path/to/image.png" media="(min-width: 600px)">
  <source src="/path/to/otherimage.png" media="(min-width: 800px)">
  <img src="/path/to/image.png" alt="image description">
</picture>

One of the reasons why a new element was chosen rather than extending the existing img element was due to a misunderstanding. The WHATWG had explained that the parsing of img couldn’t be easily altered. That means that img must remain a self-closing element—any solution that requires a closing /img tag wouldn’t work. Alas, that was taken to mean that extending the img element in any way was off the cards.

The picture proposal has a number of things going for it. Its syntax is easily understandable for authors: if you know media queries, then you know how to use picture. It also has a good fallback for older browsers : a regular img element. This fallback mechanism (and the idea of multiple source elements with media queries) is exactly how the video element is specced.

Unfortunately using media queries on the sources of videos has proven to be very tricky for implementors, so they don’t want to see that pattern repeated.

Another issue with multiple source elements is that parsers must wait until the closing /picture tag before they can even begin to evaluate which image to show. That’s not good for performance.

So the alternate solution, based on Ted’s proposal, extends the img element using a new srcset attribute that takes a comma-separated list of values:

<img alt="image description"
src="/path/to/fallbackimage.png"
srcset="/path/to/image.png 800w, /path/to/otherimage.png 600w">

Not nearly as pretty, I think you’ll agree. But it is actually nice and compact for the “retina display” use-case:

<img alt="image description" src="/path/to/image.png" srcset="/path/to/otherimage.png 2x">

Just to be clear, that does not mean that otherimage.png is twice the size of image.png (though it could be). What you’re actually declaring is “Use image.png unless the device supports double-pixel density, in which case, use otherimage.png.”

Likewise, when I declare:

srcset="/path/to/image.png 600w 400h"

…it does not mean that image.png is 600 pixels wide by 400 pixels tall. Instead, it means that an action should be taken if the viewport matches those dimensions.

It took me a while to wrap my head around that distinction: I’m used to attributes describing the element they’re attached to, not the viewport.

Now for the really tricky bit: what do those numbers—600w and 400h—mean? Currently the spec is giving conflicting information.

Each image that’s listed in the srcset comma-separated list can have up to three values associated with it: w, h, and x. The x is pretty clear: that’s the pixel density of the device. The w and h values refer to the width and height of the viewport …but it’s not clear if they mean min-width/height or max-width/height.

If I’m taking a “Mobile First” approach to development, then srcset will meet my needs if w and h refer to min-width and min-height.

In this example, I’ll just use w to keep things simple:

<img src="small.png" srcset="medium.png 600w, large.png 800w">

(Expected behaviour: use small.png unless the viewport is wider than 600 pixels, in which case use medium.png unless the viewport is wider than 800 pixels, in which case use large.png).

If, on the other hand, w and h refer to max-width and max-height, I have to take a “Desktop First” approach:

<img src="large.png" srcset="medium.png 800w, small.png 600w">

(Expected behaviour: use large.png unless the viewport is narrower than 800 pixels, in which case use medium.png unless the viewport is narrower than 600 pixels, in which case use small.png).

One of the advantages of media queries is that, because they support both min- and max- width, they can be used in either use-case: “Mobile First” or “Desktop First”.

Because the srcset syntax will support either min- or max- width (but not both), it will therefore favour one case at the expense of the either.

Both use-cases are valid. Personally, I happen to use the “Mobile First” approach, but that doesn’t mean that other developers shouldn’t be able to take a “Desktop First” approach if they want. By the same logic, I don’t much like the idea of srcset forcing me to take a “Desktop First” approach.

My only alternative, if I want to take a “Mobile First” approach, is to duplicate image paths and declare ludicrous breakpoints:

<img src="small.png" srcset="small.png 600w, medium.png 800w, large.png 99999w">

I hope that this part of the spec offers a way out:

for the purposes of this requirement, omitted width descriptors and height descriptors are considered to have the value “Infinity”

I think that means I should be able to write this:

<img src="small.png" srcset="small.png 600w, medium.png 800w, large.png">

It’s all quite confusing and srcset doesn’t have anything approaching the extensibility of media queries, but I hope we can get it to work somehow.

Tagged with

HTML5 Doctor — HTML5 adaptive images: end of round one

After The Great Vendor Prefix Hullaballoo of April 2012 comes The Great Responsive Images Brouhaha of May 2012.

Adaptive images are the next unsolved mystery of Responsive Web Design. Do you send large high-res images suitable for retina dispays, which are scaled down on smaller, lower res devices and which therefore waste bandwidth? Or do you send low-res images, whch look grotty when scaled up to large screens or high-res displays? Authors have had to rely on elaborate hacks to send different content images (that is <img> in HTML rather than CSS background images) to different types of devices.

By November 2011, I was so frustrated that no specification body was considering the problem that I proposed a strawman <picture> element that re-used the mechanism of HTML5 <video> with its media queries to swap in different source files:


<picture alt="angry pirate">
   <source src=hires.png media="min-width:800px">
   <source src=midres.png media="min-width:480px">
   <source src=lores.png>
      <!-- fallback for browsers without support -->
      <img src=midres.png alt="angry pirate">
</picture>

Around the same time, others independently came to the same idea and were advised to set up a W3C community group to discuss it which they did. However, in January, the HTML5 editor, Ian Hickson, had said

What’s the use case for doing it for images in <img> elements? Typically <img> elements are for content images, where you don’t usually want to adapt anything.

Those web authors in the W3C Resposive Images Community Group soldiered on in frustration that they were they being ignored because the problem itself wasn’t seen as a problem. Then this week, Edward O’Connor of Apple suggested another method, using a new srcset attribute on the <img> element. This complemented a similar suggestion of his from February for img-set in CSS that is already being added to WebKit:

<img src="foo-lores.jpg"
     srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
     alt="decent alt text for foo.">

The numbers “2″ and “6.5x” tell the browser the relative resolutions; foo-hires.jpg is 2x the resolution of foo-lores.jpg.

Only a few days later, a variant of Apple’s suggestion was added to the spec.

There are two major differences between <picture> and srcset. The most obvious is that srcset uses the <img> element, which is great because that’s the natural place for images, adaptive or not. (You can’t re-use the <video> + <source> pattern with <img> because it is an empty element so can’t have child elements. O’Connor’s solution uses attributes, which are fine.)

The other major difference is that it doesn’t use Media Queries. With Media Queries, the author is reponsible for thinking up every permuations of viewport size, orientation, dpi, colour depth, aspect ratio and the like, deciding how to cater for them (if at all), identifing the breakpoints and coding them up. This requires a lot of consideration by the author, and makes for verbose code; a page with 20 pictures, each with 5 Media Queries on 5 <source> elements quickly becomes a lot of code.

O’Connor wrote

Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we’re asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just “media-queriable things” like device resolution but also any scaling applied to the <img> with CSS, its width=”" and height=”" attributes, or even things like the current page zoom level.

I have a lot of sympathy with allowing the browser to make decisions about what it knows of the environment (network speed, latency, pixel density, orientation) to choose the best image for the job. The idea is that the author shouldn’t be expected to anticipate and cater for all those variables. What she can do is describe the things she knows about -the images, their size and pixel density- and the browser will make its choice.

That way, when we’re all living in space and looking a 3D holograms, the proximity to a black hole can be detected by the iDroid3000 device (black holes notoriously cause Web hologram negative timespace inversions) and the right image chosen; we don’t need to invent new media queries for event horizon proximity and retrospectively add it to our websites.

There are two problems with the srcset suggestion. The first is highly subjective, but many feel the same: as it exists in the current, first draft of the spec, the syntax is revolting:

<img src="face-600-200-at-1.jpeg" alt=""
srcset="face-600-200-at-1.jpeg 600w 200h 1x,
face-600-200-at-2.jpeg 600w 200h 2x,
face-icon.png 200w 200h">

Of course, this can be improved, and must be. This isn’t just about aesthetics. If the syntax is too weird, it will be used wrongly. As Dr Remy wrote, “Good to see authors have another microsyntax to learn. It’s not like they had any trouble with vendor-prefixes.”

The second problem is that authors don’t want to relinquish control. There are questions of art direction (see the section headed Do I care about art direction?), and many remain unconvinced that the Apple suggestion addresses that; proponents of srcset are convinced that it does address those use cases.

Debate continues, with a full and frank exchange of views. There are understandably hurt feelings, too, because some of those who laboured in the Community Group feel that their wishes and work have been ignored.

As one of those who proposed <picture>, I have a degree of attachment to it. That’s ego. (In fact, I’d be delighted if it were called the <yayBruce> element, but I’m resigned to the unfairness of life.) But I don’t really care which syntax makes the spec, as long as it addresses the majority of use cases and it is usable by authors. I’m just glad we’re discussing the adaptive image problem at all.

So, get involved. Read the discussions and say your piece. And once the dust has settled and the specification is looking stable, we Doctors will write up our diagnosis.

HTML5 adaptive images: end of round one originally appeared on HTML5 Doctor on May 16, 2012.

Planet Mozilla — MemShrink progress, week 47–48

Add-ons

The main news in the past two weeks has been about Kyle Huey’s patch that prevents most chrome-to-content leaks, which are the most common kind of add-on leak.  Testing showed it worked beautifully, but caused a knock-on leak in add-ons built with old versions (1.3 and earlier) of the Add-on SDK.  (This received a lot of attention.)  Kyle then made a slight tweak that fixed that knock-on leak.  So we’re currently still on track for Firefox 15 being “the one that fixes add-on leaks”.

For completeness, here are the add-ons that we know were temporarily affected by that knock-on leak:  Wallflower, Visual Hashing, Translate This!, Easy YouTube Video Downloader.  They (and probably quite a few others) are all working fine again now.

Here’s a quote from an email that one user sent to Kyle this week.

Firefox was leaking about 1.5GB per hour for me. It started with Firefox 3. I tracked it down to Ghostery and NoScript, but even without those addons it leaked about 500MB per hour of browsing.

GC and CC times got up into the 10 second range. Ugly. Really really ugly! And this is on top of the line massively overclocked hardware, too. I had to install a new addon to add a restart button to Firefox, because Firefox froze solid after hitting 2GB of memory usage. I also patched it after every update to allow up to 4GB, buying a little more time…

Then your patch comes along and solves it all… you are awesome man – totally awesome!

Another user — one who uses the leaky Autopager add-on — commented on Kyle’s blog.

Certainly, before this fix I would find that Firefox often became sluggish (input lag, slow paint operations, less than silky smooth scroll animations) as the memory usage built up. It’s hard to say how much various factors contributed to the whole, but GC pauses did undoubtedly cause the scroll animation stuttering.

Restarting was the cure. I haven’t noticed the same symptoms since, and while I haven’t had enough chance to make a conclusive judgement, the signs certainly seem to be good.

I have a full tab strip more often than not, and Fx set to load tabs from last time. This is offset by the wonderful and elegantly simple tabs on demand feature. I’m running a 2 year old laptop with 4GB ram.

And while we’re on the topic, here’s a comment from my blog.

Opened my firefox today, 30+ Tabs (only counting the ones in the active group, the others aren’t loaded), using just little more than 330 MB of RAM. A year ago, with Firefox 4, this would have been impossible. Keep it going!

Good times.

The following add-ons had zombie compartments fixed:  Youtube Ratings Preview, SPDY Indicator  It’s likely these leaks would have been fixed by Kyle’s change, but since Firefox 15 won’t be released until August 28, it’s good that they’ve been fixed now.  (Indeed, the AMO review policy still requires that add-ons not cause zombie compartments with the current release of Firefox;  that policy may be revisited once Firefox 15 is released.)

Compartment-per-global

The other big news is that compartment-per-global (CPG) landed, thanks to the work of various people, especially Luke Wagner and Bobby Holley.  Bobby explained what this means and explored some of the consequences.

CPG will allow lots of things within Firefox to become simpler and faster.  The main disadvantage is, unfortunately, increased memory consumption, as can be seen on areweslimyet.com.  (Thanks to Luke, this increase was less than it could have been.)  This is mostly due to more fragmentation in the JavaScript heap — we now have many more compartments, and each 4KB heap arena cannot be shared between compartments, so there are many more partially empty arenas present.

You might think this would make me bang my head against the wall in frustration, but it doesn’t.  That’s because even if I ignore the many non-MemShrink-related benefits of CPG, there are two big MemShrink-related ones.

First, CPG will enable per-tab memory reporting, something that users have been requesting for years.

Second, CPG will lead to much more detail in about:memory and about:compartments.  For example, Nils Maier has written a patch that makes it obvious all the JavaScript modules that have been loaded.  Another example:  Justin Dolske found that plusone.google.com was doing something silly (constantly creating new iframes?) that caused huge numbers of compartments to be created;  without CPG I think all those globals would have been lumped into a single compartment and the problem would have been much less obvious.  More information in about:memory will lead to more diagnosis of existing problems — particularly leaks of various kinds — in both Firefox and websites.

Memory Reporting

Kevin Locke tweaked the JS memory reporters so that more compartments are distinguished, instead of being lumped together.  This was his first Mozilla patch — well done, Kevin!

Nathan Froyd improved the coverage of the layout memory reporters.  This significantly reduces “heap-unclassified” for huge pages like the single-page version of the HTML5 spec.

Bug counts

Here are the current bug counts.

  • P1: 22 (-2/+3)
  • P2: 83 (-6/+4)
  • P3: 105 (-5/+6)
  • Unprioritized: 3 (-1/+3)

Mostly bouncing around at the moment.

Planet Mozilla — SeaMonkey Meeting Minutes: 2012-05-15

SeaMonkey/StatusMeetings/2012-05-15

« last meeting | index | next meeting »

SeaMonkey Meeting Details

Contents

Agenda

  • Who’s taking minutes? -> Ratty

  • Nominees for Friends of the Fish Tank:
    • None
Action Items

(who needs to do what that hasn’t been recorded in a bug) We should assign people to the open items.

NEW

  • IanN to arrange with Jeff to send a tee-shirt or something to Serge (FotFT).

    • No response from The Scarlet PimpernelSerge to email, will try email again.

OPEN

CLOSED

Status of the SeaMonkey Buildbot Master and Tree
  • ewong and Callek are looking into building on MSVC2010 by Friday.

  • tonymec is worried about status of trunk l10n: 7 languages not built since Apr 27, the other 14 currently only on Linux. This is probably related to the server moves going on.
Release Train
  • 2.9b4 shipped April 19

  • 2.9 shipped April 24
  • 2.9.1 shipped April 30
  • 2.10b1 shipped May 12
Extensions Compatibility Tracking
  • See Basics page. Please only list current changes here.

  • Addon Compatibility Listings
    • Nothing special this time.
  • DOM Inspector Release Schedule (crussell)
    • bug 746784 Predictable release schedule for development and localization.

    • The last six weeks of a release cycle are for localizers no string changes will occur then. Localization happens on a branch (DOMI_2_0_12 right now) and concurrent development happens on default. Right now, DOM Inspector is set to ship with: de, el, en-GB, en-US, fr, ru, sk, sv-SE.
    • Serge has filed some bugs so that the relevant changes to pull the right branch are in place. See bug 732749 (client.py: review SeaMonkey policy about which extension revisions are packaged).
    • So in theory we could work out the correct tag from the Gecko version of the repos we’re building in? It’s not tagged it’s just a branch. To get on the right branch: 
 hg clone http://hg.mozilla.org/dom-inspector
 cd ./dom-inspector
 hg update DOMI_2_0_12
    • It is to be hoped that our build team (Serge, Callek, ewong) can sort it out so it is fairly automated rather than having to tweak the client.py every 6 weeks.
2.x (Last, Current, Next)
  • 2.9 had ~73,300 ADU by last Tuesday and 2.9.1 had ~53,600 downloads so far (2.8 reached ~203,100 downloads).

    • Of the released versions, as of last Tuesday, we have 13.7% on 2.0, 5.1% on 2.1-2.3, 9.5% on 2.4-2.6, 4.4% on 2.7, 15.8% on 2.8 and 51.5% on 2.9. So, in the last four weeks, ~5k (an additional 4% of ADU) have migrated to 2.7 or above.
  • Still a large, but slowly decreasing, chunk of users on 2.0.x.
  • Figure out what is preventing people from moving from 2.0.x to the latest versions.
    • Some people cannot upgrade due to system requirements (OS version, processor capabilities etc.)

    • Perhaps putting resources into getting certain extensions working with SM 2.4 and above (those that won’t work with SM 2.7 automatically due to compatible-by-default extensions).
    • Still need volunteers to look at what is keeping people at below 2.4. IanN could try knocking something up and send it round members lists for polishing but he’s not on all the channels (mozillazine, etc) to post it to when finished.
    • Are some Linux distributions are still stuck on 2.0? We have data on OSes and OS versions in the raw data in the Mozilla metrics.
    • metrics.mozilla.org now provides us a breakdown of versions against OS.
    • There seems to be a very small number of 2.0.x users on OSes not supported by later versions. We even have some users on windows 7 using 2.0x! Fortunately Windows 8 users are at least using 2.7.
    • Darwin 9.8 is last version with PPC support, so those people may stuck on old versions because of that.
      • For OSX/PPC I wonder if someone from the community could try building a contributed “TenFourMonkey” based on the patch sets from TenFourFox plus TenFourBird [Ratty].

      • SeaMonkey 2.6.1 for a PowerPC/G4 on Mac OS 10.5.x. IanN says we should advertise that more (and other contributed builds).
    • Ian has done some working on comparing profile of 2.0.x users against 2.9 ones.
      • Split between OS for 2.9 is Windows 92.82%, Linux 2.53%, MacOS 4.65% and for 2.0.x is Windows 85.37%, Linux 5.55%, MacOS 9.08%.

      • For those using 2.0.x on MacOS about 39% are on OSX 10.4 or above, whereas for 2.9 it is about 82%.
      • For those using 2.0.x on Linux about 98% are on Kernel 2.6, whereas for 2.9 it is about 69% (31% on 3.0 or above).
      • For those using 2.0.x on Windows about 37% are on Vista/7/2008, a further 62% are on XP/2003, whereas for 2.9 it is about 50% on Vista/7/2008 and 49% on XP/2003.
  • See Basics page for the usual reminders.
2.9

open tracking (0)
tracking requests (1)
targeted (3)
fixed (5)

  • One tracked 2.5 issue still open.

    • 2.1 through 2.7 have NOT included the ka (Kartvelian aka Georgian) locale. The last release with ka locale shipped was 2.0.14 and the ka l10n maintainers have not yet updated for changes in later SeaMonkey versions.

    • Callek now needs to morph bug 667147 into removing |ka| from our [current] automation entirely (all-locales). Callek will look at best locale to transition any ka users to.
      • Plan is to migrate ka users to en-US with a english dialog saying they are out of date, and a link to the all-locales page if there is a language they understand better. Current ADU of ka alone is 3-5 individuals, so low impact.~Callek

      • Callek and ewong were working on this but they didn’t manage to get this done by the time 2.9 shipped. No new ETA unfortunately.
  • One regression issue noted for 2.8: bug 735946 Browser is not not focused when opening links from external applications. Fixed on 2.9+.
2.Next
  • TBD
Feature List, Planning

Bug statistics for last two (full) weeks: 38 new, 26 fixed, 42 triaged.

  • Good triaging effort.

Open reviews/flags:
20 review
9 super-review
1 ui-review
6 feedback

Roundtable – Personal Status Updates

Status Updates from developers – what are you working on, what’s the progress, any other comments? (feel free to add yourself to the list if your name is missing and you have interesting status).

Aqualon
Callek

[RelEng] Released SeaMonkey 2.9.1:

  • bug 750014 Throttle 2.9 Updates to Manual Only until 2.9.1 goes live.

  • bug 750021 (SM2.9.1) Tracking bug for build and release of SeaMonkey 2.9.1.

ToDo:

  • bug 640464 Develop a way for tests in mozilla-central to be overridden in a suite build.

  • bug 741082 [sea-win32-02] “create aus previous upload dir failed”.
  • bug 746208 Investigate continuing TBPL service for SeaMonkey.
  • bug 748244 ADU breakdown by language.
  • Migrate the SeaMonkey Projects blog from Mozillazine to Mozilla Hosted.
ewong
  • Fixed:

    • bug 667327 – Data Manager Allows Passwords to Be Copied Without Input of Master Password
  • Checkin-needed:

    • bug 408834 – Page Info violates XUL box model.
  • Clueless as to what stage this bug is in:

    • bug 745847 – “No branch_id for a branch_name ‘SeaMonkey-Release’ can be found.
  • Working On:

IanN
  • Usual testing, reviewing and commenting.

  • Fixed:
    • bug 720661 Display account central when no default account / no accounts setup

    • bug 747765 Cannot add/remove Print icon in Composer toolbar
    • bug 103684 RFE: Implement direct ordering of filters (insert new filter at the current position / above the selected filter) – SM part
    • bug 749962 Fix spelling of color in chatzilla.dtd
    • bug 754065 Port |bug 744444 – delete CPP_PROG_LINK, purify/quantify targets| and |bug 606145 part 1 – Properly link host programs written in C++|
    • bug 749985 Add en-GB localisation for ChatZilla
    • bug 749989 Add en-GB localisation for Venkman
  • Checked in with rs but waiting for review:
  • Waiting for review on:
    • bug 638643 Remove obsolete EditorToggleParagraphMarks from editor.js

    • bug 749986 Add en-GB localisation for ChatZilla
    • bug 749990 Add en-GB localisation for Venkman
  • Waiting for additional review on:
  • Reviewed and waiting for feedback from mobile peer:
    • bug 689253 Update en-GB for Mobile 10.0 (comm-aurora)
  • Working on:
    • Various SM Council documents.

    • bug 606683 Allow customization of toolbar in Composer and MailNews Composition
    • bug 639690 [META] Re-arrange code between editor and editorOverlay
    • bug 657234 Move pasteQuote and pasteNoFormatting into contentAreaContextOverlay
    • File/Folder selection in windows.
  • To Do:
    • bug 639395 Get cmd_fontSize to reflect current state of selected content / content at caret.

    • Prefs-in-a-tab.
    • Create FAQ for Friends of the Fish Tank.
    • Knock something up finding out why users are not upgrading to 2.4+ and send it around members lists for polishing.
    • Help get composer standalone builds working with –enable-tests.
InvisibleSmiley
  • Fixed:

    • bug 753475 “JavaScript strict warning: chrome://messenger/content/messengerdnd.js, line 66: function CanDropOnFolderTree does not always return a value”

    • bug 753050 Port |bug 746859 – Add a play icon to the click-to-play placeholder| to Modern
    • bug 751253 Reference to non-existing dictionaryGeneric.png in mozapps/extensions/newaddon.css
    • bug 750855 Port |bug 728168 – Replace old synchronous favicons calls in feeds|
    • bug 750226 Add zh-TW to “official builds” and “language packs” list in SeaMonkey Download & Releases page
    • bug 750028 Update SeaMonkey website for 2.9.1
    • bug 747788 Update SeaMonkey website for 2.9
    • bug 747519 Port new doorhanger options from |bug 711618 – implement basic click to play permission model|
    • bug 747155 Update SeaMonkey website for 2.9 Beta 4
    • bug 738247 Create/Update 2.9 Release Notes
    • bug 567518 Consider supporting or switching to SSL Google search (https)
KaiRo
mcsmurf

Check-in needed:

  • bug 721474 Port |bug 575830 Image zoom (Page zoom) is reset when I switch tabs| to SeaMonkey.

  • bug 732027 Port |bug 575955 Replace internal usage of old transactions shim, add a new toolkit test| to SeaMonkey.
Misak
Mnyromyr
MReimer
Neil

Fixed:

  • bug 658280 Switch Profile does not Prompt to Save existing Session Restore.

  • bug 745447 XUL progress meter layout should match HTML.
  • bug 749893 favicon of previous page is displayed on tab when you hit back button.
  • bug 752505 Copy Image broken on Nightly.

In Progress:

  • bug 707305 Re-enable building with –enable-incomplete-external-linkage.

  • bug 738228 Option to display used font faces [DOMi].
  • bug 746166 Remove use of cmd_backgroundColor from comm-central.
Ratty

Fixed:

  • bug 701432 Add support for fave icons on jump list uri entries.

  • bug 747774 The Windows 7 Jumplist is using the mailbiff icon, should use html-file.ico instead.
  • bug 748991 The Find in Page Dialog does not vertically center the highlighted result like the findbar does.
  • bug 752336 Location Bar doesn’t revert back to the correct url when you enter text then shift-middle click GO to open in a new tab.
  • bug 753272 bustage fix: make package fails due to bug 749018.
  • Lightning Integration /Support:
    • bug 731264 Support with multiple toolboxes in MailNews due to Lighting Calendar and Task Tabs.

    • bug 751217 In SeaMonkey, the Delete button in the Lightning Task Actions Toolbar doesn’t have an icon because it uses mail-toolbar.png.
    • bug 753683 Simplify SeaMonkey handling of Lightnings customizable toolbars, Lightning part.
  • bug 694786 Remove hardcoded icon paths from notification.xml. Fixes the following as well:
    • bug 511874 Notification bar should use 16×16 versions of icons.

    • bug 751081 Fix typo from bug 595810 (chrome://global/skin/icons/question64.png should be chrome://global/skin/icons/question-64.png instead).

Needs branch approval:

  • bug 751081 Fix typo from bug 595810 (chrome://global/skin/icons/question64.png should be chrome://global/skin/icons/question-64.png instead) [Branches only patch from bug 694786]

In progress:

  • bug 663343 The “List all Tabs” menu should visually identify which tabs are on-screen (rather than scrolled off) [Needs UI consensus].

  • bug 751922 Asynchronously add favicons to back/forward and history menus.

To Do:

  • Port Thunderbird bug 360800 MDN confirmation dialog does not say which addresses the receipt will be sent to (can be multiple).

Investigating:

  • Spelling Preferences: Parse spellchecker dictionary names as BCP 47 language tags.

Other:

  • Did some reviews and coding mentoring.

  • Bug triage and Bug discussions.
  • End user support and PR in newsgroups and Mozillazine.
Ricardo
sgautherie
  • Fixed (or in-progress) SeaMonkey (related) bugs:

    • bug 504730 [SeaMonkey] mochitest-browser-chrome, test_idcheck.xul: venkman.xul leaks 375 kB

    • bug 635825 [SeaMonkey] mochitest-5: reenable test_notifications.html and test_prompt.html
    • bug 647875 [SeaMonkey] mochitest-chrome: investigate test_crash_submit.xul failure, then reenable this test
    • bug 730663 Port |Bug 708690 – Signed MAR files do not protect against applying an update for the wrong product| to SeaMonkey
    • bug 739041 Port |Bug 482911 – [HTML5] Re-implement bookmarks.html parsing using the HTML5 parser| to SeaMonkey. (test_384370.js + 3 other failures)
    • bug 743692 Port |Bug 493557 – “Recent Tags” and “Recently Bookmarked” are flipped when smart bookmarks are updated| to SeaMonkey
    • bug 748610 [SeaMonkey, 2.10+] “Error: package error or possible missing or unnecessary file: bin/distribution/extensions/debugQA@mozilla.org.xpi”
    • bug 749106 Port |Bug 746837 – Fix sessionstore to handle an exception thrown when attempting to focus a window that has been navigated| to SeaMonkey
    • bug 749114 Port |Bug 737821 – [Firefox] Files which are already bundled with xulrunner are listed in package-manifest| to SeaMonkey
    • bug 750656 Port |Bug 664918 – Infrastructure for media stream graph processing| to SeaMonkey
    • bug 752211 Port bug 745254 to SeaMonkey
    • bug 752216 Port |Bug 641892 – Support showing multiple popup notification icons at the same time| to SeaMonkey
    • bug 752456 Port |Bug 751334 – Redundant TabView.init call in restoreWindow leaks the browser window when the window closes before delayedStartup was called| to SeaMonkey
    • bug 753613 Stop using –disable-optimize for –enable-debug builds, in SeaMonkey
    • bug 747668 Port |Bug 495277 – autocomplete.xml should not use new Function()| to SeaMonkey
    • bug 752548 Use capturing phase for notification.xml handlers
  • Fixed (or in-progress) MailNews Core bugs:
    • bug 745998 Port |Bug 739132 – –disable-necko-wifi causes “Error: package error or possible missing or unnecessary file: bin/components/necko_wifi.xpt”| to SeaMonkey

    • bug 746745 [SeaMonkey] Space for moving to next unread doesn’t work (JavaScript error: chrome://messenger/content/mailWindowOverlay.js, line 2311)
    • bug 718190 Intermittent orange on Windows | TEST-UNEXPECTED-FAIL | test_over2GBMailboxes.js (NS_ERROR_FILE_NO_DEVICE_SPACE)
  • Fixed Core bugs:
    • bug 741070 [SeaMonkey] browser_394759_basic.js (and browser_394759_behavior.js) fails

    • bug 744663 test_websocket_basic.html: additional improvements after bug 621347
  • Fixed other projects bugs:
    • [cZ] bug 748631 Bump ChatZilla compatibility for Firefox 15.0a1 / SeaMonkey 2.12a1

    • [DOMi] bug 748634 Bump DOM Inspector compatibility for Firefox 15.0a1 / SeaMonkey 2.12a1 / Thunderbird 15.0a1 / (Gecko) Toolkit 15.0a1
    • [Venkman] bug 738564 Venkman compatibility: Use ‘.*’ instead of ‘a1′ syntax, to support *-aurora/beta/release (but not *-central)
    • [Venkman] bug 748625 Bump Venkman compatibility for Firefox 15.0a1 / SeaMonkey 2.12a1 / Thunderbird 15.0a1 / (Gecko) Toolkit 15.0a1
Stanimir
stefanh
tonymec
No change.
Any other business?
  • Geolocation

    • Geolocation now works out of the box. MoCo turned it on by default for all applications that build off mozilla-central.

    • For comm-beta all we need to do is (bug 494421) to add pref("geo.wifi.uri", "https://www.google.com/loc/json"); to browser-prefs.js. However we’re not even sure we are legally allowed to ship with the URL in, we might need to actually put in a pref to disable that in newer builds.
    • No news to date. Callek will have to reach out to his MoCo legal contact again soonish.
  • Test failures
    • qawanted, especially on Linux and MacOSX specific issues: reproducing and reporting would already help.

    • Serge says that on Linux and MacOSX, he just needs someone to actually run the tests and report what they see (screen, console, etc). For example, there is a Mac test about Ctrl+W not working. This should be so trivial.
    • tonymec suggests that any enthusiastic user, even non-technical, should be able to do some testing (litmus?) and not be scared by technical language and such.
    • IanN suggests reaching out to the user community using the newsgroups and forums.
    • Serge to do a write up and send it to Ratty to propagate to the community.
      • Ratty is still waiting for Serge.
Retrieved from “https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2012-05-15“

Planet Mozilla — 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!

W3C Team blog — Help create a world of mobile *Web* apps

The new mobile Web training course launched last February was so well received (full course!) that we are announcing a new session before this summer. The "Mobile Web 2: Applications" online course will be 6 weeks long, from 11 June to 22 July 2012, and registration is now open.

Based on students' feedback, our trainer Marcos Caceres will teach an updated program which covers all the important aspects of mobile Web application development: basics of creating a Web application that runs on mobile devices, HTML5 elements and new CSS properties, powerful Javascript APIs and libraries, and finally how to make Web apps available off-line.

This course is also looking at device APIs (geolocation, device orientation, touch events) as well as looking at what new standards are coming from the W3C.

We encourage you to follow this course to learn how to develop open mobile Web apps with HTML5, accessible from any browser on any system. As Tim Berners-Lee urged conference participants in his last month WWW2012's keynote: “The solution is in your hands: develop Web apps, not apps!”

In summary:

Mobile Web Apps course banner

Take a look at the course sections on “Who Should Attend?” and “What do I need?” to find out about the target audience and pre-requesites for this course. Looking forward to welcoming you soon online!

Planet Mozilla — Mozilla Project Meeting Minutes: 2012-05-14

WeeklyUpdates/2012-05-14

« previous week | index | next week »

  • Dial-in: conference# 8600

    • US/International: +1 650 903 0800 x92 Conf# 8600

    • US toll free: +1 800 707 2533 (pin 369) Conf# 8600
    • Canada: +1 416 848 3114 x92 Conf# 8600

Contents

All-hands Status Meeting Agenda

Items in this section will be shared during the live all-hand status meeting.

Friends of the Tree

  • Everyone who worked to get a live WebM stream up during this weekend’s WebFWD Hack Day – https://twitter.com/airmozilla/status/201446072730656768

  • All of IT/Operations for their hard work & effort over the last three months moving data centers. They worked odd hours, often over evenings and weekends to minimize disruption. Out of the hundreds of websites and services moved, few needed downtime!

Upcoming Events

This Week
  • This week, mobile and Apps QA needs help in mobile web compatibility testing – find problems in top sites that do UA sniffing or use webkit prefixes in firefox mobile!

    • See here for how to get started
Monday, 14 May
Tuesday, 15 May
Wednesday, 16 May
Thursday, 17 May
  • Grow Mozilla meeting at 10 AM pacific

Brownbag Title Presenter Time
How is UX different than UI? Brandon Schauer 12:00pm PST
Friday, 18 May
Next Week

Product Status Updates (voice updates)

Firefox Desktop

Speaker Location: toronto (johnath)

Firefox Mobile

Speaker Location: toronto (johnath)

  • Going to beta this week!

  • Why are you even looking for another bullet point, here?
  • Going. To. Beta. This. Week!
Thunderbird

Speaker Location:

Older Branch Work

Speaker Location:

Summer Code Party

Speaker Location: Matt T in Toronto

Identity

Speaker Location:

Services

Speaker Location:

Speakers

The limit is 3 minutes per speaker. It’s like a lightning talk, but don’t feel that you have to have slides in order to make a presentation.

Title Presenter Topic Media More Details
WebFWD Team Presentations Cheerleader: Diane Bisgeier We have the WebFWD teams in town – and today they will do a 30 sec elevator pitch presenting their projects http://cl.ly/GbD6/WebFWD%20Teams.pdf https://webfwd.org/portfolio/
Marketplace Mozillian Preview Justin Scott Reminder that we need your help testing our app Marketplace https://marketplace.mozilla.org https://wiki.mozilla.org/Marketplace/Mozillian_Preview
Reset Firefox is awesome magic! Michael Verdi Demo new Reset Firefox feature in Firefox 13 http://youtu.be/SSr2u1wMoFg http://support.mozilla.org/kb/reset-firefox-easily-fix-most-problems
Your Title Here Your Name Here What are you going to talk about? Links to slides or images you want displayed on screen Link to where audience can find out more information

Introducing New Hires

New Hire Introduced by Speaker location Will be working on
Who is the new hire? Who will be introducing that person? From which office will that introduction be transmitted? What will the new person be working on?
Simon Bennetts Yvan Boily Mountain View Security Automation
Rehan Dalal James Socol Toronto SUMO Engineering
Vladimir Vukicevic JP Rosevear Toronto Engineering Director
Andrew Overholt Johnny Stenback Mountain View Engineering Manager
Marshall Culpepper Faramarz Rashed Mountain View Software Engineer

Introducing New Interns

New Intern Introduced by Speaker location Will be working on
Who is the new intern? Who will be introducing that person? From which office will that introduction be transmitted? What will the new person be working on?
Benjamin Peterson Dave Mandelin Mountain View Platform Team
Thaddée Tyl Matthew Noorenberghe Mountain View Firefox DevTools Script Team
Lindsey Kuper-you may recognize Lindsey from such films as “I Missed The Nerd Cave” and “Back From the Future-The Prequel” Dave Herman Mountain View Research Team
Eric Holk- you may recognize Eric from such indie pop hits as “I know Where You Were Last Summer” and “You’d Actually Do That Again?” Dave Herman Mountain View Research Team
Devdatta Akhawe Sid Stamm Mountain View Research/Privacy
David Zbarsky Faramarz Rashed Mountain View Platform Team
Xiao Meng Wei (Eric) Kevin Brosnan Mountain View QA Team
Zack Carter Dan Mills Mountain View Browser ID
Andrew Hurle Matthew Noorenberghe Mountain View Firefox Team

Roundtable

<meta>

Notes and non-voice status updates that aren’t part of the live meeting go here.

Status Updates By Team (*non-voice* updates)

Firefox
Platform
Services
Messaging
Mobile
IT
Release Engineering
QA
Test Execution
WebQA
  • Affiliates

    • No updates
  • AMO/Marketplace
    • [1] shipped last Thursday
  • Firefox Flicks
  • Mozilla.com
    • shipped 2.4 bugs
  • Mozillians
    • Shipped a very minor release on 2012-05-09
  • MDN
    • no release last week due to server migration
  • Socorro
    • No release last week.
  • SUMO
    • Continuous Deployment; no updates
  • MozTrap
    • Working on WebDriver migration
  • Webmaker
  • Wiki
QA Community
Automation Services
Automation & Tools
Security
  • please note we are changing from whiteboard tags to keywords for security markings

Engagement
PR
Events
Creative Team
Community Marketing
Support
Metrics
Evangelism
Labs
Apps
Developer Tools
Add-ons
Webdev
L10n
People Team
WebFWD

Foundation Updates

Retrieved from “https://wiki.mozilla.org/WeeklyUpdates/2012-05-14“

Footnotes

Updated: .  Michael(tm) Smith <mike@w3.org>