- From: Francois Daoust <fd@w3.org>
- Date: Wed, 18 Jun 2008 08:58:59 +0200
- To: MWI BPWG Public <public-bpwg@w3.org>
Hi,
The minutes of our busy Mobile Web Application Best Practices day during
the F2F are available at:
http://www.w3.org/2008/06/17-bpwg-minutes.html
... and copied as text below.
In short:
- scope was refined and agreed
- we reviewed the document thoroughly and agreed on changes
- Scott proposed some more best practices and is to work on drafting
text for these
- Once changes are included in the next version of the draft, the idea
is to publish the document as First Public Working Draft, if at all
possible at the same date as the publication of Mobile Web Best
Practices as Recommendation.
Francois
17 Jun 2008
[2]Agenda
[2] http://docs.google.com/Doc?id=dd3jk8v_114tkbg6kgj
See also: [3]IRC log
[3] http://www.w3.org/2008/06/17-bpwg-irc
Attendees
Present
Ed, Jo, Adam, Zack, DKA, Kai, Sunghan, Jonathan, SeanP, Dom,
Francois, Scott, Rob, Abel, Miguel, Manrique, PH, Rotan
Regrets
Chair
Dan, Jo
Scribe
Dan, Sean, edm, rob, francois
Contents
* [4]Topics
1. [5]On the agenda
2. [6]MWABP - Scope
3. [7]MWABP - Requirements
4. [8]MWABP - Personalization
5. [9]MWABP - Security and privacy
6. [10]MWABP - User awareness and control
7. [11]MWABP - Use of cookies and redirection
8. [12]MWABP - Conservative use of resources
9. [13]MWABP - One Web
10. [14]MWABP - Interaction and presentation issues
11. [15]MWABP - Handling device capability variation
12. [16]MWABP - Separating structure, style, and behavior
13. [17]MWABP - Publication as First Public Working Draft
14. [18]mobileOK Checker
* [19]Summary of Action Items
NB: MWABP is an accronym for Mobile Web Application Best Practices.
_________________________________________________________
On the agenda
Jo: Today we have scheduled a full day of BP2. Summary of yesterday:
we made good progress on CT.
<jo> [20]Agenda
[20] http://docs.google.com/Doc?docid=dd3jk8v_114tkbg6kgj&hl=en_GB
Jo: Having spent an extra half-day on that, we need to reschedule
the things we didn't do - mobileOK topics.
... We can try to fit that in tomorrow but it may mean running into
the afternoon.
... Also tomorrow, we have a review of the accessibility document;
we need to figure out how the checker is going; we need a report
from the Korean task force; a report would be great.
Abel: We rescheduled the mobileOK item - but we are leaving in the
afternoon tomorrow.
Jo: We can move the agenda around to accomodate that.
MWABP - Scope
Jo: Adam as co-editor for BP2 has prepared some comments.
... Also a Vodafone submission.
... We will start with a document review and scope discussion.
<adam>
[21]http://docs.google.com/Doc?docid=dft77cn8_17dkz5wp8h&hl=en
[21] http://docs.google.com/Doc?docid=dft77cn8_17dkz5wp8h&hl=en
Adam: I've made notes on many of the BPs. Many of them are good but
we need to reword parts of them. Rather than wordsmithing here we
should get a feeling for intent.
... top of the doc is scope
... then section 2, which used to be the requirements section. Bryan
took the content from that and absorbed into BPs. Do we want to now
remove that section?
... I've highlighted the ones that I feel need most attention.
... there's a few more BPs we can add. We should go through those.
... scope?
Jo: yes.
<dom> [I think 4.11 (Applicability to Non-Browser Web Runtime
Environment) should probably be moved to scope, 1.4.2 ("Web
application")]
adam: I've took the original scope, pasted in Jo's comments and
removed wording on widgets. We need to flesh out the mobile context
bit and describe what's unique about the mobile context.
kai: in reading the document, it's focused on web applications - how
does it tie together? I felt a disconnect with the static properties
of mobile content. Discuss!
jo: are you saying it's missing bits on static content that are
missing in bp1?
kai: yes - I was thinking there would be some more expansion on the
topics in bp1
scott: I agree. Some of my input is in this area.
kai: I don't have any specific inputs in this area.
adam: It feels like a very big doc to me so I agree we should add
some more but also we need to cut out items.
jo: we need to categorize comments under the headings of missing,
wrong, extra, typographic and unclear.
kai: we need to have references to bp1 - a stronger linkage.
jo: what is missing is a stronger tie-in to bp1 - needs to be higher
level than bp1 but lower level than "applications."
kai: yes
jo: i think there are things missing from bp1 like the one I
suggested yesterday. For example, we don't say that it's a bp for
hosts to offer a choice of presentation where they have one. Would
you say that's a candidate for bp2?
kai: potentially.
jo: I have in mind a mental model of how these documents fit
together [goes to white board].
... BP1 is a foundation document, on which is built mobileOK basic,
on which is built mobileOK pro.
... now we are creating a new foundation document - bp2. In this
model, all the documents should refer to bp1 as the foudnation.
kai: the tests document show you adhere to the best practices. with
bp2 there is a gap.
jo: if so, then the answer is to fill that chasm in and increase the
linkage back to bp1.
adam: yes - I'd like to see that expressed in concrete best
practices.
jo: to return to the discussion of scope -
adam: there are 3 sides to the scope - what's bp, what's a web app
and what's the mobile context? Preface that with some intro wording.
... some requests to add more material to the mobile context have
come in.
... I'm happy with it in its current state.
... signifigant concerns?
jo: I've made the point that I don't think think that "great web
applications" is meaningful.
adam: I like it - I found it grounding - I think it's been dropped
out of the scope.
DKA: I like it because it speaks to web developers.
Jo: is it possible to be precise and also populist? Would it be
better to make it precise and then make it populist?
adam: It needs to be useful.
Jo: To be useful it has to be correct. To be correct it has to be
percise.
Dom: I think the question is a good one. I'm not sure there's a
direct correlation between this issue and whether the phrase "great
web applications" should be in the document.
Jo: If you advertise in the scope that it's about great web
applications then you . I think we should remove it and then make a
pass at the end.
... I think it's about ineroperability at its heart.
Ed: I regarding the audience should we be more percise, saying that
this is for web developers as opposed to programmers?
... are we talking about markup technologies primarily?
Jo: under 1.3 what would need to change there?
Ed: People who build java applications I consider to be programmers,
people who do markup are web developers [in my view].
DKA: It's all a sliding scale.
Jo: in what respect should this text change to reflect that
sentiment?
Ed: the last sentence - can we make it positive...
... Please add "Web developers"
adam: I'm happy with that.
<Zakim> dom, you wanted to suggest 4.11 be integrated in scope 1.4.2
Dom: currently applicability to web-runtimes is in 4.11. I think it
should be in the scope of 1.4.2.
adam: I agree.
<Zakim> Kai, you wanted to say that since BP 2 is supposed to be a
specification it should be precise. We should avoid marketing
speech.
kai: I wanted to get back to wording - since it's intended to be a
specification it should be percise. Specifications don't have any
room for marketing-type-speech.
Jo: We have 2 competing objectives - one is to make it accessible as
possible, the other is to make it tight and correct.
Kai: I think "great web applications" have no meaning.
Jo: How about "web applications" rather than "great web
applications"
DKA: I think having prose-type text at the beginning of a document
does not take away from percise text later in the document.
Alan: I agree with Kai that "great" isn't an appropriate term to use
in this document - but might be better in an outreach document. Also
"Web 2.0" is ill-defined.
Kai: I agree.
DKA: I agree.
Jo: rather than trying to define "Web 2.0" perhaps someone would
like to take an action to propose text for that section.
Kai: "Interactive web technologies"
<Kai> ACTION: Dan to come up with alternative phrasing for Web 2.0
[recorded in
[22]http://www.w3.org/2008/06/17-bpwg-minutes.html#action01]
<trackbot> Created ACTION-783 - Come up with alternative phrasing
for Web 2.0 [on Daniel Appelquist - due 2008-06-24].
<Scott>
[23]http://docs.google.com/Doc?docid=dd3jk8v_116pb2r6cfw&hl=en
[23] http://docs.google.com/Doc?docid=dd3jk8v_116pb2r6cfw&hl=en
[reviewing Vodafone submission]
scott: two main areas are user interface and performance - mainly
around using client side scripting.
... there may be some overlap [with the current doc]
jo: Ok - this looks "great"
... it looks like it's fairly easy to weave into the structure of
the document.
scott: some bits at the end not sure where they fit - such as
network.
adam: as we fix in the existing BPs these should slot in nicely.
Some references to minimizing network access. We need to tighten up
how that's presented and worded.
jo: back to a line by line review.
adam: this document is 9000 words long
... 1.4.4 and 1.4.5 - now obsolete. Are there bits we need to
preserve or can we delete them?
[some discussion on wording of this section]
jo: should there be an expression of what the document is not?
... as far as I'm concerned that's "great"
MWABP - Requirements
adam: section 2- this contains all the text now absorbed into
section 4.
... propose to remove section 2.
jo: I wasn't happy but I can see the rationale and the consensus
view is to remove it so let's move on
MWABP - Personalization
<Zakim> Kai, you wanted to say something on legal issues of
personalization
kai: some of the text encourages using automated means to collect
usage patterns but in Germany this can be illegal. So some of the
stuff we're saying needs to be looked at because it might be
illegal.
adam: the intent is to say if you have a relationship with the
operator you can...
kai: it needs a careful read-through with this point in mind.
jo: we touched on this - should we be seen to be encouraging illegal
behavior.
... but not sure what to do to the document...
kai: there's a difference between permission data and automated data
- that's one area where we have to be careful.
adam: is it safer just to talk about sign-on?
... there's manual signon and automated signon... so rather than
personalization talk about sign-on?
kai: I can take an action...
<dom> ACTION: Kai to review 4.1 Personalization with privacy
regulations in mind [recorded in
[24]http://www.w3.org/2008/06/17-bpwg-minutes.html#action02]
<trackbot> Created ACTION-784 - Review 4.1 Personalization with
privacy regulations in mind [on Kai Scheppe - due 2008-06-24].
DKA: do we need specific wording about privacy and legal
implications (e.g. european data protection, etc...)
Jo: that could be a slippery slope....
<Kai> ACTION: Kai to check the personalization section for specific
parts that seem to imply combination of personal information with
usage patterns [recorded in
[25]http://www.w3.org/2008/06/17-bpwg-minutes.html#action03]
<trackbot> Created ACTION-785 - Check the personalization section
for specific parts that seem to imply combination of personal
information with usage patterns [on Kai Scheppe - due 2008-06-24].
Ed: to be very generic - legality is important. Something like
"privacy regulations and legal constraints."
adam: on the back of this conversation - should we focus on login
instead of personalization?
... "use automated means for obtaining personalization information"
seems inflamatory.
kai: the current phrasing [could be construed] as encouraging
illegal behavior.
jo: add a note that it needs to be clarified.
<dom> ACTION-784: dup of ACTION-785
<trackbot> ACTION-784 Review 4.1 Personalization with privacy
regulations in mind notes added
<dom> close ACTION-784
<trackbot> ACTION-784 Review 4.1 Personalization with privacy
regulations in mind closed
adam: I suggest removing yexy "in the pc environment...is acquired"
in para 1 of 4.1. Doesn't add value - document will be more
accessibile if it's more percise.
jo: suggests "personalization often increases user value."
... [digressing] we have in a number of occations tripped across the
differences between "mobile ISPs" and traditional ISPs. Some of the
things we would like to advocate as best practices are not obvious
to the uninitiated.
... for the exampe of push - it's a good idea, but in order to do
that you must have a relationship with a "push provider" of some
kind or you can't do it - so other elements need to exist besices a
clear internet connection between the device and the origin server.
... so we need to note that there are things you need to know about
the ecosystem that you may not know.
adam: we cover the case where you have a relationship with a service
provider of some kind first and then where you don't - should we
reverse this order?
jo: yes and then we can have some additional wording on who can act
as a service provider [eg aggregators]
<jo> ACTION: Jo to draft wording for an appendix that identifies the
aggregators and operator roles that are different in the mobile
ecosystem. [recorded in
[26]http://www.w3.org/2008/06/17-bpwg-minutes.html#action04]
<trackbot> Created ACTION-786 - Draft wording for an appendix that
identifies the aggregators and operator roles that are different in
the mobile ecosystem. [on Jo Rabin - due 2008-06-24].
adam: suggest cutting out text on "other user information..."
<achuter> +
alan: occurs to me that personal information might include
accesability preferences.
adam: i'm proposing removing the enumeration all-together.
alan: ok
dom: comment on editorial process question - this is a good process
today but in the normal process we don't have to go through all your
proposed changes.
<Kai> ScribeNick: Kai
adam: [explaining his reasoning for a comment on cookies]
... that hidden information is not retained across sessions
... need to remove the cookie part
... as for security don't store personal infomation in cookies and
adjust security to what is necessary
MWABP - Security and privacy
adam: 4.2.1...is the wording ok?
... what is the intent of this BP?
jo: not sure if this is particular mobile specific
adam: not sure
dom: this may be interesting for web developers in this context
jo: i am not sure that using secure hashes is a BP
adam: should we remove this section?
is there a document we can refer to, since it is not specifically
mobile?
jo: what do the present think?
... is this sufficiently mobile?
dom: if you only develop apps for the pc then this may pose
different challenges since it is a mobile environment
... recommending not use HTTPS is certainly not a good practice, but
you have to take the mobile context into account
jo: should we say do not use HTTPS unnecessarily?
... if we were to say use a secure hash somebody might ask what is
that exactly?
francois: you want to just say use https if you have secure
information?
SeanP: isn't it the same on the PC?
jo: but it is in scope
... there are certainly harmful effects in a mobile environment
SeanP: but don't overuse it, right?
adam: so we should change this from protecting personal information
to balance the measures chosen?
jo: can you come up with seomthing?
dka: can we have explicit examples?
... instead of leaving it open, give specific alternatives
... we should not say these are the MOST secure alogrithms or
somethign like that
adam: I agree. We would then have to worry about that too.
edm: rather than just say "use HTTPS
... use "performance implications of using HTTPS"
MWABP - User awareness and control
adam: 4.3
Inform user about personal information? how and what?
adam: [explainin this proposed changes]
... perhaps the BP is good and we need to reword it a bit
... informing the user means there are some browsers that show
personal information, such as contacts etc.
... you should allow users to opt out
... I think we need to come up with a coherent view of what this
sections means and says
dom: maybe this should have a caveat if the device does not allow
the opt out the app should do so
adam: the app may not know if a dialog has popped up (?)
dka: the implementation are not out there yet
... access to the address book from the scripting layer would surely
prompt the user
jo: we should something to catch poor app design
... harmonzing access with underlying systems
dom: if you get this prompt but don't the app will get access to
your addressbook you will be surprized
adam: make the request for personal information an active choice?
dom: yes.
... we need to keep the user aware of what might trigger access to
personal information
jo: prior to running the app for the first time it should inform the
user about all the information it will access
adam: CP may not necessarily want to do that
jo: it can be done in a number of ways
edm: i think it would be good have statement of balancing security
with sensitivity
... context does matter a lot, but taking advantage of that context
is a trade off
... user experience may improve but there is a price to pay
... don't ask for everything if you make do with less
... should we recommend DCCI or so?
jo: I think we have had problems with this before and would say no
dom: I think we can't say it is a BP
... there will be a geolocation API and if this work is going ahead
fast enough, it might become interesting
jo: at the end of this section we will take a break
... 4.3.4 - Brian is keen on redirection
[break for 20 min]
[We're baaack]
MWABP - Use of cookies and redirection
adam: provide control for app behavior
... use of cookies and redirection
... this might be a bit turned around. Should be robust against loss
of cookie information
<DKA> +1
jo: the amount in infos should be minimized is the focus here
... use only the user id key
adam: minimize redirects
... use landing pages
Kai: actually landing pages tend to annoy users
jo: we don't want to interrupt user flow
... we need to balance the two
<Zakim> DKA, you wanted to wonder out-loud on whether there should
be a bp on use of client-side database?
dka: there are at least two implementation of client side databases
... would it be useful to write something about this in this
document?
jo: so to minimize client side storage is not a BP?
dka: in the mobile context you probably don't want to store lots of
information
jo: so the amount of information is important
... the amount of offline operation needs to be taken into account
... and multi channel access services
... speed of access is important
adam: where does this fit in?
jo: control of the app is really the point taking this into account
adam: does this fit into this section on cookies and redirects?
jo: no
Kai: what about redirects, latency etc. Is that still timely for
this document?
jo: we need to get to this, but let's finish this first
adam: so which BPs do we need?
jo: I think we need a how to do it
... also need to add the thing on size of client side storage
adam: move redirects to use of resources
Kai: we should not focus too much on redirects, latency and realted
issues
jo: Bryan has a similar stance
... I am not sure how much more we are saying here that hasn't been
said in BP1 already
adam: we should mention it, but it doesn't really add much
jo: we should have a coherent policy on when to mention BP1
dka: we had said earlier we need a stronger linkage between BP1 and
BP2. Here we can do that. would help to clear up that BP1 is not
encouraging lowest common denominator
jo: so where possible we should make reference to BP1
... we could have a preamble "refer also to..."
adam: web applications increase demands for redirects for
authentication?
jo: I am not sure "need" is the right
Kai: sometimes redirects really are overdone but they do have an
important role to play
... is there are web app specific part that we could mention?
adam: well the authentication part may be one
jo: so let's ref BP1 on redirection as preamble for 4.5
dom: there is no real BP that says minimize server redirection
jo: so yes, then we should call out the fine points
... but we perhaps should not mention specific numbers on redirects
<SeanP> Scribe: Sean
<SeanP> Scribenick:Sean
MWABP - Conservative use of resources
Jo: on to 4.5
Adam: Transfer compression makes sense
...not sure what we want to recommend for app level compression
Kai: Everyone thinks that compression will speed things up; when you
go to binary on a fast network it sometimes slows things down.
...not sure if this is always true in mobile environment
DKA: Makes Vodafone joke
Rob: Use text-based compression
Jo: How can we capture point of efficiency gain of compression vs.
loss of battery life, etc.
Kai: restrict to text based compression
Dom: Don't compress 1k files and be careful with other bad
compression techniques; is there a way we can get data on this?
...If you are going to send 1M of a text file, it should be
compressed.
...Where is the line?
Adam: Could publish a table with thresholds of data sizes to
compress.
Kai: Can show a table of compression data.
Jo: 4 dimensions of compression: 1. type of network, 2. type of
processor, 3. size of data to be transferred, 4. likely benefits of
carrying out compression/decompression
Rob: In practice you tell it what mime types to compress
Kai: [Puts up a table about compression on the screen]
Kai: [Describing table] Many times don't see much benefit from
compression of binary content on ISDN and broadband
...Compression makes a big difference however on text based content
Adam: Simple message: compression of text is good, compression of
binary data is bad
Kai: [another spreadsheet is projected] [Shows a case where
compression has a negative effect]
...A lot of variation in benefits of compression for different files
Rob: Given normal developer tools, it is difficult to configure to
compress different size files
Scott: After doing all of the BP1 stuff like removing whitespace,
etc, the impact of compression may not be that much.
Adam: Javascript compresses well.
Adam: Can change the compression BP by: a vague mention of being
careful with compression, mention binary files or text files, or do
some work to find out which files should be compressed or not
Kai: Obfuscating JavaScript makes the files smaller
Adam: yes, should we call it tokenizing?
<dom> [An ajaxian article referring to the lack of benchmark on the
topic
[27]http://ajaxian.com/archives/compression-caching-for-faster-load-
times]
[27]
http://ajaxian.com/archives/compression-caching-for-faster-load-times
Jo: Open question: Do some work to find out what files and sizes are
best to compress.
<dom> [another related article:
[28]http://clientside.cnet.com/best-practices/optimization/dean-edwa
rds-packer-compression-tool/ ]
[28]
http://clientside.cnet.com/best-practices/optimization/dean-edwards-packer-compression-tool/
Adam: There is a section on app compression which I thought we
should remove.
...I think it is covered elsewhere.
Jo: Can we put something in about preprocessing JavaScript?
DKA: There is a mention of EXI; I think this is out of scope for
this document.
<DKA> +1
Jo: EXI is not a done deal; we usually don't refer to things that
aren't done deals. Also WAP is out of scope.
Kai: Shouldn't we refer to asynchronous methods to reduce transport?
Adam: I agree; we should refer to that.
Jo: Should it be in this section or another section?
Kai: Maybe in another section.
Jo: Moving to "Minimize Automatically Issued Network Requests"
<dom> [an apparently very relevant IEEE paper on compression:
[29]http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/7513/20446
/00945195.pdf?arnumber=945195 "In this paper, we define the total
delay as the time for both the transfer and the decompression of a
compressed file. To minimize the total delay, a mobile program
should be compressed in the best format for minimizing the delay.
Since both the transfer time and the decompression time are
dependent upon the current un
[29]
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/7513/20446/00945195.pdf?arnumber=945195
<dom> derlying resource performance, selection of the "best" format
varies and no one compression format minimizes the total delay for
all resource performance characteristics. We present a system called
Dynamic Compression Format Selection (DCFS) for the automatic and
dynamic selection of competitive compression formats based on the
predicted values of future resource performance. Our results show
that DCFS reduces the total delay imposed by the compressed transfer
of Jav
Adam: 2 main points: Batch requests together and Back off during
periods of inactivity
<dom> a archives (.jar files) by 52% on average for the networks,
compression techniques and benchmarks studied"]
...Make these two things the focus of this section.
Dom: How do you do this?
Adam: Combine your XHR requests; configure your server to be in
chunked mode so that you are not making continuous XHR requests--not
sure if this is actually better however
Kai: Would sections like this benefit from listing bad examples?
...If we can't come up with concrete problems that we are trying to
solve, maybe we don't actually have a good BP.
Jo: A good idea, but verges on the idea of techniques.
DKA: Actually different than techniques; with techniques we would
come up with a Wiki and the community would come in and add
content...
...Come up with example applications--this would be a new work item
however.
Kai: If you show a good way and a bad way to do things, you can see
the difference.
Adam: From the view of developer, the good way would be more useful.
Jo: Back to "Minimize Automatically Issued Network Requests"
Jo: Is there anything to say about roaming here?
Adam: No way to tell if you are roaming.
...Good reason to give users more control
Scott: Are we talking about a low bandwidth version and a high
bandwidth version?
Adam: Do we want to make a BP for this?
Jo: I think we should do this.
DKA: Refer to BP1.
DKA: Example of Twitter: m.twitter.com is a really stripped down
version of Twitter; the iPhone version of Twitter is a much richer
user experience.
...I use both of them.
Adam: If it makes sense to your app, provide a low bandwidth
version.
Jo: We're going off on a tangent...we're talking about automatic
network requests.
...I think we want to say offer a low bandwidth version if you can.
...some apps may not be able to offer a low bandwith version.
Adam: Should be able to switch network off if possible.
Kai: Is this low bandwidth stuff really relevant for this
document--we're not really talking about saving money.
...it's about a comfortable application; sometime you have to spend
more money.
Jo: We're talking about value--an app
...shouldn't use bandwidth unnecessarily.
Adam: Moving to "Push Methods"
Jo: generated a lot of discussion on list
Adam: Reference to MIDP seems out of scope; but I like the idea of
the BP.
Jo: What we lack standardized or commonly accessible push methods.
Hard to recommend a specific Push method.
DKA: What about WAP push? Is it the same as OMA push?
Adam: I think they are the same?
Rob: That is the problem. Where does a developer go to find out
about this stuff?
<dom> [30]OMA Push specs
[30]
http://www.openmobilealliance.org/technical/release_program/push_v2_2.aspx
<dom> [31]WAP Push in wikipedia
[31]
http://en.wikipedia.org/wiki/Wireless_Application_Protocol#WAP_Push
Jo: This is where mobile is different from classic Web..some things
are no longer bilateral. Push is an example where you have to
through a mediator.
...since mediation is required with Push, it requires extra
administrative actions.
Adam: We have some examples; we should remove the part about MIDP.
Jo: Should we remove "vendor-specific mechanisms"? Is that too
opaque?
Jo: How is WAP push different from a text message?
DKA: WAP push sends a special SMS. Hasn't been popular because the
user experience differs greatly across handsets.
Rob: Yes, the user experience varies.
Jo: Is it worth capturing this point about the user experience
varying?
Ed: Are people still using it?
Rob: Old spec, but people still do use it.
Adam: On to Minimize Application Size
...There is a long part with examples that should be removed.
<DKA> [32]http://www.w3.org/TR/mobile-bp/#MINIMIZE
[32] http://www.w3.org/TR/mobile-bp/#MINIMIZE
...Should we just focus on tokenizing scripts?
Jo: There are ways to increase CSS speed by using selectors in a
different way; use selectors that match the semantic shape of the
document instead of class names.
...the CSS suggestion was by Martin.
...disadvantage is that the stylesheets cannot be shared easily
between documents.
Adam: Suggestion is to remove the stuff about CSS selectors and make
this BP about tokenization of scripts.
Jo: Maybe we put something in that is more bland about using CSS
selectors, but not include the detailed example.
<edm> [33]http://my.opera.com/Andrew%20Gregory/blog/
[33] http://my.opera.com/Andrew%20Gregory/blog/
[Time for lunch; back at 1:15]
<adam> [34]http://docs.google.com/Doc?id=dft77cn8_17dkz5wp8h
[34] http://docs.google.com/Doc?id=dft77cn8_17dkz5wp8h
<edm> scribe: edm
<scribe> scribenick: edm
<DKA> Of interest:
[35]http://www.moconews.net/entry/419-bank-of-america-says-it-has-1-
million-mobile-users-details-other-mobile/
[35]
http://www.moconews.net/entry/419-bank-of-america-says-it-has-1-million-mobile-users-details-other-mobile/
<edm2z> scribe: edm
<edm2z> scribenick: edm2z
adam: back to 4.5.5 Minimize DOM Manipulation
<achuter> Is there some way people can measure if they are doing
this efficiently?
Scott: parsing the javascript to initialize the doc slows things
down...
Jo: practice should be about limiting DOM manipulation required
before initialization of the page
... limit dynamic/scripting portions where possible
adam: we have not measured the cost of dynamic vs. static - need
benchmarks
... may also need new BP to minimize network requests
dka: in general this makes sense
adam: e.g., do not require additional request for JSON packet...
jo: should we discuss progressive rendering - page rendered as
streams?
... all points discussed are really about snappier user experiences
... e.g., contacts as JSON rather than fully-rendered HTML
Scott: this is about more general presentation issues - not just DOM
manipulation
DKA: need to provide immediate feedback and keep user aware of what
is going on - e.g., animation for loading in case of delays
adam: e.g., notification thta your app is coming down ...
Jo: is there anyting in particular to preserve re efficient DOM
manipulation?
dka: who would do some testing?
... if presentation related BPs cover this, we could drop this for
now.
adam: 4.5.6 Minimize External Script Files
... ...could be absorbed into other sections...
... ...e.g., minimize network requests
... topic of minimizing external script files would benefit from
some benchmarking data
... deferred binding of device specific bits seems to be a good idea
Kai: re 4.5.6.2 - question on diminishing efficiency of caching?
adam: need to discuss the benefits of deferred binding vs.
pre-loading
jo: points out the difference between static pages vs. dynamic
applications - re value of caching
adam: 4.5.7 Use Power-Efficient Methods
... ... need some benchmarking data - to show specific cost
Scott: no specific data to offer on this yet
adam: valid point in general - but there are other power efficiency
issues other than usage
Jo: ... leave this as a placeholder for now - need more details and
specific examples of power efficient techniques
... perhpas somebody should draft some specific text for the
placeholder
<scribe> ACTION: Scott to draft text re power efficiency by June 25
[recorded in
[36]http://www.w3.org/2008/06/17-bpwg-minutes.html#action05]
<trackbot> Created ACTION-787 - Draft text re power efficiency by
June 25 [on Scott Hughes - due 2008-06-24].
ISSUE: how to keep the screen alive (re null gestures) - what to
recommend?
<trackbot> Created ISSUE-263 - How to keep the screen alive (re null
gestures) - what to recommend? ; please complete additional details
at [37]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/263/edit .
[37] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/263/edit
<jo> ACTION: Dan to communicate with OpenAjax Alliance about the
backlighting issue and null gestures [recorded in
[38]http://www.w3.org/2008/06/17-bpwg-minutes.html#action06]
<trackbot> Created ACTION-788 - Communicate with OpenAjax Alliance
about the backlighting issue and null gestures [on Daniel Appelquist
- due 2008-06-24].
MWABP - One Web
adam: 4.6 One Web
jo: invites Jonathan and Sunghan to comment on this - in the context
of using application when switching devices
Sunghan: e.g., using mobile web application and switching over
seamleassly to PC at home...
adam: e.g, pushing personalization to the server would enable this
jo: is it worthwhile to design mobile web apps to work across
multiple devices - possibly simultaneously
adam: 4.6.1 may require some rewording to cover support for range of
devices AND simultanueos or serial use across multiple devices
Sunghan: agrees - but need to define specific APIs
kai: does this include switching devices within session?
dka: need to add a specific app and use case example - e.g.,
homepage app
Kai: what is meant by sharing consistent app state (in 4.6.1.1)?
MWABP - Interaction and presentation issues
adam: 4.7 Presentation Issues - still a placeholder, but some
specific examples were discussed earlier
... may need to cut dowm the preamble and add details
<rob> Scribe: rob
scribenice: rob
<scribe> scribenick: rob
<DKA> Apple guidelines:
[39]http://developer.apple.com/webapps/designingcontent.php
(specifically "Optimize for Page Readability").
[39] http://developer.apple.com/webapps/designingcontent.php
<Zakim> DKA, you wanted to gush about iPhone
dka: since we're discussing presentation issues, i've an action for
recs gleaned on this Apple doc
... some may be only appliccable to iPhone browsers but may be more
widely appliccable if say Android's webkit browser also follows suit
scott: you've got the browser that browses the whole web
but built-in a bunch of commands that allow iPhone-aware apps to
control the viewport and zoom in/out
adam: is it pure Apple-only?
scott: think it's Apple-only but would be interesting to see when it
came into Safari
... lots of things are handled automatically, the controls mostly
disable inappropriate automatic actions for your iPhone app
... Not sure if Apple are submitting those viewport controls
anywhere for others to use.
jo: so what are the generalisable good practices?
dka: there's not much, but I've transferred the action to Scott!
... interesting info about a finger being 44x44px
Scott: you do make different assumptions for focus-based /
pointer-based / touch-based devices
adam: continuing on 4.7.1
... just noting about touch-based devices
... what about WTAI links for making phone calls?
Scott: back to 3 different interfaces:
... 1) focus-based is moving over controls
... 2) pointer-based is moving a cursor around a screen, a bit like
a mouse but probably with a joystick or D-pad
... 3) touch-based is with a touch-screen and stylus or finger
... so in 2 and 3 it's essential to know what parts of the screen
are "clickable"
... Both focus-based and touch-based you can move about a page very
rapidly
... wheras pointer-based interfaces can be quite slow if you have to
move from side-to-side of the screen a lot
dka: eg controls at the top and bottom of the screen where you have
to use both a lot
scott: and you might deliberately do that with a touch-screen to
avoid chance of pressing wrong button by accident
... there are some valuable BP1s that are relevant
... but these 3 input-modes have a huge effect building apps.
jo: we need Scott to add more text around this
<jo> ACTION: Scott to propose text for different interaction modes
in discussion with Adam [recorded in
[40]http://www.w3.org/2008/06/17-bpwg-minutes.html#action07]
<trackbot> Created ACTION-789 - Propose text for different
interaction modes in discussion with Adam [on Scott Hughes - due
2008-06-24].
adam: and after that we might change the heading to reflect the
content
Scott: already discussed helping users to see what's changed in a
page (eg "yellow-fade technique")
... that works well for text and if you need to change the view in
response to an update, sliding the content in helps orientating the
user
... You need to understand which bits of the page are visible to
avoid wasting CPU on invisible changes.
... One of the top-level reasons to do this is to speed up the
apparent responsiveness of the user experience -
... providing immediate feedback (eg animation) while waiting for
information
jo: it's making more small things happen instead of just
click-wait-read
adam: recants these ideas in section 4.7
Scott: About text-entry, many browsers won't allow you to see labels
around a textbox while you enter text in it.
dom: the inputmode attribute is defined on <input> to tell the
browser what type of input you are expecting
jo: it's particularly interested in predictive text
Scott: Consider impact of CPU on the interface. You don't want jerky
motion.
... This will vary a lot between devices.
adam: I'll leave a placeholder here for Scott's contribution.
... Another potential BP: enabling the browser history by updating
the URL with #viewname
... this also allows the user to bookmark a view within the page
jo: how common is this?
adam: Google uses it all the time
jo: solves a problem, so it's a useful BP
<francois> Scribe: francois
<scribe> ScribeNick: francois
[end of break]
MWABP - Handling device capability variation
Adam: On handling device capability variation (4.9)
jo: what do we want to say here?
... 1. determine whether the device supports scripting at all
... 2. determine the level of script support
... The first think may be statistically determined through a DDR,
whereas the second may not be.
Scott: from our perspective, we test each possible device to see if
our application works
adam: there's device capability and device compliance
... Initial intent was more: if the device exposes Javascript in
some way, what can be done?
... There's a very standard pattern listed in the doc to detect
whether a feature/object is supported
jo: the static detection, the dynamic detection, and to what extent
you may design your application to use the dynamic detection
scott: dynamic may be useful for cases where you only want to update
the behavior of an application, but where it's not entirely required
scott: So we can use profiles of Javascript support, and dynamic
detection within each profile
<Zakim> Kai, you wanted to ask about script interpretation /
compatibility
<inserted> Following is a message from Heiko connecting remotely to
the IRC channel
<hgerlach> I think since I just have 1 item (action 761) and
regarding the allowlist to allow CT engine to setup a Desktop
useragent we can discuss this either next Tuesday or you could gimme
a call when you like to discuss it. So I won't need to join all time
long.
Kai: are we confident that the interpretation of Javascript is
standardized enough to tell that dynamic detection will be enough?
adam: probably not.
... should we be referencing the DDWG work?
jo: excellent idea, indeed
dka: we should make it clear it's not the only way. There's also
WURFL and proprietary means to do such things
<hgerlach> ok,
adam: there's also the question of Gears for example, where you
actually install something on a browser that doesn't have the
capability at first
jo: are we through enough on this before we move on?
adam: I'd prefer to craft some text around this, and see the result
SeanP: There's another document we could reference: the Content
Transformation guidelines with the X-Device header.
There could be a content transformation proxy between the origin
server and the client
scribe: It's thus possible that the Javascript is not executed
jo: Can we put a placeholder in whatever text you'll be crafting on
the role of CT proxies
adam: ok
... 4.9.3 Device Classification to simplify content
selection/adaptation
jo: I think it qualifies as a best practice. It's about telling
people that they don't have to do an instance by instance
implementation
... that they may use classification
Kai: it's not an easy issue
... not easy to classify devices.
jo: I agree, but depending on the features required by your
application, you need to classify accordingly: if your application
uses location, then you want to know the devices that support such
feature
Rotan: I think an attempt to create a global way to classify devices
is just a complete waste of resources
jo: we need a placeholder in there IMO to reference DD Structures
rotan: imagine an ad company that provides banners. They need to
provide the structures that are used to categorize the capabilities
of the devices that may display each device.
... The whole intent is to have structures that may be passed across
different organizations.
... hey, wait a minute, I just spot "the" DDR on screen in the doc.
I think it's dangerous, because it gives the impression that there
is only one global DDR, which is just plain wrong.
adam: OK, I'll change that to "a" DDR.
... About alternative to client-side scripting
jo: I think this fits in the "One Web" section
... it seems to me that people whether the application they develop
requires a non-javascript implementation
... We should be aware that the Accessibility and I18n folks may
have things to say about Javascript use in Web Applications.
adam: It seems to me that a Javascript application is not always
less accessible for instance
jo: that's true, but Flash for instance is often cited as not
accessible-friendly
rotan: the ability to deliver an application that doesn't rely on
Javascript may be connected to the device capability AND the user's
capability.
... so far, a DDR only talks about device capabilities, but may
include users capability in the future
achuter: the accessibility of javascript. Generally it's accessible,
but it usually depends on the assistive technology available on the
device.
... I'm not sure there is an accessibility API for mobile devices
[thunders]
jo: it seems to me that we could probably do with some draft around
that point if you could take care of that
<scribe> ACTION: alan chuter to produce some text around
accessibility of Javascript for Web Application Best Practices
[recorded in
[41]http://www.w3.org/2008/06/17-bpwg-minutes.html#action08]
<trackbot> Sorry, amibiguous username (more than one match) - alan
<trackbot> Try using a different identifier, such as family name or
username (eg. achuter, atai)
<scribe> ACTION: chuter to produce some text around accessibility of
Javascript for Web Application Best Practices [recorded in
[42]http://www.w3.org/2008/06/17-bpwg-minutes.html#action09]
<trackbot> Created ACTION-790 - Produce some text around
accessibility of Javascript for Web Application Best Practices [on
Alan Chuter - due 2008-06-24].
kai: should we emphasize the point even more?
jo: let's see what comes out of the draft when it's updated
... Anything else on 4.9.4?
adam: there's a section on progressive enhancement, which looks very
cool
... but I'm not so sure it's a good idea. I wonder whether it's not
too low-level to be a BP.
DKA: Someone presented on this at Over The Air. I wondered if it can
be reduced to something more BP-friendly
jo: yes, a big blob of html and javascript is probably not clear
enough
... I suggest we raise an issue on this
ISSUE: How to rephrase progressive enhancement to make it fit as a
BP?
<trackbot> Created ISSUE-264 - How to rephrase progressive
enhancement to make it fit as a BP? ; please complete additional
details at
[43]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/264/edit .
[43] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/264/edit
adam: 4.11, I think we agreed to move to the Scope section
jo: problem with 4.10, not clear what purpose it serves as we don't
have any specific BP related to it. I suggest we move it to
somewhere else
scott: GPRS, UMTS, Wifi... It's a nice idea, but in practice we
don't do it
... there are other things you need to consider before we move to
this point
jo: some of it may be moved to minimize use of network typically
<Zakim> abel, you wanted to add a comment related to section 4.9.5
(that i think we have skipped)
abel: about 4.9.5, I wonder if we could mention SVG. It's widely
deployed in the mobile industry today. I have an example of a
statistics chart that degrades gracefully based on the capabilities
of the device.
jo: very good point.
dka: If we do that, then we should also reference WICD, because it
was built with mobile web applications in mind
... The problem of course is that it's not implemented in any
browser today.
... I agree to take an action to draft some text
<jo> ACTION: dan to draft some text on WICD [recorded in
[44]http://www.w3.org/2008/06/17-bpwg-minutes.html#action10]
<trackbot> Created ACTION-791 - Draft some text on WICD [on Daniel
Appelquist - due 2008-06-24].
[abel projects some statistics chart demonstrating the use of SVG on
desktop and mobile browsers]
abel: first of all, this chart uses SVG FULL, with animations and
the like.
... second version, the same chart for an E61: you still have
animations. The links are made by means of XLink.
... and then the same example, where animations were removed.
... and eventually, if SVG is not supported, you may want to display
a table for instance
... The idea would be to complete the practice we have to degrade
Javascript apply to SVG.
DKA: you mean figure out what level of SVG the device has? How do
you do that on the client-side?
abel: sometimes via a DDR, but some can be determined by scripting.
DKA: hmmm. Seems like a BP that reads: use SVG when available.
<dom> [charts being demoed:
[45]http://idi.fundacionctic.org/bk/E61/barras.svg]
[45] http://idi.fundacionctic.org/bk/E61/barras.svg
kai: tangential point. To detect device capabilities... If an
application does that again and again, then it suddenly comes with a
cost in terms of processing.
<jo> -> tjamm.mobi svg dublin mobile traffic info
scott: about the Javascript doing the checks: you do that on the
first page, and that's about it.
<jo> s/tjamm.mobi/[46]http://tjamm.mobi/
[46] http://tjamm.mobi/
<abel> desktop version->
[47]http://idi.fundacionctic.org/bk/Desktop/barras.svg
[47] http://idi.fundacionctic.org/bk/Desktop/barras.svg
kai: ok. I was thinking for instance on detecting bandwidth because
you may typically do that using Javascript and sending/receiving
chunks over the network, but that's not something you want people to
do often.
<abel> Nokia e61
version-->[48]http://idi.fundacionctic.org/bk/E61/barras.svg
[48] http://idi.fundacionctic.org/bk/E61/barras.svg
<abel> raster
version-->[49]http://idi.fundacionctic.org/bk/Raster/barras.html
[49] http://idi.fundacionctic.org/bk/Raster/barras.html
jo: thanks abel for the demo.
<scribe> ACTION: abel to propose some text on SVG [recorded in
[50]http://www.w3.org/2008/06/17-bpwg-minutes.html#action11]
<trackbot> Created ACTION-792 - Propose some text on SVG [on Abel
Rionda - due 2008-06-24].
jo: Anything else from anybody else?
scott: I felt there was not much on caching. Maybe it was in BP1.
Even if you have content that changes often, you still have images
that may be cached.
kai: good point. There's something we can do: modification-based
caching which is not commonly done instead of access-based caching.
... With that, you can increase the expiration a lot because all
that matters is the last modification date.
... There's a caveat based on the memory of the device, if you cache
too much.
jo: There is stuff on caching on BP1.
... Again, I'd like to ask for more specific text. I think it's a
good point.
... I would add that we have observed, within Content
Transformation, that HEAD requests often get turned into GET
requests which is not exactly good in terms of caching.
<jo> ACTION: Kai to work with Scott to produce proposed text on
caching that goes beyond BP 1 [recorded in
[51]http://www.w3.org/2008/06/17-bpwg-minutes.html#action12]
<trackbot> Created ACTION-793 - Work with Scott to produce proposed
text on caching that goes beyond BP 1 [on Kai Scheppe - due
2008-06-24].
kai: agree to take an action
jo: anything else?
scott: things often can be done using multiple techniques in
javascript, and you probably want to identify those that are more
widely supported. We've found in general the most simple things are
more likely to work, sometimes to the cost of elegance
adam: my concern is that it could be too presprictive in terms on
how people develop their apps
dka: I know there is a document at OpenAjax which we could probably
reference.
kai: one think that I think is missing is GUI design.
... We have this top-left navigation problem. Should we comment on
what a GUI should look like?
jo: are GUI in mobile world stable enough to comment on that? I
think not.
... I suggest not. But we may put a placeholder to reconsider that
later on.
MWABP - Separating structure, style, and behavior
<JonathanJ>
[52]http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/0053.htm
l
[52] http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/0053.html
<dom> [53]http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn
[53] http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn
ACTION-695?
<trackbot> ACTION-695 -- Jonathan Jeon to extract BP statements from
K MWBP 1.5 document for consideration in BP 2.0 -- due 2008-04-17 --
OPEN
<trackbot>
[54]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/695
[54] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/695
jonathan: my proposal is about ACTION-695 separating structure,
style and behavior
<dom> [model/view/controller pattern]
adam: so this is like an MVC (model view controller) for the mobile?
jo: why don't we raise an issue on this?
<jo> ISSUE: Discussion of Jonathan's Submission ref separation of
structure presentation and behavior at
[55]http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn
[55] http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn
<trackbot> Created ISSUE-265 - Discussion of Jonathan's Submission
ref separation of structure presentation and behavior at
[56]http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn ; please
complete additional details at
[57]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/265/edit .
[56] http://docs.google.com/View?docid=dhpvgnmn_54d7cbhrhn
[57] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/265/edit
<jo> ACTION: Adam to lead off discussion on ISSUE-265 following
completion of next draft BP2 [recorded in
[58]http://www.w3.org/2008/06/17-bpwg-minutes.html#action13]
<trackbot> Created ACTION-794 - Lead off discussion on ISSUE-265
following completion of next draft BP2 [on Adam Connors - due
2008-06-24].
jo: [closing the discussion on BP2]
MWABP - Publication as First Public Working Draft
dom: schedule for publication as FPWD?
adam: once I've updated the doc, by the end of the week hopefully, I
think we should review the doc again, and then see how it goes
jo: I think we should not postpone for too long. What about saying
not to last more than 4 weeks on this?
dom: it would be fairly nice if we could talk about this in the
press release that will come with publication of Best Practices 1.0
as Rec when it's done
adam: I can commit to have a new draft of this for next week,
provided Scott does his actions as well.
jo: I think the reason for postponing the publication was mostly in
regards of the scope, and I think we're clear enough now on that.
DKA: +1
dom: +1
jo: so I don't see why we should postpone that any further once the
document is updated.
... I suggest we do checker now
[some talks on the schedule for the rest of the day and tomorrow's
schedule]
<rob> Scribe: rob
<scribe> scribenick: rob
mobileOK Checker
Miguel: summary of what we've done since beta release
... fixing bugs, completed tests, performance enhancements and test
suite
jo: how complete is test-coverage?
miguel: an example, taking into account media in linked CSS was
missing and added
... so test suite coverage is complete
... Updates to LC happening now: grammar validation and object
conformance
... and of course fixing bugs (from test-suite, Bugzilla and other
testing in the wild)
... Also doing some refactoring and documenting of code and
internationalisation
... Roadmap is Proposed Rec in 3 weeks' time
and Rec a month later
jo: synchronising with the mobileOK Basic Rec would be good?
dom: mid-July is proposed date
<jo> PROPOSED RSOLUTION: Checker 1.0 to be announced July 15 or 16
to coincide with announcement of BP to rec (and mobileOK Basic to
PR?)
<dom> +1 (if possible)
<DKA> +1
RESOLUTION: Checker 1.0 to be announced July 15 or 16 to coincide
with announcement of BP to rec (and mobileOK Basic to PR?)
jo: process is we need a plan showing a go/no-go decision week
before this
... and go/no-go criteria (eg no critical bugs)
... eg all test-suite passed; no issues of checker returning false
positives
... and it's stable (doesn't crash)
<jo> PROPOSED RESOLUTION: BPWG acceptance criterion for Checker is
that the TF asserts that the test suite is complete and that no
false positives or false negatives are known
jo: We don't want a WG plenary to approve this, the go/no-go
decicion should be technical
<jo> PROPOSED RESOLUTION: TF Delegates responsibility for Go/No Go
decision to TF based on acceptance criterion being met and no
show-stopper bugs
<jo> PROPOSED RESOLUTION: BPWG Delegates responsibility for Go/No Go
decision to TF based on acceptance criterion being met and no
show-stopper bugs
<dom> +1
<DKA> +1
<adam> +1
<Kai> +1
RESOLUTION: BPWG acceptance criterion for Checker is that the TF
asserts that the test suite is complete and that no false positives
or false negatives are known
<DKA> yipee!
RESOLUTION: BPWG Delegates responsibility for Go/No Go decision to
TF based on acceptance criterion being met and no show-stopper bugs
<dom> [this I think resolves ISSUE-228]
<dom> ISSUE-228?
<trackbot> ISSUE-228 -- What Criteria for Checker Approval? -- OPEN
<trackbot>
[59]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/228
[59] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/228
jo: how will TF get there by that date? Do you have enough
resources?
... would it help to muster more resources?
dom: yes
jo: Google?
Abel: would help to have more people testing certainly
adam: We personally don't have the time
dom: we'll keep working on this, we don't need specific promises now
... long-term maintenance plan is also needed
jo: yes, will be non-maintenance stuff to be done post-1.0 too
dom: core charter of TF is to get to 1.0
jo: we should at least plan documentation ready with 1.0 so that
others might be able to help post-1.0
Abel: there is documentation and it is being updated
dka: writing to Voda R&D colleagues in Spain for potential help
<dom> ACTION: Dan to see if R&D colleagues from Spain can help for
developing/maintening mobileOK checker [recorded in
[60]http://www.w3.org/2008/06/17-bpwg-minutes.html#action14]
<trackbot> Created ACTION-795 - See if R&D colleagues from Spain can
help for developing/maintening mobileOK checker [on Daniel
Appelquist - due 2008-06-24].
Miguel: we should also think about advertising and publicity
jo: yes, that's the point of synchronisation with mobileOK Basic
Miguel: looking at Bugzilla now, there are two important stylesheet
issues
... Meta refresh bug is a question about following meta refresh
"redirects"
dom: mobileOK doesn't suggest to do this, so should be out-of-scope
for Checker
jo: suggest leave it open as low-priority, may crop up in FAQs
dom: update priority of image/object source bug to critical
jo: documentation and internationalisation aren't required for 1.0 -
they can follow post-1.0
... and there are no accessibility requirements because there is no
user interface!
Summary of Action Items
[NEW] ACTION: abel to propose some text on SVG [recorded in
[61]http://www.w3.org/2008/06/17-bpwg-minutes.html#action11]
[NEW] ACTION: Adam to lead off discussion on ISSUE-265 following
completion of next draft BP2 [recorded in
[62]http://www.w3.org/2008/06/17-bpwg-minutes.html#action13]
[NEW] ACTION: alan chuter to produce some text around accessibility
of Javascript for Web Application Best Practices [recorded in
[63]http://www.w3.org/2008/06/17-bpwg-minutes.html#action08]
[NEW] ACTION: chuter to produce some text around accessibility of
Javascript for Web Application Best Practices [recorded in
[64]http://www.w3.org/2008/06/17-bpwg-minutes.html#action09]
[NEW] ACTION: Dan to come up with alternative phrasing for Web 2.0
[recorded in
[65]http://www.w3.org/2008/06/17-bpwg-minutes.html#action01]
[NEW] ACTION: Dan to communicate with OpenAjax Alliance about the
backlighting issue and null gestures [recorded in
[66]http://www.w3.org/2008/06/17-bpwg-minutes.html#action06]
[NEW] ACTION: dan to draft some text on WICD [recorded in
[67]http://www.w3.org/2008/06/17-bpwg-minutes.html#action10]
[NEW] ACTION: Dan to see if R&D colleagues from Spain can help for
developing/maintening mobileOK checker [recorded in
[68]http://www.w3.org/2008/06/17-bpwg-minutes.html#action14]
[NEW] ACTION: Jo to draft wording for an appendix that identifies
the aggregators and operator roles that are different in the mobile
ecosystem. [recorded in
[69]http://www.w3.org/2008/06/17-bpwg-minutes.html#action04]
[NEW] ACTION: Kai to check the personalization section for specific
parts that seem to imply combination of personal information with
usage patterns [recorded in
[70]http://www.w3.org/2008/06/17-bpwg-minutes.html#action03]
[NEW] ACTION: Kai to review 4.1 Personalization with privacy
regulations in mind [recorded in
[71]http://www.w3.org/2008/06/17-bpwg-minutes.html#action02]
[NEW] ACTION: Kai to work with Scott to produce proposed text on
caching that goes beyond BP 1 [recorded in
[72]http://www.w3.org/2008/06/17-bpwg-minutes.html#action12]
[NEW] ACTION: Scott to draft text re power efficiency by June 25
[recorded in
[73]http://www.w3.org/2008/06/17-bpwg-minutes.html#action05]
[NEW] ACTION: Scott to propose text for different interaction modes
in discussion with Adam [recorded in
[74]http://www.w3.org/2008/06/17-bpwg-minutes.html#action07]
[End of minutes]
Received on Wednesday, 18 June 2008 07:00:26 UTC