Re: New layout language.

Orion Adrian wrote:

>While XFrames is a useful spec it doesn't solve the problems I
>presented. It also is a very simplistic layout system that doesn't
>allow for dynamic growth in different proportions while maintaining
>appropriate padding (as least none of the examples present this).
>  
>
I still haven’t seen a good use case for such behavior, and I believe 
there to be none, or very few.

>Though I suppose you could use CSS to perform the actual layout
>mechanism, but then doesn't that bring us back to the same problem.
>Margin isn't safe.
>  
>
CSS cannot do ‘growth in different proportions’ either. It can only do 
sizing in differenent proportions.

And I do not see any problem with margins.

>But, XFrames could be turned into what I think is needed. You'ld have
>to get rid of the source attribute and replace it with role.
>  
>
Indeed, and I suggest you try to comment on that specification, and 
improve it. It is clearly outside the scope of CSS, given that the CSS 
WG does not control the XFrames specification, and the W3C does not 
allow competing working groups.

Note by the way that even current HTML Framesets can be used for this 
purpose, which is implemented right now - there is nothing in the HTML 
4.01 specification that requires frame sources to be HTML as well. HTML 
frames already have ‘name’s, so what would need to be done additionally 
is to standardise on a set of default names. The same is probably true 
for XFrames (which I am not familiar with).

>But regardless, even if XFrames was implemented by anybody which would
>require it get out of working draft, it still wouldn't prevent people
>from doing layout in CSS which is where the problem is.
>
You should not enforce a solution on users. They may not agree with what 
you think is best.

>It's a problem
>at a minimum for users and user agents trying to control content
>coming to them. Unless of course we expect users to make custom style
>sheets for every site they go to.
>  
>
As I mentioned before, the role attribute in XHTML 2.0 will let the 
author define roles for separate sections of the document, with a 
standardised set. Given that users use that specification (which is an 
assumption you will always have to make, also with your proposal) it 
should be relatively trivial to match on those roles and give them a 
default layout position.

With regard to conflicts with authored layouts, in practice most sites 
will use those same role hooks for the definition of their layout. And 
in the cases where they do not, 1. absolute positioning within an 
absolute positioned element will be positioned relative to any 
previously absolutely positioned elements, so they can never mess 
up/ignore your custom-set layout, and 2. you can easily explicitly 
negate any further positioning by using rules such as e.g.: 
*[role=navigation] * { position: static ! important }.

Besides, why not take it a step further and disable the author 
stylesheet in favour of a custom-created stylesheet. That should 
alleviate any concerns about author stylesheets. Because chances are 
that if you do not want to give site authors control over where to 
position layout elements, you also do not want them to control the size 
of your fonts (don’t you hate those small types), what colours to use (I 
might be colour-blind), etc.

And now, frankly, I’m done with this discussion.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.

Received on Saturday, 9 July 2005 16:39:58 UTC