On 07.10.2010 04:26, Nick Sabalausky wrote:
"Stephan Soller"<stephan.sol...@helionweb.de> wrote in message
news:i8i10k$2a8...@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
