00:00
<zcorpan>
maybe because the CP makes a substantive change for an editorial issue
00:00
<Hixie>
ok well then someone file the bug, i'll fix it, and then his issue will be moot and we can get on without worrying about process
00:00
<zcorpan>
have a pointer to foolip's CP?
00:01
<Hixie>
http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType
00:01
<Hixie>
though note that the chairs haven't actually said it's not valid and indeed still list it in issue-status
00:02
<Hixie>
so i'm very confused about whether it's valid or not
00:02
<Hixie>
they even explicitly said foolip didn't have to retract it, iirc
00:14
<benschwarz>
zcorpan: I can work something out for you. after the next week the mass changes will start to settle though
00:14
<zcorpan>
benschwarz: cool
00:15
<zcorpan>
Hixie: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984
00:15
<benschwarz>
Hixie: Is there a way to set a wildcart against a domain for appCache to continue to cache any resources that are used in a site for offline use?
00:16
<Hixie>
zcorpan: can you post on the thread just saying "i filed a bug for foolip"? that way i can reply saying i've done it
00:18
<zcorpan>
done
00:18
<Hixie>
thanks
00:30
<zcorpan>
nn
01:54
<Yuhong>
syntax.whatwg.org seems to be dead.
02:02
<abarth>
Hixie: i updated the sniffing draft to have a hook for sniffing video specifically
02:02
<abarth>
Hixie: do you need one for other kinds of media?
02:05
<abarth>
i posted on the bug
02:53
<Yuhong>
abarth: <!-- is not an indication of HTML. It is a generic SGML/XML comment.
02:59
<Hixie>
Yuhong: where did you get a link to syntax.whatwg.org?
03:00
<Hixie>
abarth: i think anne was asking for fonts, but media is all i need at this point. I'll add specific sniffing as a separate thing later, I don't honestly expect the text so far to remain out of the spec
03:00
<Yuhong>
Don't remember, but I was looking for the unofficial SGML declaration for HTML5.
03:00
<Hixie>
abarth: but thanks
03:01
<Hixie>
Yuhong: ah. There's no SGML declaration for HTML, HTML isn't anything to do with SGML any more
03:01
<Yuhong>
That is why I said "unofficial".
03:02
<Yuhong>
I think the main disadvantage of parsing HTML5 this way is the different error handling. For a web browser I wouldn't trust it.
03:04
<Yuhong>
It used to be on syntax.whatwg.org
03:07
<Yuhong>
As a bonus, with a different SGML declaration, XHTML can be parsed with the same SGML parser thanks to XML being compatible with SGML!
03:08
<Yuhong>
Hixie: BTW, have you heard of mangleme?
03:20
<othermaciej>
parsing HTML with an SGML parser...
09:23
<zcorpan>
Hixie: shouldn't workers have ononline and onoffline event handlers too?
09:32
<annevk>
haha
09:32
<annevk>
so zcorpan actually went ahead and raised the bug and Hixie fixed it
09:33
<annevk>
zcorpan, interesting observation on twitter btw
09:34
<annevk>
zcorpan, seems From-Origin is really quite useful
09:34
<zcorpan>
yeah
09:34
<zcorpan>
but i hate the name
09:35
<annevk>
if you think of something better
09:36
<zcorpan>
someone here suggested Restrict-Embedding-To or something like that
09:36
<annevk>
Embedding-Origin
09:36
<zcorpan>
wfm
09:37
<zcorpan>
or Embedding-Origins to allow multiple origins
09:37
<annevk>
yeah, I guess at some point it should allow a comma-separated list
09:37
<zcorpan>
Embedding-Origins: http://developers.whatwg.org http://simon.html5.org
09:37
<othermaciej>
annevk: I think I am going to post to www-fonts or the font wg list proposing Restrict-Embedding (or From-Origin or whatever you want to call it)
09:37
<othermaciej>
instead of SOR
09:37
<othermaciej>
for all resource types
09:38
<othermaciej>
we'll see how that goes
09:38
<zcorpan>
cool
09:38
<annevk>
zcorpan, space-separated has different semantics for Origin / Access-Control-Allow-Origin
09:38
<annevk>
zcorpan, it means the redirect chain
09:38
<zcorpan>
annevk: oh
09:38
<othermaciej>
I will explain the three-way difference among linking, embedding and reading, and how the Web has historically treated them
09:39
<othermaciej>
I think it should have the same syntax (and rough semantics) as Access-Control-Allow-Origin
09:39
<zcorpan>
annevk: well, seems useful to be able to allow multiple origins to embed your stuff in some way without jumping through hoops
09:39
<annevk>
othermaciej, see pm
09:39
<annevk>
zcorpan, yeah, could be Embedding-Origins: same, http://example.com
09:40
<zcorpan>
+1
09:40
<othermaciej>
except that header missing means allow all, not deny all, of course
09:40
<othermaciej>
I don't think you should have to explicitly list same
09:40
<othermaciej>
same-origin embedding should always be allowed
09:40
<othermaciej>
is there a use case for denying it?
09:41
<zcorpan>
good point
09:41
<annevk>
othermaciej, you mean if you just specify Embedding-Origins same is implied?
09:41
<Hixie>
zcorpan: yeah probably
09:41
<Hixie>
zcorpan: file a bug
09:41
<annevk>
wfm
09:41
<Hixie>
zcorpan: or send mail or something
09:41
<othermaciej>
Access-Control-Allow-Origins doesn;t have to list "same"
09:41
<othermaciej>
I mean, same-origin access is always allowed, and if the special header is present, then only those other headers are allowed access instead of all others
09:42
<annevk>
well, CORS is way different
09:42
<annevk>
CORS is about allowing, this is about denying
09:42
<othermaciej>
there's no way to deny same-origin reading
09:42
<othermaciej>
so I don't think there needs to be a way to deny same-origin embedding
09:43
<zcorpan>
Hixie: done
09:43
<othermaciej>
since you can always use reading to circumvent it anyway
09:43
<annevk>
yeah
09:43
<othermaciej>
having to list "same" is pretty much always what you want and having to include it is an inconvenience
09:43
<annevk>
but Embedding-Origins: same is nice
09:43
<annevk>
don't proxies sometimes strip empty headers?
09:43
<othermaciej>
I see, you want a way to say same-origin only
09:44
<annevk>
that is the most common case
09:44
<othermaciej>
I was thinking a CDN would be the most common use case, by volume of traffic served at least
09:45
<othermaciej>
anyway, "same" seems like a reasonable keyword for that
09:45
<annevk>
fair enough, but the "same" thing is what some font foundries want for their licenses
09:45
<zcorpan>
othermaciej: http://twitter.com/#!/zcorpan/status/33645906876174336
09:45
<annevk>
to require people serving it up with that
09:45
<annevk>
and yeah, it's also useful to protect against certain issues
09:45
<othermaciej>
I hope their licenses let people put a font on their own CDN to serve to their own main domain
09:45
<annevk>
and might be able to replace x-frame-options
09:46
<othermaciej>
as far as name bikeshedding, may I suggest Embed-Only-From-Origins:
09:46
<othermaciej>
if that's not too long
09:46
<annevk>
I don't really mind about the name that much
09:46
<othermaciej>
seems to be clear about what it does, and doesn't falsely imply that if you remove it, no embedding is allowed
09:47
<annevk>
it's no longer than Access-Control-Allow-Origin I think...
09:47
<annevk>
anyway, time to go skiing; ttyl
09:47
<othermaciej>
later!
10:25
<abarth|afk>
Embedding-Origins seems like something that should be part of CSP
10:52
<othermaciej>
doesn't seem related to the rest of CSP to me
10:52
<othermaciej>
although, I don't know that much about CSP
11:10
<abarth>
compare with frame-ancestors
11:10
<abarth>
which is a CSP directive
11:10
<abarth>
indicating which contexts can embed the resource
11:10
<abarth>
as an iframe
11:17
<othermaciej>
the rest of CSP doesn't really make sense for an image or a font
11:19
<othermaciej>
while it does fit with the CSP theme of denying things that are normally allowed and converting to a whitelist, it seems like overkill to use a policy language for hotlinking prevention
11:19
<othermaciej>
a key goal here is to make it substantially easier than checking an incoming Referer or Origin header
11:21
<abarth>
the counter argument that folks will make is that we're making our lives harder by proliferating policy locations
11:21
<abarth>
i'm not sure whether its that big a deal
11:24
<othermaciej>
I suspect when/if the suggestion gets posted on the fonts lists, that "it should be based on CSP" will not be one of the top 5 objections
11:24
<abarth>
:)
11:24
<abarth>
sure
11:25
<othermaciej>
I guess the reasons I am wary are:
11:25
<abarth>
but if/when you ask the mozilla folks if they'd like to implement it, i suspect it will be on their list
11:25
<othermaciej>
a) hotlinking prevention is somewhat tangention to security proper
11:25
<othermaciej>
*tangential
11:25
<othermaciej>
b) tying it to something complicated will delay progress and cut against the font vendors' desire for a solution in the short term
11:27
<abarth>
i should clarify that you don't really need to convince me
11:27
<othermaciej>
I just wanted to explain the grounds for my position
11:28
<abarth>
in some sense, this is also related to CORS
11:29
<abarth>
it's like giving access control information without being asked :)
11:30
<abarth>
i actually really like the idea
11:30
<abarth>
its super useful, especially for HTML pages
11:31
<abarth>
it would also be useful if it stopped embedding in a top-level frame
11:32
<abarth>
so that you could wall off the interior parts of your site from being linked to from outside your origin
11:33
<abarth>
i'd have to think more about that when i'm more awake
15:43
<karlcow>
would it be possible to capture the full rendering context as a series of images? A kind of webkit2png with a timer. Aka save 24 images by second in order to save a CSS3 animation, canvas animation, etc. by frame and make it a video after.
17:41
<annevk>
abarth, hey yt?
17:41
<annevk>
guess you might be sleeping
17:41
<annevk>
abarth, however, I did email font sniffing rules
17:41
<annevk>
abarth, http://www.ietf.org/mail-archive/web/websec/current/msg00235.html
18:29
<jgraham>
karlcow: All things are possible. But that is not possible from a normal security context
20:02
<Hixie>
well, nobody can say i didn't predict julian's objection
20:03
<boogyman>
Julian can :P
20:03
<tw2113>
he didn't leak it in time
20:03
<MikeSmith>
good times
20:04
<MikeSmith>
makes it all worthwhile
20:05
<MikeSmith>
meanwhile somebody seems to have decided that epub 3.0 document aren't allowed to have SVG animations
20:05
<MikeSmith>
http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-svg-restrictions
20:16
<Ms2ger>
Can has SVG fonts?
20:17
<MikeSmith>
heh
20:17
<MikeSmith>
I imagine not
20:17
<MikeSmith>
Ms2ger: I suggest writing a blog post about it
20:17
<MikeSmith>
title it whatever you want
20:18
<MikeSmith>
but make sure to use the word "myths"
20:18
<Ms2ger>
Not "considered harmful"?
20:18
<MikeSmith>
"Myths Not Considered Harmful" maybe
20:19
<Ms2ger>
1. Unicorns
20:20
<MikeSmith>
spec change requests based on mythical problem cases that aren't actually problems in practice not considered harmful
20:21
<Ms2ger>
...by Julian?
22:34
<MikeSmith>
question over on #html5 - <realityking> likely stupid question, is there DOM API to determine the language of an element (kinda like the ::lang() CSS pseudo-class, only that I don't want to check against a given value).
22:34
<MikeSmith>
<realityking> looking at the lang property doesn't help, because it seems the value is not inherited (unlike CSS where it does)
22:36
<annevk>
MikeSmith, matchesSelector() is what will allow that
22:37
<annevk>
though it won't return the language the element is in I suppose
22:37
<annevk>
just tells you whether or not it matches e.g. :lang(en)
22:39
<realityking>
annevk: thanks for trying to answer my question (language of an element)
22:40
<realityking>
from my understanding using matchesSelector() I can check whether an element would be included when going for a certain selector
22:41
<realityking>
That is quite helpful, but not quite what I'm looking for
22:41
<realityking>
I'd like to read out the language and process it
22:42
<annevk>
should be able to get it by walking up the tree
22:42
<realityking>
true
22:42
<annevk>
though you miss out on encapsulating data
22:42
<realityking>
that's what I'm doing
22:43
<realityking>
I was just surprised that the CSS :lang() selectors considers that language can be inherited, but there is no property on the element giving me that information
22:43
<annevk>
in retrospect .lang should have given you that
22:44
<Hixie>
why do you need it? (if it's a good use case, we might just add a way to do it)
22:44
<realityking>
annevk: from my testing that only works when the lang attribute is specified on that element
22:45
<annevk>
yeah, I meant if we designed it today
22:47
<realityking>
Hixie: HTML snippets send via AJAX and I need to know their language
22:47
<Hixie>
ah ok
22:47
<Hixie>
then just walking up the DOM should work fine
22:47
<realityking>
yeah it does
22:47
<Hixie>
just walk up the parentNode chain until hasAttribute('lang') returns true
22:47
<realityking>
just hoped there is a better solution that I missed
22:48
<realityking>
annevk: I guess we're 10 years late with that
22:49
<realityking>
Certainly not a feature one needs everyday
23:03
<annevk>
nn
23:12
<Hixie>
what's the implementation status of image borders?
23:13
<Hixie>
caniuse says browsers do it with prefixes
23:17
<othermaciej>
border-image you mean?
23:18
<othermaciej>
-webkit-border-image is pretty clearly prefixed
23:18
<othermaciej>
if that is what you had in mind
23:18
<webr3>
q, anybody know if it would be possible to get the browsers to generate key pairs and wrap them up in certificates, perhaps coupled to keygen?
23:27
<Hixie>
othermaciej: yeah that's what i meant by prefixed
23:27
<Hixie>
othermaciej: was wondering what the status of the spec was
23:55
<abarth>
webr3: its possible, but there isn't much momentum to do it now
23:59
<webr3>
abarth, that's good enough for me, cheers :)