See also: IRC log
francois: Charter request is being processed. Should hear by next week
jo: we're out of charter from
tomorrow
... can't have a call next week w/o renewal.
dka: we can have it, just don't tell jo.
<francois> PROPOSED RESOLUTION: The BPWG requests publication of the Mobile/Accessibility documents.
<francois> PROPOSED RESOLUTION: The BPWG requests publication of the Mobile/Accessibility documents as a WG Note.
<jo> +1
<francois> +1
<EdC> 0
<SeanP> +1
0
<jsmanrique> +1
<DKA> +1
RESOLUTION: The BPWG requests publication of the Mobile/Accessibility documents as a WG Note.
<DKA> :)
jo: There's still a little way to
go before this is ready for a further public draft, let alone a
LC draft
... there are unresolved questions to do with the
document
... On device capability detection, can we discuss or should we
wait? Eduardo, you had some things on this...?
edC: in essence I think that it is in agreement with comments published recently in the mailing list, to make a distinction between
<jo> Thread on Device Capability Detection
edC: the technologies that are available and can be endorsed, and mentioning those that are emerging and stating they may become relevant,
but not committing to them as best practice in the doc.
jo: I feel the current text goes further than we should, on the basis that DPI/DPE are not fully fledged technologies, or even RECs.
francois: I agree with you on those which are not standards yet.
dka: I reluctantly agree, I'd
like to be more specific so the doc is more useful and
standalone.
... what I don't like is that the current one is a little
cryptic, but I don't see how we can resolve this. we can only
make it non-cryptic by making
<jo> PROPOSED RESOLUTION: Remove references to DCCI and DPE ans they are not mature enough to qualify for Best Practice
dka: specific recommendations
around technologies, which I agree we shouldn't do.
... The wording is purposely vague.
jo: my view is that this is not actionable as written, and there's not much one can do about it other than remove those...
<DKA> +1
<francois> +1
<jo> +1
<EdC> +1
RESOLUTION: Remove references to DCCI and DPE ans they are not mature enough to qualify for Best Practice
jo: I also have a question about use of media queries, an established technology in the sense that it's been a REC...
francois: it's not a REC
dka: it's a candidate rec
<francois> CSS Media queries CR
jo: it's been around since before
we started BP1!
... there is doubt about the implementations status of CSS
media queries.
... the fact that it's only a CR counts against it strongly,
but we have (despite Bruce's contributions) an unknown number
of implementations in mobile.
... I don't know how you establish if they're supported on any
particular device.
... they're not recorded in DDRs
dka: iphone safari and android implement some elements of them.
jo: so 2 threads here: how widely supported is it, and is it any use in the presence of scripting to query device properties?
dka: on the iphone they use CSS
media queries to see if the device is landscape or portrait.
Not the best way to do this, but shows a use for what is a
dynamic property.
... screen width can change.
... this doesn't mean we should endorse the full media query
spec, it's not implemented which is why this is a CR
jo: surely they only work on page load, not dynamically once displayed?
<francois> BP1 Style Sheets
<francois> [[ When creating style sheets, take advantage of the CSS media types (these may be used both in the CSS @media rule and in the media attribute of the link element) to specify styles that apply to handheld rendering. ]]
francois: in BP1 we reference media queries... it's also in mobileOK, so what are we trying to add?
jo: that's media selectors, not
media queries
... in BP1 we didn't reference media queries
<jo> to be clear it's things like:
<jo> <link rel="stylesheet" media="not screen and (color)" href="example.css" />
francois: I agree with you in
this case...
... we're missing implementations.
<jo> PROPOSED RESOLUTION: Drop reference to CSS Media Queries
dka: I wouldn't be so query to
remove references to media queries. I don't support this right
now.
... I'm not comfortable because I don't know what the status of
implementation is.
... if the latest webkit browsers on phones support most of it
and fennec supports it, arguably it belongs in this doc.
... we need more information
francois: I can ask the CSS media query folks...
<EdC> This actually addresses only one aspect of the issue raised by Jo. What about the other: are media queries useful and recommended as a best practice?
<jo> ACTION: daoust to enquires as to status of CSS Media Queries Rec [recorded in http://www.w3.org/2009/06/30-bpwg-minutes.html#action01]
<trackbot> Created ACTION-986 - Enquires as to status of CSS Media Queries Rec [on François Daoust - due 2009-07-07].
jo: it's open as to how relevant this is to mobile web applications, and what this contributes over and above script...
edC: it's too ... to be of importance right now. Is there an overlap of various techniques? Should the BP suggest when to use which? This bit is missing.
jo: we can't handle your comments on this call without adam being here... and is there much to say post- the list discussion?
edC: that's correct
jo: open issues, actions...
<jo> Open Issues and Actions on BP 2
<jo> (20 open actions 10 open issues or thereabouts need tidyong up on BP2)
jo: can't do this without the gentleman from suffolk
<DKA> it rocks
jo: well done BPWG, another doc created and published
dka: we're in danger with
mobileok going so well, that people might not notice. can w3c
do more to publicise it?
... the publication of mobileok scheme appeared on the home
page. We know that was the last link in the chain for overall
publication...
... but anyone reading the homepage note will shrug and not
recognise the importance of it.
... can you prod someone into action?
francois: not sure we need a
press release like that. Perhaps a blog post for the bpwg
blog?
... I released an updated version of the user interface for the
mobileok checker. When your page is OK I added a section to
give you the POWDER claim
... you could use to claim your conformance.
... I'm planning to write some posts on that as well.
jo: checker library is 1.1?
francois: not in the library itself, but in the UI
<jo> ACTION: Dan to draft a blog post on mobileOK Scheme [recorded in http://www.w3.org/2009/06/30-bpwg-minutes.html#action02]
<trackbot> Created ACTION-987 - Draft a blog post on mobileOK Scheme [on Daniel Appelquist - due 2009-07-07].
<jo> Draft 1s
jo: lots to do on this.
<jo> Draft 1s
jo: incorporated in that draft is use of Eduardo's proposed text on fair use
<francois> ACTION-971?
<trackbot> ACTION-971 -- Jo Rabin to adopt text proposed by EdC and Amended by Jo for the Abstract -- due 2009-06-22 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/971
jo: comments?
<francois> ACTION-985?
<trackbot> ACTION-985 -- Eduardo Casais to assess whether there is any relevant terminology we can quote in respect of last para of Section 5 - cf ACTION-933 -- due 2009-06-23 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/985
<francois> close ACTION-985
<trackbot> ACTION-985 Assess whether there is any relevant terminology we can quote in respect of last para of Section 5 - cf ACTION-933 closed
<francois> ACTION-981?
<trackbot> ACTION-981 -- Eduardo Casais to reveiw text and all references to user preferences and make editorial suggestion on how to clarify, taking into account Sean's points at http://lists.w3.org/Archives/Public/public-bpwg/2009Jun/0050.html -- due 2009-06-23 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/981
jo: tempted to propose we pull
this out into a separate section. i've not made any progress on
this in the last week.
... anyone got any comments?
seanP: separate section is a good idea, it's confusing when spread around the document.
jo: references from the bits it's taken out of is the right thing to do.
edC: go ahead, please take into account the short discussion on the mailing list w/francois...
<jo> http://lists.w3.org/Archives/Public/public-bpwg/2009Jun/0109.html
jo: action-982 on stylesheets...
<jo> ACTION: Jo to proposed text for separate section based on EdC's ACTION-981 and taking into account his refinement of that at http://lists.w3.org/Archives/Public/public-bpwg/2009Jun/0109.html [recorded in http://www.w3.org/2009/06/30-bpwg-minutes.html#action03]
<trackbot> Created ACTION-988 - Proposed text for separate section based on EdC's ACTION-981 and taking into account his refinement of that at http://lists.w3.org/Archives/Public/public-bpwg/2009Jun/0109.html [on Jo Rabin - due 2009-07-07].
<jo> close ACTION-981
<trackbot> ACTION-981 Reveiw text and all references to user preferences and make editorial suggestion on how to clarify, taking into account Sean's points at http://lists.w3.org/Archives/Public/public-bpwg/2009Jun/0050.html closed
<jo> ACTION-982?
<trackbot> ACTION-982 -- Eduardo Casais to propose some specific text ref ISSUE-298 -- due 2009-06-23 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/982
jo: eduardo and I had a
discussion. I still don't understand this, anything a
stylesheet might have referred to might have been
transformed.
... the problem I have here is that I don't know what we can
write. Eduardo... can you help?
edC: let me try to put the converse question: if you have a stylesheet and at least the stylesheet is marked as handheld, why would it become invalid if you want to deliver handheld-specific content to a mobile device?
jo: it's more a feature of the nature of the transformation, as to whether it does or does not try to preserve as much of the original style as possible. It's not something we can say anything sensible about.
edC: then why do you think that enclosing markup marked "handheld-specific" would be transformed?
jo: the same elements may have both handheld and non-handheld markup style applied to them.
seanP: I'm a bit confused too. My
understanding is that if you have a handheld page, and you
weren't transforming it, you wouldn't transform the stylesheet
no matter what the medium type
... and if you have a desktop page being transformed, it could
have a handheld CSS but you wouldn't use that one, you'd use
the non-handheld one.
... so you WOULD want to transform that, if you were
transforming the page itself. To me there's no need to say
anything here, we've already said "transform the CSS if you
transform the page"
<francois> [The question seems rather to be: is markup that links to a handheld CSS stylesheet an explicit mobile tag that fits in the list of 4.2.9 Proxy Decision to Transform]
edC: I go back to what sean was
saying. if this is the intent that is correct and there's
nothing in the guidelines enforcing that...
... in it's present configuration the rules allow you to
preserve mobile-specific markup but do what you like with the
handheld stylesheet.
jo: so we're saying "leave stylesheets attached to mobile pages alone". But we resolved not to say the same re images attached to pages. why?
edC: because here we can say the
stylesheet is explicitly handheld. there is no ambiguity.
... if you have a desktop markup, you'll have a screen
stylesheet
...
jo: what do we do about cases like opera, which is handheld and ignores the handheld bits?
edC: that's opera's problem.
seanP: in 4.1.5.4, it mentions
that (...)
... which is what i was thinking of. there's nothing on what
happens if you don't transform the page itself.
edC: if you access a linked resource, you should access with the same characteristics, but it says nothing about the response.
francois: it means add a
bulletpoint to the list in 4.2.9 ...
... for proxies, there's no way to link the request for a
resource to a previous request for the markup except maybe
using HTTP_REFERER
... so the only actionable statement would be to use the value
of the referer, to continue to behave transparently wrt a
linked resource
edC: the other technique is for
all proxies relying on url-rewriting, don't rewrite a link for
a stylesheet marked handheld
... I didn't want to include every included resource...
... but this one is specific, because there is a marking for
it.
francois: you can then have a mobileok marked up regular stylesheet - e.g. if the server uses transformation.
edC: you are correct if you haven't said it's for handheld, or encoded content in a media selector for handheld.
<jo> Under 4.2.9 - add a bullet stating that included resources refernced from no transform resource that are specifically noted as being handheld (mobile) applicable should not be transformed
<jo> PROPOSED RESOLUTION: Under 4.2.9 - add a bullet stating that included resources refernced from a resource that has been handled transparently that are specifically noted as being handheld (mobile) applicable should not be transformed
francois: so what is the rationale to restrict this to handheld? i'm fine with it, just can't see why it's restricted.
jo: because then we drag along the image case.
edC: and you can't mark an image as mobile specific.
francois: we're talking about
markup detected as mobile.
... handheld in this case requires the CT proxy to check
referer and remember there was a handheld attribute value
somewhere.
jo: if it's a link rewriting
proxy it could remember the link it rewrote, but this is a
document untouched by a LR proxy...
... the request on a transparently handled document will be
sent to the origin server not proxy
<jo> PROPOSED RESOLUTION: Under 4.2.9 - add a bullet stating that included resources refernced from a resource that has been handled transparently that are specifically noted as being handheld (mobile) applicable should not be transformed (this is applicable to non link rewriting proxies only)
seanP: don't think this does any harm...
<jo> PROPOSED RESOLUTION: Under 4.2.9 - add a bullet stating that included resources refernced from a resource that has been handled transparently that are specifically noted as being handheld (mobile) applicable should not be transformed
<jo> +1
<EdC> +1
+1
<SeanP> +1
<francois> 0 as I don't grab why it's restricted to handheld...
RESOLUTION: Under 4.2.9 - add a bullet stating that included resources refernced from a resource that has been handled transparently that are specifically noted as being handheld (mobile) applicable should not be transformed
<jo> ACTION: jo to enact resolution on included resources identified as mobile in 4.2.9 (above) [recorded in http://www.w3.org/2009/06/30-bpwg-minutes.html#action04]
<trackbot> Created ACTION-989 - Enact resolution on included resources identified as mobile in 4.2.9 (above) [on Jo Rabin - due 2009-07-07].
jo: eduardo proposed that we have a mailing list for conformance statements - otherwise where do they go?
edC: where can you put them, where can you find them?
jo: brilliant and blindingly
obvious.
... comment?
<francois> +1 to the creation of a mailing-list for ICS statements.
+1
<EdC> +1
<SeanP> +1
<jo> PROPOSED RESOLUTION: Create a standing mailing list called public-content-transformation-conformance to record conformance statements and reference from CT Guidelines
<jo> +1
francois: this is just to record
statements, not have an entity that validates them?
... we might also hit max length limits with that name
edC: one consequence is that i suggest the list is for people to provide feedback on tests re conformance
francois: absolutely, it's a public forum to reply to conformance statements.
<SeanP> +1
<EdC> +1
RESOLUTION: Create a standing mailing list called public-content-transformation-conformance to record conformance statements and reference from CT Guidelines
<jo> ACTION: Jo to reference the conformance mailing list in the ct doc [recorded in http://www.w3.org/2009/06/30-bpwg-minutes.html#action05]
<trackbot> Created ACTION-990 - Reference the conformance mailing list in the ct doc [on Jo Rabin - due 2009-07-07].
<jo> ACTION: daoust to check legality of mailing list name and maek the new list [recorded in http://www.w3.org/2009/06/30-bpwg-minutes.html#action06]
<trackbot> Created ACTION-991 - Check legality of mailing list name and maek the new list [on François Daoust - due 2009-07-07].
jo: I was actioned to put in a table of x-device mappings, which I did. although you SHOULD NOT change any other headers, if you do , SHOULD or MUST you record the changed value in an x-device version of the headaer?
<EdC> this was also one of the points I raised in another message.
francois: purpose of this table
was to register new header appropriately in the IANA
registry
... if we have another guideline saying you can register any
x-device-header fields you like, we'll run into trouble.
<jo> http://lists.w3.org/Archives/Public/public-bpwg/2009Jun/0084.html
seanP: are you asking that even though you change some headers other than the ones you're "allowed" to, you should put x-device in for those too?
jo: that would be logical
seanP: makes sense to me. why would other headers be special?
jo: it's covered in the text, you could infer it from the text
<francois> Scribe: francois
SeanP: I think the text already says that this is the case.
edc: Yes, there is enough room
for other mappings to be used for other HTTP header
fields.
... We have to link it to section 4.1.5
jo: can we resolve to leave it as it stands?
<jo> PROPOSED RESOLUTION: on 4.1.5.5 add the text Outside of the scope of normal HTTP operation ...
<EdC> +1
<SeanP> +1
<jo> +1
+1
<jo> ACTION: Jo to add the text proposed in resolution above on 4.1.5.5 [recorded in http://www.w3.org/2009/06/30-bpwg-minutes.html#action07]
<trackbot> Created ACTION-992 - Add the text proposed in resolution above on 4.1.5.5 [on Jo Rabin - due 2009-07-07].
RESOLUTION: on 4.1.5.5 add the text Outside of the scope of normal HTTP operation ...
<jo> Same doc reference
-> http://lists.w3.org/Archives/Public/public-bpwg/2009Jun/0121.html Thread on same-document reference
jo: in 4.2.9, we can be sure in that case that it is a same-document reference
francois: RFC3986 is pretty clear
on the definition.
... we should complete first bullet of 4.2.9 to say that href
can contain a same-document reference
jo: we need to put a note that explains why this doesn't work when the content is multi-served.
<jo> ACTION: JO to propose text on same document refernce under 4.2.9 proposing a note to explain that this cannot be used for multiserving environemnts where more than one represenation shares the same URI [recorded in http://www.w3.org/2009/06/30-bpwg-minutes.html#action08]
<trackbot> Created ACTION-993 - Propose text on same document refernce under 4.2.9 proposing a note to explain that this cannot be used for multiserving environemnts where more than one represenation shares the same URI [on Jo Rabin - due 2009-07-07].
ACTION-983?
<trackbot> ACTION-983 -- François Daoust to review same-document reference for first bullet in 4.2.9 (and elsewhere where it is referred to e.g. Appendix G) -- due 2009-06-23 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/983
close ACTION-983
<trackbot> ACTION-983 Review same-document reference for first bullet in 4.2.9 (and elsewhere where it is referred to e.g. Appendix G) closed
edc: quickly, there was a point I raised on URI patterns.
jo: yes, we added a note, but it
seems not to be clear enough. Let's come back to that next
week.
... We also have Charles' comments and proposed test to
review.
[call adjourned]
<jsmanrique> bye