AXR: Arbitrary XML Rendering

  "model"                            presentation
  -------                            ------------
  <div class="order">                .order { .. } 
    <h1 class="agent">...</h1>       .agent { .. } 
  
  here your model has turned into html, yet has to be
  re-expressed as presentation rules. your model is 
  presentation. WAT.

  =>
  <order>                            order { render: box }
    <agent>                          agent { font: ... }

In the presentation they say they're looking for "Computer Science Engineers" make me think this is a bunch of aggravated designers. On the other hand, there is code on GitHub. But it's C++, which makes it feel like this is a bunch of aggravated developers who can't stand having to do HTML or CSS and want to do "real engineering" (usually defined as non-webapps). This seems to pop up every other month. All the while people keep making awesome web sites, applications and libraries with the stack we have today.

A small group of people is usually all it takes to change something, on the other hand, I don't think is change people want or need.

That said, I wish them all the best.

For crying out loud, let's finally unify the syntaxes, rather than creating yet another way to represent tree structures.

How are you going to compete with existing browser rendering engines written with massive engineering resources and years of optimizations and convince browser vendors to replace them with your stuff and let go of control over the development?

If Webkit started supporting AXR, it would become the new standard.

Who has the most to gain by supporting a genuinely good web standard? Could be Microsoft actually.

Microsoft -> Mozilla -> Webkit -> Everywhere

Have you tried reaching out to the IE team, or had interactions with other browser companies?

Here are some thoughts:

- We need to decouple semantic structure definitions from browser releases. AXR gets this, but we can go further.

- Further, we ought to somehow retain HTTP as a transport layer and keep the content text-based but still remove the reliance on SPECIFIC languages.

What I imagine is very similar to AXR, only it would be something you could build AXR on TOP of. If you have a better idea than AXR, you could build that as well. Let the market decide. In fact, traditional HTML/CSS/JS could also be built on top of the new system.

As you're probably guessing, I'm imagining some sort of "assembly language" + object model that exposes the core primitives of structure, presentation, and behavior. Now when I say "object model" I don't mean the DOM. I mean something more primitive than that in which the traditional DOM and other things could be implemented.

The nice thing about this model is that the site can specify the location and version of the "compilers" it needs the browser to use to understand whatever it is sending. Most of the time, these would be well-known software components that ship with all browsers by default and are updated via standards bodies (just like now). The difference is that the standards can evolve independently of the browsers. Also, sites are free to use whatever they want as long as they can come up with it and the user agrees to download the components. When you think about it, this is really no different than "plugins", only now the content is not opaque.

Browsers now become exercises in implementing the primitive "HTTP VM" (or whatever it's called) in the most efficient way possible, adding end-user features like tabs and private browsing, and implementing new VM versions as they are released by the WhatWG or W3C. Hopefully, these can move more slowly because you shouldn't need new primitives as often.

It doesn't need to be said, but the HTTP VM can also be implemented server-side.

I know this idea is half-baked and has some major problems, like:

- How do you define what's "primitive" without getting into decade-long ontological discussions?

- How does this change how web crawlers work? Presumably, sites like Google would have to act like web clients and also download and run the compilers needed to parse each site. Could this be done with acceptable performance?

- What does this "assembly language" look like? If it looks like XML, aren't we back to AXR?

- If we keep going down to abstractions, we might as well just send LLVM code through HTTP and have web clients implement some "idealized real computer" with I/O and memory and all that. Then what are we doing? Isn't this something totally different? Why not just build that and hope it gains traction?

- JS JIT compilers are very finely-tuned. Will going down to a lower level of abstraction actually make performance suffer because there are less high-level things that can be recognized and inlined?

- Are HTML/CSS/JS ALREADY this assembly language of which I speak? If we just add the ability to define arbitrary HTML tags, allow them to "derive" existing tags, and define their default structure, presentation and behavior through JS calls or declarations on some "meta tagdef" element, aren't we mostly there? With so many browser vendors and versions, it's much easier to evolve than replace.

That said, my point is that no matter how good you can imagine the "next" HTML/CSS/JS, why fight the battle to bake it into all web browsers only to have to fight that battle AGAIN in another 20 years. Sure, revolutionize the platform. But revolutionize it toward abstractions and language independence.

use XML instead of CSS syntax and XPath instead of CSS selectors and just make it less obnoxious than XSL-FO and less template-oriented than XSL:

  <!-- index.xml -->
  <books>
    <book>...</book>
    <book>...</book>
  </books>

  <!-- index.style -->
  <axr:style select="//book">
      <color>#000</color>
      <background color="red"/>
  </axr:style>

  <!-- index.style -->
  <books>
      <book>
         <axr:color>#000</axr:color>
         <axr:background color="red"/>
      </book>
  </books>

Note: I'm generally in favor of rewriting things, when the benefits are clear. With HSS, I don't see why I'd want to replicate the tree again,(using a different syntax, i won't even be able to copy-paste!) just for the style. I'd rather use XPath selectors and XML.

Some thoughts:

1. It would be nice to merge CSS with XML (as others have said - there is really no need to have 2 different syntaxes)

2. It would be nice to use XML everywhere (the more you use it, the easier it's going to be to integrate this into IDEs, scripts, web apps, etc).

3. The important thing is the value of the COLOR, not the fact that you managed to parse braces, pipes, etc and come up with your own syntax for representing a tree and selecting elements in it? That's wasted effort and you're not innovating. Use XML, or JSON, or YAML (whatever floats your boat), but use that EVERYWHERE: for data and style. That would be a step forward from HTML/CSS.

4. Again, there is no need to reinvent XPath, like CSS selectors are trying to do. Use XPath, it works great with XML, it's CONCISE and it is familiar and simple, because it looks like a file path (or basic url) with some optional filtering on each level. (N.B.: don't fall in the XPath2/XQuery trap).

5. Embedding Javascript would be easy: it would be the same as HTML: <script/>.

6. You get brownie points if you could use JSON for elements, style and scripts. You'd reduce the entire HTML/CSS/JS stack to just JSON:

  //index.json
  {
    books: [ { title:"foo" }, { title:"bar" } ]
  }

  //index.axr (keep XPath-like syntax for selectors, use HSS-like syntax for style)
  {
     select:"books[0]/title",
     style: {
              color:"#ff0",
              background: { ... }
            }
  }
    

Though I think I prefer the XML/XPath stack.

Those were my few cents. Good luck with your project!