Last week began the final stretch. Following the release of the preview, I focused on finding and fixing bugs and preparing the final features. Amongst other things, I updated the highlight widget to allow users to preview which elements match a given selector (hovering a selector in the list shows all matching elements).

Earlier today I spoke with Beau about the goals for the final project (and accomplished some bug-squashing to boot). We decided that this week I should focus on implementing the last few critical editing features (adding/editing/removing selectors and properties, the point-and-select UI) and improving theme compatibility (accounting for CSS @rules and potentially including @import rules in the model). The editing features are well on their way, and if all goes well @rules should fit into the model nicely. I’d like to provide a method to recompile the output—however, this is likely non-trivial and may have to wait until a later version.

Good luck, everyone!

A Preview

Hey everyone, yesterday I had the pleasure of presenting a preview build of the editor in #wordpress-gsoc. I received some great feedback—thanks to everyone who came!

I discussed the major limitations of the preview in the meeting:

The editor will eventually handle any theme. This is one of my major goals this summer, and I’m well on my way.

There are, however, several limitations in the current build:

First, it’s important to note that the editor does not modify a theme’s style.css; it saves its modifications in a separate file—all edits you make can be discarded. However, the separate file is used in place of style.css. At the moment, if you save customizations to a theme and update style.css at a later point, the customizations will not reflect those updates. I’ll be working on a recompile method to attempt to automate these updates and make upgrading themes as painless as possible.

Currently, any at-rules in the CSS (such as @import and @media) will be ignored and discarded. I’ll be adding support for @import soon (as it is the most common and has the highest impact on the output).

The current version has a very limited UI—for the moment, you can only edit properties (no adding/removing yet). More detailed UIs, such as panels dedicated to background, typography, spacing, and borders, along with UI elements (such as color pickers, sliders, and dropdowns) will be added soon. I’m also working on a firebug-inspect-like feature for selecting elements.

Download the preview.

---

For the past week, I’ve been hard at work building the preview. The event bus/history manager has been updated and integrated, the properties panel is now functional, and saving, loading, and resetting have been added. Most placeholders have been removed, so almost everything you see should be functional.

This week, I’ll be tackling some of the following: the in-iframe UI, adding/removing properties, shorthand property parsing, and maybe even another panel.

Try out the preview and let me know what you think!

Hey all, this week has been both tricky and fairly productive.

I wrote a JS event bus that supports history (specifically undo and redo), which will serve as the foundation for most UI events.

While working out the saving algorithm, I found myself stuck with the choice between having the theme load its style.css file and an additional edits.css file (generated by the editor), or load only a compiled style-and-edits.css file. There are downsides to each method—for the former, it’s impossible to remove a property from a selector; for the latter, the style-and-edits.css file must be recompiled every time the theme’s style.css is updated. After talking with Beau and Andrew, I decided to go with the latter. In the future, I’ll attempt to automate as many recompilations as possible (hook in when a theme is updated through the admin UI, checking the theme’s current version against the version used during the last compilation, and hopefully taking advantage of any APIs Andrew develops to detect file updates), but for now there will likely just be a big “recompile” button.

In switching to the style-and-edits.css method, I found that I needed to tweak the data I was sending from the PHP to the JS. In doing so, I managed to improve performance and slash data size in half. I’m in the process of adapting the JS to the updated data and writing the methods that will power most of the style panels (I posted the first major patch earlier today).

I’m moving along at a brisk pace, but there’s much to be done. And so it goes.

I’ve kept busy this past week. I managed to reduce CSS parsing time and data size significantly—to the point where the plugin is now competitive with widgets and menus for overall load times and data size. It felt fantastic to finally be able to move forward.

I then wrote the data structures to manage the parsed CSS in the JavaScript (CSS property priorities are trickier than they initially appear). I’ve worked out a few possible algorithms for saving the CSS (the goal is to ensure no priority conflicts while minimizing css size), and designed the data structures with them in mind. I also updated the JS selector parser to generate accurate priorities (which allows me to work with user-generated selectors without parsing them via AJAX).

I’ve integrated those data structures into the search panel and top bar. I’m leaving the preview item-selection unconnected for now—I want to see how the properties panel turns out before developing that interface any further.

The properties panel (a generic property/value editor) is my next major milestone. I’ve added new inline and stretching input UI widgets, and am currently working on the interface to apply property changes (and other major events). I hope to finish the properties panel before this week’s community meeting and give users something to play with. I’ll leave you with a little preview. ‘Til next time.

Hey all, this’ll be another quick update. This week has been primarily devoted to parser writing and AST creation, accompanied by a healthy amount of bug squashing. I’m working on integrating a property/value panel, along with tweaking the parsers and improving performance. I’m currently wrangling a few bugs and preparing a few pieces for commit—watch this space.

“Two steps forward, one step back” seems to have been this week’s mantra. I finished up the panel UI, implemented a few generic widgets, and began to integrate them into the UI.

The step back came when I began to implement and organize the CSS data I needed to continue moving forward. While I had implemented what appeared to be the best potential solution, the code to make the solution cross-browser began to detract from performance. This, as well as additional benchmark data and the fact that each browser’s representation of the data differs, led me to begin writing a CSS lexer/parser in PHP. (To be clear, this is something I’d already planned on doing, I just shifted the date in the timeline).

As a result, the latter half of my week has been devoted to researching and coding the lexer/parser. I’m happy to say that the lexer is complete and working, and if all goes well, the parser will soon follow.

Hey all, late update this week.

This week I began fitting some of the pieces into the UI and immediately found it too cluttered, so I decided to take another approach. The new approach clears out some unnecessary controls, pulls the preview into the workflow, and allows active controls to occupy more space.

I’ve also been shifting the UI from mockup to code, there are continually more things with moving bits and pieces instead of sitting there and looking pretty. I’ll continue coding the remaining static UI bits this week.

I was originally using the meta-box core functions to generate my side panels, but I found that I was both hacking behind the functions and providing an interface to the functions. This wasn’t entirely sensible, so I’ve rolled my own panel UI. It’s just about done; I now have to tweak the JavaScript side of things.

This week I plan on finishing up the generic panel code, implementing the rest of the selector workflow, and adding a few new panels.

This week has been quite productive. I’ve written majority of the necessary functions (and they’re cross-browser to boot). I’m going to keep this short for the time being, but I’ll try to write a longer update and have something pretty for you to play with soon. Cheers.

This week I focused my efforts on the CSS Object Model. Initially, YUI’s StyleSheet module seemed promising (I even managed to take the Y out of it), but unfortunately it solves cross-browser issues by bringing everything down to IE’s level. While their solution has negligible effects in certain situations, my project is decidedly not one of those situations. I surveyed a large number of CSSOM modules and nothing accomplishes what I’m looking for. YUI and Google Closure (which is licensed under Apache 2, sadly) come closest.

I’ve spent the majority of the week writing my own implementation (and borrowing from YUI where applicable). I’ve managed to simulate the proper data structures in IE and am now working on writing the methods and smoothing out the bumps. The end product will be a small, powerful library that will handle most of the heavy lifting in the plugin.

This week will be filled with more CSSOM work. Hopefully I’ll be wrapping it up and shifting my focus to the UI by this time next week.

I’ve spent the past week testing basic UIs and after several revisions have a decent working draft. It’s still liable to change—I’ll be contacting some of you UI/UX gurus this week for your thoughts.

I’ve also updated my project with a list of milestones and checked my code into svn.

This week I’m shifting my focus to parsing and writing CSS. It’s proving to be a fun problem with a bunch of wonderful cross-browser differences. As usual, IE crashed the party. I’m still trying to determine the best approach, but know of at least one viable cross-browser solution.