Forum Moderators: not2easy
Does it not simply keep the excess code in the HTML and also then add to the CSS?
YUI Grids [developer.yahoo.com]
Deeper NestingYou can nest grids within other nested grids to create more columns.
Here is an example of deeper nesting to create four columns.
In the markup below, be sure to note two things.
First: If the direct child of a grid is itself a grid,
it need not be within a unit; in this case
grids behave as units.
Second: Be sure to denote the "first" of each set:
1...
2<div id="yui-main">
3 <div class="yui-b">
4 <div class="yui-g">
5 <div class="yui-g first">
6 <div class="yui-u first"></div>
7 <div class="yui-u"></div>
8 </div>
9 <div class="yui-g">
10 <div class="yui-u first"></div>
11 <div class="yui-u"></div>
12 </div>
13 </div>
14 </div>
15</div>
16...
that code offers nothing more than tables, in fact it's worse, you have to go into the HTML to change those classnames.. and what the heck do they mean, very unsemantic!
Yes you get a nice big stylesheet covering all options but in order to change an option/layout you go into the html and change a classname.. what's up with that?
[Sample classnames from blueprint's grid.css [files.bjorkoy.com]]
/* Use these classes to set the width of a column. */
.span-1 { width: 30px; }
.span-2 { width: 70px; }
.span-3 { width: 110px; }
.span-4 { width: 150px; }
.span-5 { width: 190px; }
.span-6 { width: 230px; }
.span-7 { width: 270px; }
.span-8 { width: 310px; }
.span-9 { width: 350px; }
.span-10 { width: 390px; }
.span-11 { width: 430px; }
.span-12 { width: 470px; }
.span-13 { width: 510px; }
.span-14 { width: 550px; }
.span-15 { width: 590px; }
.span-16 { width: 630px; }
.span-17 { width: 670px; }
.span-18 { width: 710px; }
.span-19 { width: 750px; }
.span-20 { width: 790px; }
.span-21 { width: 830px; }
.span-22 { width: 870px; }
.span-23 { width: 910px; }
.span-24 { width: 950px; margin: 0; }
What say you, are grids useful as a start off or leading to a whole new slew of abuse and misunderstandings
-Suzy
Just my 2 cents on that matter.
Brandon
CSS just isn't designed for this, yet. In other ways, it's more flexible than tables, right now.
But a table can follow height. And that's an oversight in CSS.
>>But a table can follow height. And that's an oversight in CSS.
we're not chatting about one versus the other in this discussion
I'm simply wondering why is adding all those non-semantic divs and classes to the HTML, any better or worse than abusing the table, tr, and td HTML elements for layout in the first place?
[edited by: SuzyUK at 12:44 pm (utc) on Mar. 23, 2008]
Ideally you'd have a structure appropriate to the content - without the css. That's why it's useful to use the web toolbar in FF, which is an addon download, to switch off css. I think you can do it in Firebug, too.
A layout may often have to 'stretch', but then CSS doesn't easily allow the rest of the layout to stretch with it, as we've seen in these recent 'challenges'.
In other words, the complaint had been that 'we need' css to separate out that awful 'presentation' that people were always stuffing into tables. And then when they do come up with css, there's no alternative to what tables can do, in various ways.
The present css way is to rely upon the HTML. It relies on HTML for presentation structure. It's needed to establish the hierarchies, basically the relationships. You cannot say, attach elements of this class to the left side of that class. That information is contained in the structure of HTML. And I wonder if css shouldn't be set up to specifically starting attaching and aligning elements by selector, regardless the hierarchy in the HTML?
Specifically attaching elements to other elements.. I feel browser-specific troublemakers scream with pleasure on the thought of the horrors we can expect there.. Padding, border, margin; ie the padding holds the aligned element off, FF removes the padding, while NS goes the middle way brrr..
But I do not think there is a problem to rely on html to do the structural work for us. Isn't it logical to have a solid basic structure for your data, and you start adjusting, formatting and shifting that with the CSS?
my 2P
Ideally you'd have a structure appropriate to the content
agreed, that is the principle behind marking up your document (HTML) without its presentation being known. Structure the content into logical divisions in the markup sure.. and yes turn CSS off to make sure the document makes sense.. but there's more, these grids (or CSS Layouts on a plate) are expecting the layout template programmers, not Designers to "know" where in the HTML you need to add the classes. That to me is exactly the same as the 'tables way because it's easiest' relies on template programmers at present knowing where to insert table cells, rows colspans etc.. but more importantly as I'm wondering just now - isn't that the joining together of presentation and content all over again?
But I do not think there is a problem to rely on html to do the structural work for us. Isn't it logical to have a solid basic structure for your data, and you start adjusting, formatting and shifting that with the CSS?
Hi jelle, again in the same vein as above I agree, but what is the document structure and what is the design "structure" in the HTML above? - aren't these grids attempting to get us to put design "limitations" back into the HTML code - I see no document structure e.g. <headings> paragraphs etc.. in the above HTML, and I also would have to know which yui- class was needed where during the markup process.. presuming that is I even knew which of the many classnames I needed at that time!
and this:
You can nest grids within other nested grids to create more columns.
does that not remind anyone on those previous nested nightmares?.. i.e. you have to know more then about the document structure to successfully apply the grids.css?
that's the reason for my questions I suppose just trying to find out if this type of CSS Layout is a help to the CSS way of thinking or a hindrance..
although I'm horrified at all those unsemantic CSS classes :o
[edited by: SuzyUK at 2:28 pm (utc) on Mar. 18, 2008]
If that ordering is a part of the content, it would necessarily have to do so. If you lose the ordering, you lose part of the information.
But in keeping things together, obviously it lends itself to 'meta' layout. And this is what people want. A grid is something css could easily provide. But it doesn't. And floating boxes in left is going to cause some jam-ups. One could align pixel by pixel. But that's putting something the computer can do into the hands of the designer/programmer, and is a HUGE step backward. The alignments people now use go hand in hand with their table layouts. The styling and tables go right together and require each other.
are grids useful as a start off or leading to a whole new slew of abuse and misunderstandings
My two cents......tables were created to present tabular data to a user. divs were created to divide the page up.
HTML + CSS still isn't perfect, but if we are going to move to a place where standards are followed and where one CSS statement has the same effect no matter what browser/OS combo then we need to all be using HTML+ CSS the same way..... HTML and CSS can be perfect.
So it isn't that tables are bad for layouts... they just simply weren't meant for it, Divs were, and so I will try to use them as they were intended.
Again are table based layouts bad? I don't think so but I am trying to keep my HTML strict and keep to the standards in the hopes that one day we won't need tables for layouts.... not because they are bad, but because that just isn't what they were meant for.
[edited by: Demaestro at 9:44 pm (utc) on Mar. 18, 2008]
E.g. using "divs" to replace "tables", it just isn't the solution either.
Getting the layout of the the HTML is much more important than getting rid of tables. (the tables will go on their own)
I didn't really love the other solutions for relative font sizes...but am I taking too much of a shortcut?
Yes you get a nice big stylesheet covering all options but in order to change an option/layout you go into the html and change a classname.. what's up with that?
I've built my own CSS framework from all the work put into Blueprint. Using a Javascript utility I can consolidate those messy html style classes into one id or class. Which means, to me, there really is no drawback to using a grid system.
As for table layouts? Well if you can't do it cleanly using divs then, I'm afraid you're obsolete. :(
PS: I can post a link to my latest release version but, I'm not sure about link policies on this forum...
It's not possible, at this point, to produce tables with css. Stylesheets aren't designed for that. You can stacks divs. You can mimic tables, in some circumstances.
Of course html and css go together. But specifically so do tables and css. Tables seem to be the issue. The styles can fix your elements, could probably put an auto-resizing frame around the viewport, if desired. But a div can be pushed on all sides, yes. But it won't expand to its neighbor, or even necessarily even stay in the text flow. It will move. It won't stretch, forcing fixed dimensions to be used which defeats the purpose of floating layout for various web device, small screen to large.
If css can incorporate the idea of stretching right, left, top and/or bottom, and can include parameters to optionally flow text and stretch other elements even if to elements that are positioned absolutely, it could help remove the 'layout' structure from html, and leave it more in the way of simply xml.
topic reminders..
"Grids" or "Blueprint" CSS seems to be the easy way to "get" CSS layouts for those making the transition to CSS Design but is it right?
What say you, are grids useful as a start off or leading to a whole new slew of abuse and misunderstandings
if this thread goes of topic too, like some other recent ones I'll have to get out my axe again ;)
I agree with Dave75 in that if you can't do CSS layouts, or give it CSS's best shot at this time then you may well be obsolete and I suppose at least 'grids.css' would allow you to keep prospective employers who demand a tableless layout happy, it will also allow you to build popular CMS themes?
I like the idea of using it, grids.css, as the framework to build the layout and then compressing the stylesheet later..
[edited by: SuzyUK at 5:28 pm (utc) on Mar. 21, 2008]
I like the idea of using it, grids.css, as the framework to build the layout and then compressing the stylesheet later..
Me too. Using a CSS framewrok w/ grid system has reduced my layout styling time from 3-4hrs to about ten min. About two months ago I was about to design 40 complete webpage interfaces over the course of about 16hrs.
[edited by: SuzyUK at 9:50 am (utc) on Mar. 23, 2008]
[edit reason] snipped off topic quote [/edit]
I didn't really love the other solutions for relative font sizes...but am I taking too much of a shortcut?
I don't think you would be taking too much of a shortcut if all you want is to plug and go in order to get on with site content - it is simply a choice - floats are not perfect for layout either. If you actually want to learn how floats and/or CSS+P do work you can still learn while using grids, you can reverse engineer them - and IMHO as long as you don't start to think that Yahoo's version is how CSS or rather its coding practice is meant to work you'll be fine :)
honestly.. there's not meant to be all those presentational classnames in the HTML nor is the stylesheet meant to have separate class names for each property:value, this shortcut to tons of layouts could very well make people believe this is how CSS actually works.. which is what I mean about future abuse/misunderstanding ;)
>>misunderstandings..
hehe I wonder if people will in a few years time be shouting at Yahoo for encouraging bad coding practice or 'inventing' "div and CSS abuse" :o
1. If I use relative font sizes, with that 62.5% trick to make 1em~=10px, does that work pretty well cross browser or are there issues w/ different browsers seeing different sizes?
2. Are there "source ordered content" layouts that are properly formatted? Or do they also use tricks like Yahoo does with it's classes?
1. If I use relative font sizes, with that 62.5% trick to make 1em~=10px, does that work pretty well cross browser or are there issues w/ different browsers seeing different sizes?
works pretty well, but old schoolish if you expect 62.5% to = 10px = 1em, not all browsers have a 16px default (62.5% of 16px = 10px in a default world) and 1em is also based on the size of the letter "m" in your chosen font, not all users will have the same default font and not all may have your default choice available on their system see recent topic [webmasterworld.com] but as a rough guideline it's OK!
2. Are there "source ordered content" layouts that are properly formatted? Or do they also use tricks like Yahoo does with it's classes?
there is a very good source of SOC layouts (40+) which can use the same basic HTML and no tricks just good old fashioned maths! in fact the layouts are "trick free" and I have the 'inside' knowledge that would make them virtually IE proof too seeing as how I built a virtually identical one, and have learned their foibles ;).
update: check out "Layout Gala" - sorry couldn't find it earlier it's not the same site I had bookmarked :o
-Suzy
[edited by: SuzyUK at 4:05 am (utc) on Mar. 28, 2008]
You just learn how to be a C&P coder. You don't understand why one thing is better than another. And you won't learn it.
These prepackaged things are for people to not have to know. They don't have to learn, that way.
I hate to say it, but back in my day... we learnt it all the hard way and tried and failed and tried and failed and tried and succeeded...
Having said that, I think it's fine to use such stock code if you know exactly what it's doing and how to stop it from doing the bad (or at least unnecessary) things.
Stock code like Yahoo Grids are built for every situation -- problem is, you only need it for one situation each time.
</2c>
These prepackaged things are for people to not have to know. They don't have to learn, that way.I hate to say it, but back in my day... we learnt it all the hard way and tried and failed and tried and failed and tried and succeeded...
This is probably where the 'abuse' issue SuzyUK raised comes from. I strongly believe that before you use a framework for any language you should already have a solid understanding and reasonable experience coding with it. Frameworks are not educational shortcuts, they are production shortcuts.
As for semantic markup. I used to be a standardista. Now I focus on value. If the site is accessible and usable then it will necessarily be more valuable than a semantic site that is not as usable and/or has accessibility issues.
For me, these basic 'abuses' come mostly out of technical ignorance, not from the design and implementation process.
