http://conferences.oreillynet.com/os2003/
Last year's in San Diego, CA, was nice. This year, I won't have to pay for the hotel room... my parents live right across the Columbia River in Vancouver, WA.
Looks like this year, mozilla.org's presence will be restricted to Birds-of-a-Feather sessions (BOFs). Maybe we should try crashing the party (one BOF a day) ;)
BOF: Mozilla Beyond 1.4, BOF: QA & Triage, BOF: Bug Fixing, BOF: Business & Documentation, BOF: Anything Under The Sun, BOF: Introduction to Mozilla Technologies, etc.
I'll let Christopher Aillon (module owner for Inspector) speak on long-term planning for Inspector, but I felt I should just take a moment to summarize just what I've been up to for Inspector.
First off, if you really want to look at all bugs filed against DOM Inspector, here's a Bugzilla query:
http://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&product=Browser&component=DOM+Inspector&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit
A lot of those bugs catch my eye. Among them is bug 109682, my ultimate goal in the long-term: making Inspector into a fifth panel on Editor.
Bug 112775 is my first major change (by major, I mean something which requires significant tinkering to figure out how to do it right), for something that you'd think would be simple: inserting a node. Turns out there's a lot of possibilities to consider.
Bug 112922 is a bug for editing and splitting text nodes -- a pretty important feature of a DOM editor tool. I haven't yet explained my approach, so in a nutshell, I'm thinking of textareas which update the node as you type. This is consistent with how Editor works, and it's seamless (WYSIWYG).
It also makes handling undo and redo operations in Inspector a bit touchy. Bug 179621 is a multi-phase process for converting Inspector to use Editor's Transaction Manager model, which governs undo/redo for the major applications of Mozilla (Navigator, Composer, Mail/News).
The bread and butter of DOM Inspector are the various viewers -- the applets that let you see the structure of the document and interact with said document. Big changes are coming. I already mentioned bug 112775 (that affects the DOM Nodes, or dom.xul, panel) and bug 112922 (that affects the DOM Node, or domNode.xul, panel). Looking from viewer to viewer, there are other improvements to note.
In dom.xul, we're finally going to see the #document node. Bug 156072. We're also going to see other #document nodes which are "contentDocument" properties of framed documents (like the HTML iframe's contents). That one is bug 201585, and bzbarsky is handling it. (Sorry, I can't hack C++.)
As a direct result of bug 201585, we'll be able to look at stylesheets for framed documents as well. (Bug 201586.) That'll be the Stylesheets viewer for a document, stylesheets.xul.
For specific DOM nodes selected in the left panel, the right panel will see a lot of new information, tailored to newly-exposed nodes such as document nodes, document-type nodes, and processing instructions. Bug 201129.
I'm not touching the box model. Fuggedaboudit.
XBL bindings, I should probably take the time to redesign it a little bit. The interface is confusing. I'm not going to file a bug on that yet, or accept one (if you readers get any ideas). but it's itching in the back of my mind.
Style Rules, well, we need a way to add a new style rule. I'm waiting to hear back from Mr. Aillon as to whether his bug on changing how Inspector accesses style rules includes that or not. If not, I'll file then.
Bug 192841, for non-CSSStyleRule rules, is pretty important to fix for this panel.
Computed Style: It's a simple interface, doesn't need anything from me.
JavaScript Object: the most drastic changes of all the panels, by far. You won't recognize it at first. Bug 193942. New features:
* Dynamic resorting by alphabetical listing or by original ordering
* Revealing unenumerated properties (like window.Components)
* Regular-expression searches of the tree for names or values matching a regexp
* A multiline textbox for those multiline values
* Typeof included
* Matching an inspected value against a higher inspected value (for instance, document.defaultView.document == document)
* Assigning a match for convenience
* Creating new properties and methods on the fly
* Executing methods on the fly and getting a return value added to the tree
* I think that's all I've come up with so far...
Other bugs:
I really should take the time to fix bug 111411.
I filed bug 119388, and I should investigate that one further.
Bug 121774, I should ask for reviews on for what I've got, and again I wait for Mr. Aillon for style rules.
Bug 123089 sounds interesting.
Bug 128421 I think bzbarsky is going to take.
Bug 150560 is another I should take the time to fix.
Bug 158826 will almost certainly need a DOM extension if it's ever going to happen.
Bug 166749, shouldn't be too hard.
Bug 178582 and bug 178583, I'm not sure why I filed those...
Bug 183060 I will probably spend some time fixing. Seems easy.
Bug 189950 I came up with a fix for, and it's the wrong one...
Bug 193724 is assertion-cleanup (so I've heard, since I don't work with assertions) and minor UI improvements.
That's the news so far. We're looking at a timeline for most of the bugs (except under "Other Bugs") of roughly Mozilla 1.5 or 1.6 beta.
Started doing some tinkering around for bug 179621. Here's a documentation/logic breakdown for the first phase patch.
Bug 111514, including comments up to 80
There's been a long and sharp debate on how Mozilla should treat an XHTML document's DOM as the mime-type indicates it. I've made a static copy of the first 80 comments on the bug, so as to cut down on Bugzilla server load, and invite the discussion over here.
There are four mime-types for XHTML documents. The first, text/html, is irrelevant as that automatically triggers HTMLDocument. The best, application/xhtml+xml, currently is XMLDocument. (jst has a patch to make that HTMLDocument as well.)
The other two, application/xml and text/xml, are gray areas. My thinking now is these two mime-types we should continue to treat as XMLDocument for DOM purposes.
Extended debate welcome.