Loading ...
Sorry, an error occurred while loading the content.

Re: Firefox 1.5 with SVG now officially released

Expand Messages
  • domenico_strazzullo
    Hi Andreas, I accept your mediation, you are so gentle. Also other friends off list. I still maintain though that the release of an incomplete implementation
    Message 1 of 49 , Dec 2, 2005
    View Source
    • 0 Attachment
      Hi Andreas,

      I accept your mediation, you are so gentle. Also other friends off
      list. I still maintain though that the release of an incomplete
      implementation is against the DVA and CA industries deontology. You
      cite open source projects, when Open Office 1.0 was released it
      could open and save .doc format flawlessly, for example. Can you
      imagine the drama if it would mess up just, say, the display of a
      document?

      In response to Jonathan's, and others', arguments I am obliged to
      remind that the question I raised is not how easy or difficult it is
      to implement. It is not about the quality of the team's work and
      dedication. The question is about the timing in the decision to make
      the product available to the greater public. It's a sign of lack of
      patience that will pay off negatively.

      If the 70% figure of rendering success has been realistically set by
      yourself then I don't dispute it, but I randomly visited about 15 of
      the svg links in my bookmarks and got 0% positive results.

      From Jonathan's answer I understand DOM 2 is complete, but then I
      also deduce that the SVG DOM subset is not complete: getNumberOfChars
      () method doesn't work. My text formatter, which is not artwork,
      works beautifully, all the window functionalities, displacement etc.
      Beautiful. But there's no text in it! Of course I could count the
      number of chars in the dummy line myself and skip getNumberOfChars
      (), but I won't do it.

      A big difference between ASV 1 and 2 and FFsvg is that ASV simply
      allowed the kick off, I don't think there were any works prior to
      that, or were there? The scenario is totally opposite for FF, it
      claims to be able to render SVG but then it doesn't quite make it.
      Plus, the official tada launch is pre spoiled by the same token.
      Also, remember that Adobe would not release ASV6 until the 1.2 draft
      would become a spec. Michel Hirtzler recently said a very wise
      thing, referring to SVG WG: "Why do they worry about 1.2? Why not
      get things together for 1.1 first?". Of course in this type of
      society the trend to not listen to older, wiser people, is ever
      galloping. Always the same story over and over again for the web.
      This type of thing makes the web suck, not rock. It's hysterical.

      What Martyn Eggleton says was true prior to 1.5, and this type of
      discussion didn't need to exist then.

      Andre Winter and Jean-David Benamou reported advertisement.

      ------------------------------------

      Jonathan,

      In my letter I can read:
      "artists and programmers"
      "artists and technicians"
      Can you?

      You say you (the Mozilla team) poled the community. I've been away
      from the list for a few months, as other developers have. Wouldn't
      have it been more appropriate to make some individual contact, like
      you did when you suggested auditing, and seek personal advice
      like "Hi xyz, the implementation is in advanced state, but this and
      that is still missing, do you think it would be blah blah?". The
      majority replied "yes". Did you take into consideration eventually
      what the minority said? Did you think it was appropriate to sort by
      number instead of by experience level? I'm not sure that you quite
      got the measure of how much artists, programmers and developers are
      concerned. The work that they have ALREADY done is affected, valid
      or not valid. This is not a personal attack against you or the
      Mozilla team, I simply know that unfortunately we often take
      decisions more in respect to schedules than anything else...

      > I am, of course, very sorry that you find that the SVG support is
      not up
      > to your needs.

      You sound like an AT&T public relation agent. I can do without this
      type of remark. I raised an issue that I see as a problem, and a
      solution that I think would be beneficial for the community,
      including Mozilla.

      > Those sound like rather nasty problems. Bug reports with testcases
      would
      > be helpful.

      Are you serious??? I'm a human, can you please talk in a way other
      than binary logic? I mean... SMIL is missing in the implementation
      and you ask for bug report? What would be the point? You call them
      nasty problems, that is what they are, not bugs.

      I don't see how switching svg off by default like prior to 1.5,
      would affect FF navigation. Did you raise the issue at all with the
      Mozilla Foundation before stating that it's "very unlikely that the
      Mozilla Foundation would take sucha drastic step"?

      But anyway, let's forget, who cares... I already said to Andreas I
      was accepting his mediation. Let's have it the Mozilla way. Let's
      have performances where instruments are untuned, galleries with
      gelatin filters on their spots, pottery made of undercooked clay,
      plays without actors, svg bar charts without bars, books with blank
      pages, let's hurry up, the Mozilla way.

      Domenico


      --- In svg-developers@yahoogroups.com, "Andreas Neumann"
      <neumann@k...> wrote:
      >
      > Richard,
      >
      > also, if you use a lot of SMIL in your examples, you have to be
      aware that Mozilla SVG does
      > not yet support SMIL.
      >
      > Andreas
      >
      > --- In svg-developers@yahoogroups.com, T Rowley <tor@c...> wrote:
      > >
      > > On 12/1/05 3:07 PM, Richard Pearman wrote:
      > > > Firefox doesn't correctly display any of the SVG's on my site,
      including
      > > > ones I'm pretty sure have the Kosha namespace declarations
      etc. Also, as
      > > > far as I can tell, the server uses the correct mime type for
      SVGZ. Can
      > > > anyone please tell me what the problem is?
      > >
      > > Your server isn't sending the Content-Encoding header for svgz
      files:
      > >
      > > http://jwatt.org/svg/authoring/#server-configuration
      > >
      > > -tor
      > >
      >
    • Jonathan Chetwynd
      Ronan, it would be great to see examples of some of your accessibility solutions for SVG, perhaps you could post links with comments? As Chris points out, SVG
      Message 49 of 49 , Dec 22, 2005
      View Source
      • 0 Attachment
        Ronan,

        it would be great to see examples of some of your accessibility
        solutions for SVG, perhaps you could post links with comments?
        As Chris points out, SVG would benefit from an accessibility
        techniques document.

        regarding meta-data labelling of SVG, http://www.peepo.co.uk uses
        reasonably extensive RDF descriptions of GUIs, can you perhaps point
        to an example that you consider relevant?

        cheers

        Jonathan Chetwynd
        Accessible Solutions
        http://www.eas-i.co.uk



        On 19 Dec 2005, at 23:04, Ronan Oger wrote:

        Jonathan,

        On Monday 19 December 2005 18:07, Jonathan Chetwynd wrote:
        > Ronan,
        >
        > as an accessibility consultant I use a variety of equipment and
        > operating systems, linux since '97-'98**, OS X currently and windows
        > whenever, certainly all three every workday.

        Yes, the inclusion of legacy systems into new systems... that painful
        old
        problem. Luckily, pre-2000 PCs are totally underweight for the
        simplest SVG
        applications, so we are technologically constrained to winXP, win2K,
        winME,
        and the serious OSs.

        >
        > Accessibility has to be included at each level, from document
        through
        > to application and operating system.

        Agreed. And I would add that there is a need for consistency.
        specifying the
        source of input is inappropriate in the document, and specifying the
        mouseover effects is inappropriate in the OS.

        I think we would be most prudent to all agree to a set of standards,
        and them
        implement those.

        The thing that would make me happiest is using metadata tags (hence
        outside of
        SVG namespace) to describe some behaviour that you can either pick up
        through
        a standardized set of scripts or through built-in UA functionality.

        > It is possible and indeed likely that there may be conflicts, and
        > this is only one reason why it is critical that accessibility is
        > included at each level.
        > Indeed KDE, Gnome and Mozilla each have helpful accessibility
        experts.
        >
        > It is important to separate out DOM level keyboard events such as
        > text entry from the general application functionality to which 1.1
        > refers.
        >
        > At the document level it may for instance be essential to provide
        > some visual indicator to the keyboard user to help them identify
        > where they are.
        > in HTML this is frequently a border around the graphic or a
        change of
        > background colour.
        > This can be done by the application, but is frequently controlled by
        > the author.
        > These de facto standards have arisen for HTML but are remarkably
        > absent from SVG at the present time:
        >

        These may be defacto standards in html, but SVG applications are far
        closer to
        QT or GTK applications than they are to html apps. I propose to you
        that it
        makes good business sense to provide shortcut functionality along the
        lines
        of those frameworks, and that app developers will be *forced* to do
        this by
        their managers when SVG applications begin to fulfil commercial
        requirements.

        I firmly believe that it is far more in the interests of the parties
        interested in accessibility to get the user agents and viewers to
        implement
        accessibility hooks that can be implemented by developers than to ask
        each
        developer to figure out how to do it themeselves in the code. This is
        simply
        asking for trouble.

        I personally would be happier with a standard we can all live with
        that offers
        a lightweight solution via scripting, using declarative tags. Like
        what the
        widgets people have been doing for years now with declarative widgets.

        > See WCAG 2.4: Provide mechanisms to help users find content, orient
        > themselves within it, and navigate through it.
        > and 2.4.8 in particular: "Using an icon or text to indicate current
        > location within navigation bars."
        > http://www.w3.org/TR/WCAG20/guidelines.html#navigation-mechanisms
        >
        > Arbitrary links are likely to be confusing for most users, what is
        > needed are standards derived through experience.
        > There is to date remarkably little keyboard navigation data
        available
        > for SVG which makes it harder to create techniques and guidelines.
        >

        True. Even more perplexing is the addition of new dynamicallay generated
        links.

        SVG applications can add/remove links that the developers may not
        have known
        about (think wikis). Tabbing is a fine way to go, but is rather
        fragile when
        used in context of the complexity that SVG can throw at you.

        Ronan



        > Chris Lilley: "an SVG techniques document would help"
        > http://lists.w3.org/Archives/Public/www-svg/2005Dec/0044.html
        >
        > Do please try our keyboard navigation using ff1.5 at http://
        > www.peepo.com/index.svg to see how we have attempted to meet 2.4.8.
        > use the 'tab' key to navigate, 'shift + tab' to go back through the
        > links.
        >

        Correction: your link is http://www.peepo.co.uk/index.svg .

        It's nice and I like the tabbing functionality. I don't like that
        it's in
        scripting and i understand why you are unhappy withthe lack of a spec
        for
        this in the w3c. However, I also think that this is best left to
        commercial
        interests to sort out as they see fit. If providers build junk, sales
        will
        sag. That's generally enough to push app developers to implement
        accessibility imho.

        You know my position that the accessibility guidelines can get
        totally out of
        control and that there will always be someone hurt by the help given to
        another person ("Document must offer brail solution",
        "Document must offer acoustic solution",
        "Document must work on an LCD without a microphone",
        "Document must provide same functionality to all users" ).

        So what do we do...?
        Do we build our systems for the lowest common denominator?
        Do we build improved systems that inevitably exclude some users?
        Do we legislate functionality into applications? If so, do we do it
        accross
        the board? If yes, why are we applying different standards to web
        apps than
        we apply to the physical press, public transportation, and vocal
        communication?

        Keep up the accessibility fight.

        Cheers,

        Ronan


        > regards
        >
        > Jonathan Chetwynd
        > Accessible Solutions
        > http://www.eas-i.co.uk
        >
        > **My install instructions for the dell latitude 433mc, which is
        > possibly one of the earliest colour(8) laptops to run linux,
        remained
        > at linux-laptops for many years!
        > This machine was never capable of running windows, but happily ran
        > tweaked linux games for our students in ~4Mb.
        >
        > On 19 Dec 2005, at 15:05, Ronan Oger wrote:
        >
        > Jonathan,
        >
        > > 1.1 "Ensure that the user can operate, through keyboard input
        alone,
        > > any user agent functionality available through the user
        interface."
        >
        > This capability already exists in all serious OS's, and adding this
        > functionality on Yet Another Layer will only create confusion where
        > none is
        > required.
        >
        > When we talk about keyboard events, we are talking about the
        > svg-document-level undersranding of the context of a keypress (such
        > as the
        > letter 'p' in the text-entry context). And I agree that SVG
        > implementations
        > need to address this. However, I also believe that this is best
        handled
        > through scripting (ie programatically) rather than declaratively.
        >
        > The idea of using key events to trigger mouse pointer events does
        not
        > need to
        > be part of this discussion because this is already handled at the OS
        > level
        > and because it is generally desirable to have consistent behaviour
        > accross
        > the entire window manager (MS Windows in your case, I presume).
        >
        > Adding this to the SVG app level will add nothing to usability and
        > will serve
        > only to make the SVG app architect's job more difficult.
        >
        > In Linux, for example, mouse and keyboard events can be linked
        > arbitrarily and
        > interchanged at will. Because of this, it is critical that an app
        > developer
        > not be able to arbitrarily impose their own mappings which may
        render
        > the UI
        > inoperable.
        >
        > It is simply not the job of SVG to know what the input methods are.
        > This is an
        > OS-level or user-inter-face-level problem. If we allow the SVG
        canvas
        > to have
        > different fundamental behaviour than the OS does, then we will cause
        > a rat's
        > nest of complications.
        >
        > I don't know how windows handles this, but in linux systems, if you
        > want to
        > use your keyboard(s) to define mouse events, it is a trivial
        problem.
        >
        > Presumably, windows XP is a reasonably well written application. Can
        > it not
        > handle arbitrary pointing device setups, including keyboard
        mappings...?
        >
        > Ronan
        >
        > On Monday 19 December 2005 09:25, you wrote:
        > > "Ensure that the user can operate, through keyboard input
        alone, any
        > > user agent functionality available through the user interface."
        > >
        > > Ronan,
        > >
        > > This distinctly is an SVG issue, which was drawn to your
        attention at
        > > our SVG meeting in London**.
        > >
        > > your quote* is an admission of error, not an exclusion, and it is
        > > important that this is acknowledged.
        > > Please refer to the SVG accessibility appendix H:
        > > http://www.w3.org/TR/2003/REC-SVG11-20030114/access.html
        > > and UAAG Guideline 1 in particular:
        > > http://www.w3.org/TR/UAAG10/guidelines.html#gl-device-independence
        > >
        > > 1.1 "Ensure that the user can operate, through keyboard input
        alone,
        > > any user agent functionality available through the user
        interface."
        > >
        > > I remain grateful to the firefox SVG team for resolving this
        matter
        > > in bug:
        > > https://bugzilla.mozilla.org/show_bug.cgi?id=259062
        > > but have no control over their method.
        > >
        > > regards
        > >
        > > Jonathan Chetwynd
        > > Accessible Solutions
        > > http://www.eas-i.co.uk
        > >
        > >
        > >
        > > On 17 Dec 2005, at 19:38, Ronan Oger wrote:
        > >
        > > *"As in DOM2 Key events, the SVG specification does not provide a
        > > key event
        > > set. An event set designed for use with keyboard input devices
        >
        > will be
        >
        > > included in a later version of the DOM and SVG specifications."
        > >
        > > **There were many outcomes including: http://svg-whiz.com/BAM/
        #key-
        > > mapping and
        > > http://jan.kollhof.net/projects/svg/examples/focus.svg was in fact
        > > presented.
        >
        > --
        > Ronan Oger
        > Director
        > RO IT Systems GmbH
        > ...Building Web2.0 with SVG since 2001
        >
        > http://www.roitsystems.com
        >
        >
        > -----
        > To unsubscribe send a message to: svg-developers-
        > unsubscribe@yahoogroups.com
        > -or-
        > visit http://groups.yahoo.com/group/svg-developers and click
        "edit my
        > membership"
        > ----
        >
        >
        >
        > SPONSORED LINKS
        > Computer internet security Computer internet business Computer
        > internet access
        > Computer internet privacy securities Computer internet help How to
        > format a computer hard drive
        >
        > YAHOO! GROUPS LINKS
        >
        > Visit your group "svg-developers" on the web.
        >
        > To unsubscribe from this group, send an email to:
        > svg-developers-unsubscribe@yahoogroups.com
        >
        > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        Service.
        >
        >
        >
        >
        >
        > -----
        > To unsubscribe send a message to:
        > svg-developers-unsubscribe@yahoogroups.com -or-
        > visit http://groups.yahoo.com/group/svg-developers and click
        "edit my
        > membership" ----
        >
        >
        >
        > YAHOO! GROUPS LINKS
        >
        >
        > Visit your group "svg-developers" on the web.
        >
        > To unsubscribe from this group, send an email to:
        > svg-developers-unsubscribe@yahoogroups.com
        >
        > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

        --
        Ronan Oger
        Director
        RO IT Systems GmbH
        ...Building Web2.0 with SVG since 2001

        http://www.roitsystems.com


        -----
        To unsubscribe send a message to: svg-developers-
        unsubscribe@yahoogroups.com
        -or-
        visit http://groups.yahoo.com/group/svg-developers and click "edit my
        membership"
        ----



        SPONSORED LINKS
        Computer internet security Computer internet business Computer
        internet access
        Computer internet privacy securities Computer internet help How to
        format a computer hard drive

        YAHOO! GROUPS LINKS

        Visit your group "svg-developers" on the web.

        To unsubscribe from this group, send an email to:
        svg-developers-unsubscribe@yahoogroups.com

        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      Your message has been successfully submitted and would be delivered to recipients shortly.