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.

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.

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.

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.

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.

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.

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

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

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.

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.

C++ is also less cross-platform in this sense because to support multiple platforms, you will have to support compilation across target platforms and handle the variety of plugin APIs available for those platforms. And on iOS, your stuff won't work at all because it's Javascript or the highway if you want to run in Safari. (I guess you could ship your own browser on the App Store, but I suspect you'd run into rule hassles.) Maybe you could use Native Client, but in that case you will need to ship native client binaries for each CPU architecture and you'll only work inside Chrome.

Attempting to entirely supplant the browser's rendering engine with yours in a plugin is also a hopelessly shortsighted move. You'll be throwing out all the hardware acceleration and advanced layout logic provided by modern browsers. Just rendering text is complex enough to require multiple full-time salaried engineers, and you will have to bear that burden if you will ever be compatible with HTML/CSS, because international text is important.

Build a prototype using JavaScript, HTML, and Canvas/SVG where needed. Put it in front of people. Let web designers and programmers play with it. If they can play with it, they'll find reasons to love it. Once you have web designers and programmers who love your actual product, you have a path to success.

Isn't that what RDFa is? Which has to advantages over HSS already: 1) it's designed to extend HTML while remaining compatible with older browsers and 2) It's already used by big sites and understood by Google.