Quick! Someone explain to me how CSS is awesome and great and The Real WTF is me!
-
If you can't see images because my domain is blocked at your workplace? Suck it.
-
If I had to guess, I would say that it's an interaction between the text and the size of the div. Try adding overflow:hidden to the top div, if that produces the same effect as adding a pixel of padding that's what's going on.
-
Yup, you're right, that fixes it. I think CSS was designed with the principle of "most surprise", like that Google API in the other thread.
Now I just have to figure out how to get the web server to serve my .theme file with the right MIME type...
-
I agree; CSS is awsomely contrary. My favorite problem is how to get a rectangular box of a given size onto the screen regardless of what's inside it. My div-tags keep resizing to fit the contents. The best I can come up with? A TABLE CELL! Not CSS!
-
CSS would be awesome and great, in spite of quirks like that one, if at least they were always consistent between browsers.
-
CSS is awesome. TRWTF is whatever you are using to render it.
-
@CrisW said:
CSS is awesome. TRWTF is whatever you are using to render it.
If CSS is so awesome, then why hasn't anyone built a browser that can render it sans WTF?
-
@AndyCanfield said:
I agree; CSS is awsomely contrary. My favorite problem is how to get a rectangular box of a given size onto the screen regardless of what's inside it. My div-tags keep resizing to fit the contents. The best I can come up with? A TABLE CELL! Not CSS!
What's wrong with {display:block; width:123px; height:456px; overflow:hidden } ?
-
@AndyCanfield said:
My favorite problem is how to get a rectangular box of a given size onto the screen regardless of what's inside it
Set width and height. Done.
Can you provide code of where it goes wrong?
-
@blakeyrat said:
problem
On of the shittiest features of CSS is margin overflow. That is, the first and last elements in your grey box are probably a P. With margin. Which overflow outside the grey box because I don't know I think someone at the W3C got really high one day.
Padding at the relevant egde stops that behaviour. Overflow:hidden/auto also stop that behaviour.
-
@pjt33 said:
@AndyCanfield said:
My favorite problem is how to get a rectangular box of a given size onto the screen regardless of what's inside it. My div-tags keep resizing to fit the contents.
What's wrong with {display:block; width:123px; height:456px; overflow:hidden } ?Thank you. That works. I wrote it as:
<div style='border-style:solid;border-color:red;display:block;width:300px;height:100px;overflow:hidden'>
and it did make a rectangular box on the page, with a cropped picture inside, and the text inside, and white space as extra.
In my own defense, when you specify width and height in CSS, why doesn't it believe you? These are suggestions?Argh!
But my file Test-css.html has your solution in it, so I can refer to it in the future. Thank you!
-
@Seahen said:
CSS *would* be awesome and great, in spite of quirks like that one, if at least they were always consistent between browsers.
If you want to see what your website looks like on different browsers I have previously used this:
-
This thread has taught me to use overflow: hidden on EVERY CSS element I ever work with from now on.
-
@Seahen said:
CSS *would* be awesome and great, in spite of quirks like that one, if at least they were always consistent between browsers.
Surely that's a browser issue, than a CSS issue - the fault lies not in the specification, but in coders' interpretation/implementation of it.
@Seahen said:
If CSS is so awesome, then why hasn't anyone built a browser that can render it sans WTF?
Browser issue, coder issue, etc - not CSS issue. Also, good that CSS is, I'm not sure I'd describe it as "awesome". I'm impressed, but not really completely awe-struck by it.
@AndyCanfield said:
In my own defense, when you specify width and height in CSS, why doesn't it believe you? These are suggestions?Argh!
I got the impression those work like table cell dimensions: they're a min size, but the container will expand to fit a bigger object, rather than cropping it to fit the specified dimensions. (ISTR that there is a crop option, mind.)
FWIW - there have been some studies on how different browsers implement the box-model, and the way in which padding/spacing/margin is used has caught me out also. Tweaking one or two settings has (apparently) created the display I sought, only to find it was the wrong setting yet still had a desired effect.
Web Dev toolbar and firebug often helps in this situation, I find.
-
@AndyCanfield said:
In my own defense, when you specify width and height in CSS, why doesn't it believe you? These are suggestions?Argh!
When you specify width and height, these are always very strictly respected. It's possible that your layout gave the illusion that this was not the case.
Second, divs are already block. Setting them to display:block; is a NOOP.
-
@The_Assimilator said:
This thread has taught me to use overflow: hidden on EVERY CSS element I ever work with from now on.
Then you are not fit to write code of any kind.
-
@Cassidy said:
I got the impression those work like table cell dimensions: they're a min size, but the container will expand to fit a bigger object,rather than cropping it to fit the specified dimensions.
Let me just use really big type here because you are all feeding eachother half-truths and misinformation.
NO, THAT IS WRONG.
width and height on a block element will always produce exactly that width and height, unless you're in IE6 and/or quirks, in which case you have bigger problems.
@Cassidy said:
they're a min size
For that, CSS has min-width and min-height, and their max- counterparts.
@Cassidy said:
ISTR that there is a crop option, mind.
That would be overflow:hidden;
-
Aha - ta for the corrections, it was probably min-width: rather than width: I was thinking about.
(I don't do enough CSS to have many attributes memoried, my CSS2 book is well-thumbed and the W3C specs are bookmarked in my browser for reference. I keep looking things up then slapping my forehead with a "I've used that before! Should have remembered...")
Footnote: anyone else notice that if you move the "Quick Reply" box around, you lose the cursor in it? Seems I've got to tab away then back again to make it visible)
-
If you give a div a width and height, and put contents inside it which exceed those dimensions then most browsers will (and I belive should according to the spec) force the div to the minimum size it needs to be to accomodate the content, resulting in it being larger than the original dimensions you specified. This is why the overflow property works to crop the extra content.
I believe that max-width and max-height were brought in for this reason, to instruct the browser never to go above these dimensions, and implying that overflow:hidden is on without specifying it, although that doesn't really work most of the time because of bad implementation by browsers.
On a side note, I've had my own CSS wtf this morning. IE allows you to style a <nav> element if you make sure the element is declared properly with Javascript. However, IE7 renders it as a block level element by default, and IE8 renders it as an inline element. I know neither browser version actually supports the <nav> element, but I'd appreciate it at least if they didn't support it in the same way, rather than each version making a half-arsed attempt.
-
@dhromed said:
Let me just use really big type here because you are all feeding eachother half-truths and misinformation.
NO, THAT IS WRONG.
width and height on a block element will always produce exactly that width and height, unless you're in IE6 and/or quirks, in which case you have bigger problems.
That's a half-truth as well. The block element will be exactly that width and height, but it might appear larger because its contents will (by default) overflow out of it if they don't fit.
CSS is really rather quirky, and it wasn't originally designed for the kind of things it's used for on the web nowadays. In 10 years the stuff which they're currently specifying might be stable enough and sufficiently widely deployed that it's possible to learn it* without uttering "WTF", but at present some beating of head against wall is normal.
* To the level that you can produce the layouts which designers pass you, not just on a theoretical basis.
-
@dhromed said:
@The_Assimilator said:
This thread has taught me to use overflow: hidden on EVERY CSS element I ever work with from now on.
Then you are not fit to write code of any kind.
Don't make me write /sarcasm at the end of my posts.
-
@The_Assimilator said:
@dhromed said:
@The_Assimilator said:
This thread has taught me to use overflow: hidden on EVERY CSS element I ever work with from now on.
Then you are not fit to write code of any kind.
Don't make me write /sarcasm at the end of my posts.
My apologies. I was tired.
-
@pjt33 said:
but it might appear larger
So, it isn't actually larger.
@pjt33 said:
it wasn't originally designed for the kind of things it's used for on the web nowadays
That is the idea one gets, unfortunately.
@pjt33 said:
To the level that you can produce the layouts which designers pass you
TBH, I don't have much trouble with that part.
-
@Seahen said:
@CrisW said:
CSS is awesome. TRWTF is whatever you are using to render it.
If CSS is so awesome, then why hasn't anyone built a browser that can render it sans WTF?
They have. Those are the browsers that pass the Acid II test.
-
@CrisW said:
They have. Those are the browsers that pass the Acid II test.
I'd prefer it if they rendered my CSS right.
-
@dhromed said:
@CrisW said:
They have. Those are the browsers that pass the Acid II test.
I'd prefer it if they rendered my CSS right.
You mean that you wished that the css did what you wanted it to do, rather than what you told it to do.
-
Well, in some cases, it'd be nice if the browser did what the CSS specs claimed it should do, rather than what the browser developers thought it ought to.
Thankfully most modern browsers honour the CSS spec much closer than their earlier counterparts. About a week before I refused to start adding CSS hacks in so the page would display properly in IE6, Youtube announced they were dropping support for that same browser, and other organisations began to follow suit. No, it wasn't something I started, but I convinced higher-ups that adding workarounds for a broken browser was increasing development costs/timescales by another 25-50%, and this practise was only encouraging longevity for something that should have been deprecated long ago. The Youtube decision showed I wasn't the only one that thought that way...
/derail...
-
@CrisW said:
You mean that you wished that the css did what you wanted it to do, rather than what you told it to do.
Doesn't anyone, who writes any sort of code, wish for this?
-
@CrisW said:
You mean that you wished that the css did what you wanted it to do, rather than what you told it to do.
Heh, no I mean that the browsers would actually do what I tell them to according to the specs.
-
@Cassidy said:
I wasn't the only one that thought that way...
And now it's time for IE7 and 8 to die.
-
Ok I didn't read all the posts because, Jesus Fuck what the hell.
Here's the WTFs in order of WTF-ness:
1) Making a 1-pixel change to the .css file doesn't result in a 1-pixel change to the page.
2) Setting the padding-bottom to anything other than 0px somehow also magically enables a completely unrelated overflow option.
3) The overflow: hidden option is documented (by W3Schools at least) as so: "The overflow is clipped, and the rest of the content will be invisible" WHAT THE FUCK does that have to do with the behavior I'm seeing on the screen when I set it? The overflow isn't "clipped", it actually extends further than it did without overflow: hidden set.
4) CSS doesn't have a way of defining simple columns. (I know this is completely unrelated to the posted WTF, but it's such a huge WTF I thought I'd add it anyway.)Here's the URL, if anybody wants to look at the code: hiareyou.com
-
@blakeyrat said:
4) CSS doesn't have a way of defining simple columns.
Yes, this is a huge WTF.However, for the other 3 points, how are those problems with CSS? Aren't they examples of the browser not rendering things properly?
-
@El_Heffe said:
However, for the other 3 points, how are those problems with CSS? Aren't they examples of the browser not rendering things properly?
Since IE8, IE9 and Chrome all rendered it identically, I assume not. Unless you're going to make the ludicrous claim that all of those browsers are broken-- IE8, maybe. But the other two? Hah.
Besides which, it doesn't fucking matter because I live here in this place called the "real world" where my webpage is viewed by real people using browsers like, say, IE8, IE9 and Chrome. If it doesn't work in those browser, it doesn't fucking matter whether it doesn't work because the browser is broken or because the spec is broken, the end result is it's broken.
So you're wrong, and your argument is fundamentally flawed. Congratulations.
Edit: BTW, I would also argue that a spec so complicated that it's even possible to get something like this wrong, and one with no test suite/reference implementation to forestall errors like this, is completely broken. I mean the entire IE/W3C split in the first place was caused by a CSS spec that was so fucking vague it didn't bother to define how the box model was actually supposed to work-- then it became Microsoft's fault when they implemented it "wrong". (Even though, by the wording of the spec, their implementation was correct.) That is a problem with the spec, not the browser.
-
@blakeyrat said:
4) CSS doesn't have a way of defining simple columns. (I know this is completely unrelated to the posted WTF, but it's such a huge WTF I thought I'd add it anyway.)
Amen on that one. ISTR a discussion about CSS trying to provide typographic facilities but predated the columnar format popular with blogs and online periodicals. It really is crying out for some way to allow text to flow between multiple columns. Perhaps that may come with CSS4...
@blakeyrat said:
Here's the URL, if anybody wants to look at the code: hiareyou.com
Nice pics, BTW. Some remind me of Fractint doing mandlebrot or plasma renders.
-
@blakeyrat said:
2) Setting the padding-bottom to anything other than 0px somehow also magically enables a completely unrelated overflow option.
Isn't it fun? :D
@blakeyrat said:
3) The overflow: hidden option is documented (by W3Schools at least) as so: "The overflow is clipped, and the rest of the content will be invisible" WHAT THE FUCK does that have to do with the behavior I'm seeing on the screen when I set it? The overflow isn't "clipped", it actually extends further than it did without overflow: hidden set.
Oh, that's a different thing. Overflowing margins are not principally related to the overflow property. Isn't it fun? :D
-
@Cassidy said:
It really is crying out for some way to allow text to flow between multiple columns.
?
CSS3 can format text as columns in an element.
-
@Cassidy said:
Surely that's a browser issue, than a CSS issue - the fault lies not in the specification, but in coders' interpretation/implementation of it.
If there is room for "interpretation" in your technical specification, then your technical specification has a fault.
-
@blakeyrat said:
3) The overflow: hidden option is documented (by W3Schools at least)
Using W3Schools as a reference for anything makes you TRWTF. There are various non-WTF reference sites for HTML and CSS: the one I use is http://www.htmldog.com/reference/
-
This is a CSS behaviour called “margin collapsing” (dhromed got close). Here is the relevant part of the spec. You aren’t “adding” pixels on the screen. The first screenshot has the margin of the inner <p> drawn outside the light grey container because it has been collapsed into the next element on the page. Forcing a padding at the bottom of the grey container prevents the two margins from being collapsed into one. Yes, this is incredibly dumb, but that shouldn’t really come as a surprise, since, well, it’s CSS, land of “form element behaviour is undefined”, “positioning behaviour inside table cells is undefined”, and “variables are harmful” (from one of the designers of CSS!). Though it won’t help you here, WebKit has some proprietary CSS properties to control whether or not margins are allowed to collapse. Incidentally, if you have ever seen a Web page where something animates, and then at the end of the animation the content “pops” into place, that ugliness is margin collapsing in action. Here’s more reading about it, including these ironic sentences: “Why is this? Because it's what authors would tend to expect.” Enjoy.
-
@pjt33 said:
@blakeyrat said:
Do you have something to back up this claim, or is it just more elitist propaganda?3) The overflow: hidden option is documented (by W3Schools at least)
Using W3Schools as a reference for anything makes you TRWTF. There are various non-WTF reference sites for HTML and CSS: the one I use is http://www.htmldog.com/reference/
-
@Sutherlands said:
@pjt33 said:
It’s bad enough that a huge cabal of front-end developers created http://w3fools.com to warn people away from it around this time last year. They’ve improved, somewhat, but the quality of the information on the site is still not very good.@blakeyrat said:
Do you have something to back up this claim, or is it just more elitist propaganda?3) The overflow: hidden option is documented (by W3Schools at least)
Using W3Schools as a reference for anything makes you TRWTF. There are various non-WTF reference sites for HTML and CSS: the one I use is http://www.htmldog.com/reference/
-
@snover said:
“variables are harmful” (from one of the designers of CSS!).
This site is trwtf. I actually wanted to use elinks to read that shit.
-
It's called "margin collapse". It's useful if you actually know what you're doing. Google it.
-
This is why I really like being a command line infrastructure dev. FOOK YOU GUI.
-
If anyone's actually curious about the CSS3 multi-column module, there's more information at A List Apart (as always). It sounds like only Firefox has a native implementation of it, but that writeup also includes a good cross-browser JavaScript implementation.
-
-
Read it before. ("Long time reader, first time poster.") The main contribution I was trying to make there was the cross-browser JavaScript implementation I've found quite useful, but meh.
-
@blakeyrat said:
Besides which, it doesn't fucking matter because I live here in this place called the "real world" where my webpage is viewed by real people using browsers like, say, IE8, IE9 and Chrome. If it doesn't work in those browser, it doesn't fucking matter whether it doesn't work because the browser is broken or because the spec is broken, the end result is it's broken.
So you're wrong, and your argument is fundamentally flawed. Congratulations.
Just a quick question (although I can guess your answer if you even bother making one) but have you actually tried to make any suggesting to the WHAT Working Group? I follow the mails that come out of there, and I get involved in the discussions about different specs, and a lot of other people do too. If you haven't even made a single effort at getting anything changed, then what bloody right do you have to complain? So what you can't understand CSS? So what if it's part of your job? So what if you basically can't understand what thousands of others get. It's not the spec writers fault that you're too stupid to understand (sorry, but after 5 years of using CSS, if you still don't get simple things like padding and margin and have to whine here when things don't work for you, then you're stupid) but yours for being an imbecile.
-
@dhromed said:
CSS3 can format text as columns in an element.
Didn't know that. Then again, don't do enough web dev to keep up to date with these standards.
@heterodox said:
If anyone's actually curious about the CSS3 multi-column module, there's more information at A List Apart (as always).
Oh, deffo. Ta for that, will have a play later to try some of those examples out.
-
@blakeyrat said:
it doesn't fucking matter whether it doesn't work because the browser is broken or because the spec is broken, the end result is it's broken.
That's just nuts. Yes, CSS is a huge complicated, convoluted mess. But not everything is the fault of a shitty, overly complicated spec.@blakeyrat said:
1) Making a 1-pixel change to the .css file doesn't result in a 1-pixel change to the page.
How is that the fault of the CSS spec and not the fault of the browser? Please explain. Go ahead. I'll wait. . . . . . .@blakeyrat said:
3) The overflow: hidden option is documented (by W3Schools at least) as so: "The overflow is clipped, and the rest of the content will be invisible" WHAT THE FUCK does that have to do with the behavior I'm seeing on the screen when I set it? The overflow isn't "clipped", it actually extends further than it did without overflow: hidden set.
So you just gave an example of the browser not doing what the documented spec says it should do. And this is the fault of the spec and not the browser .... how exactly?
