5 ms·

>In any case, a lot of those features frankly aren't all that beneficial anyway You're clearly not on the edge of new experimental features or you wouldn't be

>In any case, a lot of those features frankly aren't all that beneficial anyway You're clearly not on the edge of new experimental features or you wouldn't be making such a claim.

Silhouette 15y ago
You couldn't be more wrong. I make my living building web sites and embedded browser-accessible user interfaces, and several of the projects I'm working on right now use state-of-the-art features with HTML5, CSS3, mobile devices and all that jazz. And I stand by my previous comment despite that.
- drivebyacct2 15y ago
  >state-of-the-art features How can you claim to use state-of-the-art features and not appreciate that those features will be more stable and more readily available than ever? And the cool new features being worked on are far, far, far more expansive, neat and "useful" (as you desire) than "css3" or "mobile devices". If you're really doing "state of the art" things, then you're probably using features that were added to Chrome and Gecko as part of one of the features that was enabled by the rapid release cycle with multiple versions and pipelines being worked on simultaneously. Further, what breaking changes have you seen as a result of Firefox and Chrome's rapid development cycle. I mean, the features I'm discussing break regularly, but then again their specs are still in a very draft status and it's known that they will break. I can't say I've ever had a stable Javascript API or CSS rule just completely change when moving from Firefox 11 to 12 or whatever. >"Much of the content on those sites doesn't even work on both Gecko and WebKit at the same time, never mind IE." Honestly a lot of your claims seem to be exaggerated or I'm on a very different subset of the Internet than you.
  - Silhouette 15y ago
    How can you claim to use state-of-the-art features and not appreciate that those features will be more stable and more readily available than ever? Because they aren't more stable and readily available than ever. Browser fragmentation is worse today than at any time in history, including the peak of the Netscape/Microsoft war. At any given time, you might have to implement a given bit of styling at least three or four times over, not because the browsers differ in their functionality, but just because they all do it with slightly different syntax. That in turn is because the browsers frequently have slightly different ways of doing things first, even if someone then wins later, which of course means everyone else has to slightly change their behaviour to match whichever standard wins. And that's before you even consider the standard refrain that "it's all beta, we can change the APIs at any time, this functionality shouldn't be relied on for production sites, yada yada". And then you have to consider the bugs, of which there are many in bleeding edge features, not helped by the fact that the six week release cycle is demonstrably too fast for a reliable QA process for software of this complexity. And even when you've taken care of all of that, you still have to consider the fallbacks for older versions of IE, graceful degradation for mobile devices with limited bandwidth, and so on. Further, what breaking changes have you seen as a result of Firefox and Chrome's rapid development cycle. I mean, the features I'm discussing break regularly, but then again their specs are still in a very draft status and it's known that they will break. I can't say I've ever had a stable Javascript API or CSS rule just completely change when moving from Firefox 11 to 12 or whatever. Lucky you. We're lucky if an update ships and we don't get someone finding a bug somewhere. Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next. Another example for Chrome from a bit further back was the way they completely stuffed the drawing of rounded corners. And then stuffed it again, in a slightly different way, in the next update. And then stuffed it again, a different way again, the update after that. Then there's the whole H.264 question. Is it supported or not? Officially it was going to be dropped quite a while ago. And then it wasn't. And then maybe it is, but actually on Windows it works anyway because of someone else's software. Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets. That bug was known about several days before the update went out, but they pushed it anyway. Having established the scale of the screw-up, they then proceeded not to undo the update until they had a fix, which took several more days. On behalf of the customer support guys I work with who were flooded with complaints that our user interfaces had stopped working for about a fortnight, I'd like to thank the people at Mozilla for instituting such a robust and user-focussed QA process along with their rapid release cycle. I could go on (and on, and on), but right there you have several real world examples of rapid releases pushing out fixes that broke fundamental, widely used technologies, both old and new. Honestly a lot of your claims seem to be exaggerated or I'm on a very different subset of the Internet than you. It's funny how often I hear that. And yet two minutes with Google searching for information about any of the bugs above will turn you up thousands of references. And I'm being kind here and not even picking on all the little details they keep breaking in more bleeding edge features, nor on all the irritation to end users rather than developers that both Mozilla and Google cause when they subtly change their UI around for no particular reason.
    - primatology 15y ago
      > all the irritation to end users rather than developers that both Mozilla and Google cause when they subtly change their UI around for no particular reason. This is why I use Safari. Despite the fact that Safari crashes routinely when one tab hangs up, at least I don't have to worry about the UI rearranging every time I restart. Remember the days of Firefox launch parties? Honestly, a year release cycle feels quick.
    - XLcommerce 15y ago
      Seems like about half the issues you've mentioned relate to differences in syntax/behaviour. This is to be expected. That is what vendor prefixes are for. They are a known (and necessary) evil. Would you prefer to allow the design by committee approach to continue? We've already suffered through 10 years of stagnation due to this approach. Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next. This one sounds like a biggie. Do you have a reproducible test case to demonstrate this behaviour? I know it's time consuming, but you really should file bug reports for this type of stuff. I've filed a number over the years and they do get worked on and they do get fixed (sometimes a lot quicker than you'd imagine). Are you building apps or websites? I can't imagine seeing the fundamentals of layout, box model etc breaking from one release to the next. On the other hand if you're building applications that rely on vendor prefixes then I agree you do have to tread carefully. Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets. Software breaks life goes on. If i'd never personally shipped a line of code with a bug in it I might complain louder. The pace of innovation is blistering. Just look at all the stuff that's come out recently websockets, webgl, flex-box, css columns, dnd, offline storage, css animation, audio, video, filreader, canvas the list goes on. If you're building just another brochure website none of this will interest you. On the other hand life is sweet if you have the luxury of using these features. Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.

>In any case, a lot of those features frankly aren't all that beneficial anyway You're clearly not on the edge of new experimental features or you wouldn't be making such a claim.

Silhouette 15y ago

You couldn't be more wrong. I make my living building web sites and embedded browser-accessible user interfaces, and several of the projects I'm working on right now use state-of-the-art features with HTML5, CSS3, mobile devices and all that jazz. And I stand by my previous comment despite that.

drivebyacct2 15y ago
>state-of-the-art features How can you claim to use state-of-the-art features and not appreciate that those features will be more stable and more readily available than ever? And the cool new features being worked on are far, far, far more expansive, neat and "useful" (as you desire) than "css3" or "mobile devices". If you're really doing "state of the art" things, then you're probably using features that were added to Chrome and Gecko as part of one of the features that was enabled by the rapid release cycle with multiple versions and pipelines being worked on simultaneously. Further, what breaking changes have you seen as a result of Firefox and Chrome's rapid development cycle. I mean, the features I'm discussing break regularly, but then again their specs are still in a very draft status and it's known that they will break. I can't say I've ever had a stable Javascript API or CSS rule just completely change when moving from Firefox 11 to 12 or whatever. >"Much of the content on those sites doesn't even work on both Gecko and WebKit at the same time, never mind IE." Honestly a lot of your claims seem to be exaggerated or I'm on a very different subset of the Internet than you.
- Silhouette 15y ago
  How can you claim to use state-of-the-art features and not appreciate that those features will be more stable and more readily available than ever? Because they aren't more stable and readily available than ever. Browser fragmentation is worse today than at any time in history, including the peak of the Netscape/Microsoft war. At any given time, you might have to implement a given bit of styling at least three or four times over, not because the browsers differ in their functionality, but just because they all do it with slightly different syntax. That in turn is because the browsers frequently have slightly different ways of doing things first, even if someone then wins later, which of course means everyone else has to slightly change their behaviour to match whichever standard wins. And that's before you even consider the standard refrain that "it's all beta, we can change the APIs at any time, this functionality shouldn't be relied on for production sites, yada yada". And then you have to consider the bugs, of which there are many in bleeding edge features, not helped by the fact that the six week release cycle is demonstrably too fast for a reliable QA process for software of this complexity. And even when you've taken care of all of that, you still have to consider the fallbacks for older versions of IE, graceful degradation for mobile devices with limited bandwidth, and so on. Further, what breaking changes have you seen as a result of Firefox and Chrome's rapid development cycle. I mean, the features I'm discussing break regularly, but then again their specs are still in a very draft status and it's known that they will break. I can't say I've ever had a stable Javascript API or CSS rule just completely change when moving from Firefox 11 to 12 or whatever. Lucky you. We're lucky if an update ships and we don't get someone finding a bug somewhere. Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next. Another example for Chrome from a bit further back was the way they completely stuffed the drawing of rounded corners. And then stuffed it again, in a slightly different way, in the next update. And then stuffed it again, a different way again, the update after that. Then there's the whole H.264 question. Is it supported or not? Officially it was going to be dropped quite a while ago. And then it wasn't. And then maybe it is, but actually on Windows it works anyway because of someone else's software. Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets. That bug was known about several days before the update went out, but they pushed it anyway. Having established the scale of the screw-up, they then proceeded not to undo the update until they had a fix, which took several more days. On behalf of the customer support guys I work with who were flooded with complaints that our user interfaces had stopped working for about a fortnight, I'd like to thank the people at Mozilla for instituting such a robust and user-focussed QA process along with their rapid release cycle. I could go on (and on, and on), but right there you have several real world examples of rapid releases pushing out fixes that broke fundamental, widely used technologies, both old and new. Honestly a lot of your claims seem to be exaggerated or I'm on a very different subset of the Internet than you. It's funny how often I hear that. And yet two minutes with Google searching for information about any of the bugs above will turn you up thousands of references. And I'm being kind here and not even picking on all the little details they keep breaking in more bleeding edge features, nor on all the irritation to end users rather than developers that both Mozilla and Google cause when they subtly change their UI around for no particular reason.
  - primatology 15y ago
    > all the irritation to end users rather than developers that both Mozilla and Google cause when they subtly change their UI around for no particular reason. This is why I use Safari. Despite the fact that Safari crashes routinely when one tab hangs up, at least I don't have to worry about the UI rearranging every time I restart. Remember the days of Firefox launch parties? Honestly, a year release cycle feels quick.
  - XLcommerce 15y ago
    Seems like about half the issues you've mentioned relate to differences in syntax/behaviour. This is to be expected. That is what vendor prefixes are for. They are a known (and necessary) evil. Would you prefer to allow the design by committee approach to continue? We've already suffered through 10 years of stagnation due to this approach. Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next. This one sounds like a biggie. Do you have a reproducible test case to demonstrate this behaviour? I know it's time consuming, but you really should file bug reports for this type of stuff. I've filed a number over the years and they do get worked on and they do get fixed (sometimes a lot quicker than you'd imagine). Are you building apps or websites? I can't imagine seeing the fundamentals of layout, box model etc breaking from one release to the next. On the other hand if you're building applications that rely on vendor prefixes then I agree you do have to tread carefully. Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets. Software breaks life goes on. If i'd never personally shipped a line of code with a bug in it I might complain louder. The pace of innovation is blistering. Just look at all the stuff that's come out recently websockets, webgl, flex-box, css columns, dnd, offline storage, css animation, audio, video, filreader, canvas the list goes on. If you're building just another brochure website none of this will interest you. On the other hand life is sweet if you have the luxury of using these features. Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.