Hacker News Reader

Comment by prohor | Hacker News Reader

Yes like this one - just dropping part of current SVG standard that was supported by all browsers. Without any notification and replacement it broke some sites. Why? Because it was too much code, low adoption and it is depreciated in SVG 2.0 draft.

https://bugs.chromium.org/p/chromium/issues/detail?id=539385

View on HN

Actually, Chrome dropping a feature that was removed from a spec, was a lot of code and had low adoption sounds like a good idea.

Engineering is always about trade-offs, and choosing a good balance in Chrome is what made it so popular. The parent of this comment was worried about Chrome's "dominance", but remember Chrome was the last browser to the party. Safari's dominance appears to be the reason Firefox added -webkit prefixes.

If you really think the SVG feature was important and Chrome should support it, then lobby for it to be part of the standard and for other web developers to use it. But it's not a great example of Chrome pushing its whim on others.

Isn't that the point though? This is part of the standard, and was being used by developers. Not many developers, but then I'm pretty sure that there are parts of lots of standards that are barely used - doesn't mean we just go around taking them out because we feel like it.

The best part of Firefox/Netscape/Chrome/Safari/Opera eating IE's lunch was that they all converged (roughly) on standards compliance, so we didn't have to have "Built for IE 6.0" stickers all over everything. Chrome ditching parts of the standard just because they don't like it is the fast track back to there.

Yes, but the problem it is part of current standard, 2.0 is still work in progress. Also alternative API from SVG 2.0 is not yet delivered by Chrome either as far as I know.

The Chrome team removed something that there was agreement across all browsers to deprecate, and which was made optional in a near-finished spec.

Also, it's perfectly typical for drafts to be what implementers are targeting, as plenty of published specs receive almost no errata and any issues in them only get addressed in new revisions.

The comments in that thread are really saddening.

I feel sorry for those developers that have suddenly had their applications broken for them on a whim by the Chromium team.

I write JS code and deliver it to clients. What will I tell them when their website widgets break because Chrome removed SVG support entirely?

Give them a thumbnail explanation of what Chrome did, and suggest a more inclusive browser.

But they don't decide what browser their customers use.

Then suggest that they detect browsers, and put up a little non-distracting version of your thumbnail explanation to their customers. :)

If this is truly distracting or breaking to your clients' customers, then someone is going to have to do or say something.

The terrible truth is that consumers don't give a shit about standards, freedom, and the greater good. They just want the website to work with the least amount of effort possible.

Lets turn this around:

The terrible truth is that some web devs don't give a shit about web standards. They just want the site to look good on their iMac with Safari. So now we have huge webkit emulation layers in all major browser...

Or to turn it around:

The terrible truth is that Chrome don't give a shit about standards, freedom, and the greater good. They just want to write their code with the least amount of effort possible, standards be damned.

I don't understand your logic here.

Are the costumers using Chrome? Then devs should test on Chrome too.

Are the costumers NOT using Chrome? Then what is the problem??

The problem is that it was tested and working in chrome, until they decided to remove that feature.

The consumers are using different browsers. People who write HTML are often not very competent and cannot make page display properly everywhere.

I use Chromium (because unlike Chrome it is open source). Video playback doesn't work even on twitter and vimeo (who can afford to hire good developers) let alone smaller websites. But it works on Youtube (not always, some videos require flash) and Wikipedia.

UPD: That is why I think people sould learn from Wikipedia developers and not some hipster guys explaining how to connect Redux to Angular2 using ES7.

Video playback doesn't work even on twitter and vimeo

This is because they use H.264, a patented but common video codec. Chrome includes a licensed decoder for it, but Chromium cannot include that because it's open source. Firefox "solves" this by relying on installed system libraries (for video) and a licensing hack by Cisco (for WebRTC).

Your experience is a pretty good illustration that Chromium is not the open source version of Chrome.

Chromium might not support H.264 but it supports VP8 and some open source codec Wikipedia uses. So the problem is with developers relying on proprietary codecs.

H264 isn't proprietary, it's patented. Anyway, like my own post here, what you say is factually right but besides the point. Users expect H264 to work or the web will break. Like -webkit prefixes.

> Are the costumers using Chrome? Then devs should test on Chrome too.

I do test on Chrome! The context is Chrome removing standardised features with no warning years down the line, breaking existing deployed content.

What do you expect a web developer to do in that case?

No amount of the Chromium team being hostile to web developers will stop people from using Chrome. Yet so long as the Chromium team are breaking websites using standardised features without warning, the web developer's life will be pain.

It is bad idea to rely on new features anyway. How will your website work in a 5-year-old browser?

Like on a 5 year old browser. Honestly, unless you develop for government I don't see any reason to consider 5 year old browsers. Do you develop apps for iPhone 1 or Android 1? The web is already behind anyway...

New features? Chrome was removing an old, standard web feature supported everywhere for years.

Css regions was included in Canary and ousted because it was too much code too (and because basically the Chrome Team didn't like the spec.) And I'm not talking about the half baked html5 widgets like datepicker ...

Reply on news.ycombinator.com