I am currently migrating a site to HTML 5 and taking advantage of the new input types and attributes - using JavaScript as a fallback when a type or attribute is not implemented. My issue is that when the required message is triggered in FireFox the message is being cropped due to it overlapping the boundary of the containing div as below:
Demo: http://jsfiddle.net/f8b7D/2/
Is there a way to trigger the display of the message to shift to use the space available further left where it would not be cropped? I know that the message box cannot be selected using CSS and I would prefer not to rely on a JS solution as we have a number of users who have JavaScript disabled.
Additional Info:
In Chrome the default message for a select element overlaps the message bubble, although it is fully visible.
In Opera it displays correctly.
IE doesn't support the required attribute.
Fixed in Firefox 29 - apparently due to some dead code from 2002 that was removed once someone called their attention to it.
https://bugzilla.mozilla.org/show_bug.cgi?id=647813
I'm afraid that there is no way (and perhaps never will be a way) to style the message bubble for HTML5. I'm afraid that Javascript is your best bet. Here's some context.
HTML5 Required input styling
After some further playing around I found that the width of the message box is the same as the width of the select element. By setting the min-width of the select to the width of the message box (230px) the cropping can be prevented.
select{min-width: 230px;}
This solution is definitely a hack and should only be used if your site style will not be ruined by wide select elements. If you only have options with short text values e.g. Yes, No, Maybe then the required width of the select may look peculiar so only use this solution with care.
Unfortunately this does nothing about the appearance in Chrome.
I found a solution of sorts to this clipping of html5 form error messages. Its caused by a width being used in our css for a select element. If you increase the width the popup error message also increases in width. This also only seems to affect Firefox.
So I wrapped the 'select' in a span and gave that a position relative. I then gave the select a wider width (to accommodate the error message), but then also gave it a negative left margin. You'll need to play with your own px widths for your situation, but this solved the issue. I avoided having a default value for the first 'option' but I'm guessing you can use text-align right on the 'option' elements.
This solution then creates another issue! The red outline which Firefox uses for its invalid states will outline the entire 'hidden' area of the select which looks odd and different to other elements, so the answer was to simply turn off the borders, but I used css for the valid and invalid states to simply add a background icon (check/cross) to indicate when form fields were valid/invalid. I also used x:-moz-any-link in my css to filter these styles only for firefox and no other browsers. Heres my css...
/* start styles for Firefox clipping of validation msgs */
form fieldset > span, x:-moz-any-link {position: relative; }
form select, x:-moz-any-link {width: 230px; margin-left: -82px; }
form select option, x:-moz-any-link {width: 220px; margin-right: -20px; text-align: center; }
form input, form select, x:-moz-any-link {border: solid 1px transparent; box-shadow: none; }
form input:-moz-placeholder, form select:-moz-placeholder, x:-moz-any-link {box-shadow: none !important; }
form input:invalid, form select:invalid, x:-moz-any-link {box-shadow:0 0 3px transparent; }
/* end styles for Firefox clipping of validation msgs */
input:valid {background: #fff url("forms-check.png") no-repeat 130px center; }
input:focus:invalid {background: #fff url("forms-cancel.png") no-repeat 130px center; }
Its all a lot easier than I've made it sound?!
Hope its useful.
Related
I have an HTML element textarea with defined CSS rule { resize: both }. In FF when the user mouse over the right bottom corner of textarea the cursor changed according to value of property resize, but in Chrome cursor doesn't change.
Please open this example in FF and Chrome to check the difference.
Is it a bug of Google Chrome and can I fix it with CSS on my side?
Update
I reported bug to Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=942017
Update 2
The bug was fixed in Chrome 80.
Actually, there are, or at least were ways in which you could style the resizer and add cursor: se-resize; on hover. Check out this post: Can I style the resize grabber of textarea?
It describes how you can use ::-webkit-resizer to style the resizer:
::-webkit-resizer {
border: 2px solid black;
background: red;
box-shadow: 0 0 5px 5px blue;
outline: 2px solid yellow;
}
Unfortunately it stopped working in Chrome and I couldn't anything similar. (I think it still works in Safari).
But fear not, it's not hard to make a custom handle. Actually, I would encourage you to use a custom one as the default one is too small and hard to hit. Especially with touch. There are actually a lot of sites that use custom handles (or at least automatic resizers based which grows based on the content. Works great on touch too!).
Ie. Stackoverflow uses a custom handle (TextAreaResizer):
GIF of Stackoverflows resize handle
There are also lots of libraries for exactly that purpose, just do a Google search, and you'll find something that works for you :)
This is rendered by browser itself cant be designed using css
Problem
I have a <select> where one of its <option>’s text values is very long. I want the <select> to resize so it is never wider than its parent, even if it has to cut off its displayed text. max-width: 100% should do that.
Before resize:
What I want after resize:
But if you load this jsFiddle example and resize the Result panel’s width to be smaller than that of the <select>, you can see that the select inside the <fieldset> fails to scale its width down.
What I’m actually seeing after resize:
However, the equivalent page with a <div> instead of a <fieldset> does scale properly. You can see that and test your changes more easily if you have a <fieldset> and a <div> next to each other on one page. And if you delete the surrounding <fieldset> tags, the resizing works. The <fieldset> tag is somehow causing horizontal resizing to break.
The <fieldset> acts is as if there is a CSS rule fieldset { min-width: min-content; }. (min-content means, roughly, the smallest width that doesn’t cause a child to overflow.) If I replace the <fieldset> with a <div> with min-width: min-content, it looks exactly the same. Yet there is no rule with min-content in my styles, in the browser default stylesheet, or visible in Firebug’s CSS Inspector. I tried to override every style visible on the <fieldset> in Firebug’s CSS Inspector and in Firefox’s default stylesheet forms.css, but that didn’t help. Specifically overriding min-width and width didn’t do anything either.
Code
HTML of the fieldset:
<fieldset>
<div class="wrapper">
<select id="section" name="section">
<option value="-1"></option>
<option value="1501" selected="selected">Sphinx of black quartz, judge my vow. The quick brown fox jumps over the lazy dog.</option>
<option value="1480">Subcontractor</option>
<option value="3181">Valley</option>
<option value="3180">Ventura</option>
<option value="3220">Very Newest Section</option>
<option value="1481">Visitor</option>
<option value="3200">N/A</option>
</select>
</div>
</fieldset>
My CSS that should be working but isn’t:
fieldset {
/* hide fieldset-specific visual features: */
margin: 0;
padding: 0;
border: none;
}
select {
max-width: 100%;
}
Resetting the width properties to the defaults does nothing:
fieldset {
width: auto;
min-width: 0;
max-width: none;
}
Further CSS in which I try and fail to fix the problem:
/* try lots of things to fix the width, with no success: */
fieldset {
display: block;
min-width: 0;
max-width: 100%;
width: 100%;
text-overflow: clip;
}
div.wrapper {
width: 100%;
}
select {
overflow: hidden;
}
More details
The problem also occurs in this more comprehensive, more complicated jsFiddle example, which is more similar to the web page I’m actually trying to fix. You can see from that that the <select> is not the problem – an inline-block div also fails to resize. Though this example is more complicated, I assume that the fix for the simple case above will also fix this more complicated case.
[Edit: see browser support details below.]
One curious thing about this problem is that if you set div.wrapper { width: 50%; }, the <fieldset> stops resizing itself at the point then the full-size <select> would have hit the edge of the viewport. The resizing happens as if the <select> has width: 100%, even though the <select> looks like it has width: 50%.
If you give the <select> itself width: 50%, that behavior does not occur; the width is simply correctly set.
I don’t understand the reason for that difference. But it may not be relevant.
I also found the very similar question HTML fieldset allows children to expand indefinitely. The asker couldn’t find a solution and guesses that there is no solution apart from removing the <fieldset>. But I’m wondering, if it really is impossible to make the <fieldset> display right, why is that? What in <fieldset>’s spec or default CSS (as of this question) causes this behavior? This special behavior is probably be documented somewhere, since multiple browsers work like this.
Background goal and requirements
The reason I’m trying to do this is as part of writing mobile styles for an existing page with a big form. The form has multiple sections, and one part of it is wrapped in a <fieldset>. On a smartphone (or if you make your browser window small), the part of the page with the <fieldset> is much wider than the rest of the form. Most of the form constrains its width just fine, but the section with the <fieldset> does not, forcing the user to zoom out or scroll right to see all of that section.
I’m wary of simply removing the <fieldset>, as it is generated on many pages in a big app, and I’m not sure what selectors in CSS or JavaScript might depend on it.
I can use JavaScript if I need to, and a JavaScript solution is better than nothing. But if JavaScript is the only way to do this, I’d be curious to hear an explanation for why this is not possible using only CSS and HTML.
Edit: browser support
On the site, I need to support Internet Explorer 8 and later (we just dropped support for IE7), the latest Firefox, and the latest Chrome. This particular page should also work on iOS and Android smartphones. Slightly degraded but still usable behavior is acceptable for Internet Explorer 8.
I retested my broken fieldset example on different browsers. It actually already works in these browsers:
Internet Explorer 8, 9, and 10
Chrome
Chrome for Android
It breaks in these browsers:
Firefox
Firefox for Android
Internet Explorer 7
Thus, the only browser I care about that the current code breaks in is Firefox (on both desktop and mobile). If the code were fixed so it worked in Firefox without breaking it in any other browsers, that would solve my problem.
The site HTML template uses Internet Explorer conditional comments to add classes such .ie8 and .oldie to the <html> element. You can use those classes in your CSS if you need to work around styling differences in IE. The classes added are the same as in this old version of HTML5 Boilerplate.
Update (25 Sept 2017)
The Firefox bug described below is fixed as of Firefox 53 and the link to this answer has finally been removed from Bootstrap's documentation.
Also, my sincere apologies to the Mozilla contributors who had to block removing support for -moz-document partly due to this answer.
The fix
In WebKit and Firefox 53+, you just set min-width: 0; on the fieldset to override the default value of min-content.¹
Still, Firefox is a bit… odd when it comes to fieldsets. To make this work in earlier versions, you must change the display property of the fieldset to one of the following values:
table-cell (recommended)
table-column
table-column-group
table-footer-group
table-header-group
table-row
table-row-group
Of these, I recommend table-cell. Both table-row and table-row-group prevent you from changing width, while table-column and table-column-group prevent you from changing height.
This will (somewhat reasonably) break rendering in IE. Since only Gecko needs this, you can justifiably use #-moz-document—one of Mozilla's proprietary CSS extensions—to hide it from other browsers:
#-moz-document url-prefix() {
fieldset {
display: table-cell;
}
}
(Here's a jsFiddle demo.)
That fixes things, but if you're anything like me your reaction was something like…
What.
There is a reason, but it's not pretty.
The default presentation of the fieldset element is absurd and essentially impossible to specify in CSS. Think about it: the fieldset's border disappears where it's overlapped by a legend element, but the background remains visible! There's no way to reproduce this with any other combination of elements.
To top it off, implementations are full of concessions to legacy behaviour. One such is that the minimum width of a fieldset is never less than the intrinsic width of its content. WebKit gives you a way to override this behaviour by specifying it in the default stylesheet, but Gecko² goes a step further and enforces it in the rendering engine.
However, internal table elements constitute a special frame type in Gecko. Dimensional constraints for elements with these display values set are calculated in a separate code path, entirely circumventing the enforced minimum width imposed on fieldsets.
Again—the bug for this has been fixed as of Firefox 53, so you do not need this hack if you are only targeting newer versions.
Is using #-moz-document safe?
For this one issue, yes. #-moz-document works as intended in all versions of Firefox up until 53, where this bug is fixed.
This is no accident. Due in part to this answer, the bug to limit #-moz-document to user/UA stylesheets was made dependent on the underlying fieldset bug being fixed first.
Beyond this, do not use #-moz-document to target Firefox in your CSS, other resources notwithstanding.³
¹ Value may be prefixed. According to one reader, this has no effect in Android 4.1.2 Stock Browser and possibly other old versions; I have not had time to verify this.
² All links to the Gecko source in this answer refer to the 5065fdc12408 changeset, committed 29ᵗʰ July 2013; you may wish to compare notes with the most recent revision from Mozilla Central.
³ See e.g. SO #953491: Targeting only Firefox with CSS and CSS Tricks: CSS hacks targeting Firefox for widely referenced articles on high-profile sites.
Safari on iOS issue with selected answer
I found the answer from Jordan Gray to be particularly helpful.
However it didn't seem to solve this issue on Safari iOS for me.
The issue for me is simply that the fieldset cannot have an auto width if the element within has a max-width as a % width.
Fix for issue
Simply setting the fieldset to have a 100% width of it's container seems to get around this issue.
Example
fieldset {
min-width: 0;
width: 100%;
}
Please refer to the below for working examples - if you remove the % width off the fieldset or replace it with auto, it will not continue to function.
JSFiddle | Codepen
I’ve struggled for many hours with this, and basically, the browser is applying computed styling that you need to override in your CSS. I forget the exact property that is being set on fieldset elements versus divs (perhaps min-width?).
My best advice would be to change your element to a div, copy the computed styles from your inspector, then change your element back to fieldset and compare the computed styles to find the culprit.
Hope that helps.
Update: Adding display: table-cell helps in non-Chrome browsers.
.fake-select { white-space:nowrap; } caused the fieldset to interpret the .fake-select element by its original width, rather than its forced width (even when the overflow is hidden).
Remove that rule, and change .fake-select's max-width:100% to just width:100% and everything fits. The caveat is that you see all of the content of the fake-select, but I don't think this is all that bad, and it fits horizontally now.
Update: with the current rules in the following fiddle (which contains only real selects), the fieldset's children are constrained to correct widths. Other than removing rules for .fake-select and fixing comments (from // comment to /* comment */, I've noted changes in the fiddle's CSS.
I understand your problem better now, and the fiddle reflects some progress. I set default rules for all <select>s, and reserve .xxlarge for those which you know will be wider than 480px (and this only works because you know the width of #viewport, and can manually add the class to those too wide. Just requires a little bit of testing)
Proof
The problem only happens on input[type="text"] in Webkit. No matter what I do, there is the equivalent of an extra padding: 1px 0 0 1px (top and left only) on the element.
A similar problem happens in Gecko, input[type="text"] has an equivalent extra padding: 1px 0 0 1px and input[type="button"] has an extra padding: 1px 0 0 0.
Here's a JSFiddle showing you everything I've tried, and nothing works: http://jsfiddle.net/PncMR/10/
Interestingly, when you set the line-height of all the elements to 0 ( http://jsfiddle.net/PncMR/11/ ), the only unaffected elements are the ones with the problems, so I'm assuming that the browser is defaulting to a specific line-height, and I'm now looking for a way to override it.
I've found nothing in the webkit base styles that would do this, but feel free to check yourself:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css
This is not a moz-focus-inner problem, or an appearance: none problem, or a box-sizing problem, or an outline problem and I can't find any other solutions.
Edit: See my answer below for the vertical padding problems, but I'm still looking for a solution to the extra padding-left: 1px equivalent on text-inputs only in webkit and gecko. ( http://jsfiddle.net/PncMR/14/ )
In Webkit
The extra vertical "padding" on input[type="text"] in Webkit is because you cannot give text inputs a line-height value of less than normal, which isn't a specific value, but varies depending on the typeface.
I know this is the cause, but I cannot find where the input would be getting this style, because it doesn't appear in the Webkit UA stylesheets.
In Gecko
The extra vertical "padding" on input[type="text"] and input[type="button"] in Gecko is due to user-agent stylesheet containing:
input {
line-height: normal !important;
}
and !important declarations in the user-agent stylesheet cannot be overidden in any way.
Conclusion
You can't go under line-height: normal in Webkit, and you can't have anything other than line-height: normal on these elements in Gecko, so the best solution is to always style these elements with line-height: normal to get the best consistency, which isn't really a nice solution. Ideally, we'd be able to override all UA styles.
Neither of these account for the extra 1px of what acts like text-indent that only appears on input[type="text"] in both rendering engines.
People who care about this, should voice their opinions on these two Bugzilla threads:
https://bugzilla.mozilla.org/show_bug.cgi?id=697451
https://bugzilla.mozilla.org/show_bug.cgi?id=349259
The reason this is happening is because the browser is treating the content of the <input> as if it were an inline element, regardless of the display setting of the <input>. Inline elements have a minimum height as demonstrated here: http://jsfiddle.net/ThinkingStiff/zhReb/
You can override this behavior by making the "child" element inline-block. You can do this with the first-line pseudo-element.
input:first-line {
display: inline-block;
}
I go into more detail as to why this is in my answer to another question: https://stackoverflow.com/a/8964378/918414
This doesn't work in Firefox, but for another reason: Firefox's UA stylesheet (as outlined in #Ian's answer).
Normally I'm able to fix my HTML errors by myself since it's not that complicated, but this time, I'm having a hard one.
I decided to change my navigation on my website and most of it works well & most browsers displays it correctly.
Where my problem is tho, is that I have a 5-6px margin I cannot find where is coming from. The link & image showing my problem will be below.
My second problem is that IE7 shows a huge margin, and again, I cant spot where it's coming from.
The webpage URL is: Deaglegame.net & below here is the image:
I'm leaving for work in a couple hours, so if I dont reply it's not because I dont wanna reply, I'll check this thread as soon as possible, but any help is greatly appreciated!
Thanks to anyone willing to help!
The IE7 Issue is due to compatibility view. This will be forced on you by default if you are visiting the page through an intranet address. You can get around this issue by dropping the bottom padding and setting the height to 175px: for the main div. This also seems to fix the margin issue when running compatibility view.
You menu item list is somehow causing the margin issue outside of compatibility view, I would suggest when running IE to hit F12 and that should open Developer tools, that is how I found these settings that needed to be adjusted.
#Mmerrell's fix for div#main should sort one half of the issue. Next comes #Bumble Bee's observation for your ul#navigation li a span styles. The padding of the SPAN elements is causing your links to push the content.
/* deaglegame.css (line 48) */
#navigate li:hover a span,
#navigate li.hover a span,
#navigate li.active a span {
/* removed padding: 12px 0 0; */
}
/* deaglegame.css (line 30) */
#navigate li a span {
cursor: pointer;
float: left;
height: 38px;
line-height: 2.5;
/* removed padding: 12px 0 0; */
position: relative;
}
Drop the padding on them and set the line-height property. In general, it's better to use line-height for the vertical positioning of text (it applies to content of both block and inline elements) in place of padding.
You may want to consider using YUI CSS reset in the future (or perhaps even integrating it now), http://developer.yahoo.com/yui/3/cssreset/ . I've found it helps me considerably when designing cross-browser compatible sites, and has almost eliminated weird margin or padding errors I come across.
Check the image below, which might solve your first problem. Try to specify a lesser value for the padding there. Consider using a tool like firebug to resolve this kind of issues.
How can I hide the div without using display:none or JavaScript?
In my country, a lot of Blackberrys come with the CSS support disabled (the mobile companies here are not so good to developers). I have text that says
<div class="BBwarn">
please activate your css support and a link
</div>
I want to hide that once the user activates CSS support, but i can't use display:none; because it is only supported in BB firmware 4.6. It is a public site and I can't make all my visitors upgrade.
Does anybody knows a solution to this? I hope the question is easier to understand now.
Update:
Thank you all for the answers but I can't use
position:absolute
overflow
because they are available from Blackberry firmware 4.6 and up
things to try:
use the z-index to put it behind some other element
move it off the screen by absolute positioning
visbility: hidden
make the content "invisible" by setting background to foreground color (works only for text)
opacity: 0
but the real question is: why?
This is a common way:
margin-left: -9999;
How about:
visibility: hidden;
That should hide the DIV, (note how it will still be rendered but be invisible, that means it will take space in the document as if it was visible, but be invisible (unlike display:none; where the div will not be rendered)).
<div style="height:0;width:0;overflow:hidden;">
<!-- content here -->
</div>
Incidentally, this is what I do to preload images, which is nice because it doesn't use javascript.
Visibility:hidden won't do the same thing because some browsers are smart and won't make the request unless it thinks its actually visible.
Why not try the simple:
position: absolute;
left: -1000px;
I can't see why it wouldn't work.
I'm not sure of the percentages you're talking about that are using < 4.6, but if it's that important to you, then I can see a rationale for accepting that you can't please all the people all the time, and an acceptable cascading solution to this should be achievable. Probably with a link to explain the benefits of upgrading and enabling css.
height: 0;
overflow: hidden;
visibility: hidden;
color: #fff;
background: #fff;
BTW - you'd better make sure that you're css is good if you're telling someone to turn it on... :-)
What makes you think display: none is not supported before version 4.6? Did you test that, or are you going by their documentation?
I'm not a mobile developer either, so I'm just going by what I gleaned from the documentation.
The BlackBerry Browser 4.6 CSS Reference indeed mentions "Availability: BlackBerry® Device Software version 4.6 or later" for the display property, but their BlackBerry Browser 4.3 Content Developer Guide indicates that 4.3 already supported a very limited version of the display property, including display: none. Versions before 4.3 don't support the display property (again, going by the BlackBerry Browser developer documentation).
Can you assume your users do at least have firmware version 4.3, or is that just as unacceptable as assuming they have 4.6?
Have you tried simply setting the width and height to zero? I'm not familiar with the BlackBerry (Browser), but I'm sceptically assuming its CSS support is less than perfect, certainly on the older versions. I wouldn't be surprised if this worked:
.BBwarn {
display: none; /* for 4.6 and up */
width: 0px; /* for 4.3 */
height: 0px;
}
But then width and height are only supported on all elements starting from version 4.3. Before that they could only be applied to <button> and <img> tags and some <input> types (according to the documentation).
So perhaps the safest way to really make it work on all BlackBerry firmware versions is to use an image for the warning, and use CSS to set its width and height to zero.
If an image is not an option (due to lozalization issues or so, perhaps), an ugly hack might be to specify an empty/illegal image source and put the warning text in the alt attribute. I don't know if setting its width and height to zero would still hide that alt text then.
visibility: hidden; will work, but the space taken up by that particular div will still appear. If you are going to use the negative left-margin method, remember that you will need to set the object's position to absolute.
How about this:
clip: rect(0,0,0,0);
Note: Please note the clip property does not work if "overflow:visible" is used.
In your case:
<div class="BBwarn">
please activate your css support and a link
</div>
just add this css:
.BBwarn{
position: absolute;
clip: rect(0,0,0,0);
}
You could position it absolutely off the screen.
But I, also, am not a mobile developer.
I assume You don't want to use JavaScript because the Blackberrys don't support it.
What about if you did the opposite and displayed the block of code with JavaScript, rather than tried to hide it?
<script type="text/javascript"><!--
document.open();
document.writeln('<div class="BBwarn">');
document.writeln('please activate your css support and a link');
document.writeln('</div>');
document.close();
//--></script>
This is a bit of a hack, but would not display the text with disabled JavaScript...
You can do something like wise:
.class{
opacity:0; overflow:hidden; visibility: hidden; height:0;
}
for being more precise you can add :
color:transparent; background-color:transparent;
What exactly is wrong with (the earlier mentioned)
width: 0
height:0
visibility: hidden
width: 0 height:0 visibility: hidden
...Does not always work with firmware 2.2 and older. Sometimes you can get an element to be hidden, but it will reappear with certain keystrokes (like underscore, for instance).
Or you could use Please enable Javascript
And use an image that reads "Enable CSS" and style it using "display:none".
So that whenever the corresponding feature is enabled these warnings wont show.
Alternately, I presume you are using some server side code? You could try detecting for the most common known platforms that support specific versions of css/javascript and deliver content accordingly. You might not even have to write it all yourself.
I had a similar problem when I was trying to customize a select box using javascript in BlackBerry Curve 8530 (OS 5.0). But, the menu created couldn't be hidden because the css following properties still don't work:
display
overflow
position: absolute
visibility
z-index
And destroying and recreating the HTML elements didn't work either, so I got here and could solve my problem.
I know my answer isn't exactly about the question raised here, but once I got here when had problems, I think I'm not the only one with it happened and is going to.
Anyway, even if those css properties worked, what I needed was some code that could work on the most of the BB models.
My solution was made using all the answers found here. It was simple. I made two classes:
.element
{
width: 100px;
height: 100px;
font-size: 12px;
color: black;
background-color: transparent;
border: 1px solid black;
}
.element_hidden
{
width: 0px;
height: 0px;
font-size: 0px;
color: white;
background-color: white;
border: none;
}
Yes. I've made two of them for each kind of element I had in my page.
Initially, all classes are set to class="element_hidden", so when the mouse is over the select box menu, all the classes are changed to class="element" and they are shown and hidden as if they were made invisible/visible.
I hope this can be useful to someone! ;D
We can use the transform property to scale the element along the x and y axis.
. BBwarn{
transform : scale(0,0);
}
I used font size to obtain this without using display none
font-size: 0px;
As you said in question that you need solution for Blackberry version below 4.6 and there are very few CSS properties supported for Blackberry version below 4.6 so we can use some sort of hack for this purpose. Try and set the text color to whatever the background is or set font-size to 0. It's a hack, but it makes it invisible. Run the following snippet and let me know if its works for you.
.alert1 {
color: #fff; //3.8 or later
}
.alert2 {
font-size: 0; //3.8 or later
}
<b>Alert1</b>
<div class="alert1">
please activate your css support and a link
</div>
<b>Alert2</b>
<div class="alert2">
please activate your css support and a link
</div>