Re: New layout language.

> Well as I stated before, your system is really not much different, you've
> just shorthanded some stuff.  And I'll also point out that your 3 minutes
> and my 45 are vastly different since mine had to be tested first.

And yet I know mine is right since given a layout the design is
obvious, which is something that isn't garunteed in CSS. As you said,
you had to test. The only thing I'm looking for it is typos. Assuming
support for the langauge... Something that could be written in an
afternoon, all it takes is knowing what you want.

Because each layout has one set of code for it and that code can be
known easily, it becomes trivial to create a WYSIWYG editor for it
(and it produces clean code to boot).

> Additionally if I had to set up something like this again it would take me
> MUCH less time since I wasn't initially sure of how to go about certain
> portions of it.  But as a general rule, the only required fields to make
> the css do what you wanted were the position:absolute; and then a
> top,left,bottom,right placement, or in some instances 3 of those with a
> width statement.  You've short-handed min-width/height statements into your
> system, so that's really no different than css either.

It translates as so. In my version 
    left: becomes left (percentage) and margin-left. 
    top: becomes top (percentage) and margin-top.
    width: becomes min-width and width (percentage).
    height: becomes min-height and height (percentage).

> I'd also like to point out something I think you've missed thus far.  (This
> is friendly crits, not trying to be a pain)  Your middle two columns needed
> a 10 px margin between them.  You've provided no mechanism in your own
> system to handle such a thing thus far.  I've looked through your code a
> couple times now and still come up empty handed there.  It's exactly this
> sort of a scenario that explains why the W3C box model (while a little
> odder at first) is superior to the MS box model.  

Actually they are there. It's incorperated into the code you saw. But
margin's don't have to be explicit since it's incorperated into the
left and top calculations.

> Your initial supposition
> was that you wouldn't need margins at all since you're manually placing
> each object exactly where you want, but that isn't the case when you're
> using percentages.

Sure it is. My supposition is still correct. I've done the math to
prove that it is.

> This isn't the only area you'd need the margins either.
> Between the middle two columns and the bottom footer area you'd have the
> same problem.

Again, no... The margins (or spacing) was accounted for.

> Again, I'll mention that your system would not degrade nicely after a
> certain resize point either.  You'd suffer the same fate as my css version.
> I've at least proposed a fix for that:

It degrades in the same way in this instance, but you could produce
code that would degrade gracefully. Also the algorithm could be made
so that it does. Though it won't have the CSS problem of overlapping.
As the viewport shrinks past the minimum size, the viewport hides the
excess.

> In addition to this particular short-coming, the only thing our
> conversation has produced thus far is an inkling that CSS might benefit
> from a more robust short-hand system.  But even that's questionable as I
> myself really don't like using short-hand at all in css as it can be
> confusing to beginners and advanced developers alike.

Well the system proposed doesn't suffer from the overlap problem that
I observed in the CSS version (using Firefox). Though alternate code
might work. It seems the constructs to do it are there, if you include
min-width and min-height, but it lacks consistency. At least now I
know that's it's possible. Also now that I've done a translation there
is at least one model that's deterministic.
 
> Finally, I'll point out that there's really not much of a difference
> between what you wrote and what I wrote.  A single days worth of coding
> could probably create the application needed to change anything you wrote
> in your syntax into real css syntax.  The problem here of course is that
> anything you developed thus would only work in Firefox, and now we're back
> to the whole point about MS not implementing squat for the last 4 years
> which I think is a played out conversation.

I would suspect that if you gave Microsoft a sufficiently compelling
reason to make changes they would. But I imagine in their mind,
nothing has been proposed that gives them sufficient reason to add it.
There have been no killer features incorporated. Most layouts in use
can be accomplished with either CSS or HTML tables in IE. I would
imagine to them their job is done.

> Suffice it to say that even if your language were implemented, it's not
> really any simpler than css is currently, and you'd still suffer from MS
> not implementing it, so how is it truly any different?

I consider it monumentally simpler in that it's fairly strait forward
for a person and a machine. It also intelligently incorporates four
differently named sets of properties (8 total) into 4 similarly named
properties.

But either way, the benefit of the system resides not necessarily in
it's layout model, but in the fact that it separates layout from
formatting (a plus), it allows for layouts to be reused (a plus) and
it can, but doesn't have to put control of layout with the
device/UA/user and not with the page, making it infinately more
maintainable since it moves the work from pages to devices.

It also finally allows separation of overhead content (navigation,
headers, footers, ToC, indexes, sitemaps, etc) away from the actual
document removing the need for content managment systems. Content
management systems exist to merge content with all the other things
that currently go into a page. This would no longer be necessary.

-- 

Orion Adrian

Received on Wednesday, 6 July 2005 16:14:26 UTC