Stupid things that make you want to walk into the w3c with a gun... The irony of it all

lech

Fair warning, what you're about to read might be completely inane. Ok, it's known that the xhtml/css specs are out there to promote accessibility, and to some extent backwards compatibility through xml fallbacks. If I'm wrong, sue me, I'm writing this more out of frustration, so just bear with me for now. So from this standpoint, things are fine, clean source, no font tags raping 50% of your document, simple to manage styles across via one css file for all your documents, ok. So here's my scenario, albeit mildly stupid, it's one of those things which would after a while make you question whether or not these people even know what they're thinking when they write some of these specs. I don't completely blame the folks behind these wonderful specs, but you have to wonder whether any serious consideration was taken when assigning validity to a couple proprietary tags first introduced by IE back in the day. Yes, IE, you read that correctly, hate it as we will, there's some pretty standard stuff which now most browsers treat as ultra-basic for compatibility and overall general offerings. So here's the scenario, I'm cooking up a radio page for a shoutcast server (ok, given I'm already screwing the deaf folks with this one), but I created my style in such a way that some "now playing" titles are way too long, even at 10-12 pt while maintaining clairity on screen at a higher res. Yes, I'm a 1600x1200 whore too. Regardless, the layout looks nice, simple, but that "now playing" title was wrapping all ugly-like 2-3 lines on extremely long titles breaking layout even though it's partly fluid. Quick idea: marquee! hell, even your media players use it and it looks nice most of the time, right? Ok, I'm not talking about those pages from 1995, with the lime green background with just "OMG ROFL" blinking and scrolling across the page being useless. This is just a simple song title. Quick reference to the w3c and a few google searches later, the <marquee> tag is invalid across nearly every xhtml/html spec and css hardly has any support for it. Crud, ok, I should have known that. Now my title is going to look like a god damn optomitrists eye chart /me throws accessibility for those visually impared but who can still hear out the window. The options: invalid markup, or even more inaccessible content by piling on some 40 lines of javascript just so i can have a god damn ticker-style song title nicely scroll across the page. So, <marquee> or <script language="javascript"... assload of cdata tags or maybe some flash to really fuck with them, hmmm decisions? The deaf are already screwed since they can't hear the music that's obvious, but at least they could see a nice semi-scrolling ticker to see what's playing. Now, anyone who's blind with a screen reader should surely be able to parse a <marquee> tag vs JS or flash, right? So the question to the w3c, why the hell invalidate it at all? It's not like I'm intentionally creating a page to set off epileptics with the mother of all blink tags! It's actually a quite useful tag if used correctly under the correct context, all while maintaining that which you're already aiming for: ACCESSIBILITY... THAT, and nearly any browser you pick out (probably screen readers too) compiled this or last year (or even long before that, which aren't IE) support it and have supported it for quite some time! Even some CSS3 specs are slated to support marquee elements in the future (I think that's right, yeah, you can correct me on that one). So I think at this point I'm just going to screw myself by using this marquee tag conditionally, unless I can find some xhtml compatable work-around which doesn't require JS, Flash or some other bloat I have to add to my page. THANKS W3C, YOU BLOW! Love, Lech P.S. Don't read and interpret any of this as me trying to intentionally screw the deaf, blind, or epileptic folks in any way, really, I don't want to screw anyone over. I just like the god damn page to validate while remaining lite(tm)! GRRRR!

Bergamot

Of all the things that make me want to punch the w3c in their stupid face, this ranks pretty low. And I can't even think of how useful a marquee tag would even be without some kind of dynamically updating ajax stuff, and if you have that, then the javascript of actually making it scroll is trivial.

aloicious

There's a balance between validity and functionality. If you can't make it valid, make it usable for the greatest number of your users.

Lack of validity won't make your shiny new website explode. That being said, there are better ways to do it than with a marquee...

Bergamot

I want to know why there's no easy way for a container to clear floated children. I want to know why there's no way to remove an element from the document flow, but position it relative to where it would have been. I want to know why there is no easy way to center a div vertically within a container. I want to know why CSS selector syntax is so incredibly wimpy.

lech

aloicious, I'm all ears on a similar replacement method that's simple enough to impliment without much bloat. Bergamot, I'll agree, it ranks pretty low, but if you look at the common sense of it all in terms of actually being able to use just that stupid tag, or at least a css selector to enable it, it would be a plus. Ajax or not if you're pulling content one way or another. But yes, even the gripes you listed are also on my list, but this one is just one of those mindless ones I figured I'd toss out there just out of annoyance.

nick1presta

Um, for 99% of all things, marquee tags are annoying as hell and useless. I want to see all my text at once, not sit there and wait for it to scroll across the screen. However, that is besides the point since you obviously need it for an app. Also, use this for marquee, http://developer.mozilla.org/en/docs/DHTML_Demonstrations_Using_DOM/Style:Stock_Ticker http://devedge-temp.mozilla.org/toolbox/examples/2002/xb/xbMarquee/index_en.html No one said you had to follow the W3C's standards. You are free to create your own Document Type and your own namespace and such.

placenamehere

I have nothing to say about marquee... i wouldn't be opposed to browsers supporting text-decoration:marquee (or similar solution like -moz-binding: but i don't miss it. Is overflow:auto too bulky of a solution visually here -- bringing in scrollbars. Bergamot's post is a bit more interesting though.. .just some thoughts off the top of my head... (1) two solutions for clearing blocks that would work according to spec but not browsers named IE6 (or probably IE7) - using the + selector to make sure the element after the container clears (div#content+*).. doesn't open up the content box though if you're trying to use a background for example - using :after to add an element to the container that can be cleared (2) My guess is because it would be hell on a layout engine, particularly if you were compounding multiple elements positioned this way... I know a few cases where it would be useful, instead of floating hacks, but t could get real messy real fast (3) there is[1] *if* you know the height of the eleemnt you're positiong. You could hack that with ems too if you know how many lines of text you have. - if you are looking just to the css2 spec you could also use display:table-cell and vertical-align:middle (4) there are some thigns i think are missing, but ultimately a lot of what is missing is again because of overhead. Here i think they went overboard in the 'make sure the spec can be followed by a huge variety of UAs and platforms' area and could have added some selectors like '<' or '-' where you're only moving one element around the tree, but I don't think you'll ever see something that is the opposite of "A B" becuse you'll get into situations where (a) you'll have tremedously ugly cascades and overhead parsing and (b) you'll never be able to render a page until you're totally done parsing it becuase you'll just have too many cases where you have to redraw elements. [1] http://placenamehere.com/yayhooray/valigntest.html

Bergamot

(1) two solutions for clearing blocks that would work according to spec but not browsers named IE6 (or probably IE7)
- using the + selector to make sure the element after the container clears (div#content+*).. doesn't open up the content box though if you're trying to use a background for example
- using :after to add an element to the container that can be cleared

I know the workarounds (and even the workarounds to the workarounds that make everything work in IE6), but that doesn't change the fact that this is basic functionality. If not enabled by default (and I'm racking my brains trying to think of a situation when I would want a float to overflow its container), it should be an explicit setting, not a side effect of a setting on some other (potentially imaginary) element.

Oh, and for the record, both methods should work fine in IE7; sibling selectors and :after have been added.

(2) My guess is because it would be hell on a layout engine, particularly if you were compounding multiple elements positioned this way... I know a few cases where it would be useful, instead of floating hacks, but t could get real messy real fast

I used to think so too, but while reading through Mark's CSS for the accounts page, I discovered something interesting: Absolutely positioned elements without position properties are removed from the document flow, but remain in the location they would have been had they been flowed normally. This is vaguely implied by one example in the spec, but is never explicitly spelled out.

Since it's already completely outside of the document flow, it can't be terribly hard just to move it a few pixels left or right.

(3) there is[1] *if* you know the height of the eleemnt you're positiong. You could hack that with ems too if you know how many lines of text you have.
- if you are looking just to the css2 spec you could also use display:table-cell and vertical-align:middle

Whenever you have to resort to an ugly hack, you're either trying to cover up for a badly designed browser, or a badly designed spec. In this case, it isn't the browser.

(4) there are some thigns i think are missing, but ultimately a lot of what is missing is again because of overhead. Here i think they went overboard in the 'make sure the spec can be followed by a huge variety of UAs and platforms' area and could have added some selectors like '<' or '-' where you're only moving one element around the tree, but I don't think you'll ever see something that is the opposite of "A B" becuse you'll get into situations where (a) you'll have tremedously ugly cascades and overhead parsing and (b) you'll never be able to render a page until you're totally done parsing it becuase you'll just have too many cases where you have to redraw elements.</blockquote>Performance and clarity are both extremely valid goals, but it's pretty obvious from the spec that neither were a priority.

Also, browsers that render the page before parsing the whole stylesheet are generally looked down upon

Kosmo

This all comes down to the age old wisdom, standards don't mean jack shit, if you still have to hack away on every different browser and their different versions.

Bergamot

Well as long as you confine your "hacks" to CSS and JS, the markup will still at least be clean, which is what's really important.

Mainly, it's just a hassle.

Kosmo

True, and the main point would be that, the small differences between browsers and their different versions are due to the programmers different views of the same thing. If W3C developed some libraries that controlled the behavior of tags and such, then it would be unified across browsers. Or maybe if they did the renderers and different browser makers just made the doohickeys and whatnots.

placenamehere

I didn't mean rendering before the stylesheet is bought in, i meant before the html document is finished being parsed... this isn't a fouc problem, its one of drawing the content.. even styled. by creating slectors that move back up the tree you're creating a sitaution where the entire document must be layed out before displaying it or risk many more situations where a full reflow is called for. Consider the case where you can call the parent of div#footer instead of having to select the body element explicitly to change the styling to color:red from color:black... With current selectors and cascading rules a UA will know what color to style the text of a P as soon as it its it... with selectors that can go the other way it will think the color is "black" when it hits the P in the 1st line of the body.... but 200 lines later, after its rendered almost the entire page its gotta say "oh crap! we have a #footer! now I have to modify the cascade for the entire page!"

placenamehere

oh, and :before/:after will at this time not make IE7: http://blogs.msdn.com/ie/archive/2006/02/02/523679.aspx#524199 Not sure about other missing elements, i know they're working on min/max height & width, but i don't konw about other "simple" things like the inherit or transparent unit values. A good & growing source of details here: http://css-discuss.incutio.com/?page=IE7

nick1presta

""This all comes down to the age old wisdom, standards don't mean jack shit, if you still have to hack away on every different browser and their different versions."" Um, standards are important and mean everything. Th W3C set these standards and SHOULD be followed. It's not W3C's fault that BROWSERS don't conform to the set standard. Gecko, Presto, Tasman, KHTML and WebCore all seem to follow the standard pretty well. Too bad IE doesn't. Does this mean you should throw standards out the window? No, of course not. You should provide a standards compliant alternative (conditional comments if needed) to support IE, handheld devices, older browsers and other things that can't support the standards due to a variety of reasons. Saying standards don't mean anything is just plain stupid and lazy.

WallPhone

Not meaning to veer off the direction the thread is heading, but why don't you truncate the song title and keep the whole title in a hidden span that appears when the mouse hovers over the abbreviated title? Something like the folder names do in Windows Explorer when the left hand pane is too narrow.

aloicious

I want to know why there's no way to remove an element from the document flow, but position it relative to where it would have been.

Isn't that a contradiction? If you remove an element from the document flow, then it is... well, removed from the document flow. It's relative to where it should be - that is, not in the document flow!

Bergamot

Isn't that a contradiction? If you remove an element from the document flow, then it is... well, removed from the document flow. It's relative to where it should be - that is, not in the document flow!

Elements that are removed from flow don't automatically go off to [0,0]; they stay in the same spot they normally would. everything else flows as if that element didn't exist at all.

Sometimes, though, it would be nice to take that element and bump it 10px up. I can fake it with negative margins, but that's not really guaranteed to work everywhere.

oh, and :before/:after will at this time not make IE7:
http://blogs.msdn.com/ie/archive/2006/02/02/523679.aspx#524199

Interesting; I wonder why that specifically was cut.

by creating slectors that move back up the tree you're creating a sitaution where the entire document must be layed out before displaying it or risk many more situations where a full reflow is called for.

I can't see how it would be worse than a sibling selector.

And anyway, specific browser optimizations are not the business of the spec.

aloicious

That's right, being removed from the flow means that the rest of the elements aren't aware of their presence.

I still see abs/rel position as completely exclusive and not sure why you'd want to combine the two. Despite some of the comments above, and knowing that I'm not sure of your usage, I would still recommend some floats and clears to achieve it.

Well that's just me, anyway... :P

lech

My question is, has anyone here actually ever made their own DTD?

Bergamot

I generally prefer Relax NG

placenamehere

<blockquote>And anyway, specific browser optimizations are not the business of the spec.</blockquote> When the spec is being written by representatives of the individual implementors their concerns over implementations will always be the business of the spec. And without those representatives you'll wind up with an unimplementable and ultimately useless spec.