I read this story a few months ago, it had a few more details then.
They tried giving them iron cookware, but they didn't like the weight. They then tried putting a random piece of iron in with their cooking, but not many kept up with doing it. That's where the idea to shape the iron like a lucky fish came from, and it seems to be working.
> Wish there was another standard that could co-exist side by side on the web, something simple enough to be implemented reliably by the browser vendors.
That standard exists. It's called flexbox. It was designed to solve exactly this problem (among many others), and does.
That said, as I never tire of mentioning, vertical centering was a part of the design of CSS 2.1. The technique is called "absolute centering". See CSS 2.1 10.6.4 : "If both 'margin-top' and 'margin-bottom' are 'auto', solve the equation under the extra constraint that the two margins get equal values."
Nothing happened to it. It gets used by front-end developers every single day. I personally can't follow the CSS complaints. It is easier to learn than any other front-end dev language in one's toolkit.
Yeah, everyone did a really bad job of evangelizing absolute centering back in the day, leading to lots of angry Web developers and awful hacks like the inline-block/vertical-align trick. It should have been the first example given for "position: absolute"…
Exactly. I haven't done HTML layout since circa 2000. I tried WPF about 8-9 years ago and well, it was just simple to get layouts right. I'm sure there's some reasonable reason for it, I just don't understand why browsers couldn't do similar, or just rip off WPF.
as someone who's done both (and web) -- Android's XML layout is easily the best of Android, iOS, and web, while iOS's AutoLayout is a complete mess that basically only works because there are still so few iOS screen sizes. Android coding in general is a pain compared to iOS, but they definitely got the declarative layout system right.
iOS developer here. AutoLayout is definitely not borderline magic, and some people hate it.
It is inefficient. It is awkward to set up in code, so many people write their own syntactic sugar around it. It crashes hard when it isn't 100% sure what to do with its constraints. Working with multi-line text is still a pain, so you often run into clipped text on iOS if you dare to increase the font size. etc.
Unlikely; these things usually take some time to do (advisors provide feedback, multiple edit sessions likely, reviewed by lawyers, etc). I can't see them pulling this out so quickly...though I guess it's certainly possible just seems unlikely to me.
I wonder if there is any data out there to show how long executive orders typically take from conception to execution.
I don't think it's a knee-jerk reaction. For me it's easier to believe that this EO was signed deliberately to make every important security researcher guilty by default. It's hard to go against a government that can always punish you for what you have already done.
Hi, technical question from a long-time iOS developer here, i hope you can put my concerns at ease:
How, when you're running JS on a different thread to the iOS main thread, do you avoid race conditions? A simple example:
* Say a button's event handler pushes a new view controller onto the navigation stack, what's to stop the user from tapping the button twice very quickly before the JS thread gets a chance to service the first tap, eg it may be garbage collecting or busy elsewhere, and once it's free again it runs the handler twice and pushes two view controllers onto the navigation stack?
Looks great by the way, i'll certainly check it out.