| 09:49 | <zcorpan_> | isn't chairship in html wg also invite-only? |
| 09:49 | <jgraham> | zcorpan_: Didn't hixie say that? |
| 09:50 | <zcorpan_> | dunno, still have 24 emails to read |
| 11:23 | <annevk3> | I guess I should review Uniform Messaging at some point... |
| 11:26 | <Hixie> | does it affect xbl2, <canvas>/<img>, and <video>'s future use of CORS? |
| 11:29 | <annevk3> | They say they want to replace CORS with it |
| 11:30 | <annevk3> | And solve all the same use cases... |
| 11:30 | <annevk3> | I don't think that is possible given what I know about the design and I believe supporting UM on top of CORS is trivial, but at some point I ought to make sure that is all true and point it out I guess... |
| 11:31 | <gsnedders> | "That's what she says/But the words of an eager lover should be treated like words written on wind and swift flowing water" |
| 11:32 | <Hixie> | good thing i didn't integrate anything with CORS yet i guess |
| 11:33 | <Hixie> | i wonder if UM also affects the CORS-like thing in websockets |
| 11:34 | <annevk3> | I would guess Mark is not in favor of that either since it is origin-based |
| 11:45 | <salty-horse> | the second example here uses a really odd notation for tags closing the one on the previous line: "><p" -- http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-section-element |
| 11:45 | <salty-horse> | and the zork example here also has this notation, and it's wrong (closes a tag twice): http://www.whatwg.org/specs/web-apps/current-work/#the-pre-element |
| 11:46 | <salty-horse> | it also appears here: http://www.whatwg.org/specs/web-apps/current-work/#a-group-of-images-that-form-a-single-larger-picture-with-no-links |
| 11:46 | <annevk3> | weird syntax is on purpose |
| 11:46 | <annevk3> | for bugs you should prolly file bugs |
| 12:01 | <salty-horse> | filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8455 |
| 12:01 | <Philip`> | erlehmann: You can just copy-and-paste the URL and add "multipage" before the # and it'll give you the proper version |
| 12:03 | <salty-horse> | Philip`, nice! |
| 12:13 | <annevk3> | what also worries me a bit is that studying further threads such as "Re: CSRF vulnerability in Tyler's GuestXHR protocol?" have unanswered questions |
| 12:13 | <annevk3> | it's not really clear to me everything has been thought through entirely |
| 12:14 | <Hixie> | i haven't been paying enough attention to really know either way |
| 12:15 | <murr4y> | i just sent my first mailing list mail ever :p |
| 12:15 | <murr4y> | am i supposed to recieve it back from the list? |
| 12:15 | <Hixie> | :-) |
| 12:15 | <Hixie> | depends on your settings and your mail service provider |
| 12:16 | <Hixie> | which list? |
| 12:16 | <murr4y> | help |
| 12:17 | <Hixie> | what was the subject? |
| 12:19 | <murr4y> | it was: Validator error: End tag for body seen but there wereunclosed elements |
| 12:19 | <murr4y> | my name is ali |
| 12:19 | <murr4y> | just checked my settings, i am set to recieve my own posts |
| 12:19 | <murr4y> | maybe it takes a few minutes, guess i was a bit impatient :p |
| 12:20 | <Hixie> | ah yes, i saw your mail a while back |
| 12:20 | <Hixie> | dunno why you wouldn't have received it |
| 12:20 | <Hixie> | it did make it to the list :-) |
| 12:20 | Philip` | thought the default was to not receive your own messages |
| 12:20 | <Dashiva> | Is Roy really arguing that we shouldn't add anything that can already be done in JS? |
| 12:20 | <annevk3> | murr4y, see http://lists.whatwg.org/pipermail/help-whatwg.org/2009-December/date.html |
| 12:21 | <murr4y> | ah, nice :) |
| 12:23 | <Dashiva> | ... and he doesn't seem to understand the point of CR |
| 12:23 | <annevk3> | Hixie, so the network events thingie I copied from you, but I guess they don't need to be queued if the "same-origin request event rules" themselves are a task (and they are for the async scenario) |
| 12:24 | <annevk3> | might actually simplify a few things... |
| 12:24 | <Hixie> | annevk3: yeah if you're in a task, and if the task completes quickly (doesn't spin the event loop or pause or anything), then you can fire events synchronously within the task |
| 12:25 | <Hixie> | also so long as you never execute script cross-origin |
| 12:26 | <annevk3> | so why are image load events queued rather than dispatched directly? |
| 12:26 | <annevk3> | do impls really do it that way? |
| 12:26 | <Hixie> | dispatched directly from what? |
| 12:26 | <annevk3> | dispatched directly from the fetch task if the complete condition has been met |
| 12:26 | <annevk3> | sorry, available condition |
| 12:27 | <Hixie> | i guess that could be done too |
| 12:27 | <annevk3> | copying that is how XHR ended up with this bug |
| 12:27 | <annevk3> | :/ |
| 12:27 | <Hixie> | heh |
| 12:27 | <Hixie> | shouldn't copy without understanding :-) |
| 12:28 | <annevk3> | well, I thought I did |
| 12:28 | <Hixie> | :-) |
| 12:29 | <annevk3> | and I asked for review months ago on that change saying I was not entirely sure |
| 12:29 | <annevk3> | of course it happens just after we publish a Last Call WD |
| 12:29 | annevk3 | is getting annoyed with that |
| 12:29 | <jgraham> | salty-horse: Yes that outliner probably is broken gsnedders has one that works |
| 12:30 | <gsnedders> | Well, it might work. I'm not promising anything. |
| 12:31 | <Hixie> | annevk3: eh, writing specs takes time. you can't rush reviews; q.f. my e-mail about hy i think web storage etc should have 6 months lc review at minimum |
| 12:31 | <Hixie> | annevk3: don't forget XHR was originally set to go to CR only by 2012 :-) |
| 12:34 | <annevk3> | :p |
| 12:36 | <annevk3> | Hixie, I guess |
| 12:36 | <annevk3> | Hixie, the change has been in for about 6 months by now though |
| 12:36 | <annevk3> | first TR/ draft with it was in August |
| 12:37 | <zcorpan_> | does anyone know a wysiwyg editor with css3 and html5 support? |
| 12:37 | <annevk3> | but yeah, stuff takes ages |
| 12:37 | <Hixie> | zcorpan_: live dom viewer? :-) |
| 12:38 | <zcorpan_> | heh |
| 12:42 | <Dashiva> | Microdata isn't ready to compete against RDFa on many levels [...] published W3C REC status |
| 12:42 | <Dashiva> | We can't let Microdata become a REC because it's not a REC |
| 12:43 | <Hixie> | yeah the arguments for removing microdata don't seem all that rational to me |
| 12:43 | <Hixie> | i don't really get it |
| 12:43 | <Hixie> | it's like people want it killed but don't dare suggest that |
| 12:43 | <Hixie> | which seems pretty silly |
| 12:43 | <Hixie> | given how many things we've killed so far in html5 |
| 12:43 | <Hixie> | it's hardly a controversial thing to suggest |
| 12:45 | <zcorpan_> | hasn't that been suggested too? |
| 12:45 | <Hixie> | only by shelley, i think |
| 12:45 | <Dashiva> | They do suggest that too, but that's harder to achieve |
| 12:45 | <Hixie> | the arguments for dropping it seem much more rational to me |
| 12:45 | <zcorpan_> | maybe it's the next step of the agenda |
| 12:46 | <Dashiva> | Once it's a separate spec, proposal to publish as note and abandon it |
| 12:46 | <Dashiva> | It's surprising how many fans of the w3c process are coming out and saying "You must have implementations before LC" in various situations lately |
| 12:50 | <annevk3> | "whatever works" |
| 13:34 | <Hixie> | anyone understand what http://www.w3.org/Bugs/Public/show_bug.cgi?id=8108 is asking? |
| 13:36 | <annevk3> | sounds somewhat similar to the transparency for events thingie someone was asking about |
| 13:36 | <annevk3> | i.e. something to be addressed with extensions to pointer-events |
| 13:36 | <annevk3> | but it's quite vague so maybe I'm wrong :) |
| 13:39 | <jgraham> | It sounds like it was auto-translated |
| 13:40 | <jgraham> | I guess it means something about whether objects should revieve events if they are transparent |
| 13:44 | <WWFan> | i wish browsers would be faster with their implementations :( |
| 13:45 | <Hixie> | k, thanks |
| 13:45 | <Hixie> | WWFan: they'd be more buggy if they were faster, probably :-) |
| 13:52 | Philip` | wonders if Hixie could easily make his Bugzilla-posting script wrap text at the same width as Bugzilla itself wraps text, so it doesn't end up with individual words on lines by themselves |
| 13:52 | <Hixie> | the posting script does wrap text to the same width that bugzilla does, because it's bugzilla doing the wrapping |
| 13:52 | <Hixie> | i just send an unwrapped string |
| 13:53 | <Philip`> | Oh |
| 13:53 | <Philip`> | Maybe you should wrap text manually then, since Bugzilla seems to get it wrong :-) |
| 13:53 | <Philip`> | (Well, not manually, but in the posting script) |
| 13:54 | <Philip`> | It is slightly aesthetically displeasing and therefore a grave concern |
| 13:56 | <Hixie> | i recommend contacting the bugzilla authors or giving me perl code that, given a string $text, mutates $text to your satisfaction |
| 13:57 | <Hixie> | (and has no other side-effects other than CPU and memory usage) |
| 13:57 | <Dashiva> | Darn, I was hoping to do it on the GPU |
| 13:58 | <Dashiva> | Submit a comment, render the result, do graphical analysis, delete and retry if it doesn't match the requirements for an acceptable result |
| 13:58 | <Hixie> | i don't think i have a GPU on this machine |
| 14:03 | <Philip`> | use Text::Wrap; |
| 14:03 | <Philip`> | $Text::Wrap::columns = 79; |
| 14:03 | <Philip`> | # ... |
| 14:03 | <Philip`> | $text = wrap('', '', $text); |
| 14:10 | <Hixie> | i have updated the script accordingly but not tested it |
| 14:10 | <Hixie> | so someone should file a (real) bug to see if still works |
| 14:12 | <Hixie> | annevk3: i sent a comment on UM. It might be helpful for you, when you review UM, to go through the old requirements for CORS (like being able to handle very large lists of origins to say yes to, such that the header can't include a list of origins), and make sure that UM matches them. |
| 14:13 | <annevk3> | my understanding is that UM does not work with origins at all |
| 14:14 | <Philip`> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=8457 - it didn't die or anything |
| 14:14 | <Philip`> | so that's good |
| 14:15 | <Philip`> | (though that particular bug doesn't help see if it's wrapping correctly) |
| 14:29 | <annevk3> | my MacBook crashed... |
| 14:29 | <annevk3> | (again) |
| 14:29 | <annevk3> | (three times so far today, so much fail) |
| 14:32 | <annevk3> | Hixie, so yeah, I think the design is based around some concept of tokens, but the details of that have not been explained fully I think |
| 14:32 | <annevk3> | Hixie, but maybe I'm missing something |
| 15:18 | <Hixie> | annevk3: i couldn't find any tokens in their proposal, just a single on/off flag |
| 15:19 | <annevk3> | yup |
| 15:19 | <annevk3> | I guess Tyler still has the idea to transmit such data through URLs |
| 15:20 | <Hixie> | i guess i'll wait to see what his reply is |
| 15:20 | <annevk3> | afaict the proposal is just not complete enough as to how it ought to function, but hopefully a reply to your email will shed some light on that |
| 15:20 | <annevk3> | right :) |
| 15:21 | <Hixie> | this JSON thing in public-rdfa-in-xhtml-tf seems to somewhat miss the point of the object of prefixes |
| 15:22 | <salty-horse> | reasking from yesterday: is there an html5 way to specify that an <article> with a summarized post in a blog's main page and the permalink of the post page have the same content? |
| 15:22 | <Hixie> | and this thread on public-web-security that assumes that it's ok to embed arbitrary hostile css seems to be also somewhat missing the point |
| 15:22 | <Hixie> | salty-horse: can you elaborate? |
| 15:23 | <salty-horse> | I'll try rephrasing: is there a semantic way to mark a post's "read more" link in a blog's main page? a way to say that link is a permalink to the same content you see now? |
| 15:24 | <annevk3> | rel=bookmark? |
| 15:25 | <annevk3> | http://whatwg.org/html5#link-type-bookmark |
| 15:25 | <salty-horse> | that's it :) thanks! |
| 15:25 | <Hixie> | rel=bookmark is how you label a permalink, yeah |
| 15:26 | <salty-horse> | and it relates to the ancestor <article> which is exactly what I asked :) |
| 15:29 | <Hixie> | i could've sworn i'd already written the text for what 8111 is asking |
| 15:32 | <Hixie> | "a new version of opera was downloaded, but the update was not applied" |
| 15:32 | <Hixie> | well... apply it then |
| 15:42 | <Philip`> | Hixie: The line-wrapping seems to not be applied to messages like http://www.w3.org/Bugs/Public/show_bug.cgi?id=8110#c1 :-( |
| 15:43 | <Philip`> | so words like "If" and "please" still appear on lines by themselves |
| 15:43 | <Philip`> | at least with my particular browser and font and font size |
| 15:44 | <annevk3> | hmm, wfm |
| 15:44 | <Philip`> | (I was concerned about that rather than about the initial bug reports) |
| 15:44 | <Philip`> | annevk3: I guess you don't have my particular browser and font and font size :-) |
| 15:45 | <annevk3> | guess not |
| 15:45 | <Philip`> | It works for me if I zoom in or out, but not when I just look at it normally |
| 15:53 | <Hixie> | Philip`: that doesn't go through my script, i use safari to edit the bugs |
| 15:54 | <Hixie> | only comments by contributor⊙wo are scripted |
| 15:56 | <ttepasse> | Lines of poetry or source code I want to individually manipulate via the dom. The HTML5 way would be <pre><span>...</span><br>...</pre>? |
| 15:57 | <Dashiva> | If the lines are entities, sounds like a list |
| 15:57 | <Philip`> | Hixie: Oh, I'd assumed it was somewhat automated |
| 16:00 | <ttepasse> | <pre><ol> is sadly not allowed. |
| 16:00 | <Dashiva> | You wouldn't need <pre> |
| 16:01 | <Hixie> | ttepasse: lines of poetry (unless it has unusual formatting) should use <p><span>...</span><br><span>...</span></p> |
| 16:01 | <Hixie> | ttepasse: (the <span>s being needed only if you want to do DOM manipulation) |
| 16:02 | <Hixie> | ttepasse: source code would just be <pre><code><span>...</span>\n<span>...</span></code></pre> (where \n is a line break, not a literal "\n") |
| 16:02 | <Hixie> | (and again, <span>s here just for DOM manipulation) |
| 16:02 | <ttepasse> | Frustrating, but ok. |
| 16:02 | <Hixie> | why frustrating? |
| 16:03 | <ttepasse> | <line> is more expressive. |
| 16:03 | <Dashiva> | Not much difference between <line> and <span><br> |
| 16:03 | <Hixie> | if it wasn't for <br> already existing, <line> would probably be better |
| 16:03 | <Hixie> | but we already have <br>, so that's water under the bridge |
| 16:04 | <annevk3> | would <line> have white-space:nowrap ? |
| 16:04 | <annevk3> | or pre-line or some such |
| 16:04 | <Hixie> | dunno, haven't thought about it |
| 16:05 | annevk3 | was never quite sure how <l> would work and whether it would be the quite the same as <br> |
| 16:06 | <ttepasse> | I'd imagine white-space: normal for poetry and white-space:pre for XHTML2s "blockcode > l" |
| 16:06 | <Hixie> | ok wtf. <table rules=all> has an effect on _padding_?? |
| 16:09 | <othermaciej> | Hixie: good point re the public-web-security thread |
| 16:09 | <Hixie> | actually make that border-spacing |
| 16:09 | <othermaciej> | Hixie: you can do a lot of damage, security-wise, just by moving controls around on the page, making them invisible, injecting images or text content.... |
| 16:10 | <Hixie> | othermaciej: yeah! |
| 16:10 | <Hixie> | othermaciej: if you accept arbitrary input, you have to whitelist, it's not rocket science |
| 16:10 | <othermaciej> | I'm not sure if they are trying to defend against deliberate self-injection of arbitrary CSS from an untrusted source, or just mitigate the damage if it occurs accidentally (on a site that successfully prevents script injection) |
| 16:10 | <annevk3> | the latter |
| 16:11 | <annevk3> | hmm, I guess it can apply to both |
| 16:11 | <annevk3> | but it seemed like they were walking about injection scenarios |
| 16:11 | <annevk3> | talking, not walking |
| 16:11 | <othermaciej> | annevk3, Hixie: I think UM is probably worth supporting as an alternate XHR mode (it's useful for sandboxing toolkits like Caja), but it's not at all obvious how one would apply it to video |
| 16:11 | <annevk3> | or <img> |
| 16:11 | <annevk3> | or EventSource |
| 16:12 | <annevk3> | etc. |
| 16:12 | <othermaciej> | like, if your secret token is in the page then anyone can get it using "View Source" |
| 16:12 | <annevk3> | but UM can be one extra flag in the current XHR spec rather than a whole separate spec |
| 16:12 | <Hixie> | isn't UM a subset of CORS? |
| 16:12 | <Hixie> | specifically, basically the subset IE implements? |
| 16:12 | <othermaciej> | annevk3: I don't mind if there's a separate spec for what the flag does, assuming that's extensive enough to be more than a few sentences |
| 16:12 | <annevk3> | you'd always exclude credentials and set Origin to null |
| 16:13 | <Hixie> | why would a site opt out of including Origin |
| 16:13 | <annevk3> | given that all the infrastructure is already in XHR/CORS it seems like a waste, but sure |
| 16:13 | <Hixie> | if it knows to opt out of it, why would it use it |
| 16:13 | <Hixie> | the point of the proposal seems to be to remove the risk that someone might use Origin at all |
| 16:13 | <annevk3> | well yeah, it's not clear we need it at all if we decide CORS is the way to go |
| 16:13 | <Hixie> | so allowing people to disable Origin is unlikely to satisfy anyone |
| 16:15 | <Hixie> | sweet jesus |
| 16:15 | <Creap> | why is <table border> still in HTML5? |
| 16:15 | <Hixie> | i'm 4-for-4 on uninteroperable behaviour for mixing CSS with table frames=all |
| 16:15 | <Hixie> | er, rules=all |
| 16:17 | <othermaciej> | Hixie: ability to *opt* out of Origin does serve one use case, namely allowing content sandboxed by something like Caja to still do XHR |
| 16:18 | <annevk3> | you would get that automatically with <iframe sandbox>, fwiw |
| 16:19 | <Hixie> | othermaciej: that still wouldn't be safe for same-origin requests |
| 16:20 | <othermaciej> | (assuming non-sandboxed content on that site does send Origin with its XHR requests) |
| 16:20 | <othermaciej> | (and checks it) |
| 16:21 | <othermaciej> | annevk3: I am not sure what problem if any people doing Caja-like things would have with <iframe sandbox> - they do dislike regular iframes since those let a bit too much power leak through (e.g. ability to navigate the top frame) |
| 16:21 | <Hixie> | this would also mean we should add new flags for EventSource, WebSocket, <video>, <img>, etc |
| 16:22 | <Hixie> | which i don't think makes sense |
| 16:22 | <othermaciej> | good point - the Caja model is not compatible with protecting such things purely via Origin without addition of some new flag |
| 16:22 | <Hixie> | i think if you're doing something like caja you have to build the entire platform from the ground up, you can't do half the job and then rely on the browser's XHR or WebSocket, etc. |
| 16:23 | <othermaciej> | (for EventSource or WebSocket it is plausible, at least they are APIs) |
| 16:23 | <othermaciej> | Caja currently presumably does not pass through EventSource or WebSocket at all |
| 16:24 | <othermaciej> | but if they allow <img> and <canvas>, then Caja-tized content (or whatever the term is) can read the pixels of all of the embedding site's images |
| 16:37 | <TabAtkins> | Creap: The same reason tons of other retarded old presentational attributes are in HTML5 - because sites use them and rely on them working. <table border> is *not* valid HTML5, though - the spec says not to use it, but specifies how browsers should treat it when it does appear. |
| 16:37 | <Creap> | ok |
| 16:37 | <Hixie> | oh sorry creap, missed your question |
| 16:37 | <Hixie> | thanks tab |
| 16:37 | <TabAtkins> | np |
| 16:38 | <Creap> | I don't see how a site would rely on border for _working_ though? |
| 16:38 | <Creap> | border=0 for table layouts? |
| 16:38 | <Hixie> | TabAtkins: did you see manu's updated change proposal? not sure if there's anything that needs adding to yours, it didn't seem to make any particularly strong new points, but i might have missed something |
| 16:40 | <TabAtkins> | How strange. |
| 16:41 | <Hixie> | Creap: many sites use border, especially if they were written in the 90s |
| 16:44 | <TabAtkins> | Creap: More specifically, a browser which ignored <table border> entirely would render a lot of sites in a visibly uglier way than other browsers. So they'd be at a competitive disadvantage. HTML5 helps by defining precisely what they need to do when they see that attribute, since they'll have to handle it anyway. This way they don't have to spend QA time and money reverse-engineering... |
| 16:44 | <TabAtkins> | ...other browsers. |
| 16:59 | Hixie_ | tries to remember what the devapi list is called |
| 17:00 | <Hixie_> | ah, public-device-apis |
| 17:02 | <salty-horse> | googling for "html5 outline" gives http://james.html5.org/outliner.html as the first result. since that doesn't work, maybe that page could redirect to http://gsnedders.html5.org/outliner/ ? |
| 17:31 | Hixie_ | sends his ideas to public-device-apis to see if anyone has any suggestions for UI |
| 17:51 | <annevk3> | can't you just have something simple? that when you hit accept you see a little screen displaying whatever your camera aims at and maybe some audio animation for the mic |
| 17:51 | <annevk3> | and some visible stop button around there too |
| 17:51 | <annevk3> | maybe sound separately isn't even needed, it's pretty clear that it goes with video |
| 17:51 | <annevk3> | at least in other contexts, e.g. skype |
| 17:54 | <annevk3> | oh, nobody is here |
| 17:54 | <annevk3> | netsplits ftw |
| 18:12 | <annevk3> | this split sucks |
| 18:13 | <annevk3> | I guess I should go have dinner instead of complaining |
| 18:24 | <annevk3> | Hixie_, see logs for some thoughts |
| 18:24 | <annevk3> | netsplit ftl |
| 18:24 | <Hixie_> | looking... |
| 18:25 | <Hixie_> | the problem is the "hit accept" part |
| 18:26 | <Hixie_> | also, you don't want a separate monitor window when you're doing video chat |
| 18:26 | <Hixie_> | you want your camera to be shown p-i-p in the incoming video's output |
| 18:26 | <Hixie_> | which is trivial with css and <video> |
| 18:27 | <Hixie_> | the problem is how to do the bit where the page asks for video, and the user accepts it |
| 18:27 | <Hixie_> | (or alternatively, the bit where the user tells the page he's ready to use video) |
| 18:29 | <TabAtkins> | Hrm. Does <video> allow different-origin @src to be used? |
| 18:30 | <TabAtkins> | My skim of that section doesn't see anything disallowing it. |
| 18:30 | <annevk3> | p-i-p? |
| 18:30 | <TabAtkins> | picture-in-picture |
| 18:30 | <Hixie_> | TabAtkins: yes, but we'll have to limit that to no-metadata-only later when we add metadata reading |
| 18:31 | <annevk3> | hmm, I suppose |
| 18:31 | <TabAtkins> | Hixie: That sucks. That means anyone can drain my bandwidth by hotlinking my videos. ;_; |
| 18:31 | <TabAtkins> | Image hotlinking is bad enough already. |
| 18:32 | <annevk3> | have there been issues with what Flash is using? |
| 18:32 | <Hixie_> | TabAtkins: they can anyway by using iframe |
| 18:32 | <TabAtkins> | I dunno what flash is using. |
| 18:32 | <Hixie_> | annevk3: flash uses a modal prompt, i believe. |
| 18:32 | <TabAtkins> | Hixie: Yeah, but then I have to have a page amenable to that, it's not as pretty, and it's more effort. |
| 18:33 | <Hixie_> | hm? |
| 18:33 | <TabAtkins> | More effort for the hotlinker, that is. |
| 18:33 | <TabAtkins> | While just doing <video src="xanthir.com/coolvid">; is trivial. |
| 18:34 | <AryehGregor> | Also will probably break, unless http:// became optional and I didn't notice. |
| 18:34 | <AryehGregor> | (is it optional?) |
| 18:34 | <TabAtkins> | Gah, technicalities. |
| 18:34 | <TabAtkins> | No, I'd need //xanthir.com |
| 18:34 | <AryehGregor> | It can't be, that's legitimately baseURL/xanthir.com/... |
| 18:35 | <Hixie_> | TabAtkins: well when we add teh cross-origin protection for metadata, we'll also add the ability to block cross-origin loads altgoether |
| 18:35 | <AryehGregor> | Which Firefox already does, right? |
| 18:35 | <Hixie_> | TabAtkins: but i thought we should wait for anne to go through the pain of figuring out how cors is to work before using it |
| 18:36 | <TabAtkins> | Hrm. Is it appropriate to make shutting down linking a proactive choice? CORS is all about doing the opposite. |
| 18:37 | <othermaciej> | TabAtkins: will you have a chance to update your counter-proposal soon? Would Thursday be a reasonable deadline? |
| 18:38 | <TabAtkins> | othermaciej: Yeah, I'm planning to do it at lunch today. Meant to do it yesterday, but ended up on the phone with shepazu instead. |
| 18:38 | <othermaciej> | wfm |
| 18:42 | <annevk3> | Hixie_, blocking altogether is not a feature of CORS |
| 18:42 | <annevk3> | I'm not all a fan of the @font-face crowd abusing it for that |
| 18:42 | <annevk3> | but maybe that's just me |
| 18:42 | <Hixie_> | sure it is, if the resource's allowed origin doesn't match the actual origin, that blocks it |
| 18:43 | <TabAtkins> | That's a same-origin restriction, and has nothing to do with CORS. |
| 18:43 | <annevk3> | it would just block for the purposes of sharing metadata |
| 18:43 | <TabAtkins> | CORS then just lifts that restriction. |
| 18:43 | <annevk3> | the idea is that CORS only lifts restrictions |
| 18:43 | <Hixie_> | TabAtkins: right, but if you start with the assumption that the default is not to block but to allow playback, just with metadata disabled, and then you apply CORS, you get what i described |
| 18:44 | <annevk3> | no you don't |
| 18:44 | <annevk3> | CORS applied on cross-origin images would not suddenly stop displaying external images |
| 18:44 | <Hixie_> | othermaciej: any idea if window.iTunes.waveform turns out to have been a good idea or not? (seems few if any LPs actually use it, is that just because they didn't want to, or does it have issues?) |
| 18:44 | <annevk3> | well, we could do that, but that was not the intent |
| 18:44 | <Hixie_> | annevk3: that depends on what the spec that applies CORS says |
| 18:44 | <TabAtkins> | CORS on external images would do basically nothing, right, anne? |
| 18:45 | <TabAtkins> | Since they already fully share themselves cross-origin? |
| 18:45 | <annevk3> | TabAtkins, it would stop tainting canvas |
| 18:45 | <Hixie_> | annevk3: anyway, this is all academic; eventually we'll need this three-mode thing, but not yet |
| 18:45 | <TabAtkins> | Ah, yes. |
| 18:45 | <Hixie_> | and then we can either use CORS, or modify CORS, or use something else, or whatever |
| 18:46 | <othermaciej> | Hixie_: I'm not sure what that is |
| 18:47 | <annevk3> | it seems I was right that UM requires a redesign of every feature |
| 18:47 | <othermaciej> | Hixie_: is that some extension to visualize the currently playing song? |
| 18:47 | <annevk3> | fun times |
| 18:47 | <annevk3> | really dinnertime now :) |
| 18:47 | <othermaciej> | Hixie_: I can ask some of the people who worked on that stuff |
| 18:47 | <Hixie_> | othermaciej: it exposes the amplitude of the current playback audio, split into 128 buckets, as far as i can tell |
| 18:48 | <Hixie_> | othermaciej: it would be useful to know what their experience was, in case we should just add it to HTMLMediaElement |
| 18:48 | <othermaciej> | Hixie_: amplitude, not FFT frequency analysis? |
| 18:48 | <Hixie_> | dunno |
| 18:48 | <Hixie_> | i assume it's the magnitude of each of 128 frequency ranges |
| 18:49 | <Hixie_> | but really no idea |
| 18:50 | <othermaciej> | I see, that would make sense as data for a visualizer |
| 20:19 | <zcorpan_> | Philip`: could you add Excalibur Logotype to web font optimizer? |
| 20:25 | <Philip`> | zcorpan_: No, since it doesn't seem to claim to have a license that allows modification and distribution |
| 20:25 | <Philip`> | (It doesn't actually seem to claim to have any license at all, as far as I can tell) |
| 20:26 | <zcorpan_> | bummer |
| 20:26 | <Philip`> | You could use the offline http://bitbucket.org/philip/font-optimizer/src/ tool though |
| 20:27 | <Philip`> | which should be easy to use (in theory) and means the licensing is entirely your responsibility |
| 20:29 | <zcorpan_> | too lazy at the moment :) |
| 21:31 | <TabAtkins> | I know it's invalid, but setting a boolean attribute to something other than "" or the element's name still sets it, correct? |
| 21:31 | <TabAtkins> | So, frex, <script async=true> would still make an async script? |
| 21:31 | <Philip`> | Yes |
| 21:31 | <Philip`> | All that matters is whether the attribute is present |
| 21:32 | <TabAtkins> | K, just making sure. All the invalid-but-specified things are always tucked away in places that I can't find easily. |
| 21:32 | <Philip`> | (<script async=false> would make it async too, which is a reason to not encourage use of async=true) |
| 21:33 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#boolean-attributes |
| 21:33 | <Philip`> | That covers the invalid cases |
| 21:35 | <TabAtkins> | The previous paragraph should make it clear, but it's easy to be paranoid. |
| 22:24 | <Sirisian_> | curious is rounded corners part of HTML5? I don't get why moz and webkit have their own style tags. |
| 22:25 | <Hixie_> | that's css |
| 22:25 | <Sirisian_> | ah yes |
| 22:25 | <Sirisian_> | whoops |
| 22:53 | <annevk3> | TabAtkins, you should point out that the IDL attribute is a boolean and so technically should not be set to a string |
| 22:54 | <annevk3> | TabAtkins, so script.async = true is perfectly fine |
| 22:54 | <TabAtkins> | I don't actually know that, so I won't point it out. |
| 22:54 | <annevk3> | and script.async = 'async' is not |
| 22:54 | <annevk3> | but script.setAttribute("async", "async") is |
| 22:54 | <annevk3> | etc. |
| 22:54 | <annevk3> | it seems the commenter is confused on that |
| 22:55 | <TabAtkins> | Nod, I am too. jQuery abstracts it enough that I don't have to care about things. |
| 22:55 | <annevk3> | I see... |
| 22:55 | <TabAtkins> | So the idl attribute *can* be unset with =false? Or no? |
| 22:56 | <annevk3> | it can, yes |
| 22:56 | <annevk3> | it's a boolean |
| 22:56 | <TabAtkins> | kk |
| 22:56 | <TabAtkins> | DOM is confusing. >_< |
| 22:56 | <annevk3> | see the HTMLScriptElement interface |
| 22:56 | <annevk3> | it's very simple |
| 22:57 | <annevk3> | setting the IDL attribute to false will in fact remove the content attribute |
| 22:57 | <TabAtkins> | So those are the names I should use when talking about this? "IDL attribute" and "content attribute"? |
| 22:58 | <annevk3> | it's what HTML5 uses |
| 22:58 | <TabAtkins> | kk |
| 22:58 | <annevk3> | you might see DOM attribute being referred to as property as well because that's what it is in ECMAScript, but that's somewhat confusing given CSS |
| 22:59 | <TabAtkins> | "DOM attribute" = "IDL attribute"? |
| 22:59 | <jgraham> | me does't think "very simple" is really true |
| 23:00 | <jgraham> | When script.async = false does exactly the opposite to script.setAttribute("async", false) |
| 23:00 | <annevk3> | TabAtkins, ah sorry, used to be DOM attribute, now is IDL attribute |
| 23:01 | <annevk3> | jgraham, they're completely different things |
| 23:01 | <jgraham> | annevk3: Yes. That's why it's not "very simple" |
| 23:05 | <annevk3> | mu |
| 23:09 | <annevk3> | (hopefully mu works for DOM arguments too) |
| 23:09 | <annevk3> | (maybe it should be "du") |
| 23:11 | <TabAtkins> | script.async="false" would still make it true, right? (Almost certain of this, but want to double-check before I send the email.) |
| 23:11 | <Philip`> | That sounds like an issue for WebIDL |
| 23:11 | <annevk3> | that's because a non-zero string evaluates to true in ECMAScript |
| 23:12 | <TabAtkins> | That's what I thought. |
| 23:14 | <Philip`> | http://dev.w3.org/2006/webapi/WebIDL/#es-boolean |
| 23:14 | <Philip`> | so it just defers to ES's ToBoolean |
| 23:15 | <Philip`> | (which does what annevk3 says) |
| 23:16 | <annevk3> | annevk3 is awesome |
| 23:26 | <annevk2> | hmm |
| 23:27 | <annevk2> | it's prolly no longer worth pointing out that SGML allowed omission of the attribute if the value itself gave enough context... |
| 23:39 | <annevk2> | I've learned history is important, but I always wonder if knowing (some of) the technical details of SGML is really helping me... |
| 23:40 | <Philip`> | Is your life not immeasurably enriched by knowing it's the attribute name rather than the value that is optional? |
| 23:41 | <annevk2> | So far I've not experienced that unfortunately |
| 23:41 | <annevk2> | Hopefully that is yet to come |
| 23:48 | <jwalden> | 𝅘𝅥𝅮 the best is yet to come 𝅘𝅥𝅮 |
| 23:52 | <annevk2> | Track 18 of Metal Gear Solid? :) |
| 23:53 | <annevk2> | (see also http://en.wikipedia.org/wiki/Metal_Gear_Solid_Original_Game_Soundtrack for those who do not have the CD) |
| 23:54 | <annevk2> | (Wikipedia is awesome) |