A
Andy Dingley
joker197cinque wrote:
Gawd! The infamous ImageReady chop-n splice "website"! Not a web page
but an image of a webpage...I can only imagine.
Amen! Testify Brother!
joker197cinque wrote:
Gawd! The infamous ImageReady chop-n splice "website"! Not a web page
but an image of a webpage...I can only imagine.
joker197cinque said:I'm a webmaster. Few days ago a very strange project arrived in my
hands.
I have a photoshop layout that I am supposed to slice and mount into
HTML+CSS. This is a very common task for me....but this time is
different.
Final goal is to have a semi-transparent grid layer that overlay ALL
website content (text, pics tables,colors) ... as concept imagine a
background image pattern that stay ABOVE website content and not
below.
Do you know a way to obtain this effect without impact on other
standard functionality of a webpage ?
I tried for example some DIV structures with
opacity: 0.n;
-moz-opacity: 0.n;
filter: alpha(opacity=n);
The problem with this approach (and all solutions lightbox like) is
that the layer is modal. No access to underline content is allowed.
Any help much much appreciated.
Best regards.
Your test case raises an interesting point. According to CSS 2.1 as
written (although it hardly mentions opacity, since that's really
only in CSS 3) you shouldn't really be able to see the image in the
third floated div at all because it should be behind the div.
Since the image has opacity on it, it starts a new stacking context,
which means that the float is no longer treated by the img as though
the float started a new stacking context (see CSS 2.1 Appendix E
section 5).
That puts the img behind the float, since there's no reason for the
img not to be in stacking level 3 (and the float is in level 4).
But I reckon most browsers are putting the img in level 6, as if it
had z-index: 0, which makes more sense.
These levels are all explained in 9.9.1.
Behind the floated div's background image. It should technically be,
from the back, semi-transparent Mickey mouse, then opaque grid lines
completely obscuring him.
And Appendix E is particularly bad.
No please don't aggravate yourself
Eh? How do you figure that? Mickey is on top/in front of the
background of its container no matter what anybody says about the
stacking order and the background of this container contains the
grid image as a background image. I really don't see how even the
w3c could **** that up.
According to the rules[1], there are two stacking contexts on that
page. The root stacking context, and a new one created by the image
because it has opacity set on it.
In the root stacking context, from back to front, go:
1. the background and borders of the element forming the stacking
context. [that's the HTML or "root" element]
2. the stacking contexts of descendants with negative stack
levels.
[None of those here]
3. a stacking level containing in-flow non-inline-level
descendants.
[The img is one of those-- it's display: block]
4. a stacking level for floats and their contents. [That's the
box
with the grid lines for its background]
5. a stacking level for in-flow inline-level descendants. [None
of
those]
6. a stacking level for positioned descendants with 'z-index:
auto',
and any descendant stacking contexts with 'z-index: 0'. [or of
these]
7. the stacking contexts of descendants with positive stack
levels.
[or these]
The image is in level 3, and the floated div is in level 4, on top of
it!
The only reason that doesn't happen for every block image inside a
float is because of what Appendix E says:
5. All non-positioned floating descendants, in tree order. For
each
one of these, treat the element as if it created a new
stacking context, but any descendants which actually create a
new stacking context should be considered part of the parent
stacking context, not this new one.
Normally the image doesn't create a new stacking context, so we treat
the float as if it did. So that puts the image at level 3 in the
float's "stacking context", which at least means it's on top of the
float.
But as soon as the image really creates a stacking context, we have
to consider it "part of the parent stacking context"-- i.e. the one
the float's in. In that stacking context, it's at level 3, behind the
float in level 4.
[1]
The "rule" that opacity creates a new stacking context is not really
a rule but a vague hint, also in 9.9.1:
"In future levels of CSS, other properties may introduce stacking
contexts, for example opacity"
But for opacity not to create a stacking context would be bizarre.
Ben C said:I hope dorayme is reading this. I kept claiming the canvas is
often transparent, but just saw this in Appendix E:
The canvas is transparent if contained within another, and given a
UA-defined color if it is not.
Ben C said:Yes, although it may be that every time FF3 opens a window it opens a
viewport. Only some of those viewports contain rendered HTML documents.
The toolbars, dialogue boxes, everything in Firefox is represented by
markup (not HTML but something called XUL) that it then renders using
itself.
But we could just as well say FF3 uses transparent viewports and puts
the UA-defined colour behind that.
That is what I always thought originally but you have pressed me intoIn many ways it's moot-- the idea is just to have a mental model that
works and is reasonably simple.
They also talk in Appendix E about painting the root element's
background on top of the canvas, so one interpretation of what they
meant is that the canvas _is_ one colour and is then _painted_ with
another colour.
In the root stacking context, from back to front, go:
1. the background and borders of the element forming the
stacking
context. [that's the HTML or "root" element]
2. the stacking contexts of descendants with negative stack
levels.
[None of those here]
3. a stacking level containing in-flow non-inline-level
descendants.
[The img is one of those-- it's display: block]
4. a stacking level for floats and their contents. [That's the
box
with the grid lines for its background]
5. a stacking level for in-flow inline-level descendants. [None
of
those]
6. a stacking level for positioned descendants with 'z-index:
auto',
and any descendant stacking contexts with 'z-index: 0'. [or
of these]
7. the stacking contexts of descendants with positive stack
levels.
[or these]
The image is in level 3, and the floated div is in level 4, on top
of it!
Well...I would say that the image is in level 4: "floats and their
contents", because the image is inside the floated div.
Now that's a good point. We could say the image is in level 4 because
it's "the contents of a float", even though it starts its own
stacking context.
But I think by "a level for floats and their contents" they mean the
same thing as what is given in more detail in Appendix E: in other
words that level 4 is for floats and those of their contents that
don't start stacking contexts.
It's not spelled out because they're only really hinting about
opacity anyway since it doesn't belong in CSS 2.1. Anything else that
starts a stacking context has a clear and unambiguous level in the
parent context because it has a z-index that isn't auto (so it's at
level 2, 6 or 7).
Just because it's "display:block;" shouldn't matter, should it?
That just puts it in level 3 rather than in level 5. You've raised
the possibility that it should be in level 4 (and you could be on to
something there).
In level 3 it's behind the float's background. In level 4 or 5, in
front of it. So level 4 would work.
, and level 3 says "...in-flow...descendants" which I interpret as
the en-divved image not being if for no other reason than the only
place it is "in-flow" is within the floated div which has no other
content.
That makes it an in-flow descendent of the root stacking context
though, which qualifies it for level 3.
I hope dorayme is reading this. I kept claiming the canvas is
often transparent, but just saw this in Appendix E:
The canvas is transparent if contained within another, and given
a UA-defined color if it is not.
Not what any browser I've tried does-- they draw the UA-defined
colour behind the canvas as you can see if you set a CSS3 rgba colour
on the root element and define a distinctive background in your UA.
It also seems to contradict 14.2:
The background of the root element becomes the background of the
canvas and covers the entire canvas
Appendix E says that unless the canvas is transparent it gets a
UA-defined colour, but 14.2 says you can set its colour in CSS (by
setting background-color on the root element). I think they really
mean "viewport background" (although they never use that term) not
"canvas" in Appendix E.
Still it does seem to imply that iframe/frame viewports should have
transparent backgrounds, not white ones like Konqueror gives them.
Ben C said:[...]
OK, I am not really disagreeing with this. I just am a bit resistant to
the idea of viewports having backs. It is a window through which you
look. The rest of the show belongs to the website and the browser.
The only reason I give them backs is because then they behave exactly
like normal overflow: scroll boxes, and everything is much simpler.
Is one colour and painted with another is OK. After all that's what
canvas in the real world behaves like.
Sorry if I misled you. The model I described is equivalent (and _I_
still think preferable) but it's less confusing if everyone tries to
stick with the W3C model.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.