veosotano

What I wanted to put in the final license was something along the lines of "an implementation of the specification is only granted the permission to use the technology if at the time of being released (out of beta) it is absolutely compliant with the specification, obtaining a 100% score on all the tests released by the official AXR community", to be able to ensure that we don't end up in the same situation as now, in case other implementations appear.

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?

I've looked at it and it seems to share goals with AXR, but how good is it for semantics, accessibility and backwards-compatibility? Those are quite essential requirements.

The people that I usually see getting wowed are web designers and devs, that know the pains of dealing with all those issues that this project is trying to solve. I don't know your background, but if you don't do CSS you probably don't know or care about all the troubles that one has to go through to get your site working correctly across all browsers, laying out your page (most apparent in fluid designs, or with dynamic content from a database), etc.

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

Well for starters its open source instead of proprietary. I think that already deserves some respect on its own.

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.

The goals of the project are way beyond just making "A as wide as B is high". That is just a drop in the ocean. Once we do effects (such as shadows, blur, noise, etc) and more advanced processing we'll need as much performance as we can.

Sorry about that. It's not fully fleshed out yet. Are you interested in helping us figure out how to make the reparenting syntax as nice as possible? If so, I think the mailing list would be the best place for that... :)

You're rising some interesting questions. Mind posing them on the mailing list? That would be awesome :D Cheers.

The plan is to make the rendering engine an auto-updateable library, that's independent of the browser's release schedule. Thus, users would stay current faster.

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.

I know we don't have anything to show right now, I didn't put this on HNews... we're still about 2 months from actually doing something like a public release, so sorry about that. But be assured that we'll have something to play with pretty soon :D

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 ;)

Suggestions on how to improve the phrasing of the website are always welcome :D

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 ;)

The reason is because that's one of the main pieces of the project. Providing a library that browsers can USE, not IMPLEMENT.

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

So can you do "myElement { alignY: 50% }" or something like that to automatically center vertically in your browser?

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

It does indeed use JavaScript. Sorry about not being more clear about it in the spec, but that's a part we're still working on.

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.

You're right: HTML is going to stay with us for a long, long time. This is not about eliminating it, but to try something new as an alternative.

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

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