I don't understand why they are implementing the prototype in C++. If you built it in JavaScript, any modern browser could load their alternative markup and render it through some sort of fallback (I would expect HTML5+CSS+Canvas+SVG all put together provide enough functionality to render content expressed in their new language(s)).

Building it in C++ basically guarantees that nobody will be able to use it, ever, because it provides no support for older browsers and no support for older HTML-oriented technology like search engine spiders.

Worse is better.

Sorry, but HTML isn't going anywhere. XML had its chance — full support from W3C and implementations in all-but-one browsers for a decade now. text/html parsers survived that.

I don't think you can convince all browser vendors to bet on XML again. They all opposed XHTML2. W3C tried to push XHTML2 without them and ended up making HTML even stronger.

XML with vector shapes? We've got SVG. It may not be perfect, but has tools and implementations.

Easier CSS layouts? Flex box, grids and calc() are around the corner. They'll be usable sooner than HSS, and kill the project by being good enough.

Too many of the comments here are implying that "It's too hard, there's obstacles in the way, so don't bother". Which is pretty disappointing.

To a large extent, I agree with that sentiment. There may be obstacles, more human than technical, but under no circumstances should that ever be an excuse for not even trying. All the best, and I like the cut of your jib.

Show me the CODE! Where is it???

If you are trying to revolutionize and disrupt existing languages/syntaxes, show how yours is better! Side-by-side on the front page is best. Look at CoffeeScript's site.

I was expecting something different. I thought this was going to contain solutions for building web apps at scale, but it's basically a way to build plain old websites with a somewhat nicer and more maintainable syntax.

Some things that I want to see solutions for:

* Implementing richer controls that can behave as if they are native to the platform (e.g. building a better date picker that is fully encapsulated from the perspective of the developer)

* Dealing with styling at scale (tens of thousands of lines, up to a dozen levels of element nesting)

* Encapsulating application modules so they are incapable of conflicting with other application modules (in structure, behavior and styling), and can have a separate lifecycle from the page they are loaded into.

To me those are the real problems in building web apps at scale, and I was expecting to see solutions for these.

I have to have Flash installed to see the slide deck that actually shows code samples? So much for "the web done right".

Won't we have the same problem once it's implemented in browsers? They implement different things, in different ways. And XML does induce a lot of overhead compared to other ways to share data. I'm not against changing the way we code, but it has to be well thought out.

I don't think AXR is the solution to rendering engines not keeping the same pace. It's hard to have competition and at the same time wish I didn't have to check my CSS in Trident, Gecko, Presto and Webkit.

I don't think XML is any better than HTML for presentation. In fact, HAML is way better, and much more powerful. In the same way I don't see why to use HSS when we have SASS/SCSS, Jade, Less...

The terms to use and redistribute all source code for the AXR project WILL CHANGE in the future, since it will include clauses not included in any of the available free software licenses, mostly in aspects that will ensure the integrity of AXR as a web publishing platform.

This is worrying. What exactly are you expecting to put in such clauses? Anything more restrictive than Apache v2 (like the current license, GPL) is 100% sure to rule out inclusion in some browsers.

Hi there! My name is Miro Keller, and I'm the founder of AXR, so I'll probably be the best person to answer any questions you guys may have. So feel free to ask me anything about this project :)

I'll try to answer all questions posed here, step by step:

@shimonamit: The code is not the only part that's important here, it's just one piece of the puzzle. So how would you go about to determine what part of the code to show, and at the same time try to convey the general idea to the visitors, without overwhelming them with too much information at once?

If you click on the "enter the site" button you'll see the spec, where there's plenty of code for you to read through :)

@ahrens: One of the most important points about the project it's that it would be the same library used by the browsers, they wouldn't reimplement it. And to account for syntax variations in future versions, there is a versioning system, where the author of the document declares which one it is targeting. Thus, the rendering engine will know what the author actually wanted to say and interpret it accordingly.

What other ways of sharing data do you mean? We are open to suggestions about what technologies to use, we just want it to be great. Keep in mind that there are a couple of requirements, all of which are achieved with XML, such as:

- It needs a way to be semantic, so that common things on the internet must be representable, such as products, events, flight reservations, etc. XML solves this with namespaces. - It needs to be able to provide a way to show documents written in that language in current browsers using a plug-in. XML solves that with XSLT (there will be a standard .xls file for easy backwards compatibility). - It should be able to be just uploaded on an FTP server by the average author, just as HTML, without installing server-side software or messing around with settings. - It should be easy to write for authors.

So, again, we are open for suggestions, but keep in mind those requirements. If any other one you know of fits the bill, we would love to hear about it!

@drKarl You're missing the point. XML is used to represent the structure of your data, not the presentation. That's what HSS is for.

On the other hand, with all those other languages you mentioned you have the problem that you'll always end with plain old CSS. Therefore you may get an easier syntax, but you still have all the problems associated with CSS: browser fragmentation, static syntax (you can't do "100%-50px" or "ref(height of myOtherElement)" ), no vector shapes support in the language itself (SVG doesn't count), etc.

@lovskogen Well AXR tries to be an alternative platform to HTML+CSS, not to replace it. It would still face much competition from that and Flash, Silverlight, or any other RIA out there....

The proposed solution is that the implementation is provided by the project itself, so that the rendering engine would be always the same. They could still differentiate themselves by providing unique UI, history management, social media integration, developer tools, etc. The part that we want to be the same, and only that part, would be the same. Of course, there is more to it than this, such as auto updating the engine independently from the browser, versioning system for stylesheets, etc, but that would be too in depth to discuss it here :)

@kevingadd Basically the main reason we opted for C++ was performance and cross-platform compatibility. Doing it in JavaScript would make it slow as hell. But hey, we would love to see more ideas of how this could be done. At the end of the day this is just a prototype, it is meant to explore ideas and see if and how this can be done at all.

You're wrong about nobody able to use it, since one of the main goals of this project is to support older browsers to increase chances of adoption. That's why there is a step-gap measure in the plan to create a wrapper that will use the library as a browser plug-in, so that it can be installed anywhere where there is a NPAPI or ActiveX interface (in IE). We already spotted a framework that will assist us in this (http://www.firebreath.org), so hopefully this won't be too difficult :)

Cheers, Miro

If you are going to start from scratch, why would you ever use XML? XML violates so many things we know to be good, including the essential lisp idea of 'data is code' (which json does OK), not to mention it's ugly, hard to read, and makes for arbitrary patterns.

>HSS is a language based on CSS, but offers many more advanced features, such as object orientation, rule nesting, expressions, references to other objects, modularization (code reuse), etc.

Ew. This is an advertisement? Elegance is usually achieved when you hit a maximum of capabilities with a minimum of explicitly defined features. The last thing you want is so many different constructs that when someone reads your code they have to keep a reference manual handy.

Granted, I haven't worked my way through the spec, but maybe there's a better way to phrase that sentence that doesn't evoke memories of C++.

On an emotional level, XML is annoying.

XML is strict and unforgiving - great for validation, tools, and stuffing into SOAP envelopes. OTOH, for all of HTML's warts, it is flexible and forgiving to humans. Great developers and designers want to be happy working with their creations, and WYSIWYG tools often do not fit the process. So when you are forced to work with markup by hand, the perceived friendliness and ease of the markup language is significant.

In the end, to each their own. But programming languages are a popularity contest. Especially new ones.

Okay. Assuming I liked it and it really works. This is going to make websites, no? How is this going to display on the browsers that people are using? Is my site going to be consistent across them?

Have you guys looked into Qt's QML? It is already there and addresses the same problems that you are trying to. All it needs is some more publicity.

in my django stack, i already have shpaml+sass+templating. this by itself, already fulfills all my html+css needs, and it makes it retardedly easy to work with. why would i need to change something that is already working?

The slide deck is flash... Mmmm... Are u being serious when u say "web done right"?...

Wait - we're going back to XML again?

I'm looking forward to seeing where this goes. It may not be the tool that replaces the current html/css set, it doesn't even have any mention of how javascript fits in, but its very encouraging to see that it is getting worked on. We do need to replace them, and playing with things like axr is a start.

Our current web programming stack is a depressing, ugly hacked together kludge with painfully limited capabilities, even how HTTP fits in needs to be examined, it has its place but it can't remain the only option. Websockets are a solution to a problem that doesn't have to exist. I have nothing against the fact that we're wedging more and more into technology that it was never designed for, but the seams have been showing for quite some time how.