Daryl Koopersmith

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:

• The average WordPress user serves to benefit the most from an interactive theme editor as they currently have no similar tools at their disposal. As a result, we cannot assume that users know CSS, and must design the UI accordingly. If and when features are added for developers, they should be added in a separate “developer mode” so as not to overwhelm the average user.

Backend:

• Many theme developers are unfamiliar with PHP (despite the fact that it’s the backbone of WordPress). Beginners should be able to easily add CSS editor support to a theme. Easy-to-understand APIs will both result in fewer errors, and increased usage. That said, we should not sideline advanced developers; providing advanced APIs and adding hooks will allow advanced developers to tweak functionality and extend the editor through plugins.

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:

• The core function of the plugin; users will be able to edit CSS using a visual GUI, and view their modifications in a live preview (if they’re editing the activated theme, site visitors will not see changes until they are saved). Elements of the GUI are described further below.

Theme developers specify which elements are editable:

• To prevent potentially thousands of HTML elements from overwhelming the end user, theme developers will register editable CSS selectors with the editor. Developers will provide selector descriptions (i.e. “the post header”) and manage editable properties to prevent users from breaking the theme.

Central event bus:

• The UI elements will communicate through a central point using custom JS events. This allows for rapid iteration and makes the UI extensible.

Automatic child themes:

• Since we’re altering the CSS, it makes sense to automatically generate child themes upon modification. This project would benefit immensely from a theme revision API being implemented in core, as much of the following would already be implemented (and then some). By saving child themes in a custom post type, the plugin can gain theme revisions, MultiSite support, and inherit media features from the post editor. However, the plugin would also have to be capable of exporting these themes, and alter the “Manage Themes” page to display them as well.

Developer Features

Edit CSS with live preview:

• Strip away the GUI and provide a text editor in its place, allowing users to edit the child theme’s CSS and see results live. The plugin could embed the WordPress core theme editor, provide client-side validation, and apply updates live.

Multiple active sessions and cross-browser preview:

• By allowing users to have multiple active sessions, the plugin editor could provide cross-browser preview. This has several nice implications, such as allowing users to make the CSS editor full screen and see updates live in other browsers. If average users have the ability to edit CSS properties that are not supported in all browsers, this could be of use in the plugin core. Implement this by keeping track of the sessions in PHP. When certain events pass through the Event Bus, send them to the server, which will push them to the other sessions via ajax with long polling.

Edit CSS Properties: Features & UI

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

• Users can select elements either by hovering over elements (akin to Firebug’s “Inspect” feature), or selecting elements from a list/dropdown.
• Like properties will be grouped together as tabs in the UI.
• Color-based properties will present users with a color picker and a color palette (consisting of other colors within the theme), and also accept hex values.
• Image-based properties will hook into the WordPress media library, and take cues from custom-header.php and custom-background.php in presentation and function (use wp_handle_upload, etc).
• Properties with various set text values (i.e. border-style) will have options presented in either a dropdown or a radio button-set (think align left/center/right in TinyMCE) depending on how many options are available to the user.
• Numerical properties will present users with a “value” slider and a “units” dropdown (or radio button-set).
• To edit margins and padding, users will be shown a visual box model (a box inside another box for padding and margins, respectively). Top/bottom/left/right values are positioned according within each box, and are clickable; once selected, they can be edited like a regular numerical property.

Potential issues:

• Not all browsers implement the same CSS properties; certain properties, like opacity, will have to be normalized across browsers. However, the trickier issue is how to deal with browsers that don’t implement a given CSS property (such as text-shadow). One option is to simply not implement them (which is viable, since most, if not all, are CSS3). Otherwise, there would have to be a system to warn the end user if they were using an incompatible browser (as they would see no changes), and warn them of other incompatible browsers.

Feature: Color Palette Editor & Dynamic Selections

Color palette editor:

• Color is a huge part of theme design. Users will be able to quickly change their theme’s color scheme, without repetitive clicking (or the chance of missing a property).
• This wouldn’t be revolutionary to developers; it requires a simple find/replace.

Dynamic selections:

• These are element-filters. Users could select all elements where property X equals Y, and then modify their CSS. (You can almost think of it as SQL for stylesheets, but with a friendly UI).
• A color palette editor requires the dynamic selector: “Select all elements where any property is a color.” As a result, it makes sense to (at the least) include dynamic selectors in the editor API. The question is: do we expose it in the UI?
• This is incredibly useful for developers dealing with complex properties such as background or border: Want to select all borders that are 1px wide and dotted? Simple. In a text editor, not so simple (unless you already know what you’re looking for). Matches include:
  • p{ border: 1px dotted; }
  • p{ border-width: 1px; border-style: dotted; }
  • p{ border: 1px white dotted; }
• For users, usage of the raw feature is questionable, and has the potential to overwhelm. However, it could become more palatable in the form that lets users say “Select all elements like this.”

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.

• Week 1: Make wireframes, write core JS events system. Do research, and read lots and lots of code.
• Week 2: Build APIs for live CSS editing and generating the resulting stylesheet.
• Week 3: Begin to build UIs to edit CSS, excluding media features. User test.
• Week 4: Continue building and refining UIs. Color pickers, sliders, etc, should all have prototypes by now.
• Week 5: Add theme saving and management using custom post types, or a core theme revisions API. Begin building cross-browser preview.
• Week 6: Continue testing theme saving/management. Finish cross-browser preview. Begin media features.
• Week 7: Complete media features. Midterm evaluations. Prototype complete!
• Weeks 8-12: As per WordPress GSoC custom, dedicated to debugging, documentation, and refining the project.

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.