See also: IRC log
<scribe> scribe: slightlyoff
<scribe> scribenick: slightlyoff
<scribe> scribenick: slightlyoff
HT: a report on DRM: web science
2013, Cory Doctorow gave the keynote
... he's a great speaker
... consistent with the buzz around the W3C's position on DRM, there was a perception that DRM is on its way into HTML
... the perception is so strong that the EFF have joined the W3C again to formally object to the re-chartering of the HTML WG
MC: Jeff answered questions on
the blog and made it sound as though it's not in the way
... and if the perception is something else, Jeff seems to have failed at setting that expectation
MC to TBL: I'm clarifying the perception as distinct from reality
HT: the perception is that the W3C has embraced DRM in HTML
TBL: what has actually happened is that EME has been added to the charter for the HTML WG
<wycats_> has the charter for HTML WG been approved?
HT: Harry Halpin invited Amelia
Andersdotter who is a member of the pirate party in Sweden
(elected to european parliment) spent a lot of time trying to
clarify the arguments against with me
... vs. my expectation that consenting users and providers can come to a mutually agreeable arrangement about how to deliver content
... and I wanted to understand the arguments against that, both technical and social
... the argument is that the DRM technology is too early in 2 senses:
... 1.) it occurs too early in the relationship between the consumer and producer; it's in the platform at a level that is very, very low that precludes something like fair-use
YC: but that's a general argument against DRM.
TBL: but what happens
... the decryption happens very late
wycats_: sorry = \
HT: it prevents anyone who has a
right to extract for fair-use from doing so.
... 2.) it's too early socially
... the argument is that it's premature to bake in this model when the business model is still not baked and is shifting
... I find that less compelling, though
... I'm done with the report, now
NM: I don't think that's evocative of what you mean when we say "too early": it's really about the level at which processing must occur in the model
YK: I'm not friend of DRM, but
there's no reason you can't contract away your right to fair
... I don't find DRM generally compelling, but I don't think what she argued should change your position
HT: the reason I brought this to the TAG and not to the pub is that I'm conscious that I don't understand enough of the issues behind it to know if there's an architectural issue here that the TAG needs to look into at some later time
TBL: my conclusion is that there
is an architectural issue(s)
... but it's not clear to me that many of the anti-DRM folks understand how DRM works
<annevk> What's the point of this discussion? I'm kinda confused.
TBL: but I have a box with lots
of OSS and I can still use DRM'd content
... and I'd like to understand that dichotomy
... I had a conversation with lots of students where I tried to catalog a lot of the statements that were made. I tried to point out to everyone that it's actually complicated and that if you don't understand the fundamentals, you can't argue well. If you tell me that "DRM is evil", I'm not impressed.
... these tend to be arguments about what people *will* do
... perhaps, instead, you should try to prevent bad things from happening if/when hooks are there, not to preclude the predicate for bad action
<wycats_> point of order
TBL: there's also a technical piece: can you ahve more than one DRM system on one machine?
<wycats_> Tim's arguments are outside the scope of the current discussion
TBL: can you have a system that accommodates multiple roots of trust?
YK: we're either have a discussion about DRM or not, which is it?
AvK: what is the point of this discussion?
PL: this discussion is trying to establish wether or not DRM is something we want to investigate as the TAG
<ht> Wrt Amelia Andersdotter: https://en.wikipedia.org/wiki/Amelia_Andersdotter
PL: do we want to open this can of worms and invite people in to explain the merits on both sides to us?
YK: I'm going to say something meta, and others will say something technical, I'm not sure what I'm allowed to discuss
<annevk> LOTS OF IT
NM: I think this is something the TAG should take up, learn about, etc.
<Zakim> noah, you wanted to say problems are not all about what people will do later
PL: we're spending tons of time arguing about wether or not we should argue about this
<wycats_> I do not believe having this conversation with the constraint placed on it is useful at all
NM: there's a sensitivity about
anything that can see bits in the clear, and that constrains
the systems, so you can make the case that DRM has very large
... you can make the argument that where this goes will affect many people's lives
... it maybe the case that putting the hooks into HTML, we might be endorsing something other than what we've typically seen so far, ala TimBL's proposed questions around multiple roots of trust
MC: I'd also like to see the TAG
invesigate this, and invite both proponents and opponents
... folks from the EFF, etc.
JT: my question would be: we
should spend time doing things where we can affect an outcome,
is this one of those places?
... or is this a place where these will be decided on extra-technical merits no matter what we do?
<Zakim> ht, you wanted to reply to Jeni
<wycats_> This argument bottoms out at "Netflix refuses any solution that is not hardware-enforced DRM"
HT: it seems to me that we can identify more and less damaging ways to go about this, should it go forward
<wycats_> which seems unrelated to technical merits
<wycats_> so I agree with Jeni
<Zakim> noah, you wanted to say role of the TAG is not only to affect the short term outcome
NM: there's a plausible premise
in what JT said, but part of our charter is to document the
... leaving a record might be valuable
<JeniT> yes, I would prefer to spend time on things that are not ineffectual
PL: I'm hearing support for having people in, getting more data ,etc.
YK: I have a question: do we think that technical input will affect anything, particularly to content providers?
YK: and they'll be OK with stuff that's not hardware-enforced DRM?
TBL: there's a whole body of thought that says they'll be happy with watermarking or something short of full-scale DRM
YK: if we rule out of order the hostage-taking arguments
TBL: yes, of course
<wycats_> slightlyoff: well said
AR: I think the TAG should do more than hold coats, it's one of the only bodies at the W3C that's chartered to have an opinion of its own
YK: I don't think there's a cage
match with heycam
... I can give an udpate on what was discussed last time
... we have a thing in the platform right now called WebIDL; its job is to map between JS and C++ via a declarative indirection
YK is presenting: http://wycats.github.io/jsidl/jsidl.html
<annevk> (TR is out-of-date)
YK: it has 2 levels: a language semantics and a binding system to JS
TBL: can you describe all JS interfaces in WebIDL?
AR: no, WebIDL is a subset of the operational semantics of JS
YK: WebIDL users define things
like "window" or DOMElement that are defined in terms of
... the most charitable way to think about that is that these are coercions about JS and C++ objects
... the primary goal of JSIDL is to remove the intermediate layer -- e.g., instead of coercing from JS to IDL to C++ and all the way back again, you instead define your interface in terms of JS objects, removing the intermediate mapping
... this lets you talk about things that are defined as JS but _just happen_ to be implemented in C++
TBL: why are there 2 levels in JSIDL?
YK: there aren't
... ToString is a nomenclature thing that is a bit confusing: it's a coercion rule about the nominal type "any"
AR: this is about not enforcing nominal types at boundaries, but declaring the coercions that are likely to occur
YK: the old WebIDL semantics had
nominal type overloading that showed the issues
... WebIDL wanted an interface with a positional parameter that wanted a String vs. long in the same position to do this by something that is relatively complicated vs. the natural-to-write JS
YK: let me get to that after
outlining where we are in the process
... I've talked to heycam, bz, etc., and they're cautiously optimistic if I do the work
NM: are there entrenched communities of opposition? or is this about finding a path?
YK: I've heard 2 cocerns: heycam
wanted to do this incrementally but I don't understand how to
incrementally remove a mapping layer. He seemed to think it was
about syntax changes -- which everyone wants -- but I'm after
... I don't know if he's fully persuaded, but he's willing to let me try
... the other argument is that there is a lot of existing tooling
... the point of JSIDL is also to be declarative, and you can imagine a mapping system
NM: but you're not specifying mapping now?
NM: <describes the landscape>
TBL: has anyone tried this before?
MC: MSFT has done typescript
YK: TypeScript does something more nominal than this
NM: that was clarifying intro for me
YK: most of TC39 didn't hate
JSIDL, except Luke Hoban (MSFT) has the objection that WebIDL
isn't the real problem
... allenwb has offered to help add things to the spec that might help in making JSIDL more friendly to ES6
... there was interest from others about a Guards proposal
YK: the other operational thing
is that I've been maintaining a DOM JSIDL
... this is more natural, as it calls out that things like enums are a legacy concept
... there's some attempt to bring the terminology in line
... readonly vs. nonwriteable
TBL: is that meaningful
AR: e.g., configurability allows nonwriteable to be converted in some cases
YK: there are cases where you can re-define many of these things in the object model
AR: why void and not "undefined"?
YK: good point
AVK: I've mentioned before that
it might be better to do it incrementally, and I want to try
again to convince you
... every time we make small changes to browsrs, we get bug reports and have compat issues
... and I understand you want to make semantic changes where you can if there's wiggle room
YK: I'm happy to give up on that for now
AVK: if you keep it functionally equivalent, it might work, but if you change semantics at the same time, it's going to be hard to get browsers to do this
YK: good argument, and one we
haven't heard before
... let me give you an example of something that's hard to convert (in response to TBL)
... destructuring and dictionary types
... it's not obvious that it's possible to perfectly translate some of these forms
TBL: many real IDL files can probably be automatically converted?
AR: overloading turns out to be
mostly in new stuff, and I'm identifying the places no where
... and it's mostly in new stuff where people have built C++-heavy designs that reflect that thinking through to JS in an un-reformed way
YK: turns out that it's hard to
think about a lot of those issues as automated
... you told me that there's some issues around undefined vs. missing
AVK: bz is happy to try it out,
and we can probably change this in WebIDL first
... returning/accepting Number has constraints on it now which we might need to describe more clearly
YK: I need you and bz and heycam to help flag these sorts of cases
(e.g., Number clamping)
MC: some of this is a bit harder to parse (e.g. the block for "nonwriteable")
AR/YK: not that hard to parse...
HT: what is the TAG's role here?
HT: are we putting this in REC track in the TAG? or finding a WG?
YK: happy to do the latter
... where is WebIDL now?
YK: will work with heycam on that
YL: there's a lot of coordination to do
YK: you can do a manual conversion relatively quickly
YL: there's a lot of testing overhead here too
YK: yes. Not signing up to do all
of the testing and tooling, but will do the work to help
improve the system to make that easier
... answer is that I'll keep the repo in the TAG org on github for now, and move it to WebApps at some point as I work more closely with heycam
PL: next steps?
YK: for now, wanted to make sure
we could be correct
... more to do in TC39 space to ensure that branding works
... need to make sure that TC39 thinks that'll work with the language
... next, after that, is to flesh out the syntax
... appendices for legacy content
AR: doubling up is not going to be very friendly to the people working on bindings (in response to AVK about not wanting more than one IDL format at once)
TBL: in C++, if you're pretending to be C++, can you do everything a JS object can do
AR: JS VMs are done in C++, so yes, this can happen without a mismatch
YK: the tag can help coordinate
<annevk> plinss: you realize that parses as <br> right?
<annevk> i.e., more breaks :-)
<JeniT> annevk, were there two breaks?
<annevk> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cbr%3E%3C%2Fbr%3E is beautiful
YK: we should either make sure that specs bend to AWWW, or we should change AWWW
AVK: agreed. The reform agenda makes this pretty plain that we want to be about the web as it exists.
NM: we should be careful to be
thinking about what's relevant for 15-30 years
... we should careful about how we change things
YK: normative language shouldn't be at odds with reality
MC: there's normative language in there
TBL: I have a lot of cynicism
about MUST, etc. as used in RFC 2616, as lots of people use
"normative" as an adjective, when in fact it's a relationship.
When a spec says you "MUST get up on Saturday morning", it only
means that when you are talking about meeting some criteria
that is on the box that says "we are X compatible"
... this is conformance with some contract, not an enjoinment
<noah> + to take contrary position
MC: we have to remove the MUST,
normative language in AWWW
... faking authority about making AWWW a REC doesn't help anything
TBL: it could be in TR space without being a protocol spec or similar, lots of things are there that aren't technical specs
YK: I'd be supportive of changing
this to not talk about content type
... there are other headers that are used authoritatively, and content-type is perhaps a bad example
PL: there's a queue
YK: I didn't mean to start the
conversation that just happened, it would be nice to take up
... I'm making a narrower ask, though, that we remove normative language that's inconsistent with other specs
... perhaps removing all normative language if TBL is uncomfortable with it in thing that don't have conformance criteria
... we could use other examples, e.g., CSP
PL: to NM's point, we shouldn't
just go through the doc and remove stuff
... it might turn out that we'd like to keep some principles that don't have platform examples
YK: those should be agenda items
HT: on the very narrow question
of sniffing, the situation is that RFC 2616 says that
Content-Type is authoritative
... it governs HTTP and the HTTP URL scheme
... I'm loathe to ignore it
... second, we revised the Authoriatitve Metadata finding some time ago
... third, the wording from HTTP bis is wording that _we_ offered them to acknowledge the reality around sniffing
... there's good reason to believe that this isn't authoritative for Content-Type
... under those circumstances, I'd be happy to revise the section to add more example, but not to remove the Content-Type example, it may add clarity about the idea that you _should_ try to do it right if you can, and if you can't, see our other documents
... we shouldn't do anything until HTTPbis comes out
<noah> .Hmm, I'm sure I was on the queue
<discussion about timing of HTTPbis>
<Zakim> ht, you wanted to argue we have to respect the IETF and to ht2 to +1 to a 2nd edition for AWWW
HT: it is time to see if we can
scope a viable plan to produce a second edition of AWWW
... if we could say it's a small-ish set of changes and can do it in 3-6 months, we should
... we should try to scope it to do it only if we can set parameters that enable it to be finished quickly
... I can volunteer if we can scope it like that
<Zakim> ht2, you wanted to +1 to a 2nd edition for AWWW
<Zakim> JeniT, you wanted to +1 to a 2nd edition of AWWW to reflect experience
PL: one way to do that might be to have another doc which we can undertake in parallel
JT: I wanted to support doing a
second edition of AWWW and to address places where we want to
reflect some new experience since publication
... it'd be good to show the path from where we are to where we want to be
... we have more experience now, so we should try to reflect that, but I don't know how to scope that
... large changes have happened since the publication of AWWW
HT: I was using code to say that there are limits on what you can do in a "second edition"
YL: you probably shouldn't introduce interop issues, but this won't happen in this caes
AVK: many groups have violated that principle, SVG, XML, etc.
TBL: does the group think that we
should issue new documents to cover new areas? or should we
... we could create a "Volume 2"
AVK: it was useful to me when I
... but it also sounds like it's going to be a lot of work
JT: time-boxing is effective in limiting the scope
AVK: I favor a revision vs. surgical edits
<agreement that it would be nice to have>
JT: one of the conversations I
had yesterday with Jo Rabin was about revising AWWW, he
suggested it should be cut down and easier to read
... he said it's to big, too hard to read
JT: MC's suggestion that it be in github and open to many editors wanting to change bits, might be good way to go fowrard. If it generates discussion, that's not a bad thing
NM: I suggest you announce this loudly
MC: we can put a hook in that will notify the mailing list
<Zakim> ht3, you wanted to argue it remains a REC, because it _is_ authoritative about Web Arch
NM: you'd be surprised how strongly people will feel about changes
<Zakim> noah, you wanted to take contrary position
HT: I'm very strongly in favor of keeping this a REC. This being something that WGs can refer to as a way to know what they'll be judged by late in their process is a valuable property of the document.
JeniT: I'll race him = )
NM: I wanted to say something very similar. I think that AWWW serves a bunch of purposes, but it's a spec for specs. I don't think anybody disagrees that the sniffing instructions in HTML5 violate the old versions of 2616. What I see AWWW saying in its current form is "that's a violation of web architecture". Weather you continue to spell that "MUST" vs.
"must" is interesting. That this is a spec for specs is a good thing and you shouldn't run away from that and turn it fluffy. It's OK for people to make selective violations.
NM: where things are viewed as
exceptions and not rules is important
... I agree it should be a REC
JT: another option for managing changes that might lead us to another version (vs. a new edition) might be to break up stuff
NM: it's useful that we have a single document
TBL: it was historically put
together out of a lot of findings, and Ian Jacobs did much of
the work of making them consistent and integrating them.
... we could take it apart for maintainece and put it back together.
e.g., missing JS
AR: I'd like to do something for helping people design good JS APIs before we contemplate putting this stuff into AWWW
JT: but there's even just acknowledging that scripts _exist_ that's missing
YK: pushState() is important to note
NM: that they can generate content!
AR: I'm scared that acknowledging scripts in this sort of document begs some _very_ deep questions and will cause huge changes
TBL: the value of briefing people
is good. I'm having difficulty imagining that they won't have
read a book on JS for Vol 2...what will we have to describe?
async? the language?
... should we only describe the bits where JS interacts with things like URLs?
AR: I don't think that's
reasonable. JS goes very deep into the architecture of the
client-side platform. It's very very deep...fundamental.
... and we won't produce a document that acknowledges that correctly by the end of hte year
HT: we can acknowledge that
*effects* of JS without doing the very valuable work of
cataloging the client-side architecture
... HTTPbis is really terse about, e.g., databases
... and that's a bug
<Yves> not a bug
TBL: if we put in the minimal
version, we have to talk about async, events, etc.
... and we must assume people have read a good JS book
<Zakim> noah, you wanted to talk about role of scripts
NM: I might be saying the same
thing as HT, but we're talking about how to introduce the
"document application model" that exists now and didn't when
the original doc was written
... I think the way to do this is to put some of this new story very early in the docment
... to acknowledge that JS can dynamically create much of what the server used to build
... just saying that JS *can* do this stuff may help clarify
... I think we should bring it up clearly and very early
YK: I agree with NM in principle.
I agree that what tends to happen in webapps is that you
download a generic thing at a URL that then interprets the URL
... historically, that might have been the role of a fragid, and now there's a fragid-like thing that's happening via regular URLs itnerpreted by script
JT: why are you saying that isn't happening with fragids?
YK: the way people were doing routing early was fragid-based, but for tactical reasons, taht didn't turn out to be effective, so they're using something more like regular URLs in practice
TBL: it goes both ways
... e.g., twitter
<everyone agrees that Twitter did it both ways, and likely wrong>
TBL: T.V. Raman wrote about this
<Zakim> timbl, you wanted to say we should list things people could do wrong
<noah> This is the finding to which Raman contributed, and to which Tim just referred: http://www.w3.org/2001/tag/doc/IdentifyingApplicationState
TBL: there's a pattern where much
of the content is part of the page and is augmented lightly by
JS but is mostly HTML
... there's another mode where everything is JS-mediates
... there's yet another where the hash isn't the content indicator, but rather the URL is
... original AWWW was derived from things we discovered that people shouldn't do
... it might be possible that we write about the current status of modules, etc.
... but going to 6 volumes about everything isn't maybe the best idea
AR: can rephrase as "we should only be trying to tell people about what only we can tell people"?
TBL: plus "what only we _will_
... Futures? should we include advice of that sort?
AR: we should have a document about good API design first
TBL/PL: well, this would be about a Volume 2
<noah> scribenick: noah
PL: Are we agreed on doing a 2nd edition.
<slightlyoff> TBL/PL: this wouldn't be a short-term thing
<slightlyoff> PL: I'm hearing that we should do a second edition
HT: Yes, but conditional on finding a suitably bounded scope
<timbl> TBL: we should include in vol 2 things warnings about things you should not do, like don't abuse the global symbol space in JS, etc. and ways to avoid doing that.
PL: Are we reasonably informed to take a stab at that now
HT: We need to do things. Welcome help on both, but NEED help on one. 1) Put existing source in GitHub. 2) start figuring out what's clearly to be dropped, clearly to be kept, suspect, needs tweaking, etc. Not sure how best to try. Will take an ACTION to start email conversation.
<ht> ACTION ht to move the source into [private w3c] github with help from Marcos
<trackbot> Created ACTION-812 - Move the source into [private w3c] github with help from Marcos [on Henry Thompson - due 2013-06-07].
For source, look in CVS in 2001/tag/2004
<ht> It's in 2001/tag/2004/webarch-20041209
<ht> ACTION ht to initiate email discussion on how we decide what bits of AWWW to work on, i.e. to collect some starting points for the scoping discussion, with help Jeni
<trackbot> Created ACTION-813 - Initiate email discussion on how we decide what bits of AWWW to work on, i.e. to collect some starting points for the scoping discussion, with help Jeni [on Henry Thompson - due 2013-06-07].
<slightlyoff> back, sorry, happy to take over noah
Henry suggests we not minute, because he will shortly provide a link to a document with all that matters.
<slightlyoff> scribenick: slightlyoff
<noah> scribenick: slightlyoff
NM: there are many people who are trying to use URLs/URIs/URNs for the long-term identity and location
HT: there are many people who are
trying to use URLs/URIs/URNs for the long-term identity and
... the TAG's involvement came out of advice the TAG made to the memebership to oppose the OASIS XRI proposal 7 or 8 years ago
... this was done under the banner that "HTTP is good enough"
<clarifications about what URL, URI, and URN mean in the current use>
<decision that HT will use URL and URI interchangeably, but that URN means something different>
HT: we had a request from members
to explain why HTTP URIs were good enough
... the core ansewr is that *all* URI schemes are vulnerable to its management system
... any publicly managed naming scheme has social failure modes
... there might be things that militate against persistence, but you can't talk about it without discussing management
... we invited some curation community visitors in 2010 to discuss this
... we agreed to have a workshop, which happened in Dec 2011
... in conjunction with a curation conference
... some interesting things came out of it: new clarity, largely due to jonathan, distinguishing binding from from resolution is important
... binding == "relationship between a new name and what it is to name"
... resolution == " looking up a name in order to discover what it names"
... e.g., linean taxonomy.
... the governance for that is publication in a journal
... the authoritative way to find out is a distributed local-reference system based on some local librarian knowing where it is and providing it to you
... there's another point, which is to distinguish binding from ownership
... Johathan observes that for *persistent* names, binding is one-time
... the other new thing that came out of it is that broad agreement was reached that htere should be an open community process for managing binding for persistent names on the web
... the model is RFC #'s to RFCs
... net, to create a persistent naming system, it would have to be managed socially and adhere to the "lots of copies keep things safe" principle
... the existing domain name system is not easily ammenable to this style of use
... proposal: .arpa has special rules that might be better for this
AVK: but we don't have to use URIs, right?
HT: yeah, but the goal was to see if we could
NM: Metcalfe's law point
<ht> The projected report is at http://www.w3.org/2001/tag/2011/12/dnap-workshop/report.html
AR: ok, so many things can't easily be put into a different GTLD (e.g., .gov.uk) like .arpa, can we use this as a reverse mapping?
HT: that's the thought
YK: so the problem is that domains can transfer ownership?
HT: and that they can be taken
... there's an arbitration process
... 3 problems:
... leased, not owned
... there's an arbitration process
YK: do new TLDs help?
TBL: new TLDs can propose new
... and I've proposed `.archive`
NM: the judgement in the room that using a new TLD is more political work than using .arpa
HT: the third problem is that
people just walk away. Organizations fold.
... e.g., foaf.org
... note that resolution is separate
YK: you can imagine that you put a copy of a book under an archive domain and want to update it
HT: that's why you need a community process
TBL: the promise in general is that if you assign an ISBN, you can't stop using the relationship, but you can't re-use the ISBN
<Zakim> noah, you wanted to ask what's happening now
NM: what has happened since?
NM: do you think the TAG can/should catalyze any action here?
HT: Gavin Brown came up with the
... but he was drowning in TLD registration stuff
... this is someplace where we could get help from the IETF, but we haven't tried
YK: why can't we do .archive?
<discussion of kickstarter, etc.>
<break class="lunch" data-till="13:45">
<scribe> scribenick: slightlyoff
JeniT: just as soon as it breaks some bit of real-world code that cares, I'll get right on it = )
annevk: thanks for that
DA: many, many more
... and "mobile" is dead
... the word "responsive" is being used as an umbrella for this sort of content adaptation
... Dave Shea is re-launching CSS Zen Garden as a responsive showcase
... is there something that we need to do to encourage spec authors, writers, etc. to think about this
YK: the tactical goal that people
have is to get either one thing that works for all devices, or
to get one thing that works on the device you have
... I think people get sad when you have to create multiple forms for different devices
... I think people really want one set of bits that work for all devices, but on some devices that doesn't work (e.g., with resp images)
DA: but the UI might be radically
different per device
... there's a nuance that the client-side logic might need to make decisions about what to do
... there's a question about being responsive to network bandwidth
YK: I think people using the name
"responsive design" are trying to use the same bits to service
all clients, and want to collapse all of their different axes
of choices into a single point, and want to be able to automate
all of this
... they are asking for the platform to help them do the right thing to manage those constraints
<Zakim> ht, you wanted to ask about relationship to ?demise? of transforming gateways?
HT: does this mean that transforming intermediaries are going away?
DA: yes, we sure hope so
NM: opera still makes a business on this, right?
MC: what about Kindle Fire (silk)?
DA: there's a nuance about what
sort of intermediaries there are and what they're doing
... "transforming intermediaries" vs. a "split browser"
<discussion about details and observability of transformations>
YK: modern proxies are trying very hard not to be observable
<Zakim> ht2, you wanted to ask about where this leaves mobile [profiling]
HT: we put a lot of work into specing a way for devices to describe themselves...is that still relevant?
MC: there's another proposal called "client hints": https://github.com/igrigorik/http-client-hints
<ht> device description working group
<ht> device description vocabulary
DA: the philosophy behind "responsive" is that the client does the work to disambiguate, not the server
NM: so this all hangs on JS? imperative code?
MC: there's a misunderstanding of
what it means to be declarative in the CG taht's working on
... designers are so used to having per-pixel control, they think they can just go into HTML and put in a media query and it'll be magically applies
... but in markup, you're just making suggestions
NM: that's not because it's declarative, that's because the <img> tag has that ambiguity built in
MC: the pre-parser that's part of
many impls get broken by some of these proposed forms
... browser vendors reacted badly to having their optimizations broken by the proposals
... in the resp-images spec, there's now an acknowledgement of the browser perspective and it tries to marry the concerns, but it's not perfect yet
DA: has anyone talked to the resp-design community to tease out pet peeves?
YK: it's nonsensical to talk
about the "resp design community". Everyone who cares about
mobile is doing this
... there's some stuff like "element queries" that might make things better
... it's very hard, and browser vendors react badly to it
... but people are still asking for something
JT: there's also device
... input modes, etc.
AR: I've proposed a couple of times that media query parameters be extensible and it always falls on deaf ears
PL: you can't easily isolate the timing for CSS application and query resolution from the time when JS would run
AR: this can be done without implicating calling JS from CSS
AVK: we'd like to leave the timing of when queries are evaluated from the main thread opaque
AR: it'd be dirty-bit based
AVK: we've considered sync flush for the box tree
YK: the point is that it's the
same sort of dirtying behavior that doesn't require sync
... how do we make this better? what's next?
AVK: you might nudge tab and fantasi?
YK: people keep getting met with a stone wall...how do we make sure that people don't just bounce off
AVK: css is already overconstrained...it might not be something people feel like they shoul be working on this as a high-priority issue
PL: the issue with element queries is implementability
YK: open question: what do we tell Ian Storm Taylor?
DA: there are 2 CGs in this area, what else is happening in the community that's working on these problems...we heard about client-hits...is there anything for us to do here?
DA: is there something that we can do? should do?
AVK: we might be able to coordinate, but we don't have expertise here.
TBL: the main question is: is anyone else going to do this?
YK: we should look at what people are doing
MC: I'd like to talk to that
group and give them a recommendation from the TAG
... should we tell people to use the picturefill polyfill?
... it could be nicer if it were in the platform
AVK: we shouldn't use the names that we'd like to have adopted in the public ewb
MC: we need to check with the drupal guys, but they were deploying <picture> on the web with the polyfill
<Zakim> noah, you wanted to say be careful about requiring everything to be "responsive"
MC: and we might need to go talk to them
NM: discussing this is clearly good, it's only somewhat clear to me what the TAG's role in moving this forward would be
annevk: no problem
I've got it
NM: if things are organized right, should they be doing what they're doing?
MC: it's a great thing if the feed back is "good on 'ya"
NM: I don't see anything deeper
and architectural here
... I think the TAG could play a role if the community doesn't get it right
... there's a tradeoff: encouraging responsivness is a good thing to do. Increasing the barrier to putting content on the web by making harsh recommendations that people "MUST" do things is also problematic
<Zakim> ht, you wanted to say IST's blog post seems helpful (and well-explained)
HT: I've looked at some of this intro material and it's hugely helpful in understanding the problem
<JeniT> reference is to http://ianstormtaylor.com/media-queries-are-a-hack/
PL: it's not impossible, just
... and it has been explained
YK: could you send a link?
<wycats_> also see http://www.jonathantneal.com/blog/thoughts-on-media-queries-for-elements/
<wycats_> a prollyfill for element queries
AR: I think this is TAG business because it _is_ architectural: the adaptation of content is core to the architecture of the client platform
NM: yes, it's important, but we
don't weigh in most of HTML5
... i was responding to the particular idiom under discussion
... at the principles level, I agree that we should support adaptation
AR: I reject the framing, I think the TAG needs to be involved in the details in order to be an honest broker about the social disconnects between developers and vendors in this area
NM: I'm not trying to say you shouldn't do that, just don't own the details
YK: it might be worth banging the
drum about layering as a solution for this area
... layering is a framing that doesn't require everyone to give up on their specific areas of concern
... and AR's proposal helps enable both implementers and users to iterate in their own space and get past this
TBL: this sounds like a good way for the TAG to operate: acquire enough information about the specifics to be able to make good recommendations and point to in our layering advice about what does and doesn't work
<timbl> We have worked like this before, to go into specific breakage, and come out with to just opining on that and helping mediate, but demonstrating need for broader arch pricnoples.
DA: on the resp-images controversy, we have a community that's very interested in images and they care a lot -- sounds like the audio thing where htere's a community of experts -- and they've built that knowledge into the proposal and when they bring that to the larger community which is thinking about other concerns it meets resistance
MC: that's a tiny bit off....the
community is the design community
... they know all about the larger context
YK: and iOS is making this easy for htem and hard for us...they're saying "why is this so hard on the web?"
MC: we want browser involvement
because there are things like powering up the radio that cause
... the JS solution has raggedy edges
YK: it's not composable
... if I use hitch.js to modify my images, I can't use other things
<wycats_> hitch.js is a CSS prollyfill engine
AVK: there are existing communities in which these things can be solved
MC: there are guiding principles
that we can use and the TAG can transmit back to the
... it's not obvious to everyone else
YK: when we write down the principles, we should higlight things like that: don't build stuff that can't be taken back if it's not part of a standard
DA: perhaps we can take that back
MC: we can't say "web components" 'cause it's not there yet
YK: we can't say "use
components", but we can say "look at how that was done"
... someone should write the Polymer WC for responsive images
MC: I'd be happy to write up something along those lines
YK: it seems like people agree
that CGs were intended for a particular purpose and it seems
like they are getting used as a way to divert some folks away
... e.g., resp-images is an example of a lack of vendor involvement, and the CG worked really ahrd and the vendors were astonished
TBL: if you put people out in a CG, the WG has a responsibility to liason with that CG
DA: someone said "there should be
the ability to send a pull request to a WG from a CG"
... you could think of a CG being allowed to fork a spec and allow those sorts of changes
NM: letting people patch
communication problems is clearly good
... when YK said "this isn't what htey're for", I want to understand that
DA: CG's were initially set up to incubate NEW work
NM: I'd have thought that if a group wanted to do something in an area that a WG is already formed in, they should try that ifrst, but if someone finds that problematic, they started CGs ot spec that
YK: I don't think taht's what happened in this case; people who weren't WG memebers were pushed off for resp-images
MC: that's not what happened with HTML/XHTML
TBL: what they were designed for
should not restrict what they're used for
... there are several failure modes; sometime they go off and do work and are not respected, or they go off and don't do work
... but perhaps we should look into CGs that are explicitly spun-off from WGs
<wycats_> think of them more like "task forces"
DA: yeah, was thinking about CG's that are treated more like Task Forces and not independent entities
NM: I don't think this is
particularly TAG business
... more like something we could refer to the AB
DA: not sure if it's TAG business, but it's soemthing I intend to personally take to the AC/AB
NM: I dont' want us to be process nerds, but the TAG's charter is fundamentally technical
DA: but lets not use that as a reason not to talk about things
AVK: "3. to help coordinate cross-technology architecture developments inside and outside W3C."
<noah> "The TAG's scope is limited to technical issues about Web architecture. The TAG should not consider administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee, Advisory Board, and Team."
AR: diplomats, not politicians
<ht> That's the hard part
<ht> Here's the apparently reasonable request: http://ianstormtaylor.com/media-queries-are-a-hack/
DA: we're due to close in 55 min....we should probably move forward. JT suggests we not talk about DWA but instead wrap up, talk about next actions, etc.
DA: don't want to re-open packaging becaues it'll eat the whole hour
<general consensus to go to wrap up>
AVK: do we have actions we can review?
NM: they're in tracker
<trackbot> ACTION-802 -- Yves Lafon to bring new W3C initiatives to TAG's attention, open-ended, due 2015-12-31 -- due 2013-06-05 -- OPEN
<trackbot> ACTION-803 -- Daniel Appelquist to talk with Art Barstow and/or Charles Mac??-Neville to find out who from Webapps might come to talk to us -- due 2013-06-05 -- OPEN
<trackbot> ACTION-804 -- Yves Lafon to invite Olivier Theroux to lunch on Friday due 2013-05-29 -- due 2013-05-30 -- CLOSED
<trackbot> ACTION-805 -- Anne van Kesteren to find a representative of Web RTC to talk to the TAG -- due 2013-06-05 -- OPEN
<trackbot> ACTION-806 -- Jeni Tennison to invite Phil Archer to talk to the TAG -- due 2013-06-05 -- OPEN
<trackbot> ACTION-807 -- Daniel Appelquist to invite someone from Responsive Images CG to talk to the TAG -- due 2013-06-05 -- OPEN
<JeniT> marcosc: did you ReSpec that?!?
<trackbot> ACTION-808 -- Daniel Appelquist to pull together a plan for TC39 participation at TPAC in November in China -- due 2013-06-05 -- OPEN
<trackbot> ACTION-809 -- Yehuda Katz to and alex will create an initial draft of high level view/survey and how they relate to system capabilities -- due 2013-06-05 -- OPEN
<trackbot> ACTION-810 -- Jeni Tennison to create a first draft of capability document guidelines -- due 2013-06-05 -- OPEN
<trackbot> ACTION-811 -- Yehuda Katz to send a note to the web audio working group with some architectural suggestions. -- due 2013-06-06 -- OPEN
<trackbot> ACTION-812 -- Henry Thompson to move the source into [private w3c] github with help from Marcos -- due 2013-06-07 -- OPEN
<trackbot> ACTION-813 -- Henry Thompson to initiate email discussion on how we decide what bits of AWWW to work on, i.e. to collect some starting points for the scoping discussion, with help Jeni -- due 2013-06-07 -- OPEN
DA: should we invite WebMIDI?
<noah> ACTION: Marcos to present on midi on future telcon - Due 2013-06-30 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action01]
<trackbot> Created ACTION-814 - present on midi on future telcon [on Marcos Caceres - due 2013-06-30].
YK: that's not reasonable since we want to inform the entire TAG
AR: good point
<noah> ACTION: Dan to invite Anssi to present on DAP/Sysapps on future telcon - Due 2013-06-15 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action02]
<trackbot> Created ACTION-815 - invite Anssi to present on DAP/Sysapps on future telcon [on Daniel Appelquist - due 2013-06-15].
<noah> close ACTION-807
<trackbot> Closed ACTION-807 Invite someone from Responsive Images CG to talk to the TAG.
<noah> Suggest we paste the URI's here for the minutes
<noah> OK, I'll do it: https://github.com/w3ctag
<noah> ACTION: Yehuda to write readme for architectural principles of promises - Due 2013-07-01 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action03]
<trackbot> Created ACTION-816 - write readme for architectural principles of promises [on Yehuda Katz - due 2013-07-01].
<noah> ACTION: Alex to write readme on extending HTML responsibly - Due 2013-07-01 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action04]
<trackbot> Created ACTION-817 - write readme on extending HTML responsibly [on Alex Russell - due 2013-07-01].
<noah> ACTION: Peter to coordinate redesign of home page, finding lists, etc. - Due 2013-08-01 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action05]
<trackbot> Created ACTION-818 - coordinate redesign of home page, finding lists, etc. [on Peter Linss - due 2013-08-01].
<noah> ACTION: Peter to set up mirroring of git repos - Due 2013-07-04 [recorded in http://www.w3.org/2013/05/31-tagmem-minutes.html#action06]
<trackbot> Created ACTION-819 - set up mirroring of git repos [on Peter Linss - due 2013-07-04].
RRSAgent: make minutes
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/NH/HT/ Succeeded: s/invited X/invited Amelia Andersdotter/ Succeeded: s/say// Succeeded: s/Joe/Jo/ Succeeded: s/hsouldn't/shouldn't/ Succeeded: s/GIT hub/GitHub/ Succeeded: s/Tailor/Taylor/ Succeeded: s/soem/some/ WARNING: Bad s/// command: s/HTML/XHTML/WHATWG Found Scribe: slightlyoff Inferring ScribeNick: slightlyoff Found ScribeNick: slightlyoff Found ScribeNick: slightlyoff Found ScribeNick: noah Found ScribeNick: slightlyoff Found ScribeNick: slightlyoff Found ScribeNick: slightlyoff ScribeNicks: slightlyoff, noah WARNING: No "Present: ... " found! Possibly Present: AR AVK DA DKA_ JT JeniT MC NM PL TBL YC YK YL Yves annevk ht https joined marcosc noah plinss scribenick slightlyoff tagmem timbl trackbot wycats_ You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 31 May 2013 Guessing minutes URL: http://www.w3.org/2013/05/31-tagmem-minutes.html People with action items: alex dan marcos peter yehuda WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]