"Stephan Soller" <[email protected]> wrote in message news:[email protected]... > On 07.10.2010 04:26, Nick Sabalausky wrote: >> "Stephan Soller"<[email protected]> wrote in message >> news:[email protected]... >>> On 06.10.2010 02:08, Arlo White wrote: >>>> That's because HTML/CSS is a pretty terrible language for anything >>>> beyond simple layouts. It shares more with Word/PDF/PostScript in terms >>>> of its purpose and history than it does with real gui layout engines >>>> (GTK, QT, etc). >>>> >>> >>> HTML/CSS is primary made for documents not applications. >> >> So true. That, combined with HTTP's stateless nature (and the >> exploit-prone >> nature of trying to build state on top of it), is why I view "web as a >> platform" as being little different from using PDF as an application >> platform. Heck, the PDF spec is so open-ended it could certainly be done. >> > > Never read the PDF spec, but I don't believe that it includes a world wide > network of web servers, does it?
Not explicitly as far as I'm aware, but then neither does HTML aside from URLs. And the PDF format does have provisions for files/data of arbitrary types to be embedded into it. So that could be used to embed HTTP URLs, or any other form of network-oriented links, or any other application-related information/instructions/data you want. Then you could build CSS/JS/CGI-like stuff on top of all that. And all of a sudden "PDF-readers" become a really shitty application platform just like what happened with HTML and web browsers. > > To be honest I use fixed with designs a lot. Usually I just don't have so > much content that I have to use every part of the screen. ;) > I've been tempted to do that as well just because controlling resize-flow is such a pain with HTML/CSS as they currently are. >> For instance, try to make a resizable box with bit-mapped borders that >> behaves reliably (I've needed to do a lot of that for a client recently). >> Easy as pie with tables and CSS background images. But with anything else >> in >> CSS, I've become convinced it's just not possible. >> > > Actually is pretty easy in CSS. I also had to do it a lot in the past. You > just nest as many elements (usually divs) inside each other as you need > background images. Then you use one of those divs to create the border for > one side: just assign a background image to this side and a proper padding > that makes sure only this side is visible. Corners are a bit tricky to do > no problem if you make the main container "position: relative" and then > position the corner divs with "position: aboslute". However for most of my > layouts I found that I didn't need a variable height and therefore 4 divs > where sufficient. This method had it's troubles for IE 5 but in IE 6 you > shouldn't have much of a problem (maybe one bug, don't remember exactly). > Interesting. > On modern browsers you can simply user border images (as many as you > want). This also eliminates the need for semantically stupid HTML > elements. However thanks to box-shadow, border-radius and colors with > alpha transparency I hardly use graphics programs to design any more. I > just do it directly in HTML/CSS with is usually quite a bit comfortable > (and faster!). I usually like to minimize bitmapped stuff on pages too, just because it's simpler, it can still get acceptable results, and I'm no artist ;) But then when the client has a design they want it to look like and it includes things that can only be done as images, well, then I just don't have the energy or patience to try to talk them out of it - I'll just toss in whatever I need to to make it work, even if that means tables, and be done with it.
