Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elements styled with display: inline-block are treated as block elements #1378

Closed
nvaccessAuto opened this issue Feb 18, 2011 · 17 comments
Closed

Comments

@nvaccessAuto
Copy link

Reported by ianr on 2011-02-18 18:12
On some sites nvda will read heading tags as though each word is on it's own line.
Pressing h to get to the heading tag will read the entire heading which is good, but when you press the down arrow key to move to the line below the heading nvda instead reads just the second word of the heading, pressing down again and again gives the third word, then the fourth and so on.

Here is a site that demonstrates the problem:
http://overactdev.com/

@nvaccessAuto
Copy link
Author

Comment 1 by briang1 on 2011-02-19 10:11
This effect is present in Firefox, all recent versions, in XP in my case and on latest snaps as well as betas.
Also IE gives a more expected effect of a line at a time of text with the heading type preceding each line of text.

@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2011-02-20 23:54
This page is using cufón to render custom fonts. The h4 is being translated into something else entirely using !JavaScript.

Technical: The specific issue is that each element it generates uses the inline-block display style. NVDA incorrectly treats this as block, but for our purposes, it should be treated as inline. (Inline-block "causes an element to generate an inline-level block container." We don't care about the container, just whether it is inline- level or not. See http://www.w3.org/TR/CSS2/visuren.html for details.)

Brian: I don't understand what you mean with regard to differences between Firefox and IE. For me, it behaves the same way in both browsers.
Changes:
Changed title from "Some h4 tags read as one word per line" to "Elements styled with display: inline-block are treated as block elements"
Milestone changed from None to 2011.2

@nvaccessAuto
Copy link
Author

Comment 3 by briang1 on 2011-02-21 09:06
Well, I just tried it again and I get more than one word per line in IE and only one in Firefox. I was using the latest snap of 2011.1 and IE8 at the time on XP.
Could there be some config that is treated differently between IE and Firefox?
after all, I do notice some links are inline on one browser but vertical on seperate lines in the other, it could just be a happy accident.
I'll play with settings later on and see what Ican find.

@nvaccessAuto
Copy link
Author

Attachment inlineBlock.html added by jteh on 2011-02-21 09:55
Description:
Test case.

@nvaccessAuto
Copy link
Author

Comment 4 by briang1 on 2011-02-21 10:15
Well now on a different machine this time with IE7, and the same result. Just using cut and paste in the two browsers shows up the difference. However although the IE looks right, the lines appear to have no cr/lf at end of cut and pasted lines so they seem to just get placed end to end, whereas the cut and pasted firefox ones have a cr/lf at the end of each word.
Its interesting to note that on that page generally in ie, blank lines appear quite often, but not in firefox. Here we go..

IE...

Bringing your software application to market takes more than just time and money. Insuring that your concept changes the world takes a deeper understanding of the vision, intent, and long term strategy of your application. Identifying potential challenges before a line of code is written ensures your project is delivered on time, stable, and on budget to ensure we exceed your expectations.
Firefox.
Bringing
your
software
application
to
market
takes
more
than
just
time
and
money.
Insuring
that
your
concept
changes
the
world
takes
a
deeper
understanding
of
the
vision,
intent,
and
long
term
strategy
of
your
application.
Identifying
potential
challenges
before
a
line
of
code
is
written
ensures
your
project
is
delivered
on
time,
stable,
and
on
budget
to
ensure
we
exceed
your
expectations.

@nvaccessAuto
Copy link
Author

Comment 5 by jteh on 2011-02-21 10:19
In IE, I see the same as in Firefox; that is, each word on a new line. Not sure why it doesn't work that way on your system. In any case, the attached test case should reproduce the problem reliably.

@nvaccessAuto
Copy link
Author

Comment 6 by briang1 on 2011-02-21 12:32
That certainly puts the words on different lines. The main differences between IE and firefox on that are that the seperator says align centre in IE, but not in FF, and on ff there is a blank line between each word but not in IE.
Weird. In the original also heading level 4 was on every line as well.
I am using XP though, maybe that is the difference?
Adding

just before the message does make it add the heading before each word, but i notice the blank lines in Firefox also get labelled. even more weird!

@nvaccessAuto
Copy link
Author

Comment 7 by jteh on 2011-02-28 05:13
Urg. Fixing the inline-block issue fixes cufón for Gecko, but not for MSHTML. The problem is that the VML shape elements near each piece of text in MSHTML are block elements, even though the parent elements are inline-block. I don't know if we can work around this.

@nvaccessAuto
Copy link
Author

Comment 8 by jteh on 2011-03-01 11:16
Inline-block fix committed for both MSHTML and Gecko in 72d537b. However, as noted in comment:7, this fixes cufón for Gecko but not for IE.

@nvaccessAuto
Copy link
Author

Comment 9 by mdcurran on 2011-04-26 01:39
NVDA main with IE9 on overactdev.com/ now shows the headings as it should (i.e. words not on a separate line each). It seems in IE9, and I guess latest QFON that canvice elements are now used rather than the VML tags or what ever. But the more important point is that these elements are now inline, not block.
So, its fixed in Gecko, its fixed in IE9, and the general inline-block problem is also fixed in <=IE8, excluding those vml block tags.
Should we close as fixed, or really try and fix the <=IE8 case? However I think it would be extremely dificult to do so, the change should probably really be in QFON... they should be inline.

@nvaccessAuto
Copy link
Author

Comment 10 by briang1 on 2011-04-26 07:15
Well, the only people who cannot resolve this will be people not running Firefox on XP. As there is no IE9 for XP, I guess the advice is going to be grin and bear it or use another browser.

@nvaccessAuto
Copy link
Author

Comment 11 by jteh (in reply to comment 9) on 2011-04-27 21:56
Replying to mdcurran:

It seems in IE9, and I guess latest QFON that canvice elements are now used rather than the VML tags or what ever.

I think canvas is used if it's supported. cufón uses canvas for Gecko as well. VML is a non-standard, IE-specific technology.

Should we close as fixed, or really try and fix the <=IE8 case? However I think it would be extremely dificult to do so,

One idea you had a while back was to not treat empty block elements as block. Is this acceptable?

the change should probably really be in QFON... they should be inline.

The tricky question is whether a block element inside inline-block really starts a new line. It might start a new line inside the inline-block element, but it might not outside. If it doesn't start a new line outside, the above fix is probably best.

That said, I don't really understand why these are block elements, and as you say, they probably should be inline.

@nvaccessAuto
Copy link
Author

Comment 12 by jteh on 2011-05-23 15:49
It looks like block inside inline-block does remain inline in terms of the outer (inline-block) container. However, fixing this for NVDA could cause a lot of problems with regard to controls ending up on the same line when they shouldn't.

Given the above, I'm closing this ticket, as the issue with inline-block nodes themselves is now fixed and cufón works in both Firefox and IE9.
Changes:
State: closed

@nvaccessAuto
Copy link
Author

Comment 13 by fatma.mehanna on 2011-06-26 11:55
i reopened the ticket as the problem still exists.
surely it has been fixed in the example given above in the description, but it still exists here:
http://www.nyu.edu/life/living-at-nyu.html
Changes:
State: reopened

@nvaccessAuto
Copy link
Author

Comment 14 by ianr on 2011-06-26 19:39
I tested with Firefox 5 and the original link in the description and the problem still persists.

Here is the link again:
 http://overactdev.com/

It is also broken on fatma.mehanna 's link in Firefox 5.

@nvaccessAuto
Copy link
Author

Comment 15 by fatma.mehanna on 2011-06-26 20:11
yes, i tested it with fire fox 4 and it is still exists.
it also still exists with internet explorer when we use the arrow keys.

@nvaccessAuto
Copy link
Author

Comment 16 by jteh on 2011-06-28 05:07
The issue with the original link is definitely fixed for me in Firefox. Note that you have to be using screen layout. If you're not using screen layout, you're choosing not to see how things are presented on screen and instead to see all elements on different lines, so you'll see it on separate lines. That is your choice, but we cannot fix this for non-screen layout.

@fatma.mehanna: The example you provided is not related to this ticket and is intentional on the part of the author. The author has actually forced line breaks between every word of that heading. I have no idea why, but that's what they've done.
Changes:
State: closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant