Stephan Soller wrote:
> here's the link to the presentation of a talk I gave about D1:
> 
> 
> http://events.mi.hdm-stuttgart.de/archive/2010-04-13-d-einf%C3%BChrung/der-coole-stoff/Pr%C3%A4sentation%20(HTML).html 

Too good not to share! http://twitter.com/D_Programming

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.


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


-- 
Bruno Medeiros - Software Engineer

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

On 13/10/2010 17:42, Stephan Soller wrote:
> 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.
>

There is no confusion, I know "the "position" property does not influence how large an element is". I don't care how big or small the inner div is, I just want it to be contained in the parent div. I just mentioned the 'position' property because if position is 'fixed', it does make sense for that div not to be considered as contained in the parent div. But not so for other values of position (at least for the default one).


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

Yes, I forgot to mention in my example that the problem happens when float is used in the inner div. Thanks for noticing that.
Indeed, using a clearer div seems to solve the problem as, and likely with less side-effects. Not sure if it is completely side-effect free though.


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

Well I would say some sort of "column layout model" (if understood your term correctly) is pretty essential. You need something like that, or something that can do the same job nearly as easily. So are you saying its ok to use CSS tables now? (disregarding the issue with old browsers)
Because when I first learned about CSS and div layouts, the mantra was "tables are evil, don't use tables".

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

>For websites or documents CSS fits well.

That statement is true but completely irrelevant: This particular line of discussion was about how feasible it would be to use JS for layout, and JS only, nothing else of CSS, except for manipulating "position and dimensions" properties.
As such I made a statement about what the disadvantages of having to use JS would be in websites, HTML documents, or any other scenario.


-- 
Bruno Medeiros - Software Engineer

On 13.10.2010 22:39, Bruno Medeiros wrote:
> On 13/10/2010 17:42, Stephan Soller wrote:
>> 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.
>>
>
> There is no confusion, I know "the "position" property does not
> influence how large an element is". I don't care how big or small the
> inner div is, I just want it to be contained in the parent div. I just
> mentioned the 'position' property because if position is 'fixed', it
> does make sense for that div not to be considered as contained in the
> parent div. But not so for other values of position (at least for the
> default one).
>

Sorry, look like I got confused then. :)

I'm still not sure if I understand your point correctly. Do you mean that it's inconsistent that some positioning models take the element out of the document flow?

>> 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.
>
> Yes, I forgot to mention in my example that the problem happens when
> float is used in the inner div. Thanks for noticing that.
> Indeed, using a clearer div seems to solve the problem as, and likely
> with less side-effects. Not sure if it is completely side-effect free
> though.
>
>
>> 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.
>>
>
> Well I would say some sort of "column layout model" (if understood your
> term correctly) is pretty essential. You need something like that, or
> something that can do the same job nearly as easily. So are you saying
> its ok to use CSS tables now? (disregarding the issue with old browsers)
> Because when I first learned about CSS and div layouts, the mantra was
> "tables are evil, don't use tables".
>

I also heard/read that a lot when learning CSS. Using table _elements_ for layout is bad stuff since the table element in HTML indicates tabular data. If you use it for layout the abstract content (or data) of the page gets totally screwed up just for it to look right.

However the layout rules of tables are quite useful and so they found their way into CSS. If you can properly separate data from presentation
you can use whatever layout rules you want. ;)

Basically don't use table _data_ to push elements around in HTML. Using table layout rules in CSS is ok since it does not interfere with the data of the page.

>>>>> 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
>
>  >For websites or documents CSS fits well.
>
> That statement is true but completely irrelevant: This particular line
> of discussion was about how feasible it would be to use JS for layout,
> and JS only, nothing else of CSS, except for manipulating "position and
> dimensions" properties.
> As such I made a statement about what the disadvantages of having to use
> JS would be in websites, HTML documents, or any other scenario.
>

I see now, I somewhat missed the point. For many situation (e.g. websites) I agree with you that using only JS for layout is awful. But there are also situations where this approach looks ok (e.g. rich client side applications).

Happy programming
Stephan

On 14/10/2010 09:09, Stephan Soller wrote:
>>
>> There is no confusion, I know "the "position" property does not
>> influence how large an element is". I don't care how big or small the
>> inner div is, I just want it to be contained in the parent div. I just
>> mentioned the 'position' property because if position is 'fixed', it
>> does make sense for that div not to be considered as contained in the
>> parent div. But not so for other values of position (at least for the
>> default one).
>>
>
> Sorry, look like I got confused then. :)
>
> I'm still not sure if I understand your point correctly. Do you mean
> that it's inconsistent that some positioning models take the element out
> of the document flow?
>

Not exactly. My problem is that when an element is taken out of the flow (such as with "float:left"), it means the element no longer needs to be contained in the parent div. I think that model is very unhelpful. Although I'm no expert in HTML coding, I would venture that in at least 90% of the cases that's what you want (for the element to be contained in the parent, if its position is not 'fixed').
Otherwise this brings up several problems: it messes up the layout of the elements right after the parent div. Or it messes up the area for the background/border colors of the parent div.
However if a clearer div works without additional problems, I'm probably happy with that, even if its more verbose.


>>> 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.
>>>
>>
>> Well I would say some sort of "column layout model" (if understood your
>> term correctly) is pretty essential. You need something like that, or
>> something that can do the same job nearly as easily. So are you saying
>> its ok to use CSS tables now? (disregarding the issue with old browsers)
>> Because when I first learned about CSS and div layouts, the mantra was
>> "tables are evil, don't use tables".
>>
>
> I also heard/read that a lot when learning CSS. Using table _elements_
> for layout is bad stuff since the table element in HTML indicates
> tabular data. If you use it for layout the abstract content (or data) of
> the page gets totally screwed up just for it to look right.
>
> However the layout rules of tables are quite useful and so they found
> their way into CSS. If you can properly separate data from presentation
> you can use whatever layout rules you want. ;)
>
> Basically don't use table _data_ to push elements around in HTML. Using
> table layout rules in CSS is ok since it does not interfere with the
> data of the page.
>

Ok, so it is as I thought, is is still "wrong"/unrecommended to use tables for layout. The recommended way to do column layouts is still with divs, right? By "column layouts" I don't mean tables, but stuff like a sidebar of any kind (the typical two or tree column layout).

-- 
Bruno Medeiros - Software Engineer

On 14.10.2010 13:03, Bruno Medeiros wrote:
> On 14/10/2010 09:09, Stephan Soller wrote:
>>>
>>> There is no confusion, I know "the "position" property does not
>>> influence how large an element is". I don't care how big or small the
>>> inner div is, I just want it to be contained in the parent div. I just
>>> mentioned the 'position' property because if position is 'fixed', it
>>> does make sense for that div not to be considered as contained in the
>>> parent div. But not so for other values of position (at least for the
>>> default one).
>>>
>>
>> Sorry, look like I got confused then. :)
>>
>> I'm still not sure if I understand your point correctly. Do you mean
>> that it's inconsistent that some positioning models take the element out
>> of the document flow?
>>
>
> Not exactly. My problem is that when an element is taken out of the flow
> (such as with "float:left"), it means the element no longer needs to be
> contained in the parent div. I think that model is very unhelpful.
> Although I'm no expert in HTML coding, I would venture that in at least
> 90% of the cases that's what you want (for the element to be contained
> in the parent, if its position is not 'fixed').
> Otherwise this brings up several problems: it messes up the layout of
> the elements right after the parent div. Or it messes up the area for
> the background/border colors of the parent div.
> However if a clearer div works without additional problems, I'm probably
> happy with that, even if its more verbose.
>

In the context of using floats for multi column layout I agree with you. It just doesn't make sense for the parent element to not contain any floating child elements. I looked in the CSS 2.1 spec to figure out why they defined it this way and the third example in the [section about floats][1] makes it pretty clear. Basically if you float an image in a paragraph you want the next paragraph to float around it, too. If you don't want it set the "clear" property of the next element (e.g. headlines). Therefore the "cross border of parent box" default is a good choice in such situations.

When using floats for layout I would rather like the default to be that floats are contained in their parent boxes. But that is not what floats were made for so the decision is ok IMHO.

[1]: http://www.w3.org/TR/CSS21/visuren.html#floats

>>>> 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.
>>>>
>>>
>>> Well I would say some sort of "column layout model" (if understood your
>>> term correctly) is pretty essential. You need something like that, or
>>> something that can do the same job nearly as easily. So are you saying
>>> its ok to use CSS tables now? (disregarding the issue with old browsers)
>>> Because when I first learned about CSS and div layouts, the mantra was
>>> "tables are evil, don't use tables".
>>>
>>
>> I also heard/read that a lot when learning CSS. Using table _elements_
>> for layout is bad stuff since the table element in HTML indicates
>> tabular data. If you use it for layout the abstract content (or data) of
>> the page gets totally screwed up just for it to look right.
>>
>> However the layout rules of tables are quite useful and so they found
>> their way into CSS. If you can properly separate data from presentation
>> you can use whatever layout rules you want. ;)
>>
>> Basically don't use table _data_ to push elements around in HTML. Using
>> table layout rules in CSS is ok since it does not interfere with the
>> data of the page.
>>
>
> Ok, so it is as I thought, is is still "wrong"/unrecommended to use
> tables for layout. The recommended way to do column layouts is still
> with divs, right? By "column layouts" I don't mean tables, but stuff
> like a sidebar of any kind (the typical two or tree column layout).
>

Yes, in HTML4 and XHTML 1 you would use div elements for each "column". I actually don't like that very much because it usually ends with a lot of div elements that don't add any useful information to the document. It's still better than tables though because table elements have a meaning that isn't met. But that's a problem of these two HTML versions (they lack structural block level elements). HTML5 adds more meaningful elements for that purpose (section, aside, header, footer, …) but that's a different story.

Happy programming
Stephan