7 ms·

AXR: Arbitrary XML Rendering

48 points by ryannielsen 14y ago

marcusf 14y ago
I'm sorry to be skeptical, but this seems both redundant and pie-in-the-sky. In the presentation they say they're looking for "Computer Science Engineers" make me think this is a bunch of aggravated designers. On the other hand, there is code on GitHub. But it's C++, which makes it feel like this is a bunch of aggravated developers who can't stand having to do HTML or CSS and want to do "real engineering" (usually defined as non-webapps). This seems to pop up every other month. All the while people keep making awesome web sites, applications and libraries with the stack we have today. A small group of people is usually all it takes to change something, on the other hand, I don't think is change people want or need. That said, I wish them all the best.
- matzipan 14y ago
  Fortunately, our team is made up of both designers and programmers. In fact, our lead programmer is also our lead designer (small team). It is true, you can make really awesome apps with HTML5/CSS. We, ourselves, are doing the same thing. We are bringing to attention some new concepts that we think have not been taken into acount into HTML simply because HTML features have just been stacked together and it HTML simply evolved into something it was not intended to. On the other hand, the HTML5 completion date has been announced as 2020. Do you really think HTML5 will still suit the needs of the web then? It should probably be HTML7.
  - quink 14y ago
    > HTML5 completion date has been announced as 2020 CSS2.1 became a W3C Recommendation on 7 June 2011. People have been using the HTML5 doctype for years now, never mind quite a few of the features. Arguing that the W3C is slow to standardise things is preaching to the choir, but CSS3 or HTML5 not being standards has had no impact on the ecosystem that's been using -moz-border-radius since Firefox 1.0. (that's 8 years ago. There are web designers that aren't twice that age out there). Also, sorry to be that person, but isn't SASS/SCSS (edit: and calc()) "good enough"™. The problem with XML files not rendering nicely in the browser is not anywhere near as important to developers as XML not supporting a way of plugging in JavaScript as HTML does with <script>. Edit: And lastly, what's wrong with XSL? It's got XPath, which as much as people love to dump on it, is not that bad. And you get HTML with all the bells and whistles as an output.
    - TazeTSchnitzel 14y ago
      >using -moz-border-radius since Firefox 1.0. (that's 8 years ago. There are web designers that aren't twice that age out there). ...web designers who had no idea -moz-border-radius existed until recently. Thanks, W3Schools!
    - matzipan 14y ago
      Well, the XML is just the template AXR uses to generate it's object model. Everything that happens after there is not upto XML anymore. It is all about HSS goodness.
  - matzipan 14y ago
    Yeah, but do you really feel like this W3C standardising process is really benefiting anybody? I know creating a standard involves a lot of work, but I don't like it. SASS/SCSS has nothing to do with HSS. SASS compiles intro regular CSS. HSS is standalone and can only be run in AXR supporting environments.
    - timdorr 14y ago
      HSS could be compiled into CSS. LESS stays LESS until it's compiled by a javascript shiv into CSS. If you're going to build out a browser plugin, you're going to have to plug into the built-in styling system to translate your HSS into CSS or some internal representation of CSS. Unless you write your own browser from scratch, they are all built internally to support CSS and will require drastic internal change (beyond what a plugin can do) to natively support something like HSS without translating to CSS.
      - matzipan 14y ago
        No sane browser vendor would do such a deep integration of CSS. Doing such a thing would be bad software design. The AXR Prototype was designed to be the same core implemented through lots of different wrappers (desktop, browser, you name it), much like webkit. We are planning to fork a popular browser in order to prove this is actually do-able. We have discovered it's not as hard as it seems.
  - weavejester 14y ago
    The 2022 date is no longer relevant, see: http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2022.3F http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2... Whilst there may very well be many advantages to your approach, please don't misrepresent the competition.
    - matzipan 14y ago
      Haven't heard the news. I guess they recieved a lot of bad feedback on that.
sohn 14y ago
This is completely superfluous. This is NOT the path the web needs to take.
- alexchamberlain 14y ago
  For what reasons?
  - reiz 14y ago
    I am against Browser Plugins. If it requires a plugin, I will not use it. I agree that the current CSS and HTML is not the best. There are many workarounds. But I believe in evolution. I think we have to improve CSS and HTML. And the people are creating Frameworks to solve problems and to hide workarounds. What works actually pretty good. It is not perfect, but it works. I think AXR is important. If people are contributing to AXR and starting to using it, that shows that something is not OK with CSS and HTML. And that could lead to faster improvements in CSS and HTML.
    - matzipan 14y ago
      We are still thinking on this. Last time we talked about actually forking chromium, to prove it's do-able.
PommeDeTerre 14y ago
Why do we need two different syntaxes for representing trees? Both XML and their so-called "HSS" are redundant. S-expressions are a much cleaner syntax, and can be used to represent both the "markup" and the "styling" in this case. For crying out loud, let's finally unify the syntaxes, rather than creating yet another way to represent tree structures.
- matzipan 14y ago
  Just to make it clear, HSS is directly replacing CSS. No markup there. You are missing the point, unfortuantely, the whole idea of the project is to sepparate the data from the presentation. Mixing them together would be pretty similar to what HTML was in 2005. Not desirable.
  - CodeMage 14y ago
    I believe you're missing his point: he said unify the syntax, not mix the data with the presentation.
  - matzipan 14y ago
    Oh, I totally understand. Thanks CodeMage. Sorry for the misunderstanding. XML is a widely-used data interchange format. It is well known and used. It's focus is the actual content. The syntax of HSS/CSS focuses on attributes. Makes for a perfect use in this case.
  - weavejester 14y ago
    I don't believe PommeDeTerre is saying that semantic information needs to be mixed with presentation information. He or she is asking why you have two different syntaxes when all you're doing in both cases is representing a nested tree. For example, you could have your data structure as: (books (book (title "Little Schemer"))) And then define your presentation as: (books (book (title (:color "ff6666")))) I'm not saying that this is necessarily the best representation, but it's more consistent and simpler for a machine to parse than XML/HSS.
- alexchamberlain 14y ago
toyg 14y ago
It's a very bold concept, but without buy-in from at least one major browser (i.e. not Opera) it has no chance to ever become mainstream. Browser plugins are where interesting technologies go to die.
- matzipan 14y ago
  Well, this is really what our plan really looks like. But we really have no idea how to do that.
  - alexchamberlain 14y ago
    Fork Chromium.
    - matzipan 14y ago
      Seems reasonable. Never thought about that. Thanks.
simonw 14y ago
This absolutely will not go anywhere if it requires either a browser plugin or buy-in from browser vendors. I'd suggest creating a JavaScript library that can read the XML/HSS format and render them as HTML/CSS/SVG.
- timdorr 14y ago
  Even better: Why not build on and extend the work that SASS/LESS have already started?
  - matzipan 14y ago
    Well, SASS/LESS are just supersets of CSS. They aren't designed to do anything else but what is compilable into actual CSS. I'm not sure how a feature like filters or event triggers would actually work in this language. We will definetely have a look at those.
- romaniv 14y ago
  That might be a good solution for transition period, but in the long run, another custom rendering engines in JS is the last thing the web needs right now. It needs a practical, declarative and semantic way of creating modern websites. So these guys are thinking in the right direction, even if what they propose is not perfect.
Tloewald 14y ago
CSS and HTML have quite a few baked in flaws that are unlikely to get fixed anytime soon, but there are workarounds. Most of the benefits of AXR seem to be similar to using XML, XSL, and LESS, which has the extra huge advantage of running in every major browser today. I think writing a good XML, XSL, LESS tool chain would be more practical, but I admire your spunk.
- deleted 14y ago
  [deleted]
- romaniv 14y ago
  CSS and HTML have quite a few baked in flaws that are unlikely to get fixed anytime soon, but there are workarounds. That's the problem. 90% of modern web design is all about workarounds. Those workarounds became more important than core technologies, because the latter no longer capture typical use cases of the web.
  - Tloewald 14y ago
    Actually a lot of modern web design is about working around the virtues of HTML, such as users controlling presentation and intentional markup. My point is that there's no workaround for "doesn't work in your browser".
agwa 14y ago
I wish they would use XPath (or at least a subset) for their selectors. They could probably easily use an existing implementation, and they would get filters for free in the form of predicates. This would avoid creating yet another XML selector language.
breckinloggins 14y ago
Why can't we go even deeper? If we want to replace the existing HTML/CSS/JS situation with something better, it would suck to replace them with technologies that have the same shortcomings. Here are some thoughts: - We need to decouple semantic structure definitions from browser releases. AXR gets this, but we can go further. - Further, we ought to somehow retain HTTP as a transport layer and keep the content text-based but still remove the reliance on SPECIFIC languages. What I imagine is very similar to AXR, only it would be something you could build AXR on TOP of. If you have a better idea than AXR, you could build that as well. Let the market decide. In fact, traditional HTML/CSS/JS could also be built on top of the new system. As you're probably guessing, I'm imagining some sort of "assembly language" + object model that exposes the core primitives of structure, presentation, and behavior. Now when I say "object model" I don't mean the DOM. I mean something more primitive than that in which the traditional DOM and other things could be implemented. The nice thing about this model is that the site can specify the location and version of the "compilers" it needs the browser to use to understand whatever it is sending. Most of the time, these would be well-known software components that ship with all browsers by default and are updated via standards bodies (just like now). The difference is that the standards can evolve independently of the browsers. Also, sites are free to use whatever they want as long as they can come up with it and the user agrees to download the components. When you think about it, this is really no different than "plugins", only now the content is not opaque. Browsers now become exercises in implementing the primitive "HTTP VM" (or whatever it's called) in the most efficient way possible, adding end-user features like tabs and private browsing, and implementing new VM versions as they are released by the WhatWG or W3C. Hopefully, these can move more slowly because you shouldn't need new primitives as often. It doesn't need to be said, but the HTTP VM can also be implemented server-side. I know this idea is half-baked and has some major problems, like: - How do you define what's "primitive" without getting into decade-long ontological discussions? - How does this change how web crawlers work? Presumably, sites like Google would have to act like web clients and also download and run the compilers needed to parse each site. Could this be done with acceptable performance? - What does this "assembly language" look like? If it looks like XML, aren't we back to AXR? - If we keep going down to abstractions, we might as well just send LLVM code through HTTP and have web clients implement some "idealized real computer" with I/O and memory and all that. Then what are we doing? Isn't this something totally different? Why not just build that and hope it gains traction? - JS JIT compilers are very finely-tuned. Will going down to a lower level of abstraction actually make performance suffer because there are less high-level things that can be recognized and inlined? - Are HTML/CSS/JS ALREADY this assembly language of which I speak? If we just add the ability to define arbitrary HTML tags, allow them to "derive" existing tags, and define their default structure, presentation and behavior through JS calls or declarations on some "meta tagdef" element, aren't we mostly there? With so many browser vendors and versions, it's much easier to evolve than replace. That said, my point is that no matter how good you can imagine the "next" HTML/CSS/JS, why fight the battle to bake it into all web browsers only to have to fight that battle AGAIN in another 20 years. Sure, revolutionize the platform. But revolutionize it toward abstractions and language independence.
d4n3 14y ago
Your plan is to make a common library that all browser vendors will use and you will control? How are you going to compete with existing browser rendering engines written with massive engineering resources and years of optimizations and convince browser vendors to replace them with your stuff and let go of control over the development?
- matzipan 14y ago
  Hey, Rome wasn't built in a day. Right now it's at a prototype/concept level. It will take a couple of years until we have an actual usable product. Thinking you have no chances in succeeding will only get you not even trying.
agumonkey 14y ago
I'll probably get flamed for this, but I often fall into wishing there was xml ontologies + formatting rules. Skipping the HTML layer entirely. Be model-centric instead of html centric. "model" presentation ------- ------------ <div class="order"> .order { .. } <h1 class="agent">...</h1> .agent { .. } here your model has turned into html, yet has to be re-expressed as presentation rules. your model is presentation. WAT. => <order> order { render: box } <agent> agent { font: ... } I'm sure it's been done many times before but I've never read about why it failed.
- matzipan 14y ago
  That's exactly what we have in mind. The thing is <div> and <h1> are just presentation tags, when, in fact, you are styling them with css too. In hss object model, everything is a box. How it is styled and how it behaves it's up to you. There will be an HSS framework, which will provide basic capabilities like heading, dropdown, radio. We are proposing a syntax like order { isA: heading }
  - agumonkey 14y ago
    Maybe in the future the box model will be one `dsl` in a larger rendering system that borrows from stack based 2d, matrix based 3d. So you can use what fits best when it fits best. edit : Traces of this are in place, js based advanced layouts , webgl, canvas. It's just non composable right now.
edgarvm 14y ago
in a very different context something slighty close to it already exists: QML
optymizer 14y ago
Instead of creating yet another way of defining a tree structure (HSS), why not do this: use XML instead of CSS syntax and XPath instead of CSS selectors and just make it less obnoxious than XSL-FO and less template-oriented than XSL:  <books> <book>...</book> <book>...</book> </books>  <axr:style select="//book"> <color>#000</color> <background color="red"/> </axr:style> You can still have your hierarchy, if you prefer, instead of the 'select' above:  <books> <book> <axr:color>#000</axr:color> <axr:background color="red"/> </book> </books> See? No need for an HSS parser. That's really what "reinventing the wheel" warns against. Note: I'm generally in favor of rewriting things, when the benefits are clear. With HSS, I don't see why I'd want to replicate the tree again,(using a different syntax, i won't even be able to copy-paste!) just for the style. I'd rather use XPath selectors and XML. Some thoughts: 1. It would be nice to merge CSS with XML (as others have said - there is really no need to have 2 different syntaxes) 2. It would be nice to use XML everywhere (the more you use it, the easier it's going to be to integrate this into IDEs, scripts, web apps, etc). 3. The important thing is the value of the COLOR, not the fact that you managed to parse braces, pipes, etc and come up with your own syntax for representing a tree and selecting elements in it? That's wasted effort and you're not innovating. Use XML, or JSON, or YAML (whatever floats your boat), but use that EVERYWHERE: for data and style. That would be a step forward from HTML/CSS. 4. Again, there is no need to reinvent XPath, like CSS selectors are trying to do. Use XPath, it works great with XML, it's CONCISE and it is familiar and simple, because it looks like a file path (or basic url) with some optional filtering on each level. (N.B.: don't fall in the XPath2/XQuery trap). 5. Embedding Javascript would be easy: it would be the same as HTML: <script/>. 6. You get brownie points if you could use JSON for elements, style and scripts. You'd reduce the entire HTML/CSS/JS stack to just JSON: //index.json { books: [ { title:"foo" }, { title:"bar" } ] } //index.axr (keep XPath-like syntax for selectors, use HSS-like syntax for style) { select:"books[0]/title", style: { color:"#ff0", background: { ... } } } This would allow for some interesting (maybe faster?) interactions between Javascript, style and object model. Though I think I prefer the XML/XPath stack. Those were my few cents. Good luck with your project!
- matzipan 14y ago
dylanhassinger 14y ago
If one major browser started supporting AXR, others would follow. If Webkit started supporting AXR, it would become the new standard. Who has the most to gain by supporting a genuinely good web standard? Could be Microsoft actually. Microsoft -> Mozilla -> Webkit -> Everywhere Have you tried reaching out to the IE team, or had interactions with other browser companies?
- matzipan 14y ago
  It's not about webkit, as we're planning to actually replace webkit. I think this kind of action coming from somewone like microsoft would be seen as another proprietary software imposed to the web. We have not tried yet, as we did not have anything relevant to work with. We really have no idea how we can do that. Maybe you can help?

48 points by ryannielsen 14y ago

I'm sorry to be skeptical, but this seems both redundant and pie-in-the-sky. In the presentation they say they're looking for "Computer Science Engineers" make me think this is a bunch of aggravated designers. On the other hand, there is code on GitHub. But it's C++, which makes it feel like this is a bunch of aggravated developers who can't stand having to do HTML or CSS and want to do "real engineering" (usually defined as non-webapps). This seems to pop up every other month. All the while people keep making awesome web sites, applications and libraries with the stack we have today. A small group of people is usually all it takes to change something, on the other hand, I don't think is change people want or need. That said, I wish them all the best.

matzipan 14y ago
Fortunately, our team is made up of both designers and programmers. In fact, our lead programmer is also our lead designer (small team). It is true, you can make really awesome apps with HTML5/CSS. We, ourselves, are doing the same thing. We are bringing to attention some new concepts that we think have not been taken into acount into HTML simply because HTML features have just been stacked together and it HTML simply evolved into something it was not intended to. On the other hand, the HTML5 completion date has been announced as 2020. Do you really think HTML5 will still suit the needs of the web then? It should probably be HTML7.
- quink 14y ago
  > HTML5 completion date has been announced as 2020 CSS2.1 became a W3C Recommendation on 7 June 2011. People have been using the HTML5 doctype for years now, never mind quite a few of the features. Arguing that the W3C is slow to standardise things is preaching to the choir, but CSS3 or HTML5 not being standards has had no impact on the ecosystem that's been using -moz-border-radius since Firefox 1.0. (that's 8 years ago. There are web designers that aren't twice that age out there). Also, sorry to be that person, but isn't SASS/SCSS (edit: and calc()) "good enough"™. The problem with XML files not rendering nicely in the browser is not anywhere near as important to developers as XML not supporting a way of plugging in JavaScript as HTML does with <script>. Edit: And lastly, what's wrong with XSL? It's got XPath, which as much as people love to dump on it, is not that bad. And you get HTML with all the bells and whistles as an output.
  - TazeTSchnitzel 14y ago
    >using -moz-border-radius since Firefox 1.0. (that's 8 years ago. There are web designers that aren't twice that age out there). ...web designers who had no idea -moz-border-radius existed until recently. Thanks, W3Schools!
  - matzipan 14y ago
    Well, the XML is just the template AXR uses to generate it's object model. Everything that happens after there is not upto XML anymore. It is all about HSS goodness.
- matzipan 14y ago
  Yeah, but do you really feel like this W3C standardising process is really benefiting anybody? I know creating a standard involves a lot of work, but I don't like it. SASS/SCSS has nothing to do with HSS. SASS compiles intro regular CSS. HSS is standalone and can only be run in AXR supporting environments.
  - timdorr 14y ago
    HSS could be compiled into CSS. LESS stays LESS until it's compiled by a javascript shiv into CSS. If you're going to build out a browser plugin, you're going to have to plug into the built-in styling system to translate your HSS into CSS or some internal representation of CSS. Unless you write your own browser from scratch, they are all built internally to support CSS and will require drastic internal change (beyond what a plugin can do) to natively support something like HSS without translating to CSS.
    - matzipan 14y ago
      No sane browser vendor would do such a deep integration of CSS. Doing such a thing would be bad software design. The AXR Prototype was designed to be the same core implemented through lots of different wrappers (desktop, browser, you name it), much like webkit. We are planning to fork a popular browser in order to prove this is actually do-able. We have discovered it's not as hard as it seems.
- weavejester 14y ago
  The 2022 date is no longer relevant, see: http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2022.3F http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2... Whilst there may very well be many advantages to your approach, please don't misrepresent the competition.
  - matzipan 14y ago
    Haven't heard the news. I guess they recieved a lot of bad feedback on that.

sohn 14y ago

This is completely superfluous. This is NOT the path the web needs to take.

alexchamberlain 14y ago
For what reasons?
- reiz 14y ago
  I am against Browser Plugins. If it requires a plugin, I will not use it. I agree that the current CSS and HTML is not the best. There are many workarounds. But I believe in evolution. I think we have to improve CSS and HTML. And the people are creating Frameworks to solve problems and to hide workarounds. What works actually pretty good. It is not perfect, but it works. I think AXR is important. If people are contributing to AXR and starting to using it, that shows that something is not OK with CSS and HTML. And that could lead to faster improvements in CSS and HTML.
  - matzipan 14y ago
    We are still thinking on this. Last time we talked about actually forking chromium, to prove it's do-able.

PommeDeTerre 14y ago

Why do we need two different syntaxes for representing trees? Both XML and their so-called "HSS" are redundant. S-expressions are a much cleaner syntax, and can be used to represent both the "markup" and the "styling" in this case. For crying out loud, let's finally unify the syntaxes, rather than creating yet another way to represent tree structures.

matzipan 14y ago
Just to make it clear, HSS is directly replacing CSS. No markup there. You are missing the point, unfortuantely, the whole idea of the project is to sepparate the data from the presentation. Mixing them together would be pretty similar to what HTML was in 2005. Not desirable.
- CodeMage 14y ago
  I believe you're missing his point: he said unify the syntax, not mix the data with the presentation.
- matzipan 14y ago
  Oh, I totally understand. Thanks CodeMage. Sorry for the misunderstanding. XML is a widely-used data interchange format. It is well known and used. It's focus is the actual content. The syntax of HSS/CSS focuses on attributes. Makes for a perfect use in this case.
- weavejester 14y ago
  I don't believe PommeDeTerre is saying that semantic information needs to be mixed with presentation information. He or she is asking why you have two different syntaxes when all you're doing in both cases is representing a nested tree. For example, you could have your data structure as: (books (book (title "Little Schemer"))) And then define your presentation as: (books (book (title (:color "ff6666")))) I'm not saying that this is necessarily the best representation, but it's more consistent and simpler for a machine to parse than XML/HSS.
alexchamberlain 14y ago

toyg 14y ago

It's a very bold concept, but without buy-in from at least one major browser (i.e. not Opera) it has no chance to ever become mainstream. Browser plugins are where interesting technologies go to die.

matzipan 14y ago
Well, this is really what our plan really looks like. But we really have no idea how to do that.
- alexchamberlain 14y ago
  Fork Chromium.
  - matzipan 14y ago
    Seems reasonable. Never thought about that. Thanks.

simonw 14y ago

This absolutely will not go anywhere if it requires either a browser plugin or buy-in from browser vendors. I'd suggest creating a JavaScript library that can read the XML/HSS format and render them as HTML/CSS/SVG.

timdorr 14y ago
Even better: Why not build on and extend the work that SASS/LESS have already started?
- matzipan 14y ago
  Well, SASS/LESS are just supersets of CSS. They aren't designed to do anything else but what is compilable into actual CSS. I'm not sure how a feature like filters or event triggers would actually work in this language. We will definetely have a look at those.
romaniv 14y ago
That might be a good solution for transition period, but in the long run, another custom rendering engines in JS is the last thing the web needs right now. It needs a practical, declarative and semantic way of creating modern websites. So these guys are thinking in the right direction, even if what they propose is not perfect.

Tloewald 14y ago

CSS and HTML have quite a few baked in flaws that are unlikely to get fixed anytime soon, but there are workarounds. Most of the benefits of AXR seem to be similar to using XML, XSL, and LESS, which has the extra huge advantage of running in every major browser today. I think writing a good XML, XSL, LESS tool chain would be more practical, but I admire your spunk.

deleted 14y ago
[deleted]
romaniv 14y ago
CSS and HTML have quite a few baked in flaws that are unlikely to get fixed anytime soon, but there are workarounds. That's the problem. 90% of modern web design is all about workarounds. Those workarounds became more important than core technologies, because the latter no longer capture typical use cases of the web.
- Tloewald 14y ago
  Actually a lot of modern web design is about working around the virtues of HTML, such as users controlling presentation and intentional markup. My point is that there's no workaround for "doesn't work in your browser".

agwa 14y ago

I wish they would use XPath (or at least a subset) for their selectors. They could probably easily use an existing implementation, and they would get filters for free in the form of predicates. This would avoid creating yet another XML selector language.

breckinloggins 14y ago

Why can't we go even deeper? If we want to replace the existing HTML/CSS/JS situation with something better, it would suck to replace them with technologies that have the same shortcomings. Here are some thoughts: - We need to decouple semantic structure definitions from browser releases. AXR gets this, but we can go further. - Further, we ought to somehow retain HTTP as a transport layer and keep the content text-based but still remove the reliance on SPECIFIC languages. What I imagine is very similar to AXR, only it would be something you could build AXR on TOP of. If you have a better idea than AXR, you could build that as well. Let the market decide. In fact, traditional HTML/CSS/JS could also be built on top of the new system. As you're probably guessing, I'm imagining some sort of "assembly language" + object model that exposes the core primitives of structure, presentation, and behavior. Now when I say "object model" I don't mean the DOM. I mean something more primitive than that in which the traditional DOM and other things could be implemented. The nice thing about this model is that the site can specify the location and version of the "compilers" it needs the browser to use to understand whatever it is sending. Most of the time, these would be well-known software components that ship with all browsers by default and are updated via standards bodies (just like now). The difference is that the standards can evolve independently of the browsers. Also, sites are free to use whatever they want as long as they can come up with it and the user agrees to download the components. When you think about it, this is really no different than "plugins", only now the content is not opaque. Browsers now become exercises in implementing the primitive "HTTP VM" (or whatever it's called) in the most efficient way possible, adding end-user features like tabs and private browsing, and implementing new VM versions as they are released by the WhatWG or W3C. Hopefully, these can move more slowly because you shouldn't need new primitives as often. It doesn't need to be said, but the HTTP VM can also be implemented server-side. I know this idea is half-baked and has some major problems, like: - How do you define what's "primitive" without getting into decade-long ontological discussions? - How does this change how web crawlers work? Presumably, sites like Google would have to act like web clients and also download and run the compilers needed to parse each site. Could this be done with acceptable performance? - What does this "assembly language" look like? If it looks like XML, aren't we back to AXR? - If we keep going down to abstractions, we might as well just send LLVM code through HTTP and have web clients implement some "idealized real computer" with I/O and memory and all that. Then what are we doing? Isn't this something totally different? Why not just build that and hope it gains traction? - JS JIT compilers are very finely-tuned. Will going down to a lower level of abstraction actually make performance suffer because there are less high-level things that can be recognized and inlined? - Are HTML/CSS/JS ALREADY this assembly language of which I speak? If we just add the ability to define arbitrary HTML tags, allow them to "derive" existing tags, and define their default structure, presentation and behavior through JS calls or declarations on some "meta tagdef" element, aren't we mostly there? With so many browser vendors and versions, it's much easier to evolve than replace. That said, my point is that no matter how good you can imagine the "next" HTML/CSS/JS, why fight the battle to bake it into all web browsers only to have to fight that battle AGAIN in another 20 years. Sure, revolutionize the platform. But revolutionize it toward abstractions and language independence.

d4n3 14y ago

Your plan is to make a common library that all browser vendors will use and you will control? How are you going to compete with existing browser rendering engines written with massive engineering resources and years of optimizations and convince browser vendors to replace them with your stuff and let go of control over the development?

matzipan 14y ago
Hey, Rome wasn't built in a day. Right now it's at a prototype/concept level. It will take a couple of years until we have an actual usable product. Thinking you have no chances in succeeding will only get you not even trying.

agumonkey 14y ago

I'll probably get flamed for this, but I often fall into wishing there was xml ontologies + formatting rules. Skipping the HTML layer entirely. Be model-centric instead of html centric. "model" presentation ------- ------------ <div class="order"> .order { .. } <h1 class="agent">...</h1> .agent { .. } here your model has turned into html, yet has to be re-expressed as presentation rules. your model is presentation. WAT. => <order> order { render: box } <agent> agent { font: ... } I'm sure it's been done many times before but I've never read about why it failed.

matzipan 14y ago
That's exactly what we have in mind. The thing is <div> and <h1> are just presentation tags, when, in fact, you are styling them with css too. In hss object model, everything is a box. How it is styled and how it behaves it's up to you. There will be an HSS framework, which will provide basic capabilities like heading, dropdown, radio. We are proposing a syntax like order { isA: heading }
- agumonkey 14y ago
  Maybe in the future the box model will be one `dsl` in a larger rendering system that borrows from stack based 2d, matrix based 3d. So you can use what fits best when it fits best. edit : Traces of this are in place, js based advanced layouts , webgl, canvas. It's just non composable right now.

edgarvm 14y ago

in a very different context something slighty close to it already exists: QML

optymizer 14y ago

Instead of creating yet another way of defining a tree structure (HSS), why not do this: use XML instead of CSS syntax and XPath instead of CSS selectors and just make it less obnoxious than XSL-FO and less template-oriented than XSL:  <books> <book>...</book> <book>...</book> </books>  <axr:style select="//book"> <color>#000</color> <background color="red"/> </axr:style> You can still have your hierarchy, if you prefer, instead of the 'select' above:  <books> <book> <axr:color>#000</axr:color> <axr:background color="red"/> </book> </books> See? No need for an HSS parser. That's really what "reinventing the wheel" warns against. Note: I'm generally in favor of rewriting things, when the benefits are clear. With HSS, I don't see why I'd want to replicate the tree again,(using a different syntax, i won't even be able to copy-paste!) just for the style. I'd rather use XPath selectors and XML. Some thoughts: 1. It would be nice to merge CSS with XML (as others have said - there is really no need to have 2 different syntaxes) 2. It would be nice to use XML everywhere (the more you use it, the easier it's going to be to integrate this into IDEs, scripts, web apps, etc). 3. The important thing is the value of the COLOR, not the fact that you managed to parse braces, pipes, etc and come up with your own syntax for representing a tree and selecting elements in it? That's wasted effort and you're not innovating. Use XML, or JSON, or YAML (whatever floats your boat), but use that EVERYWHERE: for data and style. That would be a step forward from HTML/CSS. 4. Again, there is no need to reinvent XPath, like CSS selectors are trying to do. Use XPath, it works great with XML, it's CONCISE and it is familiar and simple, because it looks like a file path (or basic url) with some optional filtering on each level. (N.B.: don't fall in the XPath2/XQuery trap). 5. Embedding Javascript would be easy: it would be the same as HTML: <script/>. 6. You get brownie points if you could use JSON for elements, style and scripts. You'd reduce the entire HTML/CSS/JS stack to just JSON: //index.json { books: [ { title:"foo" }, { title:"bar" } ] } //index.axr (keep XPath-like syntax for selectors, use HSS-like syntax for style) { select:"books[0]/title", style: { color:"#ff0", background: { ... } } } This would allow for some interesting (maybe faster?) interactions between Javascript, style and object model. Though I think I prefer the XML/XPath stack. Those were my few cents. Good luck with your project!

matzipan 14y ago

dylanhassinger 14y ago

If one major browser started supporting AXR, others would follow. If Webkit started supporting AXR, it would become the new standard. Who has the most to gain by supporting a genuinely good web standard? Could be Microsoft actually. Microsoft -> Mozilla -> Webkit -> Everywhere Have you tried reaching out to the IE team, or had interactions with other browser companies?

matzipan 14y ago
It's not about webkit, as we're planning to actually replace webkit. I think this kind of action coming from somewone like microsoft would be seen as another proprietary software imposed to the web. We have not tried yet, as we did not have anything relevant to work with. We really have no idea how we can do that. Maybe you can help?