Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Languages Which Almost Became CSS

eager.io

Post reply on HN
Print view View original

81–90 of 136 posts

Re: Languages Which Almost Became CSS

#81

Post by izym »

Kinnard wrote: post #62
edvinbesic wrote: post #29

Earlier quoted context omitted.

There is always Grid Style Sheets[1] if you want to try it out. It is based on the same algorithms as iOS constraint engine[2] AFAIK. Unfortunately it has to compute the constraints using javascript as its not native. [1]: https://gridstylesheets.org/ [2]: https://en.wikipedia.org/wiki/Cassowary_(software)

WebAssembly should be able to help with that, no?

I think so, yes. Personally I'm really looking forward to seeing what people are going to implement with WebAssembly. Another possibility would be virtual DOM diffing.

Re: Languages Which Almost Became CSS

#82

Post by unimpressive »

majewsky wrote: post #79
martyalain wrote: post #77

Writing pages in a web site is a mess, polluted by different syntaxes, HTML, CSS, Javascript, jQuery things, MarkDown, ... It's a miracle that Wikipedia exists! Several works have been done to bring some unity, for instance Skribe, Scribble, LAML, SXML, but they generally lead to complex systems devoted to coders and forgetting web designers and, of course, beginners. The {lambda way} project is built as a thin overl…

https://xkcd.com/927/

And yet, if everybody followed this logic we would never get new standards.

Re: Languages Which Almost Became CSS

#83

Post by jomamaxx »

mahyarm wrote: post #53
Animats wrote: post #27

Layout should have been constraint-oriented, not procedural. You should be able to express "Bottom of this box is adjacent to top of that box", and such. All those constraints go into a constraint engine, and a layout is generated. This is something a WYSIWYG editor can generate. To get a sense of how this could work, try sketch mode in Autodesk Inventor (there's a free 30 day demo) You can specify that a point must…

Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n). I think out of practicality it wasn't adopted. It would be better if both were available, but such is life. http://floriankugler.com/2013/04/22/auto-layout-performance-...

"Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n)."

Those are the upper bounded constraints, but not reality.

Pragmatically, there's no reason 'constraint bounded' algs can't - in practice - approach procedural layouts.

Second, is the fact that layout is becoming less and less of an issue re: performance, to the point that in a few years, the argument may be moot.

Third, I'd argue that 'performance' is only one factor.

But good point.

Re: Languages Which Almost Became CSS

#84

Post by wnevets »

justinator wrote: post #34
Animats wrote: post #27

Layout should have been constraint-oriented, not procedural. You should be able to express "Bottom of this box is adjacent to top of that box", and such. All those constraints go into a constraint engine, and a layout is generated. This is something a WYSIWYG editor can generate. To get a sense of how this could work, try sketch mode in Autodesk Inventor (there's a free 30 day demo) You can specify that a point must…

> The people who designed HTML5 and CSS thought procedurally, not geometrically. It shows. The problem the article points out is that they wanted styling to happen, before the entire document is downloaded. Obv. you can't say, "hey, this box should be pinned to the bottom of the footer" if the HTML for the footer isn't yet existing in the stream that's downloaded. I think enough people fume when they see the Flash of…

It sounds like people are forgetting that most users were on dial up during the 90s.

Re: Languages Which Almost Became CSS

#85

Post by pcwalton »

naasking wrote: post #78
pcwalton wrote: post #65

Earlier quoted context omitted.

Not only do I think the stylesheets would not end up appreciably smaller after gzip, I also disagree with that argument. Rendering performance (animations, scrolling, etc.) is one of the key reasons why native is perceived to be winning vs. the Web. Making the Web even slower at rich interactive apps is not doing the Web any favors.

> Rendering performance (animations, scrolling, etc.) is one of the key reasons why native is perceived to be winning vs. the Web. Except this is an argument against JavaScript driven behaviour, not against a restricted styling language slightly more expressive than CSS. The fact that we would be able to move some of this dynamic behaviour from a general purpose language where optimizing redraw is difficult, to a dom…

> The fact that we would be able to move some of this dynamic behaviour from a general purpose language where optimizing redraw is difficult, to a domain-specific language where optimizing redraw is loads easier would yield performance improvements, not regressions.

No, it wouldn't. "Optimizing redraw" isn't difficult, and to the extent that it is it has nothing to do with the expressiveness of CSS.

Re: Languages Which Almost Became CSS

#87

Post by shrugger2 »

ryanbrunner wrote: post #76
Animats wrote: post #70

Earlier quoted context omitted.

It's used for screen layout in MacOS Lion and Grid Style Sheets.[1] There's also a subdomain that goes faster, and simple layouts should be in that subdomain. The idea is to get away from programmer-oriented layout input.

Right, but neither Lion or Grid Style Sheets were available in the early 90's. It may have been possible to implement, sure, but we're talking early enough in the web's history that the performance of the styling engine was a legitimate concern.

Sure, but now we're past all that and people still come up with bullshit reasons that CSS SHOULDN'T be replaced when there is every reason to believe that we can do a better job now that we've suffered through 20 years of learning.

Re: Languages Which Almost Became CSS

#88

Post by mahyarm »

jomamaxx wrote: post #83
mahyarm wrote: post #53

Earlier quoted context omitted.

Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n). I think out of practicality it wasn't adopted. It would be better if both were available, but such is life. http://floriankugler.com/2013/04/22/auto-layout-performance-...

"Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n)." Those are the upper bounded constraints, but not reality. Pragmatically, there's no reason 'constraint bounded' algs can't - in practice - approach procedural layouts. Second, is the fact that layout is becoming less and less of an issue re: performance, to the point that in a few years, the argument may be moot. Th…

I wish iOS autolayout wasn't n^2. You have to realize these algorithms have very small time budgets and you can start seeing stutters when you use them in things like UICollectionViews and UITableViews and other scrolling / gesture contexts. Performance is still a very real thing for these things.

Devices you support will also last 5+ years and I don't think we will see the same power/performance ratio gains in mobile in the next 5 years like we have in the last 5 years. I bought an iPad Mini 4 recently and I see general stuttering in the OS programs alone and it's the most recent iPad Mini you can buy!

You can have something pretty close to constraint based layouts in procedural layouts in something like "snap view 1 bottom to view 2 top", etc.

Re: Languages Which Almost Became CSS

#89

Post by paragraft »

What a great post. I really appreciate these longer digs into the past that go behind the 'what' to explain the how & why of where we got where we are; and just as much the futures that could have been and why they didn't happen. I keep thinking there's room for a decent series discussing the evolution of Rust, since that design process was such a public thing.

Re: Languages Which Almost Became CSS

#90

Post by panic »

pcwalton wrote: post #64
patrickmay wrote: post #15

Earlier quoted context omitted.

The engineering management that prevented Scheme in the browser should never be forgiven: https://brendaneich.com/2008/04/popularity/

Scheme in the browser would have been fine. Scheme in the hot path of every single restyle, not so much.

Why not? Modern JIT compilers generate very fast code.
Post reply on HN