On 13.10.2010 14:30, Bruno Medeiros wrote:
On 10/10/2010 15:23, Stephan Soller wrote:
On 07.10.2010 11:41, Bruno Medeiros wrote:
On 06/10/2010 15:25, Stephan Soller wrote:
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. 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.
The issue is not with level of possibilites. HTML/CSS has as much
possibilities as many GUI toolkits, if not more. (there is really a lot
of stuff you can do you HTML/CSS if you figure out how to). The issue is
that it's incredibly hard to do that, HTML/CSS is so convoluted. (and
I'm talking about proper flowing designs, now pixel-based, fixed-width
ones. Those are fairly easy in both HTML and GUI toolkits).
It does not feel convoluted to me but I have learned HTML/CSS gradually
as they evolved. Therefore I might not be able to properly see how it
looks from the distance if someone doesn't know the details. To me it
looks well structured (block vs. inline elements, different distinct
layout models, typography, etc.). There sure a some parts that deserve a
little cleanup and simplification but I can't think of any right now.
I'm just curious about your point of view. What parts of CSS look
convoluted to you?
The layout rules. I don't remember the details, because again I've
forgotten the rules and most of what I learned then. There is only issue
I can remember on the top of my head:
* If you have two nested divs, and the inner div has a position value
other than "fixed", it is not true that the inner div is visually
contained on the other div! That makes no sense to me. You have to add
some properties to the outer div (such as overflow:hidden) to make it
so, but it usually these properties have side-effects that are adverse
to other aspects of the layout.
I think you are confusing two things. The "position" property does not
influence how large an element is (it contains all it's normal content).
The value "static" is the default value and does nothing at all (the box
is not positioned, that's what you probably meant with "fixed").
"absolute" lets you position the box at arbitrary coordinates but also
takes it "out of the flow". That is all elements after it ignore
absolute positioned boxes. This effectively allows you to layer stuff
like you want. There are some more values ("relative" and "fixed") but
this isn't a CSS lesson.
The behavior you describe is a "problem" of the float layout model. If
you float an element left or right it is taken out of the normal
document flow but all following content flows around it. This was
defined for pictures or figure in texts. You can then use the "clear"
property on the next paragraph to stop it from flowing around the picture.
Since early CSS had no proper layout model for multiple variable height
columns (like tables are by definition) man people used the float layout
model to "emulate" multiple columns. The problem with this is that the
floated columns are taken out of the normal document flow. Therefore the
parent element does not contain them and usually collapses to zero
height. To avoid this you can either add a clearer after the columns or
use the "overflow" trick (any value other than "visible" will do) which
will make the parent box containing all it's floated child elements.
This works in IE 6 and does not need an extra element. Therefore it's
the most used technique now. But all this does not change the fact that
using floats for column layouts is still nothing else than a workaround
for the missing column layout model in the early days.
For many page layouts this actually isn't needed but especially people
used to use tables for layouts often try to use this technique because
it mimics tables more or less. With CSS tables you don't have to use
floats any more since you have all the power of tables in CSS now (with
less markup in most cases). These however only work with IE 8 or newer
(I'm not sure if not already in IE 7) and I don't know about FF 2. If
you have to make pages that work in IE 6 and 7 you still have to use
floats though.
And what do you mean "use JavaScript for layout"? You can't use
JavaScript for layout. You can use JavaScript to programmatically
manipulate the CSS properties of HTML elements, but you are still using
the same HTML rules for layout, so the difficulty is unchanged.
You're right. At the end HTML/CSS simply is the interface to tell the
browser about the structure and appearance of your document. However you
can make every element a block level element ("display: block;") and use
absolute positioning. Then each element basically behaves like a window
of an window manager and you can use your own algorithms to do the
layout by calculating the position and dimensions (top, left, height,
width). At that stage you don't have to think about any of the layout
models of CSS and you're totally independent of them.
Happy programming
Stephan
Ah, I see what you mean now. Yes, then you could have your own rules and
layout system, assuming HTML Javascript can detect window resizes (from
what I recall it can, but I'm sure if it is possible in a
standards-compliant way, or if it has to be browser specific).
But even if possible, this approach would be awful : you would need JS
enabled to layout your site, plus you would incur a heavy performance
penalty for all the JS code you'd be executing.
JS can detect window resizes (there's an event for it). The JS speed
shouldn't be a problem (IE 6 is pretty slow though) as long as you don't
layout an entire operating system with it. JS has become pretty fast in
the last few years.
To rely on JavaScript isn't a problem for most "application" since the
application itself only works with enabled JS, too. "application" does
mean something like a desktop like application with reacts to
interactive events without page reloads. Since that requires HTTP
requests in the background you have your JS dependency anyway.
On websites however required JS support is more of a problem. But in my
experience websites are structured like documents most of the time (they
at least try to deliver content, many big cooperation websites however
totally fail here…). In this case the layout models CSS provides are
often quite handy and match for most if not all cases.
In short:
- For websites or documents CSS fits well
- For applications you can use JS for layout since it's needed anyway
Happy programming
Stephan
