Re: New layout language.

On 7/6/05, Kris@meridian-ds.com <Kris@meridian-ds.com> wrote:
> 
> 
> OK Orion I think we're at least getting somewhere.
> 
> Let's see if we're on the same page.
> 
> 1.) CSS can do a lot currently, and is close to working for layouts the way
> you would expect and want.

It can do them, but not in a pleasing way.

> 2.) most of your other issues have been addressed/resolved with the
> exception of commingling of formatting and layout.

Not layout as content. Nor is the desire to move layout to the UA so
it can bring in other elements.

> That about right?

Close, but not exact.

> With that as the case, let us preface this.  Point two is really a
> religious point.  It's one that can be argued until everyone is blue in the
> face with essentially no change.
> 
> So with that in mind, let me start at this one gently.  I'm going to lay as
> solid a foundation as I can, and move from there.
> 
> We're going to assume that you're right.  Layout and Formatting should be
> encapsulated in different files.  You've suggestion different languages,
> and I'm opposed to that since CSS already takes care of both issues.  I
> think we can probably except that position. I hope.

Combining elements only makes sense if the task can only be done by
combining it. Separate, smaller systems are easier to write, test and
maintain.

> >From there let us assume that you're correct.  HTML should be formatted by
> one document, and the layout should be controlled by another.  Nevermind
> that these documents are written in the same language, the real point of
> the arguement is what SHOULD be happening.  Now, I don't know if I agree
> that it SHOULD happen... but I can definitely see how it might be
> beneficial.  With that said, all the selecting power we currently have in
> css gives us everything we need to do this currently.
> 
> Example:
> 
> if I have an id of main I can format in one document the layout thus:
> 
> #main {
>  whatever:css;
> }

It does, but it also open up the door for abuse on the formatting side
which means that content will be written to a specific id rather than
a class-based system. This allows authors to write HTML and CSS
styling individual elements differently than the rest in order to get
a layout they want. Take it away, give them what they really wanted (a
layout system) and everybody's happy (minus the UA people).

> and in another document I have a number of text formatting options open to
> me.  I can either add a class to the same element of main, and then define
> that class here, or I can also format the id main for general text
> purposes.  In fact, in my mind the fact that we're using the same language
> to describe the format and layout is beneficial.  It means we can get away
> with having less information directly in the html document.  Yes?

ID's shouldn't be necessary in a formatting language. Classes
shouldn't be necessary in a layout language. Because of the
combination, they get used for the wrong thing. You may consider this
a religious point, but to me, it directly corelates with at least two
things. One maintainability and two, the ability for user agents to
meaningfully and consistently modify formatting and layout for users.
I'll describe this in more detail if you like.

> Assuming Yes, then we're back to the REAL problem.  The real problem is
> that people DON'T do this.  And the reason they don't is that layout and
> format ARE written in the same language.  Path of least resistance suggests
> that we put them in the same document which is where your problem come up
> (as I understand it).  So this is less an arguement of how things work, and
> more an arguement of how things OUGHT to work.

Design in computer science is always about how things *ought* to work. 

> And I agree, the idea is
> beneficial.  But IMO, it's JUST an idea.  It's an intruiging enough idea
> that I may very well give it a go on my next project.  But truthfully, I
> find marking up two seperate documents somewhat of a pain... no matter how
> logical it may be.

This will be debated fruitlessly until we can get actual numbers. I
think people will like the idea of separate layout and formatting and
how easy it is to maintain versus combined layout and formatting.

> I think that about covers it as far as I can see.  To sum up:
> 
> 1.) What you suggest has possible benefits.
> 
> 2.) Ultimately what you suggest is only an idea.

Actually I coded it up while reading these. It took me about 30
minutes. It defines the regions using borders. Though this may or may
not be an idea in your mind, the code is less than 80 lines (not
including boilerplate) which includes a 31 line struct for the data.

> 3.) Perhaps it could have far reaching effects if it were actually taught
> to people, but ultimately, that's not really the consortium's job.

It is however the consortium's job to create tools that are optimized
to the task. I've also shown that the system is incredibly easy to
code up. I don't know what the record is for developing absolute
positioning in CSS, but I bet I beat it by a bit.

> So like I said, it's a nice idea, but as I see it, it's really just an
> idea.  It's easy to implement, but that's a personal style point, not a
> definition of how it WILL be.  Chances are there will always be people who
> will mix layout and format.  It just stream-lines stuff.  :-)

To me, it unstreamlines stuff. Either way it's implemented now. Now it
doesn't grab data from a file since I haven't come up with an official
syntax. It also doesn't put anything in those region. I could make
each one a little browser I guess, but I'm not trying to produce a
product, but rather a proof of concept.

As an aside, it scales down past it's min sizes nicely.

-- 

Orion Adrian

Received on Wednesday, 6 July 2005 23:44:34 UTC