Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

W3C Member Proposes "Fix" For CSS Prefix Problem

Unknown Lamer posted more than 2 years ago | from the worse-is-better-is-a-terrible-way-to-love dept.

The Internet 144

Pieroxy writes "The W3C is proposing a set of new rules for CSS prefixing by browser vendors. This would greatly mitigate the problem caused today where vendor specific prefixing is seeing its way through production sites. The problem is so bad that some vendors are now tempted to support other browsers' prefixing. The article also has a link to an email from Mozilla's Henri Sivonen that does a nice job of addressing many potential issues and shortcomings of this new proposal." I was under the impression that browser prefixes existed to allow use of experimental CSS features before standardization; just ditching the vendor prefix seems like a step backward.

cancel ×

144 comments

Sorry! There are no comments related to the filter you selected.

The solution is.. (4, Insightful)

Psylok (1526433) | more than 2 years ago | (#39940677)

Drop them all.

I always wondered why they've put them there in the first place. I mean: since you are implementing the function, why call it with a different name?

Re:The solution is.. (4, Funny)

Anonymous Coward | more than 2 years ago | (#39940693)

Yes, they should just use the standard.

Stupid microsoft.

Re:The solution is.. (4, Informative)

WrongSizeGlass (838941) | more than 2 years ago | (#39940759)

Yes, they should just use the standard.

Stupid microsoft.

Many of the browser vendors are to blame. I'd love to point the finger at Microsoft, but they aren't the only one who isn't compliant with the supposed standards (CSS, DOM, Javascript, etc).

Re:The solution is.. (2)

gl4ss (559668) | more than 2 years ago | (#39940943)

Yes, they should just use the standard.

Stupid microsoft.

Many of the browser vendors are to blame. I'd love to point the finger at Microsoft, but they aren't the only one who isn't compliant with the supposed standards (CSS, DOM, Javascript, etc).

I think it was a sarcastic jest at the parent post, which suggested that a browser producer should name a css property superblubbery instead of ms-superblubbery, which is what ms did and got flak for?

who really gives a fuck about w3c anyways? it's not like they're ever on the leading edge. devices api group? oh they're only 5 years late and based on vendor specific stuff that shipped 5 years ago, how very nice.

Re:The solution is.. (4, Informative)

mwvdlee (775178) | more than 2 years ago | (#39941037)

I used to think that too, but then I started to do web development.
Usually I develop a site on Chrome.
Then verify that everything works on Safari, FireFox, Opera and iOS/Android if applicable.
Then replace CSS styling with images to make it work on IE9.
Then reduce layout to make it work on IE8.
Then replace the div layout with nested tables to make it work on IE6.
Then thank the gods I don't have to support IE5.5 any more.

Yes, all browsers have compliancy issues. IE is just far, far worse than all the others.
Even IE9 is more troublesome than a version of FireFox from a few years ago.
IE10 improves a lot, but is still worse than the other major browsers.

Re:The solution is.. (3, Interesting)

Anonymous Coward | more than 2 years ago | (#39941185)

What we need is a more "amateur" web, where people only do the work in your first step, maybe also do the second step (test on one or more other (non-IE) browsers) which only takes a minute or two, and then say they're done -- simply blowing off the question of whether or not the site looks perfect on IE.

You can't do that (neither can I) at our jobs but for a situation where there isn't some boss telling you "21% of our users are still using IE so the site has to look ok," then blowing off IE is simply no problem.

I mean it's not a problem for anyone, not even the IE users, because they would either accept they're not seeing the same web as everyone else (and there's actually nothing wrong with that) or else they'd upgrade. Or, worst case, they would bitch like they always do and balkanize off to their own web and the world wouldn't miss them.

Nobody loses, if only we had a less professional approach. "Pro" doesn't mean "better."

Re:The solution is.. (2)

Piata (927858) | more than 2 years ago | (#39941265)

I really hope you're exaggerating about using nested tables to make a site work in IE6. A custom stylesheet that only targets IE6 can do the job just as well. The only hard part is knowing all of IE6's quarks.

Personally, I prefer to go the slightly more controversial route and not support anything below IE8. If a client wants IE6 support, they're going to pay through the nose for it.

Re:The solution is.. (0)

Anonymous Coward | more than 2 years ago | (#39941797)

"quarks"... I think you meant "quirks".

Re:The solution is.. (4, Funny)

Anonymous Coward | more than 2 years ago | (#39942159)

You've not done much work with IE6, have you? Heisenberg's uncertainty principle is definitely in play.

GP is right, though; an IE6-only stylesheet is usually enough (even if you have to degrade support slightly in IE6).

Re:The solution is.. (1)

Zaiff Urgulbunger (591514) | more than 2 years ago | (#39944005)

You've not done much work with IE6, have you? Heisenberg's uncertainty principle is definitely in play.

+1 Genuinely did LOL at that! :D

Re:The solution is.. (1)

rs79 (71822) | more than 2 years ago | (#39941997)

I have a more radical solution. If I detect IE I use an undocumented instruction and make sparks fly out the back of the computer.

Payback for all that "this site only works in IE" rubbish.

Re:The solution is.. (0)

Anonymous Coward | more than 2 years ago | (#39942837)

This was almost acheivable with vbscript once upon a time - an infinite loop that popped up a message box would mean they had to kill their browser.

Re:The solution is.. (0)

Billly Gates (198444) | more than 2 years ago | (#39942079)

Don't use CSS 3. IE 9 is not IE 6. It doesn't do things its own way and IE 9 was released when Firefox 3.6 was out and is over a year old so logically it doesn't support all of CSS 3 yet, as other webkit browsers support CSS 3 in their own prefixed way. It is not like MS is the one who is trying to be proprietary as yourself and many others are advocating.

There are too many older browsers out there to use that anyway and the mobile experience is going to be the best as a result. IE 7 and FF 3.5 is still standard in the Office until 2014 thanks to the beancounters who are putting the brakes on upgrading to boast the share price. Using CSS 2.1 and HTML 4 is the most logical thing to do for now.

Re:The solution is.. (0)

Anonymous Coward | more than 2 years ago | (#39942101)

Then replace the div layout with nested tables to make it work on IE6

I no longer support IE 6. And when clients insist I charge them and arm and leg to support it.

Then replace CSS styling with images to make it work on IE9

You're not very good at what you do, are you.

Yes, all browsers have compliancy issues. IE is just far, far worse than all the others.
Even IE9 is more troublesome than a version of FireFox from a few years ago.
IE10 improves a lot, but is still worse than the other major browsers.

This statement is horse apples. I run into a near equal number of irritating quirks these days with all the latest browsers. IE9 has come so far from where IE was 2 years ago that I feel I have been divinely saved from browser purgatory. It runs, generaly, like a browser should and often better than any of the others. It supports HTML5 better than most, etc., etc., any web developer worth his/her salt knows this.

All the latest releases of the mainstream browsers have their issues, but singling out IE anymore is just lazy and simply false.

Re:The solution is.. (0)

Anonymous Coward | more than 2 years ago | (#39942435)

Actually what you are really saying ancient version of IE are far far worse. Which makes sense, because they are, in fact, ancient.

Re:The solution is.. (-1)

Nethemas the Great (909900) | more than 2 years ago | (#39943021)

Now of course the amusing part comes when--knowing this kind of non-sense is normally involved--people like to claim that HTML5/Javascript is ready for prime-time replacement of installed applications. Web monkeys and their toys are 5-10 years behind the curve when it comes to delivering practical, straightforward solutions to their clients. This technology can enable you to do some pretty slick things. I don't think there's any questioning that. But, the fickleness of the environment and the limitations of the languages in terms of expression but especially and most importantly maintainability of the code should really give pause to anyone that wants to use it for anything other than auxiliary clients.

It would be awesome if we could have a WORA [wikipedia.org] technology suite that has the expressive power and creative freedom of WPF; the choice of a lightweight agile scripting language like Javascript OR the reliable, maintainable formality and expressive power of Java or C# depending upon requirements; coupled with the ability to trust that no matter what platform the software is run on, it will never deviate. The reality on the ground unfortunately is anything but that.

Re:The solution is.. (-1, Flamebait)

Nethemas the Great (909900) | more than 2 years ago | (#39944409)

Really web monkeys? Is that the best you can do? Mod me down because you don't like what I have to say? Why not refute what I'm saying if you believe me to be in error? Show me how I'm wrong, because honestly, I'd love to have access to a technology suite such as I described.

PROTIP: (0)

Anonymous Coward | more than 2 years ago | (#39945053)

Really web monkeys? Is that the best you can do? Mod me down because you don't like what I have to say?

People are probably modding you down because you're referring to people them as "monkeys." If you were interested in frank discussion, you don't start with disparaging comparisons to other mammals. That's trolling no matter how well founded your arguments might be.

Re:The solution is.. (2)

Eponymous Hero (2090636) | more than 2 years ago | (#39945239)

i was with you until IE6. it's your duty as a developer to royally bitchslap the living fuck out of anyone still using that browser. no mercy, no excuses. IE6 is unsupported and dead. dead dead. 0xDEADDEAD, microsoft says STOP, error. 0xDEADBEEF dead. your memory of IE6 has been freed up and you may no longer reference it. fuggetaboutit. if you're being paid enough money to convince yourself otherwise, a simple IE targeted stylesheet (included via conditional comments) is enough to pixel push it back into shape.

Re:The solution is.. (-1)

Anonymous Coward | more than 2 years ago | (#39940893)

What is this, I don't even...

Re:The solution is.. (1, Troll)

spottedkangaroo (451692) | more than 2 years ago | (#39941053)

I think they're talking about stuff like this... not really a microsoft problem. #example1 { -moz-box-shadow: 10px 10px 5px #888; -webkit-box-shadow: 10px 10px 5px #888; box-shadow: 10px 10px 5px #888; }

Re:The solution is.. (0)

Anonymous Coward | more than 2 years ago | (#39941665)

Yes, they should just use the standard.

Stupid microsoft.

As long as it works in Firefox the rest can go play in something brown and smelly i will check now and the using Opera but IE not a hope in hell and don't go much on crome either but it's got to work on "Konqueror" as well . Switching the club site to HTML5 right now and this supposed replacement for the

the thing is proving to be a real PITA completely screwing with the layout .

Re:The solution is.. (0)

Anonymous Coward | more than 2 years ago | (#39945245)

Yes, they should just use the standard.

Stupid microsoft.

This has always reminded me of Microsoft's spoofing of Mozilla early in IE history, which they introduced and everyone followed suit. Rendered User-Agent pointless without tricky parsing logic. So yeah, I'll be happy to extend some of the blame for this to Microsoft.

Worse, they're STILL DOING IT.

http://msdn.microsoft.com/en-us/library/ms537503(v=vs.85).aspx [microsoft.com]

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
[...] For historical reasons, Internet Explorer identifies itself as a Mozilla browser. [...]

Re:The solution is.. (3, Insightful)

Sarten-X (1102295) | more than 2 years ago | (#39940739)

Because IE's implementation of a given function might be different from WebKit's, so a designer has to resort to more painful workarounds to get a perfect design. It's easier to just duplicate the same detail with different prefixes (and slightly different parameters, as needed), and know that the directive will be ignored by browsers that don't do exactly what the designer wanted.

It's like back in the bad old days of web design, where websites ran JavaScript to detect what browser was in use, so the page elements could be repositioned on the fly as needed, and the right objects would be used in other scripts.

Re:The solution is.. (4, Insightful)

QuasiSteve (2042606) | more than 2 years ago | (#39940983)

It's like back in the bad old days of web design, where websites ran JavaScript to detect what browser was in use

Those bad old days are ongoing. Just because everybody and their dog are including jquery now doesn't mean the sites aren't still using browser-specific javascript, css, markup, etc.

It's easier to just duplicate the same detail with different prefixes (and slightly different parameters, as needed), and know that the directive will be ignored by browsers that don't do exactly what the designer wanted.

Which, unfortunately, got broken with the popularity of WebKit (whether one blames Apple or Google, doesn't really matter), because designers just started using the webkit prefixed CSS and ignored the rest because it still looked 'okay enough' in other browsers, so why bother making those look 'great'?
The same applies to things outside of the CSS realm, like the apple-touch-icon link. Android uses it. Yep - want pretty bookmarks on Android? Specify the Apple (by name) icons.
Largely this is because the standards people are moving way, way too slow.

But then there's the flipside of the coin. The Opera article in which they announced - along with Mozilla - to support some webkit prefixes, was hilarious.

Their solution is to essentially alias the webkit prefixes to their own. Fine, right? But what happens if there's directives for both? Well, the last one specified overrides. Note that not the vendor-specific one that applies to that vendor's browser overrides, just the last one specified.

So when it comes time to build a site that works well on all browsers, including the ones that use such aliasing, what do they suggest?


blah {
-webkit-foo : bar;
-moz-foo : bar;
-ms-foo : bar;
-o-foo : bar;
foo : bar;
}

But then they also note that for some features, they don't support the prefix-less version for reasons of it not being finalized yet.

So let's say webkit specifies a blue background, moz specifies a yellow one, and o specifies red. When you view it in Opera it will be? red.
Now you view it in a Mozilla browser, using the same aliasing nonsense, what color will it be? red. Opera's. Because that was specified last.
Want to fix it to yellow? You'll have to specify the moz line last.
Except that then Opera will also render it in yellow.

It's all good and well to want to accept other vendors' prefixes, but why would you not let your own override, rather than the last-specified? I realize that as CSS goes, last-specified is supposed to override when there are conflicting specifications... but given the vendor-specific prefixes, there is no actual conflict.

Most hilariously, they already anticipated one response... "So I only need to use -webkit- prefixes now? w00t!" and answered it with "absolutely not." and then go on to give a very, very weak defense for why developers shouldn't do exactly that. Use the webkit prefixes where webkit doesn't make use of the non-prefixed version, use the non-prefixed version to make the page future-proof (assuming the behavior stays the same, but them's the breaks), and call it a day, because Opera now supports the webkit prefix, Mozilla apparently intends to support it, and IE... well, IE...

Re:The solution is.. (1)

Cajun Hell (725246) | more than 2 years ago | (#39941621)

The same applies to things outside of the CSS realm, like the apple-touch-icon link. Android uses it. Yep - want pretty bookmarks on Android? Specify the Apple (by name) icons. Largely this is because the standards people are moving way, way too slow.

Didn't we already have link rel="icon"? Apple fucked around for no good reason that I can see. All they did was make people add more crap to their page heads, to make those pages say they same thing they were already saying, a new way.

Combined with Microsoft's shittiness (although perversely, they and their ico format are better than everything else, at dealing with multiple icon sizes as an alternative to scaling), my pages' heads specify icons three different ways (not counting the fact there's also a /favicon.ico). Bloat bloat bloat for no reason at all, other than there being three ways to say the same thing.

Indeed, my pages heads are just plain getting fucking huge with all the shit.

(It's not just browsers, either, but also the crawlers/scrapers/robots. Facebook, you bastards! OGP just couldn't just use all the same tags that everything else already knew how to read. link rel="img_src" and meta property="og:image" to specify the same image url, *sigh*. At least meta name="description" property="og:description" content="blah" seem to combine ok into one tag so I don't have too much duplication on that one. But WTF: meta property="og:title" when we've already had a title tag ever since html 1.0? Fuck you, Facebook.)

So let's say webkit specifies a blue background, moz specifies a yellow one, and o specifies red.

When the document author has specified ambiguous intent, it doesn't really matter what color it comes out. My complaint is that you often have to say the same thing three different ways; that's bad enough. You're talking about an even crazier situation where you want to say three different things, three different ways. ;-) Of course Opera, the one browser that tries the hardest to do everything, is going to have its mind blown by that.

Re:The solution is.. (1)

guruevi (827432) | more than 2 years ago | (#39941649)

The CSS rules specify that the last one overrides. So they're still following the rules. They're aliasing a number of -webkit- prefixes because some developers (apparently you) thought that developing for -webkit- gave them good enough results but then the content wouldn't display in Opera or other browsers.

Why the hell would you want each browser to have a specific color? Your website should look the same regardless of browser, that's what CSS and HTML is for. As you see the example, if you want to use -webkit-foo because it gives you certain options that's fine, but also include a standard foo so that your content gets displayed on non-webkit browsers.

The prefixes are only there for certain functionality that's not in CSS (yet), however full websites are being built with only these functionality. Opera is aliasing certain features, not so everyone can start using the webkit prefixes, but so that websites will work and hopefully eventually, those webkit prefixes will disappear and they can remove this hack.

Re:The solution is.. (0)

Anonymous Coward | more than 2 years ago | (#39942145)

It wouldn't be so bad if I was allowed to write rules like {,-ms-,-moz-,-o-,-webkit-}whatever: magick;

Re:The solution is.. (5, Informative)

Anonymous Coward | more than 2 years ago | (#39940787)

Because before it's allowed to be a recommendation, it has to have "beta'd" in 2 browsers. So, usually they prefix with the vendor-name (minus webkit browsers which use the engine-name).

Sometimes they have competing syntaxes, such as in gradients, which webkit and gecko duked out.

Basically, they need to allow to experiment, allow backwards compatibility (NEVER BREAK THE WEB), and still be able to ship. Prefixes solve this problem.

The problem most are having with this, is web developers are getting lazy, and on mobile sites only including (pretty much) webkit. So now, IE9Mobile and Firefox Fennac(? is it still called that), are having to implement the -webkit- features because sites look terrible on them, because developers got lazy.

Re:The solution is.. (2)

pmontra (738736) | more than 2 years ago | (#39940951)

Agreed but there is more to that. W3C should take its share of blame for not having standardized yet rounded corners and the like. But among W3C members there are also browser vendors, so maybe it's them who don't like to agree on standards with their competitors.

Re:The solution is.. (2)

mcgrew (92797) | more than 2 years ago | (#39941727)

W3C should take its share of blame for not having standardized yet rounded corners and the like.

What the GP said about lazy (and perhaps incompetent) developers applies here. My old site had rounded corners in 1997, and in fact had most of the web2.0 crap without the annoying "chase the moving link" game and the more annoying "page scrolls up by itself after I scroll down" (sj-r.com is a really bad offender here).

You also need to remember that nobody comes to your site because of what it looks like (although it may keep them away because it looks amateurish and unprofessional), they come to your site for its content.

Re:The solution is.. (0)

Anonymous Coward | more than 2 years ago | (#39945029)

I sometimes use -webit- prefixes not because I'm lazy but because it looks like a bag of ass in firefox.

Re:The solution is.. (5, Informative)

chrissigler (1930758) | more than 2 years ago | (#39940905)

In some cases, different engine authors have different ideas of what the best way to define the spec would be. And given that there's no solid standard yet, they want to do it the way they want to do it. And over time, they can even change their minds, perhaps submitting to the weight of the broader industry.

For example, consider Webkit's two implementations of a simple linear gradient, from black at the top to white at the bottom:

-webkit-gradient(linear, left top, left bottom, color-stop(0%,#000000), color-stop(100%,#ffffff)); /* older webkit method */
-webkit-linear-gradient(top, #000000 0%, #ffffff 100%); /* newer webkit method */

Note that the "new" approach to the arguments is based more on the emerging "standard" (implemented the same way with -ms-, -moz, and -o- prefixes). But when you're out there before the standard emerges (or better yet, is defined), you don't just presume to define the standard.

Or, at least that's how I imagine it went down...

Re:The solution is.. (1)

Samantha Wright (1324923) | more than 2 years ago | (#39940919)

Because the standard won't be done for like a bajillion years, and the correct syntax could change. The prefixes are supposed to be dropped at the earliest opportunity by site implementers, and should serve as a warning to the coder that the feature they're toying with isn't done yet—unfortunately, W3C has once more underestimated the cargo-cult mindset of web developers.

Re:The solution is.. (2)

xouumalperxe (815707) | more than 2 years ago | (#39940925)

Because many of the prefixed CSS properties have not actually been fully standardised, so having vendors support them with prefixes and varying (possibly incomplete!) implementations/syntaxes means we actually get to try the various approaches being proposed, and only pick one to standardise on once the dust has settled and people have made up their minds as to which one is better.

Re:The solution is.. (1)

MickyTheIdiot (1032226) | more than 2 years ago | (#39941525)

When ANY browser does something non-standard, it breaks the web. Period.

Re:The solution is.. (0)

Anonymous Coward | more than 2 years ago | (#39942141)

Drop them all.

I always wondered why they've put them there in the first place. I mean: since you are implementing the function, why call it with a different name?

Sane standards bodies will not certify a proposal as a standard unless there are at least two independent implementations. This is a good thing: Coming up with an idea is trivial. Getting the idea implemented and widely used without breaking existing systems is far harder.

How will you implement a proposal for a standard without changing a browser? Do you think the change should not have a vendor prefix, even if it only works with one vendor?

Browsers should ship with prefix support disabled (4, Insightful)

Anonymous Coward | more than 2 years ago | (#39940683)

Browsers should have an option to enable support for their experimental features and ship with the option turned off. If the masses have feature-enabled browsers, these features will be used in production websites. The only way to prevent fragmentation is to keep fragmenting features out of the installed base.

Re:Browsers should ship with prefix support disabl (1)

azalin (67640) | more than 2 years ago | (#39941093)

Amen. It's rather tiring to explain customers over and over again why not to use the shiny bling they saw on some other site recently. Experimental tags are useful but should not be used in production web sites. The problem is however that it takes forever until some new and useful features are finally part of the standard.
My solution would be twofold first speeding up the decision process and second mark experimental features "experimental" and drop them when they have been integrated into the standard or have been ditched. That might break a website or two but with the feature labeled experimental the persons involved have only themselves to blame.

Re:Browsers should ship with prefix support disabl (3, Insightful)

Anonymous Coward | more than 2 years ago | (#39941695)

If microsoft didn't push out their ActiveXObject("Microsoft.XMLHTTP") in IE 5.5 - and people wouldn't exploit it like mad, we still wouldn't use ajax today.

Re:Browsers should ship with prefix support disabl (1)

Anonymous Coward | more than 2 years ago | (#39942303)

The possibility for AJAX lingered so long before it saw widespread use that I have to question if a more standards oriented approach might have been better, i.e. propose a method for Javascript to get and push documents, then make that feature available as an experimental (default OFF) feature, let developers play with it, standardize it and enable it everywhere. AJAX has its problems, which might have been avoided if Microsoft had not set them in stone by making the first implementation the reference for all others.

Here's another proposal: (5, Insightful)

orthancstone (665890) | more than 2 years ago | (#39940729)

Get the standard done. Browser vendors are not going to wait 20 years for you to make up your mind. The digital world moves too fast for policy to take too long. Proposed ideas are going through vigorous testing in the real world long before a finalized plan for that idea is set.

Re:Here's another proposal: (0)

Anonymous Coward | more than 2 years ago | (#39940811)

Real Standard Writers Ship.

Re:Here's another proposal: (4, Insightful)

Anonymous Coward | more than 2 years ago | (#39940887)

The online world is not moving fast at all. Two years ago, a browser from the turn of the century combined with a proprietary plugin was the definition of the usable feature set, because the availability of anything beyond that could not be relied upon. At least until the end of life of Windows XP, the role of holding everybody back falls to IE8. HTML5? No show. The other browser makers can slow the fuck down and concentrate on building secure browsers that don't need to be updated twice in a full moon. Instead we get browser war style feature fragmentation and "best viewed with" (or worse, silent failure) drives people nuts.

Re:Here's another proposal: (1)

Billly Gates (198444) | more than 2 years ago | (#39942229)

The world is changing again.

It moved fast in the 1990s and stalled when Microsoft won browser wars 1.0. Today we have not just desktop browsers, but tablets, phones, and other devices with Webkit potentially become the next IE 6 of this decade.

Browsers get updated every 6 weeks and even IE is going to get an annual update. True, many corporations will stick with IE 8 and XP if not IE 6 until 2014, but the web will leave them behind as soon as IE 8 and earlier get less than 5% marketshare. According to g.statcounter.com IE 8 is already around 14% on the weekends since MS automatically upgrades IE.

The standards groups need to move on before we have another nightmare of proprietary standards [pcmag.com] again. Apple and Google would love to have the web only work in their browsers and have a vested interest in a slow process unfortunately.

Re:Here's another proposal: (1)

orthancstone (665890) | more than 2 years ago | (#39942551)

The online world is not moving fast at all.

I think you missed my point. Often enough, new proposed standards are implemented, tested, and accepted/rejected long before the standards are considered viable for the final proposal. A five year discussion might work for a proposal committee, but practical application moves on while they sit around and chew the fat on accepted details across the various platforms.

Re:Here's another proposal: (3, Interesting)

WankersRevenge (452399) | more than 2 years ago | (#39942581)

At least until the end of life of Windows XP, the role of holding everybody back falls to IE8. HTML5? No show.

Funny ... I've been writing HTML5 for awhile now and it works fine in ie6 and up. Granted it requires conditionals and some clever use of css, but it renders fine in older browsers and modern browsers get to experience some of the latest features. And no - there is no "best viewed" anywhere in my sites. Everything just works with or without JavaScript all written in standard markup.

It takes work, but so does anything worth doing.

Re:Here's another proposal: (1)

yuhong (1378501) | more than 2 years ago | (#39943605)

At least until the end of life of Windows XP, the role of holding everybody back falls to IE8. HTML5? No show.

Or even the 10 years old XHTML and DOM2!

Re:Here's another proposal: (1)

shentino (1139071) | more than 2 years ago | (#39944221)

Maybe companies should stop touting proprietary features in an attempt to infect the market and strong-arm the standards committees.

Re:Here's another proposal: (1)

KiloByte (825081) | more than 2 years ago | (#39940997)

Remember XHTML? Remember exported templates in C++?

This kind of experimental features are better done _marked_ as experimental, so they don't need to be supported forever. So I'd go the totally opposite way: force using such prefixes, and request browser makers to drop support X time after a feature is accepted into the standard.

Re:Here's another proposal: (0)

Nethemas the Great (909900) | more than 2 years ago | (#39943221)

It might feel nice to b**ch slap the vendors providing the browsers. But, the reality is that you're only hurting your customers not them. They're the ones that will be furious and fuming about how the software they paid a large sum of money for doesn't work one day after an update is pushed to their machines.

Re:Here's another proposal: (1)

drinkypoo (153816) | more than 2 years ago | (#39944073)

So I'd go the totally opposite way: force using such prefixes, and request browser makers to drop support X time after a feature is accepted into the standard.

Bingo! I learned this lesson from watching multitexture get into OpenGL. It got in there. Now it's everywhere. Started in SGI. Brought to you by 3dfx.

Re:Here's another proposal: (1)

Anonymous Coward | more than 2 years ago | (#39941055)

Get the standard done. Browser vendors are not going to wait 20 years for you to make up your mind.

You do realise that the W3C is only made of of the browser vendors? The moment all vendors agree is the moment the standard is done.

Re:Here's another proposal: (3, Insightful)

Skuto (171945) | more than 2 years ago | (#39941271)

...and some vendors (mostly Apple, a little bit Google) have an interest in that not happening. So good luck waiting.

Re:Here's another proposal: (1)

MisterSquid (231834) | more than 2 years ago | (#39943575)

...and some vendors (mostly Apple, a little bit Google) have an interest in that not happening. So good luck waiting.

What evidence do you have for this claim? Apple and Google use the same browser engine and both companies seem quite committed to having markup, CSS, and JavaScript render identically in their browsers.

In other words, Apple and Google are fierce competitors but they are both sane enough to understand the benefit of shared web standards and both companies are leading the way in browser innovation. Have you taken a look at what Mobile Safari is capable of? Have you checked Google+ recently and seen its graceful and effective implementation of JavaScript?

My guess is you're trolling or reacting in accordance with unspecified and cult-like prejudices.

Re:Here's another proposal: (1)

orthancstone (665890) | more than 2 years ago | (#39942493)

The moment all vendors agree is the moment the standard is done.

And since that process applies to every damn detail in the standard, it is no wonder that they all just implement experimental ideas immediately rather than wait for the standard to be completed. Consensus takes forever.

Re:Here's another proposal: (1)

gr8_phk (621180) | more than 2 years ago | (#39941229)

Get the standard done. Browser vendors are not going to wait 20 years for you to make up your mind.

And excellent point. And in the mean time, sites should avoid browser-specific features. This is not just "MS did it wrong, gotta support that variant", in this case the prefix actually indicates a browser specific implementation. If you want to burden yourself with it feel free, but don't complain. If you must complain, complain that the standard isn't done - not that you dug yourself a hole with non-standard features.

Bias Reporting (1)

Anonymous Coward | more than 2 years ago | (#39940731)

I was under the impression that browser prefixes existed to allow use of experimental CSS features before standardization; just ditching the vendor prefix seems like a step backward.

Can you please just state the fact in an article and not attempt to persuade an opinion? Personal commentary really kills it for us.

Re:Bias Reporting (2)

NemoinSpace (1118137) | more than 2 years ago | (#39940853)

If you can't handle the concept of editorial bias and persuasion, I suggest you pick up an encyclopedia. If everyone agreed on facts, there would not be much point in regurgitating them in a discussion, unless your at a pep rally.
Oh.

Re:Bias Reporting (0)

Anonymous Coward | more than 2 years ago | (#39940949)

Slashdot: Fox News for nerds, stuff that matters

Re:Bias Reporting (-1)

Anonymous Coward | more than 2 years ago | (#39940987)

And you'd think the fucking submitter could be bother to read the fucking article to find out why this is being fucking proposed. Fucking Jesus.

Re:Bias Reporting (0)

Anonymous Coward | more than 2 years ago | (#39941227)

If you were also a Web developer you would agree with what he said because that's exactly what vendor prefixes are all about. See linear gradients for an example where not everyone implemented the feature in the same way at first.

Re:Bias Reporting (1)

jbov (2202938) | more than 2 years ago | (#39944983)

... and if you read the article you would disagree with what he said, because they aren't "ditching the vendor prefix".

Proposal
When a browser vendor implements a new css feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.

Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.

If a large amount of content accumulates using the a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.

Call to action for web developers (0)

Anonymous Coward | more than 2 years ago | (#39941015)

http://www.webstandards.org/2012/02/09/call-for-action-on-vendor-prefixes/ [webstandards.org]

Without web developers including all prefixes plus a non-prefixed version of every experimental CSS rule, the state we were in with the IE monopoly of pseudo-standards becomes a -webkit- prefix monopoly of pseudo-standards.

Good proposal (2)

gstrickler (920733) | more than 2 years ago | (#39941027)

It would be a step in the right direction. Henri Sivonen's response also addresses several valid points, some of which can be addressed with minor mods to the proposal, some of which can be addressed (but not solved) by issuing guidance to vendors and authors. Having developed data communications standards and software in another industry, I'm well aware of the issues caused by non-compliance, insufficiently (and overly) specific standards, and that vendors and authors do not always follow the guidance (mostly because the developers rarely read it).

Most importanly, this proposal gives a clear, standard method for both authors and browser vendors. When it comes to getting compliance and compatibility with a standard, the simpler it is, the better for everyone.

Opera is pushing this... (1)

thestudio_bob (894258) | more than 2 years ago | (#39941051)

First of all, this "proposal" is coming from the fine folks over at Opera. And the "problem" is that people are using prefixes, just not their prefix (-o-). So they want to do away with them. Just last week they announced they were going to copy webkit's prefix, so I really don'y know why they are proposing this.

Re:Opera is pushing this... (4, Informative)

Skuto (171945) | more than 2 years ago | (#39941299)

They're proposing this because the other "solution" they announced obviously totally sucks (but they have no choice).

To pretend this is only Opera's problem is silly. It's an everybody-who-is-not-Webkit problem. Which is why Mozilla said they will do the same, and if Microsoft ever gets any mobile devices out, they'll have the same problem.

Re:Opera is pushing this... (1)

mounthood (993037) | more than 2 years ago | (#39941483)

Non-Opera prefixes are often used together, and sometimes in production. There is usually an no-prefix rule and two more, one with -moz- and one with -webkit- , and sometimes an -ms-. But Opera often gets left out since they're not that popular. Copying the Webkit prefixes will let them render correctly when there isn't an -o- prefix.

First of all, this "proposal" is coming from the fine folks over at Opera. And the "problem" is that people are using prefixes, just not their prefix (-o-). So they want to do away with them. Just last week they announced they were going to copy webkit's prefix, so I really don'y know why they are proposing this.

Opera wants this because the little players in any market want standardization, and the market leaders always want something along the gradient of 'freedom to innovate' to 'proprietary extensions'. Mozilla/Webkit/Chrome could fix this by not supporting private prefixes by default, and only supporting private prefixes when developers have turned them on. But the market leaders want to use the prefixes to force progress on CSS3 more than they want standardization.

CSS is annoying (4, Insightful)

Lord Lode (1290856) | more than 2 years ago | (#39941141)

CSS is supposed to separate content from layout. However so many layout things cannot be done with CSS in straightforward and portable ways.

Something as basic as vertically centering text is impossible.

Putting things left, right, in a horizontal row or in a vertical row is a nightmare that usually involves creating more HTML elements anyway instead of being able to use pure CSS.

You can't make adaptive colors in CSS, like a shadow color automatically calculated from another color.

On top of that, you can't inherit from CSS classes so have to duplicate the same thing multiple times if you don't want to give each element multiple classes.

How about a new standard, replacing CSS, that truly allows separation of content and style in modern web apps?

Re:CSS is annoying (1)

phantomfive (622387) | more than 2 years ago | (#39941323)

All they have to do to get a true separation of content from layout is add the ability for constants. Then in one file you can define $CENTER_TEXT="Lorem ipsum dolor sit amet, consectetuer adipiscing..." $HEADER_TEXT="elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam" and then in your main page have your layout formatting. Problem solved instantly by allowing you to remove the content, and accepting that HTML is necessary for layout.

Won't solve the vertical centering problem, though.

CSS pre-processors. (1)

oneiros27 (46144) | more than 2 years ago | (#39941539)

The centering bits are a problem, but for the others -- use a CSS pre-processor. (Sass [sass-lang.com] , LESS [lesscss.org] , Scaffold [github.com] , Compass [compass-style.org] , Stylus [github.com] ,etc.)

There are ones that are more Ruby-ish, or Python-ish, etc. Some can calculate colors (darken, lighten, blend, etc.), but almost all let you set things to variables so they can be set in one place and used multiple times.

(and none of this is really new -- I know folks that were using ColdFusion, PHP or even Perl to generate their CSS a good decade or so ago ... it's a page of text, and pretty much anything that can generate an HTML page can generate CSS too)

Re:CSS pre-processors. (2)

phantomfive (622387) | more than 2 years ago | (#39942047)

Can we agree that using a CSS pre-processor is a horrible hack, and that it shouldn't be necessary?

Re:CSS pre-processors. (0)

Anonymous Coward | more than 2 years ago | (#39942279)

Can we agree that using a CSS pre-processor is a horrible hack, and that it shouldn't be necessary?

I used to be of this opinion, then I actually tried using one. It's since been an integral part of my design workflow. Variables, mixins, et al make managing stylesheets much easier and time efficient.

Re:CSS pre-processors. (2)

phantomfive (622387) | more than 2 years ago | (#39942675)

No, that's the problem. They DO make it so much easier. You shouldn't need to add that crap to CSS.

Re:CSS pre-processors. (1)

sourcerror (1718066) | more than 2 years ago | (#39943257)

You should add that crap to CSS.

FTFY

Re:CSS pre-processors. (0)

Anonymous Coward | more than 2 years ago | (#39945695)

I always have problems with CSS. I will definitely be trying some of those pre-processors. I have bookmarked your /. comment, lol.

Re:CSS is annoying (1)

Lord Lode (1290856) | more than 2 years ago | (#39941613)

To continue my rant:

You can't properly choose independently if an element is focusable by mouse only, or by keyboard with tabbing only.

You can't properly to make it break text into multiple lines if a single word is too long and you really want it to break text inside the width of your element. Websites all over the place are now using JS to insert random spaces in long strings like URLs due to this.

Why can't you say with CSS: The text gets THIS area to render itself in, so the text STAYS in there, do the best you can to render it there in a nice way, break between words, or break a word if necessary, but DON'T frigging put the text outside of my div, and DON'T add ugly scrollbars.

Why do table cells get some nice properties that you can't give to divs?

Why can't you do all kinds of awesome things using a SINGLE div and various styles, rather than relying on hacks involving multiple divs, that have to totally change again if seemingly layout-only things of the design change?

Re:CSS is annoying (0)

Anonymous Coward | more than 2 years ago | (#39942309)

To continue my rant:

You can't properly choose independently if an element is focusable by mouse only, or by keyboard with tabbing only.

That is what the :hover and :focus pseudo selectors do, no?

You can't properly to make it break text into multiple lines if a single word is too long and you really want it to break text inside the width of your element. Websites all over the place are now using JS to insert random spaces in long strings like URLs due to this.

Yeah you can. p { word-wrap:break-word; }

Why can't you say with CSS: The text gets THIS area to render itself in, so the text STAYS in there, do the best you can to render it there in a nice way, break between words, or break a word if necessary, but DON'T frigging put the text outside of my div, and DON'T add ugly scrollbars.

p { width:100px; word-wrap:break-word; }
If you want a box with a fixed height and width, then:
p { width:100px; height:100px; word-wrap:break-word; overflow:hidden; }

Why do table cells get some nice properties that you can't give to divs?

div { display: table-cell; }

Why can't you do all kinds of awesome things using a SINGLE div and various styles, rather than relying on hacks involving multiple divs, that have to totally change again if seemingly layout-only things of the design change?

I can. Problem is, apparently you cannot.

Re:CSS is annoying (1)

Lord Lode (1290856) | more than 2 years ago | (#39942741)

I forgot to mention the word wrapping problem is in a table cell.

Re:CSS is annoying (1)

tholme (1385629) | more than 2 years ago | (#39944375)

You can do it in a table cell with a wrapper div, even if you set the width on the table. See example below:

<!doctype html>
<title>word-wrap:break-word test</title>
<style type="text/css">
td {
    width:50px;
}
td > div {
    word-wrap:break-word;width:inherit;
}
</style>

<table><tr><td><div>
Quitealongstringthathopefullyslashdotwillallow
</div>
</td>
</table>

Re:CSS is annoying (1)

lee1 (219161) | more than 2 years ago | (#39941743)

You can't make adaptive colors in CSS, like a shadow color automatically calculated from another color.

You can use CSS compilers, like CleverCSS, for this.

if you don't want to give each element multiple classes.

But that's the best [csswizardry.com] way to do it.

Re:CSS is annoying (0)

Anonymous Coward | more than 2 years ago | (#39942167)

It a text flow layout and that comes with limitations and complicated circumvention. Text flow modes like right to left and bottom to top would be useful but not solve the issues caused by the fact we are working in a text flow model.

CSS Class inheritance would save a lot of labor and make files smaller and easier to maintain. Then you could create some method to shift colors of the parent which would give you some ability to calculate color without introducing variables.

Some of the CSS 3 seems to be going in the wrong direction. We do not need more complexity, conditionals, etc. We could use some new layout models; CSS tables are simple and work to a limited degree; complex situations end up a mess compared to html tables. We could use some new layout models beyond just text, tables, and fixed positioning.

Re:CSS is annoying (1)

arnodf (1310501) | more than 2 years ago | (#39942959)

I suggest a name for the replacement: Advanced Style Sheet or ASS

Re:CSS is annoying (1)

allo (1728082) | more than 2 years ago | (#39944101)

> vertically centering text
because there is no vertical middle. your document is (potentially) endless in vertical dimensions. you want to center it in the window, but the window can become arbitrary large/small.

Re:CSS is annoying (2)

Lord Lode (1290856) | more than 2 years ago | (#39944201)

If you have a div with a certain width and height, you should perfectly be able to center text horizontally and vertically. And UI designers of a web app can and will put the text of every thing centered.

It's such a basic, simple, logical, thing to do that it is really annoying of CSS to not have such a fundamental concept.

Re:CSS is annoying (1)

tholme (1385629) | more than 2 years ago | (#39944471)

It does.

Try:

display:table-cell; vertical-align:middle; height:100px;

Re:CSS is annoying (2)

Tom (822) | more than 2 years ago | (#39945375)

You can't make adaptive colors in CSS, like a shadow color automatically calculated from another color.

On real browsers (i.e. anything except IE, at least up to 8, not sure about 9) you can come very close by using rgba colours for the shadow.

On top of that, you can't inherit from CSS classes so have to duplicate the same thing multiple times if you don't want to give each element multiple classes.

But giving elements multiple classes is kind of the whole idea. I regularily have one class that sets the layout stuff and one that sets colours, etc.

How about a new standard, replacing CSS, that truly allows separation of content and style in modern web apps?

Why? Just because it isn't perfect you want to replace it with something that for many years will be lagging behind?

Constants (3, Insightful)

phantomfive (622387) | more than 2 years ago | (#39941257)

Can we have constants now? That is the number 2 limitation of HTML/CSS right now. Cascading is great, but if you want to change your style, you STILL have to change the color value all over the place. What exactly are they worried about? Unreadable web pages? Have they looked at the web lately?

Re:Constants (0)

Anonymous Coward | more than 2 years ago | (#39941851)

LESS

Filler text to beat the stupid f$cking lameness filter.

Re:Constants (0)

Anonymous Coward | more than 2 years ago | (#39942063)

The simple solution for this in the interim is SASS/SCSS or LESS. You can define constants, functions (mixins), and extend/inherit from other sets. If used properly you should only have to make minor changes to remove all of the vendor prefix stuff when the time comes (if it ever does).

Re:Constants (2)

jbov (2202938) | more than 2 years ago | (#39945431)

you STILL have to change the color value all over the place

You're doing it wrong. There are 146 color names already provided to you. These should provide sufficient color selection for any site. In addition, each color has a very easy to remember, concise name, such as LightGoldenRodYellow [w3schools.com] .

It is best to use these standard names instead of trying to decide on your own variable names. Committees of highly intelligent architects have already decided on the best names for you. For example, see the distinction between Lime [w3schools.com] and Lime Green [w3schools.com] . My personal favorite: Brown [w3schools.com] , which is a carefully chosen contenders Sienna [w3schools.com] or SaddleBrown [w3schools.com] to be the champion of the Browns.

To make things easy, the substrings "grey" and "gray" are interchangeable in any color name.

Please stop trying to reinvent the wheel.

Automatic prefixes (0)

Anonymous Coward | more than 2 years ago | (#39942365)

I'm surprised noone has mentioned prefixfree.js (http://leaverou.github.com/prefixfree/) or cssfx (http://imsky.github.com/cssFx/). Both are polyfills that will automatically apply any missing vendor prefixes at runtime, allowing you to author the CSS without worrying about prefixes.

Re:Automatic prefixes (0)

Anonymous Coward | more than 2 years ago | (#39944173)

mod parent up

Wrong solution to the wrong problem (2)

Archibald Buttle (536586) | more than 2 years ago | (#39942683)

IMHO the use of vendor prefixes was the right thing to do, and remains exactly the right thing to do.

The problem instead is that the standardisation process is taking far too long.

2D transforms, 3D transforms, transitions and animations still aren't officially standardised. They've existed for years, and are now supported in all major browsers (if one includes IE10), and are all essentially compatible. There's mostly only been minor tweaks to them all since they first appeared. Yet these CSS3 features are all at "working draft" stage. Indeed, the 3D transforms spec is a working draft, dated March 2009, over 3 years ago. It's absurd.

The real solution should be instead to expedite the standardisation process. That way the vendor prefixes can vanish much faster.

Re:Wrong solution to the wrong problem (1)

BZ (40346) | more than 2 years ago | (#39942985)

What happened with those specs is that Apple proposed the drafts and Apple employees were the original editors (which all makes sense so far)... and then they did absolutely nothing for a while. Completely ignoring feedback mail, not fixing obvious bugs in the text (e.g. the text totally not matching what every browser, including WebKit, implements).

Hard to expedite the standardization process when some participants sandbag.

After a bit of this, new editors got assigned to the drafts, and they're making better progress now.

Note that you should not be confusing "whatever happens to be published under /TR" with "the current state of the spec. The current state of CSS transforms (2d and 3d got folded into a single document) is at http://dev.w3.org/csswg/css3-transforms/ [w3.org] and pretty much no one involved in the working group or the browsers that are implementing these specs pays any attention to what's happening in /TR land.

One last comment: there have in fact been pretty major changes to 2d and 3d transforms since they first appeared, both in terms of browser behavior (esp. around transitions between transforms) and even more in terms of the actual spec (because the initial drafts submitted by Apple didn't even match WebKit's behavior).

Sadly needed (0)

Anonymous Coward | more than 2 years ago | (#39942695)

Browser vendors need to wait to ship new CSS features until they work. People use these for compatibility hacks where things render differently.

Let's look at the good old days. When CSS first started appearing in user agents, we had crazy stuff like Opera interpreting z-index BACKWARDS. It was fixed in the next major release, but it was a real problem. I had been pushing many of our users to Opera (web designer + tech at ISP) and had to stop recommending it after that. At the time, I could have used something like moz-z-index: 10; o-z-index: -10 or something to work around the broken Opera folks implementation. This was somewhere between opera 3 and 4 and around the time they hired one of the co-authors of the CSS standard.

Not to just pick on opera, remember IE3's very limited CSS which basically let you do link color and hover. In fact, what we really need is a clear CSS1, CSS2, CSS3 definition that browsers provide when they have FULL support for the standard as well as a way to detect user agent and version within a style sheet. It's terrible it's come to this, but if I could just wrap IE is broken crap in a ua:ie { } type thing it would make people happy. Let's face it, object detection was a great idea but it's still a fail. Things don't work right in IE or Opera. Firefox or Chrome can be picky about certain things and lose features in newer versions. Security on iframes and cookies keeps tightening up. Having the object doesn't mean it behaves like it did 3 versions back. We need a whole new model for defining capabilities that isn't broken on the web.

Is not broken, don't fix. (1)

Tei (520358) | more than 2 years ago | (#39943307)

I have write a lot of open source software. I am OSS supported as the next guy, and for OSS standards are very important.

But standards are not more important than progress. With the current system, browser creators can invent any fun stuff and add it on the next update this week. And it don't break anything. And theres nothing bad in that.

About webmaster using it, what is wrong is the level. Wen a JQuery extension or a CSS library (think... reset.css) use a extension, is Ok, because it abstract a problem, so the normal webmaster don't have to know or use all these -moz- -webkit- etc things. These things HELPS, helps so much that we can fix broken things on the web using then, like... making all browsers act the same way. And to do that, sometimes we need a library author, or a JQuery plugin author to put his hands on these extensions. Another similar thing is how you don't have localStorage of HTML5 support everywhere, but you can use it everywhere trought a library that uses something else in browsers that don't support it ( IE has something similar to localStorage from IE5, that is superugly but can be forced to provide the feature).

These extensions are GOOD, but should be reserved to be used by the library authors, not the general webmaster public.

This proposition is WRONG because sometimes you may want to support "opacity", but your programmers can't support exactly as speced, is better to have a --ie-opacity than have a opacity that work different than the standard. The browser extensions allow browsers to support things in a dirty/not complete mode, withouth breaking standards. This proposition is wrong.

Re:Is not broken, don't fix. (1)

Your.Master (1088569) | more than 2 years ago | (#39944303)

The problem is that the system is broken. The web is starting to be written to webkit in much the same way as it used to be written to IE6, even where it doesn't make sense. Using a library is already possible and is already not working. It doesn't matter whether you think it's really the web developer's fault for not using libraries, or the library's fault for not being updated; it's happening.

That doesn't mean I agree with this proposal. I'm wondering if there's a new thing that can be introduced that allows the benefits you described while mitigating the problems that vendor prefixing is causing. For instance, a vendor-neutral prefix for all experimental features coexisting with the vendor-prefix. Maybe that's no better than libraries in the end.

The real solution (1)

Spudley (171066) | more than 2 years ago | (#39945287)

The real solution to the problem is to make the experimental features more obviously experimental.

It should be mandatory that a pre-standardised feature be disabled by default in the browser, and enabled via a preference setting for developers to try them out.

Most non-developer users would not bother to fiddle with these prefs, and thus the features would remain truly experimental until they were standardised.

Yes, this would mean that developers would get frustrated by stuff they want to do which is tantalisingly out of reach in terms of being able to use it for mainstream development. But on the flip side, I believe it would also act as an encouragement to all parties involved to get the features through the standardisation process at a decent speed (this has been a large part of the underlying cause of the problem, not the prefix policy itself).

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?