See also: IRC log
The group addressed the list of last call comments on Mobile Web Application Best Practices. Changes brought to the document are non-substantive and the group expects to request transition to Candidate Recommendation once the Last Call reviewers have agreed with the group's replies to their comments.
<DKA> http://lists.w3.org/Archives/Public/public-bpwg/2009Dec/0001.html
DKA: Today we are trying to get
MWABP out the door - if we can't get agreement, we can drop
stuff. Our mantra for today is Art Bartsow's ICLWI test - "I
can live with it"
... (Art is my life guru. I say "what would Barstow do?")
JR: That explains a lot.
<francois> List of last call comments on MWABP
RESOLUTION: Editorial, accepted.
LC-2265 - Why should this be a Recommendation
CMN: The question is really how to show that people do these things. The answer is, show that each Best Practice is implemented.
DKA: There are previous examples of guidelines going to Rec, and we plan to follow that pattern
JR: Exit criteria weren't that implementations did everything, but that everything was used.
Adam: Exit Criteria will matter
DKA: can we note our sincere thanks to Art?
RESOLUTION: We will follow the precedent set by various Recommendations which are guidelines, and have Exit Criteria which shows that each Best Practice is implemented and therefore implementable. Hugs and Kisses from Dan
<jeffs> +1
<DKA> +1
LC-2271 - cookies as a mobile-specific issue?
<DKA> http://lists.w3.org/Archives/Public/public-bpwg/2009Nov/0018.html
<jeffs> IMHO the cookies issue is particularly important in a mobile context as location and other personal information may be available & thus privacy issues come to the fore
CMN: The best practice points out that the issue here is that it increases data being shipped, a known problem for mobile in particular (battery life)
Adam: And it is a known issue that Mobile Operators may interfere
Proposed RESOLUTION: We disagree, following Adam. Note that privacy issues are considered out of scope.
DKA: disagree with the comment
Adam: Not that we disagree, but that there is no action required. There are two parts - one is the lack of privacy section (which we have deliberately not addressed)
FD: We disagree with the claim that there is no mobile-specific aspect to cookies
<jeffs> +1
<francois> [For clarity, I suggest adding a note that privacy issues are out of scope somewhere in the Scope section]
Proposed RESOLUTION: We disagree with the claim that there is no mobile-specific aspect to cookies (the shifting of data is mobile-specific). We also note that privacy issues are considered out of Scope - and will add a note to that effect.
<jeffs> +1
<DKA> +1
RESOLUTION: We disagree with the claim that there is no mobile-specific aspect to cookies (the shifting of data is mobile-specific). We also note that privacy issues are considered out of Scope - and will add a note to that effect.
<jeffs> +1
LC-2272 - BONDI, Widgets and alternative references
LC-2292 (likewise)
CMN: This is editorial - it is about what we use as examples
Proposed Resolution: Editorial. We can look for more specific references...
<jeffs> what about the point in LC-2272: 'The second point of "making updates locally at first" should be supplemented with a need to add UI treatment to make it clear to the user that their data is uncommitted.'??
JR: Can we add some explanation that these are current things at the time of writing, with some references to groups who will do more?
FD: Group will be DAP - they have lots of specs, storage is just one of them
CMN: Note that Web Apps also has some local storage specs (database stuff, minimal fileAPI...)
<Jo> PROPOSED RESOLUTION: Add text to 3.1.2.1. stating that work is in progress to unify these apis and to see the work of WebApps and Device API WGs
<jeffs> +1
FileSystem in DAP is read/write, and IMHO is a form of local storage
<DKA> +1
<darobin> RB: I don't think that DAP really has any storage spec (not in the usually understood sense anyway), unless you count File System or being able to expose how much disk space there is — most storage is WebApps
<darobin> yes, it is, and we might do localFS — but that's not what people generally mean by "the storage specs
<darobin> "
RESOLUTION: Add text to 3.1.2.1. stating that work is in progress to unify these apis and pointing to the work of WebApps and Device API WGs
Adam: If you have local data that is not committed to the server, should it have some UI treatment saying it is on the way to the server?
JR: We have said various things about indicating what is going on, and for the sake of battery life I don't think we should be making a recommendation on this
<Jo> PROPOSED RESOLUTION: On LC-2272 resolve no, we think we make sufficient comment about progress indications elsewhere
<DKA> +1
<adam> +1
<jeffs> +1
<francois> +1
RESOLUTION: On LC-2272 resolve no, we thing we make sufficient comment about progress indications
CMN: Not clear what the action required might be
<jeffs> the point is "don't trust"
DKA: The wording "10x" isn't good...
Proposed RESOLUTION: Editorial, but we will remove the "10x"
<jeffs> suggest replace "are approximately x10 slower" with "are known to be significantly slower"
<Jo> may be considerably slower (or faster)
Proposed RESOLUTION: Editorial, but we will remove the "10x" and say "considerably"
CMN: Jeff's point that this is untrusted data seems more like the rationale.
<jeffs> want to push that the point is "don't trust"
DKA: Should we note the availability of native JSON parsers as a device capability we should be calling out?
JR: Not sure. Native support isn't necessarily faster
<jeffs> just because there is a native JSON parser doesn't mean it is safer, either
[we are in recess, as we move to a new room]
<francois> Scribe: francois
CMN: Starting again with LC-2293
jeffs: What's in the section is "don't trust incoming JSON data".
adam: that's why we say use JSON
parsers which should be protected against that, as opposed
eval.
... I think Robin's point has more to do with the efficiency
point. With a native JSON parsing, the x10 slower performance
is not true anymore.
jeffs: I just want to make sure
we do say "don't trust JSON stuff", do it on the client
side.
... We must make sure that the message reads that the client
must deal with JSON strings as if they were containing evil
code.
adam: The initial point was more to do with performance. Trust appears afterwards. This is a compromise which I think is good.
jeffs: I can live with that, but...
DKA: That's it, you said the magic words.
jeffs: I just want to make sure we don't undermine evil possibilities with JSON exchanges.
<darobin> my point was more about security than performance: native JSON parsing is faster than eval but will still be slow on large JSON, but you're not using eval and so it's a lot safer
DKA: is there any way we can strengthen the wording or do you think what we have is enough?
jeffs: It's about trading security for performance.
adam: I think we already have
some careful wording that is strong about security
issues.
... We just need to correct the part that says that JSON
parsing is necessarily slow, in agreement with Robin's
comment.
<jeffs> +1
<darobin> +1
PROPOSED RESOLUTION: Re. LC-2293, resolve yes and remove the parenthetical comment on performance issues with JSON parsers
<adam2> +1
+1
<DKA> +1
RESOLUTION: Re. LC-2293, resolve yes and remove the parenthetical comment on performance issues with JSON parser
-> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2294 LC-2294
adam: ref. the bullet points, I think they are just examples, and fine as they stand.
<jeffs> +1 to adam's comment
francois: there's a more generic
thing here about implementers vs. authors.
... The section is for authors but these UI notifications are
(to be) handled by the browser.
dka: OK, let's address these issues separately and go back to the first point in LC-2293
CMN: most points in 3.3 should be
left to the browser.
... You should only do these things when you know that the
browser does not adequately alert the user.
DKA: If through testing you determine that the user cannot tell what's happening behind the scene, you need to do it yourself.
<jeffs> I would recommend the reverse... assume you cannot trust unless you know the browser takes care of it
adam: 3.3.1.2 should alert about not replicating the functionality.
<jeffs> what item are we on pls? 3.2.1 LC-2293 or beyond?
CMN: The thing is we do expect the browser to do these things. We can expect some browsers to do it wrong. Only in that later case should this be handled at the application level.
adam: We have some similar wording in 3.3.3.2.
CMN: I suggest wording in 3.3.3.2 be moved to description text in 3.3
adam: I don't feel strongly about
any thing here. I just don't want to make changes that are not
really needed.
... I think the BPs cover what you do at the application level,
with a relatively correct browser.
<jeffs> again, I would comment that one should inform the user *unless* one is sure that the browser is doing so
<Jo> PROPOSED RESOLUTION: ref LC-2293 resolve no, it's made clear under 3.3.3.2 that applications should not duplicate native fundtionality but should be prepared to warn in the admittedly rare case that the browser doesn't solicit permission
<jeffs> scratch "admittedly rare"
jeffs: I just don't want us to say "browsers are cool"
<chaals> [agree with Jeff]
<Jo> PROPOSED RESOLUTION: ref LC-2293 resolve no, it's made clear under 3.3.3.2 that applications should not duplicate native fundtionality but should be prepared to warn in the probably
jo: The problem with that philosophy is as often that we have no data, we just don't know what browsers do good or bad.
<Jo> rare case that the browser doesn't solicit permission
jeffs: I think my point is that it should be at the application level that authors handle all these points.
jo: We're not proposing any
change to the document here.
... I changed "admittedly rare" to "probably rare".
jeffs: we should not do that kind
of statement.
... I don't want to tell users that they can just trust the
browser and let go of any warning.
<Zakim> francois, you wanted to say that we do trust browsers to have some kind of same-origin policy.
<DKA> +1 to proposed resolution - and to keeping jeffs's suggested mindset in our back pocket - maybe this is a high level positioning statement we can make?
<DKA> (and in the mean time let's move on)
<jeffs> +1 to "high level positioning statement"... authors should *not* default to trust
<adam2> +1
francois: we already put a lot of trust on browsers, e.g. that they implement some kind of same-origin policy. I don't quite see the point in commenting they are secure or insecure.
<jeffs> agree
<chaals> [ICLWI now]
DKA: let's agree with the proposed resolution and come back to it later if we think it's needed.
PROPOSED RESOLUTION: ref LC-2293 resolve no, it's made clear under 3.3.3.2 that applications should not duplicate native functionality.
<jeffs> +1
<adam2> +1
<DKA> +1
<achuter> +1
RESOLUTION: ref LC-2293 resolve no, it's made clear under 3.3.3.2 that applications should not duplicate native functionality.
<adam2> Response on public-bpwg: "I'd be concerned this would just complicate things -- you'd then wonder whether you had to produce a different variant of your application for different browsers, which we know no-one will ever really do for this kind of thing... (or at least, I wouldn't). I hope the phrasing "an icon is usually sufficient" is suitably relaxed that no-one will take this as a strong recommendation to implement features that might not be necessary in some
<adam2> So I suggest we resolve no.
[I'm not sure that's a "resolve no", as this is already mentioned in 3.3.3.2]
PROPOSED RESOLUTION: ref LC-2275, resolve no as this would complicate things for authors who would then have to maintain different variants of their applications for different browsers.
<adam2> +1
<jeffs> +1
+1
RESOLUTION: ref LC-2275, resolve no as this would complicate things for authors who would then have to maintain different variants of their applications for different browsers.
<jeffs> agree w fixing spelling
<jeffs> disagree with not contrasting
<jeffs> issue is one of using dynamic graphics & how to differentiate between when SVG is appropriate & when Canvas is appropriate
adam: The latest version already contains changes that address parts of the comment.
CMN: do we mean "use one vs the other" or use one or the other depending on your needs?
adam: This was more to emphasis the existence of these technologies.
CMN: SVG is more implemented in mobile devices. Canvas is not really. Anyway, as written, it's not a bet practice, it's rather an interesting thing about the universe.
<jeffs> IMHO the critical issue is to use SVG if you need access to the DOM & want to make things accessible
jo: I don't think we have anything to say on that topic, having gone through that discussion 6 times now.
phila: dropping that section would be substantive, meaning another last call is needed.
<jeffs> I would oppose dropping this section
francois: I was in favor of removing the section before publication. I still think it should be removed, and agree with Phil that means another Last Call.
<jeffs> canvas is not accessible, SVG is. canvas does not admit to DOM manipulation, SVG does. authors need to know this
jeffs: We need to make a statement on what I just typed on IRC.
<chaals> [I think the value of this is using canvas/SVG rather than other technologies for interactive graphics, but not sure what the value of the rest is although I don't mind leaving in some simple waffle about the differences]
jeffs: By stating this, we'll just help authors to make a choice between two technologies.
adam: I agree with jeffs here.
CMN: yes, but that's really not a best practice, just a series of facts about SVG and Canvas.
<darobin> I think that the only thing that can be usefully said within the scope of this specification is that they are complementary technologies, that authors should consider their relative merits before committing to one, and should be careful with canvas's accessibility issues
CMN: The value I see in this is to use SVG/Canvas instead of Silverlight, Flash, or Shockwave or any other proprietary technology.
jeffs: the value for me is more to help users making a choice between two technologies.
<darobin> "Don't use proprietary technology" is a good BP :)
DKA: could we say both in the section? Use natively supported graphics, and highlight the differences between SVG and Canvas.
<darobin> the problem you're up against is that it's rather difficult to recommend when to use which. At the extremes it's clear, but there are plenty of situations in the middle where you could use either
DKA: If you need scalable, use one of Canvas/SVG.
<jeffs> accessability and DOM access are 2 clear issues
adam: We've tried it, but it's actually not a best practice, it adds loads of Javascript to your application.
<darobin> if you need accessibility, or indexing of content by search engines, you're in SVG land
<darobin> at the game-like end of the spectrum, you're where canvas shines
CMN: I don't see how we can build consensus here in a short time. I would be in favor of dropping this section and put a note about it.
<jeffs> I would oppose dropping this section
jo: I think the accessibility
point is somewhat moot, given that the document is about
exploiting device capabilities.
... The best practice would be "provide an accessible
alternative".
DKA: I'm reluctant to drop things
from the document that are useful to readers.
... Could we take that out of the BP list and put it in some
"things you should be aware of if you're a mobile developer"
section?
<DKA> PROPOSED RESOLUTION: take the BP on SVG and canvas usage and make it even more informative in some way - so demote it from being a BP.
DKA: my proposal would address the points raised by everyone around the table.
Phil: What are the other BPs that you would then demote?
adam: all of the BPS could then be demoted ;)
<jeffs> I agree w Adam, it would be silly to pick this one out to "demote"
<jeffs> real developers will increasingly need to decide whether to use one or the other, we need to give them advice
DKA: I think we're in a position where chaals opposes the BP if it stays in and jeffs opposes the demotion of the BP.
<jeffs> "consider whether to use..."
CMN: following your resolution
would be a good thing. I think 3.5.9 and 3.5.10 are the only
BPs that are candidate to be demoted in my view.
... because they are not actionable.
<jeffs> DKA "the best practice to follow when making this decision is" is a position which makes sense to me
Phil: I would add section 3.7 Further considerations with current sections 3.5.9 and 3.5.10.
<DKA> PROPOSED RESOLUTION: move 3.5.10 and 3.5.9 to a "further considerations" section.
<jeffs> real developers in the real world will increasingly need to deal with dynamic graphics issues in their work
<adam2> I would prefer to leave as is, but I'm happy to move 3.5.10 and 3.5.9 into "Further Considerations" section.
<adam2> +1
<jeffs> I can live with that
<DKA> "I can live with it."
CMN: all things considered, 3.5.9 could become "Use mobile specific technologies" and could be actionable.
<DKA> PROPOSED RESOLUTION: move 3.5.10 to a "further considerations" section.
DKA: OK, let's restrict ourselves to 3.5.10 at this point.
+1
<DKA> +1
<DKA> RESOLUTION: move 3.5.10 to a "further considerations" section.
<adam2> +1
<jeffs> +1
<achuter> +1
RESOLUTION: move 3.5.10 to a "further considerations" section.
<DKA> RESOLUTION: "resolve yes" on LC-2299.
<phila> scribe: PhilA
<scribe> scribeNick:Phila
<jeffs> no, we did *not* resolve "yes" on all of LC-2299
<jeffs> LC-2299 says "don't try to contrast them", & that is the whole fscking *point*
3.5.9 is unaffected by this btw - it stays where it is
CMN: It seems that 2259 suggests taking 3.5.10 should be removed but doesn't actually say this explicitly
<jeffs> LC-2299 says "In most cases Canvas is faster" and this is an empirical question & may not be true in all cases
FD: So Jeffs are you saying we should resolve no? or partial?
Jeffs: We resolved to move the
section to a new further consideration section. LC2299 says we
mean element not tag, there are other bits. We shouldn't agree
with the statement that in most cases canvas is faster
... the 2nd one I disagree with is where the comment says it's
flaky and wrong
<francois> [The note on "in most cases Canvas is faster" was taken from the draft, FWIW]
Jeffs: I think that contrasting these isthe whole point of thisBP
FD: Text says "if speed is important..."
CMN: Which slants towards using canvas
Adam: I agree that we're resolving partial
Jeffs: I think we've only resolved a part of what's in LC2299
FD: Can we stick to factual
things about SVG nad canvas?
... the facts are that canvas is not accessible and SVG
is
... SVG you can access and manipulate the DOM and with canvas
you can't
... speed is not a hard fact
Adam: In some browsers you can empirically measure the greater speed of canvas
jeffs: I agree that we should only be adressing the 2 key facts and not speed
jeffs: if you want to change canvas you ave to redraw the whole thing which isn't true in SVG
Adam: I would be sorry to see this go as I find it useful information
CMN: I can live with removing as much as you want to remove
Jeffs: I can live with a speed part being in although it shouldn't
Adam: We're just talking about
moving the text as is and putting it into a new section
... The wording has been softened since the version you're
working with Jeff
<DKA> PROPOSED RESOLUTION: on the matter of LC-2299, we resolve partial actually. We will not make any change to the wording though the BP has moved to "further consideration" section.
<DKA> +1
<jeffs> +1
<adam2> +1
RESOLUTION: on the matter of LC-2299, we resolve partial actually. We will not make any further change to the wording though the BP has moved to "further consideration" section.
<adam2> Note, we did change the wording somewhat since LC-2299 and addressed the typo issues.
<jeffs> +1
<adam2> +1
short break
<DKA> (and Alan)
<DKA> PROPOSED RESOLUTION: rename the document to "Great Practices for Cool Mobile WebApps"
LC-2275
LC-2276
LC-2294
LC-2295
LC-2296
<jeffs> tnx
Adam: I think it's the same as one we've already resolved no to.
<DKA> PROPOSED RESOLUTION: LC-2295 identical to LC-2275 so it's the same.
<DKA> +1
Jo: So let's resolve that it's identical to 2275 (no)
<DKA> PROPOSED RESOLUTION: LC-2295 identical to LC-2275 so it's the same response (resolved no).
<jeffs> +1
<DKA> +1
Adam: I'm confused about 2276 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2276
<DKA> LC-2276
CMN: This throws up the worm 'What do you do to provide an option'
Adam: I think we can just change the word Must to Should
CMN: And the doc isn't normative so that's OK
<DKA> PROPOSED RESOLUTION: Change must to should in 3.3.2.2
<achuter> +1
RESOLUTION: Change must to should in 3.3.2.2
<jeffs> +1
<DKA> LC-2296
CMN: n to 2296 http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2296
Adam: I agree its a bit dubious
FD: Maybe we should add a note at the top of the doc to say that the BPs are on top of what is available in the browser
CMN: Something like 'some of this functionality is already covered by browsers. App developers should be aware of what the browser does already and complement, not duplicate it.'
<jeffs> "developers should take care to avoid duplicating browser functionality"??
<chaals> Proposed RESOLUTION: Add to section 3.3 intro: "Note that where these functionalities are provided by the browser, that is sufficient, and better than the application providing them"
<jeffs> +1
Adam: I don't think that these BPs are there to replace anything in the browser. I think it would be ad to try and compensate for any and all browser deficiencies. It should ensure that the relevant info is provided for the user
CMN: You can say that 'if these BPs are achieved by the browser already then your job is done.'
FD: It's really about providing info cf. privacy issues
Jo: I'm not sure about that
... it's probably a good thing for the app to say 'if you say
not to any of these things then the app may not work'
<jeffs> "while developers should take care to avoid duplication of browser functionality in this area, they should also ensure users are informed"??
<DKA> +1 to jeffs's suggestion.
<francois> +1 to jeff's suggestion
Alan: There's a thing about
browsers being able to change a stylesheet to change the font
size and yet there are loads of sites that provide buttons to
do this in the page
... so you could get to the situation where people didn't know
where to look for alerts on the page (because they haven't got
used to seeing where it is made clear in the browser)
CMN: I'm happy with Jeff's suggestion as well
DKA: I take your point, Alan but I don't think Jeff's suggestion tells developers ... anything
<adam2> Note that application behaviour should be complimentary to and in addition to native browser functionality. Developers should ensure users are informed whilst avoiding duplication of default browser functionality."
<Jo> PROPSOED RESOLUTION: Add to 3.3 the into text: Where ossible rely on the browser's native functionality to implement the confirming featues described in this section
<adam2> +1
<DKA> +1
<francois> +1
<jeffs> +1
RESOLUTION: Add to 3.3 the into text: Where possible rely on the browser's native functionality to implement the confirming featues described in this section
<Jo> (modulo correction of typos)
<jeffs> ♡♡♡♡♡♡♡
LC 2296 - we agree. The new intro to 3.3 should cover this (also LC 2276, 2295, 2275, 2294 ...)
RESOLUTION: LC-2296 resolved yes. See new intro to section 3.3
<DKA> ❀
Adam: What about the 'dubious' bit of 2296?
Further to the resolution to agree 'yes' we should remove the references to the help pages
When you allow persistent authentication you must provide a way to turn it off
CMN: I agree
Adam: I don't disagree
... I fee it's talking about security etc which is out of
scope
CMN: No, it's about about being
always signed in if you can't sign out on mobile
... The rationale being for when you lose your phone
Adam: if you provide a sign in you should provide a sign out. What this comment's about is when you store a secure token you should set up a way to revoke the token from the server
<jeffs> the "change/invalidation of password" idea makes a lot of sense to me
FD: I think the comment is
already addressed by the text
... but I agree with Charles
<Jo> PROPOSED RESOLUTION: Add to 3.3.4.2 "Provide the user with the ability to sign out using both the device that automatic sign on is enabled on and on other devices to that automatic sign on tokens are revoked.
CMN: What it should say is that it should be revokable (a new workd AFAIK)
FD: It is a BP to say you should provide a sign out if you do a sign in
Jo: points to his earlier comment
<Jo> PROPOSED RESOLUTION: Add to 3.3.4.2 "Provide the user with the ability to sign out using both the device that automatic sign on is enabled on and on other devices so that automatic sign on tokens are revoked."
Adam: Do we also want to change the text to say that the token should be revokable
<jeffs> "Provide the user with the ability to sign out, using either the device that automatic sign on is enabled on or other devices which result in tokens being revoked."??
Jo: My point is that if we put it in How to Do it it's a less substantive change (thank what it means)
DKA: Can you live with it?
CMN: Deep sigh
FD: Isn't the substantive point a bit moot since we've already made a substantive change (moving a section)
Jo: we changed the emphasis
CMN: This is also a change in emphasis
Adam: If you provide a sign in
link you must provide a sign out option (actually if you're
signed in there's a sign out)
... I'd say if you have automatic sign in then your app should
have a sign out link
CMN: This is a clarification, not a substantive change
<jeffs> what about the issue of revocation via other devices? the "may be stolen" use-case makes sense for the mobile context
PhilA: I have amphorae full of aphoristic emphasis
<jeffs> what about the issue of revocation via other devices? the "may be stolen" use-case makes sense for the mobile context
<chaals> Proposed RESOLUTION: We agree with the comment, and have edited the how to do it to match the server case. Adam will also clarify the "option" in the what it means to ensure it is clear that it also allows sign out / not automatically signing in.
Adam: On Jeff's point - I think
that's covered by the text already
... I think that text has been added since the LC comment
Jeffs: I may be working with an old version
RESOLUTION: We agree with the comment, and have edited the how to do it to match the server case. Adam will also clarify the "option" in the what it means to ensure it is clear that it also allows sign out / not automatically signing in
<DKA> +1 to chaals
<jeffs> +1
DKA: This is about EXI. That's in CR?
FD: Yes, as of yesterday
<jeffs> yes, email went out
CMN: At the time of writing GFlate is more widely supported. Robin's saying that there is an actual dis-benefit in compressive small files
<jeffs> very small files do indeed get larger with gzip
CMN: for very small files (< 1K) there is no benefit in compression. And for most media files (audio, video, png, gifs) etc. compression can be counter-producvtive are, at best, a waste of time
<jeffs> warning of this possibility makes sense
CMN: I can't think of a video
format that benefits from cmpression
... SVG is a specific exception since it does benefit from
compression
... Image formats don't benefit from compression - SVG does
<jeffs> already says "Most images (especially JPEGs) do not benefit from compression"
<jeffs> perhaps change "images" to "media files"
<darobin> well if you use a video format that you really shouldn't be using for mobile in the first place it might benefit from compression, but that's daft
<jeffs> perhaps change "images" to "media files"??
chaals types a lot to my right
<darobin> I would also be careful to s/do not benefit from compression/do not benefit from additional compression/
<chaals> Proposed RESOLUTION: Adjust 3.4.1 to note (as per FD) that gzip/DEFLATE are widely supported at time of writing; change images bullet to note that most formats don't benefit from compression but SVG does, add bullet that audio and video formats don't, edit bullet point on small files to note that they generally don't benefit from compression
<darobin> JPEG and friends are already compressed, compressing twice almost always increases the file size
<adam2> +1
<darobin> mentioning EXI would be the nice thing to do
<jeffs> could simply change "images" to "media files"...
CMN: I'd e happy to add EXI as a techn to watch
DKA: Agree
CMN: Where supported, EXI is more efficient than compression
<darobin> re changing to "media file", perhaps yes if there's a <dfn> of it to say it includes images, audio, video
<jeffs> agree
<darobin> EXI can provide better compression with much faster processing and the matching much lower battery consumption
Jo: BP1 was in limbo for 18 months because it mentioned XHTML Basic
CMN: This is not a normative dependency. Where supported, EXI does...
<jeffs> could simply change "images" to "media files (like images, audio, and video)"...
<jeffs> simple is good
CMN: Happy with Jeffs -
... Can we resolve the proposal?
It's getting very editorial
Proposed RESOLUTION: Adjust 3.4.1 to note (as per FD) that gzip/DEFLATE are widely supported at time of writing; change images bullet to note that most formats don't benefit from compression but SVG does, add bullet that audio and video formats don't, edit bullet point on small files to note that they generally don't benefit from compression (or editorially equivalent)
RESOLUTION: Adjust 3.4.1 to note (as per FD) that gzip/DEFLATE are widely supported at time of writing; change images bullet to note that most formats don't benefit from compression but SVG does, add bullet that audio and video formats don't, edit bullet point on small files to note that they generally don't benefit from compression (or editorially equivalent)
<DKA> +1
<jeffs> +1
<adam2> +1
EXI
CMN: Add a note pointing to EXI
PROPOSED RESOLUTION: Include a pointer to EXI
<jeffs> I think Jo's comment about BP1 is a cautionary note to be attended to
<francois> Efficient XML Interchange (EXI) Format 1.0
<Jo> i think that it is too much of a forward looking best practice and may have transition consequences
<jeffs> I'd suggest leaving EXI comment for another version
<darobin> suggesting to look into it is hardly forward looking :)
DKA: Its not a normative dependency, it won't trip us up
CMN: Will anyone object if we leave it out?
<darobin> I would be tempted to
DKA: I won't object but I don't see a reason to leave it ou
<jeffs> no, just a little worried
DKA: Who cannot live with it being in there?
FD: Push mention on EXI into the new Further Considerations?
<chaals> +1
<adam2> -1 (+1 to dka)
DKA: I don't think this should go
into further considerations. It belongs here because we're
talking about compression
... it's just a little informative note saying think about EXI
for the future because it's going to be on your roadmap
FD: Anyone against including EXI
Jo: Me#DKA: Will you formally object?
<jeffs> no, just a little worried
Jo: No
<DKA> PROPOSED RESOLUTION: informative nice note on EXI in compression section.
<jeffs> +1
<adam2> +1
<DKA> +1
RESOLUTION: informative nice note on EXI in compression section.
RESOLUTION: 2278 is editorial and accepted.
<jeffs> +1
<jeffs> no to LC-2279
PROPOSED RESOLUTION "No to LC-2279"
<jeffs> +1
AC: Issue is gone now.
RESOLUTION: "No to LC-2279"
RESOLUTION: 2280 RESOLVED NO.
<jeffs> change "below 10Mb" to "as small as is reasonable"??
AC: LC-2281 have addressed this in new draft.
CMN: use "stored" or "loaded" not "visible"
RESOLUTION: 2281 Agree we have reworded document.
RESOLUTION: 2298 Same issue as 2281.
<jeffs> tricky... what happens when JS processing aimed at deciding what stylesheets to load?
CMN, for third point, point to existing literature on subject of optimising startup time.
<jeffs> agree w CMN
JR: Depends much on what the JS processing is supposed to be doing.
FD: Later we do say to put JS at page end.
PROPOSED RESOLUTION 2282: 3.5.1.1 agree, done, ref is updated; 3.5.1.2 thank you; "...initiate any network requests..." is not a long-term best practice so not accepted, will add pointers to other resources.
<jeffs> +1
<Jo> PROPOSED RESOLUTION 2282: 3.5.1.1 agree, done, ref is updated; 3.5.1.2 thank you; "...initiate any network requests..."depends too much on exactly what the JS is doing so hard to generalize, make reference to BP 3.5.2.2 saying that JS put at bottom of page
<jeffs> +1
<chaals> PROPOSED RESOLUTION 2282: 3.5.1.1 agree, done, ref is updated; 3.5.1.2 thank you; "...initiate any network requests..."depends too much on exactly what the JS is doing so hard to generalize, make reference to BP 3.5.2.2 saying that JS put at bottom of page and to the fact that there is ongoing research in this area.
<adam2> +1
<DKA> +1
<jeffs> +1
+1
RESOLUTION 2282: 3.5.1.1 agree, done, ref is updated; 3.5.1.2 thank you; "...initiate any network requests..."depends too much on exactly what the JS is doing so hard to generalize, make reference to BP 3.5.2.2 saying that JS put at bottom of page and to the fact that there is ongoing research in this area.
<jeffs> +1 already
<jeffs> if memory serves me, this is particularly an issue for blind users... accessibility
PROPOSED RESOLUTION: 2283 Agree to leave as is.
<jeffs> +1
RESOLUTION: 2283 Agree to leave as is.
<DKA> LC-2284
RESOLUTION: 2284 Agree.
<Jo> PRPOSED RESOLUTION: Comment already partly addressed in current ED, in addition remove refcerence to "explicit disallow scaling"
<Jo> PRPOSED RESOLUTION: RE LC-2285 Comment already partly addressed in current ED, in addition remove refcerence to "explicit disallow scaling"
<jeffs> +1
<DKA> +1
<jeffs> should we say "to enhance accessibility, avoid explicitly disallowing scaling up of the page"??
RESOLUTION: RE LC-2285 Comment already partly addressed in current ED, in addition remove refcerence to "explicit disallow scaling"
CMN: Add a second possible configuration, XHTML support or not, with or without touch screen.
JR: Example of Ajax or not, and APIs or not.
CMN: Add a second example.
<DKA> LC-2286
PROPOSED RESOLUTION 2286: Add second example with touch screen.
<jeffs> +1
RESOLUTION LC-2286: Add second example with touch screen.
<Jo> PROPOSED RESOLUTION: Ref LC-2287 resolve yes add text to how to do it sating that <noscript> element should be used appropriately
<jeffs> +1
<adam2> +1
<francois> +1
+1
<chaals> +1
RESOLUTION: Ref LC-2287 resolve yes add text to how to do it sating that <noscript> element should be used appropriately
FD: UA string is to be able to look up device in DDR.
<chaals> Proposed RESOLUTION: s/return a 406 Not Acceptable response along with/return a response with/
<adam2> +1
PROPOSED RESOLUTION 2288: Agree to remove 406 requirement
<adam2> +1
<DKA> +1 "i can live with it"
RESOLUTION LC-2288: Agree to remove 406 requirement
<DKA> LC-2300
RESOLUTION LC-2300: Same issue as LC-2288.
<Jo> PROPSOED RESOLUTION: In re 2266 we agree and will delete the offending non normative words
Jo: proposal for acknowledgement section
<adam2> +1
<DKA> +1
RESOLUTION: In re 2266 we agree and will delete the offending non normative words
RESOLUTION: Editorial, we agree and will change accordingly
RESOLUTION: Editorial, we agree and will change accordingly
FD: The BP is about the security, not about the processing power, so we should resolve no
CMN: The comment isn't important to the substance of the Best Practice
Adam: This is implicit
RESOLUTION: Agree - this is already implicit in the text and we won't change that.
<DKA> +1
<DKA> PROPOSED RESOLUTION: The group requests transition of MWABP to CR.
<DKA> PROPOSED RESOLUTION: The group requests transition of MWABP to CR.
<DKA> PROPOSED RESOLUTION: The group requests transition of MWABP to CR (pending the changes that Adam makes and pending responses from commenters).
<DKA> PROPOSED RESOLUTION: The editorial changes resolved today to MWABP in response to LC comments will not be substantive.
<DKA> PROPOSED RESOLUTION: The editorial changes resolved today to MWABP in response to LC comments aren't "substantive." Therefore we will be requesting transition to CR pending commenters' responses.
<DKA> +1
RESOLUTION: The editorial changes resolved today to MWABP in response to LC comments aren't "substantive." Therefore we will be requesting transition to CR pending commenters' responses.
<scribe> ScribeNick: DKA
PROPOSED RESOLUTION: Exit criteria for MWABP will be similar to MWBP: a report indicating at least 2 implementations of each BP (or something).
<francois> [[ Extract from BP1 CR:
<francois> The Mobile Web Best Practices Working Group expects to request that the Director advance this document to Proposed Recommendation once:
<francois> 1. Sufficient reports of implementation experience have been gathered to demonstrate that the Mobile Web Best Practices are implementable and are interpreted in a consistent manner. To test this, the Working Groups expects to evaluate web content (web sites, pages) that has been created using the Mobile Web Best Practices. To exit "Candidate Recommendation" for each Best Practice, at least two web sites/pages which are not solely demonstrations of Best
<francois> Practices implementation should pass the Best Practice.
<francois> 2. An implementation report has been produced indicating the results of using each best practices for the web sites/pages considered
<francois> ]]
PROPOSED RESOLUTION: Beer o'clock.
RESOLUTION: We will set exit criteria when we are ready to ask for CR, but expect to ask for at least two independently sourced implementations of each BP...
RESOLUTION: Bo'C
+1
<chaals> [adjourned]