Re: Parent pseudo-containers - a method for seperation of content from design

Do we really need something so heavy handed as XSLT though? And
besides it doesn't fix all the layouts we're trying to make.

There are two fundamental things that authors want to do and currently
can't. I think we must look to intentions and not just properties.
Authors want to be able to position one this relative to another but
they want to do so by connecting one of the nine points of interest.

I think whatever layout scheme is worked out, this should be a core
part of it. Currently this is impossible. Not hard to do, but
impossible since the size of objects can't be known and even if the
size of objects could be known, I still wouldn't want to do it that
way.

Orion Adrian

On Apr 7, 2005 7:33 PM, Ben Curtis <bcurtis@bivia.com> wrote:
> 
> On Apr 6, 2005, at 3:14 PM, Mark Moore wrote:
> 
> > I think Emrah's post speaks to a fundamental problem I'm beginning to
> > see.
> > There are really three distinct concepts that need to be separated,
> > not two:
> > Content, Layout, and Style.
> >
> > CSS crosses the boundary between Layout and Style and because it
> > doesn't
> > directly address Layout it does a very mediocre job.
> 
> Kudos to Mark for striking this nail on the head.
> 
> As the lead developer and standards-monger (our own, as well as the
> W3C's) of a web development business, I used to encounter on a daily
> basis problems and bugs embedded in code due to layout and style
> declarations being intermingled. Often the code would mix its purposes
> simply because the purposes shared a selector -- the content goes here
> and the content looks like this. The way CSS works now encourages this;
> it's good for simplicity, but discourages complex growth.
> 
> This year, I began separating all stylesheets into styles and layout
> sheets, and it has made life much easier for my team and my clients.
> The team can more easily use the cascade and specificity rules to
> selectively declare and override rules without stepping on each other's
> toes (e.g., the designers stop using position:relative; when they
> really want to use margins). It encourages a development process where
> the client can approve a layout without needing to approve the color
> scheme and font.
> 
> However, I also create a stylesheet for "structures," which are
> reasonably self-contained and often intricate blocks of layout code
> that don't care where they are put (e.g., a nested ul menu). Because
> they are self-contained and we fill our reusable code library with
> these, they often contain styling info, but we separate that out with
> comments to change from site to site. Does this mean layout and style
> should merge? No. It just means that we haven't quite standardized a
> way to encapsulate multiple file types in a single file (MIME-like
> multi-part stylesheets would be a boon).
> 
> Without suggesting a solution, I want to heartily encourage more work
> in this direction. Perhaps pulling layout coding strictly into XSLT is
> good; perhaps pseudo-elements and moving is enough. I don't know. But
> if the code encourages the separation of these things, then I think
> we'll see more adoption and greater efficiency in authoring, especially
> by teams. I don't think that the current CSS layout techniques
> encourage this separation, and if a different language altogether were
> needed to separate these elements of design then it would be worth the
> cost.
> 
> --
> 
>         Ben Curtis : webwright
>         bivia : a personal web studio
>         http://www.bivia.com
>         v: (818) 507-6613
> 
>

Received on Friday, 8 April 2005 14:25:39 UTC