473,854 Members | 1,573 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Margin-bottom of last child in overflowed block is not rendered

Hello fellow authoring.style sheets colleagues,

Can someone please explain why the bottom margin of the last inflow
block-level child in an overflowed parent should not have its margin
reachable. I read and re-read carefully the CSS 2.1 spec and I just
can not see why.

Related webpages:

http://www.gtalbot.org/BrowserBugsSe...tRendered.html

Mozilla related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=47710#c36

WebKit related bug:
https://bugs.webkit.org/show_bug.cgi?id=13632#c4

IE beta feedback related bug (you need to be registered):
https://connect.microsoft.com/IE/fee...dbackID=344808

IE 8 beta 1 entry:
http://www.gtalbot.org/BrowserBugsSe...IE8Bugs/#bug71

CSS 2.1, section 10.6 Calculating heights and margins
* 10.6.3 Block-level non-replaced elements in normal flow when
'overflow' computes to 'visible'
and that section also covers when overflow: auto

Regards, Gérard
Jun 27 '08 #1
7 3454
On 2008-06-06, GTalbot <ne*******@gtal bot.orgwrote:
Hello fellow authoring.style sheets colleagues,

Can someone please explain why the bottom margin of the last inflow
block-level child in an overflowed parent should not have its margin
reachable.
It all depends whether you consider margins to be "content" or not.
I read and re-read carefully the CSS 2.1 spec and I just
can not see why.
The spec (CSS 2.1 11.1) says that overflow: scroll means you get some
mechanism to reach the "content". It doesn't really say anywhere whether
margins count as content (although space is usually reserved for them in
containing elements' "content areas").

Personally I don't think margins should be considered to be content. If
you think they should, then you have to explain how scrolling is
supposed to work when there are negative margins.

Consider this case:

<div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>

In Firefox 2 I can scroll down and find a 20px gap at the bottom. But if
I scroll to the right there is no corresponding 20px gap there.

Why not? Well if you read the spec (10.3.3), the used value of the inner
div's right margin is -60px, even though I set it to 20px. Its used
bottom margin however is still 20px.

So there simply is no 20px gap to the right. If anything there is a gap
of -60px. Is that "negative content"? Should the browser not let you
even scroll as far as the right border because of the negative right
margin? Well that would obviously be silly.

What Firefox 2 is doing is reasonable and doesn't violate the spec, but
I can't see how it's particularly helpful.

If you want a left or right margin that you can scroll to you need to
put a shrink-to-fit wrapper around the inner div, effectively putting
its margins into the content area (and I use the word content advisedly)
of this shrink-to-fit parent.

You can do just the same for the top and bottom margins in a browser
(unlike FF2) that didn't treat margins as content, if you wanted to be
able to scroll through them, although you would need a pixel of bottom
padding to prevent collapsing.

If you have some free time, I tried to explain this in www-style:

http://lists.w3.org/Archives/Public/...8Feb/0033.html

go back in the thread a bit too, but IIRC the early part of the
discussion was about padding on the parent element, which is a
no-brainer: that is always inside the parent's border box, regardless of
whether the contents overflow or not.
Jun 27 '08 #2
On 2008-06-06, Ben C <sp******@spam. eggswrote:
[...]
Consider this case:

<div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>

In Firefox 2 I can scroll down and find a 20px gap at the bottom. But if
I scroll to the right there is no corresponding 20px gap there.

Why not? Well if you read the spec (10.3.3), the used value of the inner
div's right margin is -60px, even though I set it to 20px. Its used
bottom margin however is still 20px.
That's -40px not -60px. Negative anyway.

The idea is:

20 + 10 + 200 + 10 + x = 200
therefore x = -40
Jun 27 '08 #3
On 6 juin, 16:45, Ben C <spams...@spam. eggswrote:
On 2008-06-06, GTalbot <newsgr...@gtal bot.orgwrote:
Hello fellow authoring.style sheets colleagues,
Can someone please explain why the bottom margin of the last inflow
block-level child in an overflowed parent should not have its margin
reachable.

It all depends whether you consider margins to be "content" or not.
I read and re-read carefully the CSS 2.1 spec and I just
can not see why.

The spec (CSS 2.1 11.1) says that overflow: scroll means you get some
mechanism to reach the "content". It doesn't really say anywhere whether
margins count as content (although space is usually reserved for them in
containing elements' "content areas").

Personally I don't think margins should be considered to be content. If
you think they should, then you have to explain how scrolling is
supposed to work when there are negative margins.

Consider this case:

* * <div style="overflow : scroll; width: 200px; height: 200px;
* * * * border: 1px solid black">
* * * * <div style="width: 200px; height: 200px; margin: 20px;
* * * * * * border: 10px solid blue">
* * * * </div>
* * </div>

In Firefox 2 I can scroll down and find a 20px gap at the bottom.
In Firefox 3, you will not be able to scroll down and find that 20px
gap at the bottom. Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 do
not allow scrolling down all the way down to reach, to view that 20px
gap at bottom.
Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 all render your code
snippet in the same manner.

This new behavior in Firefox 3 is not reflected in section 10.6.3 ...
But if
I scroll to the right there is no corresponding 20px gap there.

Why not? Well if you read the spec (10.3.3), the used value of the inner
div's right margin is -60px, even though I set it to 20px. Its used
bottom margin however is still 20px.

Section 10.3.3 mentions that
"
If
[
margin-left, border-left-width, padding-left, width, padding-right,
border-right-width, margin-right, scrollbar width (if any), width of
containing block
]
all have a computed value other than 'auto', [then] the values are
said to be 'over-constrained' and one of the used values will have to
be different from its computed value.
"

and so the least damage one can do when resetting a value is to reset
the margin-right. No "real" content (css content) is lost.

But the problem is that there is no equivalent for margin-bottom as
explained in section 10.6.3. No correspondence. I do read
"(...) Similarly, if the bottom margin of the block does not collapse
with the bottom margin of its last in-flow child, then the content
ends at the bottom margin edge of the bottommost child."
section 10.6.3
http://www.w3.org/TR/CSS21/visudet.html#normal-block

Maybe I do not understand what they mean with "ends at the bottom" ...
So there simply is no 20px gap to the right. If anything there is a gap
of -60px. Is that "negative content"? Should the browser not let you
even scroll as far as the right border because of the negative right
margin? Well that would obviously be silly.
I agree it would be silly.
What Firefox 2 is doing is reasonable and doesn't violate the spec, but
I can't see how it's particularly helpful.
It may not be particularly or specifically helpful but it is what the
web author wanted, expected, coded for. He wanted and requested a 20px
margin-bottom gap at the bottom of that 10px blue border. And as far
as specification is involved, I do not see how or why that 20px bottom
margin edge of the bottommost child should not be rendered.

Regards, Gérard
Jun 27 '08 #4
On 6 juin, 16:45, Ben C <spams...@spam. eggswrote:

<div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>
If you have some free time, I tried to explain this in www-style:

http://lists.w3.org/Archives/Public/...8Feb/0033.html

go back in the thread a bit too,
It starts here:

http://lists.w3.org/Archives/Public/...8Feb/0000.html

Regards, Gérard

Jun 27 '08 #5
On 2008-06-06, GTalbot <ne*******@gtal bot.orgwrote:
On 6 juin, 16:45, Ben C <spams...@spam. eggswrote:
[...]
>Personally I don't think margins should be considered to be content. If
you think they should, then you have to explain how scrolling is
supposed to work when there are negative margins.

Consider this case:

* * <div style="overflow : scroll; width: 200px; height: 200px;
* * * * border: 1px solid black">
* * * * <div style="width: 200px; height: 200px; margin: 20px;
* * * * * * border: 10px solid blue">
* * * * </div>
* * </div>

In Firefox 2 I can scroll down and find a 20px gap at the bottom.

In Firefox 3, you will not be able to scroll down and find that 20px
gap at the bottom. Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 do
not allow scrolling down all the way down to reach, to view that 20px
gap at bottom.
Good! I think that is the simplest and most reasonable interpretation.
Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 all render your code
snippet in the same manner.

This new behavior in Firefox 3 is not reflected in section 10.6.3 ...
No. 10.6.3 is a bit of a diversion: I just wanted to point out that if
margins are considered content (and therefore scrollable-to), although
that works fairly easily for vertical margins, it usually doesn't work
for horizontal margins since if the element has overflowed it usually
has used negative horizontal margins whatever the author set.

I conclude from this that the idea that "margins count as content" is a
bit problematic and unhelpful.
>But if
I scroll to the right there is no corresponding 20px gap there.

Why not? Well if you read the spec (10.3.3), the used value of the inner
div's right margin is -60px, even though I set it to 20px. Its used
bottom margin however is still 20px.


Section 10.3.3 mentions that
"
If
[
margin-left, border-left-width, padding-left, width, padding-right,
border-right-width, margin-right, scrollbar width (if any), width of
containing block
]
all have a computed value other than 'auto', [then] the values are
said to be 'over-constrained' and one of the used values will have to
be different from its computed value.
"

and so the least damage one can do when resetting a value is to reset
the margin-right. No "real" content (css content) is lost.
Exactly (or the left margin in rtl).
But the problem is that there is no equivalent for margin-bottom as
explained in section 10.6.3. No correspondence. I do read
"(...) Similarly, if the bottom margin of the block does not collapse
with the bottom margin of its last in-flow child, then the content
ends at the bottom margin edge of the bottommost child."
section 10.6.3
http://www.w3.org/TR/CSS21/visudet.html#normal-block

Maybe I do not understand what they mean with "ends at the bottom" ...
It is ambiguous, and it does sound from that paragraph as though margins
are supposed to be content.

But they are talking about how to work out the size of the content area
of a container with auto height.

That container's "content area" does end after the child's bottom margin
(assume no collapsing for the sake of argument-- e.g. the container has
a border), if the container has auto height.

So when they say "content" here do they mean the container's contents,
or the container's content area?

Note also that this section is entitled, rather weaselishly,
"Block-level non-replaced elements in normal flow when overflow computes
to visible".
>So there simply is no 20px gap to the right. If anything there is a gap
of -60px. Is that "negative content"? Should the browser not let you
even scroll as far as the right border because of the negative right
margin? Well that would obviously be silly.

I agree it would be silly.
>What Firefox 2 is doing is reasonable and doesn't violate the spec, but
I can't see how it's particularly helpful.

It may not be particularly or specifically helpful but it is what the
web author wanted, expected, coded for. He wanted and requested a 20px
margin-bottom gap at the bottom of that 10px blue border. And as far
as specification is involved, I do not see how or why that 20px bottom
margin edge of the bottommost child should not be rendered.
I don't think the spec is clear either way. In my opinion Firefox 2 is
not wrong, and neither is Firefox 3. But I find the interpretation of
Firefox 3 more logical, simpler, and more useful. Perhaps they will
reword to spec to make this clearer, especially as everyone seems to be
leaning towards this interpretation in the latest versions of their
products.
Jun 27 '08 #6
On 7 juin, 04:30, Ben C <spams...@spam. eggswrote:
On 2008-06-06, GTalbot <newsgr...@gtal bot.orgwrote:
On 6 juin, 16:45, Ben C <spams...@spam. eggswrote:
[...]
Personally I don't think margins should be considered to be content. If
you think they should, then you have to explain how scrolling is
supposed to work when there are negative margins.
Consider this case:
* * <div style="overflow : scroll; width: 200px; height: 200px;
* * * * border: 1px solid black">
* * * * <div style="width: 200px; height: 200px; margin: 20px;
* * * * * * border: 10px solid blue">
* * * * </div>
* * </div>
In Firefox 2 I can scroll down and find a 20px gap at the bottom.
In Firefox 3, you will not be able to scroll down and find that 20px
gap at the bottom. Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 do
not allow scrolling down all the way down to reach, to view that 20px
gap at bottom.

Good! I think that is the simplest and most reasonable interpretation.
Firefox 3, Opera 9.50, Safari 3.1.1 and IE 8 b1 all render your code
snippet in the same manner.
This new behavior in Firefox 3 is not reflected in section 10.6.3 ...

No. 10.6.3 is a bit of a diversion: I just wanted to point out that if
margins are considered content (and therefore scrollable-to), although
that works fairly easily for vertical margins, it usually doesn't work
for horizontal margins since if the element has overflowed it usually
has used negative horizontal margins whatever the author set.

I conclude from this that the idea that "margins count as content" is a
bit problematic and unhelpful.
But if
I scroll to the right there is no corresponding 20px gap there.
Why not? Well if you read the spec (10.3.3), the used value of the inner
div's right margin is -60px, even though I set it to 20px. Its used
bottom margin however is still 20px.
Section 10.3.3 mentions that
"
If
[
margin-left, border-left-width, padding-left, width, padding-right,
border-right-width, margin-right, scrollbar width (if any), width of
containing block
]
all have a computed value other than 'auto', [then] the values are
said to be 'over-constrained' and one of the used values will have to
be different from its computed value.
"
and so the least damage one can do when resetting a value is to reset
the margin-right. No "real" content (css content) is lost.

Exactly (or the left margin in rtl).
But the problem is that there is no equivalent for margin-bottom as
explained in section 10.6.3. No correspondence. I do read
"(...) Similarly, if the bottom margin of the block does not collapse
with the bottom margin of its last in-flow child, then the content
ends at the bottom margin edge of the bottommost child."
section 10.6.3
http://www.w3.org/TR/CSS21/visudet.html#normal-block
Maybe I do not understand what they mean with "ends at the bottom" ...

It is ambiguous, and it does sound from that paragraph as though margins
are supposed to be content.

But they are talking about how to work out the size of the content area
of a container with auto height.

That container's "content area" does end after the child's bottom margin
(assume no collapsing for the sake of argument-- e.g. the container has
a border), if the container has auto height.

So when they say "content" here do they mean the container's contents,
or the container's content area?

Note also that this section is entitled, rather weaselishly,
"Block-level non-replaced elements in normal flow when overflow computes
to visible".
Yes, good point. They should have created a sub-section for when
overflow
does not compute to visible. This really could and should be improved.
>
So there simply is no 20px gap to the right. If anything there is a gap
of -60px. Is that "negative content"? Should the browser not let you
even scroll as far as the right border because of the negative right
margin? Well that would obviously be silly.
I agree it would be silly.
What Firefox 2 is doing is reasonable and doesn't violate the spec, but
I can't see how it's particularly helpful.
It may not be particularly or specifically helpful but it is what the
web author wanted, expected, coded for. He wanted and requested a 20px
margin-bottom gap at the bottom of that 10px blue border. And as far
as specification is involved, I do not see how or why that 20px bottom
margin edge of the bottommost child should not be rendered.

I don't think the spec is clear either way. In my opinion Firefox 2 is
not wrong, and neither is Firefox 3. But I find the interpretation of
Firefox 3 more logical, simpler, and more useful. Perhaps they will
reword to spec to make this clearer, especially as everyone seems to be
leaning towards this interpretation in the latest versions of their
products.
I wish cases like that would be utterly clear, explicit, even with a
diagram,
picture, schema, etc. so that no one loses a sec. trying to figure
things out.

I read the w3 email list (read all I could, tried to closely
understand... but couldn't very well).
Brad Kemper has a point: I agree with him when he says that it is
counter-intuitive.
The way it is implemented is/will be counter-intuitive for web authors
(I'm not saying
there isn't a *good* ... although not sure I see one good ... reason
for this sort of
behavior). From your example

<div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>

a beginner, intermediate and even an experienced web author will
assume or will
presumably reach the conclusion that the browser(s) must be wrong or
it must
be a bug... because the 20px bottom margin disappear.

Thank you for your time and assistance,

Regards, Gérard
Jun 27 '08 #7
On 2008-06-07, GTalbot <ne*******@gtal bot.orgwrote:
On 7 juin, 04:30, Ben C <spams...@spam. eggswrote:
[...]
But the problem is that there is no equivalent for margin-bottom as
explained in section 10.6.3. No correspondence. I do read
"(...) Similarly, if the bottom margin of the block does not collapse
with the bottom margin of its last in-flow child, then the content
ends at the bottom margin edge of the bottommost child."
section 10.6.3
http://www.w3.org/TR/CSS21/visudet.html#normal-block
Maybe I do not understand what they mean with "ends at the bottom" ...

It is ambiguous, and it does sound from that paragraph as though margins
are supposed to be content.

But they are talking about how to work out the size of the content area
of a container with auto height.

That container's "content area" does end after the child's bottom margin
(assume no collapsing for the sake of argument-- e.g. the container has
a border), if the container has auto height.

So when they say "content" here do they mean the container's contents,
or the container's content area?

Note also that this section is entitled, rather weaselishly,
"Block-level non-replaced elements in normal flow when overflow computes
to visible".

Yes, good point. They should have created a sub-section for when
overflow does not compute to visible. This really could and should be
improved.
What they're really driving at (I think) there is the fact that if
overflow does not compute to visible then the box starts a block
formatting context and so includes floats in its height calculation. See
10.6.6 "Complicate d cases" which links directly to 10.6.7.

[...]
>I don't think the spec is clear either way. In my opinion Firefox 2 is
not wrong, and neither is Firefox 3. But I find the interpretation of
Firefox 3 more logical, simpler, and more useful. Perhaps they will
reword to spec to make this clearer, especially as everyone seems to be
leaning towards this interpretation in the latest versions of their
products.

I wish cases like that would be utterly clear, explicit, even with a
diagram, picture, schema, etc. so that no one loses a sec. trying to
figure things out.
Yes, they should clarify it. I expect they will in a later revision.
I read the w3 email list (read all I could, tried to closely
understand... but couldn't very well). Brad Kemper has a point: I
agree with him when he says that it is counter-intuitive. The way it
is implemented is/will be counter-intuitive for web authors (I'm not
saying there isn't a *good* ... although not sure I see one good ...
reason for this sort of behavior). From your example

<div style="overflow : scroll; width: 200px; height: 200px;
border: 1px solid black">
<div style="width: 200px; height: 200px; margin: 20px;
border: 10px solid blue">
</div>
</div>

a beginner, intermediate and even an experienced web author will
assume or will presumably reach the conclusion that the browser(s)
must be wrong or it must be a bug... because the 20px bottom margin
disappear.
20px on the bottom may be intuitive on its own, but then the author may
be surprised to find no 20px on the right (because of the negative used
right margin). So all things considered I think having neither 20px gap
(like FF3) is more intuitive. The fact that the spec frequently makes
use of the idea of negative margins to position things implies that
they're better thought of as offsets than as actual objects that take up
space.
Jun 27 '08 #8

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

Similar topics

1
5301
by: Tony Benham | last post by:
I'm having problems with a css layout where a margin is being inserted with the wrong width. I believe it's my css that's at fault since it is wrong in netscape 7.1, opera,7.11 and IE6 but I cannot see what is wrong. The page with the problem is www.woodleyzebrasfc.com and the incorrect item is shown under the left hand navigation menu under links. The link to ysr has a margin applied which is causing the space between it and the next item...
4
8405
by: Harlan Messinger | last post by:
What is *supposed* to be the way to specify the horizontal offset of (a) the list item's marker and (b) the list item's content? In particular, see http://mywebpages.comcast.net/hmessinger/default.html which validates under Strict. Under IE6, Opera, and Firebird, the markers are indented as one would expect the default to be. What if I want them moved over to the left edge of the list? On the above page, there is no margin-left for...
6
16078
by: Haines Brown | last post by:
I find that when I use list-style-image with galeon or mozilla, padding is inserted between the symbol image and the following list text, while under IE 5.0 it seems to be inserted before the image instead of after it. li.up { list-style-image: url(../bin/arrow.png); height: 1.4em; margin-left: -0.4em; }
13
2003
by: Cool Guy | last post by:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>test</title> </head> <body> <div style="height: 100px; width: 100px; background-color: red;"> <div style="height: 50px; margin-top: 50px;
10
12919
by: Alan Silver | last post by:
Hello, In my (seemingly) endless quest to understand CSS, I have yet another problem. Please look at http://www.kidsinaction.org.uk/ph/x.html in Opera, where you will see it how I expected. If you look at it in IE (6 or 7), you find it also looks fine, except for the top margin missing from the links across the top of the page. That's not the main issue here, but any pointers as to why it doesn't show them would be appreciated.
3
2098
by: Luciano A. Ferrer | last post by:
this is really strange... I cant find what is wrong... so, #botonera have a left margin of 18px, but IE make it 36px! If I put a margin of 30px, IE make it 60px! I am crazy? <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">
11
4463
by: Pablito | last post by:
Hi at all into a page I wrote <style> body {margin-left:10%;margin-right:10%;text-align:justify;} </style> reading the page with FireFox the margin left is 10% but the right is 0% Why? How can I do to have a right margin like the left margin? Best regards Pab
19
6489
by: Edward | last post by:
Why is it when I have a DOCTYPE line in my HTML then "margin" and "padding" are ignored? This happens in both inline and stylesheet styles. It happens for both XHTML and HTML doctypes. It happens in IE6, IE7 and Firefox (didn't try any others). And when you save the page, the margin/paddings are actually REMOVED from the saved HTML file (!). Why is this?
2
11233
by: Steve Richter | last post by:
I want my panel to have an inner margin. Problem is label text does not appear to recognize the margin. In this example, the TextBox aligns on the margin, the label does not: <asp:Panel id="Panel1" runat="server" BackColor="gainsboro" Scrollbars=Both Style="margin:25px;" Height="200px" Width="300px">
5
3551
by: Neviton | last post by:
Hi this is the html to generate the behavior: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:// www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <body style="margin: 0px; padding: 0px;"> <div style="margin-left: 10px; float: left;"> <div id="test" style="background-color: red;"> test </div>
0
9751
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11025
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10682
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10758
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10371
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9513
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7915
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
1
4562
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
3187
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

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.