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

A div that looks different in every browser

twitter.com

Post reply on HN
Print view View original

121–130 of 133 posts

Re: A div that looks different in every browser

#121

Post by talmand »

lisper wrote: post #119
talmand wrote: post #116

Earlier quoted context omitted.

Wait, front-end developers who use CSS created the problems of CSS? That's really funny. I mean, that's the most mind-blowing accusation I've heard in a long time. I would have to suggest you are commenting on a topic that you actually know very little about. But at least you are entertaining.

Who do you think created CSS? CSS was not handed down on stone tablets by the gods, it was designed by humans, and I presume that at least some of the people who designed CSS actually used it (though to be honest I don't actually know who was on the committee). I don't know if it was their intent to make something Byzantine that served as an effective barrier to entry to doing front-end design, but that was in fact w…

Who created CSS as we know it? CERN. More or less.

Who first tested and implemented CSS? Browser programmers.

These days it's under the control of committee. I think I would disagree with the notion that CSS devs are the ones to blame in this case. Sure, there's lots of blame to share for the problems. To imply that CSS developers intentionally forced it to be complicated for purposes of job security is laughable.

After all, CSS is not C++.

Re: A div that looks different in every browser

#122

Post by lisper »

talmand wrote: post #121
lisper wrote: post #119

Earlier quoted context omitted.

Who do you think created CSS? CSS was not handed down on stone tablets by the gods, it was designed by humans, and I presume that at least some of the people who designed CSS actually used it (though to be honest I don't actually know who was on the committee). I don't know if it was their intent to make something Byzantine that served as an effective barrier to entry to doing front-end design, but that was in fact w…

Who created CSS as we know it? CERN. More or less. Who first tested and implemented CSS? Browser programmers. These days it's under the control of committee. I think I would disagree with the notion that CSS devs are the ones to blame in this case. Sure, there's lots of blame to share for the problems. To imply that CSS developers intentionally forced it to be complicated for purposes of job security is laughable. Af…

I didn't say that was their intent, only that the current state of the art has that effect. And that I think this is a bad thing.

Re: A div that looks different in every browser

#123

Post by jhomedall »

pjmlp wrote: post #120
jhomedall wrote: post #113

Earlier quoted context omitted.

React isn't really anything like 90s UI libraries. It is, however, very much like the fairly recent native immediate-mode GUIs that have come out ( https://github.com/ocornut/imgui , https://github.com/PistonDevelopers/conrod , etc). The core feature of React is that your UI is a pure function of your application state. In (e.g.) the Win32 UI, you would receive events, and then need to manually transition your curren…

Smalltalk UIs used a pattern called dependency propagation to make objects update themselves based on system wide notifications. Similar idea was used on Oberon System 3 Gadgets toolkit. Also java.util.Observable based on the same Smalltalk ideas was already part of Java 1.0.

That's still event handling. You can do basic binding between outputs and values, but more macroscopic changes (closing a dialog, changing tabs, etc) requires tracking the state your UI is in, and manually transitioning.

This is markedly different than React, where the framework diffs the desired UI state (which is a pure function of your application state), and the actual UI state. The minimal number of UI operations necessary is then applied to make the latter match the former.

ImGui above works the same way, which makes it very popular for devtools in game development.

Re: A div that looks different in every browser

#124

Post by hlmencken »

nadsumatal wrote: post #115

Joke: A man walks into a picture framing shop and says: "I'd like a 10cmx10xm frame for my 10cmx10cm picture, but make it negative 12.5cm away from the picture." The shop staff is confused, but makes a wild guess: "So you want a frame with each border 2.5cm on the other side of the picture than it would normally be?" The man just takes a note and goes to another shop. He collected the wild guesses from various pictur…

This sort of badinage is what makes HN so endearing. Thanks!

Re: A div that looks different in every browser

#125

Post by gsnedders »

olliej wrote: post #89
gsnedders wrote: post #70

Earlier quoted context omitted.

CSS outlines are still only vaguely defined and tables even less so (I mean, table-layout: auto, which is the initial value, is only now finally getting specified; it's probably the least defined but most relied upon bit of the web platform now). There's definitely still places where undefined behaviour still lives, especially around CSS. Without actually digging into it (I'm on vacation damnit), I'm pretty sure all…

Sorry yes for(in) over prototype chains is where mutation of the property list actually becomes visible -- mutating own properties on an object while iterating is specified IIRC, it's what happens when own properties alias properties in the prototype chain, or when mutating properties in the prototype chain. I blame Brendan :D

Pretty sure mutating own properties is undefined, but I'm years out of working on any JS VM and only vaguely pay attention (and looked into this a few months ago and was surprised to find iteration order still undefined!). I wonder how many unique behaviours we have with iteration order now… Is Gecko the only odd one out? Is there still any implementation that has different behaviour with dense/sparse arrays (by which I mean properties not the Array object)?

Re: A div that looks different in every browser

#126

Post by creatonez »

bwbw223 wrote: post #82
creatonez wrote: post #81

Earlier quoted context omitted.

Also, Firefox nightly with WebRender: https://i.imgur.com/Ffg0bS7.png

Are those just compression artifacts or what?

No, that's just scrot being buggy

Fixed: https://i.imgur.com/jAVrnBE.png

Re: A div that looks different in every browser

#127

Post by pjmlp »

jhomedall wrote: post #123
pjmlp wrote: post #120

Earlier quoted context omitted.

Smalltalk UIs used a pattern called dependency propagation to make objects update themselves based on system wide notifications. Similar idea was used on Oberon System 3 Gadgets toolkit. Also java.util.Observable based on the same Smalltalk ideas was already part of Java 1.0.

That's still event handling. You can do basic binding between outputs and values, but more macroscopic changes (closing a dialog, changing tabs, etc) requires tracking the state your UI is in, and manually transitioning. This is markedly different than React, where the framework diffs the desired UI state (which is a pure function of your application state), and the actual UI state. The minimal number of UI operation…

ImGui is quite similar to MS-DOS game UIs, before we migrated to Windows.

The source code of quite a few ones is available around the Net.

Re: A div that looks different in every browser

#128

Post by luk32 »

pjmlp wrote: post #87
howdydoo wrote: post #67

Earlier quoted context omitted.

https://codepen.io/anon/pen/NzQQJm This is a gross abuse of html, but if you really want that syntax, you can have it. I can't say I understand all the complaining here. You want to make $200K a year sitting at a desk, but learning flexbox or googling when you need it is too much effort?

Where is this $200k wonderful place?

For 200k I'd consider working even on JS and front-end xD

Re: A div that looks different in every browser

#130

Post by billybolton »

crimsonalucard wrote: post #100
billybolton wrote: post #54

Earlier quoted context omitted.

Forcing the DOM, JS and CSS was a mistake. The problem was that you couldn't have alternatives. wasm is going to disrupt front end by allowing you to have a strong typed language that you can use to build your own framework like the good ol' days.

Still gotta deal with the dom though. They need a root pixel level api to be made in conjunction to wasm, so people can restart from scratch.

Only once for the containing canvas. A direct access to the canvas pixel data and webGL offscreen rendering is all you need. With a few hacks, we're already 90% there. I expect by next year to see an explosion of this. There already are projects in Github that translated SDL and OpenGL to build web widgets.
Post reply on HN