Place a DIV above all site content

[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!

 

[Andy]

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.

Hi,

First of all, I'm not an expert but I believe I may have something similar
to what you're looking for.

Essentially I have content with text, buttons and input fields etc and I
wanted to be able to overlay bullet point labels identifying what each
element does.

Here's a link to the news article that introduces the (QUICKHELP OVERLAY)
effect...

www.microbuild.com/microbuild/news/website/august 2008.html

(you'll have to cut&paste link coz of the break)

I can't see why the bullet point labels couldn't be replaced with an image
or even use a background image in the overlay div.


Anyhoo, hope this helps.

Andy

 

[Neredbojias]

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.

I have to admit I don't follow your argument too well. Like one
shouldn't be able to see the image in the third floated div because it
should be behind ?what? 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).

Oh, woe is me. Reading specs is bad enough, but reading appendices to
specs...

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.

I don't doubt the validity of your conclusions here but see no reason to
aggravate myself superfluously as an option. It works, it's valid, and
that's as philosophical as I want to get. A large part of this
"attitude" comes from the w3c itself because I think the decisions it
often makes regarding "the specs" are absurd.

 

[Neredbojias]

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.

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.

And Appendix E is particularly bad.

Yes, I _could be_ missing something, I guess, so if that is your belief
would you kindly explain it to me in a simpler way which I may (or
not!) understand.

No please don't aggravate yourself

I try not to every chance I get...

 

[Neredbojias]

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!

Well...I would say that the image is in level 4: "floats and their
contents", because the image is inside the floated div. Just because
it's "display:block;" shouldn't matter, should it?, 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.

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.

Well, this (to me) merely obfuscates the issue, but the w3c is no
stranger to that.

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.

I dunno, perhaps to the nth degree of logic you're right, but I still
consider this prima facie evidence that the w3c would rather
rationalize its mistakes than fix them.

 

[dorayme]

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.

dorayme reads everything, it has come to earth to absorb material that
others find too painful. It takes that pain on so others do not have to
suffer so.

What it does with the material is try to make sense of it. So far it has
concluded that canvases are often transparent, sometimes not but when
not, one can also posit an Ultimate Opaque object.

I have given you some data (which you ignored perhaps because it looked
crazy) which suggests this ultimate object is not the viewport's back
but that of the browser itself, at least in FF3.

Basically, we can make merry with the colourless "UA-defined color".

But thanks, I will be looking, more closely at the sections you quote.

 

[dorayme]

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.

Ah... now, I think this is stretching it a bit. I know what you are
doing and it is a bit cunning and desperate at the same time. We must
have a few fixed anchors and not turn the whole area into quicksand.
Viewport is Viewport and for looking at webpages. We were not happy
about having just BODY and HTML, we needed Viewport to anchor our
understanding of things like absolute positioning and canvases and
transparency, You are turning about and degrading its lofty status by
comparing it to a mere desktop window. Have you no conscience?

The whole window in which Source appears is quite different in
appearance and function. That flash of colour I referred you to, and
made a movie of, suggests the simplest thing, the browser itself has
this Ultimate Coloured Rectangle and sports it by default whenever.

It is as if I caught a magician slip up in his trick. The browser has
this coloured rectangle in its right hand and is ever ready with it. It
had to withdraw it pretty smartly in the case of the source window and
let the source have its normal white bg. There was no evidence of the
white being overlain. It looked for all the world like the yellowy cream
(my answer to Bergamot's Sicko Green or B's Unconscionable Purple) was
hastily withdrawn. That Ultimate Opaque is there and belongs to the
browser and used in many of its tricks. It is not the poor Viewport's.

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.

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.

In 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.

That is what I always thought originally but you have pressed me into
seriously considering the essential transparency of canvases. I like
being pressed this way because it does explain quite a few things. But
there are limits.

 

[Neredbojias]

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.

Well, he-he, after all is said and said again, I still find the whole
thing confusing and _possibly_ as non-intuitive as can be, depending
upon one's interpretation. An example of clear, concise
standardization it is not. Anyway, I have nothing further to add to my
argument and do admit you present a reasonable case for your
point-of-view. I still find it aggravating, though...

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.

I would say so though it might be hard to support that notion with the
terminology of the specs.

 

[dorayme]

[...]

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.

I agree. I have been getting the feeling of greater consistency and
unity to think of all elements as having a canvas which can be given a
colour or not, if not, they are transparent by default and can be so
seen to be on scroll with overflow: auto or scroll. It is just that
there is a Final Guiding Hand that plays tricks and funny business and
makes modelling hard. Think Quantum Theory.

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.

Don't worry, in this business, you would not culpable. Where these odd
models are concerned, the difference between truth and falsity is not so
straightforward.