New home page

Stephan Soller stephan.soller at helionweb.de
Thu Oct 7 01:13:10 PDT 2010


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? From an application developers 
point of view I have to agree, HTTPs stateless nature is a bit 
problematic at first. However as soon as it comes to scalability the 
stateless approach saves you from _a lot_ of trouble. I can't think the 
Internet could be what it is with HTTP being design to be statefull.

With the advent of REST people not look at HTTP a bit more and realize 
that there is more to it than GET and POST.

>> If you want you can simply make every element a block level element and
>> use JavaScript for layout. I don't know GTK and QT in depth but then you
>> should have about the same level of possibilities as with these layout
>> engines. It wouldn't surprise me if GUI frameworks like jQuery UI actually
>> do this.
>
> Heh, layouts that magically break with JS off. Fun :)
>
> I bet you're right though that something like that is out there on the web
> (or will be coming).
>
> You know what's even weirder, though? (And I hope on not veering too far
> offtopic with this...) I've actually some across pages that will load
> perfectly fine with JS off, and *then* two seconds after loading it will be
> automatically replaced with a different page that says "This site doesn't
> work without JS." Ummm, yea, it obviously *did* work...I *saw* it work...
>

There is very much abuse or improper user of JavaScript in the Internet. 
Especially in the cooperate world where people usually don't have the 
time or are not willing to really understand the thoughts behind the 
tools they use (HTTP, HTML, CSS, JS). Business people are usually happy 
as long as it looks fancy. Even among professional web developers I 
don't know that many that really care much about the technical 
"correctness" of what they do. There are many ways to get the job done, 
who cares if it was a "right" one? (reminds me of a program I once hat 
to understand: it only used 8 global variables and lots of gotos… but it 
worked… and everyone was happy with it, except me).

Well, in the case to work with or without JS you have to make a 
distinction. A "document" should work all right without JS since its 
main purpose is to be viewed. However if you build a "real" web 
application in the sense of being more like a desktop application its 
almost a lost cause to make it work without JS. It will only cause a 
great deal of redundancy of code and an overcomplicated architecture. It 
is possible though if you really feel the need. However I would just 
stick to using JS and in conjunction with a REST interface. For a 
"application" this gives you a great deal of flexibility while still 
maintaining a simple architecture and good interoperability with other 
systems.

>>
>> You can do quite a lot of stuff with the "position" property. As soon as
>> you defined something as "position: absolute" you can move it around as
>> you want. How well that (and other techniques) work depends on your HTML
>> structure. However I have to agree that in most practical cases you have
>> to modify the HTML in any way because the document structure changes.
>>
>
> Unfortunately, as soon as you start using "position: absolute", you usually
> start causing problems for resize behavior. Unless you're using a
> static-width layout which is generally considered bad style (for good
> reason).
>
> That's one thing I've noticed about CSS layouts that I think a lot of web
> developers tend to overlook. You generally *can* get what you want with CSS
> as long as you assume page width is always the same. But once you decide
> "web pages should be dynamic width" and try to make it look correct at
> different widths, that's when CSS *really* starts to break down. Tables tend
> to resize far better, and give you far better control over resize behavior.
>

Actually tables prevent you from reordering your elements according to 
page size but this limitation also affects other techniques. 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. ;)

A while ago it was more of a problem but since the zoom functions of 
browsers evolved a lot it's not that much of a problem any more.

However there are ways to build flexible layouts. Usually it's 
considered good practice to use the "em" unit (size of a X in the 
current font-size) for your dimensions instead of "px". It's quite handy 
and gives you the ability to resize the entire page by just changing the 
font-size of the body element.

Reordering of main page elements according to screen size used to be 
very tricky (some clever combinations of float and overflow). I never 
really did it on a project tough. Today you can just use [media 
queries][1] to define different layouts for different screen sizes and 
devices (this is also quite handy to define layouts printing or for 
mobile devices). There is plenty of material on the web about this and I 
regular use it to turn small documents into presentations (by defining 
styles for the "projection" media type which is used by Opera in full 
screen mode).

[1]: http://dev.opera.com/articles/view/safe-media-queries/

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

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!). However these properties can slow down browsers quite a 
bit (at least Firefox). [This article][2] gives a good overview of 
what's possible already and where it is supported.

[2]: 
http://dev.opera.com/articles/view/beautiful-ui-styling-with-css3-text-shadow-box-shadow-and-border-radius/

Happy programming
Stephan


More information about the Digitalmars-d-announce mailing list