A div that looks different in every browser • Hacker News Board

Re: A div that looks different in every browser

#41

Post by chiefalchemist » Sun, Jul 08, 2018, 8:58 PM UTC

tgummerer wrote: post #38

jayd16 wrote: post #31

Earlier quoted context omitted.

This isn't really a spec thing. Its more a manifestation of undefined behavior. Even c++ compilers have undefined behavior.

Especially C++ compilers have undefined behavior

Yes. But are you going to to use 3 to 5 or mote C++ compilers on a given project?

The worst part of these frontend issues is, ultimately, the UX can become inconsistent, if not mess. Given that nearly everyone interfaces via the visual UI, you'd think we'd have this sorted out by now.

Re: A div that looks different in every browser

#42

Post by lisper » Sun, Jul 08, 2018, 9:07 PM UTC

rvense wrote: post #40

lisper wrote: post #32

Earlier quoted context omitted.

The code shown on that page actually doesn't work, though the code in the github repo does. And this exposes the problem with the current state of the art: yes, you can probably get flexbox to do what you want [@] if you know how. But if you don't know how, trying to figure it out is still very hard. You should be able to write: stuff or stuff There is really no reason that should not Just Work. (The tag has worked f…

You should not be centering things in HTML, that's the stylesheet's job.

I have no objection to having a style sheet that defines what the tag does. But it should at least be possible to have a center tag and a vertical-center tag. AFAICT it is not possible. At the very least you need both a center-capable container and centered elements.

Re: A div that looks different in every browser

#43

Post by ben0x539 » Sun, Jul 08, 2018, 9:33 PM UTC

chiefalchemist wrote: post #41

tgummerer wrote: post #38

Earlier quoted context omitted.

Especially C++ compilers have undefined behavior

Yes. But are you going to to use 3 to 5 or mote C++ compilers on a given project? The worst part of these frontend issues is, ultimately, the UX can become inconsistent, if not mess. Given that nearly everyone interfaces via the visual UI, you'd think we'd have this sorted out by now.

If your project is a library, I'd expect that people are gonna use it with, like, maybe not 5 but probably 2 or 3 different compilers, and they're gonna be less diligent about upgrading their compiler versions than mainstream browser users.

Re: A div that looks different in every browser

#44

Post by Dylan16807 » Sun, Jul 08, 2018, 9:34 PM UTC

rvense wrote: post #40

lisper wrote: post #32

Earlier quoted context omitted.

The code shown on that page actually doesn't work, though the code in the github repo does. And this exposes the problem with the current state of the art: yes, you can probably get flexbox to do what you want [@] if you know how. But if you don't know how, trying to figure it out is still very hard. You should be able to write: stuff or stuff There is really no reason that should not Just Work. (The tag has worked f…

You should not be centering things in HTML, that's the stylesheet's job.

Sure, what's the CSS to make a div be centered vertically?

Re: A div that looks different in every browser

#45

Post by Buge » Sun, Jul 08, 2018, 9:47 PM UTC

jayd16 wrote: post #31

dopamean wrote: post #2

On one hand I think this is really neat. On the other this is why I have never taken front end development seriously enough to spend any real time learning it [0]. From the get go it always seemed like the rules were arbitrary and involved lots of guessing to get things right. I know this isn't actually true but it felt true enough early on to poison my mind to it. [0] Not something I'm proud of and I know front end…

This isn't really a spec thing. Its more a manifestation of undefined behavior. Even c++ compilers have undefined behavior.

But in c++ when there's undefined behavior, the spec specifically says there's undefined behavior. It doesn't sound like the spec is specifically saying there's undefined behavior in this case.

Re: A div that looks different in every browser

#46

Post by olliej » Sun, Jul 08, 2018, 9:56 PM UTC

jayd16 wrote: post #31

dopamean wrote: post #2

On one hand I think this is really neat. On the other this is why I have never taken front end development seriously enough to spend any real time learning it [0]. From the get go it always seemed like the rules were arbitrary and involved lots of guessing to get things right. I know this isn't actually true but it felt true enough early on to poison my mind to it. [0] Not something I'm proud of and I know front end…

This isn't really a spec thing. Its more a manifestation of undefined behavior. Even c++ compilers have undefined behavior.

I worked in web standards bodies for many years (mostly TC39, but also the initial webgl spec, and random clumps [mostly canvas] of the dim specs)

One of the goals of all the web related committees for more than a decade has been to ensure that there is no undefined behaviour. Undefined behaviour is exactly the reason we used to have to have different versions of a webpage for every browser.

The only intentionally remaining ambiguities are in areas where there is significant existing content that depends on mutually incompatible behaviour, eg: content that does one thing in browser A, and another in browser B, but is using the same API in each path yet expecting different behaviour. I can’t recall any specifics off the top of my head any more, but a classic has always been for(in) enumeration along the prototype chain when properties are being added and removed. @dbaron or @brendaneich (that his account? I can’t recall) may recall some of the others. Prefixes (that everyone on HN hates) solved this problem - it makes it possible to keep that old non-spec API around, without permanently screwing up the final specification (every points to those old -webkit-gradient properties, but forgets that that api was much clunkier to use than the final gradient spec. If the prefix hadn’t existed then the webkit api would be the permanent one that everyone would have to use)

The other big one where there’s specified behaviour that is allowed to vary is webgl. I was kind of responsible for the hated “only support the minimum subset” rules of version 1, but I believe modern specifications allow an implementation to vary according to hardware. The only other place in webgl that I made people (gpu engineers mostly) unhappy was not allowing undefined behaviour when accessing beyond the end of an array in the shader - there were voices that literally wanted to allow this to be undefined for perf reasons even when shown you could read data from other execution environments (this was mind blowing). The compromise in the end was allowing an implementation to return either zero, or some other constant defined value (I think this would fall under the C/C++ “unspecified” behaviour banner).

Anyway, in general undefined behaviour is bad on the web, and all web spec authors try to ensure that every edgecase is covered explicitly so that we never get stuck back in the terrible 2000s again.

Re: A div that looks different in every browser

#47

Post by avip » Sun, Jul 08, 2018, 9:58 PM UTC

cjhanks wrote: post #36

I would think undefined behavior would be helpful in browser fingerprinting.

Using actual rendering for fingerprinting is a serious perf. hit. I'm not aware of any production setup using that.

Re: A div that looks different in every browser

#48

Post by niutech » Sun, Jul 08, 2018, 10:02 PM UTC

Dylan16807 wrote: post #44

rvense wrote: post #40

Earlier quoted context omitted.

You should not be centering things in HTML, that's the stylesheet's job.

Sure, what's the CSS to make a div be centered vertically?

display: flex; align-items: center;

Re: A div that looks different in every browser

#49

Post by markmark » Sun, Jul 08, 2018, 10:02 PM UTC

tmd83 wrote: post #15

moron4hire wrote: post #10

Earlier quoted context omitted.

Try writing C meant to compile in different compilers, on different processor architectures. Or ANSI SQL meant to run in a variety of RDBMSes. Web GUI is not the only bastion of arbitrary behavior. I would wager, if your goal is to make as wide-spread, cross-platform GUI as possible, a Web GUI is the easiest way to do that, for both the developer and the users.

C has a much bigger baggage. I assume a big chunk of C is modern version of compilers is fairly gotcha free. But even the core basic part of Web is full of gotcha. Just the fact that you need to start with a normalize.css is reason enough. And as they fix compatibility in 1 things, they seem to add 10 more. Maybe I'm wrong and clueless. But web seems to be a bastion for adding overly complex solutions while failing a…

As someone who came from "native" gui development and has only really been doing web stuff seriously for a few years, it's pretty easy now, particularly if you don't need to support IE, and even IE11 isn't _too_ much of a pain. I've never used a normalize.css for example.

Re: A div that looks different in every browser

#50

Post by Moru » Sun, Jul 08, 2018, 10:03 PM UTC

qudat wrote: post #26

dopamean wrote: post #16

Earlier quoted context omitted.

This is a great point and I appreciate you pointing it out. Cross platform development is hard regardless of which part of the stack you're developing for. The reason development for the browser stands out for me is that when I build a web app I can control to a certain extent what environment the server is deployed in and then I don't have to worry too much about different platforms. However I have no control over w…

It's pretty easy to control, just detect which browser and throw up a screen saying that browser isn't supported or "use at your own risk." I don't see any distinction between cross platform support and cross browser support.

That is not support, that is denial of service and isnt an option for most webpages.