GSoC Proposal: Visual CSS Editor

March 2010

Please note that due to the personal nature of some sections of the WordPress GSoC proposal template, this post only contains the project description and schedule of deliverables for my proposal.

Summary

In short, I would like to create a CSS editor that will be easily integrated to existing themes and provide users with a better alternative to theme options.

As some of you may know, I worked on a similar project for WordPress in last year’s summer of code. This proposal represents a year’s worth of thought and revision with regard to the larger subject of theme editing and development. Put simply, this is what I want to do this summer.

User Groups

Theme editing is tricky business: there are many user groups to please. As a general rule of thumb, I plan on targeting users with least experience (to reach the broadest audience), and providing additional functionality and extensibility for more advanced users.

Frontend:

Backend:

Philosophy

Iterate, iterate, iterate.

User Interface: This plugin should look and feel at home in the WordPress admin panel. I plan on getting UI feedback from Jane and if willing, #wordpress-ui. If released, I plan on following the forthcoming WordPress UI guidelines.

Extensible: Like WordPress, the plugin should be light and extensible.

Core Features

Edit CSS through a GUI:

Theme developers specify which elements are editable:

Central event bus:

Automatic child themes:

Developer Features

Edit CSS with live preview:

Multiple active sessions and cross-browser preview:

Edit CSS Properties: Features & UI

Users will be able to edit CSS properties for specific selectors. Some features/UI:

Potential issues:

Feature: Color Palette Editor & Dynamic Selections

Color palette editor:

Dynamic selections:

Plugin, theme, or core

I believe the editor would be a good candidate for a core plugin. If the editor is lightweight enough and the community was behind it, parts of the editor could be integrated into core.

Research

I’ve done a considerable amount of research on numerous topics surrounding the editor. Most of them are quite technical (such as the benefits of using the native DOM StyleSheet over a JavaScript CSS parser, and the effects of browser reflow), and I don’t want to overwhelm you with implementation. If you’d like me to post a more in-depth technical analysis, please let me know. Here is one example:

I’ve played around with several ways of designing the API for themes to register selectors with the editor. While I initially thought that registering selectors in the PHP was the best option, I now plan on using CSS, as more developers are familiar with the language, and the notation is more concise. This CSS will be located in a separate file (such as visual-editor.css), and could either be automatically read or triggered by add_theme_support(‘visual-css-editor’). I’ll leverage custom properties to detect descriptions and registered properties.

Example syntax would look as follows:

h2.blog-header {
-editor-description : “The site header”;
-editor-add-property : “background font”;
-editor-remove-property : “line-height”;
}

This file would be read in the PHP, and sent to the JS as JSON. If a plugin registers an action to “visual_css_editor_selectors”, the JSON could be converted to a PHP array, passed through the action, and converted back to JSON.

Challenges

One of the larger challenges will be developing a UI that users are comfortable with. This will require a considerable amount of user testing and revision, which I am prepared to do. This project entails heavy use of JavaScript and jQuery, and I am quite experience while using both. As I learned from last summer, maintaining JavaScript code is difficult. If left untended, files can grow to massive sizes and be incredibly hard to read. I plan on separating my JS into numerous pieces that will be concatenated together using Sprockets.

Discussion

In discussions in both wp-hackers and #wordpress-gsoc the idea has been met with positive feedback. Andy Skelton suggested the idea for cross-browser preview, which I think is a fantastic feature. Jeremy Clarke suggested looking into other similar plugins, which I have done, and plan on doing further. I received additional help and feedback from Ptah Dunbar, who helped me solve issues with the Same Origin Policy; Andrew Nacin, who discussed how a core theme revisions API could benefit the editor; and John James Jacoby, who discussed the API for registering CSS elements. Finally, Beau Lebens, my mentor from last summer, has provided continued help and feedback.

Potential mentors

I’d love to be mentored by anyone who is interested in the project, and likes talking about the best way to implement a feature (also, long walks on the beach, chocolate covered strawberries…).

Noel Jackson expressed interest, as did John James Jacoby, provided he doesn’t mentor a BuddyPress project. Beau expressed interest as well, and has already heard much regarding the scope of the project.

Schedule of Deliverables

I am proposing a condensed schedule consistent with WordPress GSoC custom, and plan to have a working version by midterm evaluations. This project has intensive UI requirements, and I plan to continually user test and refine as I develop new features. In addition, this schedule allows for the inevitable roadblocks, tweaks, and bugs I’ll face along the way.

Other commitments

I will be abroad and taking exams during the community bonding period, so my time will be somewhat limited. By the start date, my exams will be over, but I will still be in the UK (and coding!). I’ll likely return home that week.