Quick! Someone explain to me how CSS is awesome and great and The Real WTF is me!

blakeyrat

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?

No. It would be a waste of my time. If you paid me a salary to deal with this shit, I'd deal with it. There's no way I'm going to volunteer my time to help someone else do their fucking job.

@ASheridan said:

If you haven't even made a single effort at getting anything changed, then what bloody right do you have to complain?

I'm an American. We have this thing here called "Freedom of Speech". I actually have the right to say whatever the fuck I want to.

@ASheridan said:

So what if you basically can't understand what thousands of others get.

The vast majority of CSS coders are doing the same "guess-and-check-and-why-the-fuck-did-that-happen" that I am. I don't deny that there are some people that "get it", but those people are very, very few and far-between.

@ASheridan said:

It's not the spec writers fault that you're too stupid to understand but yours for being an imbecile.

You've read these forums for awhile. Do you honestly believe I'm stupid?

@ASheridan said:

(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)

I thought I did get padding and margin and then, bam, look at that mysterious space go away when I add some padding for absolutely no reason whatsoever! As it turns out, what I didn't understand was the side-effect that adding padding to an element also turns on overflow: hidden, without me actually putting overflow: hidden in the stylesheet. Now suddenly I'm distinctly aware that I knew far less about CSS than I thought I did.

Did you understand the relationship between adding 1 pixel of padding and setting overflow: hidden before reading this thread? Are you capable of writing CSS without just doing "guess-and-check?" Then I guess you're smarter than me. Congratulations, you win a no-prize.

Soviut

@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!

That's stupid. Just set the width and the height of your div. Once you've set those, the box will remain that size no matter how much content you put in it. You'll eventually run into overflow issues, since the content exceeds the size of the box. So set overflow to hidden if you want to hide the overflow, scroll if you want to display a scrollbar, etc.

CSS has a few simple rules to follow. Once you know how they work, it should all make sense. But I get the impression most people complaining about CSS haven't taken the time to actually learn it.

I highly recommend the NetTuts: CSS Noob to Ninja video tutorials for beginners. I think it requires a premium subscription (9 bucks) but it's more than worth it.

ASheridan

@blakeyrat said:

There's no way I'm going to volunteer my time to help someone else do their fucking job.

It's not volunteering to do someone elses job. As people have pointed out to you, the problem is mostly you and browsers, not the spec. The browser developers happen to be on those mailing lists as well. All your childish whining is going to do is make people think you're a bit of a tit, it's not going to solve your problem, so you'll only end up whining about it another day. Congratulations, you win the award for being a stupid dumbass.

@blakeyrat said:

I'm an American. We have this thing here called "Freedom of Speech". I actually have the right to say whatever the fuck I want to.

And we have the right to mock you for being an idiot, as generally happens.

@blakeyrat said:

The vast majority of CSS coders are doing the same "guess-and-check-and-why-the-fuck-did-that-happen" that I am. I don't deny that there are some people that "get it", but those people are very, very few and far-between.

Really? Care to back that up with evidence, even a fact or two? I work as a web developer, and I know plenty of other people who do the same thing, and they "get it", and don't seem to be few and far between.

@blakeyrat said:

You've read these forums for awhile. Do you honestly believe I'm stupid?

Short answer: yes. Long answer: yes, pretty dumb and pigheaded.

@blakeyrat said:

Did you understand the relationship between adding 1 pixel of padding and setting overflow: hidden before reading this thread?

I think you're still not getting it. As snover mentioned:

@snover said:

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 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.

Where in there is anything about overflow? He mentions quite specifically what your fucking problem was, but you choose to ignore it, make up your own reasons, and then whine some more about how the world is out to get you.

boog

I haven't commented on this discussion yet because I wanted to see what others had to say first. Glad to see you've started quite the flame war here, blakerino. Kudos!

Now that I'm out of popcorn, I'll chime in:

@blakeyrat said:

Someone explain to me how CSS is awesome and great...

Lots of people are able to do really awesome and great things with CSS. No doubt you've seen this: [url]http://www.csszengarden.com[/url]

@blakeyrat said:

...and The Real WTF is me!

Actually, you're not TRWTF it seems. As far as I can tell, it's an issue with CSS (in all browsers that I tested). That said, I've never encountered this behavior in my own work, and it appears that CSS is incredibly useful in spite of it.

Still, good find!

AndyCanfield

@Soviut said:

That's stupid. Just set the width and the height of your div. Once you've set those, the box will remain that size no matter how much content you put in it.

Having followed this dicsussion, and doing more tests, I find now that width and height work pretty much "the way they ought to". Near as I can tell, a year ago, Firefox did not treat them this way.

This brings up the point that, for many of us, the definition of a term is nothing more or less than what the browser does when faced with that term. When I use CSS, I read the w3c site and code something and feed it into Firefox. If it comes out, great, I'll go with that. If it messes up, I don't know, or much care, wether it is a weird spec or a weird implementation.

One could argue that the specs should be clear and obvious enough that competant programmers like the Firefox team can implement them without too much head scratching. Don't say X means Y and then, two pages later, say "sometimes X means Y+3".

Decades ago a reliable program was defined as a program which does what a reasonable person expects it to do. Not "look in the specs", but "what does a reasonable person expect the behavior to be?" Reasonable people expect that a zero pixels border will act exactly like a one pixel border, except for display thickness.

ASheridan

@AndyCanfield said:

Decades ago a reliable program was defined as a program which does what a reasonable person expects it to do. Not "look in the specs", but "what does a reasonable person expect the behavior to be?" Reasonable people expect that a zero pixels border will act exactly like a one pixel border, except for display thickness.

But reasonable people want paragraphs to work the way they do, and rely on that. Each paragraph has top and bottom margins, and those collapse into each other under normal circumstances, unless you do something which triggers them to separate. If you suddenly change the CSS spec to collapse all margins regardless, exept for this one case with paragrahs, just because, then where would we be?

Cassidy

@AndyCanfield said:

Having followed this dicsussion, and doing more tests, I find now that width and height work pretty much "the way they ought to". Near as I can tell, a year ago, Firefox did not treat them this way.

There always seems to be a bit of lag or turbulence between specs and browsers which gradually get ironed out as newer versions of browser are released. It's this behaviour that caused me to resent IE6 so much.

@AndyCanfield said:

Decades ago a reliable program was defined as a program which does what a reasonable person expects it to do. Not "look in the specs", but "what does a reasonable person expect the behavior to be?"

I'd argue it's the other way (or may it's the other way today) - several reasonable people with different viewpoints may have varying expectations so may not all agree on a common ground. The specs define what the program should be doing, and correctness is usually measured in terms of closeness to the specifications - irrespective of how those specifications differ from the original program request or what artistic licence a developer has decided to impose during design and realisation.

At least the specs are a single documented viewpoint which developers should be aspiring to, and if they are unreasonable[1] then they should be reviewed and amended, rather than expecting reason to be added during implementation.

[1] obligatory humours link: Clients From Hell

AndyCanfield

I wish to point out the wonderfulness of the ACID tests. There, somebody who was involved with the specs created, (in theory?) a rendering engine which implemented those specs as intended, and then could compare the test results against whatever browser you are running. That is a vast improvement on specs alone. The standard rendering system that ACID compares your browser against may be 4 Gigabytes interpreted APL code and take four hours to render each screen, but it gives browser developers a reference to compare against. "Did we understand that correctly? Did we forget something on page 17? Run the ACID test and see!" Very good idea.

I also create web pages and, once they are working, run them through the w3c validator. I find typographical errors that Firefox allows but which are WRONG. The browser is designed to be forgifing, the validator is designed to be crabby, and it's wonderful. Sort of an automated code review. Yesterday I had to adjust a lot of code because company names like "Smith & Jones" came out of Firefox OK but made the validator barf. I also learned that something like:

<input name='CO' type='text' value='Smith & Jones' />

is invalid even though it's in quotes, but

<input name='CO' type='text' value='Smith &amp; Jones' />

is valid, displayed correctly, and, amazingly, passed on to the next web page as "Smith & Jones" even though that's not what is in the value field.

Experimenting withthe validator is possible and fruitful; experimenting with a spec is painful and useless.

Cassidy

@AndyCanfield said:

I also learned that something like:
<input name='CO' type='text' value='Smith & Jones' />
is invalid even though it's in quotes, but
<input name='CO' type='text' value='Smith &amp; Jones' />
is valid, displayed correctly, and, amazingly, passed on to the next web page as "Smith & Jones" even though that's not what is in the value field.

Presumably because it's an input field, and the free-text input you've specified will be passed as part of a GET string (or POST values) and be escaped into web-safe syntax. I'm no expert, but I can see the sense in pre-escaping vales that will become exposed out of their quotes and thus require translating into their web-safe equivalents.

@AndyCanfield said:

Experimenting with the validator is possible and fruitful; experimenting with a spec is painful and useless.

Isn't that the point? You don't experiment with the spec; the W3C defined the specs to establish a standard so that browser vendors know what code to expect and how to deal with it. The validator you're using simply checks conformance to the spec, saving you the hassle of reading and trying to interpret their standards to check adherence of your own code. An appreciation of what the specs are and understanding their importance is enough - no need for experimentation.

dhromed

@El_Heffe said:

you just gave an example of the browser not doing what the documented spec says it should do

Er, the browser did exactly what the spec says.

dhromed

@AndyCanfield said:

Near as I can tell, a year ago, Firefox did not treat them this way.

This is false.

dhromed

@snover said:

CSS big post

This is cool.

dhromed

@blakeyrat said:

As it turns out, what I didn't understand was the side-effect that adding padding to an element also turns on overflow: hidden, without me actually putting overflow: hidden in the stylesheet.

That is not what's happening.

dhromed

@AndyCanfield said:

amazingly, passed on to the next web page as "Smith & Jones" even though that's not what is in the value field.

Not sure if sarcastic.

pjt33

@AndyCanfield said:

Having followed this dicsussion, and doing more tests, I find now that width and height work pretty much "the way they ought to". Near as I can tell, a year ago, Firefox did not treat them this way.

Are you sure? ISTR that FF 3.0 handled it fine.

@ASheridan said:

@AndyCanfield said:
Decades ago a reliable program was defined as a program which does what a reasonable person expects it to do. Not "look in the specs", but "what does a reasonable person expect the behavior to be?" Reasonable people expect that a zero pixels border will act exactly like a one pixel border, except for display thickness.
But reasonable people want paragraphs to work the way they do, and rely on that. Each paragraph has top and bottom margins, and those collapse into each other under normal circumstances, unless you do something which triggers them to separate. If you suddenly change the CSS spec to collapse all margins regardless, exept for this one case with paragrahs, just because, then where would we be?

Borders have more properties than just width. It doesn't seem unreasonable to me to expect that { border-style: none } would allow margin collapse and { border-style: solid; border-width: 0 } would create a barrier preventing margin collapse. (Not that I'm advocating such a change to the spec - it's far too late now).

pjt33

@dhromed said:

@blakeyrat said:
As it turns out, what I didn't understand was the side-effect that adding padding to an element also turns on overflow: hidden, without me actually putting overflow: hidden in the stylesheet.

That is not what's happening.

Do you think he'll ever notice where his 8 pixels went?

dhromed

@pjt33 said:

Do you think he'll ever notice where his 8 pixels went?

I have them right here.

muahahaha

blakeyrat

@pjt33 said:

Do you think he'll ever notice where his 8 pixels went?

The site looks ok now so I no longer give a fuck.

dhromed

So... it's okay if I keep the pixels?

Watson1

@Cassidy said:

@AndyCanfield said:
I also learned that something like:
<input name='CO' type='text' value='Smith & Jones' />
is invalid even though it's in quotes, but
<input name='CO' type='text' value='Smith &amp; Jones' />
is valid, displayed correctly, and, amazingly, passed on to the next web page as "Smith & Jones" even though that's not what is in the value field.
Presumably because it's an input field, and the free-text input you've specified will be passed as part of a GET string (or POST values) and be escaped into web-safe syntax. I'm no expert, but I can see the sense in pre-escaping vales that will become exposed out of their quotes and thus require translating into their web-safe equivalents.

It's simpler than that; it's because (as the spec goes to great lengths to state over and over again) ampersands need to be escaped except under certain conditions (of which attribute values are not one).

Sure, working with the spec alone is painful and useless - especially when you don't actually read it.

AndyCanfield

@dhromed said:

@AndyCanfield said:
amazingly, passed on to the next web page as "Smith & Jones" even though that's not what is in the value field.
Not sure if sarcastic.

Not sarcastic (I don't do sarcasm). I could understand that "Smith & Jones" has to be morphed as "Smith & Jones" when it's embedded in HTML. Upon display the browser Un-morphs the "&" to display it as "&". What surprised me was that the POST transmission send me the un-morphed displayed version, not the actual string that was sent to the browser.

Since I made that post I seem to have run into another quirk. Friday night I validated my pages against 4.01 HTML Transitional, and it complained every time it saw a not-morphed "&" (as in "A&P"). Saturday night I validated against 1.0 XHMTL Transitional, and a few not-morphed "&"s cropped up and it did not complain about them. Had a vew other things to fix, but as per the "&", 1.0 XHTML Transitional seems less crabby than 4.01 HTML Transitional. (FYI the biggest problems were <meta> and <link> tags, which 4.01 HTML Transitional refuses to let you close, but 1.0 XHTML Transitional insists that you close.)

Daniel_Beardsmore

@AndyCanfield said:

I could understand that "Smith & Jones" has to be morphed as "Smith & Jones" when it's embedded in HTML. Upon display the browser Un-morphs the "&" to display it as "&".

A long time ago, the typewriter was invented. For obvious reasons, there were suddenly a lot of characters that were no longer usable. We're still struggling to dig ourselves out of that hole.

HTML entities are a way to use, on a web page, characters that a) cannot be typed on even a modern keyboard, and b) may be corrupted by confusion over character encodings (a page on ESR's site earlier was being misinterpreted by Firefox as Latin-1 despite clearly stating it was UTF-8, and characters were getting mangled, so we're still not there yet).

So, you can have you real minus sign (same width as +): − gives −; typographer's double quotation marks “ and ” give “ and ”; á = á and so forth. (I can type all these directly via my keyboard, but most people cannot, and there are far more characters than I have any need or desire to configure my PC to be able to enter. Note that there are also methods for entering Unicode code points directly as hex.)

Since & is now a reserved character, it has to be escaped, and instead of using \&, it has its own entity: &. The trailing semicolon is optional: entities terminate on (I think, you may want to check) any whitespace character, which is part of HTML's general tendency to sacrifice sanity for saving bytes, which makes it as big a WTF as CSS, just for different reasons. A&P could then mean A&P; for the nonexistent entity &P;, so you need to escape literal ampersands to produce unambiguous code. The use of & in URL query strings was a big mistake; ";" is the preferred alternative, but browsers use "&" when generating query strings, to be safe, as not all sites and libraries accept ";".

One other key need is escaping double quotation marks within attribute values, using ". For example, this attribute title="Joe "Q" User" is not going to work very well. Entities allow you to resolve this: title=Joe "Q" User". This is why HTML escaping routines will always convert " to " regardless of where it's being used.

None of this "morphing" has any bearing on POST or GET. POST and GET are encoded completely differently, typically using the URL encoding scheme with its %nn codes. The purposes of entities are to allow entry of characters that are difficult or impossible to type or that live outside the character set you're working in (for example typographer's quotes are in fact illegal in ISO Latin 1, unlike MacRoman and Windows Latin-1), and to escape quotation marks in attribute values. When a form is posted, you're not sending HTML, after all.

This is all basic HTML … rather worrying if people don't get it.

AndyCanfield

You know, this discussion clash between specs and browser implemenation reminds me of the situation in computerized versions of standard games.

For example, in Canfield Solitaire, the tableau is where you work, and the foundation is where the cards will end up. Can you legally take a card off the foundation and move it back to the tableau? Some programs let you do that, some do not, and it turns out to be critical in getting out of certain deadlocks. So I bought a physical paperback copy of Hoyle's rules of games, and read up on it. Hoyle does not say whether it is legal or not! Perhaps when the rules were written the game was young enough that nobody had thought of it.

The only rational solution is to say that the rules for the game are the rules programmed in to the software you are using. Anything the software lets you do is a legal move; anything the software prevents is not. The rules for Microsoft Freecell (which insists on autodrop) are not exactly the same as the rules for Linux KPatience Freecell (which allows you to turn off autodrop). The name of the software game is like advertising; close, but take it with a grain of salt.

(I once had a version of Klondike for MS-DOS that allowed you to cheat.)

Again, it is similar to language specs. The C language may have wonderful specs, but nobody has read them. K&R's book is the closest most people ever came to the specs. But, ultimately, the language is defined by whatever the C compiler accepts and compiles correctly. For example all C compilers that I ever used accepted comments in the C++ style, even though that's not in the specs of C.

I'll throw in another comment about ACID tests and validators. In any specification, there are ambiguities. You have a hundred minds writing them, and ten thousand minds poking holes in them. In the legal system that's the difference between legislators and lawyers. That's why we have courts; to decide the ambiguities. Well the ACID tests and validators are like courts; some place you can go to to see what the specs are supposed to mean. ACID tests are for the benefit of the people developing browsers; validators are for the benefit of people developing web pages.

pjt33

@blakeyrat said:

The site looks ok now so I no longer give a fuck.

If this is your attitude to learning, it's no wonder that you don't have a handle on CSS2 after 5 years of using it.

Watson1

@AndyCanfield said:

What surprised me was that the POST transmission send me the un-morphed displayed version, not the actual string that was sent to the browser.

You mean you were surprised that the parser parsed the escape sequence as an escape sequence?

AndyCanfield

@Watson said:

@AndyCanfield said:
What surprised me was that the POST transmission send me the un-morphed displayed version, not the actual string that was sent to the browser.
You mean you were surprised that the parser parsed the escape sequence as an escape sequence?

Of course the parser in the browser parsed the escape sequence as an escape sequence for the purpose of displaying it on the screen. What surprised me is that it passed on to the POST handler what was displayed rather than the internal form that it had to parse.

I guess, though, it has to be that way. Suppose my web page sends:

<input type='text' name='gru' value='Marks and Spencer' />

and the user replaces "Marks and Spencer" with "Marks & Spencer". Of course I would want the display to match the typing, and what is transmitted to the server should match the typing and the display, regardless of what morphing may be necessary in the HTML transmission.

Cassidy

@AndyCanfield said:

But, ultimately, the programmer writes code according to whatever the C compiler accepts and compiles correctly.

FTFY, and I think it's true of all compilers. Some have a few quirks which shapes the way in which coders would use them - which means those individuals may become unstuck when moving to a different compiler. There have been documented cases where some spec-compliant code is treated differently amongst varying compilers (I don't have any to hand, it was an article I read years ago).

@AndyCanfield said:

What surprised me was that the POST transmission send me the un-morphed displayed version, not the actual string that was sent to the browser.

I don't think it was the POST transmission, more what happened at the receiving end - an escaped sequence was correctly interpreted as web-safe characters, then unescaped into their original counterparts. Did you view the POST transmission using packet sniffing techniques or did you use some server-side method to display the POST variables?

@AndyCanfield said:

(FYI the biggest problems were <meta> and <link> tags, which 4.01 HTML Transitional refuses to let you close, but 1.0 XHTML Transitional insists that you close.)

Because XHTML insists on well-formedness (like XML), so every open tag must be closed and nested correctly. HTML's DTD doesn't contain a reference to close these tags (nor <hr>, or <img>) so adding closing tags will cause validation errors.

I learned that from reading the specs, oddly enough. I didn't experiment with them, just familiarised myself with some of the differences between XHTML and HTML.

@AndyCanfield said:

and what is transmitted to the server should match the typing and the display, regardless of what morphing may be necessary in the HTML transmission

No, you're missing the point again. What's transmitted to the server should be interpreted as the typing and display. It is (morphed|escaped|made web-safe) so that what is transmitted is not mis-interpreted at the receiving end. The actual transmission is not important, provided the receiving end gets the correct results eventually, and all of this pre-mangling takes place to prevent mangling during transmission.

(or you could argue that it will get mangled during transmission, so techniques to "unmangle" at source prior to transmission means we're assured it'll be correct when it arrives.)

AndyCanfield

@Cassidy said:

@AndyCanfield said:
What surprised me was that the POST transmission send me the un-morphed displayed version, not the actual string that was sent to the browser.
I don't think it was the POST transmission, more what happened at the receiving end - an escaped sequence was correctly interpreted as web-safe characters, then unescaped into their original counterparts. Did you view the POST transmission using packet sniffing techniques or did you use some server-side method to display the POST variables?

My web pages are coming from PHP, and I just dumped the PHP $_REQUEST array.

@Cassidy said:

@AndyCanfield said:
(FYI the biggest problems were <meta> and <link> tags, which 4.01 HTML Transitional refuses to let you close, but 1.0 XHTML Transitional insists that you close.)
Because XHTML insists on well-formedness (like XML), so every open tag must be closed and nested correctly. HTML's DTD doesn't contain a reference to close these tags (nor <hr>, or <img>) so adding closing tags will cause validation errors.
I learned that from reading the specs, oddly enough. I didn't experiment with them, just familiarised myself with some of the differences between XHTML and HTML.

On the other hand, I have been coding and <hr /> and <img ... /> for years and no validator has ever complained about it. The 4.01 HTML Transitional validator issued a yellow warning about <meta ../> but a red error for <link ... />.

@Cassidy said:

@AndyCanfield said:
and what is transmitted to the server should match the typing and the display, regardless of what morphing may be necessary in the HTML transmission
No, you're missing the point again. What's transmitted to the server should be interpreted as the typing and display. It is (morphed|escaped|made web-safe) so that what is transmitted is not mis-interpreted at the receiving end. The actual transmission is not important, provided the receiving end gets the correct results eventually, and all of this pre-mangling takes place to prevent mangling during transmission.
(or you could argue that it will get mangled during transmission, so techniques to "unmangle" at source prior to transmission means we're assured it'll be correct when it arrives.)

IMHO you used big words to say what I said. Thank you.

By the way, does anybody know why the tag is banned, but the and are still allowed? I see that this forum entry box allows B and I and U and the HTML button shows that these are implemented using the and and depreciated tags.

The whole premise of HTML is flawed in the first place. The premise is that the transmission from the server to the browser describes the content of the web page, and the browser decides how to display it. That's why there is a standard for but there is no standard for what the means in terms of margins. But management wants the page to look like thus-and-so, and so the developer, caught in the middle, has been fighting HTML for 20 years to force the browser to display it in one particular way. That's why we shouldn't use ; because when the boss wants it bold he must get bold, regardless of how the browser developer thinks should look.

@AndyCanfield said:

For example all C compilers that I ever used accepted comments in the C++ style, even though that's not in the specs of C.

It is now!

@AndyCanfield said:

On the other hand, I have been coding and <hr /> and <img ... /> for years and no validator has ever complained about it.

That's because [i]is[/i] valid in HTML — except it means > and not as it does in XHTML.

Cassidy

@AndyCanfield said:

My web pages are coming from PHP, and I just dumped the PHP $_REQUEST array.

Presumably within a CDATA or set of <pre> tags so prevent the browser from re-mangling? Also... I recall there's a php.ini setting that automatically does output escaping, I think.

(just wondered if they were interfering with the display in some way).

@AndyCanfield said:

IMHO you used big words to say what I said. Thank you.

I did? Or rather, you did? okay, it didn't seem that way, but ... errm.. thanks, I guess.

@AndyCanfield said:

By the way, does anybody know why the tag is banned, but the and are still allowed? I see that this forum entry box allows B and I and U and the HTML button shows that these are implemented using the and and depreciated tags.

I think that's outdated TinyMCE. Bold and italics should be deprecated now (but underline is okay). It possibly stems from the fact that TinyMCE based a lot of its functionality upon BB markup, using [b] and [i] to add styling tags in. Still odd it's never been updated (unless it has in a version of TinyMCE that's newer than the one used on this site)

@AndyCanfield said:

The whole premise of HTML is flawed in the first place. The premise is that the transmission from the server to the browser describes the content of the web page, and the browser decides how to display it. That's why there is a standard for but there is no standard for what the means in terms of margins.

That's not really a flawed concept - back in the HTML3 days, simply meant it was a paragraph and would be treated as such (or mistreated across different browsers). HTML4 relies upon CSS to style and position the paragraph(s) in a desired way - the HTML is really just used to identify specific regions.

@AndyCanfield said:

That's why we shouldn't use ; because when the boss wants it bold he must get bold, regardless of how the browser developer thinks should look.

No, we should use , then ensure that "strong { font-weight: bold }" is explicitly specified in the CSS so that the boss gets bold. If the boss decides that it's not bold enough, the developer can then decide to add further effects to the style, such as such as darken the colour tone or increase the type size. Strong and emphasize are style groups; bold and italics are style components.

AndyCanfield

@Cassidy said:

@AndyCanfield said:
My web pages are coming from PHP, and I just dumped the PHP $_REQUEST array.
Presumably within a CDATA or set of <pre> tags so prevent the browser from re-mangling? Also... I recall there's a php.ini setting that automatically does output escaping, I think.

Nope. My PHP generates the HTML directly; no CDATA or <pre> involved.

@Cassidy said:

@AndyCanfield said:
By the way, does anybody know why the tag is banned, but the and are still allowed? I see that this forum entry box allows B and I and U and the HTML button shows that these are implemented using the and and depreciated tags.
I think that's outdated TinyMCE. Bold and italics should be deprecated now (but underline is okay). It possibly stems from the fact that TinyMCE based a lot of its functionality upon BB markup, using [b] and [i] to add styling tags in. Still odd it's never been updated (unless it has in a version of TinyMCE that's newer than the one used on this site)

I'm pretty sure it is not TinyMCE. Look at http://www.w3schools.com/tags/default.asp - and are not depreciated but is.

@Cassidy said:

@AndyCanfield said:
The whole premise of HTML is flawed in the first place. The premise is that the transmission from the server to the browser describes the content of the web page, and the browser decides how to display it. That's why there is a standard for but there is no standard for what the means in terms of margins.
That's not really a flawed concept - back in the HTML3 days, simply meant it was a paragraph and would be treated as such (or mistreated across different browsers). HTML4 relies upon CSS to style and position the paragraph(s) in a desired way - the HTML is really just used to identify specific regions.

Yeah, but what does "paragraph" mean, in terms of what appears on the screen? NOTHING. Whatever the browser writer chose to make it. Even today, AFAIK, unless you give more specification using CSS, your tags in HTML mean "give me a paragraph, whatever that means to the hippie who wrote the browser."

@Cassidy said:

@AndyCanfield said:
That's why we shouldn't use ; because when the boss wants it bold he must get bold, regardless of how the browser developer thinks should look.
No, we should use , then ensure that "strong { font-weight: bold }" is explicitly specified in the CSS so that the boss gets bold. If the boss decides that it's not bold enough, the developer can then decide to add further effects to the style, such as such as darken the colour tone or increase the type size. Strong and emphasize are style groups; bold and italics are style components.

You're using an HTML tag which is deliberately undefined () and using CSS to define it. You could just as well use an HTML tag which is defined () to mean BOLD and use CSS to "add further effects to the ... style, such as darken the color tone or increase the type size." Af far as the HTML standard it concerned, a browser could display text as "upside down in flashing pink with floating bubbles".

AndyCanfield

@Spectre said:

@AndyCanfield said:
On the other hand, I have been coding and <hr /> and <img ... /> for years and no validator has ever complained about it.

That's because is valid in HTML — except it means > and not as it does in XHTML.

But ALPHA BETA displays as

ALPHA
BETA

whereas ALPHA >BETA displays as

ALPHA
>BETA

(I edited the HTML in this post itself.) They have never been the same. Not only has no validator ever complained about but I have never gotten an extra ">" on the next line because of it. So what do you think > means?

Daniel_Beardsmore

BTW, here's a nice escaping problem in PHP 5. rawurlencode("A&B") gives "A%26B". When PHP receives back "?foo=A%26B", it stupidly mistakes this for "?foo=A&B", so everything after & is lost and $_GET['foo'] == 'A'.

~~Add this to the confusion over whether space should be encoded as "%20" or "+" …~~

Oops. I was sure something wasn't right there ... grr, mod_rewrite is decoding it for me beforehand, which that's a nuisance ...

Daniel_Beardsmore

Argh ... the post timeout actually occurred between clicking Edit and adding a note that the stupid forum understands <strike> but not <del> (which I always forget). Surely clicking Edit should temporarily lock the edit window open a bit longer, so that you don't type into a ticking bomb? Sorry, I forgot, nothing in CS actually works in a logical manner.

Cassidy

@AndyCanfield said:

Nope. My PHP generates the HTML directly; no CDATA or <pre> involved.

That was my point - is the actual content & but the browser is rendering it as "&" and your thinking "hey, it's printing & all by itself without any escape codes!"...? Just don't want you confusing results with success.

@Cassidy said:

I'm pretty sure it is not TinyMCE. Look at http://www.w3schools.com/tags/default.asp - and are not depreciated but is.

I'm not a fan of w3schools (I found much of their content outdated and IE-centric at one time, so didn't rely upon their accuracy) however... weird - I thought it was the other way around. Consulting the W3C specs, it seems you're right, although other sources would suggest that is deprecated also.

@AndyCanfield said:

Yeah, but what does "paragraph" mean, in terms of what appears on the screen? NOTHING. Whatever the browser writer chose to make it. Even today, AFAIK, unless you give more specification using CSS, your tags in HTML mean "give me a paragraph, whatever that means to the hippie who wrote the browser."

And <div> and , etc. Tags simply enclose regions, marking up that content with context; without any styling information, the browser doesn't know how they should be displayed (other than in blocks for block-level tags). I don't disagree with you, I'm just pointing out that shouldn't mean "this paragraph should be displayed half an inch intended from the left and spaced by 150% of line-height"- that's the job of CSS.

One of the design considerations of HTML4.01 was the separation of content from style; HTML was left to be something that stuck labels on content and CSS was the fellah that came long with a paintbox and did the "paint by numbers" job, according to his CSS list. For that reason, many of the deprecated tags and attributes tend to be style-specific stuff, the idea being it could all be consolidated into CSS files.

@AndyCanfield said:

You're using an HTML tag which is deliberately undefined () and using CSS to define it.

Erm.. not quite. AFAIK, is defined as "font-weight: bold" by default, in the same way that <h1> seems to have "font-size: 200%; font-weight: bold; text-align: left" by default, and all body text begins with "color: black". Although I will concede that browsers are inconsistent with their "background-color" value for <body>...

@AndyCanfield said:

You could just as well use an HTML tag which is defined () to mean BOLD and use CSS to "add further effects to the ... style, such as darken the color tone or increase the type size." Af far as the HTML standard it concerned, a browser could display text as "upside down in flashing pink with floating bubbles".

I feel the point of is that it's a style class/group, rather than a style element/component[1]. I've come across someone who took and defined it in CSS to be italicised, underlined and a different colour to body text. Granted he was a fuckwit, but he just saw as another tag to be styled and never thought of its semantic meaning.

[1] yes, I know this argument fails when is being discussed, although it seems that it IS (or due to be) deprecated now.

ASheridan

Are you sure? How are you passing that URL back?

If you echo out 'A%26B' as a form field value, it won't be interpreted by the browser because it's URL escaped and not HTML escaped. It should then pass straight through to the server script without problems. I've just made a basic test to prove this myself (just in-case I was wrong) but everything works as expected, so I think you've got some confusion as to what needs to be encoded in what format and where.

Spaces should be %20, but most browsers will also accept the plus symbol as a space character. The browser still sends the correct character sequence to the server no matter which of the two you use, so the server will always see a space.

@AndyCanfield said:

But ALPHA BETA displays as

ALPHA
BETA

whereas ALPHA >BETA displays as

ALPHA
>BETA

That's because browsers suck. In a fully compliant browser they would be identical.

Daniel_Beardsmore

@AndyCanfield said:

But ALPHA BETA displays as

ALPHA
BETA

whereas ALPHA >BETA displays as

ALPHA
>BETA

This forum is XHTML, where is in fact correct. Regardless, browsers tend to fix errors for you. Which I vehemently disagree with.

@Spectre said:

That's because browsers suck. In a fully compliant browser they would be identical.

You were the one arguing that they mean different things (which comes from the basis that HTML is an SGML application with all the attendant memory-saving garbage such as the Null End Tags ("NET tags" to the W3C) in question here, for those wondering).

Watson1

@AndyCanfield said:

@Watson said:
@AndyCanfield said:
What surprised me was that the POST transmission send me the un-morphed displayed version, not the actual string that was sent to the browser.
You mean you were surprised that the parser parsed the escape sequence as an escape sequence?
Of course the parser in the browser parsed the escape sequence as an escape sequence for the purpose of displaying it on the screen. What surprised me is that it passed on to the POST handler what was displayed rather than the internal form that it had to parse.

No, the parser in the browser parsed the escape sequence as an escape sequence for the purposes of representing an ampersand in the attribute's value in the file. You're confusing the source code with the internal representation of the document.

<html><form>

<input type='text' id='gru' value='Marks &amp; Spencer' />

</form>

<script type='text/javascript'>

document.write(document.getElementById('gru').value.length);

</script>

The length of the string is 15, not 19.

Really, it's no stranger than the idea that the backslash in [code]echo 'O\'reilly';[/code] isn't part of the parsed string.

dhromed

@AndyCanfield said:

Whatever the browser writer chose to make it. Even today, AFAIK, unless you give more specification using CSS, your tags in HTML mean "give me a paragraph, whatever that means to the hippie who wrote the browser."

This is a correct assessment of the situation.

bridget99

CSS is TWTFOAWTF (the WTF of all WTFs). Containment is supposed to be a good metaphor for styling; what human being with normal intracranial pressure could possibly believe this?

"Herp derp derp. I am red because I'm surrounded by a red border! Herp derp derp. Let me just put my brick shirt and pants on, since I'm in a brick house."

Oh, except certain attributes don't "cascade" downward like this. Because, you know, it's not appropriate behavior for some things. That is, for all things. So, only some things are broken: the parts of "Cascading Style Sheets" that actually cascade.

The whole exercise is a joke of the highest order. TD/TR were perfect from a development standpoint: easy-to-understand repetitive constructs for doing what needs to be done. Compare that to the stupidity over at the "CSS Zen Garden" ("herp derp... after 1,231 tries I got this thing to hover correctly- in your face!") and I dare you to defend CSS. It really is an abomination.

Daniel_Beardsmore

Wow, this is like Trollamatic™ Professional Plus® with Hyperbole Expansion Kit.

Zylon

@Cassidy said:

I feel the point of is that it's a style class/group, rather than a style element/component.

Argh, stop saying that. The correct terminology (or "big words" as Andy would say) is that is a semantic tag, while etc are presentational.

Cassidy

@Zylon said:

Argh, stop saying that.

Sorry, I wanted to refer to them as a collection of style components. Class probably wasn't a good term to use. My bad!

Zylon

@Cassidy said:

Sorry, I wanted to refer to them as a collection of style components. Class probably wasn't a good term to use. My bad!

That wasn't why I argh'd. It was because you're using a dippy made-up taxonomy for HTML tags, thus adding even more confusion to an already-confused thread. Knock it off. etc aren't "style components", they're "semantic markup".

bridget99

@Zylon said:

@Cassidy said:
Sorry, I wanted to refer to them as a collection of style components. Class probably wasn't a good term to use. My bad!
That wasn't why I argh'd. It was because you're using a dippy made-up taxonomy for HTML tags, thus adding even more confusion to an already-confused thread. Knock it off. etc aren't "style components", they're "semantic markup".

The term "semantic markup" was created after-the-fact by CSS weenies, and the fact that you would use this term here points out the biggest problem I have with CSS (other than the fact that it's piss poor from a standpoint of real world productivity): it represents a smug, holier-than-thou attempt to rewrite history such that everything developers have learned is wrong.

When HTML was created, it already exhibited very good systems for separating "semantic content" from "presentation". If I nest a long string of text in "p" tags, it gets wrapped. If I nest the same text in "pre" tags, it does not. I can define tables (presentation) and fill their cells with text (semantic content). Notice how, in each case, the tags define the "presentation" and the text defines the "semantic content".

Eventually, some people decided this wasn't good enough. Ignoring the fact that smarter people than themselves had already decided that HTML as it stood was the best that could be done, these people came up with nine competing standards for what eventually became CSS. About three years later, this group disgorged the architectural abomination that was CSS 1. Almost five years later, a browser came out that actually attempted to translate this screed into a working implementation, begetting an online community of armchair quarterbacks looking for subtle CSS implementation flaws.

How and why the HTML effort was usurped in this way, by people attempting to make hay out of this distinction between "semantic content" and "presentation", is beyond me, except that it proves that 1) "architectural astronauts" (in Joel Spolsky's terminology) will always climb at least one level of abstraction too high and 2) even some very smart people are still susceptible to argument from authority, a classic logical fallacy. ("Semantic content" indeed! I don't think anyone should even feel entitled to use that phrase unless they spend their wee hours programming in GNU Bison. Aren't you ashamed of trying to bully people around with such terms?)

As HTML evolves, I have no problem with adding tags, or even with (gently) codifying behaviors that were previously implementation-dependent. I do have a huge problem with any group of people who jumps into an established community of developers and tries to tell them they're doing it wrong. If you really think that Netscape-era TD/TR is so wrong (and/or that HTML ought really to be XML), then make up your own damned markup language. HTML is (or at least, was) already spoken for.

Finally, the really, really big problem with CSS is that all of the problems it attempts to solve are better handled by a server-side page generator like ASP.NET. The vast majority of HTML that people actually view was rendered dynamically by a program written in a higher-level language like C# or C++. It's not as if we need something extra to do our styling in an abstract and central manner; we've already got C++, C#, and Java, which are much more well-known, powerful, and well-loved than CSS.

Even if CSS made sense in some fantasy world where people edit static HTML pages in Notepad++ or FrontPage (like the CSS Zen Garden), the fact is that we don't live in that world. We live in a world where C++ and C# programs generate HTML. Better to let these programs take care of, say, making all titles red or green based on a single setting than grafting some new standard atop the whole mess. In the real world, this is where the most effective styling systems come from, i.e. from things like ASP.NET "Themes", or simply from some very simplistic string manipulation code of the sort that hasn't provoked flame wars since circa 1960.

CSS is thus an answer to a question no one in his right mind would ask. No one needs a new standard to make sure his C# code (for example) automatically makes every HTML title red. Believe it or not, C# is actually well-equipped for this sort of thing, whether via ASP.NET "Themes" or using very, very simple ad hoc string manipulation techniques.

I've observed a great deal of head-scratching among people who actually try to use CSS, and the level of confusion they exhibit is simply unnecessary. There aren't any subtleties to <var>String.Replace()</var>, or even "stdio.h". This is why developers with real jobs resent being cajoled to use CSS instead.

pjt33

@bridget99 said:

... I don't think anyone should even feel entitled to use that phrase unless they spend their wee hours programming in GNU Bison. ...

Your previous post was a beautiful troll, with just the right level of confusion to tempt people in to correct you. 8/10. But this one has clearly crossed the boundary into insane rambling, and is far less entertaining.

Daniel_Beardsmore

Younger folk probably aren't even aware of just how awful web design was before CSS …

Pim

@Daniel Beardsmore said:

This forum is XHTML, where is in fact correct. Regardless, browsers tend to fix errors for you. Which I vehemently disagree with.

Not true. View Page Info says text/html. The browser doesn't care for the doctype declaration, only the http header is important.