New home page

Bruno Medeiros brunodomedeiros+spam at com.gmail
Wed Oct 13 05:30:58 PDT 2010


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


More information about the Digitalmars-d-announce mailing list