6 ms·

AXR: A better(?) alternative to HTML+CSS

86 points by janv 15y ago

lovskogen 15y ago
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 15y ago
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 15y ago
  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 15y ago
    What do you mean by reparenting an element if not the nesting example given on the SASS homepage?
    - janv 15y ago
      In presentation - http://www.slideshare.net/veosotano/axr-presentation-betabeers-english http://www.slideshare.net/veosotano/axr-presentation-betabee... - slides 12 and 13, including new elements creation (http://axr.vg/spec/chapter/55 http://axr.vg/spec/chapter/55). Didn't find anything on parent property in spec, though. Nesting is also planned (slide 15)
      - veosotano 15y ago
        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... :)
- politician 15y ago
  The author hasn't suggested XML for presentation, but rather for content.
  - drdaeman 15y ago
    IMHO, XML is terrible for both. 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).
ahrens 15y ago
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 15y ago
  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.
shimonamit 15y ago
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 15y ago
  The presentation on the front page has comparisons.
  - shimonamit 15y ago
    I had to scroll 12 slides until I reached the first snippet.
kevingadd 15y ago
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 15y ago
  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...
- extension 15y ago
  It's a nice idea, but I doubt any JS+Canvas or JS+SVG implementations are fast and memory efficient enough to implement this. They probably don't have enough low level access to UI or network APIs either.
bxr 15y ago
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 15y ago
  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.
pornel 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.
veosotano 15y ago
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 http://www.firebreath.org), so hopefully this won't be too difficult :) Cheers, Miro
deleted 15y ago
[deleted]
nubela 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
        > Why would anyone do that? Business model of proprietary software, return on investment on lock-in of customers.
    - extension 15y ago
tomelders 15y ago
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.
martingordon 15y ago
I have to have Flash installed to see the slide deck that actually shows code samples? So much for "the web done right".
scythe 15y ago
>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 15y ago
  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 ;)
csomar 15y ago
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 15y ago
  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 15y ago
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 15y ago
  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.
berserkpi 15y ago
The slide deck is flash... Mmmm... Are u being serious when u say "web done right"?...
Joeri 15y ago
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 15y ago
  You're rising some interesting questions. Mind posing them on the mailing list? That would be awesome :D Cheers.
kennystone 15y ago
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 15y ago
  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.
donohoe 15y ago
Wait - we're going back to XML again?
icebraining 15y ago
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 15y ago
  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?
  - deleted 15y ago
    [deleted]
  - icebraining 15y ago
    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.
hallmark 15y ago
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.

86 points by janv 15y ago

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 15y ago

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 15y ago
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 15y ago
  What do you mean by reparenting an element if not the nesting example given on the SASS homepage?
  - janv 15y ago
    In presentation - http://www.slideshare.net/veosotano/axr-presentation-betabeers-english http://www.slideshare.net/veosotano/axr-presentation-betabee... - slides 12 and 13, including new elements creation (http://axr.vg/spec/chapter/55 http://axr.vg/spec/chapter/55). Didn't find anything on parent property in spec, though. Nesting is also planned (slide 15)
    - veosotano 15y ago
      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... :)
politician 15y ago
The author hasn't suggested XML for presentation, but rather for content.
- drdaeman 15y ago
  IMHO, XML is terrible for both. 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).

ahrens 15y ago

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 15y ago
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.

shimonamit 15y ago

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 15y ago
The presentation on the front page has comparisons.
- shimonamit 15y ago
  I had to scroll 12 slides until I reached the first snippet.

kevingadd 15y ago

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 15y ago
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...
extension 15y ago
It's a nice idea, but I doubt any JS+Canvas or JS+SVG implementations are fast and memory efficient enough to implement this. They probably don't have enough low level access to UI or network APIs either.

bxr 15y ago

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 15y ago
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.

pornel 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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.

veosotano 15y ago

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 http://www.firebreath.org), so hopefully this won't be too difficult :) Cheers, Miro

deleted 15y ago

[deleted]

nubela 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      > Why would anyone do that? Business model of proprietary software, return on investment on lock-in of customers.
  - extension 15y ago

tomelders 15y ago

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.

martingordon 15y ago

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

scythe 15y ago

>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 15y ago
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 ;)

csomar 15y ago

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 15y ago
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 15y ago

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 15y ago
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.

berserkpi 15y ago

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

Joeri 15y ago

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 15y ago
You're rising some interesting questions. Mind posing them on the mailing list? That would be awesome :D Cheers.

kennystone 15y ago

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 15y ago
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.

donohoe 15y ago

Wait - we're going back to XML again?

icebraining 15y ago

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 15y ago
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?
- deleted 15y ago
  [deleted]
- icebraining 15y ago
  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.

hallmark 15y ago

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.