New home page

Nick Sabalausky a at a.a
Thu Oct 7 02:02:28 PDT 2010


"Stephan Soller" <stephan.soller at helionweb.de> wrote in message 
news:i8jvip$1ed6$1 at digitalmars.com...
> On 07.10.2010 04:26, Nick Sabalausky wrote:
>> "Stephan Soller"<stephan.soller at helionweb.de>  wrote in message
>> news:i8i10k$2a86$1 at digitalmars.com...
>>> 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.




More information about the Digitalmars-d-announce mailing list