16 ms·
A div that looks different in every browser
- dopamean 8y agoOn 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 development is serious business so don't @ me.
- moron4hire 8y agoTry 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.
- tmd83 8y agoC 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 at trivial things often enough not always. I agree it is probably still the cheapest way to get a cross platform GUI at least maintenance wise. But it is a pile of electricity sucking horrendous crap regardless or at least a big part of it. More frustratingly I'm not sure that it has to be the case.
- markmark 8y agoAs 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.
- dopamean 8y agoThis 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 which browser my user chooses to use and that can have a serious impact on their experience. An impact that I have to account for.
- qudat 8y agoIt'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.
- Moru 8y agoThat is not support, that is denial of service and isnt an option for most webpages.
- amelius 8y ago> 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. I guess you aren't into Deep Learning either ;)
- bryanrasmussen 8y agoMost programming/development environments/standards have arbitrary rules. Also most workplaces I've found. It's arbitrary almost all the way down.
- duxup 8y agoIt is frustrating as here we are in 2019...er 2018 and structring a page is still kinda wonky.
- robbrown451 8y agoHonestly its getting rarer and rarer to find things like this, most things that reasonable people want to do "just work." You have to go to considerable effort to come up with a case like this.
- mvdwoord 8y agoWhat is the status quo on vertical alignment if I may ask..
- evan_ 8y agoFlex box https://philipwalton.github.io/solved-by-flexbox/demos/vertical-centering/ https://philipwalton.github.io/solved-by-flexbox/demos/verti...
- lisper 8y agoThe 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: <center>stuff</center> or <vertical-center>stuff</vertical-center> There is really no reason that should not Just Work. (The <center> tag has worked for 20 years, notwithstanding that it has been deprecated for most of that time.) --- [@] What if I want to put something in the lower left or upper right hand corner?
- rvense 8y agoYou should not be centering things in HTML, that's the stylesheet's job.
- lisper 8y agoI have no objection to having a style sheet that defines what the <center> 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.
- jayd16 8y agoThis isn't really a spec thing. Its more a manifestation of undefined behavior. Even c++ compilers have undefined behavior.
- tgummerer 8y agoEspecially C++ compilers have undefined behavior
- chiefalchemist 8y agoYes. 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.
- ben0x539 8y agoIf 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.
- chiefalchemist 8y agoThanks. I wasn't thinking about it that way. Good point. That said, the browser's impact on UX is essential. A lot more people use browsers than compilers. You'd think the UX would matter by now.
- ravenstine 8y agoDoes a single compiler work exactly the same on every architecture? :D
- de_watcher 8y agoYou're using the words wrong. The code may have undefined behaviour. For example, a race condition is an UB. Compiler won't invent locks that were not specified by the programmer in a code with some raw threads. As a result, CPUs will trash the memory.
- krsdcbl 8y agoSo you're saying other dev domains don't have intrinsic glitches and oddities? ;)
- billybolton 8y agoForcing 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.
- crimsonalucard 8y agoStill 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.
- billybolton 8y agoOnly 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.
- sonnyblarney 8y ago" I know this isn't actually true " It's true. A confluence of vague definitions, poor implementations, bad documentation ... and this is the web we have. It's the tip of the iceberg, and the painful life of anyone doing html5 work, it's 'not fun' for anyone who's been exposed to regular programming because the problems you spend your day solving mostly should not be problems to begin with.
- shawn 8y agoThis is what us older people would like to believe. Meanwhile the young webdevs are having a blast ignoring us and building the apps of the future.
- King-Aaron 8y ago> having a blast ignoring us and building the apps of the future Building technical debt for the future I tend to think, which I guess is good for keeping future devs employed.
- sonnyblarney 8y agoMy experience is that young web-devs don't even know the dystopian matrix they live in, and when they discover 'regular programming', in many ways their perspective changes. Both web and regular dev have their faults but the the King of Byzantium is HTML5.
- BigJono 8y agoNah, it's mostly true (I'm one of those young webdevs), but I'd attribute the pain points in front-end development to slightly different problems than the state of browser inconsistencies and spec problems. IME 70% of the problems people run into are self-inflicted due to overengineered solutions. I spend a lot of time lurking front-end IRC channels and most of the problems that get posted is stuff that I have never had trouble with, with libraries I'd never even consider using, that I don't have the first clue how to fix without going back to square one and re-engineering the solution from the ground up. The advice given by people that do attempt to help with these problems is often awful and creates more confusion. For the most part, I don't think people realise that libraries add to the complexity of their software, rather than abstracting it away. Every front-end dev desperately needs to go and read the Law of Leaky Abstractions, because they're getting smoked by it on a daily basis and they don't realise. The other 30% of problems come down to what GP mentioned, ambiguous specs, browser inconsistencies etc. Stuff like the relationship between x-overflow and y-overflow, little flexbox niggles like different behaviour depending on if flex-direction is set to row or column etc etc. This stuff can often be worked around with simple but unintuitive fixes (usually some fuckery with negative marigns and such), the two difficulties lie in discovering the solution to begin with (there's boatloads of bad and outdated advice everywhere), and running into these solutions when they haven't been properly documented (usually the case if some junior programmer has just ripped the hack off SO without understanding the theory behind it). The secret to being good at front-end dev is to develop strategies to handle these problems, and to pick your resources very carefully (much as you would in any other ecosystem beset with noobs, like PHP back in the day). I believe (based on my experience) that it's possible to build very successful software with very horrible engineering. Good and successful aren't necessarily synonymous in the world of big VC money. A great example is this: I need two hands to count the critical failure bugs I've run into with Uber's products in the last year. By critical failures I mean things that have flat out stopped me from being able to use it. I strongly suspect (a subset of) their engineering sucks (sorry to anyone here that works for them!). But hey, I don't own a squillion dollar company so what do I know? ;)
- webwebweb 8y agoAnd GoogleBot seems to follow Safari's rendering instead of Chrome: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fcodepen.io%2FMartijnCuppens%2Fpen%2FMXojmw&tab=desktop https://developers.google.com/speed/pagespeed/insights/?url=...
- Operyl 8y agoI wonder if that’s because they’re just running an older version of WebKit/blink.
- kevingadd 8y ago"Chrome's" rendering in many cases is going to be whatever hardware accelerated stack (probably Skia + your platform's particular hardware API) is rasterizing the page. Headless rendering as found in a page scraper bot is more likely to be using software rasterization and might be using an entirely different API. Chrome has a few command line flags that can push everything through different rendering paths and you can get different results from it.
- bla2 8y agoBlink (the HTML engine) is still going to push the same drawing commands to all the backends. Winding rule order stuff might be different if a backend is buggy, but things like this shouldn't be different.
- LukeShu 8y agoI wouldn't be surprised at all if there's a drawing command that's having a negative number passed to it in a place where it doesn't expect negatives. I wouldn't be too surprised if different backends handled this "undefined behavior" differently.
- gsnedders 8y agoNah, this will all be handled within Blink. The drawing command will literally be told to draw polygons in the specific places in the coordinate space.
- JBiserkov 8y agoSee also this https://mobile.twitter.com/frivoal/status/1015441793901477888 https://mobile.twitter.com/frivoal/status/101544179390147788...
- Sniffnoy 8y agoNon-mobile link: https://twitter.com/frivoal/status/1015441793901477888 https://twitter.com/frivoal/status/1015441793901477888
- bfrydl 8y agoI think one of the most optimistic things to notice about these two images is that Edge amazingly appears to be correct in both cases.
- PeCaN 8y agoIt's pretty clear that Microsoft really took a close look at the specs when developing Edge, which is really nice. It also has the benefit of being the newest of the major engines.
- chrismorgan 8y agoActually, much of the time it comes down to what bugs people report. In a closely related area, IE and Edge both added spread distance rather than subtracting it on inner box-shadows until I reported it last year, then it was fixed in IE within a month: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/12515080/ https://developer.microsoft.com/en-us/microsoft-edge/platfor.... In this particular case, they may have got the best of it because IE didn’t support outline-offset at all, and so when they implemented it they read the spec carefully. Edge is a continuation of IE. Large swathes of the renderer have been rewritten, but when you do find bugs in Edge they’re commonly shared with IE.
- chrismorgan 8y ago(Correction: fixed in Edge within a month; IE doesn’t get such fixes. Also “IE and Edge both” should read “both IE and Edge” for increased clarity.)
- crazygringo 8y agoIs one of these correct? Or is this combination of CSS properties ambiguously or un-defined by the spec in the first place?
- ToFab123 8y agoFrom the person that wrote the code: "The specs are pretty vague about how this case should be rendered, but I think Edge handles it correctly here"
- adtac 8y ago>The specs are pretty vague about how this case should be rendered, but I think Edge handles it correctly here
- lucideer 8y agoThe code in question can be mostly boiled down to: outline: inset 100px green; outline-offset: -125px; The issue is: - spec is deliberately liberal about how outline should look (this is kind of a similar case to forms and scrollbars, the styling of which varies not just by browser, but by OS/toolkit) - inset is a keyword rarely if ever applied to outlines (and I'm not sure why it's even valid or what it's purpose would be) - outline-offset is a useful property, with well defined behaviour in most cases: inset outlines are the exception where its behaviour is ill-defined Edge's behaviour is probably technically "closest" to what I would expect, but I'm not sure if "correct" is the right term. It's an odd case, and what it should look like is debatable. IE's and Safari's could be "correct" either, and in fact IE's kind of looks truest to the intent of outlines as a thing. Chrome is doing very bizarre things and I can't really fathom why. They look like rendering bugs. Edited after a 2nd look, IE's and Safari's make a bit more sense after some consideration.
- LukeShu 8y agoFiddling with it: Firefox's mistake is definitely that it isn't handling having outline-offset less than "-min(width, height)/2" in a sane way. (In the demo, width and height are both 100px; it starts do do funny things when outline-offset goes below -50px). That said, I'm not entirely sure that there is a sane way. IE is totally ignoring the outline-offset property; it isn't implemented in IE.
- TeMPOraL 8y agoPretty. I could see various renders used as a logo for each respective browser.
- KwanEsq 8y agoAnd here's what it looks like in Servo: https://i.imgur.com/lv3xRhi.png https://i.imgur.com/lv3xRhi.png
- kibwen 8y agoI was 50/50 on whether this would be a legitimate rendering or a cheeky screencap of a panic message. :P
- KwanEsq 8y agoWhat I found interesting was that I later noticed Matt Brubeck had already done the same thing a couple of days earlier [0], yet mine in the nightly I'd just downloaded was already different. [0] https://twitter.com/mbrubeck/status/1015310959789740032 https://twitter.com/mbrubeck/status/1015310959789740032
- creatonez 8y agoAlso, Firefox nightly with WebRender: https://i.imgur.com/Ffg0bS7.png https://i.imgur.com/Ffg0bS7.png
- niutech 8y agoHere is how it looks in GNOME Web Browser: https://twitter.com/niu_tech/status/1016087312554450944 https://twitter.com/niu_tech/status/1016087312554450944
- deleted 8y ago[deleted]
- 21 8y agoIt seems to me that this example is like undefined behavior in C.
- systoll 8y agoHere's an animated version with some transparency https://codepen.io/anon/pen/PaMVYX?editors=0100 https://codepen.io/anon/pen/PaMVYX?editors=0100 The root issue is that the browsers are being asked to draw a line that's 100px in from the edge of a 100px box -- it's an impossible task, so there's no perfect solution. This CSS test suite http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/xhtml1print/outline-013.xht http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/x... suggests that browsers should treat it as though it were the largest offset that made sense at the current outline width, giving you https://codepen.io/pjwdev/pen/vrovPR?editors=0100 https://codepen.io/pjwdev/pen/vrovPR?editors=0100 Safari achieves this if the border is the same colour the whole way around, but doesn't get the individual sides in a sensible arrangement. Edge doesn't match the test, but it does another reasonable thing -- it takes the offset as a given, and uses the biggest outline width that makes sense. Chrome and firefox...
- gsnedders 8y agoThe negative value case is: > Negative values must cause the outline to shrink into the border box. Both the height and the width of outside of the shape drawn by the outline should not become smaller than twice the computed value of the outline-width property, to make sure that an outline can be rendered even with large negative values. User Agents should apply this constraint independently in each dimension. If the outline is drawn as multiple disconnected shapes, this constraint applies to each shape separately. There's a lot of RFC 2119 SHOULD there, unfortunately.
- coldseattle 8y agoMicrosoft is the only one that gets it right.
- cjhanks 8y agoI would think undefined behavior would be helpful in browser fingerprinting.
- dmurray 8y agoWhat do CSS linters have to say about it?
- r-w 8y ago“No”
- BadassFractal 8y agoAt least Brave is consistent with Chrome, as they're both Chromium-based. Phew.
- withdavidli 8y agomy Brave browser on mobile shows up as same as Safari one.
- r-w 8y agoWebKit is the only renderer on iOS.
- Froyoh 8y agoI trust edge more than any other browser.
- madrox 8y agoIt blows my mind that problems like this exist, and yet platforms like Unity and Xamarin are capable of write-once-build-everywhere apps on every platform. Why hasn't web development abstracted away these problems yet?
- pjmlp 8y agoBecause many webdevs think that our grey bears and knowledge of doing native applications are worthless, and who does native anyway. I look forward to native still winning on mobile for the years to come, with WebAssembly eventually becoming Flash's revenge.
- nadsumatal 8y agoJoke: 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 picture framing shops and posted them on twitter, getting a lot of attention on Hacker News as well. edit: present tense.