This is simple query to the group. I am going to go check out the forums as well.
I am not a ninja themer. But I am not a newbie either. I've done about 4 themes for drupal now. All have been variations of existing themes.
My questions have to do wth table-based vs liquid lay-outs.
1/ What do people recommend as a framework for building liquid lay-outs? I have tried doing up my own version of the ALA holy grail thingme, and I have tried modifying the civicspace theme, and in neither case have I enjoyed the process. Are there her techniques that don't require such wholesale manipulation of the browser-space?
2/ If there really is no alternative than to fit widths in negative relation to each other, than why is it inappropriate to use tables again? for a simple 3 column lay-out?
I'd appreciate any help you could give me on what are probably relatively simple questions,
best,
mir
Comments
Not at all...
This even has an easy answer: grids.css.
I could go into greater detail, but its all right there on the page.
Nautilus
I spent some time working with YUI grids recently. Check out the Nautilus theme in my sandbox:
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/mfredrickson/...
It comes with a module (nautilustheme.module) that lets you pick from the default Yahoo templates. It's pretty powerful, but I will admit it can also be kind of confusing. Good luck.
It also includes a dynamically created stylesheet (style.php). This is a great technique for quickly building style sheets. You can then render them to a static file with:
$ php < style.php > style.css
Enjoy,
-Mark
looks cool
I'm looking forward to taking a closer look, when do plan to do a GA release? More and more people are talking about this kind of thing, especially with themable functions being tpl'ed. Themes that implement plugable library's and dynamic CSS are the next direction.
TravisC
Maintainability
when do plan to do a GA release?
Fair question. While it works now, I am concerned about the maintainability of it. The methods to switch the numbers of columns and assign the regions is pretty convoluted. I would prefer to have a system where users create regions , create a grid somehow, and then assign the regions to those grids. I would like to tie it my idea of using CCK nodes as hooks, instead of files on the file system. (see also http://groups.drupal.org/node/854)
Also, I don't want to provide support for this theme (as it is hard to maintain and fix bugs), so I'm not releasing it to the main repo. I'm sure I'll come back to it soon, but for now it's just a proof of concept. Really, it was just an opportunity for me to get to know the YUI grid system.
If people want to work on a design for the more flexible system, let's start a thread in the this group.
-M
grid "got" it all "wrong"
Or well, that is rather arrogant of me to say, without putting it in a context. In any case, their concept of IDS and classes and the associated CSS rules is completely the wrong way around. That is not something puritan, its just pragmatic. (just like not using tables can be much easier, simpler and make you more money)
If you use grid.css, you need to change your HTML to change the appearance. But Wait... wasn't CSS supposed to handle that apearance part? Yup. Hence the "wrong way around". CSS is for layout, look and design. HTML is for structuring your data.
You should start with a very solid and well structured XHTML framework. Once that is in place, you actually need very little CSS hacks, and most of the times tiny CSS files alltogether, to make a nice, or gorgeous sites, in any sort layout/design you wish.
Grid.css is aimed at people who heard that tables are evil (without knowing the why and how) and it presents a solution that uses a concept that is "evil" for the exact the same reasons as why tables are considered evil.
(note: I disagree with that mantra tables are evil) Tables are "evil" because the force you to dig deeper and deeper into your HTML to change the lok and feel of your site. Instead of using CSS to change that look, feel and layout, you use your data structure (xhtml is about structuring data) to enforce a layout. Grid does exactly that: it forces you to hack yout XHTML, your data structure, in order to change the layout, look and feel.
just like you don't use classes such as p.font-red-arial-bold {} you should not use ids and classes such as #top-left, or .yui-t2
Bèr
http://www.webschuur.com | http://bler.webschuur.com
Nature of CSS
It is the nature of CSS that it can only work on the XHMTL that it is given. It can't magically restructure code to change the relationships within the XHTML. Example:
This comes from your whatinsinname theme blog. You didn't just use CSS to move the navigation list, you restructured your XHTML.
Some CSS purists would be enraged to learn you had to stick a wrapper around your divs. "What?! An unsemmantic wrapper! Heathen!"
Truth is, you need it to make your design work. You need that structure.
I don't think the YUI Grid system is any worse. You want two columns? You need a grid and two units. That's pretty low overhead. I'd be impressed if someone could do it with fewer divs.
As to the names of the classes, give me 5 minutes with sed and I'll turn 'yui-g' into 'sectionbox' and 'yui-u' into 'section' or whatever names you would prefer.
Is YUI Grid the be all and end all of layout techniques? No. Is a good way to concentrate on design rather than worrying about browser bugs and recreating the wheel? Yes.
-M
CSS2 quirks and more
Things like "sliding doors" stuff like "float/clear save designs" tricks like faux colums. All of them need slight modifications to allow them.
Still adding a div or a span somewhere, is not the same as rewriting yout XHTML to change the layout. I that abovementioned quote, I clearly say "Another important change is the wrapper around some content and nav panes called #tools. Tools are what people often call sideblocks."
That is NOT what you state, ""What?! An unsemmantic wrapper! Heathen!"", that is simply a semantic way to group certain data!!
So. Lets take some examples, instead of talking about fuzzy filosophical issues.
I want my primary-navigation (note how I dit not call that top-navigation!) to move to the top-right.
In my example, I would change the CSS:
#nav-main {
position: absolute;
top: 0;
right: 0;
}
With GRid you would need to change the XHTML:
move the UL#nav-main into a div called #yui-g, then maybe change the uls id into something like #y-tabbed-list.
That latter way, is the wrong way of doing things.
But let us forget about theory and let us not talk about "how stuff should be done in an ideal world". This world is far from ideal. Let us be pragmatic.
If you want grid to work properly within Drupal, you need to rewrite quite some parts of Drupal (in theme functions). That is because Drupal outputs more or less semantic IDs and classes. #search-results, instead of #bottom-right, #main-content, instead of #yui-q, etceteras. You then have two choices: Wrap the core output in more DIVs, or rewrite them in mytheme_foo() functions to give them grid ids and classes. Both of them are a bad idea, IMO.
With my approach, all that needs to really happen, is to make Drupal use even more semantic names. Drop namings like "header", "sidebar-left", because they indicate a placement. Yet use names like "toolbar" or "navigation-main", go for regions like "branding" instead of "header" and name your ids and classes in contribs consistantly too.
http://www.webschuur.com | http://bler.webschuur.com
Excellent!
Prior to this, the most cogent criticism I've heard made of grids was that its largest overall size was limited to something rediculous I couldn't even display on my monitor, let alone that I'd worry about when the target resolution is still somewhere between 800x600-1024x768.
What you say, of course, makes complete sense. I definately fit the audience you describe -- my introduction to the subject came when I discovered that IE 6 displayed transparent PNGs using a grey background for some odd reason. I'd designed an entire theme using that shade of grey before I discovered that IE had changed the shade of grey -- and worse, I quickly learned that it would just keep changing the shade no matter what I did to accomodate it.
Since then, I've become a regular reader of alistapart, csshelppile, sitepoint, etc. -- so, from my perspective, its all been a matter of finding different hacks to provide fluid layouts and then someone else discovering later that there was some unnoticed flaw involved that broke later down the line. I'm also the first to admit that NOT using grids would involve migraine-inducing amounts of logic that I'd probably give up on before I succeeded in finding an alternative to same.
On the flip side, I think Mr. Fredrickson has it right in that there's nothing preventing anyone from simply changing the structure of grids to produce a semantically correct result. Myself, given the option, I'd prefer to avoid relying on third-party software of any kind whenever possible, but I also suspect that having a theme-independant framework to provide some degree of standardization has a certain self-evident merit, as well.
By way of example? I'm currently looking at a project that requires the main page (and possibly subsequent pages as well) be presented more or less like The New York Times or The Onion. As such, I'd as soon re-work grids and create my own theme from the ground up as opposed to trying to work out a grid system on my own and come up with a grid system that won't break IE. -- I'm not at all adverse to learning the how and the why -- I just haven't come across a complete explaination of it, yet.
Without going point-by-point
Without going point-by-point through each of the things in the entire thread above about 'grid' systems, and as someone who has used a couple of them extensively at this point I'd say there is a little bit of F.U.D. going on in certain places. A couple things to consider:
Having some kind of organized, reliable system can be a good thing, especially for multi-person projects. I've worked with people who like to do their markup 'their way'. Having a good foundation at least provides a point of reference and some solid parameters (e.g., quality assurance).
For most people's purposes, they will end up with something that works better, across more browsers, and in less time with a good framework than they will by hacking_it_out_themselves.
grids bad semantics?
I am so glad to see this thread continue... I'd like to hear more input on grids... such as ATCK.
does a web design based on grids such as (YUI / ATCK / BLUEPRINT CSS, etc )... lead to an evil xhtml/css relationship that requires changes to xhtml to affect changes on design. In other words, is Bèr Kessels correct in his post(s) in this thread? for instance http://groups.drupal.org/node/892#comment-2351
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Most (semi-) automated
Most (semi-) automated layout systems, and frameworks take the "wrong" angle. They provide CSS that works. Then its up to you to provide the XHTML with that.
The correct design angle, however, would be, to start with correct XHTML and provide the CSS with that.
Because of this fundamental design-flaw they allow you to create layotus fast. But they also force you to change your data-structure (the XHTML) in order to fit it into a design.
A classic example of where this design-flaw can lead to is the following:
<?php<div class="red"><div class="bold">bold red text</div></div>
.bold { font-weight: bold; }
.red { color=red; }
?>
What YUI and the likes ask from you is nothing less. It is not as obviously wrong as the example, still it requires you to work in a similar matter. With really, really ugly XHTML such as
<div class="layout b-c">But, as I pointed out earlier, its also all about pragmatism. One should not forget that CSS2 turned 10 years old last month. Ten years! Thats a whole lot of new insights, hypes, technology and web-revolutions passing by. CSS2 is really not up to the task asked from it. CSS3 would solve most of our current needs, but taken into consideration that the most used browsers don't manage to support a ten-year old, rather simple standard properly, I doubt we'll see CSS3 hitting the masses anywhere soon.
So, if all you want is a fast solution. And your CSS skills don't yet allow you to submit your own zen-garden submission, then I'd say: forget about semantics, SEO and technological beauty and go for what works: use a framework.
EDIT: the example had a wrong class :)
http://www.webschuur.com | http://bler.webschuur.com
A few pointers...
1) Buy this book: http://www.simplebits.com/publications/solutions/ . It is the simplest and most concise guide to building semantically structured websites IMO.
2) Rather than using negative margins, I have found that floating most elements as blocks is the easiest way to build a standards compliant site. For example, if I wanted a simple two column site with a header and footer:
<div id="header">
<h1>Site Title</h1>
</div>
<div id="column1">
<p>Lorem Ipsum</p>
</div>
<div id="column2">
<p>Lorem Ipsum</p>
</div>
<div id="footer">
<p>Copyright etc....</p>
</div>
The basic CSS:
#header {
display: block;
float: left;
height: 150px;
width: 100%;
}
#column1 {
display: block;
float: left;
width: 30%;
}
#column2 {
display: block;
float: right;
width: 66%;
}
#footer {
clear: both;
float: left;
width: 100%;
}
There are tons of tutorials out there on this topic, so I'm sure if you peak around a bit you'll find what you need. Please disregard the simplicity and (probable) errors of my example. You don't always have to float everything as in this example. I'm just hoping to get you onto the right path (not that the Holy Grail approach isn't!). I Hope this helps.
Rick
You have some great leads here
I will offer my own perspective....
There's an almost puritanical movement against using tables in design. I see tables as nice to avoid, but not the evil incarnate some people label them. Sometimes it's the easiest and yes cleanest way to lay out a site, where, between all the hacks to get IE to work properly, you might end up using more code to do the layout without tables. As you dig around, you'll also find that there are many sects out there of true believers who have what they consider the best way to slay the demon tables -- and they all are different, some more elegant than others. It's definitely worth reading a broad range of sources on this topic, especially when it comes to trying to design without demon tables but render the pages in the great satan IE.
Okay, kidding aside....
Tables are pretty unpredictable, especially if you try to have cells span more than one column or row (which technically you should be able to do). While I don't buy into the prevailing dogma that dogma is Truth, in the end, I prefer CSS just because once I have the layout I find it a bit easier to change things. It's also nice because, with some layouts and certain approaches, you can have the primary page content load first and the less-relevant sidebars load after.
But with or without tables, I find liquid-width themes the hardest to design, not only because it limits the kind of hard graphics you can use in the design, but also because when the page goes wide, the content paragraphs can just bleed out way way wide, and let's face it, having really long strings of text is hard to read. In other words, liquid width threatens to reduce usability or even accessibility. Ideally, paragraphs should be 40-50 letters (7-10 words) wide; wider and the eye starts to have difficulty tracking the text, especially on line wraps. (Narrower and you get long columns, which also can be hard to read.) Even the layout here on Groups.Drupal can be tough -- I often find myself dragging my browser narrower to make it easier to read.
If you want a simple boilerplate for a hybrid layout -- blocks for header and footer, but a table for the 3 columns -- I recommend Box Grey theme in the Drupal themes downloads area. It's liquid by default, very basic.
Laura
pingVision, LLC
PINGV | Strategy • Design • Drupal Development
min and max width
Not to hijack this thread too much but the real issue you are raling against is lack of min-width and max-width handling in IE (Gecko and KHTML browswers are fine).
Does anyone know of realistic hacks to get IE to honor max-width and min-width? I would prefer a CSS solution, but if someone knows of a behavior or JS, I'll listen.
I know I could google it, so keep those answers to yourself. ;-)
-M
That's part of it
But having superwide margins just to make the text readable is also kind of strange....
Not quite ideal. And all just to fill out the screen.
It's funny. I used to hate fixed width back in those 1.0 days.
Laura
pingVision, LLC
PINGV | Strategy • Design • Drupal Development
CSS Columns
It sounds like you want some sort of CSS based columns
Narrow screen:
[Left Sidebar] [ Main Content in 1 Column] [ Right Sidebar]Wide screen:
[Left sidebar] [Main Conent Column 1] [Main Content Column 2] [ Right Sidebar Column 1] [ Right Sidebar Column 2]To some degree you can do this now with floats, but as I understand it the CSS columns spec will help a lot. Don't expect IE to support it until v. 100, though. ;-)
-M
You read my mind
--or my plan book! I'm actually planning something like this for a contrib theme for Drupal. I'm even planning sacrificing a tall chai tea on the altar of IE to make it work there, too.
Laura
pingVision, LLC
PINGV | Strategy • Design • Drupal Development
liquid layouts and full circles
Most of us sacrifice ourselves at a similar alter. Forgive me a little ramble and hopefully it is not too far away from where you find yourself.
I started professional web design about 12 months ago. I have fought hard for good mark-up, I've slaved over many techniques and watched them break and learnt more hacks. But since design comes first for me, I constantly find myself challenged with new layouts and burning the midnight hours making them work.
Recently I got to the point when my savings ran out (!) and I could no longer screw around losing time on jobs. Quite simply the breaking point was when I had to borrow money to pay the mortgage. So I reverted to using tables for specific layout tasks, just because they don't break. I had come full circle, and wondered why I bothered in the first place. I have never really identified with CSS zealots, and it looked like I was going to be ex-communicated, so to speak.
Yes, tables work, but... Putting aside "usability" and "standards compliance", the kernel of truth is that using tables for layout sucks, it is a poison. I can't do it. It makes things icky. It is the blurst of times in any monkey-speak.
So in the last couple of weeks I made a final valiant effort. Minimal markup, liquid layout, faux columns, no hacks. I feel like I'm getting close now with two articles. I know that people have different paths, different techniques and different challenges. But for what it's worth here is where I'm at with (what I see as) the topic of this thread:
Minimal markup liquid layouts:
http://tjkdesign.com/articles/one_html_markup_many_css_layouts.asp
Plus what I needed to understand the use of background images (I only read the first page):
http://www.communitymx.com/content/article.cfm?cid=AFC58
Its fundamental
« But since design comes first for me, I constantly find myself challenged with new layouts and burning the midnight hours making them work.»
That is the crux of the issue. HTML is not, has never been and will never be, (made for) design. Yes. CSS ads a little layer on top, but we all know how buggy it is.
The issue, the fundamental part is, that when you design for the web, you simply cannot say « But since design comes first». A website that looks at it from that point is a failure, before it is launched.
The nature of the web is to be accessible. The nature of the web is that content comes first. That does NOT mean that a site cannot or should not be made pretty. But the prettyness is
Overrated
Just look at many of the successful/big/booming sites. Some look okay-ish (flickr). Some are awful (Google, wikipedia), others just basic (live.com, cnn.com). They not only proof that design does not come first for the users, but they proof above all, that ugly sites can come successful, even if they have competition from good-lookers.
very restricting.
As you state: This has brought you to your knees. I beleive many Internet startups went down, because they wanted more then the web can give. And wanting nice design on the web, is almost like wanting multimedia in a magazine. A magazine is not made to carry multimedia (paper is just not fit for carrying video). The web is not made to be pretty (HTML is never designed as a layout language).
So, conclusion: «Get Real».
If you want pretty stuff, use Flash or some other layout system. Offer PDFs, or DVDs for download.
If you want a website, forget the prettyness, and focus on the accessability, structure, content and all that, and less on the layout.
Bèr
http://www.webschuur.com | http://bler.webschuur.com
taking the wrong approach?
Hi Bèr
After reading your comments, and also considering Trae's comments on the dev list, it has got me thinking about my business model.
The most important clients I am pursuing want specific design/branding with a hand-picked amount of user interaction. They are using a separate advertising agency to create the full-page design as a PSD, along with a style guide, and I turn that into a theme and incorporate it into a Drupal site with the functionality that they need.
From what I am reading, this approach will get me into trouble? I am open to any thoughts.
Drupal is a *Content* management System
And as such, it makes presumptions. About layout (phptemplate, for example is still very conservative left-centre-right), about where you can put what (the special $content is where the Content goes, you cannot drag around parts of the content, or insert ads inside that content, etc).
Drupal, making these assumptions, forces you into a certain direction. Hence starting way out of that direction, will bring you in trouble. Drupal is really something you don't want to work against, but work with.
Don't start off with PSD files that show your client how it will look, because you are promising something you have no idea whether it can be achieved in Drupal. Don't write your client documents explaining what the site will do/be/handle without knowing exactly how Drupal does it. Small things can bring you in big trouble.
I have recently helped a client whom promised a site, with rather conventional ideas. But Lots of these promises cannot be handled with Drupal, simply because Drupal thinks it should be done different.
I can really advice you to start off with a year (or less) of Drupalleering with standard stuff. Build your father a weblog. Offer your client an ordinary portal. Use Drupal for your own project management. Etc. Once you really know Drupal very well, you will see where and how and when it offers flexibility, in design, or in development, and where not. Only then can you really start being creative, by using, exploring these areas of flexibility.
Bèr
http://www.webschuur.com | http://bler.webschuur.com
thanks
Considering those risks, I've been lucky so far. Graphic designers I've worked with are not trying to re-invent the format and don't create split-content designs (or whatever). For example, there was nothing difficult about this "design-first" site.
But, thanks for the warning. I'll add a clause to the contract so that I'm protected.
.s
Agree with you
Dear Bèr Kessels
Thank you for your very usefull comment. As a beginner in Drupal and Theme
Design i discovered that implementing Clients requests combining the functionality
of a CMS like Drupal with Highquality design need really about one year of
expreience with Drupal. I discovered Drupal just 4 month ago and still am
working in testing and applying different Themes. So i guess it will take me
another 8 moth to have the right overview of propose to Clients with CMS
request some selfmade Drupal driven showcases.
Best Regards
Drupal Learning and using at http://www.adaccs.at/thanage/
wireframe.theme
For starting a new template from the scratch the wireframe is very helpfull. Thanks a lot to Ber Kessels. It's definitly the best technical solved layout.
I'm using most of the time the light modified variant xhtml.1.1-variant, which validates a bit better.
I've allready thought about integrating a style.css.php based dynamic configuration of setting width and colors, but until today I had no real need for this.
May be usefull, but its not its purpose
I never meant wireframe to be a "base theme". I hear quite some people who use it as such, but I have to add that it is not made with that in mind.
So: Use it for whatever you like. If it suits your needs for a base theme: great! But I cannot guarantee that it will remain that, simply because I developed (and use) it for a whole different purpose: module/site development.
Whenever I develop a site, or write a module, that development is often "skewed" because I use a custom theme. I have contributed modules (in the past) that looked like cr*p, simply because where/when I developed 'em they looked rather okay. My custom theme made it look better then it "actually was".
Hence I prefer to develop a site in a completely neutral (even more neutral then bluemarine) environment: wireframe!
But: Because of the need for good basethemes, I started WhatsInItsName. Deadlines are looming, so I now have to focus (pragmatism) on buildingthe theme on top of that base theme. But I will update the first code whenever I hit another milestone!
http://www.webschuur.com | http://bler.webschuur.com
ahh, I see
That is interesting. I did try wireframe once, thinking it was something to build on, so you've cleared up some confusion I had about it.
style.css.php might be best integrated in argeebee
The colors should be really easy to change. Because I developed the theme with only that in mind.
Argeebee is found here.
http://www.webschuur.com | http://bler.webschuur.com
Here's my 2 cents for what it's worth
I think drupal is the best CMS around!
And I agree with everyone that thinks design is separate from content... so I'm on board with you all there.
But, as a designer, I think we really sacrifice a lot when we compromise our layouts just so they'll be xhtml compliant or validated. I know that's the future, or so they say... but who's giving out awards for being xhtml compliant?
For me, if my client wants to pay the extra $$ and it's important to them to have a validated site layout, then I'll do it... but I'm not going to do it just to get brownie points with all the xhtml fan-clubs out there.
I think css and xhtml have a long way to go... I don't think the layout should be sacrificed just in order to make a site not use tables.
You can use styled tables where you're not doing any table formatting... it's all in the css... but you do use the table as a way to layout the page.
I do both... it just depends on the project.
If I can pull it off in xhtml/css/non-tables, then I'll do it... but once the design starts looking stupid or something isn't possible because it's not working without tables... I let the design take front seat and go back to using tables.
I know everyone is gonna hate me for saying all that :) but aren't you all tired of seeing all these sites that look like blogs and not like anyone really thought much about the design?
I think sites can and should be designed without thinking about the xhtml/css... they can be designed in photoshop and show your clients a PSD file...
Then... make it work one way or another... tables, divs, whatever... the design is the lead... not the xhtml.
And I'm not talking about building sites that only work in one browser etc...
Anyway... that's my 2 cents for what it's worth. :)
-Jeff
the bigger picture isnt pixel perfect
compliance assures you the best possible access from all browsers across all devices; be it a browser on a PC or TV screen, or a WAP browser like a PDA, or cell phone. this is not just nice to have, but in the case of disabled users a requirement.
why is that important? legal rights of disabled users. what does that mean to a developer/designer?
how about this for a test case? Class Action Lawsuit: Blind people vs. Target.com or you can search google for current news on the case.
Look at it this way: How is accessibility in website design (web designer) different than building design (architect)?
Your two cents might get you into the losing end of a class action law suit.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
RAW Project
I have been putting together a number of layouts for people to hack around with. I intend to build them for those who are new to theming since it can be a daunting task to get their brain Drupalized in PHPTemplate. Essentially, I am building some templates that are completely empty - waiting for experimentation and play.
A few notes:
Feel free to send me some comments, bugs, requests, etc. Hope they help someone and I will be making more in the coming months.
http://www.drupal.org/project/raw
Tables ? I'm wondering ...
But in fact, some people think that using tables for a long time led us to think our designs only as tables, and this is a wrong way of designing. The tables are in fact in our heads.
http://alistapart.com/articles/outsidethegrid
That's why I'm trying to get rid of tables too.
No, tables have nothing to
No, tables have nothing to do with HTML tables, it is simply the easiest way to produce a grid layout. Grids have been used for text layout for thousands of years. I wrote an article about why CSS works against common designer sense:
http://www.jakob-persson.com/node/477
Jakob Persson – Leancept – Results-only digital and marketing consultants – Personal blog
Long discussion. Here's an
Long discussion.
Here's an on topic suggestion for Mir:
I have been using LayoutGala's CSS templates with good results. (http://blog.html.it/layoutgala/)
Good cross-browser compatibility and unlike other CSS templates out there, you can keep your XHTML and----- only change the CSS to go from one column to three, from fixed to fluid. Big wow, eh?!
My 2 cents on the tables / CSS: I surf a lot on my Palm when commuting, putting my daughter to sleep etc, and that ain't fun with table based designs, I'll tell you! Imagine then being blind and having to use a screen reader or braille reader!
Have a look at your table based site in Lynx or another text browser and you get an eye opener.
Valid XHTML and CSS can serve everybody. Not just people with standard browsers on standard computers.
Cheers!
Ayza
Some new ideas about variables
I'm still hard at work trying to get my layout to perform the way I want it to...
Thanks to everyone who weighed in. If someone who edits this site could perhaps cross post thisthread to the Theming & design in Drupal group I'd appreciate it.
Some of what's been discussed has really got to go into a best -practices development time-line document for people learning to build on Drupal.
As a designer - I agree that using the photoshop to final product route can ultimately cause a lot more frustration than the aesthetics are worth.
However, I think Drupal has got learn to play nice with the people. I am now in the process of doing exactly what Bér suggested, making my own site so i can figure out Drupals functionalities without costing my client or myself any money. I am finding that in comparison to my old MT blog engine it's way difficult to do some of the most simple stuff imaginable.
So yeah maybe it's easier to code a $content variable but it's not that easy to style your site or to make a blog that has all the excellent bells and whistles I want.
It would be nice to provide three $content variables, lets's say; $featurecontent $content or $teasers. So the feature is whatever content you want people to see a lot of (extra-long teaser, image in post by default) . The regular content is whatever, in oldschool newspaper speak, appears below the fold, (not as important as feature however still in or close to browser window on page load). $teasers is anything promoted to front but not featured or content - that could be all the blog posts for that week for example.
In the content type or in the creation page site-admins can specify whether or not content appears as a feature or as a content or as a teaser - or even better, admins could say all blog entries only appear as teasers on the front page, while new pages or new book pages or new stories can be classed feature or content.
These kinds of negototiation between design and content management could offer a little more flexibility in page design so that we could start making sites that don't immediately look "Drupalish"
I mean, I've basically done all the above in various projects, but using flexiblocks, and flexinodes, and views, etc..It would be a lot easier if I could just use a couple of new variables instead of three modules and a bunch of code in my template.php file.
Sorry it took me soo long to re-join the conversation I was on vacation/ at a conference....
re: adding an inner column structure to the main area of thes site;
I did try an experiment with creating two columns in the main area and got complaints that splitting up the content that way made it difficult to read, I think I had my floats going right though, left floating things might have made it easier. But, basically I think people have been trained to scroll down for a linear, time-based version of site -events.
question on differences
howdy,
I'm not really qualified to answer your other comments, but I have a question on this:
Can you enumerate some of those? Feel free to contact me directly or start a new thread and point me to it if you'd prefer.
Thanks!
--
Growing Venture Solutions
Drupal Implementation and Support in Denver, CO
knaddison blog | Morris Animal Foundation
I'm coming in late here, but
I'm coming in late here, but now on my 3rd completely and utterly different and rather large drupal build within 3 months--1 a variation of garland to learn, 2 with absolutely no relation to anything even akin to a 'normal' drupal theme--and a big background in site design in general, I'm squarely in Ber's camp.
I've played with the YUi and other grids, and while nice for fast, purely large scale arrangement of data, they create many shortcomings. In particular, if you work any with screen readers, 508 access, etc, you can provide many clues based on placement and logical division of names. Grids to me are a sort of next round evolution of divitis, convoluting pages and adding code, but for no net effect other than a little faster baseline for smaller sites and layouts.
Take for instance, a common setup I see in my divs:
header main-nav page-wrapper (which has an anchor so that you can skip from the page load to the content) toolbar (think extras which are relevant to page content) sidebar (whiz bang features which arent so relevant or lost by page content if say view port is small) content footerNow in css, and I'll admit a lot of practice, I can get these to lay out in just about any order or way in columnar shape and size I want (yes, even painfully, for IE6). And then within each sidebar or toolbar I would have elements for sub-menus, lists, most recent posts, etc.
Now in general, the page template allows me to at least structure a lot of this just fine and dandy. I do have to keep a little mental note every time that Drupal prefers only sidebar-right and sidebar-left. I also have had to add a bunch of template exceptions in the block and node level for styling and overriding naming which to me should be a core feature for every dang block and module from the core setup, not just something which is 'entrusted' to modules and addon writers to be thorough and consistent about.
The funny thing is, I can get my same ultimate layout identifiers and goals with views, some addon modules and fields, or I can do (for me anyway) quicker exception lists in the page.tpl.php directly and save a lot of time.
Either way, I think we need to make sure the core Drupal construction is flexible and does not lock users into a single required theme setup which necessitates convoluted workarounds. So this discussion for how to handle css and semantics as well as being mindful of other frameworks (whether php/js/other cms publishing kits) is a good one to have for how much effect it could have on D7 even if not D6 so much now.
I think ideally in my world, I'd much rather Drupal focus on defining the functions of a module or block and provide base meaningful names for everything, but let all of them be as equally overridden so that these same blocks can be meshed into any naming/framework schema necessary. Even if that requires a slight abstract layer so that basic functions in drupal which might require a syntax connection can exist should the naming change (think ajax and other js functions in particular).
Otherwise I'll stay clear of the tables vs divs b/c I can get worked up about it ;) . But I can say, having worked at some rather large content providers, the bandwidth savings alone with divs over tables will make a huge impact on integration choices as Drupal grows. You'd rather add a couple somewhat less semantic content wrappers than add the entire structure of a table simply to move a column over...
**Michael
There are three possible roads to ruin-women, gambling and technology. The most pleasant is with women, the quickest is with gambling, but the surest is with technology.
Atlanta, GA USA