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.

Whether even one of the major browsers will support it is the question, and what the pages will look like in other browsers (if there's any fallback) remains to be seen...

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.

It's not XML with vector shapes, that's exactly what SVG is. Vector shapes would live all inside HSS, where you could reuse them, style them, give them flexible sizes, apply effects, etc...

Once flexbox, grids and calc come out as official specs, you'll still have to wait until all browsers implements them, and then wait again until enough users update. You'll probably have to do an old-style layout as well anyway, because there are always users with older browsers out there, and it's not as easy as with rounded corners, where if they aren't there it doesn't matter. This would break your entire page...

How would the situation be any different for AXR?

On the other hand, there will be a versioning system, so that authors can specify what version of the technology they are targeting. So if the spec changes, compatibility modules can be created akin to how Adobe apps open documents differently if they are CS3 or CS5 documents, interpreting them according to what version they are.

Usually, layers can be built with new features, where only the very basic aspects of your design require a certain feature set, while others can be optional. In some scenarios, the user will have an outdated system and the author has REQUIRED a higher version than what is installed. Then a built-in prompt to update could be displayed, maybe with an option to view anyways, with the knowledge that it may render incorrectly.

Long story short, there are many things that can be done, and we certainly will learn a lot along the way, but I think we should definitely try.

Then, this is based on doing websites in the web standards spirit of using plain-text files, where multiple components are linked together, and having the semantic content (XML) separated from the presentation (HSS).

I mean, we like the concept of HTML+CSS, but we would like to see many of its flaws and shortcomings corrected.

Flexbox is already in that bundle of browsers (and it rocks :)

calc is in IE9+ and Firefox.

Chrome and Firefox are in autoupdating very short release cycles (or, at least, Firefox is getting there rapidly).

I think the ideas in HSS are interesting, and I understand the motivation. But, the world is rapidly changing. Not everyone is going to be able to support the latest standards in their apps, but I think we're moving past the point where most developers will need to support a 10 year old browser. Time will tell!

(obDisclaimer: I'm a Mozillian)

FTFY.

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.

Indeed. This faces an uphill battle to get critical mass and once browser makers decide to support it natively there's going to be pressure to roll it into the standards process.

I believe that point of AXR is to replace this underlying base, with something more suitable for web applications. You could still use a metalanguage on top of it (maybe with some tweaking) - you can write XML using HAML anyway.

Content is best represented with some mixture of properly-chosen DSLs. For example, Markdown-like language for texts, CSV-like language for tabular data, and so on.

There are too many various type of "content", so if you try to use lowest common denominator (like XML is) you: 1) lack the expression and have to type/generate lot of pointless code and 2) start mixing various types of content in a wrong ways (like tables for layouts, padding with spaces, CSS sprites etc).

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.

This obviously needs to be studied and discussed to great extent, but I put the warning in the current licensing text to not have anyone think that it will be the final license...

What do you think, would you agree with that idea? If not, why not?

If it's the license of the code, then it's not GPL compatible and hence Firefox can't use it, since they tri-license GPL, LGPL and MPL.

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

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.

The framework I mentioned (Firebreath) already provides an abstraction layer for those APIs. I agree iOS will be the hardest nut to crack, but since this is a long-term project I'm pretty sure we'll be able to work something out (either by Apple's blessing, by providing an HTML fallback mechanism or something else) when the time is right. Right now we're just trying to figure out if it is at all possible to create a better technology...

Why do you think that you'd throw out hardware acceleration? The latest Flash has hw accelerated video, for example, so not at all impossible. Advanced layout logic? Don't make me laugh... do you mean floats? Or inline-blocks? I've had my share of trouble using theme (I'm a web designer with many years of experience...). Layout is exactly one thing that we're trying to do better! And to use flexbox and all the other new layout stuff reliably you'll still have to wait a couple of years, I think. Then you'll probably still need to create a conventional layout for older clients for much time ahead...

And for the text rendering, there are plenty of open source libraries out there, we won't reinvent the universe from scratch just to make an apple pie.

As I said... the prototype will soon be available for anyone to try out so web designers and programmers will be able to play with it as a browser plug-in, this is not just some crazy random idea ;)

I dont think that's going to happen anytime soon.

But I agree that JavaScript is the way to go with this. The prize is not that high to justify such a steep adoption curve. I mean "make A as wide as B is high" can be accomplished in javascript today.

And again, we would love to hear about how we can market ourselves better, we are all ears!

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.

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

I'd love to hear if, once you've read through the spec you still feel that the features are perceivably as complex as C++... I think they feel very naturally into the language, but then again, I designed it, so your mileage may vary ;)

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.

Or can you do "100% - ref(width of sideColumns)" to create two fixed-width and one fluid column in the middle?

Or can you rely on having exactly the same interpretation of your code across all browsers?

...

I guess you are looking at just a limited subset of what AXR is, mainly the syntax features that are similar to SASS and the like, while ignoring all the other problems it solves.

Of course we can do websites now, but no one says it's easy. Just think at all the productivity gains and improved user experience... !

Why would anyone do that? That's WAY too much work just for fucking something up just for the heck of it.

Business model of proprietary software, return on investment on lock-in of customers.

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.

It will feature a completely new DOM, integrating the properties of the HSS side and the JS ones all into one. Functions and code will be executed by setting something like this:

myElement

{

   behavior: @click {

      action: @javascript {"

         //your code goes here

      "}

   };

But that's not the usual way one would use this, instead one would do:

//define the click handler

@click myClickHandler {

   action: @javascript {"

      //your code goes here

   "}

//assign the handler to your object

myElement { behavior: myClickHandler; }

This way, you can see how it will be reusable, and your javascript can be assigned inside of any preset that you may create and apply, instead of selecting the element again from inside javascript in another file.