- From: Wingnut <wingnut@winternet.com>
- Date: Tue, 11 May 2004 08:43:06 -0500
- To: www-style@w3.org
Hi gang! Interesting thought's, Max! I like it, for the most part! This isn't really an agreement or rebutal of anything you've said, Max. Your post just spurred me to thinkin'... which is illegal in most states. :) When I first saw css3's allowance of 8 images to define the borders of a box model... I thought "how pathetic". But, when that happened... it gave permission for a free-for-all as far as adding ridiculous stuff to css. Not long before, I had proposed the colorsweep style... where the color of some paintable on all box models... could be told to sweep slowly or quickly from one color to another. Then the turn-around style would be set, such as "loop" or "ping pong" and even a color strip could be defined... to define the sequence of color changes. Advanced BLINK if you will. Post-proposal, you could hear a mosquito fart. Now, gradient textures, other PROCEDURAL textures, and pattern tiling... pops up. As some may know... I mostly work with a node-serving system... not a webserving system. Thus... I pass around nodes... and I pass around style attribute contents IN those nodes. Can you imagine the thought of shoving 8 url's into that style attribute... just to get a border on a given box model? And oh what a scaling nightmare THIS boxmodel could present! One could categorize style levels. Lets do 3 levels for lack of anything better. 1. Basic css (css1.0 maybe) 2. Advanced css (anything from 1.0 till now) 3. You gotta be kidding css. (dreams of the dreamers) One might ask right here... CAN PLUGINS DO STYLING? Certain document elements (tags) could be "released" from the built-in css system... and allowed to be handled by a plugin styling machine. See, there is some kind of proverbial "wall" in css land right now. One such "wall" is in animated styles. Fire up your dom2 IE or Mozilla, turn on your javascript, and whack this... http://www.winternet.com/~wingnut/html/test/jackal/jackal56.htm There, is all 7 of the primary css animation "motors" needed to satisfy level 1 of an 'animated css spec'. But the wall is in the way. Its the same wall that stops gradient backgrounds. It stops procedurally-grown border styles too. It stops what I call "tracking backgrounds" too... where a single large picture can be applied to a container-element's backdrop, and the backgrounds of all contained siblings will take on the PORTION of the background that is "behind" their current position in the flow of the container. And even the FACES of a font... could be part of a picture that's mapped across all the faces of a given box model content text. The text chars themselves could have borders... and we could have precedural box model shape growing. We could allow z-axis rotation of box models and ROUND box models. Most folk try to slough these dreams off-onto SVG about this point right here. Not to single-out Corel Paint here, but lets face it. If one can "do it fine", or "pull it off with a kludge"... in Corel Paint... its going to show-up in the list someday as an idea to add to css. So, does one start thinking about a universal-interfaced "add-on-style" motor dohickey pretty soon? I somewhat-proposed awhile back... using the object tag for this. Give object tag the right param elements, and you can access "the box model growing machine" and this has-to-be-absolutely-positioned box model from heck... can be styled and built in very strange and new ways. In this way, the "box model growing machine" could be a plugin... and we could have versioning fun with that. I don't know what I'm saying here, really. The "cool ideas" and the "are you out-of your minders?" are never going to stop. Folks dream of expressionism. Where is "the wall" in the current css project? I think the 8-pic border crossed it... so now its a free-for-all for ideas. In my opinion, procedural (done with math formulas) user-made border styles should have come before any consideration of an 8-pic border. The color gradient is a procedural texture too. Give the object tag access to powerful math and pixel-by-pixel plotting power... and maybe we will be able to honor a TON of future style-up ideas. Continuing to dump all css-can't-do-that's onto SVG is not going to cut it. SVG is NOT the answer to a style language that can't seem to grow, or doesn't want to grow... with the future. Its not SVG's job to cover css's butt. So if nobody minds, lets stop handing-off all css can't-cut-it's... to SVG. Keep those styling ideas coming, gang! Just tell 'em "SVG IS FOR DOING SVG, NOT FOR DOING NODE STYLING!" :) Best regards, everyone! Wingnut
Received on Tuesday, 11 May 2004 09:50:27 UTC