Hi, I happen to work on Google's Maps JavaScript API, and we actually take great pains to avoid breaking our APIs as much as possible. We take very seriously the implications that breaking changes can have for websites all across the internet, and know that many sites are not under active development.
This page covers the breaking changes from the last few years: https://developers.google.com/maps/deprecations#completed_de...
(Keep in mind that the top portion of the page covers features still in the deprecation period - meaning they still work. And that this page covers deprecations in other APIs like Android and iOS.)
My favorite: the deprecation period for v2 of the Maps JS API lasted 11 years after the introduction of the v3 Maps JS API.
Happy to hear about experiences to the contrary, but I thought a little insight might be appreciated.
Indeed I'm looking at this from a long time frame. From recollection the main breaking changes I'm aware of:
1. The change from v2 to v3, like you mentioned.
2. The new requirement to always include an API key.
3. The visual update to touch-sized controls, distorting especially tiny embedded maps.
Appreciate the feedback. #2 is actually a pretty interesting one - while clearly a change in the API’s output, we were careful to make it so that maps without API keys actually still work (though they do get a heavy visual indication that they need to get an API key).
That being said, when we are talking about such large timeframes, is it fair to portray that as “regular” breaking changes?
Yes, within the context of the type of sites I was discussing. You already indicated that you know that they are not actively maintained. Knowing that, it doesn't really matter if a breakage happens every year, 3 years, 5 years. There's no point at which it becomes "OK", if you believe in the long time preservation of content.
I'm not picking on maps specifically. It's a compounding effect of many individual parts slowly breaking. I would even agree that you did a reasonable job of maintaining backwards compatibility, but that doesn't matter...broken is broken. Content gone is content gone.
For all those saying that ARIA trumps semantic elements, consider that for basic interactions semantic elements come out of the box keyboard accessible.
For example, a <button> will have default tabindex=0 and respond to spacebar key presses, but you'd have to add that yourself if you put role=button on a <div>.
In short, if there is a semantic element that matches your need, use it.
If people could agree on what "look good" means, I don't think it'd be impossible to get the major browsers to update default styles. But every site seems to have a different idea of the look they want.
I'd be curious to see a somewhat-objective look at what's actually wrong with default browser styles, separating out well-established usability and design considerations from personal preferences and branding preferences. I wouldn't be at all surprised if there are near-universal things wrong with the default styles, and those might be possible to change if they can be separated out.
Based on my experience as a web developer working with many designers over some 20 years of design trends, here’s the problem:
Default styles aren’t pretty.
That’s it. They’re superior in every other way. You always know what to click, you always know what an element will do, how it behaves, the UX is consistent with your OS, etc. Default elements are fantastic.
Buttons in Chrome on macOS look completely different than in native apps.
Buttons and context menu in Chrome's native <video> controls look yet again different, following Material Design.
From the things one could argue are good about native browser styles "consistency with the OS" is definitely not one of them.
Depends on the element, the select and input elements are notoriously difficult to style, which is why people often remake them with divs and JS.
Combo boxes are a fucking nightmare to style, as are checkboxes and radios. Buttons arnt as bad, but you still spend a lot of time fighting against browser defaults which differ across browsers.
For some elements, yes. Many others have certain attributes that are completely unstylable, a lot of browser-specific attributes and selectors (not just prefixed attributes but also whole pseudoclasses), or both.
The one exception for me are forms. In that case I would rather use a div or section tag with role=“form”. I have seen less experienced developers do weird things with form tags and submit event and form tags have unique behaviors associated and requirements.
When a form requires JS to be submitted, there’s a high probably that I abandon that website instead. My expectations of working plain HTML are never higher than with regard to forms. By all means, progressively enhance, but don’t be tempted by the hubris of claiming to know better than the user-agent how the user-agent should work. It’s not just rude, it’s a slippery slope towards systematic incompatibility, weirder bugs than the ones you were afraid of, and security holes.
> When a form requires JS to be submitted, there’s a high probably that I abandon that website instead.
You say that, but I doubt that in practice. If the form is your bank login or bill pay or anything else you are locked into I really doubt you will give up because of some personal opinion on JavaScript and instead spend the next 30 minutes calling somebody to complete a similar action over the phone.
The goal is to achieve accessibility as equivalently as possible, with as little enhancement as possible, and yet often not force a page change because of form submission.
Does that still allow you to press "Enter" in an input field to submit the form, or do you have to build your own kludge to replicate that? If so, that sounds like that would invite only more weird things...
You are clearly underestimating the compatibility & accessibility challenges of reinventing the form submission code of a web browser from first principles.
Believing you can do so and not fuck it up is sheer hubris, not to mention, wrong. Doing so because you don't like the browser edge cases, is how websites end up suffering from even more edge cases, and harks back to the bad old days of "Sorry your browser is not supported".
Financial institutions are amongst the worst offenders - ironic since pulling this kind of naïve stunt vastly increases the attack surface. I've been in a position to redesign financial institution systems and rewrite their technology policies, and when doing so this kind of off-standard NIH crap is something I seek to stamp out.
Want to submit a form? Use a damn form, with a plain old submit button, and rely on the standard behaviour. Want to put some UI polish around it? Progressively enhance the standard behaviour.
What not to do: imagine you can write better UI<>protocol interaction code than that already in Chromium and Webkit, or hope to infer and reimplement the behaviours of any more specialised user-agents.
What you said. Most of what you said is common anti patterns. The reason is web technologies are built around a few set of standards that are designed for extension, such as the DOM and WCAG. Fearing those standards for a small set of static principles is common but that doesn’t make it smart. That’s why this technology space is so hostile to originality. You mentioned NIH but the more common problem is: https://en.m.wikipedia.org/wiki/Invented_here
Stop being so afraid and hostile. Embrace how these technologies work and more easily achieve accessibility with less effort. If you are waiting for some tool, NPM package, or framework to do it for you it’s not going to happen.
Abusing standards with shoddy inner-platform reimplementations doesn’t make someone an innovator, it makes them as much a fool as the cargo-cult of the NPM ecosystem.
So you think it's safer to rely on every engineer adding that (and the other facilities provided by web browsers by default when using native elements) to every input field in a form, than relying on them not doing weird things with that one form tag?
That doesn't sound worse than not naming the inputs or coding the buttons for keyboard interaction, things inexperienced developers will do if they're not educated in the basics of semantic HTML (even those who do use inputs too often neglect to associate a <label> where they're called for).
Forms cannot be nested. That is an html violation. That is because all submit events fire on all nodes contained by a form on submission even if the page does not go anywhere. Forms also require an action attribute that contains a submission address, which requests a new page on submission.
Not the same thing as nesting forms, but when faced with similar challenges I found the <input form="form-id" /> attribute[0] is a good solution.
The trade-off is that you have to specify it almost every single time, but it lets you group form elements that for UX purposes belong together, but for other reasons need different forms.
If a dev finds a form to be nested, it's usually because something was tacked on as an afterthought. I'm speaking from experience.
I had a project that had applications associated with it. Forms are the natural way to express this. There were some disclosures associated with the application, and there was a modal associated with emailing the disclosures. I needed to add some front end validations to this modal.
No matter what I tried, I could not get these validations to trigger correctly. I spent an entire work day on trying to get a library to work with this modal. It wouldn't work, because changing the modal's div to a form tag would cause errors or unexpected behavior due to the nested form tags.
TL;DR: Nothing requires it. Devs might not understand the implications.
I don’t know, but does it matter? If an employee group understands how much they are worth, and can get more benefits commensurate with that worth, then I applaud them.
At some point it does. If they're being underpaid, that's one issue. If they're aware that they're currently irreplaceable and able to effectively hold the company hostage, that's a different one.
I don’t see much of a problem as long as the company is still making a profit. The striking workers could strike until they’re receiving all the company’s profit, at which point it would be as if they’re receiving the actual value of their labor. Not that crazy of an idea.
Maybe the company was failing anyway. I'm not saying they shouldn't strike. Just that we don't seem to have clear numbers to tell if they should or not.
This is a ridiculous statement. The "actual value" of the striking workers (pilots) labor is "ALL the company's profit?" Nobody else -- mechanics, flight crew, reservations agents, IT staff, marketing, execs -- deserves a piece? What about investors -- by definition, nobody invests in a company designed to not return a profit.
Of course I don’t mean that one specific subset of employees (e.g. pilots) deserve all the profits distributed to them at the expense of other employees. Ideally all the workers of a firm would be organized together, but I’m aware that this isn’t the current reality of this situation.
And money used to pay back loans wouldn’t be considered “profit” in any definitions I’m familiar with. If the “investment” takes some other form such that the investor expects to be paid back a lot more due to employees being paid much less than the value they’re delivering, then yeah, I’m fine with the employees organizing and saying that’s not going to happen.
>> I’m fine with the employees organizing and saying that’s not going to happen
This is even more ridiculous. Is YComb (since we're on HN) not entitled to a positive return from the companies it helped found, just because some random group of employees claims they aren't being paid according to the "value they're delivering"?
I never used the word “entitled.” I think if an investor is extracting surplus value from employees of one of their portfolio companies, the employees of that company should be free to attempt to organize to regain as much of that surplus value as they can.
You are backtracking. The initial statement you wrote said that the value of the worker's labor = ALL the company's profit. If the workers "regain" it all, there's nothing left for an investor/founder. Since this is the scenario you endorse (you've said so three times), your position is that investors and founders should not receive any return on their investment, nor any gains from establishing the company in the first place.
> The initial statement you wrote said that the value of the worker's labor = ALL the company's profit.
I didn't say that. I said that I don't have a problem with workers organizing to ask for more compensation so long as the company is earning profit. I didn't say anyone is "entitled" to anything and I didn't even predict whether or not the efforts would work.
> If the workers "regain" it all, there's nothing left for an investor/founder.
I addressed investors already. Money used to pay back a loan is not what I consider "profit," in the same way that money used to pay for office electricity is not what I consider "profit." Obviously companies have to pay their bills. As for founders, I assume they're functioning essentially as the manager/employer and thus are the party that is negotiating with the organized labor of their company. I'm not prescribing some amount of money they get to keep versus their employees—that's precisely what the negotiations will determine.
> Since this is the scenario you endorse (you've said so three times), your position is that investors and founders should not receive any return on their investment, nor any gains from establishing the company in the first place.
I have said that zero times and have now explicitly refuted it twice, lest there be any confusion about what I am claiming.
>> until they’re receiving all the company’s profit, at which point it would be as if they’re receiving the actual value of their labor
Your first comment clearly states that the value of labor is all the company's profit. ALL. You wrote it. "receiving ALL the company's profit" = "receiving the actual value of their labor". Which means, it's only possible for the airline to show a profit by underpaying labor, and therefore existence of profit = investors are exploiting labor for "surplus value." As long as you stand by the initial statement, everything that follows is crazy-talk, whether or not you're able to follow the logic of your own statements from a to b to c.
Ideally all the workers of a firm would be organized together
They are. That organisation is called a company and decides what they get paid, which varies by job and rank.
There's no such thing as a union in which every employee of a firm is represented - by the very nature of what unions do, they create a (largely imaginary) line between "labour" and "management" then pit the first against the second.
The point of the article is that yes, the scenario where pilots can claim all airline profits is ridiculous, because is it sub-optimal for everyone -- pilots, passengers, and certainly investors.
It also never argues that pilots are "delivering value" equal to the airline profits. Only that the pilots are in a position, due to regulation, to claim those profits, because they can shut the airline down (a power that flight attendants, mechanics, reservation agents, etc don't have).
Wouldn't someone who is replaceable be overpaid until they were compensated little enough such that no-one else would work for that amount?
I'm not sure if you subscribe to the notice that it's OK for the worker to max out their compensation while it's not OK for the owner to do so, but I think it's a pretty common stance. Admittedly, the reverse is also true (as I'm hoping to point out).
Ideally, I would hope that negotiations were conducted in a way that is mutually beneficially to both parties. I'd rather we didn't resort to getting as much as we can at the expense of the other party.
Of course in a dog-eat-dog world, what can we expect? All of those bastards on the other side are going to do it to us so let's do it to them first.
But is there an advantage to living in a world that isn't dog-eat-dog? Is it possible to encourage a society where neither side "does it" to the other and neither side thinks of the other as "bastards"? I really, really hope so.
(Possibly not related to your actual position -- your words just made me think of that)
I think both parties try to maximize/minimize for their own benefit, which is healthy and is exactly what determines the market for compensation.
Inherently any gain by one side is at the expense of the other, there is no avoiding that aspect. Either than $X is paid to the pilots or it goes elsewhere in the business. I'm not sure what a non-dog-eat-dog world would look like and how it would be able to persist without heavy incentives to take advantage.
It depends what's the availability of replacements. For example if almost all pilots are employed, you won't get more pilots until they're trained. Paying more than another company just moves the problem temporarily, not solves it.
Similar to what happens with expensive cities which don't expand. The prices keep raising and there will still be people who can afford to pay for a long time... until the larger environment either changes or collapses.
Sure, but those kinds of structural issues are the airline's problem. BA's pilots are underpaid if they are so in demand, and BA would have to pay a lot more to poach pilots from other airlines.
If they're underpaid, sure. (And I would assume they are) But that was the original question - what are the working conditions? If they were paid $1M a day (of course they're not), would you still say they're underpaid just because they're in demand? What about $300k a year? What about $200k?
This article doesn't say what the pay / demand is. Another one (https://www.theguardian.com/business/2019/sep/08/ba-pilots-t...) mentions BA proposing an increase that would bring "some" over £200k a year. I'm sure that's cherry-picked for PR and doesn't show the whole distribution, but it's at least one number.
If they were paid $1M and could get more then they are still underpaid and there is sufficient demand.
There is no absolute number at which they are no longer underpaid, it is completely relative to how much demand there is and how much companies are willing to pay for that demand.
If the airlines and pilots existed in isolation then maybe. If they were paid 1M, I'd think they're overpaid and the tickets should be cheaper instead. There definitely is a threshold compared to all other salaries / cost of living / economy where the pay would become irrational - regardless of demand.
I think it was pretty nice of you to use a linear scale. If a company wanted that much more of my time I would have quoted them a premium (just as an hourly employee might make overtime in such a situation).
Exactly. The utility of income is not linear. The first 10,000 dollars are much more useful than going from 190,000 to 200,000 a year. That's why the tax system has a progressive structure. If you want me to work 10% more then you need to pay me more than 10% more.
And that does not even consider that my free time is very limited. If I have say 2h of completely free time everyday (24 hours minus work, commute, chores, gym, household crap, etc) and I need to work just 1 hour per day longer, then that cuts my free time per day in half. That is HUGE. You better pay me a lot for that.
There utility of disposable income is perhaps not linear. But I can tell you I enjoyed my second raise a lot more than my first. My first raise gave me just enough to start saving money over time, no room for quality of life improvements. My second raise is what allowed me to start spending money to enjoy myself.
What the tax system doesn't respect is that my life might be better and more productive if I spent a year earning 200,000 and then took a year off, then if I worked a 100,000/year job the entire time.
I thought someone would say that :), that's a combinatorial optimization that happens to work in the exact scenario I described, and assuming no further constraints.
But you lose out if you instead want to do 2 years on 2 years off, or if your one-year employer doesn't want you to work July to June, or if your year-off plans don't work July to June, or any number of more complicated scenarios. My point stands that the system isn't designed to support this kind of irregular high-income work.
