This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Stylesheets > November 2004 > Puzzle
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Jón Fairbairn 2004-11-25, 9:37 pm |
|
I keep reading the definition of CSS2, but am having
difficulty acquiring the precise meaning of certain of the
concepts.
Here's a document with valid html and css:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Float, Relative and Containment</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">
div#container
{background-color: teal;
position: relative;
border: solid thin green; margin: 0; padding: 0;
}
div#floater
{float: left; background-color: transparent;
width: 32%;
border: solid thin blue; margin: 0;
}
div#inner
{width: 33%;
position: relative; left: 33%; top: 0;
border: solid thin red; margin: 0;
}
div#bottommatter
{clear: both;
background-color: yellow; min-height: 10mm;
border: solid thin red; margin: 0;
}
</style>
</head>
<body>
<h1> Preamble </h1>
<p>Stuff before the container
</p>
<div id="container">
<div id="floater">
<h2>Floating left</h2>
<p>line<br>line<br>line<br>line<br>line<br>line<br>line<br>line<br>
line<br>line<br>line<br>line<br>line<br>line<br>line<br>line<br>
line<br>line<br>line<br>line<br>line<br>line<br>line<br>line<br>
line<br>line<br>line<br>line<br>line<br>line<br>line<br>line<br>
</p>
<p> Should this text be within the boundary of the container
with the teal background?
</p>
</div>
<div id="inner">
<h2>Relative, left: 33%, top: 0</h2>
<p> Where (horizontally) should this block appear?</p>
<p> Where (vertically) should the text in this block appear?</p>
</div>
<!-- <div style="clear: both"></div>
Uncomment this division and it is clear that the
float should be contained within the bounds of the
teal container.
-->
</div>
<div id="bottommatter">
Bottom banner
</div>
</html>
It is available on line, but before you look at it with your
favourite browser, see if you can tell me how it *should*
appear, answering the questions in the text.
Mozilla 1.7.2, firefox 1.0PR and konqueror 3.1.4-7 all
display the same way, though not as I would expect. Opera
7.54 Final gives a different opinion about the containment
question, and MSIE6 on W98 is in a world of its own,
although in one respect does what I expect when none of the
others does.
For the containment question, I see this (REC-CSS2, 11.1):
Generally, the content of a block box is confined to the
content edges of the box. In certain cases, a box may
overflow, meaning its content lies partly or entirely
outside of the box, e.g.:
* A line cannot be broken, causing the line box to be
wider than the block box.
* A block-level box is too wide for the containing
block. This may happen when an element's 'width'
property has a value that causes the generated
block box to spill over sides of the containing
block.
* An element's height exceeds an explicit height
assigned to the containing block (i.e., the
containing block's height is determined by the
'height' property, not by content height).
* A box is positioned absolutely.
* It has negative margins.
none of these applies. What others are there?
For the horizontal position of the inner block (9.3; 9.3.1):
2 Floats.
In the float model, a box is first laid out according
to the normal flow, then taken out of the flow and
shifted to the left or right as far as
possible. Content may flow along the side of a float.
[...]
relative
The box's position is calculated according to the
normal flow (this is called the position in normal
flow). Then the box is offset relative to its normal
position. When a box B is relatively positioned, the
position of the following box is calculated as though
B were not offset.
Anyone care to commit to an answer before looking at <URL:
http://www.cl.cam.ac.uk/~jf/FloatAndRelative.html >?
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
| |
|
|
| Jón Fairbairn 2004-11-25, 9:37 pm |
| Lauri Raittila <lauri@raittila.cjb.net> writes:
> in comp.infosystems.www.authoring.stylesheets, Jón Fairbairn wrote:
>
> Read CSS21,
ie <URL: http://www.w3.org/TR/CSS21/ >?
> and errata for CSS2
ie <URL: http://www.w3.org/Style/css2-update...512-errata.html >?
do you include the errata to the errata from the mailing
lists? Surely CSS21 subsumes REC-CSS2-19980512-errata?
To whit:
ˇ Incorporating all published CSS2 errata.
so I should only need to read CSS21? At least it's a few
thousand words shorter than CSS2, but it also says:
Publication as a Candidate Recommendation does not imply
endorsement by the W3C Membership. It is inappropriate to
cite this document as other than work in progress.
So I don't really think it counts as an authority.
To precisely which (combinations) of these documents (if
any) do the user agents conform?
CSS21 also includes the potentially reassuring:
ˇ Where implementations overwhelmingly differ from the CSS2
specification, modifying the specification to be in
accordance with generally accepted practice.
but given that the code I posted produces three different
effects from four different engines, I don't find the
potential to be realised.
>
> 404
Whoops! But that should give you a chance to say what should
happen, without looking at what does happen, should it not?
It should have read <URL:
http://www.cl.cam.ac.uk/~jf/StyleTe...ndRelative.html
> assuming that I managed to cut and paste it properly this
time.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
| |
| Lauri Raittila 2004-11-26, 12:17 pm |
| in comp.infosystems.www.authoring.stylesheets, =?iso-8859-
1?q?J=F3n_Fairbairn?= wrote:
> Lauri Raittila <lauri@raittila.cjb.net> writes:
>
> ie <URL: http://www.w3.org/TR/CSS21/ >?
Yup
Yup.
[color=darkred]
> ie <URL: http://www.w3.org/Style/css2-update...512-errata.html >?
> so I should only need to read CSS21? At least it's a few
> So I don't really think it counts as an authority.
Neither has CSS2 errata any authority. But if errata explains what
is wrong in CSS2, you don't need to think it again. Easier than finding
every relelevant parts in CSS spec yourself...
> To precisely which (combinations) of these documents (if
> any) do the user agents conform?
Depends on how you define "conform". No modern browser conforms them
anyway. Browsers that don't support CSS at all conform specs, as they
don't have CSS bugs and CSS is optional.
>
> Whoops! But that should give you a chance to say what should
> happen, without looking at what does happen, should it not?
I prefer looking at code in my editor, not in my newsclient. And it is
pain to exaplain how it should work, using english. Much easier to
compare difference...
I can easily imagine how it should be rendered. I would take ages to
describe it, and you still most likely wouldn't understand. One image
is worth 1000 words, as they say.
> It should have read <URL:
> http://www.cl.cam.ac.uk/~jf/StyleTe...ndRelative.html
Never ever type URL by hand, if you can avoid it. You just make
mistakes...
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
| |
| Lauri Raittila 2004-11-26, 12:17 pm |
| in comp.infosystems.www.authoring.stylesheets, =?iso-8859-
1?q?J=F3n_Fairbairn?= wrote:
>
> I keep reading the definition of CSS2, but am having
> difficulty acquiring the precise meaning of certain of the
> concepts.
http://www.cl.cam.ac.uk/~jf/StyleTe...ndRelative.html
> <p> Should this text be within the boundary of the container
> with the teal background?
No. IE has bug, as well as about 7.5x Opera, Opera before that gets it
correct, Opera after that gets it correct only in standards mode.
> <h2>Relative, left: 33%, top: 0</h2>
> <p> Where (horizontally) should this block appear?</p>
Same as whitout relative positioning.
> <p> Where (vertically) should the text in this block appear?</p>
33% of container width from left inner edge of container.
> Uncomment this division and it is clear that the
> float should be contained within the bounds of the
> teal container.
Correct. There is bug in Gecko. It doesn't like empty elements.
> Mozilla 1.7.2, firefox 1.0PR and konqueror 3.1.4-7 all
> display the same way, though not as I would expect.
I am surpriced of konqueror. Does it make diffrence, if you use nonempty
div for clearing up stuff?
> Opera
> 7.54 Final gives a different opinion about the containment
> question, and MSIE6 on W98 is in a world of its own,
> although in one respect does what I expect when none of the
> others does.
Opera 7.6 preview 3 gets everything correctly.
> For the containment question, I see this (REC-CSS2, 11.1):
> none of these applies. What others are there?
float is taken out of normal flow. So it is not really content of said
block.
> relative
>
> The box's position is calculated according to the
> normal flow (this is called the position in normal
> flow). Then the box is offset relative to its normal
> position. When a box B is relatively positioned, the
> position of the following box is calculated as though
> B were not offset.
If you both float and relatively position element, it is implemented
mostly as if relative positioning is done after float is taken out of
flow, but it seems that it should be done first. Irrelevat on your
current test page..
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
| |
| Jón Fairbairn 2004-11-26, 7:20 pm |
| Lauri Raittila <lauri@raittila.cjb.net> writes:
> in comp.infosystems.www.authoring.stylesheets, Jón Fairbairn wrote:
>
> http://www.cl.cam.ac.uk/~jf/StyleTe...ndRelative.html
>
>
> No.
This is one of the things I find difficult to like.
> IE has bug, as well as about 7.5x Opera, Opera before that gets it
> correct, Opera after that gets it correct only in standards mode.
The full doctype on my page is sufficent to cause Opera to go
into standards mode, isn't it?
>
> Same as whitout relative positioning.
>
>
> 33% of container width from left inner edge of container.
You seem to have your answers swapped? The left edge should
be 33% of the container width from where it would appear
without positioning, and the top exactly where it would have
appeared.
>
> Correct. There is bug in Gecko. It doesn't like empty elements.
OK
>
> I am surpriced of konqueror. Does it make diffrence, if
> you use nonempty div for clearing up stuff?
I'll have to check this later; the machine I'm using now
doesn't have konqueror. The browser specific aspects of what
follows concern Opera 7.6
>
> Opera 7.6 preview 3 gets everything correctly.
I've just looked at the page with 7.60 p3, and I'm not
convinced. I'm willing to accept that the bottom of an
overlong float should poke out of the container (if I can
find the right piece of verbiage in the docs), but I don't
see how the positioning of the inner block can be right.
If you replace "left: 33%" with "left: 0", the text in
#inner appears below the float. Now, the bits I've read
about relative positioning lead me to understand that the
effect should be to format the block as if it were not
positioned, and then move it by the amount specified. But
Opera changes the shape of the block after it has moved it.
One of the difficulties is that rather than making #inner
flow past the float, it is the content of #inner that does
the flowing.
>
>
> float is taken out of normal flow. So it is not really
> content of said block.
I can accept that, as far as containment is concerned.
>
> If you both float and relatively position element, it is
> implemented mostly as if relative positioning is done
> after float is taken out of flow, but it seems that it
> should be done first. Irrelevat on your current test
> page..
Yes. I'm only relatively positioning a normal block.
The problem I'm having is in building up a picture of what
the formatting of the content of a block depends on. It
seems reasonable to expect that it will depend on either the
width, height (, padding &c) specified for the block (which
may themselves be dependent on the container, and where not
specified, the intrinsic dimensions of the content.
It's much less clear that it need be the case (in future
stylesheet languages) that it should also depend on such
things as whether there is anything floating in the
containing block. Certainly the /position/ depends on such
things, but is it really necessary that the flow inside the
block be disrupted that way?
In
<div id="a">
<div id="f" style="float: left;...">
...stuff...
</div>
inline level stuff
<div id="b">...
</div>
</div>
The "inline level stuff" will flow around to the right of
"f". Now, since "b" doesn't have "clear" set, I would expect
that (assuming it's small enough and that "inline level
stuff" doesn't take us past the float) "b" should also
appear /as an entire block/ to the right of "f". (If "b" had
"display: inline" it would be different).
What happens in the present scheme appears to be that "b" is
positioned below "inline level stuff", but instead of being
positioned to the right of "f", it overlays it, and its
padding-left is replaced by max(padding-left(b),width(f)) to
leave room for "f". I would expect this to be the source of
much confusion, as well as requiring too much knowledge
about the environment when coding inner blocks.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
| |
| Jón Fairbairn 2004-11-26, 7:20 pm |
| Lauri Raittila <lauri@raittila.cjb.net> writes:
> Neither has CSS2 errata any authority. But if errata
> explains what is wrong in CSS2, you don't need to think it
> again. Easier than finding every relelevant parts in CSS
> spec yourself...
True enough.
>
> I prefer looking at code in my editor, not in my newsclient.
Fair enough. My editor is my newsclient :-)
> And it is pain to exaplain how it should work, using
> english. Much easier to compare difference...
>
> I can easily imagine how it should be rendered. I would take ages to
> describe it, and you still most likely wouldn't understand. One image
> is worth 1000 words, as they say.
Yes, but what I wanted to avoid was people looking at the
page and back-deriving an explanation from that. What I'm
really interested in is the extent to which CSS is
understood and understandable. Unfortunately yours have been
the only replies, so my real question remains unanswered.
Thanks for your replies, by the way.
>
> Never ever type URL by hand, if you can avoid it. You just make
> mistakes...
I know. In case you are interested in the ćtiology of
mistakes: I cut and pasted the link from a browser window,
but then realised that that server is not visible to the
outside world, so copied the page somewhere accessible and
edited the link by hand...
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
| |
| Lauri Raittila 2004-11-26, 7:20 pm |
| in comp.infosystems.www.authoring.stylesheets, =?iso-8859-1?q?J=F3n?=
Fairbairn wrote:
>
> Yes, but what I wanted to avoid was people looking at the
> page and back-deriving an explanation from that.
Well, I did know rendering in Gecko, Opera and IE even whitout first
looking at it... That is one reason describtion would have been long...
I never did look it at Gecko, IE or Opera 7.54, and I did describe the
bugs in them, didn't I?
> What I'm really interested in is the extent to which CSS is
> understood and understandable.
It is quite understandable. After you remember the spec
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
| |
| Lauri Raittila 2004-11-26, 7:20 pm |
| in comp.infosystems.www.authoring.stylesheets, =?iso-8859-1?q?J=F3n?=
Fairbairn wrote:
> Lauri Raittila <lauri@raittila.cjb.net> writes:
>
>
> This is one of the things I find difficult to like.
But that is *very* clear in spec.
s/that/Opera 7.5x/g
[color=darkred]
> The full doctype on my page is sufficent to cause Opera to go
> into standards mode, isn't it?
Yes, but there is bug on 7.5x series. Anything newer and older should
render stuff correctly, newer only if in standards mode.
>
> You seem to have your answers swapped?
Yes. Somehow I always think first vertical and then horizontal
positioning...
[color=darkred]
>
> I've just looked at the page with 7.60 p3, and I'm not
> convinced. I'm willing to accept that the bottom of an
> overlong float should poke out of the container (if I can
> find the right piece of verbiage in the docs), but I don't
> see how the positioning of the inner block can be right.
It is. Floats only have effect on text lines, not block elements. As your
elelement is about same size as float, text lines are moved down untill
there is enaugh space.
> If you replace "left: 33%" with "left: 0", the text in
> #inner appears below the float.
As it does whitout position:relative and left:0 too.
> Now, the bits I've read
> about relative positioning lead me to understand that the
> effect should be to format the block as if it were not
> positioned, and then move it by the amount specified.
Yes.
> But
> Opera changes the shape of the block after it has moved it.
The block shape is not relevant, it's top left corner is.
> One of the difficulties is that rather than making #inner
> flow past the float, it is the content of #inner that does
> the flowing.
That is because your #inner is too narrow to have text beside float.
There is about 1ex space between border of float and border of #inner.
Your text don't fit in that space.
> The problem I'm having is in building up a picture of what
> the formatting of the content of a block depends on. It
> seems reasonable to expect that it will depend on either the
> width, height (, padding &c) specified for the block (which
> may themselves be dependent on the container, and where not
> specified, the intrinsic dimensions of the content.
Yes.
> It's much less clear that it need be the case (in future
> stylesheet languages) that it should also depend on such
> things as whether there is anything floating in the
> containing block.
Well, that has effect on text line lenghts, so it has effect on number of
text lines as well.
How the hell you think float would work, if it would not affect on
rendering something? It would be same as absolute positioning then.
> Certainly the /position/ depends on such
> things, but is it really necessary that the flow inside the
> block be disrupted that way?
How the hell would you do it then? The whole point of float is that.
> <div id="a">
> <div id="f" style="float: left;...">
> ...stuff...
> </div>
> inline level stuff
> <div id="b">...
> </div>
> </div>
>
> The "inline level stuff" will flow around to the right of
> "f".
Right.
> Now, since "b" doesn't have "clear" set, I would expect
> that (assuming it's small enough and that "inline level
> stuff" doesn't take us past the float) "b" should also
> appear /as an entire block/ to the right of "f". (If "b" had
> "display: inline" it would be different).
No. That would not be good. If you want that use display:table for .b
And more importantly, that was not the way it is defined.
> What happens in the present scheme appears to be that "b" is
> positioned below "inline level stuff", but instead of being
> positioned to the right of "f", it overlays it, and its
> padding-left is replaced by max(padding-left(b),width(f)) to
> leave room for "f". I would expect this to be the source of
> much confusion, as well as requiring too much knowledge
> about the environment when coding inner blocks.
That is exactly same method used for floating stuff since NN1 and maybe
before. It has worked just fine. It would have made no sence to change
definition of float to something more complicated.
I think your problem is that you don't think float as float but some way
to archive layout which would be better done using CSS tables.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
| |
| Gus Richter 2004-11-26, 7:20 pm |
| Jón Fairbairn wrote:
> I keep reading the definition of CSS2, but am having
> difficulty acquiring the precise meaning of certain of the
> concepts.
>
> Here's a document with valid html and css:
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> <html>
> <head>
> <title>Float, Relative and Containment</title>
>
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
>
> <style type="text/css">
>
> div#container
> {background-color: teal;
> position: relative;
> border: solid thin green; margin: 0; padding: 0;
> }
> div#floater
> {float: left; background-color: transparent;
> width: 32%;
> border: solid thin blue; margin: 0;
> }
> div#inner
> {width: 33%;
> position: relative; left: 33%; top: 0;
> border: solid thin red; margin: 0;
> }
> div#bottommatter
> {clear: both;
> background-color: yellow; min-height: 10mm;
> border: solid thin red; margin: 0;
> }
>
> </style>
>
> </head>
> <body>
> <h1> Preamble </h1>
> <p>Stuff before the container
> </p>
>
> <div id="container">
> <div id="floater">
> <h2>Floating left</h2>
> <p>line<br>line<br>line<br>line<br>line<br>line<br>line<br>line<br>
> line<br>line<br>line<br>line<br>line<br>line<br>line<br>line<br>
> line<br>line<br>line<br>line<br>line<br>line<br>line<br>line<br>
> line<br>line<br>line<br>line<br>line<br>line<br>line<br>line<br>
> </p>
> <p> Should this text be within the boundary of the container
> with the teal background?
> </p>
> </div>
> <div id="inner">
> <h2>Relative, left: 33%, top: 0</h2>
> <p> Where (horizontally) should this block appear?</p>
> <p> Where (vertically) should the text in this block appear?</p>
>
> </div>
> <!-- <div style="clear: both"></div>
> Uncomment this division and it is clear that the
> float should be contained within the bounds of the
> teal container.
> -->
> </div>
> <div id="bottommatter">
> Bottom banner
>
> </div>
> </html>
>
>
> It is available on line, but before you look at it with your
> favourite browser, see if you can tell me how it *should*
> appear, answering the questions in the text.
>
> Mozilla 1.7.2, firefox 1.0PR and konqueror 3.1.4-7 all
> display the same way, though not as I would expect. Opera
> 7.54 Final gives a different opinion about the containment
> question, and MSIE6 on W98 is in a world of its own,
> although in one respect does what I expect when none of the
> others does.
>
>
> For the containment question, I see this (REC-CSS2, 11.1):
>
> Generally, the content of a block box is confined to the
> content edges of the box. In certain cases, a box may
> overflow, meaning its content lies partly or entirely
> outside of the box, e.g.:
>
> * A line cannot be broken, causing the line box to be
> wider than the block box.
>
> * A block-level box is too wide for the containing
> block. This may happen when an element's 'width'
> property has a value that causes the generated
> block box to spill over sides of the containing
> block.
>
> * An element's height exceeds an explicit height
> assigned to the containing block (i.e., the
> containing block's height is determined by the
> 'height' property, not by content height).
>
> * A box is positioned absolutely.
>
> * It has negative margins.
>
> none of these applies. What others are there?
>
> For the horizontal position of the inner block (9.3; 9.3.1):
>
>
> 2 Floats.
>
> In the float model, a box is first laid out according
> to the normal flow, then taken out of the flow and
> shifted to the left or right as far as
> possible. Content may flow along the side of a float.
>
> [...]
>
> relative
>
> The box's position is calculated according to the
> normal flow (this is called the position in normal
> flow). Then the box is offset relative to its normal
> position. When a box B is relatively positioned, the
> position of the following box is calculated as though
> B were not offset.
>
> Anyone care to commit to an answer before looking at <URL:
> http://www.cl.cam.ac.uk/~jf/FloatAndRelative.html >?
>
Gecko displays correctly.
Any deviation of this is wrong (i.e. Opera 7.54 gets it wrong (bug
submitted some time ago) - and IE doesn't get it at all).
#floater is floated (out of flow) left inside of #container, which
aligns it to the top of #container (convince yourself by adding
margin-top:0; to H2 - Opera also has a problem with margin-top to the
heading here).
The top edge of #inner is automatically aligned to the top edge of the
floated #floater (top: 0; is superfluous for #inner (as is margin:0;))
simply because it follows the floated item (part of the float box),
however the content of #inner is _Relatively Positioned_ relative to the
bottom edge of #floater causing the text in #inner to start at the
bottom edge of #floater (this is where Opera 7.54 gets it wrong).
#inner
{width: 33%; position: relative; left: 33%; border: solid thin red;}
#floater and #inner are parts of the float box and are both inside
#container and therefore will both be within the teal area since the
height of #container takes that of @inner.
Try this, without position:relative; (instead of the previous), to see
the difference.
#inner
{width: 33%; margin-left: 33%; border: solid thin red;}
In this case #inner box and text are both aligned to the top edge of
#floater and the tealed background once again extends to the height of
#inner. Remember that #floater is floated and therefore out of the flow
and therefore extends below the teal area in this case.
--
Gus
| |
|
|
| Jón Fairbairn 2004-11-30, 7:18 pm |
| Lauri Raittila <lauri@raittila.cjb.net> writes:
> in comp.infosystems.www.authoring.stylesheets, Jón Fairbairn wrote:
>
> Read CSS21,
ie <URL: http://www.w3.org/TR/CSS21/ >?
> and errata for CSS2
ie <URL: http://www.w3.org/Style/css2-update...512-errata.html >?
do you include the errata to the errata from the mailing
lists? Surely CSS21 subsumes REC-CSS2-19980512-errata?
To whit:
ˇ Incorporating all published CSS2 errata.
so I should only need to read CSS21? At least it's a few
thousand words shorter than CSS2, but it also says:
Publication as a Candidate Recommendation does not imply
endorsement by the W3C Membership. It is inappropriate to
cite this document as other than work in progress.
So I don't really think it counts as an authority.
To precisely which (combinations) of these documents (if
any) do the user agents conform?
CSS21 also includes the potentially reassuring:
ˇ Where implementations overwhelmingly differ from the CSS2
specification, modifying the specification to be in
accordance with generally accepted practice.
but given that the code I posted produces three different
effects from four different engines, I don't find the
potential to be realised.
>
> 404
Whoops! But that should give you a chance to say what should
happen, without looking at what does happen, should it not?
It should have read <URL:
http://www.cl.cam.ac.uk/~jf/StyleTe...ndRelative.html
> assuming that I managed to cut and paste it properly this
time.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|