Closed Bug 369054 Opened 18 years ago Closed 18 years ago

SVG: hover text: bounding box not letter forms

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 369766

People

(Reporter: jay, Unassigned)

References

(
URL
)

Details

Attachments

(1 obsolete file) 

When mousing over text the active area should be the bounding box of the anchor, not the letter forms.

compare with say opera, or html.
currently there is an extrememly irritating flicker as one mouses over anchored text.
Not sure what that testcase is trying to show, but pointer events for text are done per character bounding box, per specification:

  http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
tor,

please stop closing bugs I raise, make a comment first.

where do you claim in PointerEventsProperty it mentions character bounding box?

it doesn't, it refers to character cell.

if you try Opera you can zoom in plenty, and the white space is treated in such a way that character cells are joined together.

there is a white space problem at least with os x.

in any event as with html and as demonstrated by Opera it is evident the intention is that white space within a text anchor should be active.

Why should SVG text be different in this respect to html?
what's the benefit?
the downside is it's very irritating, and for those with poor fine motor skills introduces additional unnecessary problems.

if you close this bug again, before commenting, I shall immediately seek comments from Aaron and Gerv.

You haven't explained your position at all.
the specs dont mention whitespace, and it's not evident that your assumption is correct, in fact it's pretty hard to imagine why one would want to interpret them the way youve chosen too.

regards
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Attached image anchored text with two words (obsolete) (deleted) — 

    
    

    
  
The attachment demonstrates a full white space "make music"
in Opera as in HTML this whitespace is active.

mozilla nightly has inactive white spaces within words, between letters.


    
    

    
  
safari webkit also has a fully active whitespace in the attachment above.

in Amaya, select only the whitespace between "make" and "music" then double click to change location.

not to overstate the general agreement on this issue.

        Attachment #253774 -
        Attachment mime type: image/svg-xml → image/svg+xml

    
    

    
  
(In reply to comment #2)

Spaces have no interior (fill), nor do they have a perimeter (stroke). HTML does not have this concept for fill and stroke so I would not expect HTML to be comparable. 

If you want it to work the way you want then you could always stick a rect behind the text.


    
    

    
  
#6 Robert,

amaya, webkit, opera all behave with SVG in the manner I've indicated with this bug. Are you suggesting they all got it wrong?

anchors include the white space between words, and around characters.
There are good accessibility reasons why it's like this.

what do you suggest are the benefits of interpreting the specs as mozilla currently does?


    
    

    
  
(In reply to comment #7)
> #6 Robert,
> 
> amaya, webkit, opera all behave with SVG in the manner I've indicated with this
> bug. Are you suggesting they all got it wrong?
> 
> anchors include the white space between words, and around characters.
> There are good accessibility reasons why it's like this.

Perhaps you should take this up with the SVG WG and have them change the spec.

> 
> what do you suggest are the benefits of interpreting the specs as mozilla
> currently does?
> 

You seem to be suggesting that there are two ways to read the spec. Can you quote the parts that support your interpretation of pointer-events?



    
    

    
  
#8 Robert,

I'm concerned with accessibility and ensuring that web pages work in a similar predictable manner across UAs.
I'm not a spec expert at all. 

However it is clear that the three other native SVG UAs and ASV all interpet the specs in the manner suggested by this bug.

can you please point to a clear statement in the specs that supports another assertion?

http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
defines particular use cases, but doesn't immediately appear to define the default case...

    
    

    
  
(In reply to comment #9)
> #8 Robert,
> 
> I'm concerned with accessibility and ensuring that web pages work in a similar
> predictable manner across UAs.
> I'm not a spec expert at all. 

Stick a transparent rect over the text and link on that then.

> 
> However it is clear that the three other native SVG UAs and ASV all interpet
> the specs in the manner suggested by this bug.
> 
> can you please point to a clear statement in the specs that supports another
> assertion?

I did: comment 6

> 
> http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
> defines particular use cases, but doesn't immediately appear to define the
> default case...
> 

Initial:   visiblePainted



    
    

    
  
A transparent rect is one potential solution. However it is not a great solution due to additional complexity and requiring JavaScript support and it's made worse by the fact that we have lots of bugs when it comes to using JavaScript to do text measurement.

The relevant part of the spec would seem to be further down in the section http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty :-

For text elements, hit detection is performed on a character cell basis:

  * The value visiblePainted means that the text string can receive events
    anywhere within the character cell if either the 'fill' property is set
    to a value other than none or the 'stroke' property is set to a value
    other than none, with the additional requirement that the 'visibility'
    property is set to visible.

  * The values visibleFill, visibleStroke and visible are equivalent and
    indicate that the text string can receive events anywhere within the
    character cell if the 'visibility' property is set to visible. The
    values of the 'fill' and 'stroke' properties do not effect event
    processing.

  * The value painted means that the text string can receive events
    anywhere within the character cell if either the 'fill' property is
    set to a value other than none or the 'stroke' property is set to a
    value other than none. The value of the 'visibility' property does
    not effect event processing.

  * The values fill, stroke and all are equivalent and indicate that the
    text string can receive events anywhere within the character cell.
    The values of the 'fill', 'stroke' and 'visibility' properties do not
    effect event processing.

  * The value none indicates that the given text does not receive pointer
    events.


    
    

    
  
The term "character cell" would seem to me to be the rectangle that encloses a character.

    
    

    
  
#12

jwatt, this much seems evident, "anywhere within the character cell"

the "character cell" height should be the font height and character cells are contiguous.

'visiblePainted' may be the default setting provided it is understood that text strings include spaces.

presumably spaces that aren't painted....



    
    

    
  
(In reply to comment #12)
> The term "character cell" would seem to me to be the rectangle that encloses a
> character.
> 

According to cairo_text_extents, the width and height of a " " character in the attachment are both 1 and the x_advance is 4 (all other values are 0). The "m" for instance has width 11, height 9, x_advance 13.

The code in nsSVGGlyphFrame currently takes a width x height box round each character i.e. this is what we currently take to be the rectangle round each character.

I suppose it could do an x_advance x height box but this would still mean a low height for spaces.



    
    

    
  
It's essential that in general the top and bottom of all character cells in one text anchor form a continuous straight edge.

otherwise one can generate strobbing or flashing behaviours which are irritating.

    
    

    
  
(In reply to comment #14)

Or we could scan the text twice, find the largest height and use largest height x x_advance or largest height x largest width. Adding an M via DOM to an x would make the x zone bigger then though.



    
    

    
  
tor please could you either agree this bug or explain your position further?

my position hinges on general agreement amongst the other UAs, plus the phrase "anywhere within the character cell." would be redundant if it referred solely to the area of fill and/or stroke.

    
    

    
  
I've emailed www-svg since no one else has taken up Robert's suggestion to do so.

  http://lists.w3.org/Archives/Public/www-svg/2007Feb/thread.html#msg14

peepo: frequently making absolute "this is wrong" assertions in aggressive ways when what we do is often actually right (in other bugs you've filed) or a valid interpretation (as in this case) is doing you no favors. Initially you opened this bug without any spec basis for it (the one thing that's definitely important to us) and now you're asserting that your interpretation of the part of the spec tor has pointed out is essential and the only valid one. And this in spite of admitting that you know less about the specs than the devs. Your unique perspective on things is valuable, and being prompted to reevaluate our interpretation of the spec is doubtless a good thing. However, please, take it a bit easier for everyone's sake. ;-)

Robert: I'm thinking maybe the maximum font ascent/decent distance as the height and the glyph advance as the width would be a reasonable interpretation of "character cell"?

    
    

    
  
jwatt,

please re-read my comments. it's rather tor who marked this bug invalid without explaining his interpretation. I've not asserted anything, in fact in my last comment #17 I've specifically asked tor for a further explanation of his position, and laid mine out in a brief and I believe clear fashion. 

furthermore my position is rarely unique as I generally check on a significant number of UAs where possible.

It is also true that accessibility had a very low priority for SVG1.1.

I'd like an apology but guess that you're all so up yourselves that it's unlikely I'll get one.

if you or tor can come down off your high horses, I'd like some help developing a microformat for accessible SVG.

But my guess is your all too busy.

cheers

At a minimum I would like an explanation in plain english, preferably with a working attachment before my bugs are marked invalid in future.

please remember i file bugs with most of the major UA developers, and have little attachment to UAs that fail to fix them. I'm looking for consensus outside of 'standards' when necessary.

    
    

    
  
There is one other bug that I've filed, where it appears that mozilla is following the spec, and as I commented I will take this up with the WG, as I also mention Lie has already agreed with me iirc that there is an issue with the spec. in this respect.

If you would prefer I stopped filing bugs, please say so.

otherwise back off. I take plenty of time considering and formatting my attachments, titles etc. I dont like them being marked invalid on one individual's opinion, especially when he can't be bothered to add an explanation.

If i get further hassle I shall be closing all my mozilla bugs and abandoning support for mozilla, which imho would be a pity for us both.

comparing UA is a useful way of seeing how the specs behave in  the real world. You'll be aware there's a distinct lack of a popular SVG authoring tool, that's simple and easy to use.
I'm just beginning to take this up with the WG as I believe the specs are at fault, hence the requirement for a microformat.

cheers

    
    

    
  
Let me make it clear, I've not received this type of regular abuse from any other bugreport community including but not limited to:

Opera
Camino
Webkit
Apple
Amaya
iCab

the first three get similar numbers of bugs, but far less comments.

    
    

    
  
(In reply to comment #18)

> Robert: I'm thinking maybe the maximum font ascent/decent distance as the
> height and the glyph advance as the width would be a reasonable interpretation
> of "character cell"?
> 

We use cairo for drawing and it does not offer such functionality as far as I know without going though all the characters in the font and working out the maximum vertical size. That would clearly be unworkable. It's quite possible there is some other gecko subsystem I don't yet know about that would allow us to get font metrics though.

I am sorry if I muddied any waters or caused any upset with comment 6, that particular failure of spec interpretation was entirely mine. jwatt pointed out the right bit in comment 11. Even so, various members of the SVG WG do seem to agree that there is a problem with the definition of a character cell.

I am upset by your remark in comment 19. jwatt and I have tried our best to explain how gecko currently implements this functionality, how the mozilla development process works and that you can post additional evidence within bugs marked invalid.

I appreciate everyone, you included, who takes the time to file a bug report with a testcase.






    
    

    
  
Robert,

please let me assure you that I wasn't offended by your comments, and had no intention to upset you.

I prefer evidence with an explanation in plain english before bugs are marked invalid. Tor's marking of my bugs invalid without this common courtesy is forming a pattern and I find it highly offensive.

It may be that there is an implementation issue, and I'm not in a position to assist greatly, however as you will be aware, this isn't a reason for marking invalid.

A request to opera, webkit, or svgwg may produce something passable.
there's little point in reinventing this particular problem, which others seem to have resolved ~:"



    
    

    
  
peepo: the conversation we started in bug 369362 comment 7 and have continued here (and out of band) was intended to be constructive. I'm taking time to do this not because I want to abuse you, but rather because I think your input is valuable and I want to solve our deteriorating interactions. I may have become more blunt due to time pressures and lack of sleep as this has gone on, so I apologise if this has come across as abusive.

By the way, when I said "unique perspective" above I was referring to your professional expertise in the field of disability and usability. I was not making some sarcastic throwaway comment, but rather intended it as a genuine compliment and acknowledgment of your expertise.

I've reread this bug as you requested. My honest analysis is this:

comment 0: you open a bug you believe to be valid, which is good.

comment 1: tor reads your bug and sees that your justification is "compare with say opera, or html". Since we try to base our implementation on the SVG spec, arguments like "that's not what HTML does" (HTML is _completely_ different to SVG) or "that's not what other SVG browsers do" (other SVG browsers are known to violate the spec for various reasons) are not valid arguments. Essentially it comes down to spec vs. how you'd personally like things to work - usually a clear case of an invalid bug. In this case tor believed the spec said your bug was invalid so he closed it as invalid, _along_ with a comment linking to the part of the spec he believed would explain this to you.

comment 2: you reply to tor ordering him to "make a comment first" - exactly what tor believes he's just _done_ - and then go on to threaten him. If you don't have the same reading of the spec as tor or want further clarification that's absolutely fine. It's the _way_ you're going about getting it that's the problem. At this point I guess tor may have simply decided there were better uses for his scarce time. As far as the details of comment 2 go, I'm not sure how you see "character bounding box" and "character cell" as being different. Also, essentially saying that Opera and HTML show that we're "evidently" wrong is evidently wrong. Evidently we could counter with "Mozilla SVG shows that it's evidently right" (just as evidently wrong). ;-) The one very good point that you make is the problems posed for people with poor fine motor skills. Again though, the spec will trump that (i.e. the spec needs to be fixed first).

comment 11: I point out that putting the onus on authors isn't great, and quote the relevant part of the spec in situ.

comment 12: completely useless unclear comment by myself.

comment 13: I realise you see "character cell" as meaning something completely different to me and perhaps there is room for reinterpretation.

comment 15: you make an authoritative "it is essential" assertion with no spec justification. (This is what I was referring to by "assertions" in comment 18.)

comment 17: I don't understand your "would be redundant" comment. Unless you were somehow thinking of a third interpretation, where events only occur on the non-rectangular painted area of the glyph (as opposed to acceptance that the area is a rectangular cell, but split into two opinions about the _size_ of that rectangular cell.)

comment 18: I try to convey to you that the attitude in comments such as comment 15 are fanning the flames and making things worse, while also encouraging you that your input is valuable. Certainly it wasn't meant as abuse.

comment 19 and comment 20: well, I'm beginning to despair. It seems my time and best efforts are being counter productive. The terms abusive and aggressive would certainly seem to apply. Anyway, you're right, I am very busy and I've got other things I'm required to attend to. I thought it was worth spending some time trying to smooth things out here because I think your input is valuable. Hopefully you will not decide to stop giving your input to Mozilla but I really can't afford to spend any more time trying to secure that. I'm sorry my comments have only served to annoy you.

Regarding your requirement that we explain in plain English what we thing the spec says in every bug we close in future, I don't think that's fair. Personally I contribute to Mozilla to write code, not to spend time explaining the spec. to people who haven't read it. I think it should be acceptable to point to the section(s) of the spec that apply and expect bug reporters to read them (as was done here by tor). If _after_ reading it the reporter disagree, _then_ I'm happy to have a discussion to try and clarify things and possibly reopen the bug if we've made a mistake (as we sometimes will!). (That might have happened here if comment 2 had been different.) This allows us to maximize our coding time and I think it's reasonable. I see no reason for anyone to take offense or become aggressive as a result of this.

    
    

    
  
my understanding is that the current implementation for text is active over areas of fill and stroke, this would be similar to expectations for svg in general, it would be redundant to mention character cell in this case. the use of the phrase character cell in this instance clearly indicates some area outside the displayed character's fill and stroke, which is not the case with the current implementation.

hence this bug cannot be invalid, on my reading.

the issue of the technical description of the exact rectangular area is a separate and important issue, which you appear to have successfully resolved with chris's help.



    
    

    
  
I recognise that we all make mistakes, myself at least as often as others. 



    
    

    
  
The "technical description" of the rectangular area is _exactly_ what we're discussing here - or so I thought. So in actual fact you think that moz only reacts to mouse events on the actual painted pixels of a glyph? I.e. you think the unpainted area in the middle of an "O" doesn't react to mouse events? If that's what you think this bug is all about then it is definitely invalid because that's not what Mozilla does. If you look more closely you'll see that the middle of an "O" _does_ currently react to mouse events, as do all parts inside the tightest rectangular area to fit around each glyph. Hence our hit testing _is_ currently based on a rectangular cell around each glyph, just not as big a rectangle as you might like.

This sheds new light on the way you've reacted above, but I'm afraid it all seems to be down to erroneous observations on your part. Mozilla doesn't act in the way you describe in comment 25 and nobody has been arguing it should. Unfortunately that's resulted in a lot of confusion in this bug.

    
    

    
  
Just to be clear, I think that in light of the clarification on the size of a "character cell" that Chris has given on www-svg, this bug does now cover a valid issue, even if it didn't initially.

    
    

    
  
A combination of the recent alphas provoking more testing and recent core gecko changes causing regressions has caused the number of SVG bugs being reported to increase.  While we are happy to get more testing, we don't have any QA support so need to quickly triage bugs to keep the list relevant and manageable.

In this particular instance, I was quite familiar with the text portion of pointer events SVG specification from when I implemented textPath.  At that time I fixed our implementation which at the time was using the actual fill and stroke of glyphs (if you thought things were bad now...), and picked a straightforward interpretation of that section that made sense for both ordinary linear text and textPath.  The correction from glyph fill/stroke to my interpretation of "character cell" was back-ported in time for Firefox 1.5, for both performance and specification compliance reasons.

If you disagree with a developer's resolution of a bug, you're free to politely respond and give your interpretation and other evidence of interest such as the behavior of other implementations.

Based on your input, Jonathan Watt has asked the W3C SVG working group to clarify the pointer events section.  If we get a response/errata from the working group that indicates that our interpretation is incorrect, then we'll address the issue when it bubbles to the top of our priority heap.


    
  

        Attachment #253774 -
        Attachment is obsolete: true

    
  
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED

    
    

    
  
peepo: no need to close this bug - please see comment 28. reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
  
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED

    
    

    
  
jwatt you are very welcome to file your own dupe bug.

    
    

    
  
in respect for Tor's inability to apologise I've closed this bug.

if I receive any further communication I shall proceed to close further bugs.

you'll appreciate why I shall not be adding further SVG bug reports to Mozilla for the present.

specs are not fundamentals, human beings are.

It is completely clear that the mozilla interpretation is inappropriate because it leads to strobe effects that are unpleasant for the user.
If the user isn't your guide, I've no interest in your product.

    
    

    
  
I have no idea what the real resolution should be, but RESOLVED FIXED is obviously incorrect. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Argh, please don't fan the flames.

I think at this point I'm going to throw my hands in the air, wonder where _my_ apology is, bite my tongue and note that the new bug is bug 369766 for anyone who wants to find it.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → DUPLICATE

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: