www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - New home page

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.digitalmars.com

Yes, I should add some color and style sheets, but at the moment I am just 
trying to get the layout right and make it much simpler to get to what I think 
are the most useful links.

Comments welcome.
Oct 03 2010
next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
On 2010-10-04 7:09, Walter Bright wrote:

 http://www.digitalmars.com

 Yes, I should add some color and style sheets, but at the moment I am
 just trying to get the layout right and make it much simpler to get to
 what I think are the most useful links.

 Comments welcome.


The new page loads terribly slow because of some embedded resource from 
twitter.com. Twitter is blocked in China, so when I open your website 
nothing is shown until the connection to twitter times out. Perhaps you 
can use XmlHttpRequest in javascript to load the twitter stuff on the 
'background'?
Oct 03 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Lionello Lunesu wrote:

 The new page loads terribly slow because of some embedded resource from 
 twitter.com. Twitter is blocked in China, so when I open your website 
 nothing is shown until the connection to twitter times out. Perhaps you 
 can use XmlHttpRequest in javascript to load the twitter stuff on the 
 'background'?


The previous page had the same javascript in it. I don't know how this one
could 
load slow and the previous one not.

Can you post a diff for how to change the html to load in the background?
Oct 03 2010
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 04/10/10 03:59, Walter Bright wrote:

 Lionello Lunesu wrote:

 The new page loads terribly slow because of some embedded resource
 from twitter.com. Twitter is blocked in China, so when I open your
 website nothing is shown until the connection to twitter times out.
 Perhaps you can use XmlHttpRequest in javascript to load the twitter
 stuff on the 'background'?


 The previous page had the same javascript in it. I don't know how this
 one could load slow and the previous one not.

 Can you post a diff for how to change the html to load in the background?


Rather than getting the JS to load it in the background, the lazy option 
is to move the two <script> tags to the bottom of the html before 
</body> rather than before </head>. Browsers will block rendering of the 
page if it encounters a script tag until the script has been loaded - by 
placing them at the end the page will be rendered, followed by loading 
the scripts.

Alternatively you could use the HTML5 attributes with the script tag to 
make the scripts load in the background regardless, I don't know what 
browser support is like for this though.

-- 
Robert
http://octarineparrot.com/
Oct 04 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Robert Clipsham wrote:

 On 04/10/10 03:59, Walter Bright wrote:

 Lionello Lunesu wrote:

 The new page loads terribly slow because of some embedded resource
 from twitter.com. Twitter is blocked in China, so when I open your
 website nothing is shown until the connection to twitter times out.
 Perhaps you can use XmlHttpRequest in javascript to load the twitter
 stuff on the 'background'?


 The previous page had the same javascript in it. I don't know how this
 one could load slow and the previous one not.

 Can you post a diff for how to change the html to load in the background?


 
 Rather than getting the JS to load it in the background, the lazy option 
 is to move the two <script> tags to the bottom of the html before 
 </body> rather than before </head>. Browsers will block rendering of the 
 page if it encounters a script tag until the script has been loaded - by 
 placing them at the end the page will be rendered, followed by loading 
 the scripts.


Done. Good idea!



 Alternatively you could use the HTML5 attributes with the script tag to 
 make the scripts load in the background regardless, I don't know what 
 browser support is like for this though.
Oct 04 2010
parent Lionello Lunesu <lio lunesu.remove.com> writes:
On 5-10-2010 2:33, Walter Bright wrote:

 Robert Clipsham wrote:

 On 04/10/10 03:59, Walter Bright wrote:

 Lionello Lunesu wrote:

 The new page loads terribly slow because of some embedded resource
 from twitter.com. Twitter is blocked in China, so when I open your
 website nothing is shown until the connection to twitter times out.
 Perhaps you can use XmlHttpRequest in javascript to load the twitter
 stuff on the 'background'?


 The previous page had the same javascript in it. I don't know how this
 one could load slow and the previous one not.

 Can you post a diff for how to change the html to load in the
 background?


 Rather than getting the JS to load it in the background, the lazy
 option is to move the two <script> tags to the bottom of the html
 before </body> rather than before </head>. Browsers will block
 rendering of the page if it encounters a script tag until the script
 has been loaded - by placing them at the end the page will be
 rendered, followed by loading the scripts.


 Done. Good idea!


Works!
Oct 04 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Lionello Lunesu" <lio lunesu.remove.com> wrote in message 
news:i8bf68$s54$1 digitalmars.com...

 On 2010-10-04 7:09, Walter Bright wrote:

 http://www.digitalmars.com

 Yes, I should add some color and style sheets, but at the moment I am
 just trying to get the layout right and make it much simpler to get to
 what I think are the most useful links.

 Comments welcome.


 The new page loads terribly slow because of some embedded resource from 
 twitter.com. Twitter is blocked in China, so when I open your website 
 nothing is shown until the connection to twitter times out. Perhaps you 
 can use XmlHttpRequest in javascript to load the twitter stuff on the 
 'background'?


Works fine with JS off.
Oct 03 2010
parent reply BCS <none anon.com> writes:
Hello Nick,


 "Lionello Lunesu" <lio lunesu.remove.com> wrote in message
 news:i8bf68$s54$1 digitalmars.com...
 

Twitter is blocked in China, so when I open your
 website nothing is shown until the connection to twitter times out.


 Works fine with JS off.


are you in china?

 
-- 
... <IXOYE><
Oct 03 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff1d6668cd315bbe9b6d30 news.digitalmars.com...

 Hello Nick,


 "Lionello Lunesu" <lio lunesu.remove.com> wrote in message
 news:i8bf68$s54$1 digitalmars.com...


Twitter is blocked in China, so when I open your
 website nothing is shown until the connection to twitter times out.


 Works fine with JS off.


 are you in china?


The twitter access is done through JS, so without JS the page does jack-shit 
with twitter (the way all the internet should be if you ask me, JS or not). 
And the rest of the page works fine without JS (which is not something 
that's going to be affected by region), so it doesn't matter where I'm 
looking from: It's works fine with JS off...Unless the browser is stupid 
enough to actually try to load external scripts when JS is off...
Oct 04 2010
parent reply BCS <none anon.com> writes:
Hello Nick,


 "BCS" <none anon.com> wrote in message
 news:a6268ff1d6668cd315bbe9b6d30 news.digitalmars.com...
 

 are you in china?
 


 Unless
 the browser is stupid enough to actually try to load external scripts
 when JS is off...


1) You are assuming some third party isn't an idiot. I wouldn't usually bet 
on that one.
2) there could be some sort of CSS/img/etc. component to it that doesn't 
get ignored.

Point being that the whole web is so stinking complicated the only way to 
tell what the effects of blocking something are is to block it and see.

-- 
... <IXOYE><
Oct 04 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff1d6c58cd31a68901b792 news.digitalmars.com...

 Hello Nick,


 "BCS" <none anon.com> wrote in message
 news:a6268ff1d6668cd315bbe9b6d30 news.digitalmars.com...


 are you in china?


 Unless
 the browser is stupid enough to actually try to load external scripts
 when JS is off...


 1) You are assuming some third party isn't an idiot. I wouldn't usually 
 bet on that one.


Good point.


 2) there could be some sort of CSS/img/etc. component to it that doesn't 
 get ignored.


I checked the page source. Outside of actual JS code, the only reference to 
anything at twitter is one external JS file reference. And there's no 
external CSS files referenced.


 Point being that the whole web is so stinking complicated the only way to 
 tell what the effects of blocking something are is to block it and see.


Fortunately Walter's pages and nice and simple :)

You're probably right that I can't be 100% certain. But I'm fairly certain 
about it, at least aside from the question of browsers possibly loading JS 
files when JS is off. And regarding that:

I've just done a little test in FF2: I have JS turned off via NoScript, I 
cleared the cache, and used the HttpFox extension to inspect the browser's 
HTTP behavior while loading http://www.digitalmars.com. These are the only 
URLs it reported the browser loading:

http://www.digitalmars.com
http://www.digitalmars.com/dmlogo.gif
http://www.digitalmars.com/download.png
http://www.digitalmars.com/library.png
http://www.digitalmars.com/news.png
http://www.digitalmars.com/buy.png

So at least in FF2 with JS disabled via NoScript, twitter doesn't get 
referenced by the client. Or at least if HttpFox is to be trusted, but I've 
never had a problem with it.
Oct 04 2010
parent reply BCS <none anon.com> writes:
Hello Nick,


 
 http://www.digitalmars.com
 http://www.digitalmars.com/dmlogo.gif
 http://www.digitalmars.com/download.png
 http://www.digitalmars.com/library.png
 http://www.digitalmars.com/news.png
 http://www.digitalmars.com/buy.png


where is favicon.ico?


 So at least in FF2 with JS disabled via NoScript, twitter doesn't get
 referenced by the client. Or at least if HttpFox is to be trusted, but
 I've never had a problem with it.
 


-- 
... <IXOYE><
Oct 04 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff1d7818cd320c5cd65b3a news.digitalmars.com...

 Hello Nick,


 http://www.digitalmars.com
 http://www.digitalmars.com/dmlogo.gif
 http://www.digitalmars.com/download.png
 http://www.digitalmars.com/library.png
 http://www.digitalmars.com/news.png
 http://www.digitalmars.com/buy.png


 where is favicon.ico?


I have favicons turned off. (I don't have anything against favicons. I've 
just come across a number of sites with animating (!!!) favicons (What is 
this? 1996?). And strangely, FF blatantly ignores my "never animate images" 
setting for favicons.)
Oct 04 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 I have favicons turned off. (I don't have anything against favicons. I've 
 just come across a number of sites with animating (!!!) favicons (What is 
 this? 1996?). And strangely, FF blatantly ignores my "never animate images" 
 setting for favicons.) 


Check out the lovely apple-touch-icon.png you get when you bookmark the site on 
an iPod!
Oct 04 2010
prev sibling next sibling parent reply Gide Nwawudu <gide btinternet.com> writes:
On Sun, 03 Oct 2010 16:09:15 -0700, Walter Bright
<newshound2 digitalmars.com> wrote:


http://www.digitalmars.com

Yes, I should add some color and style sheets, but at the moment I am just 
trying to get the layout right and make it much simpler to get to what I think 
are the most useful links.

Comments welcome.


I think the 'Download Now' link should be just 'Download' and should
link to http://www.digitalmars.com/d/download.html.

Gide
Oct 04 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Gide Nwawudu wrote:

 On Sun, 03 Oct 2010 16:09:15 -0700, Walter Bright
 <newshound2 digitalmars.com> wrote:
 

 http://www.digitalmars.com

 Yes, I should add some color and style sheets, but at the moment I am just 
 trying to get the layout right and make it much simpler to get to what I think 
 are the most useful links.

 Comments welcome.


 
 I think the 'Download Now' link should be just 'Download' and should
 link to http://www.digitalmars.com/d/download.html.


The 'Download more...' does link to that page. I was looking to make the 
'Download Now' work as directly as possible. The download.html has a rather 
large number of options.
Oct 04 2010
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 04/10/2010 00:09, Walter Bright wrote:

 http://www.digitalmars.com

 Yes, I should add some color and style sheets, but at the moment I am
 just trying to get the layout right and make it much simpler to get to
 what I think are the most useful links.

 Comments welcome.


The layout breaks in anything but the default text zoom.  Need to get 
rid of the mixed px/em sizes.  Instead, specify all the widths in %, and 
use another div within the div for padding.

Stewart.
Oct 04 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.  Need to get 
 rid of the mixed px/em sizes.  Instead, specify all the widths in %, and 
 use another div within the div for padding.


Good idea.
Oct 04 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


The annoying thing about this is everyone says "don't use tables for layout,
use 
CSS." Except that using CSS for layout DOESN'T WORK RELIABLY. With tables, I
can 
get 3 columns that are actually 3 columns, not 3 columns that are a side effect 
of bugs in CSS.
Oct 04 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 04/10/10 19:42, Walter Bright wrote:

 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 The annoying thing about this is everyone says "don't use tables for
 layout, use CSS." Except that using CSS for layout DOESN'T WORK
 RELIABLY. With tables, I can get 3 columns that are actually 3 columns,
 not 3 columns that are a side effect of bugs in CSS.


You shouldn't use tables for layout. There's nothing wrong with using 
tables for tabular data though... This said, I can't make my mind up 
whether the data seen there is tabular ;) I think most would argue not 
though.

As for CSS, it works perfectly reliably, once you know how to use it... 
Getting a 3 column layout or anything more exciting than content, menu, 
sidebar is a pain unless you're more experienced with CSS, takes a while 
to learn the tricks for it. Then, unless you're a web developer, you 
forget how to do it next time you need to :3

-- 
Robert
http://octarineparrot.com/
Oct 04 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Robert Clipsham wrote:

 As for CSS, it works perfectly reliably, once you know how to use it... 
 Getting a 3 column layout or anything more exciting than content, menu, 
 sidebar is a pain unless you're more experienced with CSS, takes a while 
 to learn the tricks for it. Then, unless you're a web developer, you 
 forget how to do it next time you need to :3


That's what bugs me. Something as straightforward as a 3 column layout
shouldn't 
require "tricks" for it. Googling it found 3 pages dedicated to explaining this 
"trick" (each of them wildly different, of course).

One of them was the one I used. Being a "trick", it apparently doesn't always
work.
Oct 04 2010
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-10-04 23:23, Walter Bright wrote:

 Robert Clipsham wrote:

 As for CSS, it works perfectly reliably, once you know how to use
 it... Getting a 3 column layout or anything more exciting than
 content, menu, sidebar is a pain unless you're more experienced with
 CSS, takes a while to learn the tricks for it. Then, unless you're a
 web developer, you forget how to do it next time you need to :3


 That's what bugs me. Something as straightforward as a 3 column layout
 shouldn't require "tricks" for it. Googling it found 3 pages dedicated
 to explaining this "trick" (each of them wildly different, of course).

 One of them was the one I used. Being a "trick", it apparently doesn't
 always work.


I think this site has good CSS tutorials: http://css.maxdesign.com.au/
Here is a tutorial for a liquid three column layout with a header and a 
footer: http://css.maxdesign.com.au/floatutorial/tutorial0916.htm

-- 
/Jacob Carlborg
Oct 04 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:

 I think this site has good CSS tutorials: http://css.maxdesign.com.au/
 Here is a tutorial for a liquid three column layout with a header and a 
 footer: http://css.maxdesign.com.au/floatutorial/tutorial0916.htm


Thanks!
Oct 04 2010
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 05/10/2010 06:51, Jacob Carlborg wrote:
<snip>

 I think this site has good CSS tutorials: http://css.maxdesign.com.au/
 Here is a tutorial for a liquid three column layout with a header and a
 footer: http://css.maxdesign.com.au/floatutorial/tutorial0916.htm


That's geared towards creating a layout with two fixed-width 
navigational columns and a central 'main' column.

What's wanted here is three equal columns, which is a quite different thing.

Stewart.
Oct 05 2010
prev sibling parent reply Arlo White <awhite calpoly.edu> writes:
That's because HTML/CSS is a pretty terrible language for anything 
beyond simple layouts. It shares more with Word/PDF/PostScript in terms 
of its purpose and history than it does with real gui layout engines 
(GTK, QT, etc).

Hardcore HTML/CSS people tout the virtues of separating the content from 
the presentation. The problem is that HTML has implicit presentation 
that you often can't override with CSS. There are limits to what you can 
do with positioning. If I want to rearrange elements in my page I have 
to change the HTML, I can't do it all on the CSS side. That's not 
separation of content from presentation!

Real separation of the presentation has to happen right at the data 
layer. But that's server side in most applications. So you run your data 
through one view abstraction (template language such as Freemarker, PHP, 
JSP etc), then to HTML, and then polish it with CSS. Oh, and that 
application runs on an app server that runs in a Java virtual machine 
that runs in an VMware OS that runs on a real OS that actually accesses 
real hardware. That's an absurd number of layers...

Anyway, to get back to HTML. They'll say use divs not tables because a 
table represents a distinct concept not a layout element and it has 
accessibility implications. And yet I you can't layout things with divs 
in the same way that I can with a table. And even if there are obscure 
CSS properties that let me, half the user's browsers don't support them.

Sometimes I feel like I'm the only one that sees the naked Emperor. 
People are so excited about the Internet but they don't realize that 
browsers are just implementing one view language that's 15 years old and 
really isn't all that great. The beauty of the Internet is the emergent 
properties that arose from the concept of linking sites. But that's not 
something that has to be unique to the HTML language itself.

And sure there's some cool stuff in HTML5 but a pig's still a pig even 
when you velcro a TV to its head and a database on its back.


-Arlo




On 10/04/2010 02:23 PM, Walter Bright wrote:

 That's what bugs me. Something as straightforward as a 3 column layout
 shouldn't require "tricks" for it. Googling it found 3 pages dedicated
 to explaining this "trick" (each of them wildly different, of course).
Oct 05 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Arlo White" <awhite calpoly.edu> wrote in message 
news:i8gem3$20al$1 digitalmars.com...

 That's because HTML/CSS is a pretty terrible language for anything beyond 
 simple layouts. It shares more with Word/PDF/PostScript in terms of its 
 purpose and history than it does with real gui layout engines (GTK, QT, 
 etc).

 Hardcore HTML/CSS people tout the virtues of separating the content from 
 the presentation. The problem is that HTML has implicit presentation that 
 you often can't override with CSS. There are limits to what you can do 
 with positioning. If I want to rearrange elements in my page I have to 
 change the HTML, I can't do it all on the CSS side. That's not separation 
 of content from presentation!

 Real separation of the presentation has to happen right at the data layer. 
 But that's server side in most applications. So you run your data through 
 one view abstraction (template language such as Freemarker, PHP, JSP etc), 
 then to HTML, and then polish it with CSS. Oh, and that application runs 
 on an app server that runs in a Java virtual machine that runs in an 
 VMware OS that runs on a real OS that actually accesses real hardware. 
 That's an absurd number of layers...

 Anyway, to get back to HTML. They'll say use divs not tables because a 
 table represents a distinct concept not a layout element and it has 
 accessibility implications. And yet I you can't layout things with divs in 
 the same way that I can with a table. And even if there are obscure CSS 
 properties that let me, half the user's browsers don't support them.

 Sometimes I feel like I'm the only one that sees the naked Emperor. People 
 are so excited about the Internet but they don't realize that browsers are 
 just implementing one view language that's 15 years old and really isn't 
 all that great. The beauty of the Internet is the emergent properties that 
 arose from the concept of linking sites. But that's not something that has 
 to be unique to the HTML language itself.

 And sure there's some cool stuff in HTML5 but a pig's still a pig even 
 when you velcro a TV to its head and a database on its back.


I seem to have met my doppleganger ;) Seriously, if I didn't know better I'd 
have to check the "From" line to know I hadn't written that myself.

Welcome to the Amish-of-programming club. We're small, but growing ;)
Oct 05 2010
prev sibling parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


HTML/CSS is primary made for documents not applications. If you want you 
can simply make every element a block level element and use JavaScript 
for layout. I don't know GTK and QT in depth but then you should have 
about the same level of possibilities as with these layout engines. It 
wouldn't surprise me if GUI frameworks like jQuery UI actually do this.

However the way GUI frameworks approach layout isn't very well suited 
for documents and therefore I'm very happy that they oriented CSS on 
documents (there were several early drafts and what we know today was 
just the draft from Howcome Lie).


 Hardcore HTML/CSS people tout the virtues of separating the content from
 the presentation. The problem is that HTML has implicit presentation
 that you often can't override with CSS. There are limits to what you can
 do with positioning. If I want to rearrange elements in my page I have
 to change the HTML, I can't do it all on the CSS side. That's not
 separation of content from presentation!


You can do quite a lot of stuff with the "position" property. As soon as 
you defined something as "position: absolute" you can move it around as 
you want. How well that (and other techniques) work depends on your HTML 
structure. However I have to agree that in most practical cases you have 
to modify the HTML in any way because the document structure changes.


 Real separation of the presentation has to happen right at the data
 layer. But that's server side in most applications. So you run your data
 through one view abstraction (template language such as Freemarker, PHP,
 JSP etc), then to HTML, and then polish it with CSS. Oh, and that
 application runs on an app server that runs in a Java virtual machine
 that runs in an VMware OS that runs on a real OS that actually accesses
 real hardware. That's an absurd number of layers...

 Anyway, to get back to HTML. They'll say use divs not tables because a
 table represents a distinct concept not a layout element and it has
 accessibility implications. And yet I you can't layout things with divs
 in the same way that I can with a table. And even if there are obscure
 CSS properties that let me, half the user's browsers don't support them.


Unfortunately this is true (if "half the user's browsers" refers to IE 6 
and 7). In other browsers however you can do exactly the same as with 
tables but with significantly less HTML elements ("display: table" 
property). Plus the other positioning models allow you to do things that 
are not possible with HTML. Netscape 4 once supported an "layer" element 
which could have been used to do stuff like you can do with "position: 
absolute" but the resulting HTML had nothing to do with "a document" any 
more.


 Sometimes I feel like I'm the only one that sees the naked Emperor.
 People are so excited about the Internet but they don't realize that
 browsers are just implementing one view language that's 15 years old and
 really isn't all that great. The beauty of the Internet is the emergent
 properties that arose from the concept of linking sites. But that's not
 something that has to be unique to the HTML language itself.

 And sure there's some cool stuff in HTML5 but a pig's still a pig even
 when you velcro a TV to its head and a database on its back.


 -Arlo


I have to agree that it's all about linking content that really created 
the web. It's not unique to HTML (I even saw thinks like that in "The 
mother of all demos" form Douglas Engelberth, 1968) but more to HTTP. 
HTML just happened to be wildly used to create documents on the web.

As for HTML5 still being a pig… well I definitely agree at some parts 
but they already cleaned up a lot. Just because the structure of C once 
was quite ugly (IMHO) doesn't mean that D is still ugly (since it's 
based on C). Technologies as well as taste evolve constantly.


 On 10/04/2010 02:23 PM, Walter Bright wrote:

 That's what bugs me. Something as straightforward as a 3 column layout
 shouldn't require "tricks" for it. Googling it found 3 pages dedicated
 to explaining this "trick" (each of them wildly different, of course).
Oct 06 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8i10k$2a86$1 digitalmars.com...

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications.


So true. That, combined with HTTP's stateless nature (and the exploit-prone 
nature of trying to build state on top of it), is why I view "web as a 
platform" as being little different from using PDF as an application 
platform. Heck, the PDF spec is so open-ended it could certainly be done.


 If you want you can simply make every element a block level element and 
 use JavaScript for layout. I don't know GTK and QT in depth but then you 
 should have about the same level of possibilities as with these layout 
 engines. It wouldn't surprise me if GUI frameworks like jQuery UI actually 
 do this.


Heh, layouts that magically break with JS off. Fun :)

I bet you're right though that something like that is out there on the web 
(or will be coming).

You know what's even weirder, though? (And I hope on not veering too far 
offtopic with this...) I've actually some across pages that will load 
perfectly fine with JS off, and *then* two seconds after loading it will be 
automatically replaced with a different page that says "This site doesn't 
work without JS." Ummm, yea, it obviously *did* work...I *saw* it work...


 You can do quite a lot of stuff with the "position" property. As soon as 
 you defined something as "position: absolute" you can move it around as 
 you want. How well that (and other techniques) work depends on your HTML 
 structure. However I have to agree that in most practical cases you have 
 to modify the HTML in any way because the document structure changes.


Unfortunately, as soon as you start using "position: absolute", you usually 
start causing problems for resize behavior. Unless you're using a 
static-width layout which is generally considered bad style (for good 
reason).

That's one thing I've noticed about CSS layouts that I think a lot of web 
developers tend to overlook. You generally *can* get what you want with CSS 
as long as you assume page width is always the same. But once you decide 
"web pages should be dynamic width" and try to make it look correct at 
different widths, that's when CSS *really* starts to break down. Tables tend 
to resize far better, and give you far better control over resize behavior.

For instance, try to make a resizable box with bit-mapped borders that 
behaves reliably (I've needed to do a lot of that for a client recently). 
Easy as pie with tables and CSS background images. But with anything else in 
CSS, I've become convinced it's just not possible.
Oct 06 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 07.10.2010 04:26, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8i10k$2a86$1 digitalmars.com...

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications.


 So true. That, combined with HTTP's stateless nature (and the exploit-prone
 nature of trying to build state on top of it), is why I view "web as a
 platform" as being little different from using PDF as an application
 platform. Heck, the PDF spec is so open-ended it could certainly be done.


Never read the PDF spec, but I don't believe that it includes a world 
wide network of web servers, does it? From an application developers 
point of view I have to agree, HTTPs stateless nature is a bit 
problematic at first. However as soon as it comes to scalability the 
stateless approach saves you from _a lot_ of trouble. I can't think the 
Internet could be what it is with HTTP being design to be statefull.

With the advent of REST people not look at HTTP a bit more and realize 
that there is more to it than GET and POST.


 If you want you can simply make every element a block level element and
 use JavaScript for layout. I don't know GTK and QT in depth but then you
 should have about the same level of possibilities as with these layout
 engines. It wouldn't surprise me if GUI frameworks like jQuery UI actually
 do this.


 Heh, layouts that magically break with JS off. Fun :)

 I bet you're right though that something like that is out there on the web
 (or will be coming).

 You know what's even weirder, though? (And I hope on not veering too far
 offtopic with this...) I've actually some across pages that will load
 perfectly fine with JS off, and *then* two seconds after loading it will be
 automatically replaced with a different page that says "This site doesn't
 work without JS." Ummm, yea, it obviously *did* work...I *saw* it work...


There is very much abuse or improper user of JavaScript in the Internet. 
Especially in the cooperate world where people usually don't have the 
time or are not willing to really understand the thoughts behind the 
tools they use (HTTP, HTML, CSS, JS). Business people are usually happy 
as long as it looks fancy. Even among professional web developers I 
don't know that many that really care much about the technical 
"correctness" of what they do. There are many ways to get the job done, 
who cares if it was a "right" one? (reminds me of a program I once hat 
to understand: it only used 8 global variables and lots of gotos… but it 
worked… and everyone was happy with it, except me).

Well, in the case to work with or without JS you have to make a 
distinction. A "document" should work all right without JS since its 
main purpose is to be viewed. However if you build a "real" web 
application in the sense of being more like a desktop application its 
almost a lost cause to make it work without JS. It will only cause a 
great deal of redundancy of code and an overcomplicated architecture. It 
is possible though if you really feel the need. However I would just 
stick to using JS and in conjunction with a REST interface. For a 
"application" this gives you a great deal of flexibility while still 
maintaining a simple architecture and good interoperability with other 
systems.


 You can do quite a lot of stuff with the "position" property. As soon as
 you defined something as "position: absolute" you can move it around as
 you want. How well that (and other techniques) work depends on your HTML
 structure. However I have to agree that in most practical cases you have
 to modify the HTML in any way because the document structure changes.


 Unfortunately, as soon as you start using "position: absolute", you usually
 start causing problems for resize behavior. Unless you're using a
 static-width layout which is generally considered bad style (for good
 reason).

 That's one thing I've noticed about CSS layouts that I think a lot of web
 developers tend to overlook. You generally *can* get what you want with CSS
 as long as you assume page width is always the same. But once you decide
 "web pages should be dynamic width" and try to make it look correct at
 different widths, that's when CSS *really* starts to break down. Tables tend
 to resize far better, and give you far better control over resize behavior.


Actually tables prevent you from reordering your elements according to 
page size but this limitation also affects other techniques. To be 
honest I use fixed with designs a lot. Usually I just don't have so much 
content that I have to use every part of the screen. ;)

A while ago it was more of a problem but since the zoom functions of 
browsers evolved a lot it's not that much of a problem any more.

However there are ways to build flexible layouts. Usually it's 
considered good practice to use the "em" unit (size of a X in the 
current font-size) for your dimensions instead of "px". It's quite handy 
and gives you the ability to resize the entire page by just changing the 
font-size of the body element.

Reordering of main page elements according to screen size used to be 
very tricky (some clever combinations of float and overflow). I never 
really did it on a project tough. Today you can just use [media 
queries][1] to define different layouts for different screen sizes and 
devices (this is also quite handy to define layouts printing or for 
mobile devices). There is plenty of material on the web about this and I 
regular use it to turn small documents into presentations (by defining 
styles for the "projection" media type which is used by Opera in full 
screen mode).

[1]: http://dev.opera.com/articles/view/safe-media-queries/


 For instance, try to make a resizable box with bit-mapped borders that
 behaves reliably (I've needed to do a lot of that for a client recently).
 Easy as pie with tables and CSS background images. But with anything else in
 CSS, I've become convinced it's just not possible.


Actually is pretty easy in CSS. I also had to do it a lot in the past. 
You just nest as many elements (usually divs) inside each other as you 
need background images. Then you use one of those divs to create the 
border for one side: just assign a background image to this side and a 
proper padding that makes sure only this side is visible. Corners are a 
bit tricky to do no problem if you make the main container "position: 
relative" and then position the corner divs with "position: aboslute". 
However for most of my layouts I found that I didn't need a variable 
height and therefore 4 divs where sufficient. This method had it's 
troubles for IE 5 but in IE 6 you shouldn't have much of a problem 
(maybe one bug, don't remember exactly).

On modern browsers you can simply user border images (as many as you 
want). This also eliminates the need for semantically stupid HTML 
elements. However thanks to box-shadow, border-radius and colors with 
alpha transparency I hardly use graphics programs to design any more. I 
just do it directly in HTML/CSS with is usually quite a bit comfortable 
(and faster!). However these properties can slow down browsers quite a 
bit (at least Firefox). [This article][2] gives a good overview of 
what's possible already and where it is supported.

[2]: 
http://dev.opera.com/articles/view/beautiful-ui-styling-with-css3-text-shadow-box-shadow-and-border-radius/

Happy programming
Stephan
Oct 07 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8jvip$1ed6$1 digitalmars.com...

 On 07.10.2010 04:26, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8i10k$2a86$1 digitalmars.com...

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications.


 So true. That, combined with HTTP's stateless nature (and the 
 exploit-prone
 nature of trying to build state on top of it), is why I view "web as a
 platform" as being little different from using PDF as an application
 platform. Heck, the PDF spec is so open-ended it could certainly be done.


 Never read the PDF spec, but I don't believe that it includes a world wide 
 network of web servers, does it?


Not explicitly as far as I'm aware, but then neither does HTML aside from 
URLs. And the PDF format does have provisions for files/data of arbitrary 
types to be embedded into it. So that could be used to embed HTTP URLs, or 
any other form of network-oriented links, or any other application-related 
information/instructions/data you want. Then you could build CSS/JS/CGI-like 
stuff on top of all that. And all of a sudden "PDF-readers" become a really 
shitty application platform just like what happened with HTML and web 
browsers.


 To be honest I use fixed with designs a lot. Usually I just don't have so 
 much content that I have to use every part of the screen. ;)


I've been tempted to do that as well just because controlling resize-flow is 
such a pain with HTML/CSS as they currently are.


 For instance, try to make a resizable box with bit-mapped borders that
 behaves reliably (I've needed to do a lot of that for a client recently).
 Easy as pie with tables and CSS background images. But with anything else 
 in
 CSS, I've become convinced it's just not possible.


 Actually is pretty easy in CSS. I also had to do it a lot in the past. You 
 just nest as many elements (usually divs) inside each other as you need 
 background images. Then you use one of those divs to create the border for 
 one side: just assign a background image to this side and a proper padding 
 that makes sure only this side is visible. Corners are a bit tricky to do 
 no problem if you make the main container "position: relative" and then 
 position the corner divs with "position: aboslute". However for most of my 
 layouts I found that I didn't need a variable height and therefore 4 divs 
 where sufficient. This method had it's troubles for IE 5 but in IE 6 you 
 shouldn't have much of a problem (maybe one bug, don't remember exactly).


Interesting.


 On modern browsers you can simply user border images (as many as you 
 want). This also eliminates the need for semantically stupid HTML 
 elements. However thanks to box-shadow, border-radius and colors with 
 alpha transparency I hardly use graphics programs to design any more. I 
 just do it directly in HTML/CSS with is usually quite a bit comfortable 
 (and faster!).


I usually like to minimize bitmapped stuff on pages too, just because it's 
simpler, it can still get acceptable results, and I'm no artist ;)  But then 
when the client has a design they want it to look like and it includes 
things that can only be done as images, well, then I just don't have the 
energy or patience to try to talk them out of it - I'll just toss in 
whatever I need to to make it work, even if that means tables, and be done 
with it.
Oct 07 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 07.10.2010 11:02, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8jvip$1ed6$1 digitalmars.com...

 On 07.10.2010 04:26, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>   wrote in message
 news:i8i10k$2a86$1 digitalmars.com...

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications.


 So true. That, combined with HTTP's stateless nature (and the
 exploit-prone
 nature of trying to build state on top of it), is why I view "web as a
 platform" as being little different from using PDF as an application
 platform. Heck, the PDF spec is so open-ended it could certainly be done.


 Never read the PDF spec, but I don't believe that it includes a world wide
 network of web servers, does it?


 Not explicitly as far as I'm aware, but then neither does HTML aside from
 URLs. And the PDF format does have provisions for files/data of arbitrary
 types to be embedded into it. So that could be used to embed HTTP URLs, or
 any other form of network-oriented links, or any other application-related
 information/instructions/data you want. Then you could build CSS/JS/CGI-like
 stuff on top of all that. And all of a sudden "PDF-readers" become a really
 shitty application platform just like what happened with HTML and web
 browsers.


Interesting point of view. So PDF basically equals to HTML in that 
regard. Never thought about it that way but you're probably right. :)


 To be honest I use fixed with designs a lot. Usually I just don't have so
 much content that I have to use every part of the screen. ;)


 I've been tempted to do that as well just because controlling resize-flow is
 such a pain with HTML/CSS as they currently are.


 For instance, try to make a resizable box with bit-mapped borders that
 behaves reliably (I've needed to do a lot of that for a client recently).
 Easy as pie with tables and CSS background images. But with anything else
 in
 CSS, I've become convinced it's just not possible.


 Actually is pretty easy in CSS. I also had to do it a lot in the past. You
 just nest as many elements (usually divs) inside each other as you need
 background images. Then you use one of those divs to create the border for
 one side: just assign a background image to this side and a proper padding
 that makes sure only this side is visible. Corners are a bit tricky to do
 no problem if you make the main container "position: relative" and then
 position the corner divs with "position: aboslute". However for most of my
 layouts I found that I didn't need a variable height and therefore 4 divs
 where sufficient. This method had it's troubles for IE 5 but in IE 6 you
 shouldn't have much of a problem (maybe one bug, don't remember exactly).


 Interesting.


 On modern browsers you can simply user border images (as many as you
 want). This also eliminates the need for semantically stupid HTML
 elements. However thanks to box-shadow, border-radius and colors with
 alpha transparency I hardly use graphics programs to design any more. I
 just do it directly in HTML/CSS with is usually quite a bit comfortable
 (and faster!).


 I usually like to minimize bitmapped stuff on pages too, just because it's
 simpler, it can still get acceptable results, and I'm no artist ;)  But then
 when the client has a design they want it to look like and it includes
 things that can only be done as images, well, then I just don't have the
 energy or patience to try to talk them out of it - I'll just toss in
 whatever I need to to make it work, even if that means tables, and be done
 with it.


If I get a design from a client I do that to. I don't use tables but 
most often a combination of floats and relative/absolute positioning but 
usually with quite a lot of images in it. Even if they don't have a 
finished design arguing about it often is a lost cause anyway. However 
for my own personal project (or in case I have to do the design myself) 
these new CSS techniques come in quite handy (if the environment allows 
it...).

I used it for my [personal website][1] and it was quite handy. The only 
images are the header image, icons and the background gradient. The 
gradient only because I was to lazy to look up the proper properties and 
do some cross browser testing (not sure if Opera support gradient yet 
though).

[1]: http://arkanis.de/

Happy programming
Stephan
Oct 07 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8k8k9$230n$1 digitalmars.com...

 On 07.10.2010 11:02, Nick Sabalausky wrote:

 Not explicitly as far as I'm aware, but then neither does HTML aside from
 URLs. And the PDF format does have provisions for files/data of arbitrary
 types to be embedded into it. So that could be used to embed HTTP URLs, 
 or
 any other form of network-oriented links, or any other 
 application-related
 information/instructions/data you want. Then you could build 
 CSS/JS/CGI-like
 stuff on top of all that. And all of a sudden "PDF-readers" become a 
 really
 shitty application platform just like what happened with HTML and web
 browsers.


 Interesting point of view. So PDF basically equals to HTML in that regard. 
 Never thought about it that way but you're probably right. :)


Well, they were both created as document formats ;)


 I usually like to minimize bitmapped stuff on pages too, just because 
 it's
 simpler, it can still get acceptable results, and I'm no artist ;)  But 
 then
 when the client has a design they want it to look like and it includes
 things that can only be done as images, well, then I just don't have the
 energy or patience to try to talk them out of it - I'll just toss in
 whatever I need to to make it work, even if that means tables, and be 
 done
 with it.


 If I get a design from a client I do that to. I don't use tables but most 
 often a combination of floats and relative/absolute positioning but 
 usually with quite a lot of images in it. Even if they don't have a 
 finished design arguing about it often is a lost cause anyway. However for 
 my own personal project (or in case I have to do the design myself) these 
 new CSS techniques come in quite handy (if the environment allows it...).

 I used it for my [personal website][1] and it was quite handy. The only 
 images are the header image, icons and the background gradient. The 
 gradient only because I was to lazy to look up the proper properties and 
 do some cross browser testing (not sure if Opera support gradient yet 
 though).

 [1]: http://arkanis.de/


Not to complain, just FYI, this is what that page looks like for me:

http://www.semitwist.com/download/arkanis1.png
http://www.semitwist.com/download/arkanis2.png
http://www.semitwist.com/download/arkanis3.png

Interestingly, if I turn JS on, than it'll look a lot better *until* it 
finishes loading, at which point it goes back to looking just like those 
screenshots.
Oct 07 2010
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 07 Oct 2010 08:56:07 -0400, Nick Sabalausky wrote:


 "Stephan Soller" <stephan.soller helionweb.de> wrote in message
 news:i8k8k9$230n$1 digitalmars.com...

 On 07.10.2010 11:02, Nick Sabalausky wrote:

 Not explicitly as far as I'm aware, but then neither does HTML aside
 from URLs. And the PDF format does have provisions for files/data of
 arbitrary types to be embedded into it. So that could be used to embed
 HTTP URLs, or
 any other form of network-oriented links, or any other
 application-related
 information/instructions/data you want. Then you could build
 CSS/JS/CGI-like
 stuff on top of all that. And all of a sudden "PDF-readers" become a
 really
 shitty application platform just like what happened with HTML and web
 browsers.


 Interesting point of view. So PDF basically equals to HTML in that
 regard. Never thought about it that way but you're probably right. :)


 Well, they were both created as document formats ;)
 
 

 I usually like to minimize bitmapped stuff on pages too, just because
 it's
 simpler, it can still get acceptable results, and I'm no artist ;) 
 But then
 when the client has a design they want it to look like and it includes
 things that can only be done as images, well, then I just don't have
 the energy or patience to try to talk them out of it - I'll just toss
 in whatever I need to to make it work, even if that means tables, and
 be done
 with it.


 If I get a design from a client I do that to. I don't use tables but
 most often a combination of floats and relative/absolute positioning
 but usually with quite a lot of images in it. Even if they don't have a
 finished design arguing about it often is a lost cause anyway. However
 for my own personal project (or in case I have to do the design myself)
 these new CSS techniques come in quite handy (if the environment allows
 it...).

 I used it for my [personal website][1] and it was quite handy. The only
 images are the header image, icons and the background gradient. The
 gradient only because I was to lazy to look up the proper properties
 and do some cross browser testing (not sure if Opera support gradient
 yet though).

 [1]: http://arkanis.de/


 Not to complain, just FYI, this is what that page looks like for me:
 
 http://www.semitwist.com/download/arkanis1.png
 http://www.semitwist.com/download/arkanis2.png
 http://www.semitwist.com/download/arkanis3.png
 
 Interestingly, if I turn JS on, than it'll look a lot better *until* it
 finishes loading, at which point it goes back to looking just like those
 screenshots.


I don't think the look has anything to do with JS.  It looks perfectly 
fine on my computer, even with JS off.  Here's a quote from another part 
of Stephan's web page, where he writes about the arkandis.de design 
itself:

"This project also builds upon the new HTML5 semantic tags and uses CSS3 
styles for almost everything in its design. Box shadows, rounded corners, 
transparency, HSL-colors, table positioning, etc. This page shows to a 
good degree what's possible if you ditch the old browsers and use the new 
stuff."

I guess you haven't ditched the old browsers, then. ;)

-Lars
Oct 07 2010
prev sibling parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 07.10.2010 14:56, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8k8k9$230n$1 digitalmars.com...

 On 07.10.2010 11:02, Nick Sabalausky wrote:

 Not explicitly as far as I'm aware, but then neither does HTML aside from
 URLs. And the PDF format does have provisions for files/data of arbitrary
 types to be embedded into it. So that could be used to embed HTTP URLs,
 or
 any other form of network-oriented links, or any other
 application-related
 information/instructions/data you want. Then you could build
 CSS/JS/CGI-like
 stuff on top of all that. And all of a sudden "PDF-readers" become a
 really
 shitty application platform just like what happened with HTML and web
 browsers.


 Interesting point of view. So PDF basically equals to HTML in that regard.
 Never thought about it that way but you're probably right. :)


 Well, they were both created as document formats ;)


 I usually like to minimize bitmapped stuff on pages too, just because
 it's
 simpler, it can still get acceptable results, and I'm no artist ;)  But
 then
 when the client has a design they want it to look like and it includes
 things that can only be done as images, well, then I just don't have the
 energy or patience to try to talk them out of it - I'll just toss in
 whatever I need to to make it work, even if that means tables, and be
 done
 with it.


 If I get a design from a client I do that to. I don't use tables but most
 often a combination of floats and relative/absolute positioning but
 usually with quite a lot of images in it. Even if they don't have a
 finished design arguing about it often is a lost cause anyway. However for
 my own personal project (or in case I have to do the design myself) these
 new CSS techniques come in quite handy (if the environment allows it...).

 I used it for my [personal website][1] and it was quite handy. The only
 images are the header image, icons and the background gradient. The
 gradient only because I was to lazy to look up the proper properties and
 do some cross browser testing (not sure if Opera support gradient yet
 though).

 [1]: http://arkanis.de/


 Not to complain, just FYI, this is what that page looks like for me:

 http://www.semitwist.com/download/arkanis1.png
 http://www.semitwist.com/download/arkanis2.png
 http://www.semitwist.com/download/arkanis3.png

 Interestingly, if I turn JS on, than it'll look a lot better *until* it
 finishes loading, at which point it goes back to looking just like those
 screenshots.


Thanks for the screenshots. May I ask which version of Firefox (if I see 
that correctly) your're using? The JS stuff is quite interesting since 
the page actually does not use JS at all. The only situation where JS 
should actually be involved is for IE (because you need to introduce 
unknown elements to IE before using them). I'm not aware that any 
version of Firefox interprets IE conditional comments (although there 
was talk about it once) so this behavior is somewhat concerning.

However this page uses quite new and still in progress browser stuff 
(HTML5, CSS3) so it'll give old browsers a very hard time. It's more 
like a showcase for the new stuff. Take a look at [this screenshot][1] 
to see how it's supposed to look like. It was made with font 
antialiasing on a standard TFT but the text might look a bit awkward on 
CRTs or TFTs with a different subpixel layout (usually the OS takes care 
of that when rendering text). There's also the [design prototype][2] 
which does not use the "new" techniques. It should work on your browser 
(at least most stuff, I never IEified it nor did extensive cross browser 
testing since it's only a prototype).

[1]: http://arkanis.de/projects/arkanis-development-v3/ubuntu.png
[2]: http://arkanis.de/weblog/2008-05-25-modern-ambience-design-prototype/

And finally there's also the [old design][3] which works in IE 5.5, 6 
and 7 (ditched 4, 5, and 5.01 and I'm not sure about 8). It took about 
two weeks to make it work in IE 5.5 and 6 if I remember correctly.

[3]: http://arkanis.de/projects/arkanis-development-v2/photo-ambience/

Happy programming
Stephan
Oct 07 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8kmuc$15t$1 digitalmars.com...

 On 07.10.2010 14:56, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8k8k9$230n$1 digitalmars.com...

 [1]: http://arkanis.de/


 Not to complain, just FYI, this is what that page looks like for me:

 http://www.semitwist.com/download/arkanis1.png
 http://www.semitwist.com/download/arkanis2.png
 http://www.semitwist.com/download/arkanis3.png

 Interestingly, if I turn JS on, than it'll look a lot better *until* it
 finishes loading, at which point it goes back to looking just like those
 screenshots.


 Thanks for the screenshots. May I ask which version of Firefox (if I see 
 that correctly) your're using


v2.0.0.20

Which actually kinda surprises me because I could have sworn I was on a much 
later version of the 2.x line. I *know* there was a period where it kept 
updating itself seemingly all the time (which got quite irritating when I 
just wanted to go to a particular URL). But I guess that must have been the 
only 2.x version I was able to find after giving up on FF3. And IIRC, the 
built-in update won't let me update to anything less than FF3.

And yea, I know FF2 is really old, but I tried 3.0 and 3.5 and the JS was 
only marginally faster, it doesn't seem to fix any of the rendering bugs 
I've come across in FF2 (I have 3.5 on my Linux box, just for site testing), 
and every other change they made I hated and downloaded extentions to 
undo...until I realized there was no extention to un-unify the unified 
forward/back buttons (which I had thought was a good idea when IE7 came 
out -- until I actually used IE7), and realized the only winestripe-like 
things for FF3 weren't nearly as good as the real winestripe. So I figured 
"Why bog it down with even *more* addons just to turn it into a half-baked 
FF2, when I can just use the real FF2?" YouTube bitches to me about it, but 
well, fuck YouTube; never liked having over-compressed videos pre-embedded 
into a web-based player anyway.


 The JS stuff is quite interesting since the page actually does not use JS 
 at all. The only situation where JS should actually be involved is for IE 
 (because you need to introduce unknown elements to IE before using them). 
 I'm not aware that any version of Firefox interprets IE conditional 
 comments (although there was talk about it once) so this behavior is 
 somewhat concerning.


Don't worry. Turns out it was just a quirk caused by one of the million 
add-ons I have installed to make the web bearable. When I disabled all of 
them, the behavior and results with JS on were exactly the same as with JS 
off.


 However this page uses quite new and still in progress browser stuff 
 (HTML5, CSS3) so it'll give old browsers a very hard time. It's more like 
 a showcase for the new stuff.


I see, that explains it. Personally, I'll have no interest in CSS3 unless MS 
decides to backport IE9 to XP. I hate Win7 and refuse to let XP die 
(Granted, Win7's not quite as bad as Vista, but it's close).


 Take a look at [this screenshot][1] to see how it's supposed to look like. 
 It was made with font antialiasing on a standard TFT but the text might 
 look a bit awkward on CRTs or TFTs with a different subpixel layout 
 (usually the OS takes care of that when rendering text). There's also the 
 [design prototype][2] which does not use the "new" techniques. It should 
 work on your browser (at least most stuff, I never IEified it nor did 
 extensive cross browser testing since it's only a prototype).

 [1]: http://arkanis.de/projects/arkanis-development-v3/ubuntu.png
 [2]: http://arkanis.de/weblog/2008-05-25-modern-ambience-design-prototype/

 And finally there's also the [old design][3] which works in IE 5.5, 6 and 
 7 (ditched 4, 5, and 5.01 and I'm not sure about 8). It took about two 
 weeks to make it work in IE 5.5 and 6 if I remember correctly.

 [3]: http://arkanis.de/projects/arkanis-development-v2/photo-ambience/


Ahh. Yea, all of those do look better :) Actually, even I've ditched IE6 
(it's *that* old). 'Course, part of that is because having multiple versions 
of IE installed is a PITA - if even possible at all. In fact, that's why I 
haven't upgraded to IE8 - I'd lose the ability to test on IE7 which I think 
is still fairly common.
Oct 07 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 07.10.2010 23:59, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8kmuc$15t$1 digitalmars.com...

 On 07.10.2010 14:56, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>   wrote in message
 news:i8k8k9$230n$1 digitalmars.com...

 [1]: http://arkanis.de/


 Not to complain, just FYI, this is what that page looks like for me:

 http://www.semitwist.com/download/arkanis1.png
 http://www.semitwist.com/download/arkanis2.png
 http://www.semitwist.com/download/arkanis3.png

 Interestingly, if I turn JS on, than it'll look a lot better *until* it
 finishes loading, at which point it goes back to looking just like those
 screenshots.


 Thanks for the screenshots. May I ask which version of Firefox (if I see
 that correctly) your're using


 v2.0.0.20

 Which actually kinda surprises me because I could have sworn I was on a much
 later version of the 2.x line. I *know* there was a period where it kept
 updating itself seemingly all the time (which got quite irritating when I
 just wanted to go to a particular URL). But I guess that must have been the
 only 2.x version I was able to find after giving up on FF3. And IIRC, the
 built-in update won't let me update to anything less than FF3.

 And yea, I know FF2 is really old, but I tried 3.0 and 3.5 and the JS was
 only marginally faster, it doesn't seem to fix any of the rendering bugs
 I've come across in FF2 (I have 3.5 on my Linux box, just for site testing),
 and every other change they made I hated and downloaded extentions to
 undo...until I realized there was no extention to un-unify the unified
 forward/back buttons (which I had thought was a good idea when IE7 came
 out -- until I actually used IE7), and realized the only winestripe-like
 things for FF3 weren't nearly as good as the real winestripe. So I figured
 "Why bog it down with even *more* addons just to turn it into a half-baked
 FF2, when I can just use the real FF2?" YouTube bitches to me about it, but
 well, fuck YouTube; never liked having over-compressed videos pre-embedded
 into a web-based player anyway.


Maybe you should consider looking into some other browsers? Opera, 
Chrome and other Gecko based browsers might give you a better experience 
that the newer Firefox versions. This is the reason why there are 
different browsers after all.

Staying with FF2 for to long might really hurt your browsing experience 
since quite a bunch of functionality was added to the browsers itself 
lately. And trust me, it's really way easier to use the new stuff than 
all the old workarounds (e.g. webfonts, svg, css based animations, 
transparency, dropshadows, video, and the list goes on...). I really 
expect many people to use this stuff in the near future, not only 
because it's cool but mainly because it's so much easier than the old stuff.

I've seen people holding on to Netscape 4 because they didn't like the 
newer versions. They could endure a surprising amount of totally broken 
pages but the internet wasn't fun for them. Fortunately we have a lot 
more alternatives today. :)


 The JS stuff is quite interesting since the page actually does not use JS
 at all. The only situation where JS should actually be involved is for IE
 (because you need to introduce unknown elements to IE before using them).
 I'm not aware that any version of Firefox interprets IE conditional
 comments (although there was talk about it once) so this behavior is
 somewhat concerning.


 Don't worry. Turns out it was just a quirk caused by one of the million
 add-ons I have installed to make the web bearable. When I disabled all of
 them, the behavior and results with JS on were exactly the same as with JS
 off.


 However this page uses quite new and still in progress browser stuff
 (HTML5, CSS3) so it'll give old browsers a very hard time. It's more like
 a showcase for the new stuff.


 I see, that explains it. Personally, I'll have no interest in CSS3 unless MS
 decides to backport IE9 to XP. I hate Win7 and refuse to let XP die
 (Granted, Win7's not quite as bad as Vista, but it's close).


 Take a look at [this screenshot][1] to see how it's supposed to look like.
 It was made with font antialiasing on a standard TFT but the text might
 look a bit awkward on CRTs or TFTs with a different subpixel layout
 (usually the OS takes care of that when rendering text). There's also the
 [design prototype][2] which does not use the "new" techniques. It should
 work on your browser (at least most stuff, I never IEified it nor did
 extensive cross browser testing since it's only a prototype).

 [1]: http://arkanis.de/projects/arkanis-development-v3/ubuntu.png
 [2]: http://arkanis.de/weblog/2008-05-25-modern-ambience-design-prototype/

 And finally there's also the [old design][3] which works in IE 5.5, 6 and
 7 (ditched 4, 5, and 5.01 and I'm not sure about 8). It took about two
 weeks to make it work in IE 5.5 and 6 if I remember correctly.

 [3]: http://arkanis.de/projects/arkanis-development-v2/photo-ambience/


 Ahh. Yea, all of those do look better :) Actually, even I've ditched IE6
 (it's *that* old). 'Course, part of that is because having multiple versions
 of IE installed is a PITA - if even possible at all. In fact, that's why I
 haven't upgraded to IE8 - I'd lose the ability to test on IE7 which I think
 is still fairly common.


Actually you could run IE 5 up to 6 on one WinXP. You only needed a 
couple of DLLs and the iexplorer.exe of the corresponding IE version. 
The [Evolt browser archive][1] provided these nice standalone versions 
of IE. I used it for a long time since it is considerably faster than 
using VMs but I'm not sure if this still works with IE 7 and 8. Because 
of that I switched to VMs a few years back (one VM for IE 6 on XP, one 
for IE 8 on XP which will give you IE 7 by using the compatibility mode 
and one for IE 8 on Win7 because of the fonts).

[1]: http://browsers.evolt.org/

Happy programming
Stephan
Oct 10 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8sh5u$2ijp$1 digitalmars.com...

 On 07.10.2010 23:59, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8kmuc$15t$1 digitalmars.com...

 On 07.10.2010 14:56, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>   wrote in message
 news:i8k8k9$230n$1 digitalmars.com...

 [1]: http://arkanis.de/


 Not to complain, just FYI, this is what that page looks like for me:

 http://www.semitwist.com/download/arkanis1.png
 http://www.semitwist.com/download/arkanis2.png
 http://www.semitwist.com/download/arkanis3.png

 Interestingly, if I turn JS on, than it'll look a lot better *until* it
 finishes loading, at which point it goes back to looking just like 
 those
 screenshots.


 Thanks for the screenshots. May I ask which version of Firefox (if I see
 that correctly) your're using


 v2.0.0.20

 Which actually kinda surprises me because I could have sworn I was on a 
 much
 later version of the 2.x line. I *know* there was a period where it kept
 updating itself seemingly all the time (which got quite irritating when I
 just wanted to go to a particular URL). But I guess that must have been 
 the
 only 2.x version I was able to find after giving up on FF3. And IIRC, the
 built-in update won't let me update to anything less than FF3.

 And yea, I know FF2 is really old, but I tried 3.0 and 3.5 and the JS was
 only marginally faster, it doesn't seem to fix any of the rendering bugs
 I've come across in FF2 (I have 3.5 on my Linux box, just for site 
 testing),
 and every other change they made I hated and downloaded extentions to
 undo...until I realized there was no extention to un-unify the unified
 forward/back buttons (which I had thought was a good idea when IE7 came
 out -- until I actually used IE7), and realized the only winestripe-like
 things for FF3 weren't nearly as good as the real winestripe. So I 
 figured
 "Why bog it down with even *more* addons just to turn it into a 
 half-baked
 FF2, when I can just use the real FF2?" YouTube bitches to me about it, 
 but
 well, fuck YouTube; never liked having over-compressed videos 
 pre-embedded
 into a web-based player anyway.


 Maybe you should consider looking into some other browsers? Opera, Chrome 
 and other Gecko based browsers might give you a better experience that the 
 newer Firefox versions. This is the reason why there are different 
 browsers after all.


- Safari is ruled out because it's a blurry mess (all for the sake of making 
it look more like the printed version? WTF?) and forces useless background 
processes, has zero respect for my system's look-and-feel, and has no 
"Adblock Plus", "NoScript", or "BetterPrivacy" (Three FF add-ons that 
provide functionality that, for me, are absolutely 100% essential).

- IE7+ is out because it has no "Adblock Plus", "NoScript", or 
"BetterPrivacy", and I don't like the unified forward/back buttons.

- Iron is out because I *hate* absolutely everything about it's UI, and it 
doesn't have "NoScript" (I've heard it has "AdBlock Plus", but I didn't see 
it when I first looked so I don't know). Also, configurability seems to be 
practically non-existent compared to FF.

- Chrome is out because of all the reasons for which Iron was created in the 
first place. I won't even allow Chrome (or Safari) on my computer at all.

- Opera is ruled out because it costs money and every time I tried the demos 
it seemed to combine the worst aspects of all the other browsers, plus had 
by far the most rendering problems.

- And everything else like IE6-, Netscape, WebTV, Lynx, etc are all ruled 
out for obvious reasons.
Oct 10 2010
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:


 "Stephan Soller" <stephan.soller helionweb.de> wrote in message
 news:i8sh5u$2ijp$1 digitalmars.com...

 On 07.10.2010 23:59, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8kmuc$15t$1 digitalmars.com...

 On 07.10.2010 14:56, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>   wrote in message
 news:i8k8k9$230n$1 digitalmars.com...

 [1]: http://arkanis.de/


 Not to complain, just FYI, this is what that page looks like for me:

 http://www.semitwist.com/download/arkanis1.png
 http://www.semitwist.com/download/arkanis2.png
 http://www.semitwist.com/download/arkanis3.png

 Interestingly, if I turn JS on, than it'll look a lot better *until* it
 finishes loading, at which point it goes back to looking just like
 those
 screenshots.


 Thanks for the screenshots. May I ask which version of Firefox (if I see
 that correctly) your're using


 v2.0.0.20

 Which actually kinda surprises me because I could have sworn I was on a
 much
 later version of the 2.x line. I *know* there was a period where it kept
 updating itself seemingly all the time (which got quite irritating when I
 just wanted to go to a particular URL). But I guess that must have been
 the
 only 2.x version I was able to find after giving up on FF3. And IIRC, the
 built-in update won't let me update to anything less than FF3.

 And yea, I know FF2 is really old, but I tried 3.0 and 3.5 and the JS was
 only marginally faster, it doesn't seem to fix any of the rendering bugs
 I've come across in FF2 (I have 3.5 on my Linux box, just for site
 testing),
 and every other change they made I hated and downloaded extentions to
 undo...until I realized there was no extention to un-unify the unified
 forward/back buttons (which I had thought was a good idea when IE7 came
 out -- until I actually used IE7), and realized the only winestripe-like
 things for FF3 weren't nearly as good as the real winestripe. So I
 figured
 "Why bog it down with even *more* addons just to turn it into a
 half-baked
 FF2, when I can just use the real FF2?" YouTube bitches to me about it,
 but
 well, fuck YouTube; never liked having over-compressed videos
 pre-embedded
 into a web-based player anyway.


 Maybe you should consider looking into some other browsers? Opera, Chrome
 and other Gecko based browsers might give you a better experience that the
 newer Firefox versions. This is the reason why there are different
 browsers after all.


 
 - Safari is ruled out because it's a blurry mess (all for the sake of making
 it look more like the printed version? WTF?) and forces useless background
 processes, has zero respect for my system's look-and-feel, and has no
 "Adblock Plus", "NoScript", or "BetterPrivacy" (Three FF add-ons that
 provide functionality that, for me, are absolutely 100% essential).
 
 - IE7+ is out because it has no "Adblock Plus", "NoScript", or
 "BetterPrivacy", and I don't like the unified forward/back buttons.
 
 - Iron is out because I *hate* absolutely everything about it's UI, and it
 doesn't have "NoScript" (I've heard it has "AdBlock Plus", but I didn't see
 it when I first looked so I don't know). Also, configurability seems to be
 practically non-existent compared to FF.
 
 - Chrome is out because of all the reasons for which Iron was created in the
 first place. I won't even allow Chrome (or Safari) on my computer at all.
 
 - Opera is ruled out because it costs money and every time I tried the demos
 it seemed to combine the worst aspects of all the other browsers, plus had
 by far the most rendering problems.
 
 - And everything else like IE6-, Netscape, WebTV, Lynx, etc are all ruled
 out for obvious reasons.


Perhaps try firefox 4 (beta)? It is much faster, probably on par with chrome 
now, and it looks a bit cleaner designed.

You can download Opera for free btw.
Oct 10 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:i8ta2d$1lnd$1 digitalmars.com...

 Nick Sabalausky wrote:


 "Stephan Soller" <stephan.soller helionweb.de> wrote in message

 Maybe you should consider looking into some other browsers? Opera, 
 Chrome
 and other Gecko based browsers might give you a better experience that 
 the
 newer Firefox versions. This is the reason why there are different
 browsers after all.


 - Safari is ruled out because it's a blurry mess (all for the sake of 
 making
 it look more like the printed version? WTF?) and forces useless 
 background
 processes, has zero respect for my system's look-and-feel, and has no
 "Adblock Plus", "NoScript", or "BetterPrivacy" (Three FF add-ons that
 provide functionality that, for me, are absolutely 100% essential).

 - IE7+ is out because it has no "Adblock Plus", "NoScript", or
 "BetterPrivacy", and I don't like the unified forward/back buttons.

 - Iron is out because I *hate* absolutely everything about it's UI, and 
 it
 doesn't have "NoScript" (I've heard it has "AdBlock Plus", but I didn't 
 see
 it when I first looked so I don't know). Also, configurability seems to 
 be
 practically non-existent compared to FF.

 - Chrome is out because of all the reasons for which Iron was created in 
 the
 first place. I won't even allow Chrome (or Safari) on my computer at all.

 - Opera is ruled out because it costs money and every time I tried the 
 demos
 it seemed to combine the worst aspects of all the other browsers, plus 
 had
 by far the most rendering problems.

 - And everything else like IE6-, Netscape, WebTV, Lynx, etc are all ruled
 out for obvious reasons.


 Perhaps try firefox 4 (beta)? It is much faster, probably on par with 
 chrome
 now, and it looks a bit cleaner designed.


I'll probably try it at some point, but I seriously doubt it won't be the 
same story as FF3. It's Mozilla's basic nature to refuse to allow users to 
disable any of Mozilla's beloved *cough* "improvements", and to merely scoff 
whenever people don't like it. They're never shown any interest in making 
anything about the AwfulBar optional. Same with the unified forward/back 
buttons, or every ugly-ass theme FF has insisted on using starting with FF2 
(That's why I use Winestripe.) And like most developers, they've never shown 
any respect for people with light-on-dark schemes. Etc, etc, etc, And 
they're a bunch or arrogant douchebags to boot.  Mozilla just has their 
heads ten miles up their asses and that's all there is to it, and I don't 
believe for a second anything's ever going to change that.

Like I said, I'll probably try it at some point, but I *very* much doubt it 
won't be the same story as FF3. And from the screenshots, it looks like 
it'll end up absolutely horrid-looking on the Win Classic theme, just like 
FF2 and FF3 and just like every Windows program these days that's designed 
to assume the user is running that god-awful Aero theme (I think the only 
reason people think Aero looks good is because it's not as bad as Luna, and 
most people were too stupid to realize XP's Luna was optional.) Plus, it 
looks like they're trying to ape IE7/8 and Chrome, and I think those are 
some of the most butt-ugly and shitty-UI browsers ever made (*especially* 
Chrome).
Oct 10 2010
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:i8u779$d4a$1 digitalmars.com...

 "Lutger" <lutger.blijdestijn gmail.com> wrote in message 
 news:i8ta2d$1lnd$1 digitalmars.com...

 Nick Sabalausky wrote:


 "Stephan Soller" <stephan.soller helionweb.de> wrote in message

 Maybe you should consider looking into some other browsers? Opera, 
 Chrome
 and other Gecko based browsers might give you a better experience that 
 the
 newer Firefox versions. This is the reason why there are different
 browsers after all.


 - Safari is ruled out because it's a blurry mess (all for the sake of 
 making
 it look more like the printed version? WTF?) and forces useless 
 background
 processes, has zero respect for my system's look-and-feel, and has no
 "Adblock Plus", "NoScript", or "BetterPrivacy" (Three FF add-ons that
 provide functionality that, for me, are absolutely 100% essential).

 - IE7+ is out because it has no "Adblock Plus", "NoScript", or
 "BetterPrivacy", and I don't like the unified forward/back buttons.

 - Iron is out because I *hate* absolutely everything about it's UI, and 
 it
 doesn't have "NoScript" (I've heard it has "AdBlock Plus", but I didn't 
 see
 it when I first looked so I don't know). Also, configurability seems to 
 be
 practically non-existent compared to FF.

 - Chrome is out because of all the reasons for which Iron was created in 
 the
 first place. I won't even allow Chrome (or Safari) on my computer at 
 all.

 - Opera is ruled out because it costs money and every time I tried the 
 demos
 it seemed to combine the worst aspects of all the other browsers, plus 
 had
 by far the most rendering problems.

 - And everything else like IE6-, Netscape, WebTV, Lynx, etc are all 
 ruled
 out for obvious reasons.


 Perhaps try firefox 4 (beta)? It is much faster, probably on par with 
 chrome
 now, and it looks a bit cleaner designed.


 I'll probably try it at some point, but I seriously doubt it won't be the 
 same story as FF3. It's Mozilla's basic nature to refuse to allow users to 
 disable any of Mozilla's beloved *cough* "improvements", and to merely 
 scoff whenever people don't like it. They're never shown any interest in 
 making anything about the AwfulBar optional. Same with the unified 
 forward/back buttons, or every ugly-ass theme FF has insisted on using 
 starting with FF2 (That's why I use Winestripe.) And like most developers, 
 they've never shown any respect for people with light-on-dark schemes. 
 Etc, etc, etc, And they're a bunch or arrogant douchebags to boot. 
 Mozilla just has their heads ten miles up their asses and that's all there 
 is to it, and I don't believe for a second anything's ever going to change 
 that.

 Like I said, I'll probably try it at some point, but I *very* much doubt 
 it won't be the same story as FF3. And from the screenshots, it looks like 
 it'll end up absolutely horrid-looking on the Win Classic theme, just like 
 FF2 and FF3 and just like every Windows program these days that's designed 
 to assume the user is running that god-awful Aero theme (I think the only 
 reason people think Aero looks good is because it's not as bad as Luna, 
 and most people were too stupid to realize XP's Luna was optional.) Plus, 
 it looks like they're trying to ape IE7/8 and Chrome, and I think those 
 are some of the most butt-ugly and shitty-UI browsers ever made 
 (*especially* Chrome).


Just found a portable install of FF4 and tried it. And yea, pretty much like 
I expected. Just like all the other software being made these days, it 
refuses to use anything even resembling my native UI. Not to the horrid 
extent of Chrome/Iron, but still far worse then FF2+Winestripe. And, of 
course, there's no option to make it use native. There's no options to get 
rid of the AwfulBar, in whole or in part. There's no option to de-unify the 
unified forward/back buttons. And as far as finding add-ons to take care of 
that stuff, I'm not interested in loading my browser down with even *more* 
add-ons than I'm already using.

I'd rather do without all the pointless animations, but, again, they don't 
seem to allow that. And there's still a bunch of irritating tooltips, 
although FF2 has them too (But you'd think that *by now* they'd have had a 
chance to put in an option to disable them.)

It is faster, but that's not enough to make up for a shit UI.
Oct 11 2010
prev sibling parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 10.10.2010 22:42, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8sh5u$2ijp$1 digitalmars.com...

 On 07.10.2010 23:59, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>   wrote in message
 news:i8kmuc$15t$1 digitalmars.com...

 On 07.10.2010 14:56, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>    wrote in message
 news:i8k8k9$230n$1 digitalmars.com...

 [1]: http://arkanis.de/


 Not to complain, just FYI, this is what that page looks like for me:

 http://www.semitwist.com/download/arkanis1.png
 http://www.semitwist.com/download/arkanis2.png
 http://www.semitwist.com/download/arkanis3.png

 Interestingly, if I turn JS on, than it'll look a lot better *until* it
 finishes loading, at which point it goes back to looking just like
 those
 screenshots.


 Thanks for the screenshots. May I ask which version of Firefox (if I see
 that correctly) your're using


 v2.0.0.20

 Which actually kinda surprises me because I could have sworn I was on a
 much
 later version of the 2.x line. I *know* there was a period where it kept
 updating itself seemingly all the time (which got quite irritating when I
 just wanted to go to a particular URL). But I guess that must have been
 the
 only 2.x version I was able to find after giving up on FF3. And IIRC, the
 built-in update won't let me update to anything less than FF3.

 And yea, I know FF2 is really old, but I tried 3.0 and 3.5 and the JS was
 only marginally faster, it doesn't seem to fix any of the rendering bugs
 I've come across in FF2 (I have 3.5 on my Linux box, just for site
 testing),
 and every other change they made I hated and downloaded extentions to
 undo...until I realized there was no extention to un-unify the unified
 forward/back buttons (which I had thought was a good idea when IE7 came
 out -- until I actually used IE7), and realized the only winestripe-like
 things for FF3 weren't nearly as good as the real winestripe. So I
 figured
 "Why bog it down with even *more* addons just to turn it into a
 half-baked
 FF2, when I can just use the real FF2?" YouTube bitches to me about it,
 but
 well, fuck YouTube; never liked having over-compressed videos
 pre-embedded
 into a web-based player anyway.


 Maybe you should consider looking into some other browsers? Opera, Chrome
 and other Gecko based browsers might give you a better experience that the
 newer Firefox versions. This is the reason why there are different
 browsers after all.


 - Safari is ruled out because it's a blurry mess (all for the sake of making
 it look more like the printed version? WTF?) and forces useless background
 processes, has zero respect for my system's look-and-feel, and has no
 "Adblock Plus", "NoScript", or "BetterPrivacy" (Three FF add-ons that
 provide functionality that, for me, are absolutely 100% essential).

 - IE7+ is out because it has no "Adblock Plus", "NoScript", or
 "BetterPrivacy", and I don't like the unified forward/back buttons.

 - Iron is out because I *hate* absolutely everything about it's UI, and it
 doesn't have "NoScript" (I've heard it has "AdBlock Plus", but I didn't see
 it when I first looked so I don't know). Also, configurability seems to be
 practically non-existent compared to FF.

 - Chrome is out because of all the reasons for which Iron was created in the
 first place. I won't even allow Chrome (or Safari) on my computer at all.

 - Opera is ruled out because it costs money and every time I tried the demos
 it seemed to combine the worst aspects of all the other browsers, plus had
 by far the most rendering problems.

 - And everything else like IE6-, Netscape, WebTV, Lynx, etc are all ruled
 out for obvious reasons.


Adblock Plus, NoScript and BetterPrivacy are a combination that's hard 
to find in other browsers. I suppose you have to do some manual 
configuration to get that done.

Many browsers today "compress" the UI in order to free more horizontal 
space for the websites. There is an ongoing development towards wider 
displays that shrink in height and the new browser UIs are a logical 
counter development to that. In Opera however it's just the default 
configuration and with a few clicks you can bring every toolbar back 
(and add or remove buttons, etc.). Never found a way to revert that in 
Firefox or Chrome but I haven't searched every "about:config" option.

Regarding configuration Opera is on pair with Firefox if not even more 
flexible, therefore they don't have extensions.

Opera giving the most rendering bugs is actually a funny story. They had 
the most advanced "quirks mode" (IE 5 compatibility mode). It changed 
quite a bit in the rendering of websites and was very close to IE 5 (I 
really doubt they had fun programming this). However many developers 
didn't know how to trigger standard compliant mode back then (these 
strange DTDs...) and forced Opera (and IE 6 and Firefox) into quirks 
mode. But since Firefox looked more or less the same in quirks mode 
people of course regarded the Opera and IE rendering as bugs.

ps.: Opera is free since over 5 years, so you might want to take a look 
since much has changed since then.

Happy programming
Stephan
Oct 11 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8ufto$17dk$1 digitalmars.com...

 Adblock Plus, NoScript and BetterPrivacy are a combination that's hard to 
 find in other browsers.


Yup. And that's speaks very poorly for the overall state of web browsers. 
It's amazing that with so many offerings there's none that are actually any 
good.


 Many browsers today "compress" the UI in order to free more horizontal 
 space for the websites. There is an ongoing development towards wider 
 displays that shrink in height


Which, of course, is an absolutely rediculous trend that's been created 
almost entirely on faulty notions, but that's a whole other rant...


 and the new browser UIs are a logical counter development to that. In 
 Opera however it's just the default configuration and with a few clicks 
 you can bring every toolbar back (and add or remove buttons, etc.). Never 
 found a way to revert that in Firefox or Chrome but I haven't searched 
 every "about:config" option.


Yea, "about:config" is truly awful. I consider any setting that's only in 
there to be non-existant (unless I just happend to come across someone 
mentioning a specific one, as was the case with turning off animating images 
and favicons (I turned off favicons only because FF's "no animate" setting 
doesn't work for favicons)).


 ps.: Opera is free since over 5 years, so you might want to take a look 
 since much has changed since then.


Just gave the latest version a try (turns out the last I tried was 9.x and 
was about three years old, although I know that wasn't the first time I had 
tried it). I haven't spent much time with it yet, but my initial 
impressions:

When it first started, first thing I did was get rid of that awful "menu" 
button. Then I balked at how incredibly ugly the real menu and tabs are. I 
went to find a way to disable themes, but then discovered that it was 
*already* on the supposed "Windows Native Skin", which is quite obviously 
anything but. Looks exactly like GTK to me. There's the tell-tale GTK 
"Rediculously Excessive Padding", and the almost-equally tell-tale 
"Invisible text for light-on-dark users (black-on-black)". And then as if 
that wasn't bad enough, there's this really amateur-ish hover/pressed 
"highlight" on the top-level menu items, which 1. is obviously non-native 
since native has no hover effect and *I* have my selection color set to 
blue, but this uses white instead, and 2. results in even *more* invisi-text 
(white-on-white).

The tabs don't even try to be tabs at all, just GTK buttons acting like 
tabs. And the menus appear with a fade-in that's clearly *intended* to look 
like the subtle fade-in native stuff uses, except unlike the native apps 
they're jarringly...well, "choppy" is the only way I can think to describe 
it. And there seems to be some weird drawing-conflict between them and the 
"tabs" during that fade-in. It looks really really bad, and disabling 
effects doesn't get rid of it.

The whole UI is just a complete amateur job (which is pretty much what I 
remember from every other time I tried it, now that I think of it). Haven't 
tried any actual pages or any sort of AdBlock/NoScript/BetterPrivacy sort of 
functionality yet.
Oct 11 2010
next sibling parent Russel Winder <russel russel.org.uk> writes:
On Mon, 2010-10-11 at 07:01 -0400, Nick Sabalausky wrote:
[ . . . ]

 Yup. And that's speaks very poorly for the overall state of web browsers.=


=20

 It's amazing that with so many offerings there's none that are actually a=


ny=20

 good.


I just stick with Epiphany on Ubuntu.  It has minimal decoration around
the rendering area and it sticks with my Gnome theme.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 11 2010
prev sibling parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 11.10.2010 13:01, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8ufto$17dk$1 digitalmars.com...

 Adblock Plus, NoScript and BetterPrivacy are a combination that's hard to
 find in other browsers.


 Yup. And that's speaks very poorly for the overall state of web browsers.
 It's amazing that with so many offerings there's none that are actually any
 good.


Not only browsers but more general the understanding of privacy on the 
Internet among its users.


 Many browsers today "compress" the UI in order to free more horizontal
 space for the websites. There is an ongoing development towards wider
 displays that shrink in height


 Which, of course, is an absolutely rediculous trend that's been created
 almost entirely on faulty notions, but that's a whole other rant...


I absolutely agree on that.


 and the new browser UIs are a logical counter development to that. In
 Opera however it's just the default configuration and with a few clicks
 you can bring every toolbar back (and add or remove buttons, etc.). Never
 found a way to revert that in Firefox or Chrome but I haven't searched
 every "about:config" option.


 Yea, "about:config" is truly awful. I consider any setting that's only in
 there to be non-existant (unless I just happend to come across someone
 mentioning a specific one, as was the case with turning off animating images
 and favicons (I turned off favicons only because FF's "no animate" setting
 doesn't work for favicons)).


 ps.: Opera is free since over 5 years, so you might want to take a look
 since much has changed since then.


 Just gave the latest version a try (turns out the last I tried was 9.x and
 was about three years old, although I know that wasn't the first time I had
 tried it). I haven't spent much time with it yet, but my initial
 impressions:

 When it first started, first thing I did was get rid of that awful "menu"
 button. Then I balked at how incredibly ugly the real menu and tabs are. I
 went to find a way to disable themes, but then discovered that it was
 *already* on the supposed "Windows Native Skin", which is quite obviously
 anything but. Looks exactly like GTK to me. There's the tell-tale GTK
 "Rediculously Excessive Padding", and the almost-equally tell-tale
 "Invisible text for light-on-dark users (black-on-black)". And then as if
 that wasn't bad enough, there's this really amateur-ish hover/pressed
 "highlight" on the top-level menu items, which 1. is obviously non-native
 since native has no hover effect and *I* have my selection color set to
 blue, but this uses white instead, and 2. results in even *more* invisi-text
 (white-on-white).

 The tabs don't even try to be tabs at all, just GTK buttons acting like
 tabs. And the menus appear with a fade-in that's clearly *intended* to look
 like the subtle fade-in native stuff uses, except unlike the native apps
 they're jarringly...well, "choppy" is the only way I can think to describe
 it. And there seems to be some weird drawing-conflict between them and the
 "tabs" during that fade-in. It looks really really bad, and disabling
 effects doesn't get rid of it.

 The whole UI is just a complete amateur job (which is pretty much what I
 remember from every other time I tried it, now that I think of it). Haven't
 tried any actual pages or any sort of AdBlock/NoScript/BetterPrivacy sort of
 functionality yet.


Ok, I'll stop recommending browsers then. Maybe you should just grab 
WebKit or Gecko and build your own UI around it. This will also give you 
(almost) all the privacy control you want. ;)

Just to give the Opera guys some credit: technically their UI is pretty 
well done and fast (it's based on Qt and they skipped hardware 
acceleration for this release because it wasn't the bottleneck). The 
default design is a different story but I personally think they hit what 
the masses currently would call a "nice design".

Happy programming
Stephan
Oct 11 2010
parent "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8v03a$293d$1 digitalmars.com...

 Maybe you should just grab WebKit or Gecko and build your own UI around 
 it. This will also give you (almost) all the privacy control you want. ;)


Yea, that's been my intent, but who knows when I'll have a chance to get to 
it :/
Oct 11 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 06/10/2010 15:25, Stephan Soller wrote:

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications. If you want you
 can simply make every element a block level element and use JavaScript
 for layout. I don't know GTK and QT in depth but then you should have
 about the same level of possibilities as with these layout engines. It
 wouldn't surprise me if GUI frameworks like jQuery UI actually do this.


The issue is not with level of possibilites. HTML/CSS has as much 
possibilities as many GUI toolkits, if not more. (there is really a lot 
of stuff you can do you HTML/CSS if you figure out how to). The issue is 
that it's incredibly hard to do that, HTML/CSS is so convoluted. (and 
I'm talking about proper flowing designs, now pixel-based, fixed-width 
ones. Those are fairly easy in both HTML and GUI toolkits).

And what do you mean "use JavaScript for layout"? You can't use 
JavaScript for layout. You can use JavaScript to programmatically 
manipulate the CSS properties of HTML elements, but you are still using 
the same HTML rules for layout, so the difficulty is unchanged.

-- 
Bruno Medeiros - Software Engineer
Oct 07 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 07.10.2010 11:41, Bruno Medeiros wrote:

 On 06/10/2010 15:25, Stephan Soller wrote:

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications. If you want you
 can simply make every element a block level element and use JavaScript
 for layout. I don't know GTK and QT in depth but then you should have
 about the same level of possibilities as with these layout engines. It
 wouldn't surprise me if GUI frameworks like jQuery UI actually do this.


 The issue is not with level of possibilites. HTML/CSS has as much
 possibilities as many GUI toolkits, if not more. (there is really a lot
 of stuff you can do you HTML/CSS if you figure out how to). The issue is
 that it's incredibly hard to do that, HTML/CSS is so convoluted. (and
 I'm talking about proper flowing designs, now pixel-based, fixed-width
 ones. Those are fairly easy in both HTML and GUI toolkits).


It does not feel convoluted to me but I have learned HTML/CSS gradually 
as they evolved. Therefore I might not be able to properly see how it 
looks from the distance if someone doesn't know the details. To me it 
looks well structured (block vs. inline elements, different distinct 
layout models, typography, etc.). There sure a some parts that deserve a 
little cleanup and simplification but I can't think of any right now.

I'm just curious about your point of view. What parts of CSS look 
convoluted to you?


 And what do you mean "use JavaScript for layout"? You can't use
 JavaScript for layout. You can use JavaScript to programmatically
 manipulate the CSS properties of HTML elements, but you are still using
 the same HTML rules for layout, so the difficulty is unchanged.


You're right. At the end HTML/CSS simply is the interface to tell the 
browser about the structure and appearance of your document. However you 
can make every element a block level element ("display: block;") and use 
absolute positioning. Then each element basically behaves like a window 
of an window manager and you can use your own algorithms to do the 
layout by calculating the position and dimensions (top, left, height, 
width). At that stage you don't have to think about any of the layout 
models of CSS and you're totally independent of them.

Happy programming
Stephan
Oct 10 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 10/10/2010 15:23, Stephan Soller wrote:

 On 07.10.2010 11:41, Bruno Medeiros wrote:

 On 06/10/2010 15:25, Stephan Soller wrote:

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications. If you want you
 can simply make every element a block level element and use JavaScript
 for layout. I don't know GTK and QT in depth but then you should have
 about the same level of possibilities as with these layout engines. It
 wouldn't surprise me if GUI frameworks like jQuery UI actually do this.


 The issue is not with level of possibilites. HTML/CSS has as much
 possibilities as many GUI toolkits, if not more. (there is really a lot
 of stuff you can do you HTML/CSS if you figure out how to). The issue is
 that it's incredibly hard to do that, HTML/CSS is so convoluted. (and
 I'm talking about proper flowing designs, now pixel-based, fixed-width
 ones. Those are fairly easy in both HTML and GUI toolkits).


 It does not feel convoluted to me but I have learned HTML/CSS gradually
 as they evolved. Therefore I might not be able to properly see how it
 looks from the distance if someone doesn't know the details. To me it
 looks well structured (block vs. inline elements, different distinct
 layout models, typography, etc.). There sure a some parts that deserve a
 little cleanup and simplification but I can't think of any right now.

 I'm just curious about your point of view. What parts of CSS look
 convoluted to you?


The layout rules. I don't remember the details, because again I've 
forgotten the rules and most of what I learned then. There is only issue 
I can remember on the top of my head:
  * If you have two nested divs, and the inner div has a position value 
other than "fixed", it is not true that the inner div is visually 
contained on the other div! That makes no sense to me. You have to add 
some properties to the outer div (such as overflow:hidden) to make it 
so, but it usually these properties have side-effects that are adverse 
to other aspects of the layout.



 And what do you mean "use JavaScript for layout"? You can't use
 JavaScript for layout. You can use JavaScript to programmatically
 manipulate the CSS properties of HTML elements, but you are still using
 the same HTML rules for layout, so the difficulty is unchanged.


 You're right. At the end HTML/CSS simply is the interface to tell the
 browser about the structure and appearance of your document. However you
 can make every element a block level element ("display: block;") and use
 absolute positioning. Then each element basically behaves like a window
 of an window manager and you can use your own algorithms to do the
 layout by calculating the position and dimensions (top, left, height,
 width). At that stage you don't have to think about any of the layout
 models of CSS and you're totally independent of them.

 Happy programming
 Stephan


Ah, I see what you mean now. Yes, then you could have your own rules and 
layout system, assuming HTML Javascript can detect window resizes (from 
what I recall it can, but I'm sure if it is possible in a 
standards-compliant way, or if it has to be browser specific).
But even if possible, this approach would be awful : you would need JS 
enabled to layout your site, plus you would incur a heavy performance 
penalty for all the JS code you'd be executing.


-- 
Bruno Medeiros - Software Engineer
Oct 13 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 13.10.2010 14:30, Bruno Medeiros wrote:

 On 10/10/2010 15:23, Stephan Soller wrote:

 On 07.10.2010 11:41, Bruno Medeiros wrote:

 On 06/10/2010 15:25, Stephan Soller wrote:

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in
 terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications. If you want
 you
 can simply make every element a block level element and use JavaScript
 for layout. I don't know GTK and QT in depth but then you should have
 about the same level of possibilities as with these layout engines. It
 wouldn't surprise me if GUI frameworks like jQuery UI actually do this.


 The issue is not with level of possibilites. HTML/CSS has as much
 possibilities as many GUI toolkits, if not more. (there is really a lot
 of stuff you can do you HTML/CSS if you figure out how to). The issue is
 that it's incredibly hard to do that, HTML/CSS is so convoluted. (and
 I'm talking about proper flowing designs, now pixel-based, fixed-width
 ones. Those are fairly easy in both HTML and GUI toolkits).


 It does not feel convoluted to me but I have learned HTML/CSS gradually
 as they evolved. Therefore I might not be able to properly see how it
 looks from the distance if someone doesn't know the details. To me it
 looks well structured (block vs. inline elements, different distinct
 layout models, typography, etc.). There sure a some parts that deserve a
 little cleanup and simplification but I can't think of any right now.

 I'm just curious about your point of view. What parts of CSS look
 convoluted to you?


 The layout rules. I don't remember the details, because again I've
 forgotten the rules and most of what I learned then. There is only issue
 I can remember on the top of my head:
 * If you have two nested divs, and the inner div has a position value
 other than "fixed", it is not true that the inner div is visually
 contained on the other div! That makes no sense to me. You have to add
 some properties to the outer div (such as overflow:hidden) to make it
 so, but it usually these properties have side-effects that are adverse
 to other aspects of the layout.


I think you are confusing two things. The "position" property does not 
influence how large an element is (it contains all it's normal content). 
The value "static" is the default value and does nothing at all (the box 
is not positioned, that's what you probably meant with "fixed"). 
"absolute" lets you position the box at arbitrary coordinates but also 
takes it "out of the flow". That is all elements after it ignore 
absolute positioned boxes. This effectively allows you to layer stuff 
like you want. There are some more values ("relative" and "fixed") but 
this isn't a CSS lesson.

The behavior you describe is a "problem" of the float layout model. If 
you float an element left or right it is taken out of the normal 
document flow but all following content flows around it. This was 
defined for pictures or figure in texts. You can then use the "clear" 
property on the next paragraph to stop it from flowing around the picture.

Since early CSS had no proper layout model for multiple variable height 
columns (like tables are by definition) man people used the float layout 
model to "emulate" multiple columns. The problem with this is that the 
floated columns are taken out of the normal document flow. Therefore the 
parent element does not contain them and usually collapses to zero 
height. To avoid this you can either add a clearer after the columns or 
use the "overflow" trick (any value other than "visible" will do) which 
will make the parent box containing all it's floated child elements. 
This works in IE 6 and does not need an extra element. Therefore it's 
the most used technique now. But all this does not change the fact that 
using floats for column layouts is still nothing else than a workaround 
for the missing column layout model in the early days.

For many page layouts this actually isn't needed but especially people 
used to use tables for layouts often try to use this technique because 
it mimics tables more or less. With CSS tables you don't have to use 
floats any more since you have all the power of tables in CSS now (with 
less markup in most cases). These however only work with IE 8 or newer 
(I'm not sure if not already in IE 7) and I don't know about FF 2. If 
you have to make pages that work in IE 6 and 7 you still have to use 
floats though.


 And what do you mean "use JavaScript for layout"? You can't use
 JavaScript for layout. You can use JavaScript to programmatically
 manipulate the CSS properties of HTML elements, but you are still using
 the same HTML rules for layout, so the difficulty is unchanged.


 You're right. At the end HTML/CSS simply is the interface to tell the
 browser about the structure and appearance of your document. However you
 can make every element a block level element ("display: block;") and use
 absolute positioning. Then each element basically behaves like a window
 of an window manager and you can use your own algorithms to do the
 layout by calculating the position and dimensions (top, left, height,
 width). At that stage you don't have to think about any of the layout
 models of CSS and you're totally independent of them.

 Happy programming
 Stephan


 Ah, I see what you mean now. Yes, then you could have your own rules and
 layout system, assuming HTML Javascript can detect window resizes (from
 what I recall it can, but I'm sure if it is possible in a
 standards-compliant way, or if it has to be browser specific).
 But even if possible, this approach would be awful : you would need JS
 enabled to layout your site, plus you would incur a heavy performance
 penalty for all the JS code you'd be executing.


JS can detect window resizes (there's an event for it). The JS speed 
shouldn't be a problem (IE 6 is pretty slow though) as long as you don't 
layout an entire operating system with it. JS has become pretty fast in 
the last few years.

To rely on JavaScript isn't a problem for most "application" since the 
application itself only works with enabled JS, too. "application" does 
mean something like a desktop like application with reacts to 
interactive events without page reloads. Since that requires HTTP 
requests in the background you have your JS dependency anyway.

On websites however required JS support is more of a problem. But in my 
experience websites are structured like documents most of the time (they 
at least try to deliver content, many big cooperation websites however 
totally fail here…). In this case the layout models CSS provides are 
often quite handy and match for most if not all cases.

In short:
- For websites or documents CSS fits well
- For applications you can use JS for layout since it's needed anyway

Happy programming
Stephan
Oct 13 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 13/10/2010 17:42, Stephan Soller wrote:

 On 13.10.2010 14:30, Bruno Medeiros wrote:

 On 10/10/2010 15:23, Stephan Soller wrote:

 On 07.10.2010 11:41, Bruno Medeiros wrote:

 On 06/10/2010 15:25, Stephan Soller wrote:

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in
 terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications. If you want
 you
 can simply make every element a block level element and use JavaScript
 for layout. I don't know GTK and QT in depth but then you should have
 about the same level of possibilities as with these layout engines. It
 wouldn't surprise me if GUI frameworks like jQuery UI actually do
 this.


 The issue is not with level of possibilites. HTML/CSS has as much
 possibilities as many GUI toolkits, if not more. (there is really a lot
 of stuff you can do you HTML/CSS if you figure out how to). The
 issue is
 that it's incredibly hard to do that, HTML/CSS is so convoluted. (and
 I'm talking about proper flowing designs, now pixel-based, fixed-width
 ones. Those are fairly easy in both HTML and GUI toolkits).


 It does not feel convoluted to me but I have learned HTML/CSS gradually
 as they evolved. Therefore I might not be able to properly see how it
 looks from the distance if someone doesn't know the details. To me it
 looks well structured (block vs. inline elements, different distinct
 layout models, typography, etc.). There sure a some parts that deserve a
 little cleanup and simplification but I can't think of any right now.

 I'm just curious about your point of view. What parts of CSS look
 convoluted to you?


 The layout rules. I don't remember the details, because again I've
 forgotten the rules and most of what I learned then. There is only issue
 I can remember on the top of my head:
 * If you have two nested divs, and the inner div has a position value
 other than "fixed", it is not true that the inner div is visually
 contained on the other div! That makes no sense to me. You have to add
 some properties to the outer div (such as overflow:hidden) to make it
 so, but it usually these properties have side-effects that are adverse
 to other aspects of the layout.


 I think you are confusing two things. The "position" property does not
 influence how large an element is (it contains all it's normal content).
 The value "static" is the default value and does nothing at all (the box
 is not positioned, that's what you probably meant with "fixed").
 "absolute" lets you position the box at arbitrary coordinates but also
 takes it "out of the flow". That is all elements after it ignore
 absolute positioned boxes. This effectively allows you to layer stuff
 like you want. There are some more values ("relative" and "fixed") but
 this isn't a CSS lesson.


There is no confusion, I know "the "position" property does not 
influence how large an element is". I don't care how big or small the 
inner div is, I just want it to be contained in the parent div. I just 
mentioned the 'position' property because if position is 'fixed', it 
does make sense for that div not to be considered as contained in the 
parent div. But not so for other values of position (at least for the 
default one).



 The behavior you describe is a "problem" of the float layout model. If
 you float an element left or right it is taken out of the normal
 document flow but all following content flows around it. This was
 defined for pictures or figure in texts. You can then use the "clear"
 property on the next paragraph to stop it from flowing around the picture.

 Since early CSS had no proper layout model for multiple variable height
 columns (like tables are by definition) man people used the float layout
 model to "emulate" multiple columns. The problem with this is that the
 floated columns are taken out of the normal document flow. Therefore the
 parent element does not contain them and usually collapses to zero
 height. To avoid this you can either add a clearer after the columns or
 use the "overflow" trick (any value other than "visible" will do) which
 will make the parent box containing all it's floated child elements.
 This works in IE 6 and does not need an extra element. Therefore it's
 the most used technique now.


Yes, I forgot to mention in my example that the problem happens when 
float is used in the inner div. Thanks for noticing that.
Indeed, using a clearer div seems to solve the problem as, and likely 
with less side-effects. Not sure if it is completely side-effect free 
though.



But all this does not change the fact that
 using floats for column layouts is still nothing else than a workaround
 for the missing column layout model in the early days.

 For many page layouts this actually isn't needed but especially people
 used to use tables for layouts often try to use this technique because
 it mimics tables more or less. With CSS tables you don't have to use
 floats any more since you have all the power of tables in CSS now (with
 less markup in most cases). These however only work with IE 8 or newer
 (I'm not sure if not already in IE 7) and I don't know about FF 2. If
 you have to make pages that work in IE 6 and 7 you still have to use
 floats though.


Well I would say some sort of "column layout model" (if understood your 
term correctly) is pretty essential. You need something like that, or 
something that can do the same job nearly as easily. So are you saying 
its ok to use CSS tables now? (disregarding the issue with old browsers)
Because when I first learned about CSS and div layouts, the mantra was 
"tables are evil, don't use tables".


 And what do you mean "use JavaScript for layout"? You can't use
 JavaScript for layout. You can use JavaScript to programmatically
 manipulate the CSS properties of HTML elements, but you are still using
 the same HTML rules for layout, so the difficulty is unchanged.


 You're right. At the end HTML/CSS simply is the interface to tell the
 browser about the structure and appearance of your document. However you
 can make every element a block level element ("display: block;") and use
 absolute positioning. Then each element basically behaves like a window
 of an window manager and you can use your own algorithms to do the
 layout by calculating the position and dimensions (top, left, height,
 width). At that stage you don't have to think about any of the layout
 models of CSS and you're totally independent of them.

 Happy programming
 Stephan


 Ah, I see what you mean now. Yes, then you could have your own rules and
 layout system, assuming HTML Javascript can detect window resizes (from
 what I recall it can, but I'm sure if it is possible in a
 standards-compliant way, or if it has to be browser specific).
 But even if possible, this approach would be awful : you would need JS
 enabled to layout your site, plus you would incur a heavy performance
 penalty for all the JS code you'd be executing.


 JS can detect window resizes (there's an event for it). The JS speed
 shouldn't be a problem (IE 6 is pretty slow though) as long as you don't
 layout an entire operating system with it. JS has become pretty fast in
 the last few years.

 To rely on JavaScript isn't a problem for most "application" since the
 application itself only works with enabled JS, too. "application" does
 mean something like a desktop like application with reacts to
 interactive events without page reloads. Since that requires HTTP
 requests in the background you have your JS dependency anyway.

 On websites however required JS support is more of a problem. But in my
 experience websites are structured like documents most of the time (they
 at least try to deliver content, many big cooperation websites however
 totally fail here…). In this case the layout models CSS provides are
 often quite handy and match for most if not all cases.

 In short:
 - For websites or documents CSS fits well
 - For applications you can use JS for layout since it's needed anyway

 Happy programming
 Stephan



For websites or documents CSS fits well.


That statement is true but completely irrelevant: This particular line 
of discussion was about how feasible it would be to use JS for layout, 
and JS only, nothing else of CSS, except for manipulating "position and 
dimensions" properties.
As such I made a statement about what the disadvantages of having to use 
JS would be in websites, HTML documents, or any other scenario.


-- 
Bruno Medeiros - Software Engineer
Oct 13 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 13.10.2010 22:39, Bruno Medeiros wrote:

 On 13/10/2010 17:42, Stephan Soller wrote:

 On 13.10.2010 14:30, Bruno Medeiros wrote:

 On 10/10/2010 15:23, Stephan Soller wrote:

 On 07.10.2010 11:41, Bruno Medeiros wrote:

 On 06/10/2010 15:25, Stephan Soller wrote:

 On 06.10.2010 02:08, Arlo White wrote:

 That's because HTML/CSS is a pretty terrible language for anything
 beyond simple layouts. It shares more with Word/PDF/PostScript in
 terms
 of its purpose and history than it does with real gui layout engines
 (GTK, QT, etc).


 HTML/CSS is primary made for documents not applications. If you want
 you
 can simply make every element a block level element and use
 JavaScript
 for layout. I don't know GTK and QT in depth but then you should have
 about the same level of possibilities as with these layout
 engines. It
 wouldn't surprise me if GUI frameworks like jQuery UI actually do
 this.


 The issue is not with level of possibilites. HTML/CSS has as much
 possibilities as many GUI toolkits, if not more. (there is really a
 lot
 of stuff you can do you HTML/CSS if you figure out how to). The
 issue is
 that it's incredibly hard to do that, HTML/CSS is so convoluted. (and
 I'm talking about proper flowing designs, now pixel-based, fixed-width
 ones. Those are fairly easy in both HTML and GUI toolkits).


 It does not feel convoluted to me but I have learned HTML/CSS gradually
 as they evolved. Therefore I might not be able to properly see how it
 looks from the distance if someone doesn't know the details. To me it
 looks well structured (block vs. inline elements, different distinct
 layout models, typography, etc.). There sure a some parts that
 deserve a
 little cleanup and simplification but I can't think of any right now.

 I'm just curious about your point of view. What parts of CSS look
 convoluted to you?


 The layout rules. I don't remember the details, because again I've
 forgotten the rules and most of what I learned then. There is only issue
 I can remember on the top of my head:
 * If you have two nested divs, and the inner div has a position value
 other than "fixed", it is not true that the inner div is visually
 contained on the other div! That makes no sense to me. You have to add
 some properties to the outer div (such as overflow:hidden) to make it
 so, but it usually these properties have side-effects that are adverse
 to other aspects of the layout.


 I think you are confusing two things. The "position" property does not
 influence how large an element is (it contains all it's normal content).
 The value "static" is the default value and does nothing at all (the box
 is not positioned, that's what you probably meant with "fixed").
 "absolute" lets you position the box at arbitrary coordinates but also
 takes it "out of the flow". That is all elements after it ignore
 absolute positioned boxes. This effectively allows you to layer stuff
 like you want. There are some more values ("relative" and "fixed") but
 this isn't a CSS lesson.


 There is no confusion, I know "the "position" property does not
 influence how large an element is". I don't care how big or small the
 inner div is, I just want it to be contained in the parent div. I just
 mentioned the 'position' property because if position is 'fixed', it
 does make sense for that div not to be considered as contained in the
 parent div. But not so for other values of position (at least for the
 default one).


Sorry, look like I got confused then. :)

I'm still not sure if I understand your point correctly. Do you mean 
that it's inconsistent that some positioning models take the element out 
of the document flow?


 The behavior you describe is a "problem" of the float layout model. If
 you float an element left or right it is taken out of the normal
 document flow but all following content flows around it. This was
 defined for pictures or figure in texts. You can then use the "clear"
 property on the next paragraph to stop it from flowing around the
 picture.

 Since early CSS had no proper layout model for multiple variable height
 columns (like tables are by definition) man people used the float layout
 model to "emulate" multiple columns. The problem with this is that the
 floated columns are taken out of the normal document flow. Therefore the
 parent element does not contain them and usually collapses to zero
 height. To avoid this you can either add a clearer after the columns or
 use the "overflow" trick (any value other than "visible" will do) which
 will make the parent box containing all it's floated child elements.
 This works in IE 6 and does not need an extra element. Therefore it's
 the most used technique now.


 Yes, I forgot to mention in my example that the problem happens when
 float is used in the inner div. Thanks for noticing that.
 Indeed, using a clearer div seems to solve the problem as, and likely
 with less side-effects. Not sure if it is completely side-effect free
 though.



 But all this does not change the fact that
 using floats for column layouts is still nothing else than a workaround
 for the missing column layout model in the early days.

 For many page layouts this actually isn't needed but especially people
 used to use tables for layouts often try to use this technique because
 it mimics tables more or less. With CSS tables you don't have to use
 floats any more since you have all the power of tables in CSS now (with
 less markup in most cases). These however only work with IE 8 or newer
 (I'm not sure if not already in IE 7) and I don't know about FF 2. If
 you have to make pages that work in IE 6 and 7 you still have to use
 floats though.


 Well I would say some sort of "column layout model" (if understood your
 term correctly) is pretty essential. You need something like that, or
 something that can do the same job nearly as easily. So are you saying
 its ok to use CSS tables now? (disregarding the issue with old browsers)
 Because when I first learned about CSS and div layouts, the mantra was
 "tables are evil, don't use tables".


I also heard/read that a lot when learning CSS. Using table _elements_ 
for layout is bad stuff since the table element in HTML indicates 
tabular data. If you use it for layout the abstract content (or data) of 
the page gets totally screwed up just for it to look right.

However the layout rules of tables are quite useful and so they found 
their way into CSS. If you can properly separate data from presentation
you can use whatever layout rules you want. ;)

Basically don't use table _data_ to push elements around in HTML. Using 
table layout rules in CSS is ok since it does not interfere with the 
data of the page.


 And what do you mean "use JavaScript for layout"? You can't use
 JavaScript for layout. You can use JavaScript to programmatically
 manipulate the CSS properties of HTML elements, but you are still
 using
 the same HTML rules for layout, so the difficulty is unchanged.


 You're right. At the end HTML/CSS simply is the interface to tell the
 browser about the structure and appearance of your document. However
 you
 can make every element a block level element ("display: block;") and
 use
 absolute positioning. Then each element basically behaves like a window
 of an window manager and you can use your own algorithms to do the
 layout by calculating the position and dimensions (top, left, height,
 width). At that stage you don't have to think about any of the layout
 models of CSS and you're totally independent of them.

 Happy programming
 Stephan


 Ah, I see what you mean now. Yes, then you could have your own rules and
 layout system, assuming HTML Javascript can detect window resizes (from
 what I recall it can, but I'm sure if it is possible in a
 standards-compliant way, or if it has to be browser specific).
 But even if possible, this approach would be awful : you would need JS
 enabled to layout your site, plus you would incur a heavy performance
 penalty for all the JS code you'd be executing.


 JS can detect window resizes (there's an event for it). The JS speed
 shouldn't be a problem (IE 6 is pretty slow though) as long as you don't
 layout an entire operating system with it. JS has become pretty fast in
 the last few years.

 To rely on JavaScript isn't a problem for most "application" since the
 application itself only works with enabled JS, too. "application" does
 mean something like a desktop like application with reacts to
 interactive events without page reloads. Since that requires HTTP
 requests in the background you have your JS dependency anyway.

 On websites however required JS support is more of a problem. But in my
 experience websites are structured like documents most of the time (they
 at least try to deliver content, many big cooperation websites however
 totally fail here…). In this case the layout models CSS provides are
 often quite handy and match for most if not all cases.

 In short:
 - For websites or documents CSS fits well
 - For applications you can use JS for layout since it's needed anyway

 Happy programming
 Stephan


  >For websites or documents CSS fits well.

 That statement is true but completely irrelevant: This particular line
 of discussion was about how feasible it would be to use JS for layout,
 and JS only, nothing else of CSS, except for manipulating "position and
 dimensions" properties.
 As such I made a statement about what the disadvantages of having to use
 JS would be in websites, HTML documents, or any other scenario.


I see now, I somewhat missed the point. For many situation (e.g. 
websites) I agree with you that using only JS for layout is awful. But 
there are also situations where this approach looks ok (e.g. rich client 
side applications).

Happy programming
Stephan
Oct 14 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 14/10/2010 09:09, Stephan Soller wrote:

 There is no confusion, I know "the "position" property does not
 influence how large an element is". I don't care how big or small the
 inner div is, I just want it to be contained in the parent div. I just
 mentioned the 'position' property because if position is 'fixed', it
 does make sense for that div not to be considered as contained in the
 parent div. But not so for other values of position (at least for the
 default one).


 Sorry, look like I got confused then. :)

 I'm still not sure if I understand your point correctly. Do you mean
 that it's inconsistent that some positioning models take the element out
 of the document flow?


Not exactly. My problem is that when an element is taken out of the flow 
(such as with "float:left"), it means the element no longer needs to be 
contained in the parent div. I think that model is very unhelpful. 
Although I'm no expert in HTML coding, I would venture that in at least 
90% of the cases that's what you want (for the element to be contained 
in the parent, if its position is not 'fixed').
Otherwise this brings up several problems: it messes up the layout of 
the elements right after the parent div. Or it messes up the area for 
the background/border colors of the parent div.
However if a clearer div works without additional problems, I'm probably 
happy with that, even if its more verbose.



 But all this does not change the fact that
 using floats for column layouts is still nothing else than a workaround
 for the missing column layout model in the early days.

 For many page layouts this actually isn't needed but especially people
 used to use tables for layouts often try to use this technique because
 it mimics tables more or less. With CSS tables you don't have to use
 floats any more since you have all the power of tables in CSS now (with
 less markup in most cases). These however only work with IE 8 or newer
 (I'm not sure if not already in IE 7) and I don't know about FF 2. If
 you have to make pages that work in IE 6 and 7 you still have to use
 floats though.


 Well I would say some sort of "column layout model" (if understood your
 term correctly) is pretty essential. You need something like that, or
 something that can do the same job nearly as easily. So are you saying
 its ok to use CSS tables now? (disregarding the issue with old browsers)
 Because when I first learned about CSS and div layouts, the mantra was
 "tables are evil, don't use tables".


 I also heard/read that a lot when learning CSS. Using table _elements_
 for layout is bad stuff since the table element in HTML indicates
 tabular data. If you use it for layout the abstract content (or data) of
 the page gets totally screwed up just for it to look right.

 However the layout rules of tables are quite useful and so they found
 their way into CSS. If you can properly separate data from presentation
 you can use whatever layout rules you want. ;)

 Basically don't use table _data_ to push elements around in HTML. Using
 table layout rules in CSS is ok since it does not interfere with the
 data of the page.


Ok, so it is as I thought, is is still "wrong"/unrecommended to use 
tables for layout. The recommended way to do column layouts is still 
with divs, right? By "column layouts" I don't mean tables, but stuff 
like a sidebar of any kind (the typical two or tree column layout).

-- 
Bruno Medeiros - Software Engineer
Oct 14 2010
parent Stephan Soller <stephan.soller helionweb.de> writes:
On 14.10.2010 13:03, Bruno Medeiros wrote:

 On 14/10/2010 09:09, Stephan Soller wrote:

 There is no confusion, I know "the "position" property does not
 influence how large an element is". I don't care how big or small the
 inner div is, I just want it to be contained in the parent div. I just
 mentioned the 'position' property because if position is 'fixed', it
 does make sense for that div not to be considered as contained in the
 parent div. But not so for other values of position (at least for the
 default one).


 Sorry, look like I got confused then. :)

 I'm still not sure if I understand your point correctly. Do you mean
 that it's inconsistent that some positioning models take the element out
 of the document flow?


 Not exactly. My problem is that when an element is taken out of the flow
 (such as with "float:left"), it means the element no longer needs to be
 contained in the parent div. I think that model is very unhelpful.
 Although I'm no expert in HTML coding, I would venture that in at least
 90% of the cases that's what you want (for the element to be contained
 in the parent, if its position is not 'fixed').
 Otherwise this brings up several problems: it messes up the layout of
 the elements right after the parent div. Or it messes up the area for
 the background/border colors of the parent div.
 However if a clearer div works without additional problems, I'm probably
 happy with that, even if its more verbose.


In the context of using floats for multi column layout I agree with you. 
It just doesn't make sense for the parent element to not contain any 
floating child elements. I looked in the CSS 2.1 spec to figure out why 
they defined it this way and the third example in the [section about 
floats][1] makes it pretty clear. Basically if you float an image in a 
paragraph you want the next paragraph to float around it, too. If you 
don't want it set the "clear" property of the next element (e.g. 
headlines). Therefore the "cross border of parent box" default is a good 
choice in such situations.

When using floats for layout I would rather like the default to be that 
floats are contained in their parent boxes. But that is not what floats 
were made for so the decision is ok IMHO.

[1]: http://www.w3.org/TR/CSS21/visuren.html#floats


 But all this does not change the fact that
 using floats for column layouts is still nothing else than a workaround
 for the missing column layout model in the early days.

 For many page layouts this actually isn't needed but especially people
 used to use tables for layouts often try to use this technique because
 it mimics tables more or less. With CSS tables you don't have to use
 floats any more since you have all the power of tables in CSS now (with
 less markup in most cases). These however only work with IE 8 or newer
 (I'm not sure if not already in IE 7) and I don't know about FF 2. If
 you have to make pages that work in IE 6 and 7 you still have to use
 floats though.


 Well I would say some sort of "column layout model" (if understood your
 term correctly) is pretty essential. You need something like that, or
 something that can do the same job nearly as easily. So are you saying
 its ok to use CSS tables now? (disregarding the issue with old browsers)
 Because when I first learned about CSS and div layouts, the mantra was
 "tables are evil, don't use tables".


 I also heard/read that a lot when learning CSS. Using table _elements_
 for layout is bad stuff since the table element in HTML indicates
 tabular data. If you use it for layout the abstract content (or data) of
 the page gets totally screwed up just for it to look right.

 However the layout rules of tables are quite useful and so they found
 their way into CSS. If you can properly separate data from presentation
 you can use whatever layout rules you want. ;)

 Basically don't use table _data_ to push elements around in HTML. Using
 table layout rules in CSS is ok since it does not interfere with the
 data of the page.


 Ok, so it is as I thought, is is still "wrong"/unrecommended to use
 tables for layout. The recommended way to do column layouts is still
 with divs, right? By "column layouts" I don't mean tables, but stuff
 like a sidebar of any kind (the typical two or tree column layout).


Yes, in HTML4 and XHTML 1 you would use div elements for each "column". 
I actually don't like that very much because it usually ends with a lot 
of div elements that don't add any useful information to the document. 
It's still better than tables though because table elements have a 
meaning that isn't met. But that's a problem of these two HTML versions 
(they lack structural block level elements). HTML5 adds more meaningful 
elements for that purpose (section, aside, header, footer, …) but that's 
a different story.

Happy programming
Stephan
Oct 14 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-10-04 14:42:22 -0400, Walter Bright <newshound2 digitalmars.com> said:


 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 
 The annoying thing about this is everyone says "don't use tables for 
 layout, use CSS." Except that using CSS for layout DOESN'T WORK 
 RELIABLY. With tables, I can get 3 columns that are actually 3 columns, 
 not 3 columns that are a side effect of bugs in CSS.


Very true. CSS is great, except when you want columns, especially more 
than 2 columns with where columns have a background that must end at 
the same height.

That said, you could play with `display: table`. But the basic problem 
with `display: table` (like many "advanced" things in CSS) is that it 
won't work much with IE less than 8. Can you believe it took so long 
for Microsoft to implement this important part of a specification from 
2009 (CSS 2.1)? This is really the problem with the web: the dominant 
browser stopped evolving during a long period and is only now beginning 
to catch up. So now we're navigating in a sea of workarounds because 
everyone needs columns and other things that need a hack to work in IE.

Let's hope it gets better in the coming years as older versions of IE 
become obsolete.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 04 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:

 Very true. CSS is great, except when you want columns, especially more 
 than 2 columns with where columns have a background that must end at the 
 same height.
 
 That said, you could play with `display: table`. But the basic problem 
 with `display: table` (like many "advanced" things in CSS) is that it 
 won't work much with IE less than 8. Can you believe it took so long for 
 Microsoft to implement this important part of a specification from 2009 
 (CSS 2.1)? This is really the problem with the web: the dominant browser 
 stopped evolving during a long period and is only now beginning to catch 
 up. So now we're navigating in a sea of workarounds because everyone 
 needs columns and other things that need a hack to work in IE.


Looks like I'm going back to < table > tags.
Oct 04 2010
prev sibling next sibling parent Juanjo Alvarez <fake fakeemail.com> writes:
On Mon, 04 Oct 2010 11:42:22 -0700, Walter Bright 
<newshound2 digitalmars.com> wrote:

 CSS." Except that using CSS for layout DOESN'T WORK RELIABLY. With 


tables, I can 

 get 3 columns that are actually 3 columns, not 3 columns that are a 


side effect 

 of bugs in CSS.


If you hate CSS as much as I do take a look at the Blueprint CSS 
"framework". Its 20 minutes to learn it and the best investment in 
time you can do.
Oct 04 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i8d77c$1bf1$1 digitalmars.com...

 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 The annoying thing about this is everyone says "don't use tables for 
 layout, use CSS." Except that using CSS for layout DOESN'T WORK RELIABLY. 
 With tables, I can get 3 columns that are actually 3 columns, not 3 
 columns that are a side effect of bugs in CSS.


YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even 
been meaning to write up a little article about it. For styling, CSS is, 
umm, acceptable. But it's crap for layout. And every argument I've seen 
against using tables for layout has been either extremely minor, 
questionable/uncited, or just plain bullcrap.

Speaking of, if anyone has links to well-regarded "why you shouldn't use 
tables for layout" information, please post them. Whenever I get around to 
doing that little write-up I'd like to try to refute as much as I can. Or be 
proven wrong before making a bigger ass of myself. Either way :)
Oct 04 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 05.10.2010 04:28, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:i8d77c$1bf1$1 digitalmars.com...

 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 The annoying thing about this is everyone says "don't use tables for
 layout, use CSS." Except that using CSS for layout DOESN'T WORK RELIABLY.
 With tables, I can get 3 columns that are actually 3 columns, not 3
 columns that are a side effect of bugs in CSS.


 YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even
 been meaning to write up a little article about it. For styling, CSS is,
 umm, acceptable. But it's crap for layout. And every argument I've seen
 against using tables for layout has been either extremely minor,
 questionable/uncited, or just plain bullcrap.

 Speaking of, if anyone has links to well-regarded "why you shouldn't use
 tables for layout" information, please post them. Whenever I get around to
 doing that little write-up I'd like to try to refute as much as I can. Or be
 proven wrong before making a bigger ass of myself. Either way :)


The point in not using the table _element_ for layout is that HTML 
should be used to define the _content_ of your page not its appearance. 
It's all about what kind of data you have at hand: a heading, a list, 
tabular data, a figure with an image, etc. It says nothing about how the 
page is supposed to look, it's just the pure content.

After defining the content the appearance is setup with CSS. And there 
table layouts are used pretty often (if not always). If you don't care 
about older IE versions you can use "display: table" and companions. 
Basically these display properties just make elements behave like the 
corresponding HTML elements (e.g. "table-cell" maps to the td element).

Prior to that CSS only had mechanisms for defining float layouts (the 
"float" property) but these can be used for table layout, too. It's not
that difficult but it's less flexible. All you need is a container with 
"overflow: hidden". To create columns inside it just set some child 
elements to "fload: left". This will look like this:

     -- overflow: hidden ----------------------
     |                                        |
     |  -- float: left --  -- float: left --  |
     |  |               |  |               |  |
     |  |               |  |               |  |
     |  |               |  |               |  |
     |  |               |  -----------------  |
     |  |               |                     |
     |  -----------------                     |
     |                                        |
     ------------------------------------------

This method works quite well, only IE 6 makes some trouble because the 
floats trigger some bugs (but if you add a few pixels of reserve space 
it will be all right for IE 6). The main drawback of this method is that 
the floated boxes are independent of each other, each gets its own 
height and with. If you want them to have a consistent layout you have 
to assign fixed widths and highs. There are some workarounds for this 
(e.g. using a repeating background image on the container) but I suppose 
I already talked to much about CSS.

Basically it's all about separation of content and presentation. It's 
not always easy (nor always necessary) but if done right you don't have 
to touch the HTML code for your next redesign (and the search engines 
are very happy about proper HTML code, too).

ps.: I'm usually only reading this newsgroup because I'm somewhat new to 
D. But I couldn't resist answering about CSS. ;)


Happy programming

Stephan Soller
Oct 05 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8epjv$1d3p$1 digitalmars.com...

 On 05.10.2010 04:28, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:i8d77c$1bf1$1 digitalmars.com...

 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 The annoying thing about this is everyone says "don't use tables for
 layout, use CSS." Except that using CSS for layout DOESN'T WORK 
 RELIABLY.
 With tables, I can get 3 columns that are actually 3 columns, not 3
 columns that are a side effect of bugs in CSS.


 YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even
 been meaning to write up a little article about it. For styling, CSS is,
 umm, acceptable. But it's crap for layout. And every argument I've seen
 against using tables for layout has been either extremely minor,
 questionable/uncited, or just plain bullcrap.

 Speaking of, if anyone has links to well-regarded "why you shouldn't use
 tables for layout" information, please post them. Whenever I get around 
 to
 doing that little write-up I'd like to try to refute as much as I can. Or 
 be
 proven wrong before making a bigger ass of myself. Either way :)


 The point in not using the table _element_ for layout is that HTML should 
 be used to define the _content_ of your page not its appearance.


...

 Basically it's all about separation of content and presentation. It's not 
 always easy (nor always necessary) but if done right you don't have to 
 touch the HTML code for your next redesign (and the search engines are 
 very happy about proper HTML code, too).


Yea, I do agree in principle. But in my experience, certain realities of CSS 
complicate the issue.

Basically, I've spent enormus amounts of time and energy getting certain 
layouts to work properly and reliably in CSS. There's been plenty of times 
I've come across that and eventualy just threw my hands up and said "Ok, the 
heck with purity and ideals, I just need to get it done: So hello tables!". 
And every single time I've done that everything went smooth from that point 
on.

If CSS could handle layouts as well as tables can, then I would be all for 
abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see 
it progressing much.

Plus I often find redesigning HTML a lot more straightforward than tweaking 
typical production-scale CSS (CSS can get real hairy real quick).

Not only that, I've recently started doing my sites in a very 
MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is* 
just as much part of the view as the CSS anyway. And all I have to do to 
redesign it is just tweak an html template file. As a bonus, that allows for 
much more flexibility in my redesigns (and much more easily) than CSS could 
ever hope to achieve without CSS itself getting a fundamental overhaul.


 ps.: I'm usually only reading this newsgroup because I'm somewhat new to 
 D. But I couldn't resist answering about CSS. ;)


Welcome :)
Oct 05 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 05.10.2010 12:13, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8epjv$1d3p$1 digitalmars.com...

 On 05.10.2010 04:28, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>   wrote in message
 news:i8d77c$1bf1$1 digitalmars.com...

 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 The annoying thing about this is everyone says "don't use tables for
 layout, use CSS." Except that using CSS for layout DOESN'T WORK
 RELIABLY.
 With tables, I can get 3 columns that are actually 3 columns, not 3
 columns that are a side effect of bugs in CSS.


 YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even
 been meaning to write up a little article about it. For styling, CSS is,
 umm, acceptable. But it's crap for layout. And every argument I've seen
 against using tables for layout has been either extremely minor,
 questionable/uncited, or just plain bullcrap.

 Speaking of, if anyone has links to well-regarded "why you shouldn't use
 tables for layout" information, please post them. Whenever I get around
 to
 doing that little write-up I'd like to try to refute as much as I can. Or
 be
 proven wrong before making a bigger ass of myself. Either way :)


 The point in not using the table _element_ for layout is that HTML should
 be used to define the _content_ of your page not its appearance.


 ...

 Basically it's all about separation of content and presentation. It's not
 always easy (nor always necessary) but if done right you don't have to
 touch the HTML code for your next redesign (and the search engines are
 very happy about proper HTML code, too).


 Yea, I do agree in principle. But in my experience, certain realities of CSS
 complicate the issue.

 Basically, I've spent enormus amounts of time and energy getting certain
 layouts to work properly and reliably in CSS. There's been plenty of times
 I've come across that and eventualy just threw my hands up and said "Ok, the
 heck with purity and ideals, I just need to get it done: So hello tables!".
 And every single time I've done that everything went smooth from that point
 on.

 If CSS could handle layouts as well as tables can, then I would be all for
 abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see
 it progressing much.

 Plus I often find redesigning HTML a lot more straightforward than tweaking
 typical production-scale CSS (CSS can get real hairy real quick).

 Not only that, I've recently started doing my sites in a very
 MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is*
 just as much part of the view as the CSS anyway. And all I have to do to
 redesign it is just tweak an html template file. As a bonus, that allows for
 much more flexibility in my redesigns (and much more easily) than CSS could
 ever hope to achieve without CSS itself getting a fundamental overhaul.


 ps.: I'm usually only reading this newsgroup because I'm somewhat new to
 D. But I couldn't resist answering about CSS. ;)


 Welcome :)


Thanks. :)

I have to agree that CSS layout techniques have a somewhat steep 
learning curve. It's straight forward to use floating boxes for column 
layouts and bugs in IE still hurt. However it's the same in every 
language/field (e.g. it was totally new to me to use "() ? x : y" to get 
the common type of two expressions). Once you get to know some of the 
techniques it's way more easy to do stuff in CSS, often just because you 
have less text to type and everything in one place (a few lines in a CSS 
file).


 If CSS could handle layouts as well as tables can, then I would be all for
 abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see
 it progressing much.


CSS is absolutely ready, IE 6 and 7 are not. As soon as you can assume 
IE 8 or any decent browser you can use CSS tables. Sitepoints Book 
[Everything You Know About CSS Is Wrong][1] is a very practical guide to 
these handy properties. There are also some more experimental column or 
grid based properties but I haven't seen any of them out in the wild. 
CSS 3 defines quite some interesting stuff but it's very hard to tell if 
or when someone can use it.

[1]: http://www.sitepoint.com/books/csswrong1/


 Plus I often find redesigning HTML a lot more straightforward than tweaking
 typical production-scale CSS (CSS can get real hairy real quick).


"Production-scale" CSS can get really ugly really fast without a fitting 
coding style (e.g. I'm almost always defining margin and padding on any 
layout elements, just to have the actual values available at the same 
code line).


 Not only that, I've recently started doing my sites in a very
 MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is*
 just as much part of the view as the CSS anyway. And all I have to do to
 redesign it is just tweak an html template file. As a bonus, that allows for
 much more flexibility in my redesigns (and much more easily) than CSS could
 ever hope to achieve without CSS itself getting a fundamental overhaul


MVC frameworks are really handy, especially for larg projects. In those 
I never had the situation that someone wanted a redesign anyway, they 
always wanted new features and therefore the HTML got modified, too. 
Personally I can't image a way CSS could ever deliver that kind of 
flexibility, simply because it's only concerned with visual presentation 
and not with data (like HTML).

However for my private stuff (some documents, almost all presentations) 
I use HTML to write the content first and then define some CSS to make 
it look good. This is especially handy when doing a presentation about a 
programming language since you can use JavaScript to write a small 
syntax highlighter (the grammar in the D documentation was really handy 
for that). :)

Happy programming
Stephan
Oct 05 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Stephan Soller wrote:

 This is especially handy when doing a presentation about a 
 programming language since you can use JavaScript to write a small 
 syntax highlighter (the grammar in the D documentation was really handy 
 for that). :)


A javascript D syntax highlighter? Please post!
Oct 05 2010
next sibling parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 05.10.2010 19:28, Walter Bright wrote:

 Stephan Soller wrote:

 This is especially handy when doing a presentation about a programming
 language since you can use JavaScript to write a small syntax
 highlighter (the grammar in the D documentation was really handy for
 that). :)


 A javascript D syntax highlighter? Please post!


I will extract it out of the presentation. But be aware, it's just a 
small tool I used to highlight the D code in my presentation about D. 
Don't expect something like a proper lexer. ;)
Oct 06 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 06.10.2010 16:26, Stephan Soller wrote:

 On 05.10.2010 19:28, Walter Bright wrote:

 Stephan Soller wrote:

 This is especially handy when doing a presentation about a programming
 language since you can use JavaScript to write a small syntax
 highlighter (the grammar in the D documentation was really handy for
 that). :)


 A javascript D syntax highlighter? Please post!


 I will extract it out of the presentation. But be aware, it's just a
 small tool I used to highlight the D code in my presentation about D.
 Don't expect something like a proper lexer. ;)


Unfortunately I don't have the time right now to properly extract it and 
clean it up. I don't feel it good enough to be released here but well, 
here's the link to the presentation of a talk I gave about D1:

 
http://events.mi.hdm-stuttgart.de/archive/2010-04-13-d-einf%C3%BChrung/der-coole-stoff/Pr%C3%A4sentation%20(HTML).html

The syntax highlighter (search the source code for "syntax highlighter") 
was hacked together in a few hours. It's tuned towards the code used in 
the presentation and nowhere near usable for general D code. I tested it 
on some of my code and right now it highlights the "in" in "main" as a 
keyword…

The file also has a little presentation system build in. Press "p" to 
enable it and arrow down do fade in the next item. However it only 
really fits if you're looking at the page in full screen mode in Opera 
(no other browsers support the "projection" mode yet).

You can also take a look at the video of the talk but it's in German. In 
the first part a friend of mine introduces D and after that I'm showing 
some more features of the language. Be aware that the video does not 
work in Opera right now (they broke something in 10.60). There is a link 
to the second part of the talk:

 
http://events.mi.hdm-stuttgart.de/2010-04-13-d-einf%C3%BChrung#der-coole-stoff

While the JS syntax highlighter was abandoned I created a language 
highlighter for GEdit (a Linux text editor). I wasn't happy with the 
provided one so I made a new one based on the D language specification. 
If someone here uses GEdit (or an editor that uses the GTKSourceView2 
widget) you can give it a try:

 
http://svn.arkanis.de/projects/tools/gedit_config/trunk/config/langs/d.lang
 
https://svn.arkanis.de/projects/tools/gedit_config/trunk/config/styles/doblivion.xml
   https://svn.arkanis.de/projects/tools/gedit_config/trunk/tests/syntax.d

The first link is the language specification (just a big bunch of reg 
expressions) and the second is a color scheme I created for it. The 
third file is just a small test case to see if it works.

It's pretty complete I believe: it even contains asm instructions and 
differs between function literals and function types (because I wanted 
them to be shown in a different color). If there is a need I can try to 
port it to JavaScript.

Happy programming
Stephan
Oct 07 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Stephan Soller wrote:

 here's the link to the presentation of a talk I gave about D1:
 
 
 http://events.mi.hdm-stuttgart.de/archive/2010-04-13-d-einf%C3%BChrung/der-coole-stoff/Pr%C3%A4sen
ation%20(HTML).html 


Too good not to share! http://twitter.com/D_Programming
Oct 11 2010
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:


 Stephan Soller wrote:

 This is especially handy when doing a presentation about a
 programming language since you can use JavaScript to write a small
 syntax highlighter (the grammar in the D documentation was really handy
 for that). :)


 
 A javascript D syntax highlighter? Please post!



This is a popular javascript syntax highlighter: 
http://alexgorbatchev.com/SyntaxHighlighter/

I've written a D plugin for it (its trivial and not completely correct):
http://github.com/Lutger/d_utils/blob/master/shBrushD.js
Oct 07 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 07.10.2010 16:23, Lutger wrote:

 Walter Bright wrote:


 Stephan Soller wrote:

 This is especially handy when doing a presentation about a
 programming language since you can use JavaScript to write a small
 syntax highlighter (the grammar in the D documentation was really handy
 for that). :)


 A javascript D syntax highlighter? Please post!



 This is a popular javascript syntax highlighter:
 http://alexgorbatchev.com/SyntaxHighlighter/

 I've written a D plugin for it (its trivial and not completely correct):
 http://github.com/Lutger/d_utils/blob/master/shBrushD.js


Thanks for the link! I think I'll use that for my next D stuff. :)

When doing a presentation about a programming language I somehow tend to 
write a small and minimalistic syntax highlighter for it. Balances the 
odds of content creation vs. programming a bit I guess...

Happy programming
Stephan
Oct 07 2010
parent Juanjo Alvarez <fake fakeemail.com> writes:
On Thu, 07 Oct 2010 16:58:03 +0200, Stephan Soller 
<stephan.soller helionweb.de> wrote:

 When doing a presentation about a programming language I somehow 


tend to 

 write a small and minimalistic syntax highlighter for it. Balances 


the 

 odds of content creation vs. programming a bit I guess...


Try also vim command:

:toHTML
Oct 07 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8epjv$1d3p$1 digitalmars.com...

  (and the search engines are very happy about proper HTML code, too).


I've actually come across this point before, that search engines will rank a 
page that doesn't use tables for layout better than one that does. I can't 
really argue against that point, but I am really curious. Does anyone have 
links to any authoritative information on this?
Oct 05 2010
parent Stephan Soller <stephan.soller helionweb.de> writes:
On 05.10.2010 12:24, Nick Sabalausky wrote:

 "Stephan Soller"<stephan.soller helionweb.de>  wrote in message
 news:i8epjv$1d3p$1 digitalmars.com...

   (and the search engines are very happy about proper HTML code, too).


 I've actually come across this point before, that search engines will rank a
 page that doesn't use tables for layout better than one that does. I can't
 really argue against that point, but I am really curious. Does anyone have
 links to any authoritative information on this?


I would also like to see solid information on that topic but I'm afraid 
this statement is very hard to catch. The Google SEO Guide mainly 
focuses on the title and description of websites as well as headings an 
links. I suppose more detailed structures and elements (lists, tables, 
em, code, etc.) are not that important for search engines but for other 
tools that need to work with the document structure (js scripts, screen 
readers, semantic analysis, data mining, etc.).

Happy programming
Stephan
Oct 05 2010
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 04/10/2010 19:42, Walter Bright wrote:

 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 The annoying thing about this is everyone says "don't use tables for
 layout, use CSS." Except that using CSS for layout DOESN'T WORK
 RELIABLY. With tables, I can get 3 columns that are actually 3 columns,
 not 3 columns that are a side effect of bugs in CSS.


Indeed, here are just a few things I hate to bits about CSS:

- no overflow: grow
- overflow: grow isn't the default
- width and height mean the width and height excluding the padding

http://goingspare.wordpress.com/2007/04/06/css-padding-and-width/

Stewart.
Oct 05 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Stewart Gordon wrote:

 Indeed, here are just a few things I hate to bits about CSS:


Sure, but we're kind of stuck with it. While we can invent a new programming 
language, I don't think that inventing a new browser markup language is going
to 
get any traction without convincing Microsoft, Google, and Apple to all get on 
board.
Oct 05 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i8gj1i$28h4$1 digitalmars.com...

 Stewart Gordon wrote:

 Indeed, here are just a few things I hate to bits about CSS:


 Sure, but we're kind of stuck with it. While we can invent a new 
 programming language, I don't think that inventing a new browser markup 
 language is going to get any traction without convincing Microsoft, 
 Google, and Apple to all get on board.


Microsoft would never know it existed.

Goggle would steal it and re-invent a crappy version of it.

Apple would put a note in their developer-license-agreement prohibiting it.

Sun would release a whitepaper that attempted to explain why it wasn't 
needed, but in their attempt they would accidentally make it clear it was a 
good idea after all.

Oracle would create a not-terrible-but-not-great version of it and have 
their salesmen spend a couple million each convincing middle and upper 
managers to pay twenty million for it each. Most of them would fall for it.

Sony would form a committee to investigate the feasibility of introducing 
DRM capabilities into it.

No one would ever notice if IBM did or didn't do anything with it.

Hobbyist developers would flock towards a newly-created alternate version 
that seemed simpler at first glance, but was much slower and really just 
made it easier to introduce subtle bugs.

W3C would form a committee to standardize it. Their early recommendations 
would combine the worst aspects of all the various versions. The final draft 
would be nearly identical to the early drafts, but wouldn't be finalized 
until the original committee's grandchildren were in retirement facilities.

Adobe would create a mediocre, bloated, yet passable 
child-window-fiesta-of-an-app to deal with it and charge hundreds for it. It 
would be enormously popular.

The people formerly from JASC would create a great alternative to Adobe's 
offering at a reasonable price, and after no one bought it they would kill 
it off by selling the rights to the dying carcass of some formerly-relevant 
corporation.

Corel...ah ha ha ha ha! Corel...That's a joke that doesn't need a punchline.

Hasbro Interactive would buy the rights to one of the older versions, and 
sue any individuals and small businesses that had anything similar. Then 
they would sell the rights.

Steve Yegge will have something to say about it, but no one will know or 
care what it is because by the time they finish reading his post the 
universe will have ended. But he'll still maintain that his long-winded 
approach was "good marketing".
Oct 05 2010
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 06 Oct 2010 01:36:24 -0400, Nick Sabalausky wrote:


 "Walter Bright" <newshound2 digitalmars.com> wrote in message
 news:i8gj1i$28h4$1 digitalmars.com...

 Stewart Gordon wrote:

 Indeed, here are just a few things I hate to bits about CSS:


 Sure, but we're kind of stuck with it. While we can invent a new
 programming language, I don't think that inventing a new browser markup
 language is going to get any traction without convincing Microsoft,
 Google, and Apple to all get on board.


 
 Microsoft would never know it existed.
 
 Goggle would steal it and re-invent a crappy version of it.
 
 Apple would put a note in their developer-license-agreement prohibiting
 it.
 
 Sun would release a whitepaper that attempted to explain why it wasn't
 needed, but in their attempt they would accidentally make it clear it
 was a good idea after all.
 
 Oracle would create a not-terrible-but-not-great version of it and have
 their salesmen spend a couple million each convincing middle and upper
 managers to pay twenty million for it each. Most of them would fall for
 it.
 
 Sony would form a committee to investigate the feasibility of
 introducing DRM capabilities into it.
 
 No one would ever notice if IBM did or didn't do anything with it.
 
 Hobbyist developers would flock towards a newly-created alternate
 version that seemed simpler at first glance, but was much slower and
 really just made it easier to introduce subtle bugs.
 
 W3C would form a committee to standardize it. Their early
 recommendations would combine the worst aspects of all the various
 versions. The final draft would be nearly identical to the early drafts,
 but wouldn't be finalized until the original committee's grandchildren
 were in retirement facilities.
 
 Adobe would create a mediocre, bloated, yet passable
 child-window-fiesta-of-an-app to deal with it and charge hundreds for
 it. It would be enormously popular.
 
 The people formerly from JASC would create a great alternative to
 Adobe's offering at a reasonable price, and after no one bought it they
 would kill it off by selling the rights to the dying carcass of some
 formerly-relevant corporation.
 
 Corel...ah ha ha ha ha! Corel...That's a joke that doesn't need a
 punchline.
 
 Hasbro Interactive would buy the rights to one of the older versions,
 and sue any individuals and small businesses that had anything similar.
 Then they would sell the rights.
 
 Steve Yegge will have something to say about it, but no one will know or
 care what it is because by the time they finish reading his post the
 universe will have ended. But he'll still maintain that his long-winded
 approach was "good marketing".


:D
Oct 06 2010
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Nick Sabalausky wrote:

<stuff/>

Thanks, that gave me a good laugh :) You should post more of your newsgroup 
rants on the bigger internet.
Oct 07 2010
parent "Nick Sabalausky" <a a.a> writes:
"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:i8kko0$2o73$1 digitalmars.com...

 Nick Sabalausky wrote:

 <stuff/>

 Thanks, that gave me a good laugh :)


:)


 You should post more of your newsgroup
 rants on the bigger internet.


http://www.semitwist.com/articles/

(I'd *really* like to fix that "Article Headlines" box though, it only shows 
the first three no matter what I do.)

But, yea, maybe I should update it with more of the stuff I put on here.

On this particular post though (ie, what you replied to), I wonder how many 
of those references people actually get. Some of them are kind of obscure, 
particularly the Hasbro Interactive one.
Oct 07 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:i8gfqi$22lj$1 digitalmars.com...

 On 04/10/2010 19:42, Walter Bright wrote:

 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 The annoying thing about this is everyone says "don't use tables for
 layout, use CSS." Except that using CSS for layout DOESN'T WORK
 RELIABLY. With tables, I can get 3 columns that are actually 3 columns,
 not 3 columns that are a side effect of bugs in CSS.


 Indeed, here are just a few things I hate to bits about CSS:

 - no overflow: grow
 - overflow: grow isn't the default
 - width and height mean the width and height excluding the padding

 http://goingspare.wordpress.com/2007/04/06/css-padding-and-width/


Yea. The thing about width/height reminds me too, as much as IE gets 
chastized for not following spec, there's a lot of times their approach is 
just plain *better* than the hairbrained W3C spec. IE used to include border 
as part of the width. That made a lot more sense. And then there's the W3C's 
completely idiotic handling of JS mouse events. It's downright retarded. 
IE's approach, while different, was at least *good*. You could actually tell 
the mouse buttons apart! Gee, imagine that! But now they're forced into 
compliace with the *worse* alternatives, and all the others who are doing it 
flat-out wrong get to sit around and have their dumbass way. Not that MS 
always makes better designs, but the web-dev community's IE bashing just 
gets absurd sometimes. And FWIW, as a web dev, I've had just as much 
rendering problems with FF as with IE. Heck, I've even had FF (both 2 and 3) 
completely *lose* an entire flash applet just because of an obscure oddity 
in it's CSS width/height handling - but IE and Iron handled it perfectly 
fine.

Heck, even the trivial stuff is screwy in CSS: For everything that affects 
letters and words, is there any *real* logic to what's "font-", what's 
"text-" and what's neither? Trivial example, but just illustrates why the 
web gets me so pissed: everything from bottom to top is just garbage and no 
one seems to notice or care. And the few that do notice and care just throw 
their hands up and say "Well, it won't catch on, so why bother?" I'm damn 
glad Walter never decided "There's no way I can compete with MS's .NET or 
Sun's Java, or the astronomical userbase of C/C++, so why bother to try?"
Oct 05 2010
parent reply Stephan Soller <stephan.soller helionweb.de> writes:
On 06.10.2010 06:49, Nick Sabalausky wrote:

 "Stewart Gordon"<smjg_1998 yahoo.com>  wrote in message
 news:i8gfqi$22lj$1 digitalmars.com...

 On 04/10/2010 19:42, Walter Bright wrote:

 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 The annoying thing about this is everyone says "don't use tables for
 layout, use CSS." Except that using CSS for layout DOESN'T WORK
 RELIABLY. With tables, I can get 3 columns that are actually 3 columns,
 not 3 columns that are a side effect of bugs in CSS.


 Indeed, here are just a few things I hate to bits about CSS:

 - no overflow: grow
 - overflow: grow isn't the default
 - width and height mean the width and height excluding the padding

 http://goingspare.wordpress.com/2007/04/06/css-padding-and-width/


 Yea. The thing about width/height reminds me too, as much as IE gets
 chastized for not following spec, there's a lot of times their approach is
 just plain *better* than the hairbrained W3C spec. IE used to include border
 as part of the width. That made a lot more sense. And then there's the W3C's
 completely idiotic handling of JS mouse events. It's downright retarded.
 IE's approach, while different, was at least *good*. You could actually tell
 the mouse buttons apart! Gee, imagine that! But now they're forced into
 compliace with the *worse* alternatives, and all the others who are doing it
 flat-out wrong get to sit around and have their dumbass way. Not that MS
 always makes better designs, but the web-dev community's IE bashing just
 gets absurd sometimes. And FWIW, as a web dev, I've had just as much
 rendering problems with FF as with IE. Heck, I've even had FF (both 2 and 3)
 completely *lose* an entire flash applet just because of an obscure oddity
 in it's CSS width/height handling - but IE and Iron handled it perfectly
 fine.

 Heck, even the trivial stuff is screwy in CSS: For everything that affects
 letters and words, is there any *real* logic to what's "font-", what's
 "text-" and what's neither? Trivial example, but just illustrates why the
 web gets me so pissed: everything from bottom to top is just garbage and no
 one seems to notice or care. And the few that do notice and care just throw
 their hands up and say "Well, it won't catch on, so why bother?" I'm damn
 glad Walter never decided "There's no way I can compete with MS's .NET or
 Sun's Java, or the astronomical userbase of C/C++, so why bother to try?"


I have a totally different experience with all that. Back in the IE 6 
days it took me about 2 days to build a standard cooperate website for a 
small business that worked perfectly in standard conforming browsers (FF 
1, 2, Opera, ...). It then usually took about a week (!) to get it work 
in IE 6. The time needed to "IEify" a design and layout went down with 
time as I learned every bug of IE by hard (oh the beloved Peek-a-boo 
bug) but it still was a major pain in the ass, really. Every 
professional web developer had to know quite a lot about the IE 6 
renderer just to get some basic stuff right (e.g. the hasLayout 
mechanism). Whenever I encountered a bug in other browsers (happened 
some times in FF 1 and 2) it was gone in one of the next few releases. 
IE 6 however had no progress for years and that was the reason many web 
developers literally hated IE 6. :)

Microsoft had some good ideas before they ditched the entire IE team. 
Including the padding and border into the width and height of an element 
sure is handy. But actually I'm more concerned with a consistent 
behavior than with a perfect one. As long as all browsers do the proper 
box model I'm more than willing to calculate a bit. I had to do quite 
some stuff that worked on IE 5 too (IE 5.0, 5.01 and 5.5, all had their 
own little quirks) and the most annoying thing was to calculate the 
dimensions for every element including the padding and border. Don't 
ever ask a web developer about IE after such a project, it's like 
jumping into a basin full of piranhas.

With modern browsers you can switch the box model using the "box-sizing" 
property for every element. So you can use width and hight that includes 
padding and the border. I used it recently and it works quite well.


 Heck, even the trivial stuff is screwy in CSS: For everything that affects
 letters and words, is there any *real* logic to what's "font-", what's
 "text-" and what's neither?


It's a bit confusing at first but as soon as you know a bit more about 
how fonts are structured and build it makes perfect sense. ;)

The big difference between web development and "traditional" programming 
is that web development actually is a combination of many different 
technologies. It's not just one environment and mental pattern to catch 
it all but a combination of distinct technologies with distinct mental 
patterns each one well suited for its purpose (HTTP, HTML, CSS, 
JavaScript). Thats maybe the biggest problem for people that don't use 
this stuff all the time. Depending on what you're doing you have to 
totally switch your way of thinking.

However there are people that know this stuff as well as Walter knows 
compilers and in my opinion they did a great job designing these 
technologies. They perfectly complement each other and that's a great 
achievement. They are not perfect but there is constant progress and 
thats important (just as with D).

Happy programming
Stephan
Oct 06 2010
parent "Nick Sabalausky" <a a.a> writes:
"Stephan Soller" <stephan.soller helionweb.de> wrote in message 
news:i8hg3n$15qu$1 digitalmars.com...

 I have a totally different experience with all that. Back in the IE 6 days


...

 I had to do quite some stuff that worked on IE 5 too (IE 5.0, 5.01 and 
 5.5, all had their own little quirks)


Well, yea, IE5/6 were pretty bad. I'll grant that ;)
Oct 06 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 06/10/2010 01:27, Stewart Gordon wrote:

 On 04/10/2010 19:42, Walter Bright wrote:

 Stewart Gordon wrote:

 The layout breaks in anything but the default text zoom.


 The annoying thing about this is everyone says "don't use tables for
 layout, use CSS." Except that using CSS for layout DOESN'T WORK
 RELIABLY. With tables, I can get 3 columns that are actually 3 columns,
 not 3 columns that are a side effect of bugs in CSS.


 Indeed, here are just a few things I hate to bits about CSS:

 - no overflow: grow
 - overflow: grow isn't the default
 - width and height mean the width and height excluding the padding

 http://goingspare.wordpress.com/2007/04/06/css-padding-and-width/

 Stewart.


I had about 3 jousts with CSS and HTML layout stuff, quite some years 
ago (around 3-5 years). CSS is great for setting up the style of the 
page (as in colors, fonts, font properties, etc.)...  but for layout, it 
sucks a lot! It's the C++ of markup languages, if not worse.

My first joust was me trying to alter the template I got for my homepage 
to use divs/css instead of tables. I tried a few things, but never 
managed to make it show up the way I wanted in both IE 6 and Firefox. I 
gave up and left the template with tables, and here the blame was put 
solely on browsers issues, since it seemed IE 6 was not being standards 
compliant most of the time. (even with the HTML version set to 4, so 
that IE would not try compatibility hacks for old HTML versions) . Note 
that on this first attempt I had only read some simple CSS tutorials, 
and I had no knowledge of how things should render, only intuition (and 
the latest Firefox as a sort of reference).

Fast forward 6 months later or something like that. After reading about 
someone lauding CSS2, I decide to have another go. This time I read a 
lot about HTML/CSS2, hoping do understand it properly, and to actually 
be able to figure how the layout should look like (because at the time 
even Firefox had some prominent layout bugs). It was an utter mess 
again. Even with a a better understanding of CSS, all the code I tried 
never worked properly in both browsers. Now for some of that code I knew 
for sure that the problem was that IE was not being standards compliant, 
and why (even though in some case its behavior seemed the most logical 
one).
After much trial-and-error, learning about the quirks of each browser, 
hair-pulling, I finally managed to get a working layout (with a few 
minor concessions in the original intended functionality). But here even 
though there were faults in the browsers, I became of the opinion that 
that CSS/HTML layout itself was extremely complicated, and was actually 
more at fault than the browsers issues (hence the comment of "C++ of 
markup languages").

The confirmation of that came a year later, when again I delved into 
HTML layout. This time, I wanted to create a HTML page exactly emulating 
the Europass CV template (which, for those not familiar, is actually 
fairly more complicated than the typical resume layout, especially to 
render the separating lines). I found that:
a) I had practically forgotten all the CSS/HTML rules and info that I 
had "learned" before, because they were so strange, complicated, and 
*unnatural* that there is now way you remember them unless you work with 
it on a daily basis.
b) Even though now I only cared about it rendering properly in the 
latest Firefox (it was mostly for internal use only), and so I had no 
more browser incompatibilities, I still had lots of trial-and-error and 
hair pulling. I became completely dissatisfied with HTML/CSS layout... 
it has definitely gained the "crap" designation from me.

-- 
Bruno Medeiros - Software Engineer
Oct 06 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Bruno Medeiros" <brunodomedeiros+spam com.gmail> wrote in message 
news:i8hl00$1gv0$1 digitalmars.com...

 I found that:
 a) I had practically forgotten all the CSS/HTML rules and info that I had 
 "learned" before, because they were so strange, complicated, and 
 *unnatural* that there is now way you remember them unless you work with 
 it on a daily basis.


I've been doing a lot of HTML and such, off and on, almost as far back as 
when Mosaic was still relevant, and I still spend most of my HTML/CSS-dev 
time with at least one browser tab opened to w3schools.com in the 
background.
Oct 06 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 07/10/2010 06:09, Nick Sabalausky wrote:

 "Bruno Medeiros"<brunodomedeiros+spam com.gmail>  wrote in message
 news:i8hl00$1gv0$1 digitalmars.com...

 I found that:
 a) I had practically forgotten all the CSS/HTML rules and info that I had
 "learned" before, because they were so strange, complicated, and
 *unnatural* that there is now way you remember them unless you work with
 it on a daily basis.


 I've been doing a lot of HTML and such, off and on, almost as far back as
 when Mosaic was still relevant, and I still spend most of my HTML/CSS-dev
 time with at least one browser tab opened to w3schools.com in the
 background.


Yeah, same here. Google searches for some particular layout property or 
quirk were also common. I sometimes even tried to read some sections of 
the HTML spec itself, but whoa, that thing was way hard to understand, 
even for a spec. Completely impenetrable, it felt like reading tax 
legislation or something.

-- 
Bruno Medeiros - Software Engineer
Oct 07 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/3/10 18:09 CDT, Walter Bright wrote:

 http://www.digitalmars.com

 Yes, I should add some color and style sheets, but at the moment I am
 just trying to get the layout right and make it much simpler to get to
 what I think are the most useful links.

 Comments welcome.


Hm, looks like only on my machines the page looks broken (see 
http://img96.imageshack.us/img96/4693/screenshot20101004at122.png). This 
occurs on FF/OSX and Chrome/Ubuntu. On my other two combos, the 
DMDScript column is not misaligned, but the whole thing is still too 
narrow and doesn't fill the width of the browser window.

Could someone post a screen capture so I can figure how the site is 
meant to look? Thanks.


Andrei
Oct 04 2010
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 04 Oct 2010 21:23:29 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 10/3/10 18:09 CDT, Walter Bright wrote:

 http://www.digitalmars.com

 Yes, I should add some color and style sheets, but at the moment I am
 just trying to get the layout right and make it much simpler to get to
 what I think are the most useful links.

 Comments welcome.


 Hm, looks like only on my machines the page looks broken (see  
 http://img96.imageshack.us/img96/4693/screenshot20101004at122.png). This  
 occurs on FF/OSX and Chrome/Ubuntu. On my other two combos, the  
 DMDScript column is not misaligned, but the whole thing is still too  
 narrow and doesn't fill the width of the browser window.

 Could someone post a screen capture so I can figure how the site is  
 meant to look? Thanks.


 Andrei


Opera, Windows 7:  
http://habreffect.ru/files/532/fd0f166e1/digitalmars.com.png

Looks almost the same in IE and Chrome ("D", "C/C++" and "DMDScript"  
captions are all rendered with Times New Roman or similar font in those  
browsers).
Oct 04 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/4/10 12:42 CDT, Denis Koroskin wrote:

 On Mon, 04 Oct 2010 21:23:29 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 10/3/10 18:09 CDT, Walter Bright wrote:

 http://www.digitalmars.com

 Yes, I should add some color and style sheets, but at the moment I am
 just trying to get the layout right and make it much simpler to get to
 what I think are the most useful links.

 Comments welcome.


 Hm, looks like only on my machines the page looks broken (see
 http://img96.imageshack.us/img96/4693/screenshot20101004at122.png).
 This occurs on FF/OSX and Chrome/Ubuntu. On my other two combos, the
 DMDScript column is not misaligned, but the whole thing is still too
 narrow and doesn't fill the width of the browser window.

 Could someone post a screen capture so I can figure how the site is
 meant to look? Thanks.


 Andrei


 Opera, Windows 7:
 http://habreffect.ru/files/532/fd0f166e1/digitalmars.com.png

 Looks almost the same in IE and Chrome ("D", "C/C++" and "DMDScript"
 captions are all rendered with Times New Roman or similar font in those
 browsers).


Thanks. I update my opinion to "definitely crappy even in its intended 
look".

The three-column layout ignores the width of the browser and is 
unnecessarily cramped. What is this, a newspaper column featuring an 
obscure announcement?

The short width of the columns and the lack of hyphenation makes the 
text hopelessly ragged.

The icons are disproportionately large compared to the text.

The top three links are identical in the three columns, but there is no 
horizontal structure to acknowledge that symmetry. In fact the links 
inside columns form a menu of sorts, but are not visually laid out as 
menus.

The "site search" box is... out there.

"Code of the Nerds" is old. Drop.

I find it surprising that anyone on this forum finds this format even 
remotely passable, never mind better than the old one (which didn't set 
the bar all that high).


Andrei
Oct 04 2010
parent reply Brian Hay <bhay construct3d.com> writes:
Andrei Alexandrescu wrote:

 I find it surprising that anyone on this forum finds this format even 
 remotely passable, never mind better than the old one (which didn't set 
 the bar all that high).


With all due respect to Walter, as a professional web designer I have to 
agree with Andrei. It's terrible for all the reasons mentioned ... and 
more. "1995 programmer art" sums it up.

Sad as it may seem to some, the way D (and its parent company Digital 
Mars) are presented and marketed is just as important, if not more so, 
to many potential users of D as the quality of the language itself. If 
their first impression of the company is amateurish then that can and 
does reflect poorly on the language. Many people do judge a book by its 
cover.

I'd suggest (at least in the interim) using the 
http://d-programming-language.org/ look and feel.

Walter, I think you're on the right track with your desire to make the 
home page more of a clean, minimalistic gateway to the different 
sections of Digital Mars, but the design and execution need work.
Oct 04 2010
next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
I think so, too.
Although this background:
http://d-programming-language.org/images/gradient-red.jpg
<http://d-programming-language.org/images/gradient-red.jpg>looks slightly
pixelated to me.

On Mon, Oct 4, 2010 at 5:14 PM, Brian Hay <bhay construct3d.com> wrote:


 I'd suggest (at least in the interim) using the
 http://d-programming-language.org/ look and feel.
Oct 04 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Brian Hay wrote:

 With all due respect to Walter, as a professional web designer I have to 
 agree with Andrei. It's terrible for all the reasons mentioned ... and 
 more. "1995 programmer art" sums it up.


Ok, but on the other hand, mint.com gets high fives for its home page. But I 
find it to be slow loading, the green-on-green text (near the bottom)
impossible 
to read, and the animated text slideshows irritating.

Or maybe I'm just too old :-)
Oct 04 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/4/10 18:54 CDT, Walter Bright wrote:

 Brian Hay wrote:

 With all due respect to Walter, as a professional web designer I have
 to agree with Andrei. It's terrible for all the reasons mentioned ...
 and more. "1995 programmer art" sums it up.


 Ok, but on the other hand, mint.com gets high fives for its home page.
 But I find it to be slow loading, the green-on-green text (near the
 bottom) impossible to read, and the animated text slideshows irritating.

 Or maybe I'm just too old :-)


I think you and I (as many programmers who aren't web designers) are in 
the "don't/don't" place (we don't know what we don't know). Getting from 
there to "do/don't" -> "do/do" -> "don't/do" is a long, arduous process. 
So we're essentially unable to predict accurately the likeability of a 
web page by only looking at it, and clearly we're not in the position of 
designing a good website.

Having gladly acknowledged your interest in this topic (as I agree 
marketing is at this point essential), my overarching advice is:

1. Find a good professional.

2. Explain in broadest terms _what_ you are trying to achieve at the 
highest level (NOT "here's _how_ I want this to be, tweak it"). For 
example, instead of saying "I want three equally sized columns because 
nobody told me that that design is cr(ee|ap)py, and please color them 
like pee in a swimming pool while you're at it", tell them "I have three 
product lines, and I want them featured on the homepage in a simple and 
straightforward manner".

3. Let the (wo)man do h(is|er) job.

4. Pay h(im|er) a small fraction of the money you'd be losing in 
opportunity costs should you do all the work yourself starting from 
"don't/don't".

5. ...

6. Profit!


Andrei
Oct 04 2010
next sibling parent reply Brian Hay <bhay construct3d.com> writes:
Andrei Alexandrescu wrote:

 2. Explain in broadest terms _what_ you are trying to achieve at the 
 highest level (NOT "here's _how_ I want this to be, tweak it"). For 
 example, instead of saying "I want three equally sized columns because 
 nobody told me that that design is cr(ee|ap)py, and please color them 
 like pee in a swimming pool while you're at it", tell them "I have three 
 product lines, and I want them featured on the homepage in a simple and 
 straightforward manner".


For non web designers, this article and YouTube video are well worth the 
5 minutes:

http://boagworld.com/business-strategy/10-harsh-truths-about-corporate-websites
http://www.youtube.com/watch?v=Wac3aGn5twc

Pretty much summarises Andrei's sentiment above.
Oct 04 2010
parent "Nick Sabalausky" <a a.a> writes:
 "Brian Hay" <bhay construct3d.com> wrote in message 
news:i8duv5$2nn6$1 digitalmars.com...

 Andrei Alexandrescu wrote:

 2. Explain in broadest terms _what_ you are trying to achieve at the 
 highest level (NOT "here's _how_ I want this to be, tweak it"). For 
 example, instead of saying "I want three equally sized columns because 
 nobody told me that that design is cr(ee|ap)py, and please color them 
 like pee in a swimming pool while you're at it", tell them "I have three 
 product lines, and I want them featured on the homepage in a simple and 
 straightforward manner".


 For non web designers, this article and YouTube video are well worth the 5 
 minutes:

 http://boagworld.com/business-strategy/10-harsh-truths-about-corporate-websites


Three trivial knee-jerk reactions to that I can't keep my mouth shut about 



1. Are they sure they used enough different fonts? Couldn't they have 
crammed a few hundred more in?

2. It's a Campbell's soup site, "Big-N-Chunky"! Feel like I'm reading a 
poster through a peephole. Or using a GTK app.

Web artists often use giant 40+" monitors at five-trillion-by-ten-billion 
resolution. Apparently some of them haven't noticed that nobody else does.

3. "In most organizations I work with the website is managed by either the 
marketing or IT department. However, this inevitably leads to a turf war and 
the site becoming the victim of internal politics."

Obviously this guy's never worked at a place that *did* have a separate web 
department. If he thinks a separate web department is going to curb 
site-related turf wars and politics, he's completely off his rocker. Doesn't 
matter who handles the site, every other department is going to demand the 
site be bent exclusively to their department's whim. And if the website 
isn't *completely* separated from IT, then IT will make constant dumbass 
decisions that will screw over the site programmers.

A lot of the other stuff he says is good though.
Oct 04 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 5. ...
 
 6. Profit!


Step 5, sigh.
Oct 04 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 05/10/2010 02:13, Andrei Alexandrescu wrote:

 On 10/4/10 18:54 CDT, Walter Bright wrote:

 Brian Hay wrote:

 With all due respect to Walter, as a professional web designer I have
 to agree with Andrei. It's terrible for all the reasons mentioned ...
 and more. "1995 programmer art" sums it up.


 Ok, but on the other hand, mint.com gets high fives for its home page.
 But I find it to be slow loading, the green-on-green text (near the
 bottom) impossible to read, and the animated text slideshows irritating.

 Or maybe I'm just too old :-)


 I think you and I (as many programmers who aren't web designers) are in
 the "don't/don't" place (we don't know what we don't know). Getting from
 there to "do/don't" -> "do/do" -> "don't/do" is a long, arduous process.
 So we're essentially unable to predict accurately the likeability of a
 web page by only looking at it, and clearly we're not in the position of
 designing a good website.

 Having gladly acknowledged your interest in this topic (as I agree
 marketing is at this point essential), my overarching advice is:

 1. Find a good professional.

 2. Explain in broadest terms _what_ you are trying to achieve at the
 highest level (NOT "here's _how_ I want this to be, tweak it"). For
 example, instead of saying "I want three equally sized columns because
 nobody told me that that design is cr(ee|ap)py, and please color them
 like pee in a swimming pool while you're at it", tell them "I have three
 product lines, and I want them featured on the homepage in a simple and
 straightforward manner".

 3. Let the (wo)man do h(is|er) job.

 4. Pay h(im|er) a small fraction of the money you'd be losing in
 opportunity costs should you do all the work yourself starting from
 "don't/don't".

 5. ...

 6. Profit!


 Andrei



I totally agree with the "we're not in the position of designing a good 
website.", but I'm not so sure about "predict accurately the likeability 
of a web page"
Well, maybe not super-accurately, but I think most developers would get 
a good sense if a page is good or not. Especially since, in the case of 
D and DigitalMars, it is us/Walter who knows exactly what the target 
audience is, the purpose of the website, etc.. A hired professional 
might know that, but not as well.

I have an alternate suggestion. Go to an open source web templates (like 
http://www.oswd.org/), selected a few of them, and then choose one. The 
choose part can be either just Walter choosing, or maybe the community 
could vote on one, or maybe some other alternative in between (the 
community just commenting on what they think). But a simple process, not 
too complicated.

A new web design is nice to have, but frankly, I think much better would 
be a reorganization of the site, at least the D site. I won't go into 
much detail here, but just mention that I think it has too many links, 
and they are not very well organized. I much prefer the 
http://www.d-programming-language.org/ site for example.

-- 
Bruno Medeiros - Software Engineer
Oct 05 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 05/10/2010 13:35, Bruno Medeiros wrote:

 A new web design is nice to have, but frankly, I think much better would
 be a reorganization of the site, at least the D site. I won't go into
 much detail here, but just mention that I think it has too many links,
 and they are not very well organized. I much prefer the
 http://www.d-programming-language.org/ site for example.


I've only read now that "the long-term plan is to dedicate 
d-programming-language.org as the primary D site.", so cool, my 
complaint is moot. :)


-- 
Bruno Medeiros - Software Engineer
Oct 07 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-10-05 01:54, Walter Bright wrote:

 Brian Hay wrote:

 With all due respect to Walter, as a professional web designer I have
 to agree with Andrei. It's terrible for all the reasons mentioned ...
 and more. "1995 programmer art" sums it up.


 Ok, but on the other hand, mint.com gets high fives for its home page.
 But I find it to be slow loading, the green-on-green text (near the
 bottom) impossible to read, and the animated text slideshows irritating.

 Or maybe I'm just too old :-)


I think it looks quite alright, but I can agree about the green text at 
the bottom. But I guess that is to be expected from a site called "mint".

-- 
/Jacob Carlborg
Oct 04 2010
prev sibling parent reply klickverbot <see klickverbot.at> writes:
On 10/4/10 7:23 PM, Andrei Alexandrescu wrote:

 Hm, looks like only on my machines the page looks broken (see
 http://img96.imageshack.us/img96/4693/screenshot20101004at122.png). This
 occurs on FF/OSX and Chrome/Ubuntu. On my other two combos, the
 DMDScript column is not misaligned, but the whole thing is still too
 narrow and doesn't fill the width of the browser window.

 Could someone post a screen capture so I can figure how the site is
 meant to look? Thanks.


 Andrei


It looks like this here: 
http://img838.imageshack.us/img838/816/screenshot20101004at742.png

Have you modified the default font size setting of the browser? If the 
page uses mixed em/pixel units, layout bugs like this could occur, 
although there is quite a lot of other possible causes for that.

By the way, I don't quite see how the vegetation-at-the-beach picture 
would qualify as background for a programming language news feed 
(http://twitter.com/D_Programming) – oh, and that file is about as big 
byte-wise as the rest of the page…
Oct 04 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
klickverbot wrote:

 By the way, I don't quite see how the vegetation-at-the-beach picture 
 would qualify as background for a programming language news feed 
 (http://twitter.com/D_Programming) – oh, and that file is about as big 
 byte-wise as the rest of the page…


It's a picture I took years ago. The advantage of it is I don't have to get a 
license for it!

For example, on the http://twitter.com/digitalmars one I had to get a license 
from JPL to use the photo. Not that it was a big deal, it's just that it took 
time, I have to keep the license paperwork on file, etc.
Oct 04 2010
prev sibling next sibling parent "Mike James" <foo bar.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i8b2fn$4t9$2 digitalmars.com...

 http://www.digitalmars.com

 Yes, I should add some color and style sheets, but at the moment I am just 
 trying to get the layout right and make it much simpler to get to what I 
 think are the most useful links.

 Comments welcome.


Maybe get rid of the "Code of the Nerds" quote - it doesn't look very 
professional and doesn't seem to fit in with the rest of the page which 
looks good.

-=mike=-
Oct 04 2010
prev sibling parent reply Kagamin <spam here.lot> writes:
Walter Bright Wrote:


 http://www.digitalmars.com
 
 Yes, I should add some color and style sheets, but at the moment I am just 
 trying to get the layout right and make it much simpler to get to what I think 
 are the most useful links.


What is an easy way to get to changelog?
Oct 11 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Kagamin wrote:

 Walter Bright Wrote:
 

 http://www.digitalmars.com

 Yes, I should add some color and style sheets, but at the moment I am just 
 trying to get the layout right and make it much simpler to get to what I think 
 are the most useful links.


 
 What is an easy way to get to changelog?


[Documentation] => [D Change Log]
Oct 11 2010
parent Kagamin <spam here.lot> writes:
Walter Bright Wrote:


 What is an easy way to get to changelog?


 
 [Documentation] => [D Change Log]


Ah, thanks, found.
Oct 12 2010