|
Archives
D Programming
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics
|
digitalmars.D.announce - New Layout Wiki4D
I don't know if this deserves an announcement but I changed the layout on
wiki4d. I'm just waiting for someone to become annoyed with the new template
and revert it back to the default. Because then it's on!! :P
The template is done by gorotron not by me. If you find any bugs feel free to
fix them yourselves...:D
DavidSwe kirjoitti:
I don't know if this deserves an announcement but I changed the layout on
wiki4d. I'm just waiting for someone to become annoyed with the new template
and revert it back to the default. Because then it's on!! :P
The template is done by gorotron not by me. If you find any bugs feel free to
fix them yourselves...:D
The fixed width is probably not a good idea. Some pictures don't fit to
the page now, e.g
http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport/GEdit
Is it possible to set min-width and max-width there?
The orange-yellow background is quite aggressive. I don't like it at
all. Otherwise it's very nice.
Jari-Matti Mäkelä wrote:
DavidSwe kirjoitti:
I don't know if this deserves an announcement but I changed the layout on
wiki4d. I'm just waiting for someone to become annoyed with the new template
and revert it back to the default. Because then it's on!! :P
The template is done by gorotron not by me. If you find any bugs feel free to
fix them yourselves...:D
The fixed width is probably not a good idea. Some pictures don't fit to
the page now, e.g
Yes, the first thing I noticed was that the page should be wider, and
use a larger font. It only uses half my screen space with a rather small
font on my monitor.
Looking at the source, all sizes are specified in _pixels_. This is
typically a Bad Thing for anyone using a higher resolution than the
author uses. It certainly is for me...
http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport/GEdit
Ew, a horizontal scrollbar. I hate those, especially when it would
probably fit fine with less huge margins.
Is it possible to set min-width and max-width there?
The orange-yellow background is quite aggressive. I don't like it at
all. Otherwise it's very nice.
I agree, the background should use another color. The focus should be on
the content, not the borders.
Frits van Bommel Wrote:
<snip>
Yes, the first thing I noticed was that the page should be wider,
and use a larger font. It only uses half my screen space with a
rather small font on my monitor.
Wrong again. It should have no width set at all. Fixed width layouts on web
pages should never have been invented.
Looking at the source, all sizes are specified in _pixels_. This is
typically a Bad Thing for anyone using a higher resolution than the
author uses. It certainly is for me...
It's nothing to do with resolution. It's to do with basic accessibility
principles and not disabling the means by which browsers implement such
principles.
Either specify font sizes in ems, not pixels or points, or don't specify them
at all.
Stewart.
http://www.prowiki.org/wiki4d/wiki.cgi?action=edit&id=DocComments/WikiTemplate
HF. It's a wiki after all!
Stewart Gordon Wrote:
Frits van Bommel Wrote:
<snip>
Yes, the first thing I noticed was that the page should be wider,
and use a larger font. It only uses half my screen space with a
rather small font on my monitor.
Wrong again. It should have no width set at all. Fixed width layouts on web
pages should never have been invented.
Looking at the source, all sizes are specified in _pixels_. This is
typically a Bad Thing for anyone using a higher resolution than the
author uses. It certainly is for me...
It's nothing to do with resolution. It's to do with basic accessibility
principles and not disabling the means by which browsers implement such
principles.
Either specify font sizes in ems, not pixels or points, or don't specify them
at all.
Stewart.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
DavidSwe schrieb am 2007-02-28:
http://www.prowiki.org/wiki4d/wiki.cgi?action=edit&id=DocComments/WikiTemplate
HF. It's a wiki after all!
Sure it is. I've tried to de-pixelise the layout, but it is totaly broken.
Reverted back to the original layout.
Thomas
-----BEGIN PGP SIGNATURE-----
iD8DBQFF5dDzLK5blCcjpWoRAhR/AJ4nQnJe/NGmyFhZwHF/fOHk/P7YeACcD6Lb
yxdP1XSyPDenDckHR9QZ4Nk=
=RbgU
-----END PGP SIGNATURE-----
Couldn't you have tried a different layout instead of reverting to the old one?
Forcing Firefox to use no style on wiki4d have about the same look as the old
one. I think that speaks for itself.
Thomas Kuehne Wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
DavidSwe schrieb am 2007-02-28:
http://www.prowiki.org/wiki4d/wiki.cgi?action=edit&id=DocComments/WikiTemplate
HF. It's a wiki after all!
Sure it is. I've tried to de-pixelise the layout, but it is totaly broken.
Reverted back to the original layout.
Thomas
-----BEGIN PGP SIGNATURE-----
iD8DBQFF5dDzLK5blCcjpWoRAhR/AJ4nQnJe/NGmyFhZwHF/fOHk/P7YeACcD6Lb
yxdP1XSyPDenDckHR9QZ4Nk=
=RbgU
-----END PGP SIGNATURE-----
DavidSwe wrote:
Couldn't you have tried a different layout instead of reverting to the old
one? Forcing Firefox to use no style on wiki4d have about the same look as the
old one. I think that speaks for itself.
I suspect the simple answer is that it's easier to revert back than to
save your layout or to try a different layout.
The layout has been changed before, but usually less drastic changes
have a better chance of surviving. Perhaps, think incremental rather
than all at once.
--
jcc7
DavidSwe Wrote:
Couldn't you have tried a different layout instead of
reverting to the old one? Forcing Firefox to use no style on
wiki4d have about the same look as the old one. I think that
speaks for itself.
The result is reasonable (in IE6) when I try taking out the CSS. That's as
much as matters IMO - after all, the whole point of CSS is to facilitate the
separation of content from aesthetics.
Stewart.
Stewart Gordon wrote:
It should have no width set at all. Fixed width layouts on web pages should
never have been invented.
Hear Hear!
<lurk>
Stewart Gordon wrote:
Frits van Bommel Wrote:
<snip>
Yes, the first thing I noticed was that the page should be wider,
and use a larger font. It only uses half my screen space with a
rather small font on my monitor.
Wrong again. It should have no width set at all. Fixed width layouts on web
pages should never have been invented.
Looking at the source, all sizes are specified in _pixels_. This is
typically a Bad Thing for anyone using a higher resolution than the
author uses. It certainly is for me...
It's nothing to do with resolution. It's to do with basic accessibility
principles and not disabling the means by which browsers implement such
principles.
Either specify font sizes in ems, not pixels or points, or don't specify them
at all.
Stewart.
For general site layout, I agree. However, for columnar layout of content,
fixing the width for content has everything
to do with readability for the sighted - I for one have a hard time reading
paragraph after paragraph of text laid out
at over 1000px wide. Granted, I could just resize my browser, but the effect
is hardly the same.
The ideal solution is having paragraphs elements that layout such that they
create natural (magazine-style) columns
regardless of the dimensions of the page itself. But I have yet to see that
happen without constraining the page width,
height or number of columns in some way, without resorting to javascript hacks.
;)
--
- EricAnderton at yahoo
Pragma Wrote:
<snip>
For general site layout, I agree. However, for columnar
layout of content, fixing the width for content has everything
to do with readability for the sighted - I for one have a hard
time reading paragraph after paragraph of text laid out at
over 1000px wide. Granted, I could just resize my browser,
but the effect is hardly the same.
It also has everything to do with unreadability for the sighted, if they have
to keep scrolling their screens in a variety of directions just because the
designer's browser dimensions don't match.
The ideal solution is having paragraphs elements that layout
such that they create natural (magazine-style) columns
regardless of the dimensions of the page itself. But I have
yet to see that happen without constraining the page width,
height or number of columns in some way, without resorting to
javascript hacks. ;)
Some would claim that magazine-style columns don't belong on the WWW, but are
just a pointless attempt to mimic printed material. Someone once said:
http://allmyfaqs.net/faq.pl?Fix_the_wrong_problem
"Trying to force a text-flow from one column to another, when the real problem
is creating text interesting enough to induce readers to scroll their displays
in a presentation based on methods appropriate to the medium instead of those
adopted from print. "
Moreover, to read columns on a web page you would often have to scroll down the
column to read it, and then scroll up again to read the next column.
But you have a point. Maybe there is a way in which such a thing could be
reasonably implemented....
Stewart.
Stewart Gordon wrote:
The ideal solution is having paragraphs elements that layout
such that they create natural (magazine-style) columns
regardless of the dimensions of the page itself. But I have
yet to see that happen without constraining the page width,
height or number of columns in some way, without resorting to
javascript hacks. ;)
Some would claim that magazine-style columns don't belong on the WWW, but are
just a pointless attempt to mimic printed material. Someone once said:
I've heard somewhere before that narrower text is easier to read. But
just now I couldn't find anything in the way of corroboration.
I did find this:
http://hubel.sfasu.edu/research/textmargin.html
"""
Conclusions
Results indicated that, by itself, text width does not influence
readability; however, there was a significant interaction between text
width and margin width.
"""
But I really don't like what the data shows. They say an 8inch column
is significantly more readable with 0-inch margins. Ugh, I hate
zero-width margins. Makes me feel all stressed out looking at zero
width margins.
--bb
Stewart Gordon wrote:
Pragma Wrote:
<snip>
For general site layout, I agree. However, for columnar
layout of content, fixing the width for content has everything
to do with readability for the sighted - I for one have a hard
time reading paragraph after paragraph of text laid out at
over 1000px wide. Granted, I could just resize my browser,
but the effect is hardly the same.
It also has everything to do with unreadability for the sighted, if they have
to keep scrolling their screens in a variety of directions just because the
designer's browser dimensions don't match.
The ideal solution is having paragraphs elements that layout
such that they create natural (magazine-style) columns
regardless of the dimensions of the page itself. But I have
yet to see that happen without constraining the page width,
height or number of columns in some way, without resorting to
javascript hacks. ;)
Some would claim that magazine-style columns don't belong on the WWW, but are
just a pointless attempt to mimic printed material. Someone once said:
http://allmyfaqs.net/faq.pl?Fix_the_wrong_problem
Good link. I'll have to hang onto that one.
"Trying to force a text-flow from one column to another, when the real problem
is creating text interesting enough to induce readers to scroll their displays
in a presentation based on methods appropriate to the medium instead of those
adopted from print. "
Moreover, to read columns on a web page you would often have to scroll down
the column to read it, and then scroll up again to read the next column.
Aside: I find it genuinely funny that my newsreader (Thunderbird) saw fit to
quote you without line-wrapping in my
editor. :)
You're right (and your quoted source is right) that it's a PITA to scroll down,
then up again to keep reading. I think
the only way that works at all is if you have dissimilar content, stories or
whatnot in each column - kind of like CNN's
story layout. That way you have only one true column for something of
interest, leaving the user to "shift gears" and
scroll up to do something else.
Otherwise, for a "minimal scrolling magazine style layout", you'd have to
constrain the page to the height of the
viewport, and encourage horizontal scrolling instead of vertical - a little
counter-intuitive (and very unconventional),
but I've seen similar things done before with good looking results. I'm not
advocating this for the wiki, but I
wouldn't mind having a personal Blog done this way.
Maybe there is a way in which such a thing could be reasonably implemented....
It can be done a whole bunch of ways: javascript + CSS comes to mind so you can
adopt a different layout depending on
the viewport size/shape. But then it all comes back to accessibility and
browser behavior by version and vendor: "what
is acceptable and what isn't" depends on your audience. :(
Now what would be nice is if browser vendors changed how big an EM is depending
on the viewport size.
--
- EricAnderton at yahoo
http://weblogs.mozillazine.org/roc/archives/2005/03/gecko_18_for_we.html
Of course, you'll need a fairly recent version of a Mozilla browser.
Just try resizing the window left and right to see what happens.
-- Daniel
Pragma wrote:
Stewart Gordon wrote:
Pragma Wrote:
<snip>
For general site layout, I agree. However, for columnar layout of
content, fixing the width for content has everything to do with
readability for the sighted - I for one have a hard time reading
paragraph after paragraph of text laid out at over 1000px wide.
Granted, I could just resize my browser, but the effect is hardly the
same.
It also has everything to do with unreadability for the sighted, if
they have to keep scrolling their screens in a variety of directions
just because the designer's browser dimensions don't match.
The ideal solution is having paragraphs elements that layout such
that they create natural (magazine-style) columns regardless of the
dimensions of the page itself. But I have yet to see that happen
without constraining the page width, height or number of columns in
some way, without resorting to javascript hacks. ;)
Some would claim that magazine-style columns don't belong on the WWW,
but are just a pointless attempt to mimic printed material. Someone
once said:
http://allmyfaqs.net/faq.pl?Fix_the_wrong_problem
Good link. I'll have to hang onto that one.
"Trying to force a text-flow from one column to another, when the real
problem is creating text interesting enough to induce readers to
scroll their displays in a presentation based on methods appropriate
to the medium instead of those adopted from print. "
Moreover, to read columns on a web page you would often have to scroll
down the column to read it, and then scroll up again to read the next
column.
Aside: I find it genuinely funny that my newsreader (Thunderbird) saw
fit to quote you without line-wrapping in my editor. :)
You're right (and your quoted source is right) that it's a PITA to
scroll down, then up again to keep reading. I think the only way that
works at all is if you have dissimilar content, stories or whatnot in
each column - kind of like CNN's story layout. That way you have only
one true column for something of interest, leaving the user to "shift
gears" and scroll up to do something else.
Otherwise, for a "minimal scrolling magazine style layout", you'd have
to constrain the page to the height of the viewport, and encourage
horizontal scrolling instead of vertical - a little counter-intuitive
(and very unconventional), but I've seen similar things done before with
good looking results. I'm not advocating this for the wiki, but I
wouldn't mind having a personal Blog done this way.
Maybe there is a way in which such a thing could be reasonably
It can be done a whole bunch of ways: javascript + CSS comes to mind so
you can adopt a different layout depending on the viewport size/shape.
But then it all comes back to accessibility and browser behavior by
version and vendor: "what is acceptable and what isn't" depends on your
audience. :(
Now what would be nice is if browser vendors changed how big an EM is
depending on the viewport size.
--
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.
v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Daniel Keep wrote:
http://weblogs.mozillazine.org/roc/archives/2005/03/gecko_18_for_we.html
Of course, you'll need a fairly recent version of a Mozilla browser.
Just try resizing the window left and right to see what happens.
That's about as solid an example as anyone could hope for. Thanks for sending
that. :)
.columns {
-moz-column-width: 20em;
-moz-column-gap: 3em;
-moz-column-rule: medium solid;
-webkit-column-width: 20em;
-webkit-column-gap: 3em;
-webkit-column-rule: medium solid;
}
Shame it uses all proprietary styles, but at least it degrades well on IE.
--
- EricAnderton at yahoo
Pragma wrote:
Daniel Keep wrote:
http://weblogs.mozillazine.org/roc/archives/2005/03/gecko_18_for_we.html
Of course, you'll need a fairly recent version of a Mozilla browser.
Just try resizing the window left and right to see what happens.
That's about as solid an example as anyone could hope for. Thanks for
sending that. :)
.columns {
-moz-column-width: 20em;
-moz-column-gap: 3em;
-moz-column-rule: medium solid;
-webkit-column-width: 20em;
-webkit-column-gap: 3em;
-webkit-column-rule: medium solid;
}
Shame it uses all proprietary styles, but at least it degrades well on IE.
Well, all new "experimental" CSS styles in Mozilla start off life as
"-moz-*" properties. The thing here is that, IIRC, all the -moz-* ones
above are actually CSS3 Columns save for the prefix (the same goes for
Safari.) They do it this way because at the time the spec hadn't been
finalised.
But yeah, it is pretty cool :)
-- Daniel
--
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.
v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Pragma Wrote:
<snip>
It can be done a whole bunch of ways: javascript + CSS comes
to mind so you can adopt a different layout depending on the
viewport size/shape. But then it all comes back to
accessibility and browser behavior by version and vendor:
"what is acceptable and what isn't" depends on your audience.
:(
Now what would be nice is if browser vendors changed how big
an EM is depending on the viewport size.
What's an EM?
Stewart.
Stewart Gordon wrote:
Pragma Wrote:
<snip>
It can be done a whole bunch of ways: javascript + CSS comes
to mind so you can adopt a different layout depending on the
viewport size/shape. But then it all comes back to
accessibility and browser behavior by version and vendor:
"what is acceptable and what isn't" depends on your audience.
:(
Now what would be nice is if browser vendors changed how big
an EM is depending on the viewport size.
What's an EM?
Stewart.
One of the units of measure that CSS recognizes. In theory its the size of the
'M'
character for the current font face and size. In practice it... usually is.
Its also
generally accepted as a better unit to use than px (pixels) if you want content
to resize
itself nicely to fit different display sizes. (What looks nice at 50px on my
screen,
might be either invisibly miniscule or awkwardly huge on someone else's. At
10em it'll
usually look much the same on mine and theirs.)
-- Chris Nicholson-Sauls
"Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message
news:es58u0$23fd$1 digitalmars.com...
One of the units of measure that CSS recognizes. In theory its the size
of the 'M' character for the current font face and size. In practice
it... usually is. Its also generally accepted as a better unit to use
than px (pixels) if you want content to resize itself nicely to fit
different display sizes. (What looks nice at 50px on my screen, might be
either invisibly miniscule or awkwardly huge on someone else's. At 10em
it'll usually look much the same on mine and theirs.)
Oh, man! You are going to get reamed _out_ because Stewart already knows
what an em is. Prepare yourself!
Chris Nicholson-Sauls Wrote:
Stewart Gordon wrote:
Pragma Wrote:
Now what would be nice is if browser vendors changed how big
an EM is depending on the viewport size.
What's an EM?
One of the units of measure that CSS recognizes. In theory
its the size of the 'M' character for the current font face
and size. In practice it... usually is.
Oops. I must be just not used to seeing the word written in uppercase.
Actually, I think technically it's equal to the font height, and an en is half
of this.
But this doesn't seem to fit. Usually when people increase the size of a
browser window, they expect to see more content at once, rather than to zoom in.
Stewart.
Stewart Gordon wrote:
Frits van Bommel Wrote:
<snip>
Yes, the first thing I noticed was that the page should be wider,
and use a larger font. It only uses half my screen space with a
rather small font on my monitor.
Wrong again. It should have no width set at all.
It'll still have a width on my screen :P.
(Note I didn't say anything about a width *property*, just the width of
the page. You know, the English word "width"?)
Fixed width layouts on web pages should never have been invented.
Very true. A portable document format (i.e. html) has no business
specifying stuff in pixels.
*If* a width needs to be set, set it in ems. (Long paragraphs can get
hard to read if the text is full-width)
Either specify font sizes in ems, not pixels or points, or don't specify them
at all.
This was pretty much what I meant to say. (I couldn't remember the name
for the proper unit though)
DavidSwe wrote:
I don't know if this deserves an announcement but I changed the layout on
wiki4d. I'm just waiting for someone to become annoyed with the new template
and revert it back to the default. Because then it's on!! :P
The template is done by gorotron not by me. If you find any bugs feel free to
fix them yourselves...:D
Its about time the wiki got an update. It looks much better then before.
-Joel
DavidSwe wrote:
I don't know if this deserves an announcement but I changed the layout on
wiki4d. I'm just waiting for someone to become annoyed with the new template
and revert it back to the default. Because then it's on!! :P
The template is done by gorotron not by me. If you find any bugs feel free to
fix them yourselves...:D
How do you revert to the previous one?
DavidSwe wrote:
I don't know if this deserves an announcement but I changed the layout on
wiki4d. I'm just waiting for someone to become annoyed with the new template
and revert it back to the default. Because then it's on!! :P
The template is done by gorotron not by me. If you find any bugs feel free to
fix them yourselves...:D
Agh, I also didn't like the new layout, I'm glad it was reverted.
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
DavidSwe wrote:
I don't know if this deserves an announcement but I changed the layout on
wiki4d. I'm just waiting for someone to become annoyed with the new template
and revert it back to the default. Because then it's on!! :P
The template is done by gorotron not by me. If you find any bugs feel free to
fix them yourselves...:D
If your going to change the format, what about something more like
wikipedia (http://en.wikipedia.org/wiki/Main_Page)? I think that
website looks awesome.
-Joel
|
|
C & C++
DMDScript
Justin C Calvarese <technocrat7 gmail.com> 