table.resizable {
resize: user;
}
The user could then drag column and row separators on that table to ‘nudge’ the data into place. So many times I’ve wanted to do this when visiting a site.
Now that I think about it, there are lots of times I’d like to be able to grab a corner and drag an element so I can see it properly, like Chrome lets you do with TEXTAREAs.
What’s your fantasy CSS feature?
Well, I guess then that’s the biggest change I’d like to see in some future version. STOP allowing people to sleaze together sloppy code any old way.
That’s part of the point of strict, I guess I’d just like to see ‘stricter’. Strict formatting rules for CSS would be nice – force people to stop the slap everything on a single line in a jumbled mess asshattery.
#container{
layout-type: 3-column;
column-width: equal;
column-spacing: 30px;
design-type: elegant;
compatibility-mode: full-backwards-compatibility;
loading-speed: fast;
google-analytics: not-required;
auto-debugging: required;
valid-code: required;
PIE: required;
minify: required}
#footer{
footer-type: sticky}
I posted earlier about incorporating less, but here’s a major addition I’d love to see - layers.
Cascading is fine, but it can get out of hand. There are times when you want to just start fresh. Layers accomplish this. Layers are marked with a $ in the sheet.
$overlay {
z-index: 1;
opacity: .2;
touchable: no;
}
This defines the layer and defines it’s properties.
Layers are attached to the elements like class and id.
Assigning properties to just $ will assign them to the default layer.
The most important part of layers is that each declared layer has its own cascade context!! Items on one layer do NOT inherit from parent items on a different layer. Child elements inherit their layer from the nearest parent with a defined layer.
This allows for blocks of content to have a styling that will not change if their position on the screen is changed (a MAJOR annoyance of CSS since the beginning).
Thoughts?
[ot]
Perhaps they were tallow candles or coated in icing-sugar. Are you sure you just didn’t fancy eating candles; to see what they tasted like. Though actually enjoyed munching on them but were too afraid to admit it? ;-)[/ot]
I don’t hear anyone demanding that javascript be off by default.
That wasn’t the point, it’s that things that bug users always happen to be strangely popular with web devs for some reason…
And I’m no power user of printers. I just pay through the nose for ink, and have actually switched brands due to the old one having cartridges with a “date” on them… after that date, they will say they are empty even if they aren’t. A school near where I used to live had a warehouse full of them and none of them worked lawlz.
The only thing I want printing image-wise are google maps.
variables would be lovely. :tup:
Since I’m currently working on print output, it would be nice if all CSS properties were as well-defined in the paged media context as they are in the continuous media context. For example, it would be nice to know if a div that is split by a page break will have its min-height property applied to both halves or just the whole. (And maybe that stuff is more well-defined than I realize-- I’m pretty new to this).
First, it would be nice if all css features actually worked cross platform.
The biggest missing feature is the ability to vertically align block elements.
<div id=‘banner’>
<p>Vertically Center this text</p>
</div>
<div id=‘footer’>
Put this element to the bottom of the page without complicated mark up.
<div>
Here’s a more specific print-related CSS property that I’ve thought about pretty extensively:
background-printing: enabled;
I think giving web developers the ability to “opt in” to background printing could open up a lot of possibilities. I know, I know, only the noobiest of noobs would be so ignorant as to even contemplate such an awful thing. But think about it-- background printing could still be off by default, and no honest dev would choose to turn it back on unless they had a legitimate reason (readability, for example). So what are we worried about, then? That dishonest web developers will purposely enable background printing just to waste the user’s expensive ink? Well, that risk is already here, because it’s pretty easy to use borders to simulate background colors, and the @media print rule to hide what’s being sent to the printer.
I’m quite a big fan of sass, I’d love to see it’s features in stock CSS. That being said, I’m more of a programmer, so even sass doesn’t have as many features as I’d really like (basic objects, variable references… the last major site I worked on had nine different site sections, each with nearly a dozen different shades of its primary colour associated with it… would have been nice to wrap them up into tidy objects.)
For me, as suggested in an article here once, regular expression selectors with back-references available to the rules inside. Other than that, counter to be implemented, constants (for multiple color declarations etc), caluclations to be implemented properly, and a parent selector. All of which have been mentioned above anyway 
Part of me likes the idea of nesting selectors, and part of me doesn’t. I don’t care about the whole ‘CSS isn’t supposed to be a programming language’ arguments, they hold no water with me, but in a lot of cases the CSS doesn’t lend too well to nesting. I guess having it would be the best solution because you don’t have to use it for everything… but imagine you want to add a second selector to a group of rules using the comma, and that set of rules are nested deep in something else - you’d have to extract it first!
bah
Too flaky. I’m assuming your intending that if the link destination is the same as the URL the browser believes it is currently looking at, :current will be applied to that link, yesno? The biiiig problem with that is that URLs are rarely unique - there are usually several ways to construct a URL to get to a given page, and more so once you start to look at redirects from previous structures. I would imagine that your solution would only work when the two URLs matched exactly, and so would fail whenever they were different. That is nowhere near robust enough, not when there are plenty of solutions that do work properly now.
Consider the differences between javascript, a programming language, and css, a declarative language. Javascript modifies the DOM, while css has no methods, none, especially zilch methods that work on the DOM. Javascript will navigate the tree until it finds the element it’s looking for. It is trivial then to step back to the parent. In css, the DOM is stepped through, then for each element, all all applicable selectors are found, and the property/value pairs are combined, following a set of rules. There is no guaranteed unique element for, say p:parent {foo:bar;}. Only for something like #foo > bar:parent does a unique solution exist, and that solution is redundant to #foo.
conditionals and loops
We already have that, but we call it javascript. Once you go there, you’re talking about a programming language, not a declarative language.
better abstraction. you do too many damn things in CSS using properties whose name has nothing to do with why you’re using them. Side effects not uncommon in any language, but CSS seems to live for them.
Can you cite an example? And, explain why the why of it is desirable. Not knocking it, I just haven’t a clue what you’re talking about.
cheers,
gary