Dave Hyatt explains the reason why it can’t be implemented in his answers in this article in posts 35 and 37.
Adding absolutely nothing to the list:
I read some time ago about the issues involved in a parent selector; maybe on Moz’s bug list. It’s apparently fraught with troublesome issues involving climbing the DOM tree. It reminds me of Paul’s issues with inline elements bumping into block siblings. And that brings up {display: run-in;}, which I would like to see, but don’t expect anytime soon. As of now, no browser can pass even a small set of test cases, and there exist more than a hundred cases.
cheers,
gary
Having something that actually works across most major browsers would be nice.
http://richardshepherd.com/tv/forms/
Hey if browsers AND their AT equivalents understood this, I could see it all being a better thing… though I don’t really get the whole date-picker thing. Are people supposed to hit those little dates with their fingers if their browser is Touch? Bleh.
All this HTML5 stuff originally came from expanding/bettering forms, and so far that’s the only thing I’m starting to think is worthwhile. Of course, I can so totally see silly people relying on these for validation instead of always always using the server (never trust a client).
Is that XHTML or HTML? Pick a ruleset and stick with it…
Hey that guy may be confused about whether he wants to add extra characters to be “XHTML” with the slashes or save characters by using “required” instead of
required=“required”
but that doesn’t mean the rest of us have to.
Typekit bloats out the page for no good reason, unless of course that reason is to make every single label ILLEGIBLE…
YOU choose to surf with JS on… I never saw it : ) Perfectly legible for me and I didn’t have to wait for the crap to load.
and of course those are all checks you are going to have to do server side again ANYWAYS so the only time you’d have any ‘savings’ is when people fill it out wrong – which should NOT be frequently enough if you label your form elements correctly for the server load to be even worth thinking about.
If it herds people into putting the right information in the FIRST TIME I’m all for it. I remember when my husband’s company got an irate female who was pissed that she couldn’t register. Apparently she didn’t realise that once you register once, you don’t have to do it again, and she managed to ignore the large text in the middle of the page telling her she was already registered so it’s not like we can assume people actually read or anything.
Of course what should be an invalid form working just fine in the validator is another of the things I just HATE about HTML5. Let’s just throw away all the well formedness rules and let people slap it together any old half-assed way. At that point we might as well go back to HTML 3.2 or Tranny.
I can write my HTML4 “legally” and leave off my closing p’s and li’s but I don’t. Why would it be any different here? People have always been allowed to write sloppy code and HTML5 doesn’t change that— it only changes how browsers deal with garbage.
And no I don’t see the point in wasting bytes on closing slashes for a fake doctype when I can just tell the validator to pretend my HTML4 is XHTML to give me the dirt on any errors, psh : )
@stupid kitty – I dunno, that’s the type of half-assed mish-mash of code that’s part of my ‘issues’ with HTML5.
Is that XHTML or HTML? Pick a ruleset and stick with it… Typekit bloats out the page for no good reason, unless of course that reason is to make every single label ILLEGIBLE… and of course those are all checks you are going to have to do server side again ANYWAYS so the only time you’d have any ‘savings’ is when people fill it out wrong – which should NOT be frequently enough if you label your form elements correctly for the server load to be even worth thinking about.
Increasingly I’ve had the same attitude about javascript form checks. I’m seeing less bandwidth and CPU use on the server by just sending the damned form again than I am wasting time sending extra code to everyone whether they use it or not!
Of course what should be an invalid form working just fine in the validator is another of the things I just HATE about HTML5. Let’s just throw away all the well formedness rules and let people slap it together any old half-assed way. At that point we might as well go back to HTML 3.2 or Tranny.
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.
Me too but that was XHTML1.1 and XHTML2 and people wanted authors to be able to author whether they know what they’re doing or not. Glad it’s not that way with rocket surgeons.
And then there was that Mark Pilgrim’s The World Would End If We Had Draconian Error Handling thing that was so delightfully entertaining. You should check it out, it’s hilarious.
Hi there funky Dutch woman – yeah, that was a good read. Thanks.
The syntax for the design shown in figure 1 (display: “aaaaaaa” “bccccdd”) just makes so much sense.
That said, I think there will always be the masochists and hobbyists who get pleasure from setting floats and clearing floats and using negative margins and obsessing over haslayout issues and reviling those who use tables and being ultra concerned about semantic markup and believing with genuine sincerity that achieving valid code with a strict doctype is the ultimate nirvana.
How boring! I think I’ll go and get another beer.
Haven’t tested it but something like td:not(.variable) ?
To be fair, browser compatibility problems aren’t CSS’s fault.
Off Topic:
I lawl’d, was a huge fan for years
Way, way, way
Off Topic:
If you don’t eat your meat, you can’t have any pudding! How can you have any pudding if you don’t eat your meat?
But when the browser makers are dicking around with all that goofy CSS3 bull when they don’t even have CSS 2.1 working properly yet…
When I eat cake, I eat the frosting first. And once when I was a kid the candles weren’t wax but something edible, so every year since then I’ve tried to eat those too : (
And CSS transitions aren’t?
You can’t have your cake and eat it to. CSS is crippled by the lack of these features - I can routinely create styleseets in less that are 1/3 the size of their css output.
And with the introduction of the Transitions library it’s only going to get worse.
Finally, you’re flat wrong. If the use of these constructs was required you’d have a point, but the adding of less rules to CSS rules would be a valuable option for those of us smart enough to use them but pose no obstacle or hindrance to those who aren’t (except for the need to write several pages to get 2 pages work done). Until control structures (conditionals like if/else and loops like ‘for’ and ‘while’) are added the language will not be programmatic by definition.
Why is this useful? If you’re using JPEG for photos and GIF or PNG (properly) for logos, etc. then zipping them up is only going to improve your filesize by a few percent at the most. And if you only want to access one image, there are two possibilities: the browser downloads the whole zip file and extracts the image. Or, the server extracts the image and serves only that image. The latter could be simplified by just not using zip archives, and the former would just be a stupid waste of bandwidth and time.
It would also be nice to be able to point the <link> at a zipfile and have it use all of the CSS files found in the zipfile as well. It would make it easier to organize CSS and combined with the hash for images thing could load all of the style related elements with one HTTP request.
You can pretty much already do this.
As for what I’d want, I can see why parent selectors are problematic, but a :contains selector would be nice. E.g. something that targets anchors but only if they contain an image.
nice but all that does is attempts to make CSS more programmic… which it isn’t
I would love to see the features of less folded into CSS
Something like list comprehensions from Haskell or Python mixed with CSS combinators for element selection (I didn’t put too much thought into this but you get the idea)
[color:red(x.foo>ul) | x <- [div.bar, span>baz], x:nth-of-type(2n)]
CSS3 has a calc() function.
But looking at how well counter() got implemented in CSS2, I’m not holding my breath : )
*edit