473,320 Members | 1,841 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Where is the extra vertical space coming from?

This has me stumped. I am trying to use as little space as possible at
the top of my document but Firefox/Mozilla insists on placing vertical
space before any element. IE displays it correctly (as I want). At one
point, I set some negative top margins which moved the graphics above
the page in IE. Here's the link: http://abateofnm.org/ I've tried
reformatting the HTML to assure there is no white space and I've tried
setting top margins and padding to 0, all with no luck. Strangely, it
seems to be using the height of the flag images as a top margin or
something.

--
Stan McCann "Uncle Pirate" http://stanmccann.us/pirate.html
Webmaster/Computer Center Manager, NMSU at Alamogordo
Coordinator, Tularosa Basin Chapter, ABATE of NM; AMA#758681; COBB
'94 1500 Vulcan (now wrecked) :( http://motorcyclefun.org/Dcp_2068c.jpg
A zest for living must include a willingness to die. - R.A. Heinlein
Jul 21 '05 #1
16 9217
Uncle Pirate wrote:
This has me stumped. I am trying to use as little space as possible at
the top of my document but Firefox/Mozilla insists on placing vertical
space before any element. IE displays it correctly (as I want). At one
point, I set some negative top margins which moved the graphics above
the page in IE. Here's the link: http://abateofnm.org/ I've tried
reformatting the HTML to assure there is no white space and I've tried
setting top margins and padding to 0, all with no luck. Strangely, it
seems to be using the height of the flag images as a top margin or
something.


The space is no doubt being generated by the top margin on first element
after the two floats, H1. The floats need to be contained and the
container needs sufficient height. What Mozilla is doing is correct I
believe.

Louise
Jul 21 '05 #2
DU
Uncle Pirate wrote:
This has me stumped. I am trying to use as little space as possible at
the top of my document but Firefox/Mozilla insists on placing vertical
space before any element. IE displays it correctly (as I want). At one
point, I set some negative top margins which moved the graphics above
the page in IE. Here's the link: http://abateofnm.org/ I've tried
reformatting the HTML to assure there is no white space and I've tried
setting top margins and padding to 0, all with no luck. Strangely, it
seems to be using the height of the flag images as a top margin or
something.


Why are there gaps between image rows in tables when the layout engine
is in the Standards mode?
http://www.mozilla.org/docs/web-developer/faq.html#gaps

Why are there still gaps even between text rows in tables when the
layout engine is in the Standards mode or in the Almost Standards mode?
http://www.mozilla.org/docs/web-deve...q.html#margins

DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Mozilla 1.7.6 :)
Jul 21 '05 #3
DU wrote:
Uncle Pirate wrote:
This has me stumped. I am trying to use as little space as possible
at the top of my document but Firefox/Mozilla insists on placing
vertical space before any element. IE displays it correctly (as I
want). At one point, I set some negative top margins which moved the
graphics above the page in IE. Here's the link:
http://abateofnm.org/ I've tried reformatting the HTML to assure
there is no white space and I've tried setting top margins and padding
to 0, all with no luck. Strangely, it seems to be using the height of
the flag images as a top margin or something.


Why are there gaps between image rows in tables when the layout engine
is in the Standards mode?
http://www.mozilla.org/docs/web-developer/faq.html#gaps

Why are there still gaps even between text rows in tables when the
layout engine is in the Standards mode or in the Almost Standards mode?
http://www.mozilla.org/docs/web-deve...q.html#margins


Did you even look? Did you see any tables anywhere?

--
Stan McCann "Uncle Pirate" http://stanmccann.us/pirate.html
Webmaster/Computer Center Manager, NMSU at Alamogordo
Coordinator, Tularosa Basin Chapter, ABATE of NM; AMA#758681; COBB
'94 1500 Vulcan (now wrecked) :( http://motorcyclefun.org/Dcp_2068c.jpg
A zest for living must include a willingness to die. - R.A. Heinlein
Jul 21 '05 #4
in comp.infosystems.www.authoring.stylesheets, Uncle Pirate wrote:
This has me stumped. I am trying to use as little space as possible at
the top of my document but Firefox/Mozilla insists on placing vertical
space before any element. IE displays it correctly (as I want).


IE has most buggy collapsing margin support. As
* {margin:0 !important;} cures your problem, that is very likely to be
the reason. Find the margin, and make it 0.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Jul 21 '05 #5
Lauri Raittila wrote:
in comp.infosystems.www.authoring.stylesheets, Uncle Pirate wrote:
This has me stumped. I am trying to use as little space as possible at
the top of my document but Firefox/Mozilla insists on placing vertical
space before any element. IE displays it correctly (as I want).

IE has most buggy collapsing margin support. As
* {margin:0 !important;} cures your problem,


Now that is what I call beautiful. I had not thought of this.
that is very likely to be
the reason. Find the margin, and make it 0.


There is more to this than meets the eye. A great exercise (for me at
least) in gaining greater understanding. These are my tries, solutions
and findings:

SOLUTION #1: Set the margin-top of H1 to zero and use padding to move H1
down - the reason for the gap is that the overall-float-box takes on the
margin-top value from the H1 block (it doesn't for an inline block such
as P) and moves everything (the overall-float-box and content) down by
that amount. FF, IE and Opera are all happy.

SOLUTION #2: Following Louise Boclair's suggestion (the container height
suggestion has no effect), wrap the Logo, Flags and H1 in a DIV wrapper
and it must also have a border (I have not yet worked out why it needs a
border, but it doesn't work without one) - works in all if margin-top
for H1 = 0 for this example, but in Opera and IE the margin-top is
calculated strangely if > 0 (from the top of the wrapper for FF - from
the bottom of the image box for IE and Opera). So, if H1 is desired to
be moved lower, just as in Solution #1, H1's top-margin must be set to
zero and padding used, which make FF, IE and Opera all happy.

SOLUTION #3 & #4 (partial): display:table applied to H1 works very well
in FF, seems to work in IE, but not in Opera 7.54. -
display:inline-block applied to H1 seems to work in Opera 7.54, although
somewhat strangely, and not at all in FF and IE.

--
Gus
Jul 21 '05 #6
in comp.infosystems.www.authoring.stylesheets, Gus Richter wrote:
Lauri Raittila wrote:
in comp.infosystems.www.authoring.stylesheets, Uncle Pirate wrote:
This has me stumped. I am trying to use as little space as possible at
the top of my document but Firefox/Mozilla insists on placing vertical
space before any element. IE displays it correctly (as I want).

IE has most buggy collapsing margin support. As
* {margin:0 !important;} cures your problem,


Now that is what I call beautiful. I had not thought of this.


That is easy way to confirm initial though of problem being collapsing
margins. In standards mode, unvanted vertical space is because collapsing
margin for about 99% or cases...
There is more to this than meets the eye. A great exercise (for me at
least) in gaining greater understanding. These are my tries, solutions
and findings:


Google for "collapsing margins" and try find good explanation

Opera has best support for collapsing margins in my experience.

Basically, all vertical margins that are adjoining (there is no content,
padding or border between them) are considered and biggest one is using.
Floats are exeption.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Jul 21 '05 #7
Gus Richter wrote:
There is more to this than meets the eye. A great exercise (for me at
least) in gaining greater understanding. These are my tries, solutions
and findings:

SOLUTION #1: Set the margin-top of H1 to zero and use padding to move H1
down - the reason for the gap is that the overall-float-box takes on the
margin-top value from the H1 block (it doesn't for an inline block such
as P) and moves everything (the overall-float-box and content) down by
that amount. FF, IE and Opera are all happy.
Doesn't allow me to place the h1 partly in the graphic as I'm trying to
do. I want the text beginning just down and to the left of the image
over the transparant portion. I didn't really want to create the image
containing the text. I suppose I could absolutely position so that I
can use z-index.

SOLUTION #2: Following Louise Boclair's suggestion (the container height
suggestion has no effect), wrap the Logo, Flags and H1 in a DIV wrapper
and it must also have a border (I have not yet worked out why it needs a
border, but it doesn't work without one) - works in all if margin-top
for H1 = 0 for this example, but in Opera and IE the margin-top is
calculated strangely if > 0 (from the top of the wrapper for FF - from
the bottom of the image box for IE and Opera). So, if H1 is desired to
be moved lower, just as in Solution #1, H1's top-margin must be set to
zero and padding used, which make FF, IE and Opera all happy.
Another way is just to place a bordered div before the floated objects.
Like you though, why does it have to have a border? Weird. This is
probably (weird as it is) the way I'll go with it. It's something weird
with float because if I don't float anything, it sits right up at the
top of page where I want it. Floating moves it down unless I have an
unfloated, bordered object before the floats.

SOLUTION #3 & #4 (partial): display:table applied to H1 works very well
in FF, seems to work in IE, but not in Opera 7.54. -
display:inline-block applied to H1 seems to work in Opera 7.54, although
somewhat strangely, and not at all in FF and IE.


I prefer not to use fixes specified on a per browser basis. I'm in the
"I'll find a different way" category. I don't expect pages to look
identical, just as close as I can get them without going into methods
for this or that browser.

--
Stan McCann "Uncle Pirate" http://stanmccann.us/pirate.html
Webmaster/Computer Center Manager, NMSU at Alamogordo
Coordinator, Tularosa Basin Chapter, ABATE of NM; AMA#758681; COBB
'94 1500 Vulcan (now wrecked) :( http://motorcyclefun.org/Dcp_2068c.jpg
A zest for living must include a willingness to die. - R.A. Heinlein
Jul 21 '05 #8
Lauri Raittila wrote:
in comp.infosystems.www.authoring.stylesheets, Gus Richter wrote:
Lauri Raittila wrote:
in comp.infosystems.www.authoring.stylesheets, Uncle Pirate wrote:
This has me stumped. I am trying to use as little space as possible at
the top of my document but Firefox/Mozilla insists on placing vertical
space before any element. IE displays it correctly (as I want).
IE has most buggy collapsing margin support. As
* {margin:0 !important;} cures your problem,


Now that is what I call beautiful. I had not thought of this.

That is easy way to confirm initial though of problem being collapsing
margins. In standards mode, unvanted vertical space is because collapsing
margin for about 99% or cases...

There is more to this than meets the eye. A great exercise (for me at
least) in gaining greater understanding. These are my tries, solutions
and findings:

Google for "collapsing margins" and try find good explanation


Thank you very much for the push in the right direction. At first I
thought you were wrong, since I could not see any collapsing margin
relationship. This site
http://www.researchkitchen.de/blog/a...collapsing.php
explains it all beautifully. This explains my Solution #2 as well as
Solution #1.

--
Gus
Jul 21 '05 #9
Uncle Pirate wrote:
Gus Richter wrote:
There is more to this than meets the eye. A great exercise (for me at
least) in gaining greater understanding. These are my tries, solutions
and findings:

SOLUTION #1: Set the margin-top of H1 to zero and use padding to move
H1 down - the reason for the gap is that the overall-float-box takes
on the margin-top value from the H1 block (it doesn't for an inline
block such as P) and moves everything (the overall-float-box and
content) down by that amount. FF, IE and Opera are all happy.

Doesn't allow me to place the h1 partly in the graphic as I'm trying to
do. I want the text beginning just down and to the left of the image
over the transparant portion. I didn't really want to create the image
containing the text. I suppose I could absolutely position so that I
can use z-index.


Yes that you could try that. One thing to note is that you don't need to
use z-index, so long as the absolute positioned item comes after the
item to be overlayed - this uses automatic z-indexing. If you want to
overlay H1 over the left floated image, I think that Solution #2 is the
best approach.
SOLUTION #2: Following Louise Boclair's suggestion (the container
height suggestion has no effect), wrap the Logo, Flags and H1 in a DIV
wrapper and it must also have a border (I have not yet worked out why
it needs a border, but it doesn't work without one) - works in all if
margin-top for H1 = 0 for this example, but in Opera and IE the
margin-top is calculated strangely if > 0 (from the top of the wrapper
for FF - from the bottom of the image box for IE and Opera). So, if H1
is desired to be moved lower, just as in Solution #1, H1's top-margin
must be set to zero and padding used, which make FF, IE and Opera all
happy.

Another way is just to place a bordered div before the floated objects.
Like you though, why does it have to have a border? Weird. This is
probably (weird as it is) the way I'll go with it. It's something weird
with float because if I don't float anything, it sits right up at the
top of page where I want it. Floating moves it down unless I have an
unfloated, bordered object before the floats.


Read up on the link I mentioned in my response to Lauri. It explains it
regarding Collapsing Margins. I'll have to go through it a couple of
more times to fully understand it.
SOLUTION #3 & #4 (partial): display:table applied to H1 works very
well in FF, seems to work in IE, but not in Opera 7.54. -
display:inline-block applied to H1 seems to work in Opera 7.54,
although somewhat strangely, and not at all in FF and IE.


I prefer not to use fixes specified on a per browser basis. I'm in the
"I'll find a different way" category. I don't expect pages to look
identical, just as close as I can get them without going into methods
for this or that browser.


Agreed. I only provided them as additional information and as food for
thought.

--
Gus
Jul 21 '05 #10
Gus Richter wrote:
Uncle Pirate wrote:

Another way is just to place a bordered div before the floated
objects. Like you though, why does it have to have a border? Weird.
This is probably (weird as it is) the way I'll go with it. It's
something weird with float because if I don't float anything, it sits
right up at the top of page where I want it. Floating moves it down
unless I have an unfloated, bordered object before the floats.

Read up on the link I mentioned in my response to Lauri. It explains it
regarding Collapsing Margins. I'll have to go through it a couple of
more times to fully understand it.


Oh that's good. And explains what's happening. My bordered div before
my floats could be accomplished simply by setting a small padding on
body and possibly a border if I read right. I've got to study that some
and do some experimenting. Thanks for the link.

--
Stan McCann "Uncle Pirate" http://stanmccann.us/pirate.html
Webmaster/Computer Center Manager, NMSU at Alamogordo
Coordinator, Tularosa Basin Chapter, ABATE of NM; AMA#758681; COBB
'94 1500 Vulcan (now wrecked) :( http://motorcyclefun.org/Dcp_2068c.jpg
A zest for living must include a willingness to die. - R.A. Heinlein
Jul 21 '05 #11
Gus Richter wrote:
Lauri Raittila wrote:
in comp.infosystems.www.authoring.stylesheets, Uncle Pirate wrote:
This has me stumped. I am trying to use as little space as possible
at the top of my document but Firefox/Mozilla insists on placing
vertical space before any element. IE displays it correctly (as I
want).
IE has most buggy collapsing margin support. As * {margin:0
!important;} cures your problem,

SOLUTION #2: Following Louise Boclair's suggestion (the container height
suggestion has no effect), wrap the Logo, Flags and H1 in a DIV wrapper
and it must also have a border (I have not yet worked out why it needs a
border, but it doesn't work without one) - works in all if margin-top
for H1 = 0 for this example, but in Opera and IE the margin-top is
calculated strangely if > 0 (from the top of the wrapper for FF - from
the bottom of the image box for IE and Opera). So, if H1 is desired to
be moved lower, just as in Solution #1, H1's top-margin must be set to
zero and padding used, which make FF, IE and Opera all happy.


Apologies for not following the progress of this thread but, as a non
expert on CSS, I hope it is acceptable to reopen the discussion.

What I actually said was
"The space is no doubt being generated by the top margin on first
element after the two floats, H1. The floats need to be contained and
the container needs sufficient height. What Mozilla is doing is correct
I believe."

No doubt I have used wrong terms but I did not have in mind a div
wrapper with height declared. By "container" I meant "containing block";
by "height" I meant height generated by inline-height; all as
described in the Visual Formatting Model. Based on the float rules as
set out, it does seem to me that how Mozilla (Foxfire) renders is
logical. But I am wondering if I have misunderstood the Model.

My conclusions, right or wrong, came in developing a solution for
rendering a page heading the consisted of a left and a right floated object

To demonstrate what I understand I have put up a few web pages,
temporarily, borrowing some of the objects of Uncle Pirate's Abate page.

http://www.boclair.com/test/abate1.php is meant to repeat something like
the original situation where, in Foxfire, the vertical space above the
floated flags div is equal to the top margin of the following H1
element. As I read the Model, the existence of a containing block is
necessary to the vertical position a float and as the H1 element is the
first block element in the flow, the H1 block is treated the containing
block by Foxfire (In passing I notice that even if clear is declared in
H1, Foxfire still treats the H1 element as the containing block .. not
demonstrated)

http://www.boclair.com/test/abate2.php is produced following this line
of thought. An empty div is introduced before the H1 element. This
doesn't alter the rendering.

As I recall from earlier days empty divs were bad practice. The
Formatting Model also says, "A float is a box that is shifted to the
left or right on the current line." It seems illogical for an empty div
to create a current line, so:
http://www.boclair.com/test/abate3.php shows what happens when content
is inserted into the introduced div. It is interesting that now both
Foxfire and IE6 render similarly. (This is what I was alluding to in my
comment about the containing block needing height)

The space needed for rendering the introduced div, forces the H1 text
out of the desired position. The simplest solution is to reduce the
overall height of the introduced div to zero height. This is done in
http://www.boclair.com/test/abate4.php

It seems that it is not so much height that is needed as content. (Meta
physically at least I suppose "zero height" is not the same as "no height")

Louise

Jul 21 '05 #12
in comp.infosystems.www.authoring.stylesheets, boclair wrote:
http://www.boclair.com/test/abate1.php is meant to repeat something like
H1 block is treated the containing block by Foxfire
You got it wrong. In this case, margins of body, div and h1 are
collapsed, and margin is drawn for body element. Containing block is div.
http://www.boclair.com/test/abate2.php is produced following this line
of thought. An empty div is introduced before the H1 element. This
doesn't alter the rendering.
That is good thing. As it shouldn't. There seems to be bug in Opera 8b3
here...
As I recall from earlier days empty divs were bad practice.
Yes.
http://www.boclair.com/test/abate3.php shows what happens when content
is inserted into the introduced div. It is interesting that now both
Foxfire and IE6 render similarly.
Margin of h1 and body is not collapsed, as there is content inbetween.
It seems that it is not so much height that is needed as content.


Correct. If there is any border, padding or content between margins, they
don't collapse.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Jul 21 '05 #13
Lauri Raittila wrote:
in comp.infosystems.www.authoring.stylesheets, boclair wrote:

http://www.boclair.com/test/abate1.php is meant to repeat something like
H1 block is treated the containing block by Foxfire

You got it wrong. In this case, margins of body, div and h1 are
collapsed, and margin is drawn for body element. Containing block is div.


I need to (try to)understand what you have said and why it is so.

The only substantive material I have located is the "Box Model"
document, specifically Section 8.3.1. It says in part "Vertical margins
between a floated box and any other box do not collapse."

There must be something else tucked away elsewhere.

Would you expand on this please?

Louise
Jul 21 '05 #14
in comp.infosystems.www.authoring.stylesheets, boclair wrote:
It says in part "Vertical margins
between a floated box and any other box do not collapse."
Correct. Neither body, any of divs or h1 is floated.
There must be something else tucked away elsewhere.

Would you expand on this please?


Sorry, don't have energy. There is one very, very long thread findable
using google about vertical margin, where I point it out very very
clearly...
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Jul 21 '05 #15
boclair wrote:
Apologies for not following the progress of this thread but, as a non
expert on CSS, I hope it is acceptable to reopen the discussion.
As the OP of the thread, I don't mind.

What I actually said was
"The space is no doubt being generated by the top margin on first
element after the two floats, H1. The floats need to be contained and
the container needs sufficient height. What Mozilla is doing is correct
I believe."

No doubt I have used wrong terms but I did not have in mind a div
wrapper with height declared. By "container" I meant "containing block";
by "height" I meant height generated by inline-height; all as
described in the Visual Formatting Model. Based on the float rules as
set out, it does seem to me that how Mozilla (Foxfire) renders is
logical. But I am wondering if I have misunderstood the Model.

My conclusions, right or wrong, came in developing a solution for
rendering a page heading the consisted of a left and a right floated object
Right or wrong, I've solved the problem temporarily with an unfloated
object just before the floated object and setting the other image as
page background which I may change to a div background with the div
containing the floated flags and the h1, which as you point out should
do what I want it to. You and Lauri have both helped me figure out more
about vertical spacing. I've run into several of what I thought were
oddities in how vertical spacing worked differently due to a border over
the years. This explains all those "oddities."

To demonstrate what I understand I have put up a few web pages,
temporarily, borrowing some of the objects of Uncle Pirate's Abate page.


OK, just give 'em back when you're done. :)

Snipped lots to chew on.

--
Stan McCann "Uncle Pirate" http://stanmccann.us/pirate.html
Webmaster/Computer Center Manager, NMSU at Alamogordo
Coordinator, Tularosa Basin Chapter, ABATE of NM; AMA#758681; COBB
'94 1500 Vulcan (now wrecked) :( http://motorcyclefun.org/Dcp_2068c.jpg
A zest for living must include a willingness to die. - R.A. Heinlein
Jul 21 '05 #16
Lauri Raittila wrote:
in comp.infosystems.www.authoring.stylesheets, boclair wrote:

It says in part "Vertical margins
between a floated box and any other box do not collapse."

Correct. Neither body, any of divs or h1 is floated.

There must be something else tucked away elsewhere.

Would you expand on this please?

Sorry, don't have energy. There is one very, very long thread findable
using google about vertical margin, where I point it out very very
clearly...


Having ploughed through umpteen ciwas articles I have at last got it (I
think).

http://www.boclair.com/test/abate6.php is the original
http://www.boclair.com/test/abate1.php with a 1px border declared on the
body. The rendering is now the same in Foxfire and IE6.

I am still struggling with understanding the whys but I'll get there.
From what I have read the border preserves the top margin. At the
moment I am assuming that, in that case, the root element is the
containing block; otherwise the containing block is the H1 element if it
has collapsed the body's top margin

Louise

Jul 21 '05 #17

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: mappo | last post by:
There are about a million posts on how to get rid of the extra space _after_ the form end-tag, but I can't find any that solve my problem: extra space _in_ the form tag. I have a table nestled...
5
by: Applebrown | last post by:
Hello, basically, I'm just learning intermediate CSS and trying to convert my old table webpage completely to CSS. Hoorah, right? Well, it's not quite going as planned. It's an extremely simple...
12
by: skeeterbug | last post by:
http://www.geocities.com/operationsengineer1/test2.htm the extra space between the logoHeader and the menu bar occurs when i add the <ul>. if i comment out the ul and and all the li, the 1em...
0
by: michael | last post by:
On my ASP.NET pages, it seems that _after_ any web or user control - an extra (small) line break or space is inserted automatically right after the Control. This is unwanted since it messes up...
3
by: michael | last post by:
On my ASP.NET pages, it seems that _after_ any web or user control - an extra (small) line break or space is inserted automatically right after the Control. This is unwanted since it messes up...
0
by: michael | last post by:
On my ASP.NET pages, it seems that _after_ any web or user control - an extra (small) line break or space is inserted automatically right after the Control. This is unwanted since it messes up...
2
by: michael | last post by:
On my ASP.NET pages, it seems that _after_ any web or user control - an extra (small) line break or space is inserted automatically right after the Control. This is unwanted since it messes up...
2
by: michael | last post by:
On my ASP.NET pages, it seems that _after_ any web or user control - an extra (small) line break or space is inserted automatically right after the Control. This is unwanted since it messes up...
8
by: Stanley | last post by:
The following HTML works as expected in IE6 and IE7, but in Firefox, there is extra space below the image. I tried setting margin and padding to 0 for different elements but still cannot get rid of...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.