
AXR: Arbitrary XML Rendering - ryannielsen
http://axr.vg
======
simonw
This absolutely will not go anywhere if it requires either a browser plugin or
buy-in from browser vendors. I'd suggest creating a JavaScript library that
can read the XML/HSS format and render them as HTML/CSS/SVG.

~~~
timdorr
Even better: Why not build on and extend the work that SASS/LESS have already
started?

~~~
matzipan
Well, SASS/LESS are just supersets of CSS. They aren't designed to do anything
else but what is compilable into actual CSS. I'm not sure how a feature like
filters or event triggers would actually work in this language.

We will definetely have a look at those.

------
agumonkey
I'll probably get flamed for this, but I often fall into wishing there was xml
ontologies + formatting rules. Skipping the HTML layer entirely. Be model-
centric instead of html centric.

    
    
      "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: ... }
    

I'm sure it's been done many times before but I've never read about why it
failed.

~~~
matzipan
That's exactly what we have in mind. The thing is <div> and <h1> are just
presentation tags, when, in fact, you are styling them with css too.

In hss object model, everything is a box. How it is styled and how it behaves
it's up to you. There will be an HSS framework, which will provide basic
capabilities like heading, dropdown, radio. We are proposing a syntax like
order { isA: heading }

~~~
agumonkey
Maybe in the future the box model will be one `dsl` in a larger rendering
system that borrows from stack based 2d, matrix based 3d. So you can use what
fits best when it fits best.

edit : Traces of this are in place, js based advanced layouts , webgl, canvas.
It's just non composable right now.

------
Tloewald
CSS and HTML have quite a few baked in flaws that are unlikely to get fixed
anytime soon, but there are workarounds. Most of the benefits of AXR seem to
be similar to using XML, XSL, and LESS, which has the extra huge advantage of
running in every major browser today. I think writing a good XML, XSL, LESS
tool chain would be more practical, but I admire your spunk.

~~~
romaniv
_CSS and HTML have quite a few baked in flaws that are unlikely to get fixed
anytime soon, but there are workarounds._

That's the problem. 90% of modern web design is all about workarounds. Those
workarounds became more important than core technologies, because the latter
no longer capture typical use cases of the web.

~~~
Tloewald
Actually a lot of modern web design is about working around the virtues of
HTML, such as users controlling presentation and intentional markup.

My point is that there's no workaround for "doesn't work in your browser".

------
marcusf
I'm sorry to be skeptical, but this seems both redundant and pie-in-the-sky.

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.

~~~
matzipan
Fortunately, our team is made up of both designers and programmers. In fact,
our lead programmer is also our lead designer (small team).

It is true, you can make really awesome apps with HTML5/CSS. We, ourselves,
are doing the same thing.

We are bringing to attention some new concepts that we think have not been
taken into acount into HTML simply because HTML features have just been
stacked together and it HTML simply evolved into something it was not intended
to.

On the other hand, the HTML5 completion date has been announced as 2020. Do
you really think HTML5 will still suit the needs of the web then? It should
probably be HTML7.

~~~
quink
> HTML5 completion date has been announced as 2020

CSS2.1 became a W3C Recommendation on 7 June 2011. People have been using the
HTML5 doctype for years now, never mind quite a few of the features. Arguing
that the W3C is slow to standardise things is preaching to the choir, but CSS3
or HTML5 not being standards has had no impact on the ecosystem that's been
using -moz-border-radius since Firefox 1.0. (that's 8 years ago. There are web
designers that aren't twice that age out there).

Also, sorry to be that person, but isn't SASS/SCSS (edit: and calc()) "good
enough"™. The problem with XML files not rendering nicely in the browser is
not anywhere near as important to developers as XML not supporting a way of
plugging in JavaScript as HTML does with <script>.

Edit: And lastly, what's wrong with XSL? It's got XPath, which as much as
people love to dump on it, is not that bad. And you get HTML with all the
bells and whistles as an output.

~~~
TazeTSchnitzel
>using -moz-border-radius since Firefox 1.0. (that's 8 years ago. There are
web designers that aren't twice that age out there).

...web designers who had no idea -moz-border-radius existed until recently.
Thanks, W3Schools!

------
agwa
I wish they would use XPath (or at least a subset) for their selectors. They
could probably easily use an existing implementation, and they would get
filters for free in the form of predicates. This would avoid creating yet
another XML selector language.

------
PommeDeTerre
Why do we need two different syntaxes for representing trees? Both XML and
their so-called "HSS" are redundant. S-expressions are a much cleaner syntax,
and can be used to represent both the "markup" and the "styling" in this case.

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

~~~
matzipan
Just to make it clear, HSS is directly replacing CSS. No markup there.

You are missing the point, unfortuantely, the whole idea of the project is to
sepparate the data from the presentation. Mixing them together would be pretty
similar to what HTML was in 2005. Not desirable.

~~~
weavejester
I don't believe PommeDeTerre is saying that semantic information needs to be
mixed with presentation information. He or she is asking why you have two
different syntaxes when all you're doing in both cases is representing a
nested tree.

For example, you could have your data structure as:

    
    
        (books (book (title "Little Schemer")))
    

And then define your presentation as:

    
    
        (books (book (title (:color "ff6666"))))
    

I'm not saying that this is necessarily the best representation, but it's more
consistent and simpler for a machine to parse than XML/HSS.

------
d4n3
Your plan is to make a common library that all browser vendors will use and
you will control?

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?

~~~
matzipan
Hey, Rome wasn't built in a day. Right now it's at a prototype/concept level.
It will take a couple of years until we have an actual usable product.

Thinking you have no chances in succeeding will only get you not even trying.

------
toyg
It's a very bold concept, but without buy-in from at least one major browser
(i.e. not Opera) it has no chance to ever become mainstream. Browser plugins
are where interesting technologies go to die.

~~~
matzipan
Well, this is really what our plan really looks like. But we really have no
idea how to do that.

~~~
alexchamberlain
Fork Chromium.

~~~
matzipan
Seems reasonable. Never thought about that. Thanks.

------
dylanhassinger
If one major browser started supporting AXR, others would follow.

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?

~~~
matzipan
It's not about webkit, as we're planning to actually replace webkit.

I think this kind of action coming from somewone like microsoft would be seen
as another proprietary software imposed to the web.

We have not tried yet, as we did not have anything relevant to work with. We
really have no idea how we can do that. Maybe you can help?

------
edgarvm
in a very different context something slighty close to it already exists: QML

------
breckinloggins
Why can't we go even deeper? If we want to replace the existing HTML/CSS/JS
situation with something better, it would suck to replace them with
technologies that have the same shortcomings.

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.

~~~
SkyMarshal
I've wondered about this too. Websites consist of such a hodgepodge of html
pages, css pages, javascripts, embedded css and js, images, and other
resources, and we have to use all sorts of kluges to minimize requests and
other artifacts of this design.

It would be interesting for browsers to implement an HTTP bytecode vm, and web
pages are made in the usual way but compiled to a single binary blob, which is
then downloaded to browser and run in the vm, and from that point on the only
thing passing over the wires would be pure data, in JSON, XML, media streams,
etc.

HTML5 Rich Web App architecture is heading in that direction, in which the
logic is client side and the app server is an API endpoint, but the code for
the website is still that hodgepodge.

~~~
simonw
"It would be interesting for browsers to implement an HTTP bytecode vm, and
web pages are made in the usual way but compiled to a single binary blob,
which is then downloaded to browser and run in the vm" - that's essentially
how Opera Mini works - Opera run a big farm of proxies which load pages,
recompile them in to a binary blob and serve that down to Opera Mini running
on a phone to be rendered.

~~~
matzipan
Opera Mini is wrong in so many ways! And few people know about this proxying.

------
optymizer
Instead of creating yet another way of defining a tree structure (HSS), why
not do this:

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>
    
    

You can still have your hierarchy, if you prefer, instead of the 'select'
above:

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

See? No need for an HSS parser. That's really what "reinventing the wheel"
warns against.

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: { ... }
                }
      }
        

This would allow for some interesting (maybe faster?) interactions between
Javascript, style and object model.

Though I think I prefer the XML/XPath stack.

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

~~~
matzipan
How would you implement class selectors and filter features in this XML based
styling language.

~~~
optymizer
I'm not entirely sure what you're referring to as "class selectors". If it's
the ability to select elements based on the value of the 'style' attribute,
then it would be something along the lines of:

    
    
      //book[@style='someclass']
    

If that's the case, then that's not what I'd want to do, if I could improve
things (even though it would still be possible to do so). Here, the model is
coupled with the style, because your model refers to a 'class'. Why would it
refer to a class in the presentation? It's essentially saying: "render me this
way". Your model should worry about the data, not the style. Why not decouple
them, by letting the stylesheet select elements in the model, not the other
way around?

    
    
      //book[filter by some property or id]
    

Presumably, if there's a class for a <book>, then there's something that makes
that <book> different from other elements, which warranted a different style
class. In that case, instead of assigning a 'class', just assign an ID or use
some other attributes (or child elements) to figure out the uniqueness.

If by 'class selectors' you're referring to the collection of styling
attributes and the way those would be filtered and overridden, then you could
define something like:

    
    
      <axr:style id='style1'>
        <color>#ff0</color>
        <background color="purple"/>
      </axr:style>
    
      
      <axr:style>
        <axr:include ref='style1'/>
        <color>#000</color> <!-- override the color -->
      </axr:style>
    
    

Filtering/overriding qualities are similar to XSL's xsl:import / xsl:include.
The @ref could be @href instead, and could refer to elements in other
documents (a-la XPointer/XInclude):

    
    
      <axr:include href="../foo.axr#style1"/>
    

Clearly, this requires more thought than I've given it while writing the
comment, but I hope this is what you were asking about.

~~~
matzipan
This seems a pretty interesting idea indeed.

------
sohn
This is completely superfluous. This is NOT the path the web needs to take.

~~~
alexchamberlain
For what reasons?

~~~
reiz
I am against Browser Plugins. If it requires a plugin, I will not use it. I
agree that the current CSS and HTML is not the best. There are many
workarounds. But I believe in evolution. I think we have to improve CSS and
HTML. And the people are creating Frameworks to solve problems and to hide
workarounds. What works actually pretty good. It is not perfect, but it works.
I think AXR is important. If people are contributing to AXR and starting to
using it, that shows that something is not OK with CSS and HTML. And that
could lead to faster improvements in CSS and HTML.

~~~
matzipan
We are still thinking on this. Last time we talked about actually forking
chromium, to prove it's do-able.

