And here's what it looks like in Servo: https://i.imgur.com/lv3xRhi.png
Also, Firefox nightly with WebRender: https://i.imgur.com/Ffg0bS7.png
A div that looks different in every browser
81–90 of 133 posts
Re: A div that looks different in every browser
#82Re: A div that looks different in every browser
#83And GoogleBot seems to follow Safari's rendering instead of Chrome: https://developers.google.com/speed/pagespeed/insights/?url=...
Maybe chrome/blink require too much ram so they used WebKit /s
Re: A div that looks different in every browser
#84Earlier quoted context omitted.
" 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.
This 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.
Nah, 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? ;)
Re: A div that looks different in every browser
#85At least Brave is consistent with Chrome, as they're both Chromium-based. Phew.
my Brave browser on mobile shows up as same as Safari one.
Re: A div that looks different in every browser
#86Earlier quoted context omitted.
" 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.
This 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.
Yeah and then they all jump around React as some amazing achievement, having rediscovereed how 90's native UI do event handling.
Re: A div that looks different in every browser
#87Earlier 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…
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?
Re: A div that looks different in every browser
#88It 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?
Because 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.
Re: A div that looks different in every browser
#89Earlier quoted context omitted.
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 re…
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
Re: A div that looks different in every browser
#90Earlier 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…
So should there also be a and a and a and and and and and...? If you want to lower left align you set align-items and justify-content to flex-end and flex-start. For upper right, flip those. (if you’ve changed flex-direction those will need to shuffle around.) I seriously don't understand why having a different tag for every possible alignment would be somehow easier or more discoverable than just using css rules. No…
I would prefer halign=left/right/center/justify, valign=top/bottom/center. But yes.