See also: IRC log
Topics: Administrivia
<jo> PROPOSED RESOLUTION: BPWG Call to stay on Euro Time till March 30th
Jo: We won't be having a call
next week - the next call will be the 13th.
... Proposal to stay on european time - GMT - during the US
time change.
<jo> RESOLUTION: BPWG Call to stay on Euro Time till March 30th
<francois> ACTION: daoust to make sure next calls will stick to european time [recorded in http://www.w3.org/2008/02/28-bpwg-minutes.html#action01]
<trackbot-ng> Created ACTION-675 - Make sure next calls will stick to european time [on François Daoust - due 2008-03-06].
Jo: We had to make a decision
quickly and the results of the poll point to 16-20 of
June.
... Registration will start soon.
Nacho: the formal decisions have happened from both bp and dd groups. Right now I'm waiting for some information and I will send the details to the list next week.
Jo: Thanks.
<francois> latest draft
Francois: I would like to present
the latest draft to the working group.
... Summarizing: what needs to be done before we go to fpwd and
afterwards.
... We had a lot of discussion on scope and this is what we
agreed.
... First, [burst of music], extending http for communications
between the different actors is not the way to go - it's beyond
our charter and http isn't open for modifications - not
flexible enough.
... The big CT picture could take into account OMA DPE, W3C
DCCI, or Powder.
... So we decided to stick with existing technologies and try
to avoid new http headers. It's not settled if we need one or
not at the moment.
... As legacy browsers are the target for the moment, we
decided to leave the browser aside and so communications
between CT proxy and user must be through web pages. Future
browsers may add cache-control no-transform header.
... These are the two main points. Now there are 2 things that
need to be answered before fpwd.
... First is regarding the way the CT proxy works. We haven't
had time in the last call to take a resolution. How should the
proxy work - should it do "content tasting" - sending an http
request, looking at the answer to see if it is correct?
... Does it have to change the user agent? If there is no need
to change the user agent, then we probably don't need any
additional http headers.
<jeffs> "tasting" should read "testing"
Francois: Second big question:
something introduced in last draft - use of POWDER. POWDER
could be used on the server side.
... do we have a dependency on powder or do we just want to
reference powder. It doesn't exist - it's at fpwd at the
moment. So we might run into the same problem we've had with
xhtml basic - waiting for Powder.
<Zakim> Kai, you wanted to say that this depends on how DRs are discoverable
Kai: Info on POWDER - we have 2
types of documents, the web resoruce and the description that
describes the web resource.
... We are discussing URI schemes.
... wrt content tasting, 2 ways to do it - look at the resource
itself or look at the description resources. Because of the
problems we've discovered with numerical URIs, it is under
discussion to close off tasting through tasting descripion
resources but this is not prefered.
Jo: Any other questions on POWDER
or CT?
... I think we're going to spend some time in Korea discussing
these issues.
... We may not be able to take resolutions in Korea but we will
be able to make some progress in workshopping these issues.
Kai: draft is finished. It's out
there, please look at it. In the mail I posted I mentioned the
task force would ask the main group to make this a fpwd.
... also emulator code has been pasdsed to Dave Rooks.
... Progress has been good.
Jo: We'll be addressing this also in Korea.
<francois> mobileOK Pro doc
<jo> Draft Agenda for F2F
<francois> DKA: I put together an agenda. Problem is we'll have a restricted number of participants. I included some time to get input from Korean people
<francois> ... to see what would be useful to have in BP2.0
<francois> ... some time for the CT TF, mobileOK Pro TF
<francois> ... The more time we can spend flushing things in documents, the better
<francois> ... as opposed to taking resolutions as we'll be a small number of participants
Jo: Where did we get to?
Alan: Tab order.
Jo: Any comments?
... Tables_alternatives
Alan: this one is odd but some
users might find it more complicated.
... This is in the mobile context use an alternative not on all
contexts.
Kai: [censored]
Jo: We need to say that there is
no added benefit for users with disabilities and move on. I
think we should remain silent on whether it makes it more
difficult for users with disabilities.
... let's move on to tables_layout
Alan: there are 2 aspecst - using
a table for layout might cause incorrect reading order.
... If you use tables for layout, it's difficult for the user
to modifyt the layout by using their own stylesheet.
Jo: Most mobile browsers do support tables so the comment about non-support might not be correct.
<jeffs> do not use tables for layout
Jo: Moving on to nested_tables
+1
tables_nested
Alan: if tables are nested for layout then for a screen reading user it makes it very confusing. So it's best avoided.
Jo: Other comments on
tables_nested?
... Tables_support?
... No added benefit.
Alan: yes.
Jo: testing.
[long pause]
Jo: It helps to some degree but
it won't give you a benefit.
... Other comments?
... Thematic Consistency?
... I think this could do with more. Can we put a pin in this
discussion and we can raise an issue on the list to discuss
it?
Alan: the concept is the same - access the same content from a range of devices and also with a range of user abilities.
<achuter> ACTION: achuter Discuss on the list THEMATIC_CONSISTENCY [recorded in http://www.w3.org/2008/02/28-bpwg-minutes.html#action02]
<trackbot-ng> Created ACTION-676 - Discuss on the list THEMATIC_CONSISTENCY [on Alan Chuter - due 2008-03-06].
Jo: The point of the best
practice is the other way around - what we're saying you
shouldn't do is to provide pages with different meanings from
the same URI depending on the circumstances of the access.
Example of bbc.co.uk/mobile which provides mobile-friendly
content if you're on a mobile devices and instructions for use
of mobile if you're on a PC - this is not best practice.
... Moving on - URIs.
Alan: Users especially with motor disabilities might have difficulty typing them in the same way that a user of a mobile device has trouble typing them on a keypad.
Jo: Anybody got anything
else?
... Moving on - use of color.
<jeffs> add anything on greyscale?
<Kai> if you are curious http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080228#use_of_color
Alan: User of the mobile device might not see the color because of bad ambient lighting, other users might not see the color at all either because they can't see or because they have color perception deficits. So it's comon cause.
<Emmanuel> I am only on IRC not dialed into call
Jeff: Putting in 2 worth - choosing colors that go to greyscale properly.
Jo: We don't have that in BP1 but maybe we could put it in BP2.
Jeff: Yes I tell my students there.
I suggest you send something to the list on that, Jeff?
<jeffs> will send something to list on color choices and decay to greyscale
Alan: it's not about using high contrast colors but rather not using colors to convey information (e.g. red means stop).
Thanks.
Jo: We had a formula in the BP document but we removed it at one point.
<achuter> Under URIS change d in WCAG 1.0. to 2.0
Yeliz: UI wanted to say about keep URIs of entry points short - that should refer to 2.0 not 1.0.
Jo: Valid Markup - last one of the document.
Alan: This one corresponds to a
1.0 checkpoint but at 2.0 they removed requirement for valid
code at one stage and then changed it to "Well formed"
markup.
... The arguments in the wcag working group is that it doesn't
give accessibilty benefit. Does it bring a benefit or not?
Jo: I don't think it's for us to
judge.
... It does give you WCAG (2.0) compliance.
Alan: Yes but it's hard to justify whether it brings benefits to users with disabilities.
Jo: We're done with that document
for now.
... You're able to make changes now you've been waiting to
make. Yeliz made some contributions and those can be folded in
as well. OK?
... Thanks again, Alan.
... BP 2.0 - discussion of recent inputs on the mailing
list.
DKA: Have RIT done anything on scripting that we could bring into next week's f2f?
Jeff: I don't know that I have
anything concrete to contribute until what scripting.
... Seperate javascript into seperate files for PC sites and
for mobile it makes more sense to put it inline.
... I'll try to get some some written materials to the list by
the weekend.
<dom> [Adam's mail on AJAX being an opportunity to reduce network access problems took me aback, but sounds very interesting to me]
<dom> [dom's random thought of the day]
Adam: one suggestion was not to build the DOM on device but to send the whole html vs building the DOM on the device - trade offs there where it might make sens to do some experimentation.
<jeffs> will go for obvious general-level javascript BP, like inline vs separate files etc...
DKA: that sounds relevant.
<jo> [in response to Dom's, Jo's random thought is that the best place to take into account "dynamic" properties of the device is in the client and not to use OMA DPE]
Adam: I could do a simple test case for this.
DKA: Could Francois set up a space for the bp 2.0 doc test cases?
<scribe> ACTION: Dan to create an issue to start bringing together potential test cases. [recorded in http://www.w3.org/2008/02/28-bpwg-minutes.html#action03]
<trackbot-ng> Created ACTION-677 - Create an issue to start bringing together potential test cases. [on Daniel Appelquist - due 2008-03-06].
Jo: I'm going to end the meeting there.
<Kai> Enjoy Seoul!! I would like to be there.
Jo: That's it. Bye!
<abel> bye
<yeliz> byee
Bye!
<Magnus> yes
<miguel> bye
<francois> zakmi, list attendees
<Magnus> oops i left