| 07:01 | <MikeSmith> | does WebIDL not provide any way to annotate whether a certain object is live or static? |
| 07:49 | <Ms2ger> | MikeSmith, as in, nodelists? DOM could probably define that... |
| 07:50 | <MikeSmith> | Ms2ger: yeah was thinking of nodelists in particular |
| 07:51 | <Ms2ger> | WebIDL is completely oblivious to that |
| 07:52 | <Ms2ger> | But feel free to file a bug if you think that's useful |
| 07:52 | <MikeSmith> | kinda seems like it would be useful for collections in general |
| 07:52 | <MikeSmith> | OK |
| 08:25 | <Ancil> | annevk: hi |
| 08:59 | <Ancil> | Hixie: hi |
| 09:09 | <jgraham> | Ancil: Unless you are just here to greet people, I recommend going ahead and asking your question |
| 09:55 | <odinho> | jgraham: hi |
| 09:59 | <Ms2ger> | odinho: hi |
| 10:00 | <Ancil> | jgraham: I am new to #whatwg |
| 10:01 | <Ancil> | jgraham: i had few questions regarding sandboxed origin browsing context flag with respect to iframes |
| 10:04 | <Ancil> | if "sandboxed origin browsing context flag" forces the origin to unique origin, does that mean the CORS rules have to applied? |
| 10:05 | <Ancil> | or it should prevent other content from the same origin without any conditions |
| 10:08 | <odinho> | Ms2ger: Nice of you to say hi, you who steals all my collegaues. I'll be all alone here in the end! :| |
| 10:09 | <Ms2ger> | odinho, you don't have to... :) |
| 10:09 | <odinho> | I quite like Oslo :-) |
| 10:10 | <Ms2ger> | We've got a lot of remotees :) |
| 10:10 | <odinho> | Though I'm helping Mozilla set up a contributor meeting at my Hackerspace. Because I'm so nice. |
| 10:10 | <odinho> | Good guy odinho. -- But, lunch! :D |
| 10:11 | <Ms2ger> | Enjoy :) |
| 10:11 | Ms2ger | should get some too |
| 12:48 | <gsnedders> | How it template handled in XHTML? Do you manually have to move the subtree to be the template content and not its decendants? |
| 14:33 | <jgraham> | odinho: What do you like most? The rain or the eye-watering prices? :p |
| 14:33 | <jgraham> | Ancil: I'm not sure that I understand your question |
| 14:34 | <jgraham> | But I'm not an epert on snadbox or CORS |
| 14:34 | <jgraham> | *expert |
| 14:34 | <wilhelm> | jgraham: It's not rai-- oh, nevermind. |
| 14:35 | <jgraham> | gsnedders: I thought yes, but I don't remember whcih direction this went off the top of my head |
| 14:35 | <jgraham> | It was either "change XML" or "break consistency" |
| 14:39 | <odinho> | jgraham: Tss. There's very little rain in Oslo. Much more in UK. And west coast of Norway where I'm from. I'm quite pleased with the weather here. :-) |
| 14:40 | <gsnedders> | odinho: You should try going to the east coast of the UK. ;P |
| 14:40 | <Ms2ger> | gsnedders, if there's no heat wave? |
| 14:40 | <gsnedders> | Oh no, it's just /very/ dry. |
| 14:41 | <gsnedders> | (Here on the west coast we've had two brief, very hard rain showers in the past days, and thunder/lightning the day before, and otherwise sun for the past fortnight.) |
| 14:44 | <annevk> | Ancil: sandboxing and CORS are unrelated |
| 14:44 | <annevk> | gsnedders: it's parsed the same in XML as in HTML (i.e. it's a change to XML parsing) |
| 14:46 | <annevk> | Although this test suggests it might not be implemented yet universally: data:text/xml,<template xmlns="http://www.w3.org/1999/xhtml"><script>alert(1)</script></template>; |
| 14:46 | <gsnedders> | That seenms… so ugly. |
| 14:47 | <Ancil> | annevk: when "sandboxed origin browsing context flag" for an iframe is set(by setting only "allow-script" in sandbox attribute) |
| 14:48 | <Ancil> | annevk: and the iframe page makes an XHR request |
| 14:48 | <Ancil> | annevk: firefox sends a request with Origin header set to null |
| 14:49 | <annevk> | gsnedders: I think the concern is that otherwise you might run into security issues in those pages that happily switch MIME type |
| 14:49 | <odinho> | gsnedders: We have extreme-summer as well now :-) |
| 14:49 | <annevk> | Ancil: well yeah, for XMLHttpRequest you'll need to have opt-in |
| 14:50 | <gsnedders> | annevk: But there are how many deployed XML parsers out there? I'm not sure it's even viable to make such large changes, especially when it deviates from everything else all being treated identically… |
| 14:50 | <gsnedders> | annevk: Are XML implementors intending on making this change? |
| 14:51 | <Ancil> | annevk: and decides based on "Access-Contol-Allow-Origin" value in the response |
| 14:51 | <annevk> | gsnedders: I would expect only browsers to implement it. There's some magic for XSLT in browsers too, although apparently XSLT might still disappear entirely... |
| 14:51 | <Ancil> | annevk: so the sandbox restriction applies only for non XHR cotents? |
| 14:52 | <Ancil> | annevk: *contents |
| 14:52 | <gsnedders> | annevk: So then we end up with browser-XML and everything-else-XML. Great. :| |
| 14:52 | <annevk> | Ancil: if the <iframe> is given a unique origin, you'll need CORS to fetch from it, that makes sense |
| 14:53 | <annevk> | gsnedders: does anyone still care about XML? |
| 14:53 | <annevk> | gsnedders: FWIW, I did raise this concern, nobody really cared. |
| 14:54 | <gsnedders> | annevk: Well, if people still want to argue, "you can just put an HTML parser/serializer on your XML toolchain!", then we ought to care somewhat, if we want these people to move to HTML. |
| 14:54 | <gsnedders> | And as it is now, there's no way to parse template into an infoset, which is a problem for any parser targetting an XML toolchain. |
| 14:55 | <Ancil> | annevk: "sandboxed origin browsing context flag" forces the iframe to have an unique origin |
| 14:55 | <annevk> | I'm not sure anyone ever did that anyway. The only people who argued about that didn't really write much code. |
| 14:55 | <annevk> | Ancil: yes. When you asked the question originally you said nothing about XMLHttpRequest. I thought it was about the fetch for the <iframe> content itself. |
| 14:56 | <Ancil> | annevk: I am sorry for not being specific |
| 14:56 | <gsnedders> | annevk: Well, at least myself and hsivonen_ care about that. |
| 14:58 | <annevk> | gsnedders: No, hsivonen_ is in on this. |
| 14:58 | <annevk> | gsnedders: Anyway, see public-webapps archives if you want to go deeper. |
| 14:58 | <gsnedders> | annevk: Do you know what hsivonen_ has done for the Java side of his parser, then, given that just uses reprs of the infoset? |
| 14:58 | <Ancil> | annevk: the spec says "This flag forces content into a unique origin, thus preventing it from accessing other content from the same origin.". I understood even XHR are included in this. |
| 14:59 | <annevk> | gsnedders: No, someone else implemented it for Gecko though. |
| 14:59 | <gsnedders> | annevk: Yeah, but that's not so interesting when it has its own tree to parse to. :) |
| 14:59 | <annevk> | Ancil: that's correct. What Firefox does is correct. For XMLHttpRequest you'll need CORS. |
| 15:03 | <Ancil> | annevk: I am sorry if I am wrong, will it be more clear if a note is added in the specifiation regarding XHR under the line "This flag forces content into a unique origin, thus preventing it from accessing other content from the same origin." Or it it covered else where? |
| 15:05 | <annevk> | Ancil: given that the page has a unique origin, XMLHttpRequest will have a unique origin and cannot do same-origin requests. That's perfectly logical. |
| 15:10 | <Ancil> | annevk: I have question regarding CORS http://www.w3.org/TR/cors/#redirect-steps |
| 15:10 | <annevk> | gsnedders: Also, note that this gives infoset compatibility between HTML and XML, just not compatibility with XML. |
| 15:11 | <annevk> | Ancil: CORS is http://fetch.spec.whatwg.org/ now more or less. Might help reading that instead, but feel free to ask questions. |
| 15:11 | <Ancil> | annevk: In case of step six the Origin header will be set to null, in the redirected request |
| 15:12 | <Ancil> | annevk: and if the response contains "Access-Control-Allow-Origin: null" |
| 15:12 | <Ancil> | annevk: okay |
| 15:13 | <Ancil> | annevk: should the response be allowed, treated as pass/success |
| 15:13 | <annevk> | Ancil: yes, that should work |
| 15:14 | <Ancil> | annevk: thanks for the clarifications, appreciate it. :) |
| 15:27 | <dglazkov> | good morning, Whatwg! |
| 15:38 | <gsnedders> | annevk: How is it infoset compatible? XML infoset has no way to have a subtree? |
| 15:38 | <annevk> | gsnedders: both infosets changed in a compatible way. |
| 15:39 | <gsnedders> | http://html5.org/tools/web-apps-tracker?from=8074&to=8075 |
| 15:41 | <annevk> | So either the plan completely changed without it reaching me or Hixie is not in on the plan. |
| 15:42 | <gsnedders> | Is there any spec for this new infoset? |
| 15:45 | <BradEstey> | Any chance in adding "webutation-site-verification" to the Registered Meta Extensions list? |
| 15:45 | <annevk> | BradEstey: you can add it |
| 15:45 | <annevk> | gsnedders: not that I know of. |
| 15:46 | <BradEstey> | How do I request an account in here then? :\ |
| 15:46 | <gsnedders> | So we're changing XML specs without as much as letting the XML Core WG know? |
| 16:02 | <jgraham> | gsnedders: I think at some level the plan is about not letting XML-conservatives hold the web platform hostage |
| 16:12 | <gsnedders> | jgraham: In case you have an opinion: how do we implement template in html5lib? Get rid of the generic tree builders and only support all of the parser in a custom tree format? |
| 16:19 | <jgraham> | gsnedders: I haven't thought about it. |
| 16:19 | <jgraham> | But I can think about |
| 16:19 | <jgraham> | it |
| 16:19 | <jgraham> | Later |
| 16:19 | <jgraham> | Now I have to go get food |
| 16:34 | <SimonSapin> | Did the parser spec change a lot since 2009? http://git.netsurf-browser.org/libhubbub.git/tree/docs/Updated |
| 16:43 | <Ms2ger> | HTML parser? Quite a bit |
| 17:10 | <SimonSapin> | yes HTML |
| 17:11 | <SimonSapin> | http://www.netsurf-browser.org/projects/hubbub/ claims HTML5 compliance |
| 17:24 | <annevk> | See kids, this is why living standards are a bad idea! |
| 17:25 | <annevk> | gsnedders: I think for environments that do not have a scripting environment, including e.g. XSLT, the idea is that you just treat the elements as children of the template element. |
| 17:29 | <Hixie> | annevk: what am i not in on re: infoset? |
| 17:29 | <annevk> | Hixie: so the XML example above should result in <template> not having children, and them being put in <template>.contents. |
| 17:30 | <Hixie> | right? what's that got to do with the infoset |
| 17:48 | <Hixie> | annevk: ^ |
| 17:49 | <annevk> | Hixie: That's a good question. Maybe nothing. Though I thought the infoset guaranteed something about markup to infoset mapping and vice versa. |
| 17:50 | <Hixie> | i thought the infoset was just a data model |
| 17:50 | <Hixie> | and the infoset data model doesn't have a ".contents". |
| 17:52 | <Hixie> | annevk: ^ |
| 17:56 | <annevk> | Hixie: So yeah, my bad. I confused changes to XML with changes to XML infoset. |
| 17:56 | <Hixie> | aah ok |
| 18:10 | <TabAtkins> | Anyone have any clue what the mailing list for W3C's a11y stuff is? I'm trying to post a spec announcement relevant to their interests, but can't figure it out. |
| 18:16 | <annevk> | TabAtkins: seems PF WG still has a private list |
| 18:16 | <annevk> | so fucked up |
| 18:16 | <hober> | TabAtkins: public-pfwg-comments? |
| 18:16 | <TabAtkins> | is pfwg a11y? |
| 18:16 | <annevk> | I guess you could use that, though it's technically wrong |
| 18:16 | <hober> | yeah |
| 18:17 | <hober> | "PFWG reviews all W3C technologies for accessibility, and develops WAI-ARIA." |
| 18:17 | <TabAtkins> | Okay. |
| 18:18 | <TabAtkins> | I was looking through the list of mailing lists, and wai has almost two dozen worthless, empty lists. |
| 18:18 | <TabAtkins> | Most of which are named with a "wai-xx" label, where xx is some opaque two-letter identifier. |
| 18:18 | <tantek> | TabAtkins - that's not limited to WAI |
| 18:19 | <tantek> | for a good time, click on any random list here: http://lists.w3.org/Archives/Public/ |
| 18:19 | <TabAtkins> | "good" |
| 18:20 | <tantek> | at least some of them explicitly say "[Historical list - Inactive]" |
| 18:22 | <TabAtkins> | See, www-wai-pf looked totally reasonable, but it's had 10 messages in the last decade. The first is the intro message in 2002, the latest is an introduction email from 2009, and the other 8 are spam or mistakes. |
| 21:49 | <zewt> | /win 6 |
| 21:49 | <zewt> | (hi) |
| 23:11 | <gsnedders> | annevk: Then someone should tell Hixie of that plan. :) |
| 23:12 | gsnedders | sees the above conversation |
| 23:12 | <gsnedders> | Ignore m.e |
| 23:13 | <gsnedders> | SimonSapin: takkaria's GSoC project in… 2008, I think, was the parser in Hubbub |
| 23:47 | <mounir> | Hixie: is <fieldset> not barred from constraint validation on purpose? |
| 23:47 | <Hixie> | what would it mean for it not to be? |
| 23:47 | <mounir> | Hixie: I mean, it is supporting :invalid/:valid like <form> but do we really want to have .setCustomValidity applying? |
| 23:48 | <mounir> | Hixie: Gecko has it barred from constraint validation for the moment |
| 23:48 | Hixie | attempts to page in that part of the spec |
| 23:49 | <mounir> | Hixie: it is possible that when you added :invalid support, you remove that bit |
| 23:49 | <Hixie> | woah, :valid doesn't apply but :invalid does, wtf is that |
| 23:49 | <mounir> | Hixie: oh, good catch, our patch implements both :) |
| 23:49 | <Hixie> | the way :invalid is specced, the fieldset itself isn't what's checked, it's the descendants: |
| 23:49 | <Hixie> | # fieldset elements that have of one or more descendant elements that themselves are candidates for constraint validation but do not satisfy their constraints |
| 23:49 | <mounir> | indeed |
| 23:50 | <mounir> | Hixie: but I don't see in the specs the line saying that "fieldset is barred from constraint validation" |
| 23:50 | <Hixie> | oh, i misunderstood your original question above |
| 23:51 | <Hixie> | i thought you meant, is it barred from constraint validation for a reason other than on purpose? |
| 23:51 | <Hixie> | but let me look further |
| 23:51 | <mounir> | Hixie: my fault, double negative ;) |
| 23:52 | <Hixie> | aha |
| 23:52 | <Hixie> | fieldset isn't submittable |
| 23:52 | <Hixie> | so it can't be a candidate for constraint validation |
| 23:53 | <mounir> | argh |
| 23:53 | <mounir> | but good to hear ;) |
| 23:53 | <Hixie> | it appears that attempting to spec basically what browsers do has resulted in a spec about as complicated as browsers |
| 23:54 | <Hixie> | which in retrospect is unsurprising |
| 23:54 | <Hixie> | but :-( nonetheless |
| 23:54 | <Hixie> | fixed the :valid thing. |
| 23:54 | <gsnedders> | Is it just me or does simply dropping <template>'s ssubtree seem really evil to do in html5lib? |
| 23:55 | <Hixie> | gsnedders: i dunno about "evil", but it doesn't seem useful, for sure |
| 23:56 | <Hixie> | gsnedders: look up the meaning of "contents" in the html spec, that may help you decide how to handle this. http://www.whatwg.org/specs/web-apps/current-work/#concept-html-contents |
| 23:56 | <Hixie> | gsnedders: (notice that this term is used in the definition of the serialisation) |