Subject: Re: Hyperlinks in Status Bar? - msg#00020

List: web.svg

Date: Prev Next Index Thread: Prev Next Index

Hi-

I agree with Jim, this is a UA issue; I'd like to see this feature myself,
since it conforms to behavior that people have come to expect. That being
said, there are ways to do it in ASV3 right now, using scripting.

1) Simply write to window.status on mousemove (mouseover doesn't persist
long enough, so you have to use mousemove, which continually refreshes the
message). I have an example here:
http://www.schepers.cc/testbed/statusBarLink.svg
(this sample also changes the title bar, though oddly, not locally, only
when run from a server...)

2) Make your own status bar analog, which will show document state
information (say, on a bar running along the bottom of the image); some SVG
maps I've seen use this.

3) Reveal the information in a tooltip or context menu on mouseover or other
action; of course, you'd have to use script to do this, but there are many
tooltip/context-menu implementations out there (I have some myself). One
advantage to this approach that was pointed out at SVG Open was in reference
to an SVG CAD program, which presented multiple link URI options to the user
on rightclick --all the links relevant to the given object are shown on a
list, and the user selects whichever they like. This is particularly
relevant for complex XLink link types. Again, this might be a nice feature
to see in a UA, where the context menu does this automatically (maybe even
giving the option to open in the same or a new window)

Regards-
-Doug

"Jim Ley" wrote:
>
> "Damien Bezborodow" wrote in message
> > Hello,
> > Are Hyperlinks displayed in the status bar with SVG?
> > For example, in (X)HTML if you hover over a link, the
> > hyperlink (be it a mailto:, javascript: or URI) is
> >subsequently displayed in the status bar so that
> >you can see where you are going. SWF doesn't do
> >this, and I find it a major annoyance and I hope that
> >the case is different for SVG. If possible, I think it
> >would be wise to make only URIs appear in the
> >status bar and have javascript orientated hyperlinks
> > hidden.
>
> That's purely a user agent issue, and I agree it would be a useful
feature,
> I think you should address your requests to Corel/Adobe etc. who are
> currently creating viewers. The spec is right not to define a behaviour
on
> this.
>
> Jim.

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Re: New SVG 1.1/Mobile test suite released

On Wed 13 Aug 2003, Niklas Gustavsson wrote: > > Excellent news! > > Is there a change log for the test suite anywhere? It would be great if > one would be provided. No change log, sorry. To be honest, I couldn't even hint at the changes. Nothing major, just fixes to broken or mislabeled tests. Dean > Dean Jackson wrote: > >The SVG Working Group today released a new version of > >the SVG test suite, covering more of SVG 1.1 and mobile. > > > >Details at: > > > >http://www.w3.org/Graphics/SVG/Test/ > > > >Enjoy, if you're in to this kind of thing :) > > > >This should help out implementations, but others may be > >interested in the current implementation results: > > > >http://www.w3.org/Graphics/SVG/Test/20030813/status/matrix.html > > > >There have been discussions about allowing public submission > >of new tests. Any feedback is appreciated. > > > >Special thanks to the SVG working group members who > >put a lot of effort into getting this out. I did nothing, > >but can appreciate the hard work of others. > > > >Dean > > > > >

Next Message by Date: click to view message preview

USE element, script and external references.

Hi, If I reference an element in an external document with: <use xlink:href="otherDoc.svg#Moomin"/> Are scripts in the otherDoc.svg executed? SVG 1.1 appears silent on this, I can't think which behaviour is appropriate - I'd assume not, however this would lead to strange inconsistencies if the doc happened to be referenced in an image element as here the scripts would've been executed (although there's already the inconsistency discussed recently over 2 instances of the image element with differing DOMs so a 3rd inconsistency may not be unresolvable.) ASV6pr does execute global script, and also incorrectly fires the onload event not on the SVGInstanceElement (but others appear to be fired correctly on a brief look), but in a seperate document, and javascript context. Neither CSV or Batik 1.5 appear to fire the onload event at all, despite: "if event attributes are assigned to referenced elements, then the actual target for the event will be the SVGElementInstance object within the "instance tree" corresponding to the given referenced element." from SVG 1.1 None of the 3 viewers behaviour is desirable, and none appear to be in accordance with the spec as far as I can read, so I'd also like clarification that my understanding of the spec is correct here, before bugging the implementors with bug reports. Cheers, Jim.

Previous Message by Thread: click to view message preview

Re: Hyperlinks in Status Bar?

"Damien Bezborodow" <drbezborodow@xxxxxxxxxxxxxxx> wrote in message news:002001c3619c$a7cb0b00$0700a8c0@xxxxxxx > Hello, > Are Hyperlinks displayed in the status bar with SVG? > For example, in (X)HTML if you hover over a link, the > hyperlink (be it a mailto:, javascript: or URI) is >subsequently displayed in the status bar so that >you can see where you are going. SWF doesn't do >this, and I find it a major annoyance and I hope that >the case is different for SVG. If possible, I think it >would be wise to make only URIs appear in the >status bar and have javascript orientated hyperlinks > hidden. That's purely a user agent issue, and I agree it would be a useful feature, I think you should address your requests to Corel/Adobe etc. who are currently creating viewers. The spec is right not to define a behaviour on this. Jim.

Next Message by Thread: click to view message preview

XForms and Text and RCC, Oh My!

Hi, folks- I've been experimenting with implementing XForms using RCC (and some of the other goodies in 1.2 that ASV6p1 provides). Based on some tests, I have a few questions, comments, and requests to make. First off, let me say that I'm very excited about RCC, and the many things that you have done with the various text features. I think that a few key features may be missing, though. First, and most important, I think that in order for RCC to live up to its potential, it is essential that some limited aspect of XPath be included. There was much debate about this at SVG Open (and I'm sure within the WG), but there is very little said about this in the 1.2WD itself, outside of the XSLT-nature use-cases of Live Templates. Perhaps my concerns are misplaced, and you have already dealt with the issues I'm about to bring up, but I thought it important enough that it bears mentioning. I have attached an example of a simple RCC XForms sample, which can also be found at: http://schepers.cc/testbed/InstanceData.svg In any arbitrary XML, one cannot expect concessions to visual appearance. That is the job of SVG. You can't even count on having any attributes common to SVG that you can leverage, or on the structure being remotely applicable to SVG. The only thing that can be counted on is a consistent internal model of the data. XForms is slightly exceptional in regard to appearance, since there is the expectation in most people's minds that the widgets will look much like they do in HTML forms. One way in which XForms is not exceptional is that in its syntax, for the sake of brevity, the nature of any given element depends largely on the context --that is, its parent and its attributes. I go into more detail in the attached example, but suffice it to say that any given template needs to be able to access, at the very least, the attribute values of the element being rendered, and the attribute values and tagName of its immediate parent. This would make a huge difference in how easily and flexibly the author could make RCC templates, for what seems a rather modest set of features. I believe the precedent is already there in <refContent>, and I doubt that any costs in implementation and processing would outweigh that of the need for post hoc scripting it would eliminate. Authors will expect to be able to "style" (or "skin") their XML with fair degree of flexibility, and if they find they can't, they may well discard SVG for their purposes. Second, I'd like to know how editable text is going to be extended. Currently, in ASV6p1, only the text element can take this attribute. I think that this should be extended to <tspan>, and <tref>, and to <flowDiv>, <flowPara>, <flowSpan>, <flowRef >, and <flowTref>. I think that there should be nested focus targets (rather than the parent <text> element always owning the mutation event), possibly navigable by delete events. Having this fine degree of control over the text content will allow authors to make extremely rich content with little or no scripting. I give an argument for an editable <tref> in particular in my attached example, in reference to a script-free implementation of XForms Instance Data (which should be useful for Tiny). SVG 2.0 is a long way away, and we are now in a crucial time for the widespread acceptance of SVG. I feel very strongly that without some type of XPath selectors in RCC in the 1.2 Spec, the funtionality of this very promising technology will be crippled. Thanks- -Doug InstanceData.svg Description: image/svg

Loading Comments...