Earlier quoted context omitted.
display: flex; align-items: center;
Doesn't work unless you have an extra container div.
This is true, but every 'modern' DOM that I've seen has loads of extra container divs precisely to allow post hoc layout.
A div that looks different in every browser
61–70 of 133 posts
Re: A div that looks different in every browser
#62On 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…
" 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.
Re: A div that looks different in every browser
#63Re: A div that looks different in every browser
#64Earlier 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.
Does a single compiler work exactly the same on every architecture? :D
Re: A div that looks different in every browser
#65Earlier 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.
> 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.
Re: A div that looks different in every browser
#66Re: A div that looks different in every browser
#67Earlier quoted context omitted.
Flex box https://philipwalton.github.io/solved-by-flexbox/demos/verti...
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?
Re: A div that looks different in every browser
#68See also this https://mobile.twitter.com/frivoal/status/101544179390147788...
I think one of the most optimistic things to notice about these two images is that Edge amazingly appears to be correct in both cases.
It'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.
Re: A div that looks different in every browser
#69Earlier quoted context omitted.
I think one of the most optimistic things to notice about these two images is that Edge amazingly appears to be correct in both cases.
It'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.
Actually, 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/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.
Re: A div that looks different in every browser
#70Earlier quoted context omitted.
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 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 renderings are valid per CSS 2.1 (though I don't think they are per CSS UI 3 or 4? but maybe that's still a SHOULD level requirement given people wanting to publish as REC ).
The CSS WG has been pretty poor at actually tightening up specification for old features (on the face of it, due to lack of editorial time, which really points at a separate problem).
(Also, given the for(in) example, as I'm sure you know but for the benefit of others, note that iteration order of each object on the prototype chain is still undefined, and not interoperable.)
Some other good examples of things that have been standardised over the past decade: HTML parsing(!), what specific DOM exceptions are thrown all over the place, when the various document load events fire.