[hcg] minutes July 1, 2011

The HCG held a discussion today on the relationship between Media Fragments,
CSS, and SVG.
Here are the minutes from that discussion. 
We plan to hold another discussion in our next call, July 15, after the
relevant Working Groups have more time to discuss the issues internally.

http://www.w3.org/2011/07/01-hcg-minutes.html
and below as text.

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

              Hypertext Coordination Group Teleconference
                              01 Jul 2011

   See also: [2]IRC log

      [2] http://www.w3.org/2011/07/01-hcg-irc

Attendees

   Present
          Debbie_Dahl, glazou, +33.4.92.38.aaaa, shepazu, Janina,
          Steven, +33.9.52.30.aabb, raphael, Yves

   Regrets
          paul_cotton, kazuyuki

   Chair
          Debbie_Dahl

   Scribe
          Steven

Contents

     * [3]Topics
         1. [4]Media fragments
     * [5]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 01 July 2011

   <raphael> why the pass code 4824 is not valid ?

   <glazou> worked for me immediately but I was 1st on the call

   <Steven> It didn't work for me the first time; had to repeat it; in
   the second time

   <scribe> Scribenick: Steven_

   <scribe> scribe: Steven

   rrsagenat, make minutes

Media fragements

   Raphael: Media fragments has gone to last call twice, one set of
   comments not yet resolved
   ... a number of things say that the fragment should be rendered
   ... informative in the spec, not required for the implementor
   ... Do you think that way we have defined media fragments clashes
   with the SVG definition?

   <shepazu> ([6]http://www.example.com/multiresimage#xywh=10,20,30,40
   )

      [6] http://www.example.com/multiresimage#xywh=10

   Raphael: and do you think that CSS should be able to define the
   interpretation of a fragment URL?

   Glazou: The CSS parser has to validate the URL
   ... and whether to throw a CSS error
   ... and drop the rule
   ... and I don't see another way of doing it

   Doug: It's up to the parsing engine on the UA to interpret URLs
   ... since that's what the RFC says

   Glazou: It is also common practice

   Raphael: Is the syntax the same?

   Glazou: Exactly as defined by the RFC

   (RFC 3986)

   <raphael> [7]http://dev.w3.org/csswg/css3-images/#url

      [7] http://dev.w3.org/csswg/css3-images/#url

   Raphael: OK, so in the above section you reference the fragment
   identifiers
   ... from a syntax point of view that is OK, but how do you interpret
   the fragment?

   Steven: So you don't interpret the fragment?

   Glazou: Right.

   Raphael: But your spec defers to the mimetype for the meaning of the
   fragment?
   ... for many specs there is no definition of what a fragment means
   ... But you do provide interpretation of fragments
   ... for instance clipping out a part of an image
   ... fine for me, but that should really be defined by the resource
   type, not by CSS
   ... Media Fragments wants to give guidance when registering a
   mimetype

   Bert: I agree with Glazou's position, I think we should make it
   nonnormative

   Glazou: The examples on images, it is not the job of CSS to clip it.
   It is the user agent that does it

   <Bert> [8]section 4.1 of editor's draft of css3-images

      [8] http://dev.w3.org/csswg/css3-images/#url

   Glazou: CSS is *requesting* something there.

   Raphael: So we agree that there should be no clash between the
   different specs

   Glazou: So, the presence of an equals sign allows the discrimination
   between a reg. ID and an XPath
   ... to know what kind of thing they are, you have to stop parsing

   Raphael: The Media Fragments spec defines something that is a subset
   of the syntax for fragments
   ... a set of name value pairs
   ... so we have to parse to see if it is a media fragment URI
   ... so I agree you have to parse

   Daniel: This is not an issue for CSS/Media fragments, but for the
   rendering layer

   Raphael: I tend to agree
   ... except for the case where an image container contains more than
   one image
   ... of different types

   Glazou: Up to the image format

   Raphael: Well the CSS people want to know how to do it

   Glazou: Not our role to do that; external to CSS.

   Raphael: Good; we shall note the case and say it is undefined

   Doug: The syntax for media fragments seems fine
   ... audio/video commands
   ... clipping of audio/video
   ... but what if that video file is just one of three on the HTML
   page?

   Glazou: xywh is not an id, it is a command

   Doug: I meant, what if I link to a youtube video?

   Raphael: This is a frequent case. Already planned to propagate the
   hash to the actually sourced video

   Glazou: Example please?

   <shepazu> [9]http://www.example.com/example.ogv#t=10,20

      [9] http://www.example.com/example.ogv#t=10

   Doug:

   <raphael> #t=30,120 for example

   <shepazu> [10]http://www.example.com/example.html#t=10,20

     [10] http://www.example.com/example.html#t=10

   <glazou> then <video id="t"> and #t vs. #t=10,20

   Doug: In the second example the big content providers will rpoagate
   the #t= to the actual video

   Raphael: Almost, The spec says nothing normative
   ... in the example the HTML will try to find an ID called t=10,20
   ... but youtube will do something special

   Glazou: Why a hash instead of a "?" ?

   Raphael: There's a big section in the spec on the different
   behaviours
   ... you can use a ? as well
   ... with a ? you get a new resource, which is not cached etc
   ... with a # you can cache, and you have the whole root resource as
   well
   ... we have tried to define it so that nothing breaks. We have found
   no counter-example yet.

   <Bert> (Error in minutes? A "?" doesn't influence caching. Caching
   is controled by HTTP headers, not by the shape of the URL.)

   Glazou: So you are targetting media, but a web page is not media

   <raphael> indeed, I just say it just creates a completely new
   resource which has nothing to do from the "parent" resource

   Raphael: The spec doesn't recommend what happens with HTML pages, it
   is just what some sites do

   Doug: I will email my problems; I think we are setting ourselves for
   trouble

   Glazou: what if "rewind" is a command for videos and there is a
   "rewind" ID in the document ?

   Steven: #rewind isn't a MF URL, no problem

   <raphael> Raphael: this has nothing to do with media fragments

   Doug: The question is whether there are existing clashes with other
   fragment syntaxes

   <shepazu> [11]http://www.w3.org/TR/2009/WD-SVGParam-20090616/

     [11] http://www.w3.org/TR/2009/WD-SVGParam-20090616/

   Doug: I have a question about SVG
   ... SVG parameters, not there yet, but specced out
   ... minting URLs that act on the existing resource and passes
   name/value pairs

   <glazou> s/rapahel/raphael

   Doug: I hope we can avoid clashes

   <shepazu>
   [12]http://dev.w3.org/SVG/modules/param/master/SVGParam.html

     [12] http://dev.w3.org/SVG/modules/param/master/SVGParam.html

   <janina> +1 to Doug. I see the problem here is how, not whether to
   specify something/somewhere within a doc/object.

   Yves: SVG is an XML media type so should obey rfc 3023
   ... then you have to use xpointer
   ... which is different from formats that are not XML-based

   Doug: Don't assume that SVG will be XML-only
   ... maybe you and I could discuss the SVG param stuff sometime

   Glazou: Original question, conflics with CSS< there is no problem

   Debbie: I think we have a resolution here

   Raphael: No problem with CSS and SVG, need to watch out with SVG2

   Glazou: The CSS WG needs to look at this, next Wednesday

   Doug: SVG is a timed media that uses # for other purposes, but I
   need to check

   Glazou: So we will go back to our WGs and come back to the HCG

   Debbie: 15th July?

   Bert: Bad day for me (French holiday)

   Glazou: In any case we will send an email to the HCG

   Raphael: Thank you for this discussion. Looking forward to your
   responses

   Doug: Already implementations, and tests?

   Raphael: Ongoing
   ... Firefox and Opera in so far
   ... and big servers

   [ADJOURN]

Summary of Action Items

   [End of minutes]
     _________________________________________________________

Received on Friday, 1 July 2011 15:12:44 UTC