I’m using CodeMirror (current version is 3.18) to act as my source code editor. The scripted DOM is still there, this time showing attributes as children before a XUL tree separator. On the right side, we start with relevant SAX events to capture details of the DOM I’m building. Then there are logging events for the “Node Positioning Service”, which tries to align source code to DOM nodes. The lower right box captures change events from CodeMirror.
The next major phase will be about handling XML entities (&button.label; for example). This will require a first introduction of a “shadow DOM”, where some DOM nodes will hide others from direct access. (Indirectly these other nodes will still be accessible.) This also means I’m starting to catch up with progress I made five years ago… that’s what happens when you do a rewrite.
Code reviews (Python code reviews also welcome)
Mozilla’s transaction managers
Encoding support (UTF-16, Unicode, etc., since I’m definitely “doing it wrong”)
By the way, I enjoyed the Mozilla Summit, and thank you for letting me present Verbosio at the Innovation Fair in Santa Clara.
Personally, I’m opposed to it as well. MathML is one of those frontiers which has immense unexplored potential. Can you imagine writing e-mails to instructors with inline mathematics formulae, or including equations in an instant messaging chat? I can and have imagined exactly that for as long as I can remember. I tried once upon a time to bring MathML into Mozilla Composer with my Abacus project, but determined it was too hard and too hacky to be a true solution.
This is precisely why I’ve been working on my prototype XML editor, Verbosio. It’s supposed to be a complete rewrite of how we create and edit web pages. The idea is that a language like MathML is simply a Mozilla add-on to the editor. Unfortunately I’ve been buried with both full-time work and college to make any real progress on my Verbosio project on my own.
I’ve said for years that I didn’t want to attract a larger audience on an unproven principle. Maybe that’s the wrong decision in this open-source Mozilla community. While I still believe in the idea, I’ve become my own bottleneck. It’s far past time for me to swallow my pride and admit that.
With college and a full-time job, I’ve been rather busy. But I still find time to make small improvements. I’m continuing to work on my experimental XML editor, Verbosio, from the ground level. I realized a couple months ago that I really needed some pictures to show where I was at.
This is work from my Verbosio Templates subproject, which currently requires Mozilla Firefox 22 (currently in Aurora).
The first image looks like a very cheap copy of DOM Inspector – and it is.
There are a couple more differences – for instance, this latter view includes a XML declaration. In the DOM specification, it shouldn’t be there, because the XML declaration is not recognized as a node at all. But if you’re going to edit a document that already exists and already has that declaration, as a set of DOM nodes, you should preserve that declaration. So my non-standard DOM implementation makes it a processing instruction.
Both trees, by the way, are also using my TreeViews.jsm module. I hope this module can be helpful in building XUL trees from object models like the DOM.
I’m also starting work on a WebGL-based view of the same trees, where nodes and their descendants are laid out in two dimensions as cubes, in a tree hierarchy like this. WebGL is a three-dimensional context, though, so you may be wondering what the third dimension is for. Initially, I’ll draw attributes as cubes above the elements they belong to. That part shouldn’t be hard – and it should be very doable by anyone proficient with WebGL, inside an ordinary web page. I’d love it if someone beat me to it.
You have a XML or HTML document from a version control system. (SVN, Hg, git, etc.)
You have an editor which parses that into a DOM document.
You edit the document using a GUI, not looking at the source code – just adding in paragraphs, new widgets, math formulae, vector graphics, etc. with a visual editor of some kind.
You finish your changes and save the document.
You get ready to commit your altered document back to the source code repository, looking over the change set, and wonder what your editor did to your document: it only looks vaguely like what you started with.
This is a hard problem, I think, and for the most part it comes down to handling white space inside a XML tag of some kind. For instance, attributes may appear all on the same line as the element they belong to, or on new lines by themselves, with different indentations.
On the one hand, a visual editor like this isn’t required to preserve source code formatting. As long as two different formats of the same XML document’s white space parse to equal DOM nodes, the editor normally does not care. On the other hand, version control systems don’t often deal with DOM nodes – only with the source markup that an editor generates.
In trying to build a better XML editor (Verbosio) which supports editing in visual modes, I feel I have to respect both visual editing and existing source formatting. Now, there may be a solution out there – a set of algorithms and a specification – but I have certainly not heard of it. On the other hand, many source-controlled versions of XML documents have certain patterns enforced from coding patterns their authors require. I am much less concerned with formatting a document the way I think it should be than with honoring existing patterns of source formatting.
So, would you please post relevant links as comments to this blog entry? Either an existing specification for this sort of problem, or diverse XML samples where people have their hands on the code regularly.
I’ve just started putting together a guide on XPCOM streams over at MDN. We already have wonderful guides on strings, hashtables, and arrays. Streams are also really important, but there’s not much documentation on them. So I figured, why not start some?
I’m going to be working with streams a bit over the next few weeks as I convert from SAXXMLReader.parseFromString() to SAXXMLReader.parseAsync(). Apparently, the parseFromString() method is not very nice. So I’m dusting off some old tools and ideas, and I’ll be writing down what I run into that I think others can use.
The XPCOM Stream Guide is right now little more than an outline. My own time is very limited; if anyone else wants to fill in some of the blanks, I’d really appreciate it!
However, I suspected my use of DimensionalMap was unnecessary – particularly since I was working with only one dimension at the time. So in a quick experiment, I replaced the code that used it with code using WeakMap. Total execution time with the same tests: about 1.5 seconds.
Ouch. I still think the API is a good one, but clearly the implementation has issues.
Both the web technologies space and myself are undergoing a fair bit of change right now. I’m in college learning C++’s fundamentals which I missed, and picking up on concepts in computer science I never really worried about before (order N^2, order n log n, etc.). People who are familiar with my blogging are also aware I like to understand best practices that are language agnostic (i.e. “each function should do only one core thing, and leave the rest to other functions”). I can say I’ve learned a lot of what’s from talented Mozilla contributors, but not necessarily a lot of why’s (at a level higher than specific languages).
So I’m writing to ask the Web and the programming community at large (yes, bigger than just Mozilla) where we talk amongst each other about computer science as a practice – not about specific languages, but about why we do what we do. Keep in mind I’m not referring to one-way conversations, where someone writes a blog entry (CodingHorror) or a Wikipedia article or a book (thanks, Code Simplicity, seriously), but more of a freeform discussion among professionals. Sort of like an IRC channel (with politeness), or a newsgroup, or even a meal at the local bar.
I’m experienced enough as a developer now to mentor others, but I recognize that I am not yet the Wise Bearded One. (Nor will I be in December, thank you very much.) I’d really love to find a place to hang out with other professionals in a free-form exchange of ideas. Somewhere to step into the abstract without getting too technical.
For those of you who don’t care how the DOM is implemented, only that it generally works: this is definitely a “tl;dr” blog post.
I’m not suggesting Gecko DOM implement this (though that would be very nice of them). I’m going to prototype it for my own needs, and see how well it works. I hope this explanation is in clear enough language for the average developer to understand.
This cannot possibly be good for our developer community. Think about it: Visual Studio has a much more developer-friendly C++ debugger than GDB on Linux – that’s why when I’m writing C++ code, I prefer to do it in Windows. Certainly it means many of us will be stuck on VS 2010, and Mozilla will have to support code written for before the C++11 standard for quite a while.
It wasn’t that long ago that I implemented timeouts for XMLHttpRequest. If I’d had to make do with the VS2011 Express compiler… I’d be on Linux.
Pay-to-play sucks when it’s pay-to-make-the-Internet-better.
Alex Vincent's ramblings about Mozilla technology, authoring, and whatever he feels like.