W3C Member Proposes "Fix" For CSS Prefix Problem 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.
The solution is.. (Score:4, Insightful)
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.. (Score:4, Funny)
Yes, they should just use the standard.
Stupid microsoft.
Re:The solution is.. (Score:5, Informative)
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: (Score:3)
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: (Score:2)
Re:The solution is.. (Score:5, Informative)
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: (Score:3, Interesting)
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
Re:The solution is.. (Score:5, Insightful)
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.
What we really need is to learn to strongly resist the idea that a page need look perfect on any browser. This is a "drop-dead" requirement that can't be achieved. Even if you think you've done it for one browser, the next upgrade (which is probably being installed by some of your clients right now) will shoot down your perfection. And the developers of commercial browsers (e.g. IE) have taken great pains to ensure that you can't succeed. They want walled gardens, and they're building them. The concept of "perfection" in web pages is one of their tools. The only way to win this game is not to play it.
Since the start of the Web, the main function of HTML has been to make documents that are usable as widely as possible, despite the huge differences in displays, window systems, input devices, etc. The right way to test pages is to verify the usability of a page on a wide range of devices, now including handhelds. Web designers that design a "perfect" page and insist that it look the same everywhere are missing the main point of it all. The vendors are guaranteeing that you can't do this, no matter what your design.
If your page insists on a "perfect" display of the page, it will simply fail on display and/or window systems that don't permit your page's requirements. So aim for "functional" instead, with design aesthetics a distant second, and you'll produce much more usable pages.
This may require educating your boss(es) about the nature of your "market". But they should be used to this. After all, consider the canonical auto analogy: What would you think of a boss who thought that a single model car can be built that will satisfy all customers? That's just dumb, right?
Re: (Score:2)
I used to be excited about the web, until I realised it was a document display network that's being shoehorned into an application delivery platform using a woefully ill equipped scripting language -- Protip: It's called JavaScript because you're supposed to do little with it, and leave the heavy lifting to Java. Google Drive is out! To use it in a web app (JavaScript) I'm supposed to use to Base64 encode the data and manually construct a multi-part POST request and send it through an iframe proxy -- WHAT
Re: (Score:2)
Oops, forgot to escape the tags, what a joy --- that's supposed to be a JS game in IE6 dom (on a Pentium III) beating out the port of the same game in HTML5 + <canvas> & <audio> (on a 2.3Ghz dual core P4). So, it's like watching that car from "The Beverly Hill Billies" winning a Formula One race because "the state of the art" cars have to many crazy carbon-fiber wings attached.
Re: (Score:3)
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: (Score:2)
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: (Score:2)
Personally, for my own sites, I go for "It's standards compliant and works in Safari/Firefox/Chrome, it's done".
For work we tend to target recent Chrome/FF/Safari and IE7+. This generally works well as most users have upgraded to at least IE7 at this point.
Re: (Score:2)
Obviously a single sentence cannot possibly describe all the failures in standards compliance that ruin IE6 but some of the more interresting things you can do with more recent non-IE browsers simply fail in IE6. Sad as it is, but tables are still the most reliable method for layout and some things are a lot easier to do with tables than with divs (although using display:table/table-row/table-cell helps somewhat).
Re:The solution is.. (Score:4, Funny)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
What I'm saying is that a version of IE that is still in everyday use by a significant portion of visitors is far far worse.
It wouldn't be so much of a problem if those users upgraded to IE9/10 or any other browser.
Re: (Score:2)
Javascript is a language with a lot of evil, dirty stuff in it. Too bad most people can't look past the evil, dirty stuff and see how a little restraint and knowledge on the side of the programmer can turn it into an elegant language.
I came to Javascript from a mixed background of mostly C/C++, COBOL and PHP and had a lot of problem creating good code in JS as well ... until I started reading some books on what "features" to ignore and how the object model works. It's just a paradigm shift in how you design
Re: (Score:2, Troll)
Re:The solution is.. (Score:4, Insightful)
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.. (Score:5, Insightful)
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.
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?
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: (Score:2)
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 Microso
Re: (Score:2)
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 -we
Re: (Score:3)
No, the CSS rules say that when there are conflicts, the last one overrides.
For example, if I specify background-color twice for the same selector (or selectors that end up selecting the same elements), then the last-specified overrules any prior ones.
In the case of the vendor-specific prefixes, however, there is no conflict. Keep in mind that browsers aren't even supposed to be reading other browers/vendor/engine/whate
Re:The solution is.. (Score:5, Informative)
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: (Score:3)
Re: (Score:3)
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 (althoug
Re: (Score:2)
My old site had rounded corners in 1997
... by using tons of nested tables and images (but not background images, mind you -- those weren't around in '97). Which means more requests and a more complicated document for the browser to render. You may think you're a badass web designer for doing that, but in reality you were just adding load time for your users. Photoshop probably did all the work for you anyway.
...they come to your site for its content
If that was true, then all websites would be black serif font on a white background with a standardize navigation either to the left or to
Re: (Score:2)
The tables weren't nested and the images were small. I've always been a limited maximalist in design, minimalist in code. I laid it out so something interesting happened while loading; for example, one month I had a very small animated gif that tiled for the background that started as green ones and zeros wich changed and eventually disappeared as the page loaded. Very little javascript, always short programs, and only when needed. Its pages weiged in at far less than almost all of today's web pages.
Back in
Re: (Score:2)
Still, not having to mess around with nested divs and the like just to get fairly basic design features is nice and allows you to put more effort into other parts of the site (such as content and actual features).
Re: (Score:2)
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.
Developers are not "lazy". They just don't want to write out the same fucking CSS property 5 times to get it work correctly in all browsers. Especially when there's syntax difference other than the prefix in all 5 declarations.
That's kinda the point of TFA: this model is trying to solve some theoretical problem, but is it really a problem? We didn't have prefixes back in HTML4 days, and so what? innerHTML (an IE invention that was quickly picked up by other browsers) turned out just fine in the end - part o
Re:The solution is.. (Score:5, Informative)
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 */ /* newer webkit method */
-webkit-linear-gradient(top, #000000 0%, #ffffff 100%);
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: (Score:2)
In this particular case, it doesn't look like they actually need two different property names to distinguish the two. Just try to parse the value assuming that it uses the new standardized syntax; if that fails, parse it using your legacy syntax.
Are there any real cases of prefix properties where the value syntax was different, and it couldn't be distinguished from the later standard syntax by looking at the value alone?
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
When ANY browser does something non-standard, it breaks the web. Period.
Re: (Score:2)
The idea is to allow experimental feature implementations (that may differ between browsers).
The problem is with web developers who don't just use them in production environments but actually rely on them.
I'll admit I've used them a few times in production environments but the reasons have been:
Re: (Score:2)
Because the interface hasn't been defined yet. They're making experimental functions with no standard interface, so the prefix indicates it's not designed for production use yet. Look at CSS gradients, and even border-radius: until relatively recently, there were multiple different ways to achieve the same effect depending on the browser and that vendor's prefix: -moz-border-radius-topleft vs -webkit-border-top-left-radius (the latter won out and is now the standard, sans prefix) further complicated by non
Re: (Score:2)
Browsers should ship with prefix support disabled (Score:4, Insightful)
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: (Score:2)
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 o
Re: (Score:3, Insightful)
Re: (Score:1)
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 a
Re: (Score:2)
It's the same old argument - do you want the standard to be a rubber stamping of an ad hoc development with all its quirks and flaws, but available to play with early on in all browsers? Or do you want it to be a polished document produced by a committee of several dozen people deliberating over the fine details of syntax for 2 years, but available very late (and in the meantime, incomplete/fragmented implementations between browsers)?
TFA argues for the first model. If it works, let it stick, even despite m
Here's another proposal: (Score:5, Insightful)
Re:Here's another proposal: (Score:4, Insightful)
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: (Score:1)
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.sta
Re: (Score:2)
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: (Score:4, Interesting)
Funny
It takes work, but so does anything worth doing.
Re: (Score:2)
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: (Score:2)
Maybe companies should stop touting proprietary features in an attempt to infect the market and strong-arm the standards committees.
Re: (Score:2)
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: (Score:1)
Re: (Score:2)
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: (Score:1)
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: (Score:4, Insightful)
...and some vendors (mostly Apple, a little bit Google) have an interest in that not happening. So good luck waiting.
Re: (Score:2)
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 innovat
Re: (Score:2)
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: (Score:2)
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-standar
Re: (Score:2)
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.
You know that the W3C is an industry consortium, right? In other words, the browser vendors whom you claim are not going to wait are the very same people who are taking too long to finalise the standard.
Proposed ideas are going through vigorous testing in the real world long before a finalized plan for that idea is set.
Yeah, that's kind of how things work here. Vendors take a working draft, implement some experimental features based on that, throw a few implementations at the wall to see what sticks, then bring them back to the committee and suggest them as new inclusions in the standard. The committee (filled as it is wit
Bias Reporting (Score:1)
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: (Score:3)
Oh.
Re: (Score:2)
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.
Good proposal (Score:3)
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... (Score:2)
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... (Score:5, Informative)
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: (Score:2)
if Microsoft ever gets any mobile devices out, they'll have the same problem
Ironically, it was already done [zdnet.com] in the very first release of WP7 (for one particular property), but developer feedback [msdn.com] was overwhelmingly negative, so it was reverted.
Re: (Score:2)
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 'pro
CSS is annoying (Score:5, Insightful)
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: (Score:2)
Won't solve the vertical centering problem, t
CSS pre-processors. (Score:2)
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,
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
You should add that crap to CSS.
FTFY
Re: (Score:2)
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 b
Re: (Score:2)
I forgot to mention the word wrapping problem is in a table cell.
Re: (Score:1)
<!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: (Score:2)
You can use CSS compilers, like CleverCSS, for this.
But that's the best [csswizardry.com] way to do it.
Re: (Score:2)
Yes but if you're resigned to using a compiler then you may as well do away with CSS entirely and compile your site into straight HTML.
Re: (Score:2)
Re: (Score:1)
I suggest a name for the replacement: Advanced Style Sheet or ASS
Re: (Score:2)
> 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: (Score:3)
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: (Score:1)
Try:
display:table-cell; vertical-align:middle; height:100px;
Re: (Score:3)
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?
Re: (Score:2)
The aligning problems you cite are exactly the sorts of new features that are subject to the prefix problem -- see the flexbox spec (at http://www.w3.org/TR/css3-flexbox/ [w3.org])... and then see the 2009 flexbox spec (at http://www.w3.org/TR/2009/WD-css3-flexbox-20090723 [w3.org]). Most browsers (minus the IEs) support the old version. A few Chrome versions -- NOT -webkit-*, just Chrome -- support the new syntax (see http://caniuse.com/flexbox [caniuse.com]).
So, to sum up: we have this new standard you desire, but the problem addresse
Re: (Score:2)
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.
CSS3 Grid Layout [w3.org] - which is basically an adaptation of the traditional desktop UI layout model as seen in Swing, Qt etc - finally fixes that. The only catch is that, so far, the only supporting browser is IE10 beta...
Constants (Score:4, Insightful)
Re: (Score:3)
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], wh
Re: (Score:2)
Re: (Score:2)
I'd rather have constants defined up top mainColor = #FF0000;
As long as you make sure the CSS file defining the constants is loaded first, and you make sure your designers aren't trying to use these constants as variables. I'm sure that wouldn't happen since designers grasp programming concepts so well, especially when they are programming in the CSS programming language. Interpolation would require slightly more memory in the browser, therefore it would be more efficient to do this in JavaScript by looping through each element in the DOM and using IF statements with
Re: (Score:2)
Re:Constants (solution) (Score:2)
//Respond with 304 (not-modified) unless the file is changed. This means the PHP file is only evaluated once per client per session.
$last_modified_time = filemtime(__FILE__);
$etag = md5_file(__FILE__);
header("Last-Modified: ".gmdate(
Re: (Score:2)
Wrong solution to the wrong problem (Score:3)
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: (Score:2)
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 bet
Is not broken, don't fix. (Score:2)
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 prob
Re: (Score:2)
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
The real solution (Score:2)
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 tantali