
AXR: A better(?) alternative to HTML+CSS - janv
http://axr.vg/
======
kevingadd
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.

~~~
stephen_g
It's designed as a library that browsers would use to render the content, as
far as I can tell. So C++ is fairly sensible in that respect.

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

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

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

~~~
mambodog
_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_

How would the situation be any different for AXR?

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

~~~
chc
This sounds like something we already have. I don't want this to sound
confrontational, since I know the F-word is viewed as kind of "dirty" around
here, but how is what you're proposing substantially different from Flash?

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

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

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

~~~
OliverM
The presentation on the front page has comparisons.

~~~
shimonamit
I had to scroll 12 slides until I reached the first snippet.

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

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

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

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

~~~
edoloughlin
_Won't we have the same problem once it's implemented in browsers?_

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.

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

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

~~~
janv
These abstract metalanguages are still somewhat limited by the underlying base
of HTML and CSS. Some things simply can't be accomplished with CSS, no matter
how many SASS macros you write (e.g. reparent an element), or you'll just end
up with lot of code to do tasks which would be simple with HSS.

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.

~~~
Joeri
What do you mean by reparenting an element if not the nesting example given on
the SASS homepage?

~~~
janv
In presentation - [http://www.slideshare.net/veosotano/axr-presentation-
betabee...](http://www.slideshare.net/veosotano/axr-presentation-betabeers-
english) \- slides 12 and 13, including new elements creation
(<http://axr.vg/spec/chapter/55>). Didn't find anything on parent property in
spec, though. Nesting is also planned (slide 15)

~~~
veosotano
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... :)

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

~~~
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?

~~~
icebraining
I didn't understand: that's the copyright license of the code, or a license of
the spec?

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.

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

~~~
kevingadd
Performance doesn't matter if nobody can use it, and right now nobody can use
it. By the time you have a working C++ implementation, for all you know v8 and
SpiderMonkey's optimizers will be generating code just as fast as your C++.
You're allowing an engineer's natural love of premature optimization to
distract you from actually getting your product in front of people.

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.

~~~
tambourine_man
_By the time you have a working C++ implementation, for all you know v8 and
SpiderMonkey's optimizers will be generating code just as fast as your C++._

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.

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

~~~
tambourine_man
I think you need better marketing, then. I glanced over the page and didn't
see anything that “wowed” me. I think that's needed to justify the effort.

~~~
veosotano
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!

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

~~~
extension
The one thing XML is great it, as the name suggests, is _markup_. And I am in
favor of marked up text continuing as the basic model for content in any next
generation web platform.

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

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

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

------
csomar
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?

~~~
Sandman
As they say on their front page: "The part of the various browsers we want to
NOT be different, the rendering engine, would be shared among all of the
browsers".

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

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

------
nubela
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?

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

~~~
FlowerPower
Why do you think AXR would have the same interpretation across all browsers?
Dont you think somone _cough_ will make their own implementation that fucks up
the rendering/layouting just for the heck of it? _cough_

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

~~~
FlowerPower
> Why would anyone do that?

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

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

------
donohoe
Wait - we're going back to XML again?

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

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

