[css-d] Tooltip with only XHTML

[Eduardo Varela]

Hi, all.
I need assistance again for my math oriented site.

I published a page with an icon in it named "Notas" which links to another page 
of my site.
This link has a title attribute, so the reader is shown a little rectangle with 
plain text when the mouse is over the icon.
This rectangle is visible for only some seconds.

Is there any way, using only XHTML and CSS, to display the text until the 
reader closes the rectangle?

The page:
http://www.elmatemachete.com.ar/elmate_potencias.htm

The code:
   
  
   

By the way, I want to thank again to Troy Harshman and Del Wegener for the help 
they gave me with fraction bars and exponents.
Their suggestions live in the above mentioned page.


Thanks,
Eduardo


__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] FF 2.0 rendering issues - blank content

[Eric Heitz]

Thierry,

Thanks to you and all that responded for the valuable review.
Removed the overflow and floated the #content_int. Works like a charm now!

I love this list!

-
Thanks
Eric


On Tue, Mar 9, 2010 at 12:58 PM, Thierry Koblentz <
thierry.koble...@gmail.com> wrote:

> > Site recently posted live. Passes CSS Validation and has minor HTML
> > validation issue.
> >
> > http://www.eyecarecincinnati.com
> >
> > Homepage is showing correctly but moving within the site, example Our
> > Doctors page, the header and footer shows but not the content.
> > I am unsure if this is a CSS issue or just an old browser. Really not
> > even
> > sure the right place to start.
> >
> > Any input would be great. If this goes off topic, I will throw it out
> > the
> > door.
>
>
> It is "overflow:hidden" on #content_Int that creates the issue in FF2.
>
>
> As a side note, it is a good idea to post the URL of the page that shows
> the
> problem rather than the URL of the site
> I was close to say that I didn't see any problem with the site
>
>
> --
> Regards,
> Thierry
> www.tjkdesign.com | articles and tutorials
> www.ez-css.org | ultra light CSS framework
>
>
>
>
>
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] IE8 bidi and hasLayout

[Alan Gresley]

Bruno Fassino wrote:
> On Tue, Mar 9, 2010 at 9:39 AM, Alan Gresley  wrote:
>> Bruno Fassino wrote:
>>> On Sun, Mar 7, 2010 at 5:47 PM, Alan Gresley  wrote:
 It appears that MS has hacked in bidirection (somewhat improved over
 IE7) by the use of *hasLayout*.

 
>>> Yes, I see the problem, very interesting!
>>>
>>> I just would say that "direction" sometimes makes a block  a
>>> formatting context root (this is not necessarily related to hasLayout,
>>> which seems to have no more rendering effects in IE8, even if it still
>>> exists just as a dom / javascript property).
>>
>> Hello Bruno. If this is not hasLayout then why does IE8 behave like IE7 for
>> particular bugs when hasLayout (IE7- understanding) has been triggered?
>>
>> IE8 with IE7 compatibility mode does not show the peekaboo bug or the
>> escaping float bug but it does show rendering bands.
>>
>> 
>>
> [...]
>> Since using hasLayout was IE7- way of generating a block formatting context
>> than I see no other option than to declare that this is hasLayout in IE8.
>>
>> I would say that this test cases of yours would be affected.
>>
>> 
>>
>> Here a copy of another of your test cases with dir="rtl" causing IE8 to
>> render as IE7.
>>
>> 
> 
> 
> Alan,
> 
> I agree perfectly that the effects are very similar. Not calling this
> "hasLayout" is mostly a question of name :-)
> But then I see some small differences, even if I haven't tested too
> much. One of the effects of hasLayout was to stop a background from
> extending below a border. "Direction" does not seem to cause this.

Bruno,

I think this is because the bugs related to elements without hasLayout
(with respect to IE7 and hasLayout) do not applies to IE8. The
peekaboo bug and the escaping float bug happens with elements without
hasLayout. This is outlined in the MS documentation [1] about hasLayout.

"In general, elements in Internet Explorer's Dynamic HTML engine are
not responsible for arranging themselves. A div or a p element may
have a position within the source-order and flow of the document, but
their contents are arranged by their nearest ancestor with a layout
(frequently body). These elements rely on the ancestor layout to do
all the heavy lifting of determining size and measurement information
for them."

This does not apply to IE8 so I can expect that no test cases will
show any jumping margins or real bugged out behaviors.


> Also with margins collapsing the effects are slightly different.  I
> would say the effects of "dir" are more consistent with "new block
> formatting context", while hasLayout had other mixed effects.


I agree that this is related to a "new block formatting context" and
follows what is seen in the MS documentation [1].

"Elements that do have layout may establish a new block formatting
context (9.4.1 in the CSS 2.1 spec)".

A note for other subscribers. Elements that establish a "new block
formatting context" can not cross hasLayout boundaries.


> Another reason I prefer not to "overcharge" the "hasLayout" name is
> that it is just a dom property, still present in IE8 (Microsoft never
> said the property has gone, only its effects), and it is still "false"
> and "true", more or less in the same cases as before. What is
> interesting is that  if you query the property for a box with "rtl"
> you get "true" in IE8, "false" in IE7-.


To my understanding, if a query of the property for a box with "rtl"
for IE8 is hasLayout = true, then we are seeing and element that has
layout. I not to up to speed with the DOM so forgive any ignorance.


> I've added the rtl case in this old page [1] of mine, look at the (javascript 
> generated) table,
> case 24.
> 
> Regards,
> Bruno
> 
> [1] http://brunildo.org/test/hh-rtl.html


I have now done more on the test case.




As can be seen in some test cases (1c and 2b), setting text direction
to "ltr" in the CSS turns off the bug. I presume that any test where a
"new block formating context" is established will show this bug.


1. 
2. 
3. 


-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] "Transcendant" web design and CSS3

[Alan Gresley]

Thierry Koblentz wrote:
[snip]
>> Ok, I see. He want IE6- to render a page like it antiquated or ugly. I
>> totally agree but this has to be a top down banishment of IE6-. The
>> governments and the corporations of this world have to inform the
>> masses (by whatever medium) that there are 100s of thousands of web
>> designers pleading for users to stop using IE6-. This does require
>> large scale activism.
> 
> I don't understand why people think it is just a matter of choice for the
> end user.
> I'm not for serving pixel perfect designs - or even identical look - across
> browsers, but I'm not for "punishing" IE6 users either.
> I'm sorry, but this makes no sense to me...
> 
> 
> --
> Regards,
> Thierry 
> www.tjkdesign.com | articles and tutorials
> www.ez-css.org | ultra light CSS framework


I thinking more in the lines of how Georg handles IE6.




A large segment of coded pages across the web can render the same in a 
compliant browser or IE6-. Anyway, I find (with my code) that what 
usually bugs IE6- out also has the same problems in IE7 and it really 
has more to do with poor or incorrect support for CSS2.1. A layout 
such as this is a no go in IE7-.




Progressive Enhancement or Graceful Degradation has never really taken 
off due to the presence of IE6 and IE7. I have only really archived 
Progressive Enhancement or Graceful Degradation with different 
versions of non IE browsers. I guess it will be different with IE8 and 
IE9.

For an extreme case of wanting users to use IE8 or other good browsers 
is this family tree done with ordered list and display:table.




This is to replace this method using Excel spreadsheet which does not 
work in non IE browsers (the hyperlinks don't work for starters). BTW, 
view the source.




To save me duplication, I would really appreciate users to be using 
IE8 so I can code it with a text editor and generate the layout with CSS.



-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] FF 2.0 rendering issues - blank content

[Thierry Koblentz]

> Site recently posted live. Passes CSS Validation and has minor HTML
> validation issue.
> 
> http://www.eyecarecincinnati.com
> 
> Homepage is showing correctly but moving within the site, example Our
> Doctors page, the header and footer shows but not the content.
> I am unsure if this is a CSS issue or just an old browser. Really not
> even
> sure the right place to start.
> 
> Any input would be great. If this goes off topic, I will throw it out
> the
> door.


It is "overflow:hidden" on #content_Int that creates the issue in FF2.


As a side note, it is a good idea to post the URL of the page that shows the
problem rather than the URL of the site
I was close to say that I didn't see any problem with the site


--
Regards,
Thierry 
www.tjkdesign.com | articles and tutorials
www.ez-css.org | ultra light CSS framework




__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] FF 2.0 rendering issues - blank content

[Climis, Tim]

> Thus far I have looked at Doctors page in 6 browsers on 2 different operating 
> systems.

Just pointing out that the browser in question is in the subject (i.e. Firefox 
2)  I don't happen to have a copy so I can't help, but it should save some 
other people some time.

---Tim
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] FF 2.0 rendering issues - blank content

[David Laakso]

Eric Heitz wrote:
> Site recently posted live. Passes CSS Validation and has minor HTML
> validation issue.
>
> http://www.eyecarecincinnati.com
>
> Homepage is showing correctly but moving within the site, example Our
> Doctors page, the header and footer shows but not the content.
> I am unsure if this is a CSS issue or just an old browser. Really not even
> sure the right place to start.
>
> Any input would be great. If this goes off topic, I will throw it out the
> door.
>
>
> -
> Thanks
> Eric
>   


I know it is frustrating. However, unless you specify what Operating 
System, and what browser you are using, and an address for one page that 
exhibits the issue, it is equally frustrating to help. Thus far I have 
looked at Doctors page in 6 browsers on 2 different operating systems.

The only difficulty I see  on the Doctors page is in XP IE/6.0 where the 
content does in fact appear, but the content blocks are broken.

Is this what you seek a fix for?

Best,
~d



-- 
desktop
http://chelseacreekstudio.com/
mobile
http://chelseacreekstudio.mobi/

__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] FF 2.0 rendering issues - blank content

[Troy Harshman]

I'm not seeing issues in Firefox, Chrome, or IE6. The "Home" link on
your locations page is broken though.
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] FF 2.0 rendering issues - blank content

[Chris Blake]

Hi Eric,

To stop your rollover images blinking on first rollover: place both  
images side-by-side and save it as one image. Then use the background  
position property to move the image on rollover/hover.

apart from that it all looks good to me - mac, safari.

Cheers, CB




On 10/03/2010, at 1:04 AM, Eric Heitz wrote:

> Site recently posted live. Passes CSS Validation and has minor HTML
> validation issue.
>
> http://www.eyecarecincinnati.com
>
> Homepage is showing correctly but moving within the site, example Our
> Doctors page, the header and footer shows but not the content.
> I am unsure if this is a CSS issue or just an old browser. Really  
> not even
> sure the right place to start.
>
> Any input would be great. If this goes off topic, I will throw it  
> out the
> door.
>
>
> -
> Thanks
> Eric
> __
> css-discuss [cs...@lists.css-discuss.org]
> http://www.css-discuss.org/mailman/listinfo/css-d
> List wiki/FAQ -- http://css-discuss.incutio.com/
> List policies -- http://css-discuss.org/policies.html
> Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
>

__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] FF 2.0 rendering issues - blank content

[Eric Heitz]

Site recently posted live. Passes CSS Validation and has minor HTML
validation issue.

http://www.eyecarecincinnati.com

Homepage is showing correctly but moving within the site, example Our
Doctors page, the header and footer shows but not the content.
I am unsure if this is a CSS issue or just an old browser. Really not even
sure the right place to start.

Any input would be great. If this goes off topic, I will throw it out the
door.


-
Thanks
Eric
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] IE8 bidi and hasLayout

[Bruno Fassino]

On Tue, Mar 9, 2010 at 9:39 AM, Alan Gresley  wrote:
> Bruno Fassino wrote:
>>
>> On Sun, Mar 7, 2010 at 5:47 PM, Alan Gresley  wrote:
>>>
>>> It appears that MS has hacked in bidirection (somewhat improved over
>>> IE7) by the use of *hasLayout*.
>>>
>>> 
>>
>> Yes, I see the problem, very interesting!
>>
>> I just would say that "direction" sometimes makes a block  a
>> formatting context root (this is not necessarily related to hasLayout,
>> which seems to have no more rendering effects in IE8, even if it still
>> exists just as a dom / javascript property).
>
>
> Hello Bruno. If this is not hasLayout then why does IE8 behave like IE7 for
> particular bugs when hasLayout (IE7- understanding) has been triggered?
>
> IE8 with IE7 compatibility mode does not show the peekaboo bug or the
> escaping float bug but it does show rendering bands.
>
> 
>
[...]
>
> Since using hasLayout was IE7- way of generating a block formatting context
> than I see no other option than to declare that this is hasLayout in IE8.
>
> I would say that this test cases of yours would be affected.
>
> 
>
> Here a copy of another of your test cases with dir="rtl" causing IE8 to
> render as IE7.
>
> 


Alan,

I agree perfectly that the effects are very similar. Not calling this
"hasLayout" is mostly a question of name :-)
But then I see some small differences, even if I haven't tested too
much. One of the effects of hasLayout was to stop a background from
extending below a border. "Direction" does not seem to cause this.
Also with margins collapsing the effects are slightly different.  I
would say the effects of "dir" are more consistent with "new block
formatting context", while hasLayout had other mixed effects.

Another reason I prefer not to "overcharge" the "hasLayout" name is
that it is just a dom property, still present in IE8 (Microsoft never
said the property has gone, only its effects), and it is still "false"
and "true", more or less in the same cases as before. What is
interesting is that  if you query the property for a box with "rtl"
you get "true" in IE8, "false" in IE7-.  I've added the rtl case in
this old page [1] of mine, look at the (javascript generated) table,
case 24.

Regards,
Bruno

[1] http://brunildo.org/test/hh-rtl.html

-- 
Bruno Fassino http://www.brunildo.org/test
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] "Transcendant" web design and CSS3

[Thierry Koblentz]

> >> You can still support IE6- but some authors just don't want to
> bother
> >> understanding why IE6- has shocking CSS2.1 support or why a document
> >> is rendered broken in IE6-. I agree with Andy Clarke by sending
> >> IE6/Win un-styled pages but their is also that user agent IE5/Mac.
> >
> > I'm not making myself clear.  He is not serving IE6- an *unstyled*
> page,
> > he is serving it a DIFFERENTLY styled page, and a style that is just
> as
> > complex - but different.  Different graphical accents.  Black-and-
> white
> > photographs instead of color photographs.  Differences like that.
> IMO,
> > the same kind of stupid penalization of IE that it suffered when
> > Netscape users would use the (unsupported-by-Netscape) FONT tag to
> set
> > the Symbol font (making the page unreadable in IE) when the first
> > version of IE came out.  He wants to treat IE6 like the same kind of
> > pariah that Netscape 4 has been for years, with less excuse in the
> case
> > of IE6, because IE6 DOES support most of what he wants to do.
> 
> Ok, I see. He want IE6- to render a page like it antiquated or ugly. I
> totally agree but this has to be a top down banishment of IE6-. The
> governments and the corporations of this world have to inform the
> masses (by whatever medium) that there are 100s of thousands of web
> designers pleading for users to stop using IE6-. This does require
> large scale activism.

I don't understand why people think it is just a matter of choice for the
end user.
I'm not for serving pixel perfect designs - or even identical look - across
browsers, but I'm not for "punishing" IE6 users either.
I'm sorry, but this makes no sense to me...


--
Regards,
Thierry 
www.tjkdesign.com | articles and tutorials
www.ez-css.org | ultra light CSS framework




__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] IE8 bidi and hasLayout

[Alan Gresley]

Bruno Fassino wrote:
> On Sun, Mar 7, 2010 at 5:47 PM, Alan Gresley  wrote:
>> It appears that MS has hacked in bidirection (somewhat improved over
>> IE7) by the use of *hasLayout*.
>>
>> 
> 
> Yes, I see the problem, very interesting!
> 
> I just would say that "direction" sometimes makes a block  a
> formatting context root (this is not necessarily related to hasLayout,
> which seems to have no more rendering effects in IE8, even if it still
> exists just as a dom / javascript property).
> 
> 
> Best,
> Bruno


Hello Bruno. If this is not hasLayout then why does IE8 behave like 
IE7 for particular bugs when hasLayout (IE7- understanding) has been 
triggered?

IE8 with IE7 compatibility mode does not show the peekaboo bug or the 
escaping float bug but it does show rendering bands.



The major bugs associated with triggering hasLayout or an elements 
without layout don't seem to work in IE8 with IE7 compatibility mode 
on so IE8 in best mode would be the same.

Since using hasLayout was IE7- way of generating a block formatting 
context than I see no other option than to declare that this is 
hasLayout in IE8.

I would say that this test cases of yours would be affected.




Here a copy of another of your test cases with dir="rtl" causing IE8 
to render as IE7.




-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/