| 00:01 | <AryehGregor> | I love open-source: https://bugs.webkit.org/show_bug.cgi?id=73182 |
| 00:02 | <zewt> | would spoofing as "User-Agent: you're an idiot" be acceptable |
| 00:02 | <zewt> | perhaps it would help get the message across |
| 00:05 | <erlehmann> | zewt, i like your style and wish to subscribe to your newsletter. |
| 00:06 | <annevk> | I think it's right here, in #whatwg :) |
| 00:07 | <erlehmann> | // Pretend to be Firefox. Silverlight doesn't support Win Safari. |
| 00:07 | <annevk> | someone please patch WebKit to remove UTF-32 for me tonight |
| 00:07 | <erlehmann> | ahaha oh wow |
| 00:07 | <annevk> | nn |
| 00:08 | <Hixie> | nn |
| 00:08 | <erlehmann> | nn? |
| 00:09 | <AryehGregor> | Two nymphs next to a scroll. |
| 00:09 | AryehGregor | uses magic missile to knock them both off from a distance |
| 00:09 | <Hixie> | erlehmann: "night night" |
| 00:09 | <AryehGregor> | Those things can be really annoying. |
| 00:10 | AryehGregor | used to play NetHack a bunch, and sometimes still randomly associates strings of characters with monsters and treasure |
| 00:10 | <AryehGregor> | Particularly in fixed-width fonts. |
| 00:13 | <erlehmann> | i use variable width |
| 00:13 | <erlehmann> | you insensitive clod |
| 00:13 | <erlehmann> | (p.s. hot grits) |
| 02:16 | <jcranmer> | sigh @ the UTF-8 thread |
| 04:02 | <JonathanNeal> | Is this style still relevant? http://www.iecss.com/whatwg.css - I compiled it from the spec, but I think it had imaginary properties like :any(dl, menu, ol, ul) :any(dl, menu, ul) etc |
| 04:43 | <zewt> | commending boris's endurance in the utf-8 thread |
| 04:46 | <zewt> | will i be strung and quartered if i point out that missing language declarations have the exact same problem as missing encoding declarations (even if the cases it matters are fewer) |
| 04:46 | <zewt> | also drawn (need a refresher on my midieval execution methods) |
| 04:47 | <zewt> | (also medieval; striking out tonight) |
| 05:39 | <mendota> | can i ask a question about arcs in canvas? |
| 05:46 | <Hixie> | mendota: sure |
| 06:28 | <abarth> | Hixie: do you know how to subscribe to public-html ? I used to be subscribed, but I don't seem to be anymore. http://lists.w3.org/Archives/Public/public-html/ doesn't have the usual subscription instructions |
| 06:29 | <Hixie> | as a googler you have to go through tv |
| 06:29 | <abarth> | ah, thanks |
| 06:29 | <Hixie> | but frankly i would count your blessings |
| 06:30 | <abarth> | ok. i've been encouraging the web intents folks to come to public-html to talk about <intent> |
| 06:30 | <abarth> | but i guess I can read it in the archives |
| 06:41 | <abarth> | Hixie: do you have a moment to tell me how nutty this text about sandbox flags is? http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#sandbox |
| 06:41 | <abarth> | "When enforcing the sandbox directive, the user agent must set the sandbox flags for the protected document as if the document where contained in a nested browsing context within a document with sandbox flags given by the the directive-value." |
| 06:43 | <Hixie> | hrm |
| 06:43 | <abarth> | i don't think its quite right |
| 06:43 | <abarth> | i couldn't find a good hook in HTML for this |
| 06:44 | <Hixie> | what you probably want to do is set some hook that i can then do the right magic with |
| 06:44 | <Hixie> | rather than try to poke the html spec flags |
| 06:44 | <abarth> | ok |
| 06:44 | <Hixie> | because the flags you have to set are pretty complex and subtle |
| 06:44 | <Hixie> | and involve the navigation algorithm, etc |
| 06:44 | <abarth> | how about the "CSP sandbox flags" as a property of a Document |
| 06:44 | <abarth> | which will be a string like you'd get in the iframe attribute? |
| 06:44 | <abarth> | so HTML handles the parsing |
| 06:44 | <Hixie> | has to be on a browsing context, not a document |
| 06:44 | <Hixie> | doesn't make sense to sandbox a document |
| 06:45 | <abarth> | why not? |
| 06:45 | <abarth> | sorry, let me ask a different question |
| 06:45 | <abarth> | is a browsing context preserved across navigations? |
| 06:45 | <Hixie> | yes |
| 06:46 | <Hixie> | but the flags can change during the lifetime of the browsing context |
| 06:46 | <abarth> | ah |
| 06:46 | <abarth> | ok |
| 06:46 | <Hixie> | what matters to all teh security stuff is the state when the browsing context was last navigated |
| 06:47 | <Hixie> | e.g. "if... its browsing context had its sandboxed forms browsing context flag set when the Document was created ..." |
| 06:47 | <abarth> | i see |
| 06:47 | <Hixie> | but the net result is that you have to set the flags before the document is created |
| 06:47 | <abarth> | do we have the response headers when the document is created? |
| 06:47 | <Hixie> | er, before the Document is created |
| 06:47 | <Hixie> | sure |
| 06:47 | <Hixie> | assuming it came over HTTP |
| 06:48 | <abarth> | ok, so when the document is created, HTML needs to ask about the CSP policy for the document |
| 06:48 | <abarth> | or for the response |
| 06:48 | <Hixie> | we get the headers by navigate step 19 or so (type sniffing step), we create the document as a side-effect of step 20 (the switch statement that relies on the sniffed type) |
| 06:49 | <abarth> | Upon receiving an HTTP response containing ... |
| 06:49 | <abarth> | that's when the CSP policy starts getting enforced |
| 06:49 | <abarth> | "Upon receiving an HTTP response containing at least one Content-Security-Policy header field, the user agent must enforce the combination of all the policies contained in these header fields." |
| 06:50 | <Hixie> | so... what happens if the page navigates itself to a page without the CSP? |
| 06:50 | <Hixie> | or does a history.back() to a accomplice page that isn't sandboxed? |
| 06:50 | <abarth> | that's fine |
| 06:51 | <abarth> | consider the unique-origin sandbox bits |
| 06:51 | <abarth> | or the disable-script |
| 06:51 | <Hixie> | k |
| 06:51 | <abarth> | those make sense on a per-document basisi |
| 06:51 | <Hixie> | so when do we reset the flags? |
| 06:51 | <abarth> | each navigation |
| 06:52 | <abarth> | what actually happens in the implementation is that we copy the sandbox flags from the Frame to the Document when the document is created |
| 06:52 | <abarth> | because we're supposed to freeze the sandbox flags |
| 06:52 | <abarth> | we enquire about the CSP policy at that time |
| 06:52 | <abarth> | that happens each time a new document is loaded into a Frame |
| 06:52 | <Hixie> | hmm... the document is created before the session history change happens |
| 06:53 | <Hixie> | so we'd have to reset the flags before the old document is removed... |
| 06:53 | <Hixie> | might make sense to just set the flags temporarily while the document is being created or something |
| 06:53 | <Hixie> | how is this supposed to interact with the sandbox attribute? union? |
| 06:53 | <abarth> | can we not just set them on the document when we copy the state to the document? |
| 06:54 | <abarth> | Hixie: its the same combination operator that happens when you have nested iframes |
| 06:54 | <abarth> | that each contribute a sandbox attribute |
| 06:55 | <Hixie> | hmmm |
| 06:56 | <Hixie> | so the way it works for nested iframes is that setting the flag on an iframe just forces it on for all descendants iframes |
| 06:56 | <abarth> | yeah, so the union |
| 06:56 | <abarth> | (assuming the items are things like "sandboxed scripts browsing context flag") |
| 06:57 | <Hixie> | the precise text right now is "In addition, any browsing contexts nested within an iframe, either directly or indirectly, must have all the flags set on them as were set on the iframe's Document's browsing context when the iframe's Document was created." |
| 06:57 | <Hixie> | so i guess i'd just change that to "nested within a browsing context" |
| 06:57 | <Hixie> | and change the other "iframe"s to "browsing context" |
| 06:57 | <abarth> | yes |
| 06:58 | <abarth> | "iframe's Document's browsing context when the iframe's Document was created" |
| 06:58 | <abarth> | that state gets represented in the implementation |
| 06:58 | <abarth> | explicitly as a property of the document |
| 06:58 | <Hixie> | sigh, probably makes sense to just hoist all this stuff up to a generic section |
| 06:58 | <Hixie> | and then invoke it from iframe creation and from navigation |
| 06:58 | <Hixie> | or something |
| 06:58 | <Hixie> | and maybe do your "freeze on document" thing at the same time |
| 06:58 | <Hixie> | for clarity |
| 06:58 | <abarth> | sorry to make work for you :( |
| 06:58 | <Hixie> | no worries |
| 06:59 | <Hixie> | tis my job |
| 06:59 | <Hixie> | can you file a bug or send mail about it? reference this irc log if you can |
| 06:59 | <abarth> | sure |
| 06:59 | <Hixie> | probably won't happen until early next year |
| 06:59 | <abarth> | yeah, there's no rush |
| 06:59 | <Hixie> | k |
| 06:59 | <abarth> | thanks |
| 07:02 | <Hixie> | my pleasure |
| 07:19 | <zewt> | ew, IVS characters are outside of the BMP, so if they were ever actually supported and used, they'd never work reliably in JS (since nobody pays attention to surrogate pairs) |
| 07:22 | <jamesr> | what's IVS? |
| 07:22 | <zewt> | combining characters for glyph variations in unicode |
| 07:22 | <zewt> | (an alternate approach to language tagging for the han unification problem) |
| 07:23 | <zewt> | never heard of it actually being used, though |
| 07:23 | <zewt> | (and it doesn't seem very practical, in general) |
| 07:24 | jamesr | wonders if non-BMP chars are something we'll ever address on the web |
| 07:25 | <jamesr> | and if the people cooking up unicode are aware of the issues |
| 07:25 | <Hixie> | the people cooking up unicode don't have much choice in the matter |
| 07:25 | <Hixie> | the BMP is close to full |
| 07:26 | <jamesr> | so they shouldn't wait for us, obviously, unicode solves problems for things other than the web |
| 07:27 | <jamesr> | but at some point we have to deal with this, or just say that there are types of content that you can't use 99% of the web platform and libraries for |
| 07:27 | <zewt> | a set of content that will grow to less trivial levels over time |
| 07:28 | <zcorpan> | have somebody extracted IDLs from specs and put them somewhere? |
| 07:28 | <Hixie> | dom's widl checker can extract idls from spec |
| 07:28 | <jamesr> | either the world ignores that content (unlikely and seems bad), we extend the platform, or platforms other than the web grow to deal with this content |
| 07:30 | <zewt> | platforms other than the web don't need to grow--they already deal with it (well, some of them) |
| 07:31 | <zewt> | so it'll become "everyone can display these characters except for the web" (or rather, "it'll display on the web but things will break randomly") |
| 07:31 | <zewt> | (we're not *that* far off; win32 is UTF-16 too and I'm sure lots of Windows software doesn't deal with it at all) |
| 07:55 | <zcorpan> | http://widl.webvm.net/ is .... unhelpful |
| 07:57 | zcorpan | gives up |
| 08:03 | jgraham | wonders what zcorpan is trying to do |
| 08:04 | <jgraham> | Also, it seems like we shipped the HTML5 parser in an actual final release build |
| 08:04 | <jgraham> | Take that site-compatibility bugs! |
| 08:06 | <Hixie> | no more weird text nodes with css? |
| 08:07 | <zcorpan> | jgraham: i just wanted to find examples of overloading to form an opinion on what the conversion behavior should be |
| 08:07 | <Hixie> | nn |
| 08:07 | <zcorpan> | jgraham: turned out to be simpler to search for "};" |
| 08:07 | <jgraham> | gn |
| 08:08 | <jgraham> | zcorpan: Ah :) |
| 08:08 | <zcorpan> | first example is options.add() |
| 08:21 | <jamesr> | hmm |
| 08:21 | <jamesr> | any opera peeps here? i'm looking at http://dev.opera.com/articles/view/efficient-javascript/?page=3#stylechanges and scratching my head |
| 08:23 | <jamesr> | it seems like either opera's doing things that are definitely invalid or there's some interaction here that escapes me. how could you have intermediate repaints in that example? |
| 08:26 | <jgraham> | jamesr: Haven'tlooked at the article (have to go), but we repaint on a timer during script execution. It is supposed to help on slow devices where script might take a long time |
| 08:26 | <jamesr> | so you paint while script is still running? |
| 08:26 | <jgraham> | If that's not what it's about, I will have to read the article |
| 08:26 | <jamesr> | yes that's what it's about |
| 08:26 | <jamesr> | or this section, anyway |
| 08:26 | <jamesr> | and you're OK with painting intermediate results? |
| 08:27 | <jgraham> | Well it depends who you ask :) |
| 08:27 | <jgraham> | There is a tradeoff |
| 08:28 | <zcorpan> | the article says "That approach could mean multiple reflows and repaints.". this is not the case (anymore, at least) |
| 08:28 | <zcorpan> | unless the script takes a very long time |
| 08:28 | <jamesr> | well, if opera decides to repaint after every .style assignment it will |
| 08:28 | <jgraham> | On desktop if your script is so long running that it will paint intermediate results in Opera it will block the UI thread in other browsers |
| 08:28 | <jgraham> | So it's not a good UX anywhere |
| 08:29 | <jamesr> | if the script is replacing a significant part of the UI with something different then it's much better to not show a half-built thing |
| 08:29 | <jamesr> | unless you're talking about hung script dialog sorts of delays |
| 08:29 | <jamesr> | there's also standards language around this behavior, although it is somewhat weak |
| 08:30 | <zcorpan> | right, we don't conform to the html spec |
| 08:30 | <jamesr> | anyway, if you feel that's the UX you want i'll try to keep it in mind when advising web devs on what to do (probably by telling them to ignore opera since there is no way for them to build a reasonable experience with that going on) |
| 08:31 | <zcorpan> | jamesr: i hope you don't advice web devs to block the UI thread :) |
| 08:32 | <jamesr> | well, i do advise them not to write any javascript to avoid doing that |
| 08:32 | <jamesr> | but sometimes they don't listen and write some script anyway |
| 08:33 | <jamesr> | and authors don't have much control over how much wall clock time their JS takes given GC pauses, thread preemption, and native code choices |
| 08:57 | <jgraham> | jamesr_: Code that takes hundreds of ms to run is bad any way you cut it |
| 09:13 | <oal> | Shouldn't the section tag be styled in any way? And are there other tags that should be treated the same way? |
| 09:15 | <jgraham> | Giving tags default styling often makes people unhappy |
| 09:19 | <oal> | jgraham: http://www.aniketpant.com/article/html5-semantics-and-good-coding-practices says "Not: The section element should not be used for styling. A div should be preferred." Why is that? |
| 09:21 | <zcorpan> | oal: same reason you shouldn't use <h1> if you want big text but don't mean heading |
| 09:22 | <zcorpan> | oal: <section> means section, not fancy box with rounded corners and drop shadow :) |
| 09:22 | <oal> | Yeah, but I mean, if you have a section, isn't it ok to set a width, color and background color for it? Or should there be an <article> or <div> inside with those set? |
| 09:23 | <zcorpan> | sure, it's fine to style sections |
| 09:24 | <zcorpan> | it's fine to style any element |
| 09:24 | <zcorpan> | it's not fine to use any element *for styling* |
| 09:26 | <jgraham> | Right. That sentence is a bit misleading. It means you shouldn't use <section> if the only reason you need an element is as a wrapper to hook some styling on. You should only use <section> if you are actually marking up a section of content. But if you are using <section> correctly, it is fine to apply any style you like to it |
| 09:26 | <jgraham> | If you just need a styling hook, use a <div> element instead |
| 09:27 | <oal> | That makes sense. Thanks jgraham and zcorpan :-) |
| 10:30 | <annevk> | heycam|away: did you add the warning to const? |
| 11:25 | <annevk> | geez HTTP WG is taking its time |
| 11:25 | <annevk> | and forgetting about my issues after saying they'll handle it |
| 11:52 | <annevk> | Hixie: in r6843 you updated WebVTT but http://dev.w3.org/html5/webvtt/ is not updated |
| 14:12 | <annevk> | Live WebVTT Validator should match the specification again |
| 14:12 | <annevk> | https://bitbucket.org/annevk/webvtt |
| 14:12 | <annevk> | http://quuz.org/webvtt/ |
| 14:13 | <annevk> | hsivonen: is it an idea to host an instance on webvtt.validator.nu? |
| 14:37 | <DrewBarfield> | Hello everyone! I'm interested in writing demos for the WHATWG site (HTML living standard) and need suggestions. What kinds of demos would you like to see? |
| 14:38 | <annevk> | DrewBarfield: did you look at http://www.whatwg.org/demos/ ? |
| 14:39 | <annevk> | DrewBarfield: it can basically be anything that's defined in the HTML standard |
| 14:41 | <DrewBarfield> | Are there topics that are lacking demos or could use them more than others? If not, I can just iterate over the topics at http://www.whatwg.org/specs/web-apps/current-work/multipage/ |
| 14:43 | <jgraham> | I don't recall seeing any EventSource demos |
| 14:43 | <annevk> | DrewBarfield: I think currently we lack demos for most things, but there are other sites that have created demos too, such as http://html5demos.com/ |
| 14:44 | <annevk> | DrewBarfield: basically though, everything is welcome; start with what you know best I'd say :) |
| 14:44 | <jgraham> | Yes |
| 14:46 | <annevk> | DrewBarfield: Hixie can probably help set you up, but depending on your timezone you might have to email him |
| 14:47 | <DrewBarfield> | Thank you all. I think I will start with the Communication chapter and work my way out from there. |
| 14:47 | <DrewBarfield> | I have emailed Ian and he suggested that I ask everyone here for suggestions. |
| 14:47 | <annevk> | ah okay, cool |
| 15:27 | <Wilto> | I heard someone in this joint was using the phrase “responsive images,” which summons me like saying “Beetlejuice” three times. |
| 15:30 | <Wilto> | Hm, maybe not. You’ve broken my heart once again, miketaylr. |
| 15:30 | <miketaylr> | </3 |
| 15:43 | <JonathanNeal> | Goodmorning! |
| 17:44 | <JonathanNeal> | howdy |
| 18:00 | <Wilto> | How goes, JonathanNeal? |
| 18:01 | <JonathanNeal> | I'm looking to update https://github.com/jonathantneal/html5css Wilto. It's been almost a year! |
| 18:02 | <JonathanNeal> | It's a css document of the presentation guidelines from the html5 spec. |
| 18:03 | <JonathanNeal> | basically it's the user agent style sheet the spec recommends. |
| 18:04 | <Wilto> | Huh, interesting. |
| 18:09 | <JonathanNeal> | I think so. I think it's important to maintain a document like this. |
| 19:11 | <zewt> | in principle, it's possible for a busy-looping task queue to starve out all events in other task queues, right? |
| 19:12 | <zewt> | since the event loop doesn't require any kind of fairness across queues |
| 19:13 | <jamesr_> | zewt, it's organized by task source |
| 19:13 | <jamesr_> | a UA can schedule from any task source |
| 19:13 | <zewt> | right, but if one queue is busy looping, there's no requirement that other task queues are able to run |
| 19:13 | <dglazkov> | good morning, Whatwg! |
| 19:13 | <jamesr_> | no, i think that'd fall into QoI |
| 19:14 | <zewt> | right |
| 19:14 | <zewt> | was wondering, since it seems like a wrong assumption that https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html is making |
| 19:14 | <zewt> | (if you use this, in principle things like MessageChannels might get starved out) |
| 19:14 | <jamesr_> | oh, hah |
| 19:15 | <jamesr_> | yeah that spec is full of poo-brain |
| 19:15 | <zewt> | (though I suspect there are deeper issues with the UI being able to run) |
| 19:15 | <zewt> | i suppose that's a more blunt way of putting it :P |
| 19:15 | <jamesr_> | i don't think anyone will implement it |
| 19:15 | <zewt> | given that you can do that with just MessageChannel already, there's really no need (re: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15007) |
| 19:15 | <jamesr_> | (i mean i think IE did in a PP) |
| 19:16 | <jamesr_> | right, we told them that |
| 19:16 | <zewt> | also although being able to queue a task without setTimeout's delays is nice, I don't like the basic premise of how that's written (as if it's meant to be used to allow CPU-intensive work in the UI thread--ugh no) |
| 19:28 | <jamesr_> | the only reason we clamp setTimeout is because pages are dumb and flood it |
| 19:28 | <jamesr_> | if authors weren't abusive, we wouldn't need any clamp |
| 19:30 | <Ms2ger> | And there's only clamping inside nested setTimeouts, so you can queue a task without delays already |
| 19:35 | <jamesr_> | also if you're doing non-trivial work you can avoid the clamp by calling setTimeout() before the work rather than at the end |
| 19:42 | <catphive> | does anyone know if there are any planned standards for browser based presence? |
| 19:43 | <tantek_> | which meaning of "presence"? |
| 19:43 | <catphive> | like for an IM client |
| 19:43 | <catphive> | detecting if the user is available |
| 19:48 | <tantek> | catphive - sounds like a useful WebAPI |
| 19:56 | <martndemus> | doesnt chrome have something that keeps track if the actual tab the app is in is active? |
| 20:03 | <bencc> | in websocket who should send pings to keep the connection alive, the client or the server? |
| 20:03 | <bencc> | or maybe the browser does this automatically for me? |
| 20:21 | <jgraham> | bencc: The browser should send the ping frames AIUI |
| 20:22 | <jgraham> | Bu I haven't read the spec text there closely so I don't know if there are any hard requirements |
| 20:22 | <bencc> | AIUI? |
| 20:23 | <jgraham> | "As I Understand It" |
| 20:23 | <jgraham> | Nope, jut meaningless gloop |
| 20:23 | <bencc> | jgraham: so when I'm creating a websocket in FF or Chrome, the application shouldn't worry about it? |
| 20:23 | <jgraham> | Well the spec says |
| 20:23 | <jgraham> | "An endpoint MAY send a Ping frame any time after the connection is established and before the connection is closed. NOTE: A ping frame may serve either as a keepalive, or to verify that the remote endpoint is still responsive. |
| 20:23 | <bencc> | and also the server shouldn't worry about it? |
| 20:23 | <jgraham> | " |
| 20:24 | <jgraham> | Well the server is required to respond to a ping frame with a pong frame |
| 20:24 | <bencc> | I don't see ping function in the websocket object |
| 20:24 | <annevk> | oh lol |
| 20:24 | <jgraham> | Sure, it isn't API exposed |
| 20:24 | <annevk> | did they just propose the <intent> tag using DTD syntax |
| 20:24 | <Hixie> | the browser will take care of ping from the client if it's needed |
| 20:24 | <jgraham> | The browser is supposed to do it |
| 20:24 | <Hixie> | the server should take care of ping from the server if the server needs it |
| 20:24 | <annevk> | that's pretty funny considering it's 2011 |
| 20:24 | <jgraham> | But it's conforming to never send one |
| 20:24 | <jgraham> | So it's a QoI issue |
| 20:25 | <jgraham> | One hopes there will not be any braindead implementations |
| 20:25 | <Hixie> | in some situations, sending pings is actually really bad |
| 20:25 | <jgraham> | But that is not a safe assumption |
| 20:25 | <Hixie> | e.g. if you have a flaky network connection, every ping is a chance of the connection dropping |
| 20:25 | <Hixie> | whereas if you just didnt' send anything it might survive fine |
| 20:25 | <Hixie> | e.g. sometimes at home i'm on wifi and the neighbours turn their microwave on and the wifi goes down for 3 minutes |
| 20:25 | <jgraham> | If you have a really flaky connection you are probably screwed anyway |
| 20:26 | <Hixie> | if i notice this happen, i can just stop using the network, and all the apps i use that don't do keepalive survive with no probelms whatsoever |
| 20:26 | <Hixie> | but the apps that think they're clever and do keepalive all die |
| 20:26 | <bencc> | but sending a ping is the only way the server can check if the client is alive, isn't it? |
| 20:26 | <jgraham> | I mean I don't imagine that web authors are going to design with your neighbourgh's microwave in mind |
| 20:26 | <Hixie> | jgraham: it's just an example, the problem is far worse e.g. on mobile |
| 20:26 | <bencc> | in a chat, you want users to know if someone is offline |
| 20:27 | <Hixie> | jgraham: where you might be going past a big building that blocks the signal, or whatever |
| 20:27 | <bencc> | without pings, you can have zombie sessions |
| 20:27 | <jgraham> | Right, I understand that the connection can be flaky. But authors are going to assume that it isn't |
| 20:27 | <jgraham> | So it's not at all clear that pings make it worse |
| 20:28 | <bencc> | in the server the logic is a bit tricky |
| 20:28 | <Hixie> | well it seems clear that in the two examples i gave, pings are worse than no pings |
| 20:28 | <Hixie> | but i agree that there are use cases for pings |
| 20:29 | <bencc> | Let's that if the client is idle for 1 mintue, I'm sending a ping |
| 20:29 | <Hixie> | i'm just saying it's not a given that sending a ping is better than not sending one |
| 20:29 | <bencc> | now, the first response might not be the pong but a new message |
| 20:29 | <jgraham> | In any case the protocol-level pings are not something that the author can control |
| 20:29 | <jgraham> | But you can always build something identical into your application |
| 20:29 | <bencc> | the server author should implement it |
| 20:30 | <jgraham> | If you need it for some reason |
| 20:30 | <bencc> | I want to know if the user is offline in a 1 minute window |
| 20:30 | <bencc> | for a chat app |
| 20:30 | <Hixie> | define "offline" |
| 20:30 | <bencc> | dead |
| 20:30 | <bencc> | wolfs eating his body |
| 20:30 | <Hixie> | am i offline if i happen to be in the middle of a conversation but the car i'm in goes through a tunnel for 61 seconds? |
| 20:30 | <bencc> | eagles are circling in the skies |
| 20:31 | <bencc> | if that's the case, increase the window to 3 minutes |
| 20:31 | <Hixie> | am i offline if i happen to be in the middle of a conversation but the car i'm in goes through a tunnel for 181 seconds? |
| 20:31 | <bencc> | are you familiar with tunnels that long? |
| 20:31 | <bencc> | yes |
| 20:31 | <Hixie> | yes |
| 20:32 | <bencc> | am I offline if I'm dead and suddenly a miracle happened and I'm alive again? |
| 20:32 | <Hixie> | are you offline if you're dead at all? |
| 20:32 | <bencc> | good question |
| 20:33 | <bencc> | so it's 1 minute for 99.99% of the people |
| 20:33 | <bencc> | and 3 minutes for you because of the washing machine and your long tunnel |
| 20:34 | <annevk> | why would you use ping for that at all... |
| 20:35 | <bencc> | now I need to handle users without a computer... |
| 20:35 | <annevk> | if the other person doesn't say anything, clearly he's away |
| 20:35 | <annevk> | doesn't really matter what the reason is |
| 20:35 | <bencc> | in IM you can be online but quiet |
| 20:36 | <annevk> | you can also be offline but still appear online |
| 20:36 | <annevk> | Gmail seems to work that way |
| 20:36 | <annevk> | Gmail chat that is |
| 20:37 | <annevk> | doesn't really matter |
| 20:37 | <bencc> | in Gmail you suppose to appear online only if you are logged in |
| 20:37 | <bencc> | if you see someone is online and send him a message he is supposed to see the message right away |
| 20:46 | <jgraham> | bencc: That is such a bad assumption. e.g. my connection here is maintained all the time. Sometimes I am asleep or not at a computer |
| 20:46 | <Hixie> | same here |
| 20:47 | <Hixie> | same with all my IM clients actually. I proxy them all through a computer that is always online, regardless of where I am, and I connect to that proxy remotely when I'm really online, to collect my messages. |
| 20:47 | <bencc> | that's a question of user experience |
| 20:48 | <jgraham> | annevk: Yeah, presenting stuff with a DTD in 2011 is very funny |
| 20:48 | <jgraham> | It's like the last 10 years didn't happen |
| 20:48 | <bencc> | you might turn the user to 'busy' if he is not using the UI for 10 mintues |
| 20:48 | jgraham | just finds the busy/away/etc stuff confusing |
| 20:49 | <Hixie> | my /away status rarely has any bearing on my actual status |
| 20:49 | <bencc> | that's a question of user experience |
| 20:49 | <bencc> | you are still "online" |
| 20:49 | <jgraham> | I never know if the person is really busy or if they are really around but the computer decided that they were budy for some reason |
| 20:49 | <bencc> | gmail chat works perfect for me |
| 20:49 | <bencc> | when I see a friend online he is available to chat with me |
| 20:56 | <Hixie> | does anyone actually implement nested workers and message channels yet? |
| 20:56 | <annevk> | you mean shared workers? |
| 20:56 | <annevk> | Opera and WebKit I believe |
| 20:56 | <Hixie> | no, not shared workers |
| 20:57 | <Hixie> | the Worker() and MessageChannel() constructors, in a worker |
| 20:59 | <Hixie> | looks like firefox doesn't implement MessageChannel |
| 21:01 | <Hixie> | opera throws an INVALID_STATE_ERR exception from postMessage(), which is impossible per spec as far as i can tell |
| 21:01 | <Hixie> | webkit doesn't support Worker() inside workers |
| 21:05 | <tantek_> | Hixie - what would that be, the middle management feature? |
| 21:05 | <Hixie> | -_- |
| 21:05 | <tantek_> | or would you need more than one level of hierarchy for that |
| 21:06 | <Hixie> | more like the subcontractor feature, if we're going to go with this metaphor |
| 21:06 | <Hixie> | anyone actually got IE10 around? |
| 21:06 | <tantek_> | subcontractor would mean cross-origin though |
| 21:07 | <zewt> | bencc: sounds like false negatives; gmail knows the user is around if he's moving the mouse around a gmail tab, but if the user isn't using gmail it has no idea whether the user is there or not |
| 21:08 | <zewt> | eg. if it says the user is there he probably is, but if it says he isn't, it doesn't actually know at all |
| 21:08 | <tantek_> | so presence is tab-specific? that seems to make sense |
| 21:08 | <tantek_> | as, in you'd want to know if the user is present in the page's context, not just on the machine somewhere |
| 21:08 | <zewt> | i'm just talking about gmail in browsers; certainly it should not be able to tell whether i'm active in another tab (privacy) |
| 21:08 | <jgraham> | tantek_: It means that G+ tells me that annevk is away when he is talking here |
| 21:09 | <tantek_> | I suppose both could be useful |
| 21:09 | <tantek_> | is the user active on the machine |
| 21:09 | <tantek_> | is the user active on this page |
| 21:09 | <annevk> | I'd rather not reveal any of that |
| 21:09 | <annevk> | as a user |
| 21:09 | <jgraham> | Me too, but it isn't really possible to stop |
| 21:10 | <zewt> | how so? |
| 21:10 | <tantek_> | annevk - that's why it makes sense as a WebAPI - it's a permissions like thing similar to Geo etc |
| 21:10 | <jgraham> | zewt: Well the "on this machine" thing is since that doesn't work at all at present |
| 21:10 | <jgraham> | but the "on this page" isn't |
| 21:11 | <zewt> | i don't care if pages know i'm using the page, but they shouldn't be able to tell that I'm active otherwise (without extra permission) |
| 21:11 | <jgraham> | Or "on any page that has the same user identifier" |
| 21:11 | <jgraham> | (so facebook could know that you are active on any site that uses facebook login for example) |
| 21:12 | <zewt> | i was just responding to above <bencc> gmail chat works perfect for me |
| 21:12 | <zewt> | his "perfect" seemed to be flawed |
| 21:12 | <jgraham> | Yeah, I agree. It's not possible to make it perfect |
| 21:13 | <zewt> | i mean, his evaluation of "perfect" |
| 21:13 | <jgraham> | "do I want to chat right now" isn't realy something that you can infer automatically |
| 21:13 | <zewt> | <bencc> when I see a friend online he is available to chat with me |
| 21:13 | <annevk> | jgraham: fwiw, I'm permanently marked "Away", but usually when the music track changes I'm actually there :) |
| 21:13 | <zewt> | my point was that the reverse is not going to be true--people are available to chat, even though gmail says they're not (i expect) |
| 21:13 | <jgraham> | annevk: It's OK I never intend to contact you through google plus. And don't really have that much interest in stalking you |
| 21:14 | <jgraham> | Although people do think you're a girl so maybe you will get stalkers |
| 21:14 | <jgraham> | s/plus/chat/ |
| 21:15 | <annevk> | only girls get stalkers? |
| 21:15 | <zewt> | not exclusively, but i expect there's a great bias in that direction |
| 21:15 | <annevk> | anyway, not going to add anyone to Google Chat I don't like :) |
| 21:16 | <zewt> | at least in technical corners of the internet, with the usual gender ratios :P |
| 21:17 | <jgraham> | In the technical corners of the internet p(man|called anne) > p(woman|called anne) |
| 21:17 | <jgraham> | :( |
| 21:17 | <jgraham> | (note: this is almost certianly not true) |
| 21:17 | <zewt> | yeah, it says something that i just assumed from the start that anne was probably a guy |
| 21:19 | <zewt> | i couldn't quite make that leap with Silvia, though |
| 21:20 | <wilhelm> | How do Safari / WebKit version numbers work? What does 534.51.22, 7534.48.3 or 6533.18.5 correspond to? (Those numbers are from UA strings.) |
| 21:20 | <zewt> | magic |
| 21:21 | <zewt> | am I the only person in the world that Firefox save dialogs ignore? heh |
| 21:21 | <zewt> | for years, over endless versions of FF and different versions of Windows, i've had to hit alt-s 2-3 times to get the save dialog to go |
| 21:23 | <sicking> | annevk: ping |
| 21:23 | <annevk> | hey sicking |
| 21:23 | <sicking> | annevk: I'm really interested to hear your take on supporting non UTF8 encoded HTML documents in XHR |
| 21:24 | <annevk> | I actually think that maybe we should limit that to UTF-8 too |
| 21:24 | <sicking> | annevk: HUH?!? |
| 21:25 | <sicking> | annevk: that excludes some 50% of the worlds HTML |
| 21:25 | <zewt> | annevk: I'm really interested to hear your take on supporting non UTF8 encoded HTML documents in XHR, as long as you agree with me |
| 21:25 | <sicking> | zewt: no, i was very intersted in hearing dissenting opinions too. That doesn't mean i agree with them |
| 21:25 | <zewt> | i know :P |
| 21:26 | <zewt> | sicking: what about only supporting validly-tagged HTML documents, rejecting the fuzzy parts (heuristics and locale-specific defaults)? that's where the *real* evil is |
| 21:26 | <sicking> | annevk: have you talked to anyone in CJK countries about this? |
| 21:26 | <annevk> | sicking: not sure existing documents will be the primary use case, but I'm happy with what hsivonen implemented |
| 21:26 | <sicking> | annevk: have you talked to anyone in CJK countries about this? |
| 21:27 | <sicking> | annevk: and why do you think new content is the primary use case? |
| 21:27 | <zewt> | people in cjk countries (especially japan) seem to live under serious misunderstandings of utf-8 (not that saying that changes it) |
| 21:27 | <annevk> | sicking: I haven't, though I did suggest pinging myakura last time you brought this up |
| 21:28 | <sicking> | annevk: sigh, ok |
| 21:28 | <annevk> | sicking: I'm not really worried about shipping a more restrictive feature and then have people complain and we adapt |
| 21:28 | <annevk> | sicking: I'm more worried about getting in the same mess we got in with CORS |
| 21:28 | <sicking> | annevk: we get basically no feedback from that part of the world. I wouldn't take a lack of complaint to mean anything |
| 21:28 | <annevk> | where we have something very complex that's hard to use for people |
| 21:28 | <annevk> | sicking: this feature is not really deployed |
| 21:28 | <sicking> | annevk: yeah, the fact that it's header based is a bigger problem than I had thought |
| 21:29 | <annevk> | sicking: when I'm next in Tokyo I'll ask |
| 21:29 | <sicking> | annevk: the deployment cycle is probably at least a year or two for something like this. Waiting for deployment before we see what the use cases are will create a 4 year cycle |
| 21:30 | <sicking> | annevk: i'll email some of our mozilla-japan people and cc you |
| 21:30 | <annevk> | just let them email public-webapps |
| 21:30 | <annevk> | that seems better |
| 21:31 | <zewt> | annevk: i don't think it needs to be complex; take "determining the character encoding" and throw away the last three steps (replace with utf-8) |
| 21:31 | <annevk> | the use case to me is primarily that it's easy to get a DOM out of some HTML on the server |
| 21:31 | <zewt> | (or rather, any new complexity) |
| 21:31 | <sicking> | annevk: we're still really bad at getting the community to speak up on that list |
| 21:31 | <sicking> | annevk: and that's the english speaking community |
| 21:31 | <annevk> | that you have to maybe fix that HTML first is not really a big concern to me, things need to adapt over time to meet new requirements |
| 21:32 | <sicking> | annevk: i didn't understand that |
| 21:32 | <annevk> | sicking: myakura chairs a Japenese interest group and is involved in the Japenese HTML5 user group (or some such) with over 2000 developers involved |
| 21:35 | <sicking> | annevk: is this myakura.web⊙gc? |
| 21:36 | <sicking> | annevk: i see very little feedback from him |
| 21:36 | <sicking> | annevk: which either means that the user group is happy with everything we do, or that the communication channel isn't working that great yet |
| 21:38 | <annevk> | I very much doubt this is a big problem; if you run the kind of site that uses XMLHttpRequest you will very soon run into encodings and adapt appropriately |
| 21:39 | <annevk> | e.g. most things transmitted towards the server will be in UTF-8 |
| 21:39 | <zewt> | a lot of people in japan don't "like" utf-8 and use sjis on purpose |
| 21:39 | <sicking> | annevk: if you're submitting stuff yeah |
| 21:40 | <annevk> | if you're reading with responseText too |
| 21:40 | <annevk> | it's fairly limited what responseText does |
| 21:40 | <annevk> | (more broad than I'd like, but still limited) |
| 21:43 | <annevk> | zewt: not really sure that's still the case |
| 21:44 | <jgraham> | I heard it was still the case recently, but I don't think I have data |
| 21:44 | <zewt> | hard to gather real data on, it's a social/perception thing |
| 21:44 | <annevk> | anyway, using shift_jis is not really problematic |
| 21:47 | <zewt> | (... as long as it's declared correctly) |
| 21:47 | <annevk> | the only problem with shift_jis is that we haven't really defined all its details |
| 21:48 | <annevk> | IE that "shift_jis" actually maps to Microsoft Code Page 932 with error handling that is probably not even defined in that Code Page |
| 21:48 | <annevk> | s/IE/i.e./ |
| 21:50 | <zewt> | trying to fully specify the legacy encodings doesn't exactly seem worth it |
| 21:51 | <annevk> | every now and then we still hit compat issues and it makes it harder for people writing software that interprets legacy content |
| 21:51 | <annevk> | seems totally worth it |
| 21:52 | <annevk> | it's a bit of work, but a lot can be automated |
| 21:52 | <zewt> | seems like another lever to get more people to stop perpetuating legacy encodings :P |
| 21:53 | <zewt> | at least most encodings are simpler and tiny compared to the CJK ones |
| 21:53 | <annevk> | I did a bunch of work on the 8bit encodings already http://annevankesteren.nl/2010/8-bit-labels |
| 21:54 | <annevk> | just need to make some decisions on who is right, and update everything for today's implementations |
| 21:54 | <annevk> | Opera and Gecko made a few changes |
| 22:05 | <sicking> | annevk: by the way, we can totally "fix" CORS though |
| 22:06 | <sicking> | annevk: adding back the in-document access indicator that we used to have for XML would do the trick |
| 22:06 | <sicking> | annevk: but not for XML of course |
| 22:07 | <sicking> | annevk: adding a in-line for JSON would be huge |
| 22:07 | <zewt> | but images :( |
| 22:07 | <sicking> | s/in-line/in-line access descriptor/ |
| 22:07 | <sicking> | zewt: i don't see how you could do those without using headers |
| 22:07 | <zewt> | (not *personally* worried; I'd never willingly work in an environment where I can't set headers) |
| 22:08 | <jgraham> | Hmm, how would one add it to JSON? |
| 22:08 | <zewt> | though I guess that's not enough, since what matters is whether the service I'm using can set it, not what I can do :( |
| 22:08 | jgraham | might be misunderstanding |
| 22:09 | <zewt> | you could add it in a non-conforming-to-JSON way with a Javascript header, though that'd be evil |
| 22:09 | <annevk> | sicking: your definition of fixing it is adding yet more bloat; I'm intrigued :) |
| 22:09 | <sicking> | annevk: i think we would have needed the headers no matter what |
| 22:10 | <sicking> | annevk: features != bloat |
| 22:10 | <sicking> | annevk: unused features == bloat |
| 22:10 | <sicking> | or "unneeded" more accurately |
| 22:12 | <zewt> | wonder if there are security implications to inline declarations (eg. upload file to github or a pastebin or something, use the "raw text" link to serve remote files with the access grant inline) |
| 22:13 | <tantek> | Hixie, per our discussion a few days ago on permit space instead of "T" in the date-and-time microsyntax, where you said "tantek: if we can collect evidence e.g. showing that there are common parsers that support a nicer format, i'm certainly all for it, fwiw" - I've now collected that evidence and think we have enough to go on. |
| 22:13 | <tantek> | http://wiki.whatwg.org/wiki/Time_element#permit_space_instead_of_T_in_datetimes |
| 22:14 | <tantek> | cc: TabAtkins, mkanat, kennyluck |
| 22:15 | <zewt> | tantek: fyi, i think i was mistaken about IE8 (may have mixed up my browser windows or something) |
| 22:15 | <tantek> | zewt - noted in the research :) |
| 22:15 | <zewt> | so you may as well remove the reference :) |
| 22:16 | <tantek> | well it helps to say if it supports it or not one way or the other |
| 22:16 | <tantek> | do you have it in front of you? |
| 22:16 | <tantek> | can you check: |
| 22:16 | <tantek> | data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script> |
| 22:16 | <zewt> | pretty sure the second half of that sentence is the correct one (its own toString format) |
| 22:16 | <tantek> | if we can say for sure it returns NaN - that's another useful data point |
| 22:16 | <zewt> | ie8 != data: |
| 22:16 | <tantek> | ah thanks |
| 22:17 | <zewt> | and yes, returns NaN |
| 22:17 | <zewt> | returns NaN for "2011-11-11T11:11:11" as well--useful to include both (if an implementation doesn't support *T*, it doesn't matter if it doesn't support * * either) |
| 22:19 | <tantek> | oh that's interesting, yes. |
| 22:19 | <tantek> | I wonder if that's the same for IE9 and IE10 also |
| 22:20 | <zewt> | "it does help readability, incrementally" i think it's at least marginally stronger than that; it's a natural, human format, where *T* really isn't |
| 22:20 | <zewt> | fwiw, anyway |
| 22:23 | <heycam> | annevk, I did not add a warning about const, but I am happy to. wording suggestions welcome. |
| 22:25 | <annevk> | heycam: I added something in the bug |
| 22:25 | <heycam> | thanks |
| 22:25 | <annevk> | heycam: preferably .warning has a red border and such :) |
| 22:25 | <heycam> | that's perhaps a good idea |
| 22:25 | <zewt> | tantek, fyi postgresql also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07) |
| 22:26 | <zewt> | (minor data point) |
| 22:30 | <Hixie> | tantek: k, i'll update the proposal in the spec |
| 22:54 | <Hixie> | tantek: ok, i'll commit the patch to the whatwg copy; can you let the htmlwg know of it? |
| 22:58 | <Hixie> | tantek: it's checked in |
| 22:59 | <tantek> | thanks much! |
| 23:00 | <Hixie> | diff url is http://html5.org/r/6845 |
| 23:01 | <Hixie> | heycam: yt? |
| 23:02 | <heycam> | Hixie, hi |
| 23:02 | <Hixie> | heycam: so people don't like that DedicatedWorkerGlobalScope and SharedWorkerGlobalScope both seem to be WorkerGlobalScopes |
| 23:03 | <Hixie> | heycam: so i'm changing the spec so that dedicated workers have a global scope that's a DedicatedWorkerGlobalScope, and similarly for shared workers |
| 23:03 | <heycam> | let me open the spec and remind myself how they're currently specced |
| 23:03 | <Hixie> | heycam: but it'd be nice if i could hide that they really inherit from WorkerGlobalScope |
| 23:03 | <Hixie> | heycam: so my question is, is there some way i can have an inheritance hierarchy in the spec but flatten it in implementations? |
| 23:04 | <Hixie> | heycam: so that the result is the same as if i had specced it with some copy-and-paste |
| 23:04 | <heycam> | is that not what you were intending to use the [Supplemental] in the spec currently for? |
| 23:04 | <heycam> | and can you clarify what you mean about people not liking that they "both seem to be WorkerGlobalScopes"? |
| 23:04 | <Hixie> | the current spec text is trying to get the flattening but with the name of hte interface being the ancestor interface |
| 23:05 | <Hixie> | whereas i now want to flatten them so that the interfaces have their derived names |
| 23:05 | <Hixie> | and the ancestor name is a spec detail |
| 23:05 | <Hixie> | so you can't tell in the prototype chain that the global scope is defined as two interfaces |
| 23:06 | <heycam> | I feel like this has come up before and I've wondered why it is important not to be able to observe the inheritance |
| 23:06 | <Hixie> | the reasoning here being that there's no point splitting the interface in two, since a script in a worker can only ever get one instance of this interface anyway, so why waste the author's time having the author remember which interface they have to poke to override something |
| 23:07 | <Hixie> | it looks silly to have a singleton defined by a hierarchy of unique interface prototype objects |
| 23:07 | <heycam> | ok, i can see that |
| 23:07 | <annevk> | Hixie: use implements + NoInterfaceObject |
| 23:07 | <heycam> | yes just what I was going to say |
| 23:07 | <Hixie> | aha, that works, cool |
| 23:08 | <heycam> | but in more words :) |
| 23:08 | <Hixie> | and don't inherit |
| 23:08 | <Hixie> | ok |
| 23:08 | <annevk> | nn |
| 23:08 | <heycam> | bb |
| 23:08 | <Hixie> | nn |
| 23:08 | <ap_> | Hixie: is <li value="-1"> actually supposed to work now? |
| 23:09 | heycam | wonders if that is the final instance of [Supplemental] which will now be disappearing |
| 23:09 | <Hixie> | heycam: i believe so, it's why i'm poking at this. will let you know. |
| 23:09 | <ap_> | as in, the browser will display "-1." |
| 23:09 | <heycam> | cool cool |
| 23:09 | <Hixie> | ap_: yes |
| 23:10 | <heycam> | so before when you said "so people don't …" you actually meant "you don't like" ;) |
| 23:10 | <Hixie> | heycam: not just you, but any means |
| 23:10 | <heycam> | k |
| 23:10 | <ap_> | Hixie: do you happen to know if there are any list-style-type that cannot express negative numbers in print, or use something other than a "-"? |
| 23:10 | <Hixie> | heycam: the actual e-mail i had in my pile to remind me of this was from sicking |
| 23:11 | <Hixie> | ap_: lots don't have negative numbers (e.g. roman, alphabetic), no idea if any don't use - |
| 23:11 | <Hixie> | TabAtkins: ping ^ |
| 23:11 | <Hixie> | ap_: (those that don't support the range defer to decimal for unsupported numbers) |
| 23:12 | <ap_> | Hixie: thanks. where is the "defer to decimal" part specced? |
| 23:12 | <heycam> | single, busy mailing lists better than multiple, quieter ones: http://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/ |
| 23:12 | <zewt> | heycam: a fact that's been basic knowledge for years :P |
| 23:12 | <Hixie> | ap_: looks like css3 lists supports the negative punctuation being explicitly set for a counter, e.g. to use parentheses: http://www.w3.org/TR/css3-lists/#descdef-negative |
| 23:13 | <Hixie> | ap_: looks like there's a whole descriptor thing for lists, and fallback is specified by http://www.w3.org/TR/css3-lists/#descdef-fallback |
| 23:13 | <heycam> | zewt, I should probably merge some mail folders and not just have a single folder per list, now that I have to vertically scroll in thunderbird to see them all... |
| 23:13 | <Hixie> | no idea what the non-TR/ link is for this, i don't see a link at the top |
| 23:14 | <zewt> | heycam: it's really lame that gmail's label grouping doesn't let you view the group and see all of the sub-labels |
| 23:14 | <heycam> | oh, that does sound a bit lame |
| 23:14 | <heycam> | still, "all email clients suck" |
| 23:14 | <zewt> | it does nothing but gruop them visually in the label list ( = who cares) |
| 23:15 | <ap_> | Hixie: thanks |
| 23:16 | <zewt> | also group |
| 23:23 | <Hixie> | heycam: i have this paragraph for the three interfaces that define the interface of global scope objects: |
| 23:23 | <Hixie> | <p>The <code>DedicatedWorkerGlobalScope</code> interface must not |
| 23:23 | <Hixie> | exist if the interface's <span>relevant namespace object</span> is |
| 23:23 | <Hixie> | not a <code>DedicatedWorkerGlobalScope</code> object. <a |
| 23:23 | <Hixie> | href="#refsWEBIDL">[WEBIDL]</a></p> |
| 23:23 | <Hixie> | heycam: does it make sense to ahve an attribute for that? [GlobalScopeInterface] or something? |
| 23:25 | <heycam> | good question, I am not sure just yet what's the best way of describing this |
| 23:25 | <Hixie> | k. i'll leave it with that paragraph for now. |
| 23:26 | <heycam> | ok. "relevant namespace object" as a term will likely disappear soon, since we're going to drop modules from Web IDL. |
| 23:26 | <heycam> | I'll have a think about whether it makes sense to talk about globals in the spec |
| 23:29 | <Hixie> | heycam: ah ok. let me know if/when you do that so i can update this accordingly (or i can update it now if you have any idea what it should say instead?) |
| 23:29 | <heycam> | Hixie, leave it for now and I'll let you know how to update it once I've figured it out :) |
| 23:29 | <Hixie> | maybe "the ThisBinding of the global execution context" or something |
| 23:30 | <Hixie> | (that's the terminology we use to talk about WindowProxy's effects) |
| 23:45 | <tantek> | zewt - I added your additional opinion and data point to the proposal |
| 23:46 | <tantek> | Hixie - status updated in the proposal to reflect its inclusion in the spec. http://wiki.whatwg.org/wiki/Time_element#permit_space_instead_of_T_in_datetimes |
| 23:46 | <tantek> | one bit of consensus at a time. I'll follow-up on public-html. |
| 23:47 | <Hixie> | tantek: cool, tanks |
| 23:47 | <Hixie> | thanks even |