Hide text with css

[Gin]

Hi have a text that is showing on a web page (see below), that I can't
modify because is automatically added by the scriptthat is generating the
page, so I can't modify the font size to fit the layout of my design.My
question is: can I hide it with some css trick ( for example overlapping a
blank image ) so that I can add the same textwith the font size I need
?<font size="-1" face="arial"><b>Test To hide</b></font>

 

[J.O. Aho]

Hi have a text that is showing on a web page (see below), that I can't
modify because is automatically added by the scriptthat is generating the
page, so I can't modify the font size to fit the layout of my design.My
question is: can I hide it with some css trick ( for example overlapping a
blank image ) so that I can add the same textwith the font size I need
?<font size="-1" face="arial"><b>Test To hide</b></font>

You could try with making the <b> to use the same color as the background.

b {
color: #ffffff
}

 

[Andy Dingley]

can I hide it with some css trick

Set the property visibility: hidden; to make it invisible.

Set the property display: none; to make it vanish and not take up any
space.

(or do both together)


To do this, you'll need to find a CSS selector that identifies that
section of the HTML page. This could be impossible, depending on the
structure of the existing page. If you can modify the page to have
some distinctive class of "hideable" or id attribute that's in a
suitable scope, then it's easier.

..hideable font b {
visibility: hidden;
display: none;
}

If there's a similar scope within this region (e.g. a <h2>) that you
don't want to be hidden, then you might be able to over-ride the CSS
applied to it with a CSS block like this

..hideable h2 font b {
visibility: inherit;
display: inherit;
}

I doubt you can add a style attribute to the HTML itself, because if
you could do this much, you probably wouldn't be having the initial
problem!

 

[Jukka K. Korpela]

Scripsit J.O. Aho:

At this point I must say that I cannot see the point. Surely if you can add
CSS, you can modify the font size (e.g., font { font-size: 100%; }).

Moreover, if the problem is in the script, the script should be fixed, or
you should use another tool to generate your pages.

I'm afraid the OP might even be trying to remove some text that he is
required to have on the pages in order to comply with some software license.

You could try with making the <b> to use the same color as the
background.
b {
color: #ffffff
}

There are too many problems with that approach. For one thing, it is
ineffective when the user has selected "always use my colors". Second, even
if the text is invisible, it affects the layout.

You can simply set
font b { display: none; }
provided that you have no other <b> element nested inside a <font> element.

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

If there's a similar scope within this region (e.g. a <h2>) that you
don't want to be hidden, then you might be able to over-ride the CSS
applied to it with a CSS block like this

.hideable h2 font b {
visibility: inherit;
display: inherit;
}

I don't see what you are trying to achieve in that piece of code, but it's
probably unachievable.

First, IE does not support the value inherit, so in most browsing
situations, the rule above has no effect.

Second, the display property, once set to none, cannot effectively be
changed to some other value for inner elements. One might say that display:
none declares that an element be treated as nonexistent from the CSS
perspective, and you cannot then turn its subelements into existence.

 

[Andy Dingley]

I don't see what you are trying to achieve in that piece of code,

The OP can't change their HTML. Typically they probably can, but only
at a blunt whole-page level, not on an element-by-element level
(BTDT).

So if they try to apply simple CSS, we can't stop it being cacaded
onto everything. This is intended as an example of how to reverse this

but it's probably unachievable.

Works fine here - see the example below or at this URL

First, IE does not support the value inherit, so in most browsing
situations, the rule above has no effect.

Ah, IE. That's a bit like a web browser, isn't it?

<!--[if IE]>
<style type="text/css" >
..hideable h2 font b {
visibility: visible;
display: inline;
}
</style>
<![endif]-->



<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://
www.w3.org/TR/html4/loose.dtd">
<html lang="en" >
<head>
<title>CSS display: inherit; example</title>
<style type="text/css" >
body { background-color: white; color: black; font-size:1em; }
b { color: red; }
h3 { margin: 2em 4em 0; }
code { font-size: 1.4em; }


..hideable font b {
visibility: hidden;
display: none;
}

/*
If there's a similar scope within this region (e.g. a h2) that you
don't want to be hidden, then you might be able to over-ride the CSS
applied to it with a CSS block like this
*/

..hideable h2 font b {
visibility: inherit;
display: inherit;
}
</style>

<!--
Here's a hack for IE's lack of support for inherit;
-->
<!--[if IE]>
<style type="text/css" >
code { font-size: 1em; }

..hideable h2 font b {
visibility: visible;
display: inline;
}

</style>
<![endif]-->

</head><body>
<h1>CSS <code>display: inherit;</code> example</h1>

<h3>Basic markup, with nothing applied:</h3>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, <font
size="+2"
face="arial" ><b>Fnord</b></font> sed do eiusmod tempor [...]</p>



<div class="hideable" >

<h3>The following <code>&lt;h2&gt;</code> should be visible, together
with its Fnord:</h3>

<h2>This heading <font size="+2" face="arial" ><b>Fnord</b></font>
should be visible</h2>

<h3>The following "Fnord" ought to hide:</h3>

<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, <font
size="+2"
face="arial" ><b>Fnord</b></font> sed do eiusmod tempor [...]</p>

</div>

</body></html>

 

[J.O. Aho]

Scripsit J.O. Aho:
Moi


You can simply set
font b { display: none; }
provided that you have no other <b> element nested inside a <font> element.

Thats neat, I was careful as I didn't know you could define things like this
with nesting. This works in all browsers, or is it limited in the same way as
input[text] { ... } which don't work in all.

 

[Jukka K. Korpela]

Scripsit J.O. Aho:

You can simply set
font b { display: none; }
provided that you have no other <b> element nested inside a <font>
element.

Thats neat, I was careful as I didn't know you could define things
like this with nesting. This works in all browsers, or is it limited
in the same way as input[text] { ... } which don't work in all.

All browsers that have any CSS support*) can deal with contextual selectors
like font b above. The attribute selectors like input[text] or, rather,
input[type] or input[type="text"], have much less support (but the situation
is improving).

*) I must admit I don't remember IE 3 too well, but I _think_ that even its
ridiculously buggy CSS support got this thing right.

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

The OP can't change their HTML.
Really?

Typically they probably can, but only
at a blunt whole-page level, not on an element-by-element level
(BTDT).

Sorry, but that sounds ridiculous. You're saying "they" can change the
entire page but not one element there. Should I offer my services to "them"?
For some indecent sum of money, I could do the impossible for them (creating
a copy, changing what needs to be changed, and uploading the modified
version "at a blunt whole-page level").

So if they try to apply simple CSS, we can't stop it being cacaded
onto everything.

CSS works with a cascade, that's certain, but we _always_ have that problem
with CSS.

This is intended as an example of how to reverse this
effect for a more specific location (a <h2> in this case).

Yet you postulate the addition of a class attribute, thereby changing their
HTML:

<div class="hideable" >

If you can actually modify the HTML, you can do things much more easily and
naturally.

 

[Andy Dingley]

Really?

To quote the OP: "I can't modify because is automatically added by the
script that is generating the page, "

Now if they can't modify _anything_, then they have a problem.

Much more likely though is that they can't modify the script-generated
portion, but they can access some overall boilerplate. Maybe enough to
put a <link> in to a styelsheet, maybe enough to wrap the relevant
section of the page with a <div class="foo" >. Either of these makes
the problem far simpler.

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

To quote the OP: "I can't modify because is automatically added by the
script that is generating the page, "

That sounds like "I don't know how to" rather than "I can", in reality.

Now if they can't modify _anything_, then they have a problem.

We don't really know what the problem is, and neither does the OP. We might
be able to find it out, if only we knew some facts that haven't been
disclosed.

Much more likely though is that they can't modify the script-generated
portion, but they can access some overall boilerplate.

So you mean they can't change markup that is thrown _inside a heading_ as in
your example but can change something that _encloses_ it. Weird things are
possible in this weird world, but your guess is just a shot in the dark.

 

[Andy Dingley]

That sounds like "I don't know how to" rather than "I can", in reality.

Isn't that one of the reasons behind CSS ?

A competent HTML + CSS author can thus re-work the presentation of a
page without needing to change a server-side scripting language they
might not be competent with. This is a good thing.

Weird things are
possible in this weird world, but your guess is just a shot in the dark.

Outside of the ivory log-cabins of Academia, this is what we often
find ourselves doing.

If one embeds a <style> element into the <body> of a HTML page it
"works" and thus allows you to control CSS selectors based on :hover
(obviously these can't be done through a style attribute). It's not
valid, and I've no idea if it works for anything other than one
version of IE I demonstrated it with. As a result though, I was able
to control link presentation for a snippet of HTML that was embedded
on one of MSN's pages from within my own RSS feed. -- And to get this
sorted within an hour. No way would MSN allow me to modify their pages
or their stylesheets nor do I think they were even capable of doing
this in under glacial time. _That_ is the sort of hack that people in
business do find necessary on a regular basis, so I can certainly
understand the OP's situation in general, if not their specific case.

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

Isn't that one of the reasons behind CSS ?
Nope.

A competent HTML + CSS author can thus re-work the presentation of a
page without needing to change a server-side scripting language they
might not be competent with. This is a good thing.

Nope. CSS wasn't meant to act as a substitute for changing content or
structural markup. If the problem is that you cannot edit an HTML document,
then CSS is not the answer. Well, not to an _author_. As a mere _user_ of
pages, you might wish to create fancy style sheets just to make sense of
some pages, or to get them printed decently.

Outside of the ivory log-cabins of Academia, this is what we often
find ourselves doing.

Yes, people do stupid things, like make wild guesses on other people's
problem when those other people don't really want to be helped (i.e., don't
want even describe their problem and context properly).

 

[Andy Dingley]

Nope.

It's not one of the design aims of CSS and it's still not one of the
W3C's four listed benefits to CSS, but it's still an "emergent
benefit" that is extremely valuable to a lot of larger-scale projects.
Compare it to JSP vs. Java Servlets, and particularly to the use of
JSP EL (Expression Language) which _was_ deliberately targetted at
this benefit from the first.

There's a need for HTML+CSS-competent coders to be able to modify the
appearance and "skinning" of a complex server-side generated site,
without needing the skills or access to modify the scripting itself.
CSS provides this. This ability has become extremely valuable
(although sadly still under-used).

CSS wasn't meant to act as a substitute for changing content or
structural markup.

There's no need to. If the HTML is validly "structural" in nature and
is presentation-free, then the presentation layer is applied almost
entirely by the CSS and any reasonable and applicable presentation can
be applied to the same HTML. After all, if the HTML is structurally
adequate and the "presentation" change is strictly just that and
purely presentational, then this is obviously possible.

If the problem is that you cannot edit an HTML document,
then CSS is not the answer. Well, not to an _author_.

Why not? Which part is stopping you? Inflexibility of the HTML (Then
stop embedding presentation into the HTML) or incapacity in the CSS
(Are you really asking for more than a presentational change?).

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

It's not one of the design aims of CSS and it's still not one of the
W3C's four listed benefits to CSS,

That should be obvious.

but it's still an "emergent
benefit" that is extremely valuable to a lot of larger-scale projects.

You babble a lot about incompetent codes abusing CSS instead of learning
programming. I'm surprised - not at the phenomenon (there's always someone
who wants to use a hammer as a toothbrush because he does not want to get a
toothbrush or to learn how to open its package) but at your appraisal of it.
My parody detector didn't alarm. Is it broken?

After all, if the HTML is structurally
adequate and the "presentation" change is strictly just that and
purely presentational, then this is obviously possible.

Now you are talking about something completely different. The topic was
hiding text with CSS. Do you suggest that hiding text is "purely
presentational"?

For example, if we have
"You are <em>not</em> an idiot."
is it OK to you that I say it with
em { display: none; }?

 

[Andy Dingley]

You babble a lot about incompetent codes abusing CSS instead of learning
programming.

So anyone who knows CSS but not Java is "incompetent" in your view?

CSS skills rate 2/3rd of the rate that Java does locally. For much of
my tedious business data reporting tasks then only HTML, CSS and JSP
EL are necessary to implement the large bulk of the customer-specific
reporting that needs to be done. Why is it an advantage to me
commercially to start requiring a more expensive skillset to
accomplish the same task?

Additionally, a competent Java coder faced with this pile of low-
skillset work is likely to become disinterested and look for another
job.

 

[Jukka K. Korpela]

Scripsit Andy Dingley:

So anyone who knows CSS but not Java is "incompetent" in your view?

What has Java got to do with this? Did you just join the crowd who confuses
Java with JavaScript and copies JavaScript code to do something that could
easily be done more robustly or should not be done at all? I'm disappointed.

Or are you trying to say emphatically though implicitly that you are trying
to present some kind of parody?

For much of my tedious business data reporting tasks

You're kidding, right? You're doing business data reporting for a living and
you publicly advocate the idea of using CSS for hiding text? Quite some data
extraction, eh?