Hi, my name is Andrey Popelo, I'm form Ukraine.
This summer I will work on "Markup previews" project for Dojo. It is for people
who use lightweight markup languages (like Markdown, Textile, etc) in their
sites.

The aim is to create a client-side parser which will have an easy way to add
different markup languages and an easy way to load them and use with dojo.editor
and usual textarea nodes.

So it will be handy to quickly preview what you wrote without sending any
requests to the server.

For example you can take a look at Showdown - a javascript port of Markdown.
It is similar to what I intend to do.

Also a reverse parser for each markup language will be created and integrated
with dijit.Editor, so it would be able to produce data in selected markup
language instead of HTML. This will allow to simplify the server side of the
projects that will use this feature.

My mentors are David Snopek and Robert Coup.

It is my first experience in open-source development and is very interesting for
me. Doing Google Summer of Code project for Dojo is a great way to start doing
open-source!

The 1.2 release of the Dojo Toolkit is focused on the overall Look and Feel. Patches have been landing thick and fast to tighten up the visual polish. Most you might be hard-pressed to notice at first glance, but the devil is always in the details, and for a toolkit with the promise and scope of Dojo we have to sweat the small stuff.

Take Dijit’s toolbar buttons. In the editor, you have a row of graphical buttons for bold, italic, etc. For some time the rendering in Firefox has been inconsistent with the other browsers - there’s some extra space around the buttons. The result is that the toolbar is a little wider, and it’s just not tight.

Here’s how it should look (screenshot from Safari 3)

Here’s how it look(ed) in FF2

Button rendering is definitely subject to some of the most pronounced cross-browser differences. In this case the accessibility requirements of the toolbar buttons and the need for reuse across the toolkit end up forcing us to use a <button> element wrapped around a span that has the actual icon image as background.

Firebug shows us that while the inner span is 18px square, the button that wraps it has a computed width of 24px?!? Yet, here in the theme stylesheet (dijit/themes/tundra/Toolbar.css), great pains have been taken to zero any padding and shrink-wrap it as tightly as possible:

.tundra .dijitToolbar .dijitButtonNode {
	background: none;
	margin: 0px !important;
	padding: 0px !important;	
	border: none;
	font-size: 12px;
}

Despite using the largest hammer CSS gives us in the !important flag, Firebug shows there’s still something imparting padding to our button. Here’s a rare wobble in the illusion of deep and transparent insight that Firebug gives us, because there’s actually another element at play here. A trip through resource://gre/res/forms.css reveals the culprit:

button::-moz-focus-inner,
input[type="reset"]::-moz-focus-inner,
input[type="button"]::-moz-focus-inner,
input[type="submit"]::-moz-focus-inner,
input[type="file"] > input[type="button"]::-moz-focus-inner {
  padding: 0px 2px 0px 2px;
  border: 1px dotted transparent;
}

The button::-moz-focus-inner pseudo-element has a 1px border and 2px side padding. There’s our missing 6px.

forms.css is the internal stylesheet Firefox uses to render form controls - including the button elements used by our toolbar buttons. (The resource:// url is just one way of viewing these internal resources - search your local filesystem or even download the entire Firefox source for more.)

You know the outline you get on a button when you put focus on it? The gecko-based browsers have actually introduced a special element in order to render that. Now that we know its name, our solution is only a CSS rule away:

.dj_gecko .dijitToolbar .dijitButtonNode::-moz-focus-inner {
	padding:0;
}

You might be tempted to also whack the 1px border we saw in there. Don’t. Doing so prevents the button from accepting focus, and a button that cant be focused isn’t really a button anymore - use a div. Our fix is targeted only at gecko-based browsers with the .dj_gecko prefix on the selector. See Dijit’s CSS Sniff for more details.

Here’s how it looks now:

It’s subtle, but tightening up that spacing could easily make the difference that prevents a toolbar from wrapping in Firefox in your application, making a more professional and consistent user-interface across all your supported browsers.

Remember, the Dojo Toolkit is produced as an fully open-source project. This issue is tracked as ticket #6264, use username/password guest/guest to login and add comments in the Dojo bug database. If you have general feedback on widget look & feel please add your thoughts to the theme discussion. If this article describes the kind of thing you do well, we’d love for you to get involved.

Here's my presentation I gave May 12, 2008, at the Twin Cities MySQL and PHP User Group about my experience at the 2008 MySQL Conference and Expo.

Thanks to all of those that came. I had a great time!

Join members of the Internet Explorer team for an Expert Zone chat this Thursday, May 15th  at 10.00 PDT/17.00 UTC. These chats are a great opportunity to have your questions answered by members of the IE product team.

If you can’t join us online, all chat transcripts are published here. Allow approximately 7-10 days following a chat for the transcript to go live.

Hope you can join us on Thursday!

Kristen Kibble
Program Manager

I’ve previously written about the data stores I committed to the Dojo Ajax Toolkit that enable you to search Google’s services for all sorts of things - books, news, blogs, images and everything else.

Now I’ve put some demos up on DojoCampus that show off a few of the stores.  Check them out at http://dojocampus.org/explorer/#Dojo_Data_GoogleSearchStore , especially the Google Images one - it’s shiny

The time when I was applying to GoSC for DOJO, of course it is important to do research around the project topics. At that time, my computer was very very old (it is 4 years old), whatever I do multitasking, it always sounds like giving up because of too many things to do... LoL poor little box... Unfortunately, I couldnt see couple demo for Canvas3D in Firefox (simple,simple 2.0, kmzview, model view) and Opera (example, snake) since my VGA was so old (all canvas3d needs at least OpenGL1.5) but thanks to this project, I made decision to buy a "killer" box to assist this project! Hehe, I was really excited like a child gets new toys! After spent 5 hours building new computer, I am really amazed with my new computer speed! It is very very fast! Loading photoshop just couple secs, not like before couple minutes... Crazy!!! Now my performance is increased as well! Hahaha! No lag time anymore...

In this issue…

• about:mozilla reader survey
• Mozilla Party JP 9.0
• Firefox 3: Offline app demo
• Tristan, Firefox 3 and the BBC’s dot.life blog
• The slow death of the press release
• Firefox 3 Add-ons compatibility update
• All about SUMO: Mozilla’s second community survey
• Firefox 3: Site Identification button
• Processing.js
• Developer calendar
• Subscribe to the email newsletter

about:mozilla reader suvey

Mozilla has been publishing the about:mozilla newsletter since November of last year. Having been at this for almost six months, we figure it’s time to gather some reader feedback which is why we’re running an “about:mozilla Newsletter” community survey.

If you are a regular reader of this newsletter, we would really appreciate it if you could take the time to respond to the survey which you can find over at the Mozilla Europe site. At the end of the survey, there’s a place for you to enter whatever additional comments, ideas, thoughts, or criticisms you may have. The more feedback you can give us about the newsletter, the better the newsletter will be in the future.

Please take the time to help us out by responding to the about:mozilla newsletter survey. Thanks!

Mozilla Party JP 9.0

The Japanese Mozilla community, the Mozillagumi, will have their 9th annual party event on Saturday, May 31st in Tokyo, Japan. Speakers include Taro Matsuzawa of the Mozillagumi, John Daggett (platform developer) and David Tenser (SUMO manager) of Mozilla Corporation, Channy Yun of the Mozilla Korea community, Nakamoto-san of Open Office Japan Project, and Dr. Hiromitsu Takagi of the (Japan) National Institute of Advanced Industrial Science and Technology, among others. The event will be free and open to the public. Information in Japanese is available at the Mozillagumi site.

Firefox 3: Offline app demo

Mark Finkle has put together a simple demo that demonstrates the new offline capabilities of Firefox 3. “Offline mode” or “offline caching” is a new feature in HTML 5 that allows web applications to work even when Firefox 3 is on a machine that isn’t currently connected to the Internet. Finkle’s demo is called “Task Helper” and you can read more about it on his weblog. For more information about using offline resources in Firefox 3, see the article on the topic over at the Mozilla Developer Center.

Tristan, Firefox 3 and the BBC’s dot.life blog

Tristan Nitot was recently in London giving a keynote speech at Internet World called “The dangers of the proprietary web - Future of the Internet and Open Source”. While in the UK, Tristan also met with Rory Cellan-Jones, the BBC technology correspondent who writes for the BBC’s tech blog “dot.life”. Rory interviewed Tristan about open source, the background of Mozilla, and the new Firefox 3. Read the article and check out Rory’s video of Tristan’s Firefox 3 demo at the BBC dot.life weblog.

The slow death of the press release

Melissa Shapiro, Mozilla’s indefatigable Public Relations lead, has written an interesting article talking about why Mozilla doesn’t put out more press releases and how Public Relations is changing (or needs to change) as an industry. “The PR industry needs to revisit the concept of the next generation press release more than once every few years. Media is always changing. PR needs to keep pace or it will go the way of fax blasting: still around but completely out of touch with the modern era.” Melissa’s post provides a fascinating glimpse the inner workings of Mozilla’s PR efforts, making those processes more transparent and accessible. Check out the full post over at Melissa’s weblog.

Firefox 3 Add-ons compatibility update

Alex Polvi has posted another Firefox 3 Add-ons compatibility report, outlining the current state of the top add-ons that are not yet compatible with Firefox 3. This week’s list includes: Firebug, Tab Mix Plus, FireFTP, Foxmarks, FoxyTunes, Blue Ice, RedShift V2, and ColorfulTabs, among others. Alex is looking for some help, so if you would like to get your feet wet helping out with a Firefox release, head on over to his blog and see how you can get started.

All about SUMO: Mozilla’s second community survey

The Community Survey team has started publishing the results of Mozilla’s second community survey that focuses on learning more about the community that is helping with SUMO (support.mozilla.com). In these first two articles, they outline the process behind preparing the survey, publishing the survey, and some initial analyses of the results. More will be published from this survey, but for now check out the first two articles — part 1 and part 2 — over at the Mozilla Community Survey weblog.

Firefox 3: Site Identification button

One of the most exciting new security features of Firefox 3 is the Site Identification button. The button replaces and builds upon the ubiquitous “padlock” icon that has for so long been the primary security indicator used in browsers. Rather than just displaying a padlock, Firefox 3 finds out as much as it can about the sites being browsed, and makes that information easily accessible through a single click of a button. Through this feature Firefox 3 presents users with information that covers a range of different security levels. For lots more information about the new Site Identification button, check out the full article over at Deb Richardson’s weblog.

Processing.js

John Resig, part of Mozilla’s Evangelism team, has (in his spare time, no less) ported the Processing visualization language to JavaScript using the Canvas element. This project was launched last Thursday on John’s weblog, and his write up includes details about the project’s development and the Processing API, a host of demos, links to the full source code, and instructions on how to use it. The demos all work in the latest Firefox 3 beta, which you can download from the Firefox beta page. Lots more information is available at John’s weblog.

Developer calendar

Monday

• Mobile Meeting
• SUMO Meeting
• General Status Meeting

Tuesday

• Thunderbird Meeting
• Firefox/Gecko Meeting
• Bug Day!

Wednesday

• Mac Gecko Meeting
• Performance Infrastructure Meeting
• Performance/Leaks Meeting
• Mozilla 2 Meeting
• Crash Reporter + Analysis Meeting
• Weave Meeting

Thursday

• Thunderbird Bugday

Friday

• Test Day!

Subscribe to the email newsletter
If you would like to get this newsletter by email, just head on over to the about:mozilla newsletter subscription form. Fresh news, every Tuesday, right to your inbox.

We’re pleased to announce the two latest projects from SitePen Labs: Paver and Persevere!

Paver exists because of SitePen’s Kevin Dangoor, and his work on the SitePen Support web application. We found that the build tools that exist with Python just aren’t all that easy to use.

Paver is a Python-based build/distribution/deployment scripting tool along the lines of Make or Rake. What makes Paver unique is its integration with commonly used Python libraries. Common tasks that were easy before remain easy. More importantly, dealing with your applications specific needs and requirements is now much easier.

As is the case with most of the things we work on, Paver made our lives easier, and we thought it might be beneficial for you. Currently an alpha release, Paver is available under the BSD license.

Persevere on the other hand is a more deliberate approach to rethink how web servers work, and development is lead by SitePen’s Kris Zyp:

The Persevere project is an open source set of tools for persistence and distributed computing using intuitive standards-based JSON interfaces of HTTP REST, JSON-RPC, JSONPath, and HTTP Channels. The core of the Persevere project is the Persevere Server. The Persevere server includes a Persevere JavaScript client, but the standards-based interface is intended to be used with any framework or client.

The Persevere Server is an object storage engine and application server (running on Java/Rhino) that provides persistent data storage of dynamic JSON data in an interactive server side JavaScript environment. It is currently in beta, and boasts a very solid feature set that should interest JavaScript, Dojo and Ajax developers:

• Create, read, update, and delete access to persistent data through a standard JSON HTTP/REST web interface
• Dynamic object persistence - expando objects, arrays, and JavaScript functions can be stored, for extensive JavaScript persistence support
• Remote execution of JavaScript methods on the server through JSON-RPC for a consistent client/server language platform
• Flexible and fast indexed query capability through JSONPath
• Comet-based data monitoring capabilities through HTTP Channels with Bayeux transport plugin/negotiation support
• Data-centric capability-based object level security with user management, Persevere is designed to be accessed securely through Ajax with public-facing sites
• Comprehensive referencing capabilities using JSON referencing, including circular, multiple, lazy, non-lazy, cross-data source, and cross-site referencing for a wide variety of object structures
• Data integrity and validation through JSON Schema
• Class-based data hierarchy - typed objects can have methods, inheritance, class-based querying
• Pluggable data source architectures - SQL tables, XML files, remote web services can be used as data stores
• Service discovery through Service Mapping Description

Comet daily has more information about the recent addition of Comet support to Persevere. Also be sure to check out the Persevere live grid demo.

Persevere is dual-licensed under the BSD and AFL. Visit the SitePen Labs for more information or to download Paver and Persevere.

"Ciao" / "Grüezi" / "Hola" / Hello! I am excited with my first world-wide open source project so trying to greeting in many languages! Firstly, let me introduce myself, I am Robert (Robertus Harmawan Johansyah for full name). About the project, I am contributing for GFX library in DOJO Toolkit, 3 dimension graphics in web is getting hot at the moment so we shall not let DOJO be getting behind! In nutshell, this project will enhance GFX 1.1 that already implemented such as adding Canvas3D from Firefox and Opera! Of course API unification will be taken in consideration! If you interested about what i am doing right now, I am studying Computer Science as final year in Macquarie University, Sydney.

Hello Planet Dojo! I'm Jeff Balogh, and I'm doing doing a Google Summer of Code
project for Dojo this summer. I'm an undergrad at the University of Central
Florida, with one more semester to go. I'm living in Toronto this summer and
working with the DrProject folks, so drop me a line if you're in the area. :)

For this SoC, I'm creating a drag & drop form editor for Dojo. It's not
intended to be a full-featured IDE; I want to make a fun,
easy way to interact with Dojo and Dijit in the browser.. I'm planning to use a
lot of the great work already available, like dijit.form for the widgets and
dojo.dnd for all the fancy moves. This project will provide a way for dojo
users to embed dynamic, customizable forms in their apps, and I'm hoping it can
also be a nice introduction to using dojo for newcomers.

Currently, the plan is to have a drawing area where you drag and style your form
elements, an HTML source editor for twiddling with all the little details, and a
high-level property editor that exposes the important aspects of each element,
like custom validation and callback code.

My mentors are Peter Svensson, Liu Cougar, and Greg Wilson.

This is my first big javascript project, so tips and suggestions are very
welcome! I'm looking forward to a fun and illuminating summer.

The latest Dojo release includes critical but low-risk patches to version 1.1.0, plus localizations to bring the list of languages supported by Dojo to 22.

Dojo 1.1.1 is a drop-in replacement for Dojo 1.1. Because this is the release where the localizations landed, and because of the critical bug fixes, it is recommended that all 1.1.0 users upgrade to 1.1.1 immediately. Here are the highlights:

• New localizations donated by IBM -- now 24 in total, including English and two variants each of Chinese and Portuguese -- to accompany cultural support of hundreds of locales by dojo.cldr.
• Dojo mini, a new packaging of Dojo source weighing in at just over 1M. The same Dojo, with no tests, no utilities, no demos, just the unoptimized source code, making it easier than ever to download and explore Dojo.
• Bug fixes -- 26 tickets fixed ranging from look and feel tweaks to loader and cross domain (xd) loader bug fixes to severe bugs like one in dojox.cometd

Hi all,

Last week, I blogged about installing Windows XP SP3 and how it affects different versions of Internet Explorer (See my earlier blog post here). Today I will be discussing installing branded/custom versions of IE7 on machines with Windows XP SP3 installed. This post is primarily aimed towards folks who use the Internet Explorer Administration Kit 7 (IEAK7) to create custom IE7 packages, like Internet Service Providers (ISPs) and web developers. If you ever installed the IEAK7, built a custom version of IE7 or distributed a version of IE7 to others, this post is for you.

When installing a branded version of IE7 (like the one you get on a Comcast or Qwest CD when you sign up for their services) on Windows XP SP3 machine for the first time, the IE7 install might fail with the following error:

“Process 'xmllitesetup.exe /quiet /norestart /er  /log:C:\WINDOWS' exited with exit code 61681”<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

The reason is that the IE7 package you are trying to install uses old IE7 files. As you may recall, in October of 2007 we released an IE7 update, which in addition to turning on the menu bar by default and removing WGA validation also addresses the XMLLite issue above.

XMLLite.dll is one of the components that ships with IE7. This DLL is necessary to run IE7, and IE Setup installs this component as part of IE7 installation. XPSP3 contains an updated version of XMLLite.dll, so when you try to install an older version of IE7 on XPSP3 machines, IE Setup fails to install XMLLite since it’s already on your system; hence, you get the error. In the IE7 update, we modified the install logic to only install XMLLite if it’s not already present on the system.

Call To Action

If you produce custom IE7 packages, you need to ensure that those packages will install successfully on Windows XP SP3. You can either try installing IE7 on a Windows XP SP3 system, or for a quick test, you can verify the cache of the IE7 files that were downloaded when generating custom IE7 packages. To verify the cache, on the machine that has the IEAK7 installed, go to C:\Program Files\Microsoft IEAK 7\Download\Win32\<Language>\iebin and search for IESetup.msi or IEBrand.msi.

If those files are not present, then you need to perform the following:

1. Download the new IEAK7 available at TechNet.
2. Run the new IEAK7 wizard.
3. Open the INS file you generated for custom IE7 packages. (You can re-use an existing ins file or create a new one, in which case this step is optional.)
4. On the Automatic Version Synchronization screen, click on the Synchronize button. This step downloads the latest IE7 setup files that it will use to generate a new branded package.
5. Complete the rest of the wizard, and click Finish.

The new packages will be created in the directory you specified during the beginning of the IEAK Wizard. These new packages will work on XPSP3, so you are ready to distribute them to all your customers.

Thanks,

Jane Maliouta
Program Manager

I had the chance to talk about Dojo at JavaOne last week, and one of the attendees, Kenn Thisted, was nice enough to create OpenSearch plugins for dojotoolkit.org and api.dojotoolkit.org:

http://mycroft.mozdev.org/download.html?name=dojo

If you are using Firefox 2 or 3, or Internet Explorer 7, you can easily add Dojo search to your browser's search bar.

This is important, so please read on ...

A long time ago, I proposed a patch to Dojo, adding in a little gem of JavaScript to each and every test case in Dijit: _testCommon.js ... it was magic. It loaded whichever theme we chose safely, and set a class name on the body tag, just as dijit themeing requires. It also allowed us to test pseudo-a11y mode, and genuine right-to-left mode for each of the widgets at our whim. This kind of testing is important to Dijit, and as seen by the "matrix", is extensive. We have to test at a _minimum_ each of the "tundra" tests in all of dijit's supported browsers: Internet Explorer 6 + 7, FireFox 2 (and FF3 coming), Safari 3 (ideally both MacOS and Windows variants, as they differ some), as well as fun testing on "technically unsupported" browsers like the WebKit in the iPhone, Opera 9 (which Dijit mostly works with, just not guaranteed) ... It's a huge matrix. _testCommon.js helped with that some, but did something entirely anti-Dojo: magic.

This is my plea: grep your html. If you are inadvertently loading in _testCommon.js via a script tag, remove it. It is 2k of JavaScript entirely unnecessary in any production environment, or any website whatsoever. We use it as a test mechanism, though it introduces magic that causes a lot of confusion, especially among new
users of Dojo. So go. grep your html. If you have a reference to _testCommon.js, remove it. I'll wait.

If something broke, you've come back. Taking the "magic" away from our test-matrix exposes the downside of me having introduced testCommon in the first place. Again with the "there is no Dojo magic here", _testCommon.js breaks two (or more) fundamental Dijit paradigms:

The default Dijit theme is called "tundra" ... It is done entirely based on CSS, and uses a selector ".tundra" to prefix all the class definitions. _testCommon.js was adding the appropriate class name to the body tag, the most top level node available. You can technically utilize CSS inheritance / cascading, and simply put a class="themeName" around your widget dom, but some things that are direct descendant of body (Dialog, Tooltip, Popups) need the class on the body.

the safest way:
<body class="tundra"><!-- my page --></body> you need to load the theme.css!

each theme available has a folder in dijit/themes/ based on the theme name. To load the "tundra" theme, you need the file dijit/themes/tundra/tundra.css ... There is an opportunity for optimization there, but currently the only supported theme mechanism is to pull in the theme "rollup" of all the available components. _testCommon.js was using document.write (of all things) to include the link tags necessary to load the theme files. This is "magic", and also left our test cases without any useful CSS being loaded. This "magic" also probably introduced a race condition in several widgets who relied on the CSS being loaded in order to size properly. It is our recommendation you load theme theme css file before loading dojo.js to limit risk of hitting this race condition.

the recommended way:
<head>
        <link rel="stylesheet" href="js/dijit/themes/tundra/tundra.css" />
        <script src="js/dojo/dojo.js" type="text/javascript"></script>
</head>
<body class="tundra"><!-- your markup --></body>

People use our tests to learn, to copy, to start. Most of our tests are copies of previous tests, modified for some new widget. Having this "magic" _testCommon.js in each and every page propagated throughout all of dijit, some of dojox, and into user pages (I'm no exception to this copy/pasting) ... The Above "skeleton" page is all that is needed to use Dijit. Add another script tag for all your dojo.requires(), and flood the body with markup -- you are on your way.

All this said, _testCommon.js is _still_ in every test file! Ignore it, don't use it, remove it from your pages still ... We still use it to test Nihilo and Soria themes, as well as do the automated magic to set Right-to-Left mode and pseudo-a11y mode. It is still very important for us to test all these modes, and we like having the helper. Though now _testCommon.js does nothing magic until you force it, and the default theme and configuration is reflected throughout all the dijit and dojox tests.

I hope this clarifies some stuff for everyone.

Navigating a mobile app can be slow, especially on long pages and slow scrolling phones. Fortunately the xhtml mobile profile markup language supported by mobile phones provides a solution to finding links and starting phone calls inside the mobile browser.

Adding the accesskey attribute to link a lets users “click” on that link by simply pressing a number on their phone’s keypad. Valid values for accesskey can be 0-9,#, and * (all of the keys on a standard phone keypad). Displaying which key will activate a link is up to the application as most phones won’t tell the user that a link has an access key. Web site designers currently need to decide on a consistent way to inform users that an access key is associated with a given link. Most apps will use ordered lists where the order of the links corresponds with the access keys. Putting the number in brackets inside or next to the link is another way to denote the accesskey.

CNN’s mobile site makes good use of accesskeys. They have chosen to associate the main sections of their web site with the access keys 1 through 9:

CNN uses a span with the access key number to highlight to the user what number to press to activate the link:

<span class="rebg_num"> 1 </span>
<a accesskey="1" class="base_text" href="/cnn/item/world">World</a>

Pagination links, home page, and any other page that the user will use often are good candidates for adding an accesskey. Consistency is key: if home is (1) on one page, then it should be (1) on all the other pages where that link exists. If users can rely on a keys behaving constantly they will use them. Just like other information architecture exercises, take the necessary time to properly allocate the 12 accesskey options to the pages in your app.

Like the accesskey, starting a phone call from a link is just as simple. Just as mailto: will open an email message on a desktop web browser, adding href=”tel:5555555555″ to a link will start a call and dial 555-555-5555 automatically for the user. Keep in mind that most phones not developed by Apple cannot handle a web or WAP session and a phone call at the same time, so the session will end when the link is clicked.

Using both the access key and the tel protocol will enhance your mobile applications by saving the user time and integrating the mobile web experience with the voice features on the phone. Consider adding them to your existing mobile applications or using them on your next mobile project.