[Minutes] DIWG teleconf, 2006-03-15

Hi all,

Minutes of the DIWG weekly conference are here:
http://www.w3.org/2006/03/15-diwg-minutes.html

Attached as text for your convenience:

[[
W3C
DIWG teleconference
15 Mar 2006

See also: IRC log
Attendees

Present
     Rotan, Max, Cedric, Sailesh
Regrets
     Rhys, Kevin
Chair
     maxf
Scribe
     cedric

Contents

     * Topics
          1. Publication of the DCO document as a WD
          2. Access functions for DISelect
     * Summary of Action Items

Publication of the DCO document as a WD

maxf: keep it a note or send it to WD b/c we expect to change it many times?
... a Note is a document that's not expected to change any more
... a WD can become a Rec or a Note
... (a Note doesn't need to be implemented)

Rotan: are we going to make statements how often the DI group is going 
to update the document?

maxf: I think we'll have to show some kind of roadmap

<Rotan> See this in status: "There are currently no plans to amend this 
document further."

sailesh: maybe we can add information when something significant happens 
in the field of DI

Rotan: I suggest that we change the statement in the Status of the DCO 
document

all: we agree to publish the DCO document as a working draft.

<sailesh> The document will be updated when new technologies related to 
the document context emerges or matures
Access functions for DISelect

maxf: we discussed on the mailing list...

Rotan: I have concerns here. Everything that we do should be in line 
with CSS media queries
... we seem to be moving toward incorporating more and more functions. 
Maybe all this should rather be extensions
... I'm not sure what philosophy we chose here

maxf: I don't think we're trying to extend the CSS media queries
... the real question is whether we want to have all CSS MQ functions

Rotan: if CSS MQ is referring to a static info we should assume that the 
value is also static. Same for dynamic
... Our definition has to be tied closely to the definition of CSS MQ

maxf: CSS doesn't really need to know if the property is static or not 
(work made inside the browser); unlike DISelect

Rotan: if you resize the window, the browser reflows but does *not* 
select another stylesheet
... all this happens when the document onLoad occurs

maxf: when the window is resized, I would expect the style to be 
reinterpreted

Rotan: the display area is the viewPort Bert talked about

<scribe> ACTION: Max to contact the CSS group regarding the 
interpretation of media query functions [recorded in 
http://www.w3.org/2006/03/15-diwg-minutes.html#action01]

<trackbot> Created ACTION-163 - Contact the CSS group regarding the 
interpretation of media query functions [on Max Froumentin - due 
2006-03-22].

Rotan: the physical display width is static; the viewPort (usable 
display) is dynamic
... it's the display minus the scrollbars, the chrome, etc.
... typically you'll want elements not to overlap with the scrollbars
... because any other interpretations won't be useful

maxf: according to what the CSS group is going to respond, it won't 
change the definition of the function but may change the way we 
implement it (static//dynamic)

Rotan: in some browsers the chrome component can also be styled; we have 
to take that into accound
... that's a paradox situation: I can use a stylesheet depending on the 
width, but the stylesheet can change the width (since the scrollbar can 
be resized)
... not sure how we would resolve that.

maxf: we're beyond this specification?

Rotan: not sure; that would be an useful piece of information
... but we would maybe have paradoxes in the style
... maybe we could define the expected processing behaviour
... then the technologies in DISelect should mimic this behaviour

maxf: my implementation was expected to do the adaptation part on the server
... so the server should know what the viewport is

Rotan: adaptation is always a "best effort" process
... with the best available info
... but the server may be relying on information stored in the repository
... it's not always going to be perfect; it's driven by different data

maxf: should we include that statement in the spec

Rotan: we'll have to express that the delivery context might not be 
perfectly replicated across different channels
... otherwise expectations of people will be that the end result of the 
presentation will be exactly the same. I think that's impossible

maxf: I think that's the point of the "default argument"

Rotan: the description says either you know the exact info, or you know 
nothing
... but in some circumstances you'll be looking up info somewhere else
... where the information is not perfect.

<scribe> ACTION: Rotan to add some text to say that you might use 
alternative sources of information which reliability you don't know 
[recorded in http://www.w3.org/2006/03/15-diwg-minutes.html#action02]

<trackbot> Created ACTION-164 - Add some text to say that you might use 
alternative sources of information which reliability you don\'t know [on 
Rotan Hanrahan - due 2006-03-22].

maxf: does that conclude our discussion?

Rotan: OK

maxf: we might be able to wrap up
... it's only me who has open actions
... let's adjourn
... regrets for next week
Summary of Action Items
[NEW] ACTION: Max to contact the CSS group regarding the interpretation 
of media query functions [recorded in 
http://www.w3.org/2006/03/15-diwg-minutes.html#action01]
[NEW] ACTION: Rotan to add some text to say that you might use 
alternative sources of information which reliability you don't know 
[recorded in http://www.w3.org/2006/03/15-diwg-minutes.html#action02]

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/03/15 16:02:45 $
]]



BR, Cedric

-- 
Cedric Kiss                        http://www.w3.org/People/Cedric/
Device Independence Team Contact               mailto:cedric@w3.org
The World Wide Web Consortium                    http://www.w3.org/
W3C/ERCIM - 2004 route des Lucioles, 06560 Sophia Antipolis, France

Received on Wednesday, 15 March 2006 16:06:10 UTC