World: r3wp

I don't know what it is about doing table-free designs, but I personally 
think it's damn hard to do. You have some parameters that you can 
adjust for CSS that are cryptic and difficult to guess how the layout 
will be. With a table, you have cells, adjustment, width and many 
predictable elements. I think it's because CSS is underpowered for 
what it's meant to do, and the ability to separate design from content 
(desktop vs. phones) is a tad overrated, if it just makes site design 
and construction that much harder.

Agreed with Henrik.  If you aren't expecting the site to be on mulitple 
end-user hardware platforms and not expecting drastic user customizable 
styles, I don't see the need to avoid tables for the layout.  CSS 
just for the fine-tuning.

thanks. I can see e.g. big portals like  our local http://www.idnes.cz
using almost plain CSS. I noticed it on my cell phone, when FUP applied. 
The html is one long page, which then gets distributed around the 
site upon the CSS, once it is loaded ....

There have been close to holy wars between the CSS purists and those 
who use tables for everything. The best position is one that balances 
the needs and priorities of your website and development team's aptitudes.

Here'ssome arguments for as few tables as possible for layout purposes 
(it's taken for granted that tables are good for tabular data):

http://www.chromaticsites.com/blog/13-reasons-why-css-is-superior-to-tables-in-website-design/

thanks ....

Of all these points, perhaps accessability is the only valid reason 
for not using tables. If you know how to use CSS and DIVs to produce 
table-like results, fine. But it's ridiculous to assume that CSS/DIVs 
are the main bandwidth hogs for webpages. Sorry, not buying that.

sorry: "But it's ridiculous to assume that CSS/DIVs are the main 
bandwidth hogs for webpages.", should be: "But it's ridiculous to 
assume that tables are more of a bandwidth hog than CSS/DIVs for 
webpages."

Depends to what degree you use html to define visual aspects.  The 
comparison above is talking old school page design where your markup 
contains all the bgcolors, widths, font colours, etc. (FrontPage-esque) 
 Typically this approach does significantly increase page size.  
Using tables mainly as an alternative to <div> as a way to divide 
up page components in an otherwise CSS driven design isn't going 
to be at all costly in comparison.  Actual bandwidth cost I guess 
is case specific.

I'd possibly consider myself a CSS 'purist' - I like that it encourages 
a language oriented approach to page/site design (not a language 
of Rebol's calibre, indeed, but a nod in that direction : )   The 
trade off can be in the complexity in implementing layout, but really 
there are few patterns that have not been mapped out.

I use tables to presend data that belongs into tables and where it 
makes sense. I didn't use tables for general layout in a long time. 
I am not any purist but I find other ways much better than tables 
for this. It can make quite messy code and they don't degrade well 
to smaller screens.. etc..

basically tables don't presend the "information structure" of the 
site well, that is why they don't degrade well, cause problems to 
screen readers.. etc

I'll go with table free design for layout. I talked to few ppl and 
most don't use table for layout anymore ...

http://www.kalzumeus.com/2009/09/05/desktop-aps-versus-web-apps/

the web is a good distibution system... its just about all it really 
does pefectly... and that's the only thing it was designed to do.


I don't agree that web programming itself is easier, unless you really 
are doing easy apps.  


IMHO Rich clients are the best of both worlds combined into one seamless 
experience

I use mix of tables and CSS for layouts:) I don't remember exact 
cases now, but I had problems to do some layouts with just CSS (working 
not just in one browser).

There's also a page at 37signals.com advocating for web-based software 
: http://37signals.com/webbased

One of the advantage listed is : "You’ll never have to ask “Is it 
compatible?”"...good joke:-)

Curiously I find you have to ask that quite often. Still so many 
IE users around.

welll all browsers render stuff differently, chrome FF and safari 
included.

few different pixels here or there never mind :-)

Any one looked at webkit, code-wise?  I mean, using, has used, tried 
to use it, participating in it, anything.

http://webkit.org/

(webkit is the engine powering chrome and safari, if you wonder)

On OSX you can use like every other library. Fully available via 
objective-c interface.

Interesting pov onto website creation - http://24ways.org/2009/make-your-mockup-in-markup

I don't get it... I've always built websites like that. Using a paint 
program to do it is just impossible. :-)

my friend works the opposite way - design proposals are done in Photoshop, 
then he cuts it into the markup .... (sometimes wondering it "feels" 
differently to what he originally did in Photoshop :-)

I've once worked with this process of first having a designer building 
mockups in photoshop, then they were moved to Dreamweaver and I had 
to "graft" javascript on top of it, and whenever the designer made 
a change, I had to start from scratch. The customer demanded to see 
the site in full function. We moved so slowly, the project was dropped 
after a few months. 


Another time, I finished the project, but it took so long to do, 
because the design was nearly impossible to convert to HTML/JS. That 
was 5 years ago.

And people are just realizing this now?

Isn't the WHOLE thing simply insane?  After all these years, there 
is not a tool that allows both programmers and artists to work on 
the SAME data?  All strange...

Xara pretends to be such a tool, but otoh I did not found, how to 
easily adjust using code .....
http://www.xara.com/eu/products/webdesigner/features/

Many of the problems arise, because designers/developers/programmers 
try to make html do, what it wasn't supposed to do in the first place.


When making a movie, one might start out by drawing a storyboard. 
Later in the process, a camera is used to shoot some film, and in 
the end a story is told, that may or may not be close to the original 
storyboard. But it works, because the final output (images within 
a frame) is the same kind of thoughts that goes into creating the 
storyboard (images within a frame).


Designers think in the line of the final output, but html isn't wysiwyg, 
and the html technology might not be well suited for the ideas, the 
designer has. So problems arise. ... Or something. ;-)

I use Balsamico for my mock-ups. I like the tool a lot. And it can 
convert mock-ups to code via emitters.

Not tested yet but that's the right idea.

Balsamiq Mockups Robert ?

Yes, it's an ARI tool. Very nice and simple to use.

a better web is coming, just got this from google:

Dear Google Apps admin, 


In order to continue to improve our products and deliver more sophisticated 
features and performance, we are harnessing some of the latest improvements 
in web browser technology. ÊThis includes faster JavaScript processing 
and new standards like HTML5. ÊAs a result, over the course of 2010, 
we will be phasing out support for Microsoft Internet Explorer 6.0 
as well as other older browsers that are not supported by their own 
manufacturers.


We plan to begin phasing out support of these older browsers on the 
Google Docs suite and the Google Sites editor on March 1, 2010. ÊAfter 
that point, certain functionality within these applications may have 
higher latency and may not work correctly in these older browsers. 
Later in 2010, we will start to phase out support for these browsers 
for Google Mail and Google Calendar.


Google Apps will continue to support Internet Explorer 7.0 and above, 
Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 
and above.


Starting next week, users on these older browsers will see a message 
in Google Docs and the Google Sites editor explaining this change 
and asking them to upgrade their browser. ÊWe will also alert you 
again closer to March 1 to remind you of this change.


In 2009, the Google Apps team delivered more than 100 improvements 
to enhance your product experience. ÊWe are aiming to beat that in 
2010 and continue to deliver the best and most innovative collaboration 
products for businesses.

Thank you for your continued support!

Sincerely,

The Google Apps team

no more IE6 headaces 8-)

Interesting that Google will probably have more success in getting 
people to upgrade IE than MS! ;)

Hmm.... it's not google search though ..

People having trouble because facebook not the first google result 
for [facebook login]

   http://www.reghardware.co.uk/2010/02/12/google_de_facto_internet_gateway/

I'm creating a forum and using R3 CGI to output a page.  How do we 
send the Doctype to page?

Or rather how do we generate the DTD on output of the CGI

Simple PRINT the doctype before the HTML, eg
  print <!doctype html>
  print <html lang="en">
  print <head>
  etc

Yeah, I tried that.  Maybe I did something wrong.  I'm going to try 
that again.

If you look at the source of www.rebol.com you can see it done as 
simply as possible.

Alright I had done this before but it must be something broke with 
the div centering.

finally I got it to work!!!

IE8 required the DTD spec in order make the div center.

looks good on Chrome also.

Yeah, IE has different ideas on when to go to quirks mode.

Yeah I couuldn't figure out why I couldn't get the main container 
div to center on IE8.  Kept messing with it and then read where you 
had to declare the DTD for it to center.

I was going crazy because Chrome was centering it just fine.