3 ms·

> I have already listed several fundamental bugs that have resulted from the recent development processes at Google and Mozilla in my earlier post. I see that

> I have already listed several fundamental bugs that have resulted from the recent development processes at Google and Mozilla in my earlier post. I see that you mentioned "broken" rounded corners and html5 video. (1) For border radius, if you were stung by the change, you would had to have been using the vendor prefixed version of the property, which isolated you from a breaking change in the final property. Feel free to blame that one on the CSS working group, for changing the definition, or yourself, for not planning for the possibility that an explicitly-prefixed experimental property could change before being finalized. Experimental implementations need to be made before a spec is finalized. You should absolutely use them, but only in circumstances where you monitor any spec changes and update your pages appropriately. If you can't, don't. (2) For the video element, you might want to actually test for a bug before claiming to have been bitten by it: h264 support hasn't been removed yet. h264-encoded videos will play just fine in chrome. Meanwhile full adblockers have existed in chrome for some time, and while tab isolation has been somewhat delayed in firefox, plugin isolation has done wonders for total crash rates. Finally, there's a point that is well worth repeating these days: the W3C requires working implementations for specs to become finalized recommendations. The fact that you can use the latest HTML5 and CSS3 features, even if their spec isn't finished yet, isn't some kind of nefarious plot, and vendor prefixes, as annoying as they can be, just mean that we won't be burdened later if specs change before they are finished. No one is forcing you to use shiny new things or experimental effects Stick to core functionality -- which I think you'll find all the vendors have done a great job at keeping from regressing -- and you'll be fine.

Silhouette 15y ago
I think you have misunderstood my examples. > For border radius, if you were stung by the change, you would had to have been using the vendor prefixed version of the property The rounded corners issue I talked about wasn't a mark-up issue, it was a basic rendering bug. It took several attempts to fix, over a period of months. During that time, any sites that used even simple rounded corners with an unfortunate combination of colours would get a horrible show-through effect or at best a poorly anti-aliased rendering in Chrome. Rounded corners were surely one of the most anticipated CSS3 features, just the kind of thing where a rapid release cycle is supposed to move the web forward according to advocates, and they regressed it, badly, for several months. Moreover, as long as Google and Mozilla keep releasing "experimental" CSS features with syntax and capabilities that aren't yet standardised, they are on a path where the only options are supporting alternative, non-standard functionality indefinitely or breaking existing web sites that were written using the experimental features at some unspecified point in the future. That's starting to sound like IE vs. Netscape all over again. > For the video element, you might want to actually test for a bug before claiming to have been bitten by it: h264 support hasn't been removed yet. Google dropped support for H.264 in the Chrome development builds some time ago, and the change is scheduled to be pushed to users of the official release imminently. > Meanwhile full adblockers have existed in chrome for some time, and while tab isolation has been somewhat delayed in firefox, plugin isolation has done wonders for total crash rates. If you've got a full ad-blocker for Chrome, I'd love a link. I've never found one anything close to as capable as things like Ad Block Pro in Firefox. As for tab isolation in Firefox, it's not just a robustness issue, it's also a performance and potentially a security issue. One tab loading slowly or running screwed up JavaScript can still block your entire browser for several seconds, which can be very annoying. > Stick to core functionality -- which I think you'll find all the vendors have done a great job at keeping from regressing -- and you'll be fine. No, they haven't. I have given you four specific examples, and while you could argue that the two Chrome ones (CSS3 rounded corners and HTML5 video support for H.264) were experimental, there is no denying that the two Firefox ones (Java applets and the basic typography engine) are fundamental, well established, and seriously broken in several recent Firefox 3/4 builds. Please check my posting history from a few weeks ago for details; I gave specific citations to the last guy who seemed unable to believe it. Of course, if you're going to argue that we shouldn't worry about any problems with experimental features, particularly either regressing them or cutting off support when a standardised alternative becomes available, then you're basically undermining the entire premise of this discussion, which was that rapid release cycles advance the web more quickly. As I've been saying for a while, I don't think going back to the race between IE and Netscape is going to advance the web for users in any useful way. It's just going to create a nasty, half-defined mess that most developers are going to ignore most of the time anyway, and that breaks things in user-visible ways the rest of the time.
- magicalist 15y ago
  >The rounded corners issue I talked about wasn't a mark-up issue, it was a basic rendering bug. It took several attempts to fix, over a period of months. You're going to have to point to a bug report, because I don't know what you're referring to. Webkit had poor rendering of border-radius with a varying radius (the edge would be discontinuous), it had an issue where box-shadow would break with rounded corners, and it had an issue where the element background color would show show up slightly outside of any border color. All were bugs, but none were regressions, as far as I know. > Moreover, as long as Google and Mozilla keep releasing "experimental" CSS features with syntax and capabilities that aren't yet standardised, they are on a path where the only options are supporting alternative, non-standard functionality indefinitely or breaking existing web sites that were written using the experimental features at some unspecified point in the future. That's starting to sound like IE vs. Netscape all over again. That's just the reality of web development. We should have had a stable foundation for content, styling, and scripting for a decade now, but the standards are now finally being advanced at a decent rate. In order to do this, we need both experimental and working implementations. You'll note that Opera has -o- prefixed css properties and Microsoft has -ms- prefixed properties. That's how it works...implementations are built while specs are being written, but nothing is standardized until interoperable implementations exist. For more: http://www.alistapart.com/articles/prefix-or-posthack/ http://www.alistapart.com/articles/prefix-or-posthack/ > Google dropped support for H.264 in the Chrome development builds some time ago, and the change is scheduled to be pushed to users of the official release imminently. You're making me second guess myself, but AFAIK, they didn't and it isn't. The announcement was that they will sometime soon, but that was to give people time to switch. I was just able to play h264 videos in dev and canary builds on my windows and mac machines. > If you've got a full ad-blocker for Chrome, I'd love a link. I've never found one anything close to as capable as things like Ad Block Pro in Firefox. There's "AdBlock" and "AdBlock Plus." I think the second is made by the same guy that makes AdBlock Pro, but I don't really keep up with it. I have click to play enabled for plugins and that'sufficient blocking of annoying things for me. No idea what's up with applets, but the irony of bringing up the font rendering change in Firefox 4 is that Firefox 4 was a long in development, monolithic release. Whether the style of font rendering is a regression or not is up for debate (there were also tradeoffs that had to be made working with GDI and directx), but really it's just a change people don't like, which has nothing to do with changes in release rates. UI and UX regressions happen all the time; that's why it's great to have a choices. Finally, there are two points here: 1) Only use experimental features if you're willing to be a participant in the process, even if that just means keeping up with implementation changes 2) Point (1) would only prevent quick release cycles from advancing the state of the web if implementations didn't converge and specs weren't finalized at a rate faster that e.g. IE's release rate. They do, and since HTML5 and CSS3 have moved to a more modular spec format (rather than the decade long process for CSS 2.1), we are going to see the effect of a lagging IE10 over the next two years. All that said, legacy browsers will have a worse effect, so it's really not that bad. I'm not saying that Microsoft is bad (although required browser updates after, say, 3 years with only an opt-out option would make me a happier camper), I just think that the faster release cycles are better for the web (for developers, users, and advancing web standards), and that the growing pains we've experienced have actually been quite minor.

Silhouette 15y ago

I think you have misunderstood my examples. > For border radius, if you were stung by the change, you would had to have been using the vendor prefixed version of the property The rounded corners issue I talked about wasn't a mark-up issue, it was a basic rendering bug. It took several attempts to fix, over a period of months. During that time, any sites that used even simple rounded corners with an unfortunate combination of colours would get a horrible show-through effect or at best a poorly anti-aliased rendering in Chrome. Rounded corners were surely one of the most anticipated CSS3 features, just the kind of thing where a rapid release cycle is supposed to move the web forward according to advocates, and they regressed it, badly, for several months. Moreover, as long as Google and Mozilla keep releasing "experimental" CSS features with syntax and capabilities that aren't yet standardised, they are on a path where the only options are supporting alternative, non-standard functionality indefinitely or breaking existing web sites that were written using the experimental features at some unspecified point in the future. That's starting to sound like IE vs. Netscape all over again. > For the video element, you might want to actually test for a bug before claiming to have been bitten by it: h264 support hasn't been removed yet. Google dropped support for H.264 in the Chrome development builds some time ago, and the change is scheduled to be pushed to users of the official release imminently. > Meanwhile full adblockers have existed in chrome for some time, and while tab isolation has been somewhat delayed in firefox, plugin isolation has done wonders for total crash rates. If you've got a full ad-blocker for Chrome, I'd love a link. I've never found one anything close to as capable as things like Ad Block Pro in Firefox. As for tab isolation in Firefox, it's not just a robustness issue, it's also a performance and potentially a security issue. One tab loading slowly or running screwed up JavaScript can still block your entire browser for several seconds, which can be very annoying. > Stick to core functionality -- which I think you'll find all the vendors have done a great job at keeping from regressing -- and you'll be fine. No, they haven't. I have given you four specific examples, and while you could argue that the two Chrome ones (CSS3 rounded corners and HTML5 video support for H.264) were experimental, there is no denying that the two Firefox ones (Java applets and the basic typography engine) are fundamental, well established, and seriously broken in several recent Firefox 3/4 builds. Please check my posting history from a few weeks ago for details; I gave specific citations to the last guy who seemed unable to believe it. Of course, if you're going to argue that we shouldn't worry about any problems with experimental features, particularly either regressing them or cutting off support when a standardised alternative becomes available, then you're basically undermining the entire premise of this discussion, which was that rapid release cycles advance the web more quickly. As I've been saying for a while, I don't think going back to the race between IE and Netscape is going to advance the web for users in any useful way. It's just going to create a nasty, half-defined mess that most developers are going to ignore most of the time anyway, and that breaks things in user-visible ways the rest of the time.

magicalist 15y ago
>The rounded corners issue I talked about wasn't a mark-up issue, it was a basic rendering bug. It took several attempts to fix, over a period of months. You're going to have to point to a bug report, because I don't know what you're referring to. Webkit had poor rendering of border-radius with a varying radius (the edge would be discontinuous), it had an issue where box-shadow would break with rounded corners, and it had an issue where the element background color would show show up slightly outside of any border color. All were bugs, but none were regressions, as far as I know. > Moreover, as long as Google and Mozilla keep releasing "experimental" CSS features with syntax and capabilities that aren't yet standardised, they are on a path where the only options are supporting alternative, non-standard functionality indefinitely or breaking existing web sites that were written using the experimental features at some unspecified point in the future. That's starting to sound like IE vs. Netscape all over again. That's just the reality of web development. We should have had a stable foundation for content, styling, and scripting for a decade now, but the standards are now finally being advanced at a decent rate. In order to do this, we need both experimental and working implementations. You'll note that Opera has -o- prefixed css properties and Microsoft has -ms- prefixed properties. That's how it works...implementations are built while specs are being written, but nothing is standardized until interoperable implementations exist. For more: http://www.alistapart.com/articles/prefix-or-posthack/ http://www.alistapart.com/articles/prefix-or-posthack/ > Google dropped support for H.264 in the Chrome development builds some time ago, and the change is scheduled to be pushed to users of the official release imminently. You're making me second guess myself, but AFAIK, they didn't and it isn't. The announcement was that they will sometime soon, but that was to give people time to switch. I was just able to play h264 videos in dev and canary builds on my windows and mac machines. > If you've got a full ad-blocker for Chrome, I'd love a link. I've never found one anything close to as capable as things like Ad Block Pro in Firefox. There's "AdBlock" and "AdBlock Plus." I think the second is made by the same guy that makes AdBlock Pro, but I don't really keep up with it. I have click to play enabled for plugins and that'sufficient blocking of annoying things for me. No idea what's up with applets, but the irony of bringing up the font rendering change in Firefox 4 is that Firefox 4 was a long in development, monolithic release. Whether the style of font rendering is a regression or not is up for debate (there were also tradeoffs that had to be made working with GDI and directx), but really it's just a change people don't like, which has nothing to do with changes in release rates. UI and UX regressions happen all the time; that's why it's great to have a choices. Finally, there are two points here: 1) Only use experimental features if you're willing to be a participant in the process, even if that just means keeping up with implementation changes 2) Point (1) would only prevent quick release cycles from advancing the state of the web if implementations didn't converge and specs weren't finalized at a rate faster that e.g. IE's release rate. They do, and since HTML5 and CSS3 have moved to a more modular spec format (rather than the decade long process for CSS 2.1), we are going to see the effect of a lagging IE10 over the next two years. All that said, legacy browsers will have a worse effect, so it's really not that bad. I'm not saying that Microsoft is bad (although required browser updates after, say, 3 years with only an opt-out option would make me a happier camper), I just think that the faster release cycles are better for the web (for developers, users, and advancing web standards), and that the growing pains we've experienced have actually been quite minor.