Re: New layout language.

On 7/6/05, Kris@meridian-ds.com <Kris@meridian-ds.com> wrote:

> Your model system is virtually identical to absolute positioning.  In fact,
> with calc() (which your model will essentially require as well) we could
> use css EXACTLY the same way as you've proposed your method to work.  Yes
> or no?  I'm assuming you actually read through my CSS code for the last
> model just to see what I did.  The way I set my absolute position was from
> right and left yes, but I wouldn't have to do that with calc().

Yes, with calc the math would be there to do what I'm saying. I wrote
awhile ago that I thought layout was content and not presentation
touched upon by the primer.

Secondly, while I believe both layout and formatting should be in the
hands of the user agent, I believe that formatting will be controlled
system wide and layout will be contextual.

One thing I have heard many times is that designers shouldn't
manipulate fonts beyond serif and sans-serif (and those other funky
ones like monspace, etc). I think this is a good idea, but it should
have been expanded to all sorts of things.

I was wrong, flat out wrong when I said that CSS couldn't do certain
layouts. I may have nagging doubts about certain things, but I'll at
least take a more measured approach in the future.
 
> Secondly, You claim that your system will seperate layout from formatting.
> You know what, that's totally cool by me, and I have no problem with the
> ideal.  In fact, it's a good enough idea that perhaps it should be taught
> in schools and on the net and such, but I see no reason to frame people
> into it.  It's an added level of complexity.  Sure we all know it's just a
> quick link tag in the html, but I learned html and css by reading source,
> and I think that would be just that much harder.  And as I said before, you
> can already treat the problem with css as it stands currently (assuming you
> see it as a problem).

Problems and lost opportunities are always hard for me to describe. I
will often lump the latter into the former. To me this is definately a
lost opportunity. Extra languages don't complicate things for me. They
simplify them. Why? Because each language gets to use the appropriate
model for the task.

Data is set-based and relational. It benefits from a language that
understands that.

Business Logic is algorithmic in nature and benefits from a procedural
or OO language.

Semantics are structural and benefit from markup (or similar structures).

UI organizational and event based and benefits from language that
understands that.

Formatting is class based and benefits from a class-based approach.

Layout is ID/IDREF and role based and benefits from languages that understand.

> XSL already seperates structure from content.  There's no need to re-invent
> it.  xml+xsl+css makes for some of the most powerful/versatile pages out
> there.

I know, I've got a site based on that plus a little glue (ASP.Net).

I'm not against having two parts of CSS which is why I haven't been
saying let's ditch CSS. I'm saying CSS layout is complex to me in it's
interactions.

What I'd like to get away from is margins as a mechanism for layout
and keep it a mechanism for spacing as it is in word processors.

I love the margin, border, padding concept. I think it's wonderful and
it's so simple. My issues have always been around margin's dual role
as layout mechanism.

As for the syntax that seems to be bothering everyone. I didn't start
with one and I included it because I thought making it similar to CSS
in the examples would aid comprehension. I really don't care about
syntax as long as it's usable. The math works with those properties
and those properties can be translated into CSS with bottom and right.

> Finally, I wasn't really looking for an apology.  I got one and that's cool
> and all, but what I'm really looking for is to get you to take a step back.
> Realize that the system you've proposed could be accomplished with the calc
> () and (min/max)(left,top,right,bottom) attributes, and to just help us
> push for those.

I don't care about the names as long as their usable. I would like
there to be as few attributes as possible (8 is the min I could find)
and no attribute should have more than one use.

> We don't need to rock the boat.  We don't need to toss CSS
> layout out the window.  It's one step away from being able to do everything
> you've outlined, but you seem to want to throw the baby out with the bath
> water.  Giving us a mental model to work from was great.  I'm glad we got
> to see exactly what you had in mind.

I didn't give you a mental model, I gave you a mathematical one. I
described that regions are a series of linear equations. You need 4 to
describe any region. This is a mathematical truth that I've been able
to find.

> But I showed you very explicitely how
> the CSS to do your layout worked.  It works VERY similarly to what you've
> proposed, and with this minor additions, what you've proposed could be a
> reality.  No need for a redesign.  That's what's frustrating me.  You're
> beating this horse that doesn't exist, and ignoring the elephant that's
> right behind you.

My issue with layout and formatting combined isn't around syntax. It's
around perspective. And this was missed in all the discussions. For me
it was an expression of mathematics and then what CSS couldn't do. I
was wrong about what CSS couldn't do. It can, but the mathematics
stands. And I never got around to the different needs.

Layout is content that describes regions and what they contain.
Formatting describes spacing, color and borders based on semantic class.

Layout isn't selector based.

Have you ever found yourself typing this out:?

p { position: absolute; top: 10px; left: 10px; }

Of course not... It would be absurd putting all your p's in the same
location. I haven't been able to find any reason for the id selectors
outside of layout. I also haven't found a need for class selectors
outside of formatting.

Layout's primary concern is spacial orientation.
Formatting's primary concern is spacing, color and font selection.

> Although again, I admit if the system worked
> without overlaps and such (the reason that completely absolute layouts
> don't see more use) I'd be more apt to use it.

Assuming the mathematics is correct, which they're simple enough for
me to think they are, then yes it wouldn't overlap.

> That to say though that I
> was sure I could do the layout in css as soon as I saw it.  Virtually any
> layout can be done similarly with absolute children of the body tag.

It's because I couldn't prove that CSS could do it, that I doubted it.
I could prove the presented system worked mathematically.

> Again, I'm sorry for blowing up at you, but I'm trying to paint my position
> here as crystal clearly as possible, and what frustrates me about you is
> that you don't really seem to care that the system you're talking about is
> already almost in place.  THAT is what I see as arrogant.  The desire to
> toss out what's there and working currently in favor of something that
> doesn't even exist and really isn't any different.  Does that make sense?

I feel we got strung up on details that weren't important to the
argument at hand and for that I again appologize. It is layout's and
formatting's very different needs that I see as being the fundamental
reasoning behind the split. If I thought CSS were just a few
properties or even dozens of properties away, but that the approach
were appropriate, I'd be 100% behind it, but, to me, it's not.

By splitting them, we can change the mechanism for overriding
properties. Formatting would be completely safe to override since one
section couldn't affect another. I know that when I change the
margins, font or color in my word processor, everything is going to be
alright.

The same is not true in CSS where a change in margins can break a
layout. The solution to date has been to use <div>'s to handle the
case.

<div>'s primary use today is for layout. <span> is also used, but less
so. What I'm looking for is a split so that when new layouts are
needed, no change to the document is. I have seen the same problems
come up again and again and to me the problem was this comingling.

I want those problems fixed, so I spent time finding a way to fix them
and presented the math behind it. I had hoped that a new math model
would help.

One thing though I hear and have heard for years now is that CSS and
HTML are fine and all they need is this X. Sometimes taking away helps
too does it not? You accused me of not looking back. That's what I'm
asking the working group to do. It feels like sometimes the group has
tunnel vision. That what's already there works and that we just need
to focus on what else we can add.

The HTML working group admits the mistake of <b>, <u>, <i> and so on.
So they took them out. There is nothing inherently wrong with those
elements, but their use limits you.

To me, this comingling limits you. Things can be better. They *should*
be better.

-- 

Orion Adrian

Received on Wednesday, 6 July 2005 21:17:42 UTC