21–30 of 50 posts
What an idiotic move - So now they want to make webkit the next IE of internet? Standards are standards - period. I see ton of wrong with this approach, or... mabye we should just ignore the w3C CSS Working group. Vendor prefixes are fine - as long they are used as temporary solution, and no one expects them to be the "default" way of doing things.
Earlier quoted context omitted.
What would happen in the situation that a browser has developed a non-prefixed property, which later becomes a standard, but with different functionality?
Prior art of vendor features that were introduced sans prefix: innerHTML, XMLHttpRequest, , querySelectorAll, innerText... We've done this before and handled it fine. In JavaScript you can test the features, in CSS you end up duplicating a few lines of CSS-- see the gradients example: http://paulirish.com/2012/vendor-prefixes-are-not-developer-...
I know everyone talks about fragmentation concerns, and WebKit as the new IE6, but does this argument really make any sense? Internet Explorer was a poorly updated, closed source product that only worked on a single platform; WebKit is open source, maintained by two separate companies (that are basically locked in a cold war), and is available on all major platforms. If anything, why isn't the notion of a single rend…
WebKit is not controlled by 2 companies and WebKit is not a single rendering engine. WebKit is a single upstream project, the downstream browsers differ from each other just as much as they differ from gecko or presto based browsers.
Earlier quoted context omitted.
WebKit is not controlled by 2 companies and WebKit is not a single rendering engine. WebKit is a single upstream project, the downstream browsers differ from each other just as much as they differ from gecko or presto based browsers.
Not sure that is fair; Google push updates to Webkit all the time, but naturally they develop them on their fork.
What an idiotic move - So now they want to make webkit the next IE of internet? Standards are standards - period. I see ton of wrong with this approach, or... mabye we should just ignore the w3C CSS Working group. Vendor prefixes are fine - as long they are used as temporary solution, and no one expects them to be the "default" way of doing things.
Opera is not making WebKit the new IE; web developers who only use -webkit CSS prefixes have done that.
What an idiotic move - So now they want to make webkit the next IE of internet? Standards are standards - period. I see ton of wrong with this approach, or... mabye we should just ignore the w3C CSS Working group. Vendor prefixes are fine - as long they are used as temporary solution, and no one expects them to be the "default" way of doing things.
Historically, the standards that have been most successful have been the ones that describe what people are already doing
Earlier quoted context omitted.
Prior art of vendor features that were introduced sans prefix: innerHTML, XMLHttpRequest, , querySelectorAll, innerText... We've done this before and handled it fine. In JavaScript you can test the features, in CSS you end up duplicating a few lines of CSS-- see the gradients example: http://paulirish.com/2012/vendor-prefixes-are-not-developer-...
I would prefer the following 2 pronged approach: * First, prefixed properties in nightlies/dev versions of browsers, such as Canary. This would allow testing, without imposing a specific standard. Once a proposal is written, implement it without a prefix in the normal way. * Second, we need a tool to update our CSS files automagically. I should be able to use the non-prefixed version and the prefixed version added by…
This is a good thing, and there is basically no way around it. There is a varying degree of a WebKit monoculture on mobile. Without great site compatibility, users will never successfully switch to a non-webkit browser, but currently much of the great mobile content out there assumes webkit prefixes and userAgent. So Opera, Mozilla, and MS basically need to adopt some of the mobile webkit properties in order to get c…
Is vendor prefixing really worse than UA sniffing Paul? Your employer is one of the worst offenders of the latter (not blaming you). Maps, for example, falls back to a very primitive version in Firefox Mobile despite it being perfectly capable of rendering the more advanced site. My attitude is that if you don't want to test on anything other than Safari Mobile and Android Browser then fine, don't test, but let the s…
In practice, graceful degradation requires testing.
Earlier quoted context omitted.
Not sure that is fair; Google push updates to Webkit all the time, but naturally they develop them on their fork.
The other vendors choose when/if they merge Google's commits. The grandparent's comment made WebKit sound like a single entity when it's actually several competing companies with overlapping but also differing views on things. They just happen to be working from a common code base.
Earlier quoted context omitted.
Not sure that is fair; Google push updates to Webkit all the time, but naturally they develop them on their fork.
The other vendors choose when/if they merge Google's commits. The grandparent's comment made WebKit sound like a single entity when it's actually several competing companies with overlapping but also differing views on things. They just happen to be working from a common code base.