00:05
<Hixie>
in my experience, if the weird interpretation of the spec leads to something that isn't OBVIOUSLY bad, then someone will attempt to argue it's the way to interpret the spec
01:29
<zewt>
is there a name for the discussion pattern that goes: "a doesn't seem useful, because we can do a1 in an easier way" "but you can do a2, too" "why would you want to do a2?" "why are you so fixated on a2, it's also useful for a1"
01:29
<zewt>
seems like a cousin of the bait-and-switch
01:34
<karlcow>
:D
01:35
<zewt>
D:
01:38
<karlcow>
another pattern is: 1. we have an issue, we would like to add this feature
01:38
<karlcow>
2. No no don't touch the core
01:38
<karlcow>
3. But we still need to solve our issue
01:38
<karlcow>
4. Ah do for you own class of products, it's not our business
01:38
<karlcow>
5. ok we are fixing the issue ourselves
01:38
<karlcow>
6. Oh my god but you changed the core architecture
02:27
<MikeSmith>
is Encrypted Media Extensions support already enabled in Chrome?
02:27
<MikeSmith>
watching https://developers.google.com/live/shows/38132276-1/
02:28
<MikeSmith>
in that video John Luther seems to be saying it is
02:28
<MikeSmith>
Chrome video PM
02:43
MikeSmith
finds https://src.chromium.org/chrome/trunk/src/third_party/widevine/cdm/
02:43
<MikeSmith>
"This directory contains build files for integrating the Widevine CDM into Chrome."
05:12
<Hixie>
any whatwg blog people around?
05:34
<MikeSmith>
Hixie: dunno what you mean by blog people but I got blog perms of some kind
06:33
<SteveF>
Mikesmith: just arrived via google alert http://gigaom.com/2013/02/27/google-webm-video-rentals/
06:39
<othermaciej>
SteveF: does that use EME?
06:39
<SteveF>
unsure, but he did talk about EME in video
06:40
<SteveF>
"Luther went on to explain that Google did a lot of work on the security layer that delivers the videos encrypted to an HTML5 player. “As far as I know, we are the first to ever do that,” he said."
06:51
<MikeSmith>
thanks SteveF
06:51
<MikeSmith>
othermaciej: yeah it does
06:52
<MikeSmith>
I assume with Widevine
06:52
<MikeSmith>
so EME is now not only implemented, it's deployed in a production service
06:53
<MikeSmith>
oh MSE too
06:53
<MikeSmith>
he mentions that too in the video
06:54
<MikeSmith>
in the context of using it for adaptive streaming
06:54
<MikeSmith>
he says "like DASH"
07:22
<hsivonen>
MikeSmith: any info on whether Chrome's CDM supports ISO Common Encryption, too?
07:23
<MikeSmith>
dunno but I think the code is in the chromium svn repo
07:25
<MikeSmith>
hsivonen: http://src.chromium.org/svn/trunk/src/webkit/media/crypto/ppapi/
08:07
<MikeSmith>
hmm there's a submodule under that in my working directory
08:08
<MikeSmith>
with an 18KB content_decryption_module.h header file in it
09:38
<hsivonen>
so did HTTP 1.1 bis address othermaciej's comments yet?
10:51
<MikeSmith>
so apparently the EME stuff is already enabled in current desktop Chrome
10:51
<MikeSmith>
23+
10:52
<MikeSmith>
http://downloads.webmproject.org/adaptive-encrypted-demo/adaptive/index.html
10:52
<MikeSmith>
is a demo
10:52
<MikeSmith>
the Key Exchange Info part there doesn't show anything
10:52
<MikeSmith>
but a bunch of stuff is logged to the console
10:53
<MikeSmith>
doNeedKey() .. adding key for the following session
10:54
<MikeSmith>
webkit-org.w3.clearkey
10:54
<MikeSmith>
hsivonen: they have implemented support for ISO Common Encryption
10:54
<MikeSmith>
https://code.google.com/p/chromium/issues/detail?id=132351
10:56
<MikeSmith>
and see the Encrypted Media Extensions section of http://www.chromium.org/developers/web-platform-status
10:56
<annevk>
morning
10:57
<MikeSmith>
hi annevk
10:58
<MikeSmith>
also http://wiki.webmproject.org/encryption/webm-encryption-rfc
10:58
<ronaldmansveld>
morning annevk
10:58
<annevk>
ronaldmansveld: I saw you had a question about CORS?
10:59
<ronaldmansveld>
yeps, indeed
11:00
<ronaldmansveld>
I don't have the resources i found open atm (not at home), so I have to do this from the top of my head, but shouldn't CORS and CSP be related?
11:02
<ronaldmansveld>
since I don't feel that the security should be handled completely by the server when doing cross-domain requests, but also by the original content
11:02
<ronaldmansveld>
after all, it's easy for a browser plugin to inject some JS, which will then contact a malicious server. that malicious server will always respond with Allowed-Origin: *
11:03
<ronaldmansveld>
(if you want to, i can make a more complete story out of this on email)
11:04
<annevk>
You can already transmit data to a malicious server without CORS
11:04
<annevk>
The only case where that is made somewhat easier is XMLHttpRequest (it used to never do a cross-origin request), but we cannot change that now.
11:04
<annevk>
ronaldmansveld: ^
11:05
<ronaldmansveld>
but doesn't that mean that CORS will actually open up a security hole? (which then can be closed by implementing CSP)
11:07
<annevk>
ronaldmansveld: Only if your application allows arbitrary URLs to be passed to XMLHttpRequest, which would be a silly thing to do to begin with...
11:08
<annevk>
ronaldmansveld: And only if that's the only place the code would leak, and not say you could inject an image request somewhere...
11:08
<ronaldmansveld>
maybe my application doesn't, but a malicious browser-plugin might inject code that triggers a cross-domain XHR
11:10
<annevk>
ronaldmansveld: I don't know CSP specifics unfortunately, but I assume it can control outgoing requests, yes
11:10
<annevk>
ronaldmansveld: dude, if your software is malicious you are already lost
11:10
<ronaldmansveld>
and true, there are many other ways to leak, but it feels like CORS is incomplete without mentioning CSP to implement security in the application, instead of relying on the cross-domain server and checking the result
11:10
<ronaldmansveld>
CSP spec: http://www.w3.org/TR/CSP/
11:10
<ronaldmansveld>
and yes, CSP controls outgoing requests
11:11
<annevk>
CORS is not about security, it's just about making cross-origin fetching possible
11:12
<annevk>
Hmm, I don't want to stonewall you. So apologies if it came off as that.
11:12
<ronaldmansveld>
no, that's OK, I just felt that the security aspect was missing in some way
11:13
<ronaldmansveld>
but now I understand that that wasn't the intention of CORS
11:13
<ronaldmansveld>
so CORS and CSP are in fact complimentary
11:13
<darobin>
indeed
11:13
<annevk>
XMLHttpRequest had a change in behavior, that might have been a bad choice in retrospect, but it's been deployed across browsers for many years now. CORS did incite that change in behavior, but CORS is mostly about making sharing cross-origin resources possible.
11:13
<annevk>
ronaldmansveld: yes they are
11:14
<ronaldmansveld>
in that case: wouldn't it be a good idea to at least mention CSP in the CORS-spec?
11:15
<darobin>
well, a lot of things are complementary
11:15
<darobin>
doesn't mean we should mention them all :)
11:20
<ronaldmansveld>
True, but since the CORS-spec has 4 parts on security (4, 6.3, 7.3, 8.4) it felt to me it was incomplete by not mentioning CSP. And indeed no need to mention them all, but I thought this would indeed make a good case
11:23
<annevk>
CORS concerns with respect to security are about protecting the contents of cross-origin resources that are not meant to be shared.
11:24
<annevk>
Those are very different concerns from protecting the data of the application that might initiate a CORS request.
11:24
<ronaldmansveld>
I see, then I might have had different expectations from the CORS-spec
11:25
<ronaldmansveld>
I'm gonna grab a quick lunch in the meantime, brb
11:40
<hsivonen>
annevk: thanks for the quick WONTFIX on making the set of encodings open-ended
11:40
<annevk>
hsivonen: Norbert mentions that to me every now and then, I tell him it's a bad idea, not sure why it now went through a bug
11:55
<hsivonen>
annevk: fwiw, my understanding is that the Indian pages in question rely on being decoded as windows-1252
11:55
<hsivonen>
annevk: so the semantics of the characters are all wrong in browsers
11:55
<hsivonen>
annevk: but can't change that without breaking the font dependency
11:56
<hsivonen>
annevk: so adding encodings to a browser spec is unlikely to be a good idea
11:56
<hsivonen>
annevk: it's understandable why Googlebot might want to get seachable characters out of the mess, though
11:57
<hsivonen>
annevk: but OTOH, it's pretty uncool for Google to point users to pages of that level of bogosity
11:59
<hsivonen>
anyway, the right fix to avoid making Googlebot conforming would be "if you are a search engine bot, you may decode Indian legacy pages in a way that violates this spec"
11:59
<hsivonen>
not making it open-ended for browsers
12:00
<hsivonen>
(I had thought those legacy pages went away with Netscape 4.)
12:01
<annevk>
Reportedly there are some Firefox extensions that do the same thing as Googlebot. I guess you might get searchable results in such pages then? I haven't studied the details.
12:04
<annevk>
I wonder if I should go to WebApps...
12:05
<gsnedders>
hsivonen: Carakan (as in the script) has the same font-dependencies.
12:06
<gsnedders>
(Probably in part because it was only just added to Unicode in 5.2)
12:06
<annevk>
Oh that's easy. I can't attend because I'm not a member of the group.
12:07
<jgraham>
?
12:08
<annevk>
jgraham: registration is mandatory and you can't use the registration form if you're not a member.
12:09
<hsivonen>
annevk: https://addons.mozilla.org/en-us/firefox/addon/padma/ might be worth investigating
12:11
<annevk>
hsivonen: I rather not get into that unless we get more serious about doing something like that
12:11
<annevk>
(I suspect we won't ever.)
12:11
<hsivonen>
that's so sad considering that those languages have been in Unicode for a long time
12:12
<hsivonen>
"that" referring to what the extension does
12:12
<hsivonen>
not what you said
12:12
<annevk>
Yeah, I don't really understand what the problem is. I guess lack of OS support.
12:13
<gsnedders>
Legacy, as well, I expect. "This is how you do it".
12:13
<Ms2ger>
What this guy said
12:13
<hsivonen>
gsnedders: sounds right
12:13
<gsnedders>
"If you want to use the web, you set this font as the default"
12:17
<hsivonen>
Devanagari seems to have been in Unicode since 1.0
12:17
<gsnedders>
Given it's a SBCS, is there any reason we cannot just define a new charset for it?
12:17
<hsivonen>
i.e. for two decades
12:17
<hsivonen>
gsnedders: there seems to be a bewildering number of them—not just “it”
12:17
<hsivonen>
For how long has Windows supported Devanagari?
12:18
<gsnedders>
hsivonen: How many are we talking about?
12:18
<gsnedders>
hsivonen: (And how long in all locales?)
12:19
<hsivonen>
gsnedders: around 60, it seems, but I didn't look carefully and might have miscounted or misunderstood
12:19
<gsnedders>
hsivonen: Just for the Indian subcontinent?
12:20
<hsivonen>
gsnedders: right
12:20
<hsivonen>
see http://padma.mozdev.org/
12:20
<gsnedders>
Because there's certainly such things elsewhere too.
12:22
<jgraham>
annevk: I totally missed what you're not registering for
12:22
<jgraham>
Hence my "?"
12:26
<gsnedders>
hsivonen: Still tempted to say we should define them…
12:27
<hsivonen>
are the pages involved labeling their encoding in any sane way? (I'm guessing no.)
12:27
<gsnedders>
I'm similarly guessing no.
12:28
<annevk>
jgraham: I see
12:30
<gsnedders>
hsivonen: Random things on the Padma list seem to explicitly declare types, and work fine without fonts.
12:32
<gsnedders>
http://www.rajasthanpatrika.com/ seems to be text/html per HTTP, and has multiple meta elements. Uses UTF-8, ultimately, declared.
12:32
<gsnedders>
Changing charset after parsing has startd.
12:32
<gsnedders>
Most seem to be like that.
12:33
<gsnedders>
http://www.andhrabharati.com/ relies on fonts, on the other hand
12:33
<jgraham_>
annevk: Well at least one of us does :)
12:34
<gsnedders>
HTTP text/html, meta text/html; charset=x-user-defined
12:34
<annevk>
heh
12:34
<gsnedders>
Uses EOT to support IE in general.
12:35
<MikeSmith>
what's Hixie up to with that ⌛ character in the algorithms for srcset in the spec?
12:35
<MikeSmith>
what does it indicate?
12:36
<MikeSmith>
are there other algorithms in the spec that have that?
12:36
<gsnedders>
hsivonen: Problem is how to switch to right encoding, really
12:37
<MikeSmith>
my chromium/chrome don't actually display the hourglass glyph for it
12:37
<MikeSmith>
though Firefox does
12:38
<jgraham_>
MikeSmith: File a bug report and submit a testcase? :)
12:40
<MikeSmith>
well I don't care so much of it displaying, I'm just wondering what it's supposed to mean
12:41
<MikeSmith>
"This step takes a lot of time"? "There's a sleep here"?
12:42
<MikeSmith>
http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#typographic-conventions provides no clues
12:43
<MikeSmith>
oh
12:43
<MikeSmith>
nm
12:43
<MikeSmith>
found it
12:44
<MikeSmith>
"Steps in synchronous sections are marked with ⌛."
12:54
<Ms2ger>
Oh, wow, xchat found a character for that
12:56
<odinho>
WTF. The hourglass has colors here! :|
13:06
<hsivonen>
odinho: Emoji font outside Emoji range?
13:11
<MikeSmith>
has colors on OSX at least I guess
13:11
<MikeSmith>
maybe not emoji but repurposing some platform UI widget thing?
13:25
<odinho>
Yeah, I'm currently on OS X for a short while.
13:30
<MikeSmith>
http://homakov.blogspot.fr/2013/02/url-detection-with-hash-history-i-know.html
13:38
<annevk>
hsivonen: http://wiki.whatwg.org/wiki/Encrypted_Media_Extensions_Impact
13:40
<annevk>
hsivonen: Yeah, Apple has done that for a number of Emoji that were already present in Unicode
13:52
<annevk>
karlcow: can you test Location: /lo1, /loc2 as well?
13:52
<annevk>
karlcow: theoretically headers can be combined in that way
13:53
<jgraham>
odinho: s/hourglass/spinning beachball of death/
13:53
<annevk>
karlcow: I doubt it actually works in practice that way, but that's how the HTTP guys have it modelled still
13:54
<jgraham>
Oh wait, I am confused
13:54
<odinho>
jgraham: You are, you are...
13:54
<jgraham>
Therefore I think?
13:55
<karlcow>
annevk: yup. I'll do that now
14:04
<karlcow>
annevk: http://lists.w3.org/Archives/Public/www-archive/2013Feb/0093.html
14:07
<annevk>
karlcow: yeah, as expected
14:07
<annevk>
so easy to find bugs
14:07
<annevk>
thanks
14:07
<karlcow>
my pleasure
14:15
<karlcow>
⌛ no color for me on XChat on MacOSX ☺ but I guess it is not using WebKit for rendering it
14:16
<karlcow>
⌛⌛⌛⌛ hmm
14:39
<manu-db>
annevk, hsivonen: The PING (privacy WG) has invited me to come and discuss privacy implications of the EME spec with them today (12pm EST) - I was going to cover DNT and backdoor implications in CDMs, any other material that you think is worth covering?
14:41
<annevk>
manu-db: The notion of privacy and DRM at the same time seems kind of ironic
14:42
<manu-db>
annevk: Well yeah, there's that - I mean, there are the obvious "mathematical impossibility" arguments here... just wondering if there are specific browser concerns you wanted me to point out.
14:43
<manu-db>
It was going to be just me outlining the EME spec during the call, but the EME editors caught wind of it and instead offered to lead the discussion, bumping me to just comment on what they're saying.
14:44
<manu-db>
so, if there are browser manufacturer concerns (either official, or personal opinion), I thought I'd ask to see if anyone on here would want me to convey those concerns to the PING group.
14:44
<annevk>
manu-db: o_O The main problem I see is making this feasible in a way that works across browsers and platforms. But I'm not sure that has much baring on privacy.
14:44
<manu-db>
there's the concern that Mozilla wouldn't be able to do an open CDM implementation, there the DNT concerns, the backdoor concerns... anything else?
14:44
<annevk>
(The o_O was for the EME editor intervention thingie.)
14:44
manu-db
figured. :)
14:46
<manu-db>
annevk, hsivonen: Did you see this suggestion? http://www.brucelawson.co.uk/2013/more-on-drm-in-html5/#comment-1314315 -- has that approach been gaining any traction w/ Mozilla/browser manufacturers?
14:46
<zewt>
well, this sounds a bit pointless :)
14:47
<annevk>
manu-db: I think the main concern is that there is some kind of closed system outside the browser's control. I.e. we got rid of plugins but we introduce them again for DRM meaning the web does achieve its full potential and whatnot (as it's not cross-platform).
14:47
<zewt>
i mean, i can't imagine anyone implementing these closed-web drm things to be influenced by what any WG says
14:47
<annevk>
manu-db: but you mentioned that
14:48
<manu-db>
zewt: Well yes... but somebody has to go in and balance the conversation... lots of folks don't understand the implications of the EME spec, so we have to do some grassroots education on the matter. If we can get PING commenting about privacy implications, that's less work that the rest of us have to do on that front. (that's the theory, anyway)
14:48
<zewt>
it pretty much kills any pretense of the w3 being about an open web, that they're allowing a spec like that under their name
14:49
<zewt>
manu-db: but anyone implementing it in a real production browser does understand it
14:49
<zewt>
and regular users don't care--and there aren't many other parties with any influence on the situation, i would think
14:49
<rcombs>
could element.scrollIntoView be given a second argument that enables animating the scroll?
14:49
<zewt>
not to say don't try, just call me skeptical :)
14:50
<zewt>
rcombs: android scroll* already does animate :( or it did at some point, maybe they fixed that
14:51
<manu-db>
zewt: I think regular users do care once it's explained to them. I'm skeptical as well, but we have to try our best to explain what's at stake here. We can have enough of an impact on the W3C process if there are enough people commenting on the broken-ness of some of the stuff in EME.
14:52
<zewt>
rcombs: animation is tricky, and there are a lot of half-designed, brittle animation things already (css transitions and animations, which have lots of weirdness), so I'd suggest not adding any more animation stuff without doing a more thorough design
14:52
<rcombs>
zewt: well, in that case, a more thorough design is in order
14:53
<rcombs>
zewt: because scrollIntoView is pretty jarring at the moment
14:54
<Ms2ger>
XHR1 is back, eh
14:55
<annevk>
Ms2ger: is it?
14:57
<annevk>
manu-db: FWIW, roc from Mozilla I think brought forward the constraints "the web" has at some point
14:57
<zewt>
tired of asking "what's the use case for this big, complex thing" and all i can get is "it seems convenient"
14:57
<rcombs>
manu-db + zewt: my $0.02: I think the web standards should leave out DRM and wait for web devs to be forced to drop it altogether when plugins stop being as widely installed
14:57
<Ms2ger>
That would certainly work for me...
15:02
<annevk>
manu-db: http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0117.html and the email referenced therein are probably good to read
15:02
<annevk>
manu-db: I've not kept up to speed myself
15:03
manu-db
thanks annevk. (afk to chair RDFa WG call)
15:03
<odinho>
I like the XHR: The attorney edition name.
15:03
<rcombs>
DRM introduces o9k problems, it goes against open web principles, and it doesn't seem worth implementing
15:04
<zewt>
"worth implementing" is something that can only be decided by implementors
15:04
<odinho>
netflix and microsoft and google is pushing hard though. It's business business.
15:05
<Ms2ger>
odinho, maybe we should call webapps "WHATWG: The attorney edition" ;
15:05
<Ms2ger>
)
15:05
<zewt>
Ms2ger: "feat. Microsoft"
15:05
<rcombs>
zewt: II: Electric Boogaloo
15:06
<annevk>
"excl annevk for copyright reasons."
15:06
<annevk>
"incl x, y, z to replace annevk."
15:06
<annevk>
(they do a much better impression of me anyway)
15:27
<SteveF_>
zewt: "it pretty much kills any pretense of the w3 being about an open web, that they're allowing a spec like that under their name" pretty much kills pretense of Google being about the open web as well then right
15:27
<Ms2ger>
Google isn't about the open web
15:28
<SteveF_>
Ms2ger: so who is?
15:28
<Ms2ger>
Mozilla, duh!
15:28
<gavinc>
Mozilla ;)
15:29
<SteveF_>
apart from Mozilla?
15:29
<darobin>
where does Mozilla's money come from?
15:29
<SteveF_>
closed web sources
15:30
<gavinc>
No see if you launder the money first then it's fine... or something
15:30
<SteveF_>
all seems a bit simplistic to claim w3c is not about open web
15:31
<darobin>
I'm too lazy to scroll back — are we talking about DRM?
15:32
<SteveF_>
so only browser vendor that is about open web is mozilla the rest are in it for the money and self interest
15:33
<Ms2ger>
Do you disagree?
15:33
<SteveF_>
no
15:33
<SteveF_>
but I am a simpleton
15:35
<SteveF_>
whatwg, w3c etc are all in same boat , the good ship Kapital!
15:41
<marcosc>
I hear there is good money to be made in this internets thing! where do I sign up?
15:44
<SteveF_>
profit's the noose of the open web
15:46
<annevk>
Afaict Google has many interests, not all of them good for the web
15:58
<SteveF_>
annevk: probably the same for any organization to a lesser or greater degree, somebody should write a book about it '50 shades of Open Web'
16:28
<Ms2ger>
https://twitter.com/sgalineau/status/306805978135924736
16:31
<miketaylr>
sylvain loves opera
16:32
<marcosc>
if you are going to mention Opera on twitter, you are going to have a bad time :)
16:33
<jgraham>
Yeah, that miketaylr will be right in your face
16:33
<miketaylr>
but it will be fun to tease him about UX when he's working for [redacted]
16:33
<Ms2ger>
Adobe
16:34
<Ms2ger>
It's in the CSSWG conf call minutes
16:34
<miketaylr>
ok, un-redact that then
16:34
<miketaylr>
dact it? O_o
16:34
Ms2ger
duct-tapes MikeSmith
16:35
<jgraham>
Is that usually how you treat sleeping men?
16:35
Ms2ger
tears it off, attaches to miketaylr instead
16:35
<zewt>
:|
16:35
<miketaylr>
he should be awake after that
16:40
<darobin>
MikeSmith: can sleep quite soundly
16:43
<jgraham>
Probably Ms2ger drugged him before duct taping him
16:44
<MikeSmith>
I'm using the extra duct tape to patch the carburetor on my browser engine
16:45
<annevk>
The web could use some duct tape
16:46
<annevk>
Also, for the longest time I thought it was duck tape
16:46
<annevk>
And I didn't get it
16:47
<darobin>
hahaha
16:47
<darobin>
lovely Mondegreen
16:48
<jgraham>
But it *is* duck tape
16:49
<jgraham>
I think duct tape is the newer term
16:49
<Ms2ger>
Would you rather fight a tape-sized duck or a hundred duck-sized tapes?
16:50
<miketaylr>
"In 1942 Revolite, then a division of Johnson & Johnson, originally developed an adhesive tape made from a rubber-based adhesive applied to a durable duck cloth backing." huh
16:50
<miketaylr>
TIL duck isn't just some brand
16:52
marcosc
wants a leisure suit made out of duck cloth
16:52
<marcosc>
make that "durable" duck cloth... none of that cheap stuff!
16:53
<darobin>
wtf is duck cloth
16:54
<darobin>
btw if you're French you want to share the love: https://twitter.com/LesAutruches/status/307140744764858369 :)
16:54
darobin
prods SimonSapin --^
16:55
<SimonSapin>
après les pigeons, les autruches ?
16:55
<darobin>
c'est mieux, lis le texte :)
16:56
<marcosc>
"Faced with the absurdity of the IHR, URSSAF et al: The Manifesto Ostriches" ?
16:56
<darobin>
hey, not so bad
17:01
<dglazkov>
good morning, Whatwg!
17:01
<dglazkov>
the scrollback looks dangerously nsfw
17:02
<marcosc>
dglazkov: you will love it. It involves a lot of duck tape, MikeSmith, and leisure suits
17:03
<dglazkov>
just another day in the Web standards community
17:46
<annevk>
marcosc: so the TAG thing is 60min from now?
17:46
annevk
just realized he hasn't set up W3C IRC
17:46
<marcosc>
aww. God. That... I guess .
17:47
<marcosc>
oh, CVS
17:47
<marcosc>
DONT FORGET THE CVS annevk!
17:47
<annevk>
I don't want to go there really
17:47
<marcosc>
I nearly lost it
17:47
<annevk>
I think the public key I gave the W3C once has long been obsoleted
17:48
<marcosc>
I hit reply, ... started typing... closed the window.... hit reply again... started typing... deleted the draft again.
17:48
<annevk>
Also, CVS
17:48
<marcosc>
yeah, same happened to me
17:48
<marcosc>
I'm not going through that mess again
17:49
<marcosc>
I think I once wasted 2 hours trying to get CVS working with the w3c server + 24 hour wait for them to install my key
17:50
<marcosc>
anyway, yeah... call in one hour
17:50
<annevk>
I have instructions for W3C CVS on my blog somewhere, but I really rather not
17:51
<marcosc>
lets get slightlyoff to say we are using GitHub
18:10
<annevk>
odinho: fwiw, it'd be interesting to know if IE fails for e.g. 203 or 299
18:11
<annevk>
odinho: given that just allowing 200/204 is one of the paths forward
18:18
<manu-db>
annevk, zewt, rcombs, SteveF_: DRM in HTML5 (EME) discussion in Privacy Working Group - http://www.w3.org/2013/02/28-privacy-minutes.html#item01 (glad to see hsivonen on that call as well - good job on the network-access-knowability comments, btw)
18:19
<annevk>
"Less use ofd plugins is good, more use of HTML is good." So we'll give you some new plugins!
18:19
<annevk>
Flawless victory!
18:20
<annevk>
(I'm not helping, I know.)
18:23
<annevk>
It seems we did not move anywhere though. The story is still that the CDM is a black box.
18:24
<marcosc>
ridicule is the best form of medicine
18:27
<annevk>
"<adrianba> hsivonen, yes, i see your comments - i think this is the key thing we will need to address but i think mostly what we can do is call out considerations for CDM implementers"
18:27
<annevk>
That's the spec language equivalent of "Fuck you"
18:51
<TabAtkins>
scott_gonzalez: Spec is done. I'm doing editorial tweaks and inviting final review before we hit LC and then CR. WebKit already has an impl (hidden behind a flag, and bizarrely prefixed), and FF is working on one as well.
18:52
<TabAtkins>
scott_gonzalez: Also, if you need a CSS parser in JS, try mine: https://github.com/tabatkins/css-parser It matches the Syntax spec (well, now a slightly older revision of the spec, but I pick it up and sync the code every once in a while).
19:26
<scott_gonzalez>
TabAtkins: Thanks. I'll check out the css-parser :-)
20:52
<annevk>
What I really miss in Gmail is "edit the filters for this label"
20:53
<annevk>
Or am I overlooking that?
20:53
<zewt>
i always have to dig through the filters to find the one for a label
20:59
<annevk>
also, editing filters is confusing and basic stuff like "list:a list:b" does not work...
21:00
<Hixie>
woot, the spec and firefox are secure http://feross.org/fill-disk/ :-)
21:01
<zewt>
also as far as i know the only way to have one filter eg. "from:address", and a bunch of other filters like "from:address something", without the latter falling into the first, is to encapsulate every single filter into the first giving "from:addres -something -somethingelse"
21:01
<annevk>
Hixie: prolly not against entities that have loads of domains ;-)
21:01
<zewt>
which is terrible, since i want work email to go to one box, unless it's from our bug tracker or release notifications or whatever in which case i want it in a sublabel
21:05
<Hixie>
annevk: they cost money, so i'm not so worried about those
21:05
<Hixie>
annevk: a million subdomains costs the same as a hundred, but a million domains costs ten thousand times more than a hundred.
21:05
<annevk>
unless you get your domain on publicsuffix.org somehow
21:06
<annevk>
and there's stuff like dyndns on there iirc, not sure what their policies are
21:06
<annevk>
but yeah, it's a lot better than just checking the origin
21:12
<jgraham>
annevk: You could, you know, not use gmail?
21:12
<jgraham>
Or at least not use the web ui
21:12
<zewt>
if you change software every time you find something stupid in them, you won't have any software left to use
21:13
<annevk>
jgraham: I haven't found a good client for it
21:13
<jgraham>
Isn't any imap client a potential client?
21:14
<zewt>
in my experience, everything imap is terrible
21:15
<jgraham>
zewt: Yeah, but in this case moving from a frontend that you like to one that you don't because the backend changed, even though the frontends both work seems weird
21:15
<zewt>
parse error
21:17
<annevk>
jgraham: sure, but none of them quite match Gmail I've found. Though M2 was pretty good
21:19
<SimonSapin>
zewt: what’s wrong with imap?
21:20
<zewt>
been a while, but i just remember it being slow and clumsy
21:36
<odinho>
Hixie: Don't think that works as well in Opera.
21:45
<Simon______>
hi
21:47
<Simon______>
I was wondering would allow to cache the current page be possible ? Something like window.cache.save("a-new-etag");
21:50
<Simon______>
In application cache we can ask the browser to get updates from the server, but is it difficult/bad to ask the browser to cache the current computed page ?
21:58
<Simon______>
I rephrase : why HTML5's applicationCache doesn't allow to cache the current (computed) page (with no request to the server) ?
22:00
<annevk>
Simon______: you can already cache a page via HTTP
22:01
<Simon______>
yep but after some AJAX calls & DOM updates the cache is obsolete
22:02
<Simon______>
now if the user goes offline, the cached version will be obsolete
22:04
<annevk>
Oh, so you want the DOM serialized to disk? That seems unlikely to happen as that would require a lot of difficult changes.
22:04
<Simon______>
Oh ok
22:04
<Simon______>
I guessed so
22:04
<annevk>
You could store the changes via Indexed DB and apply them at onload or some such...
22:05
<Simon______>
I was asking myself that question :)
22:05
<Simon______>
Thank you
22:06
<annevk>
FWIW, there are some plans to design a better application cache, if you check back in a month or so there should be some proposals out there. Though serializing the DOM to disk will still not be covered I'm afraid ;-)
22:23
<Simon______>
@annevk I have other worries about appCache, I hope the future updates will cover them
22:24
<Simon______>
For example appCache doesn't seem great for "mixed data & logic" sites
22:27
<Simon______>
Applying updates with the help of indexedDB is nice, but still the user see the old data for a fraction of second
22:28
<Simon______>
What would be great would be able to specify another page for the offline.
22:29
<Simon______>
So when online you get a page "logic + data", and when offline you get a page login only
22:29
<Simon______>
(and then you can load the data from indexedDB)
22:30
<Simon______>
err I meant 'when offline you get a page of "logic" only'
23:30
<JonathanNeal>
http://www.w3.org/TR/css3-values/#attr-notation want want want want want
23:31
<JonathanNeal>
content: attr(src, url)
23:56
<Hixie>
do we prefer the spec to have obvious optimisations in its algorithms, or do we prefer to the spec to be extremely consistent to the point of being inefficient in its algorithms?
23:59
<Hixie>
e.g. do i prefer mode 1: if (A) { do X, then back up and go to mode 2 } else { back up then go to mode 2 }; mode 2: if (B) { ... } else { do Y }
23:59
<Hixie>
or do I prefer mode 1: if (A) { do X, do Y, go to mode 2 } else { back up then go to mode 2 }; mode 2: if (B) { ... } else { do Y }