Live data from Hacker News

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

axr.vg

41–50 of 65 posts

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

#41
post #39
post #32

Earlier quoted context omitted.

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

In presentation - http://www.slideshare.net/veosotano/axr-presentation-betabee... - 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)

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

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

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

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

#43

Earlier quoted context omitted.

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

As long as the reference implementation gets a decent head start, any re-implementers will practically be forced to maintain complete compatibility with it. This model works quite well for programming languages.

Care to enlighten me on examples of languages that got a decent head start as a reference implementation, and are wide-spread?

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

#44

Earlier quoted context omitted.

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

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.

> Why would anyone do that?

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

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

#45
post #3

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

The author hasn't suggested XML for presentation, but rather for content.

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

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

#46

Earlier quoted context omitted.

As long as the reference implementation gets a decent head start, any re-implementers will practically be forced to maintain complete compatibility with it. This model works quite well for programming languages.

Care to enlighten me on examples of languages that got a decent head start as a reference implementation, and are wide-spread?

Umm, all of them? Can you name a mainstream language that didn't start with a reference implementation?

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

#47

Earlier quoted context omitted.

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 b…

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.

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.

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

#49
post #12

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 b…

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 u…

To be honest, I think the browser support picture is changing. An increasing number of people are developing apps where they have some idea of what their target audience is like. Greater than 40% of the browsing public is now using Firefox, Chrome or Safari.

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

calc is in IE9+ and Firefox.

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

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

(obDisclaimer: I'm a Mozillian)

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

#50
post #26

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?

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".
Post reply on HN