AXR: Arbitrary XML Rendering

by ryannielsen • 14 years ago

48 67 14 years ago

marcusf• 14 years ago

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.

matzipan24• 14 years ago

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• 14 years ago

> 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.

matzipan24• 14 years ago

Yeah, but do you really feel like this W3C standardising process is really benefiting anybody? I know creating a standard involves a lot of work, but I don't like it.

SASS/SCSS has nothing to do with HSS. SASS compiles intro regular CSS. HSS is standalone and can only be run in AXR supporting environments.

weavejester6• 14 years ago

The 2022 date is no longer relevant, see: http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2...

Whilst there may very well be many advantages to your approach, please don't misrepresent the competition.

sohn• 14 years ago

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

alexchamberlain4• 14 years ago

For what reasons?

reiz• 14 years ago

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.

PommeDeTerre• 14 years ago

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.

matzipan24• 14 years ago

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.

CodeMage2• 14 years ago

I believe you're missing his point: he said unify the syntax, not mix the data with the presentation.

matzipan24• 14 years ago

Oh, I totally understand. Thanks CodeMage. Sorry for the misunderstanding.

XML is a widely-used data interchange format. It is well known and used. It's focus is the actual content.

The syntax of HSS/CSS focuses on attributes. Makes for a perfect use in this case.

weavejester6• 14 years ago

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.

alexchamberlain4• 14 years ago

Was that sarcastic? S-expressions aren't readable.

Furthermore, we used to have a mess of a language that combined style and markup. We moved onto separating the 2, so we could develop more flexible websites.

CodeMage2• 14 years ago

Okay, I don't get it: why does everyone assume that having the same syntax for trees automatically means you have to put everything in the same tree?

spacemanaki• 14 years ago

> S-expressions aren't readable.

This isn't exactly an objective truth. Personally, I find them more readable than XML or JSON.

toyg• 14 years ago

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.

matzipan24• 14 years ago

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

alexchamberlain4• 14 years ago

Fork Chromium.

simonw2• 14 years ago

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.

timdorr2• 14 years ago

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

matzipan24• 14 years ago

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.

romaniv2• 14 years ago

That might be a good solution for transition period, but in the long run, another custom rendering engines in JS is the last thing the web needs right now. It needs a practical, declarative and semantic way of creating modern websites. So these guys are thinking in the right direction, even if what they propose is not perfect.

Tloewald3• 14 years ago

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.

romaniv2• 14 years ago

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.

Tloewald3• 14 years ago

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

agwa• 14 years ago

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.

breckinloggins2• 14 years ago

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.

matzipan24• 14 years ago

Wow. This is mindblowing. At the rate at which the WWW is growing, it really needs something like this, some sort of internet-transferred bytecode.

Wonder if anyone thought of that before. And if so, what stopped them?

optymizer4• 14 years ago

Wouldn't this be possible with NaCl ?

breckinloggins2• 14 years ago

Absolutely

SkyMarshal• 14 years ago

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.

simonw2• 14 years ago

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

Tloewald3• 14 years ago

So... SGML?

d4n3• 14 years ago

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?

matzipan24• 14 years ago

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.

agumonkey2• 14 years ago

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.

matzipan24• 14 years ago

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 }

agumonkey2• 14 years ago

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.

edgarvm• 14 years ago

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

optymizer4• 14 years ago

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!

matzipan24• 14 years ago

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

optymizer4• 14 years ago

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.

dylanhassinger• 14 years ago

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?

matzipan24• 14 years ago

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?

AXR: Arbitrary XML Rendering

Related Stories