| 00:48 | <dglazkov> | good morning Whatwg! |
| 01:13 | <boogyman> | hi |
| 10:10 | <annevk> | Given WebRAW http://blog.bitops.com/blog/2013/06/04/webraw-asmjs/ and WebP, maybe allowing JavaScript to be an image decoder is not too bad... |
| 10:11 | <annevk> | Would have to sandbox it somehow so it also works for cross-origin images. And needs a story for sniffing. |
| 10:14 | <annevk> | Hixie_: Giving https://www.w3.org/Bugs/Public/show_bug.cgi?id=22185 priority would be great |
| 10:17 | <jgraham> | annevk: Well you could scope it to same-origin only, perhaps |
| 10:17 | <annevk> | jgraham: that's not acceptable |
| 10:17 | <jgraham> | Why not? |
| 10:17 | <annevk> | jgraham: because that doesn't match what the platform can do |
| 10:17 | <jgraham> | It seems strivtly better than it not working at all |
| 10:18 | <annevk> | jgraham: I think a worker without networking APIs or postMessage would be workable |
| 10:18 | <jgraham> | And matches what people retrospectively wish the platform had done |
| 10:18 | <annevk> | jgraham: the only thing it can do is decode a stream |
| 10:19 | <jgraham> | Making up a new kind of global scope for each new feature doesn't sound like fun |
| 10:19 | <MikeSmith> | fyi for anybody using w3c-test.org: I just spent an hour on there trying to unwedge apache problems due to debian upgrade bullshit and I have it running again but I very likely broke some other behavior of the web server in the process. So if you notice any problems please let me know. |
| 10:20 | <annevk> | jgraham: parallelize all the things |
| 10:21 | <annevk> | might be a problem even with that, you could encode data in output width/height |
| 10:59 | <annevk> | matjas: contacted DH |
| 10:59 | <annevk> | matjas: cc'd you |
| 11:14 | <annevk> | Ms2ger: yo |
| 11:14 | Ms2ger | appears |
| 11:15 | <annevk> | Is "The term context object means the object on which the algorithm (typically a method or attribute) being discussed was called. When the context object is unambiguous, the term can be omitted." clear enough you think? |
| 11:15 | <annevk> | Ms2ger: http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0154.html |
| 11:16 | <Ms2ger> | Hm |
| 11:16 | <Ms2ger> | A method/attribute isn't really an algorithm, though |
| 11:18 | <annevk> | so just or the things? |
| 11:18 | <Ms2ger> | "typically defining the behavior of a method or attribute" maybe? |
| 11:18 | Ms2ger | is not good with words |
| 11:18 | <annevk> | "The term <dfn>context object</dfn> means the object on which the algorithm, method, or attribute being discussed was called." |
| 11:18 | <hallvors> | context object === this object ? |
| 11:18 | <Ms2ger> | Yeah |
| 11:19 | <hallvors> | text is still a bit clumsy, in that you can not call an attribute |
| 11:19 | <jgraham> | "accessed" |
| 11:19 | <annevk> | thanks jgraham |
| 11:20 | <Ms2ger> | But can you access an algorithm? |
| 11:20 | <hallvors> | but if you mean the "this object" perhaps you could just reference a suitable definition in ES? |
| 11:20 | <hallvors> | though they might not do one for properties.. |
| 11:20 | <Ms2ger> | Maybe ... on which an algorithm, method, or attribute getter or setter ... |
| 11:20 | <annevk> | Ms2ger: yeah |
| 11:21 | <Ms2ger> | hallvors, well, it isn't a ES object :) |
| 11:21 | <annevk> | JSIDL will make most of this obsolete |
| 11:21 | hallvors | lacks context for the context object discussion |
| 11:21 | <annevk> | hallvors: see the link earlier |
| 11:21 | hallvors | is recontextualising |
| 11:22 | <jgraham> | JSIDL: Pretending it's turtles^Wjavascript all the way down since 2013 |
| 11:24 | <annevk> | jgraham: not very different from pretending there's no hardware limits |
| 11:25 | <jgraham> | Well sure, it might be a good pretense, I don't know |
| 11:26 | <jgraham> | Personally I am waiting for the time when we can design APIs where DOM objects hold references to JS objects |
| 11:27 | <annevk> | jgraham: like promises? |
| 11:27 | <Ms2ger> | Is Safari going to implement? |
| 11:27 | <annevk> | Ms2ger: implement what? |
| 11:27 | <Ms2ger> | Promises |
| 11:28 | <annevk> | Dunno, I'd assume so |
| 11:28 | <jgraham> | Doesn't Blink still have the same issue? |
| 11:29 | <jgraham> | So "is anyone other than Gecko going to implement DOM Promises", perhaps? |
| 11:32 | <annevk> | Blink is implementing for sure |
| 11:34 | <jgraham> | Interesting |
| 11:35 | <annevk> | Microsoft will too |
| 11:35 | <jgraham> | Last time I heard from abarth they had no plans to change thier memory management to deal with DOM->JS->DOM cycles |
| 11:35 | <jgraham> | This was pre-blink of course |
| 11:36 | <annevk> | abarth basically recommends implementing most directly in JS |
| 11:36 | <annevk> | which makes sense, as it'll end up there anyway |
| 11:37 | <jgraham> | I guess that might solve the problem for them |
| 11:55 | <hallvors> | annevk: "The plan is for debugging tools to solve this." - don't forget that it's common for web apps to log errors happening client-side and send the details home |
| 13:23 | <annevk> | hallvors: if at the end of your chain of futures you use .chain(e => log(e)) you'll be fine |
| 13:24 | <hallvors> | OK |
| 13:25 | <annevk> | sorry, .catch(...) |
| 13:40 | <annevk5> | marcosc: http://sysapps.github.io/sysapps/proposals/Contacts/Contacts.html is broken |
| 13:47 | <marcosc> | annevk: thanks, will fix |
| 13:48 | Ms2ger | liked the "[editing] Editing spec is no longer online" thread |
| 13:48 | <annevk> | Timestamps indicate darobin was quickest, but slowest to appear in my inbox :/ |
| 13:49 | <Ms2ger> | He was first for me |
| 13:49 | <Ms2ger> | Then you, then Art |
| 13:49 | <darobin> | there may be more replies to come |
| 13:49 | Ms2ger | replies |
| 13:49 | <annevk> | Given the lag, yes |
| 13:49 | <darobin> | Ms2ger hasn't responded yet, for instance |
| 13:50 | <annevk> | I should have learned by now not to reply to those emails |
| 13:50 | <annevk> | But every now and then... |
| 13:50 | <darobin> | yeah so should I |
| 13:50 | <darobin> | but then no one replies and it's not nice either |
| 13:55 | <hallvors> | guys, just relax and enjoy random syncronicity |
| 13:56 | <annevk> | hallvors: I think that's the problem, there'd be less 386 if I was relaxed |
| 14:16 | <manu-db> | darobin: HTML5 DOM question for you about the language associated with nodes. Does the document language expressed via the HTTP Header "Content-Language" get used by the DOM in any way? We're trying to figure out if the language specified in an HTTP Header is transferred in any way to a DOM environment. |
| 14:17 | <manu-db> | Hixie_: same question ^^ |
| 14:17 | <manu-db> | darobin, Hixie_: From a read of the spec, it doesn't look like it is... wondering if it's somewhere else in the spec. |
| 14:20 | <Ms2ger> | <p>If neither the node nor any of the node's ancestors, including the <span>root element</span>, |
| 14:20 | <Ms2ger> | have either attribute set, but there is a <span>pragma-set default language</span> set, then that |
| 14:20 | <Ms2ger> | is the language of the node. If there is no <span>pragma-set default language</span> set, then |
| 14:20 | <Ms2ger> | language information from a higher-level protocol (such as HTTP), if any, must be used as the |
| 14:20 | <Ms2ger> | final fallback language instead. In the absence of any such language information, and in cases |
| 14:20 | <Ms2ger> | where the higher-level protocol reports multiple languages, the language of the node is unknown, |
| 14:20 | <Ms2ger> | and the corresponding language tag is the empty string.</p> |
| 14:20 | <manu-db> | Yes, already read the spec... |
| 14:20 | <manu-db> | Let me rephrase the question. |
| 14:20 | <GPHemsley> | annevk: See also: https://github.com/GPHemsley/tiff-js , https://github.com/jnordberg/gif.js |
| 14:21 | <darobin> | manu-db: my understanding is that it does; at the very least setting Content-Language through <meta> certainly works |
| 14:21 | <manu-db> | Is there a way for an HTML+JavaScript app to get the "Content-Language" http header. |
| 14:21 | <darobin> | ah, that's a completely different question |
| 14:21 | <annevk> | GPHemsley: cool, yeah we should do this, but we need to figure out a way to deal with the width/height thing |
| 14:21 | <manu-db> | basically, I don't think that what's in the HTML spec is implementable in a JavaScript environment, is that true? |
| 14:21 | <Ms2ger> | No |
| 14:21 | <darobin> | presumably you mean the one that was used for the current page? |
| 14:21 | <manu-db> | and if so, what should we say in our specs when determining the language. |
| 14:22 | <Ms2ger> | But you have to implement HTTP as well |
| 14:22 | <manu-db> | darobin: yes |
| 14:22 | <manu-db> | Ms2ger: what do you mean, "you have to implement HTTP as well"? |
| 14:23 | <annevk> | Man, scumbag language. Almost always wrong, yet keeps wasting a bunch of time with regards to how to set it declaratively and how its inheritance chain works. |
| 14:23 | <Ms2ger> | HTML can be implemented in any language you want, but you can't necessarily pick just one section and implement it based on the rest of the platform |
| 14:23 | <manu-db> | darobin, Ms2ger: Here's the actual issue - Microdata and RDFa processors written in JavaScript need to be able to get the language of the current node... if the language is set via "Content-Language", there is no way for them to get at that information... so, should the spec just say that all Microdata and RDFa implementations shouldn't pay attention to Content-Language? |
| 14:24 | <annevk> | manu-db: I think the theoretical answer is that such implementations would be non-conforming until that primitive is exposed. |
| 14:24 | <Ms2ger> | I don't see why |
| 14:25 | <darobin> | no no, you don't want to say that implementation should ignore Content-Language just because you don't happen to have that information right now |
| 14:25 | <manu-db> | annevk: the only workaround we've found is for the processor to do an XHR request for the exact same document and get the Content-Language like that, but - super kludge (and you don't know if you're making the same request the browser did) |
| 14:25 | <darobin> | that's one way |
| 14:25 | <manu-db> | annevk: Is there a plan to get at the Content-Language primitive? |
| 14:26 | <darobin> | manu-db: well you seem to have a use case : |
| 14:26 | <darobin> | :) |
| 14:26 | <manu-db> | darobin: This discussion is going in a direction I didn't want it to go in. :) |
| 14:26 | <annevk> | manu-db: there's an open bug for it |
| 14:27 | <annevk> | manu-db: see DOM Standard's open bugs |
| 14:27 | <darobin> | manu-db: can't you use XPath for that? |
| 14:27 | <manu-db> | annevk: ok, thanks... reading now. |
| 14:27 | <manu-db> | darobin: I'm not hip with the XPath - how would you do that? |
| 14:27 | <annevk> | manu-db: it comes up every now and then, my main problem with doing it is that language seems so theoretical |
| 14:28 | GPHemsley | is still wondering what to do with http://wiki.whatwg.org/wiki/AAFC_Metadata_Application_Profile |
| 14:28 | <manu-db> | annevk: Yeah, I have the same issue with it - don't know of a single case where this would be useful... but we have a LC comment that we need to answer in a fairly logical way. |
| 14:28 | <annevk> | (other than as a rendering hint to work around Han unification, but we have heuristics for that) |
| 14:28 | <darobin> | ah, no, you can test for a language in XPath but not get one |
| 14:28 | <darobin> | that's a shame |
| 14:28 | <annevk> | (non-standardized heuristics, someone has to fix that) |
| 14:29 | <Ms2ger> | darobin, don't need xpath for that either |
| 14:29 | <annevk> | GPHemsley: seems fine |
| 14:29 | <annevk> | GPHemsley: it's not spam |
| 14:29 | <darobin> | isn't language also used to pick the proper glyph in parts of CJK? |
| 14:30 | <annevk> | darobin: see my () comments above |
| 14:30 | <darobin> | Ms2ger: yeah, CSS does that too. I thought XPath's lang() did more |
| 14:31 | <darobin> | annevk: ah, duh, hadn't seen that line about Han unification |
| 14:31 | <GPHemsley> | annevk: But does it belong on the wiki? And is it public domain? |
| 14:32 | <darobin> | I guess language information could also be used for automatic translation and for spellchecking of forms/editable |
| 14:37 | <manu-db> | annevk, darobin, Ms2ger: Ok, so just to be clear - I'm going to respond with something to this effect: "At present, it is impossible for a JavaScript implementation to deterministically retrieve an HTML5 element's language if no language information is provided in the document, but the language was set via the Content-Language HTTP Header. These Javascript-based implementations will continue... |
| 14:37 | <manu-db> | ...to be non-conforming in this specific case until the DOM exposes the language of an element [DOM bug #16489]. For this reason, document authors should specify the language of the document in the document itself to ensure that all HTML/RDFa implementations are capable of retrieving the language of the element." Is that response aligned with each of your thoughts on the matter? |
| 14:38 | <annevk> | manu-db: yeah |
| 14:38 | <manu-db> | annevk: ok, thanks - much appreciated. :) |
| 14:40 | <darobin> | manu-db: yeah that makes sense |
| 14:52 | <manu-db> | darobin, annevk: Outlined the use case for DOM element language property: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16489#c1 |
| 14:53 | <darobin> | Using HTTP for metadata sucks. Film at 11. |
| 15:12 | <manu-db> | Anyone here working at Google w/ the Gmail+schemas folks? You may want to tell them that their HTML+Microdata markup is so broken that it will be mis-interpreted horribly when processed by a conforming Microdata implementation: https://developers.google.com/gmail/schemas/embedding-schemas-in-emails -- or is putting a <span> element with embedded <time> elements a "thing" in HTML5 now? |
| 15:13 | <manu-db> | (that is, putting <time> in <span> in the <head>) |
| 15:13 | <manu-db> | (to see the problem, scroll down halfway on the page, click the "Microdata" example tab) |
| 15:18 | Ms2ger | wonders about http://twitpic.com/cvmib9 |
| 15:18 | <manu-db> | darobin: actually, just to sanity check - there are no plans on supporting arbitrary flow/phrasing content in HEAD are there? |
| 15:21 | <darobin> | manu-db: you mean like <head><p>blah</head>? |
| 15:21 | <manu-db> | darobin: I mean, specifically: <head><span><time .../></span></head> |
| 15:22 | <manu-db> | (like what they're doing in Gmail now) |
| 15:22 | <darobin> | mmmm, not that I know of, no |
| 15:22 | <darobin> | that would be... problematic, unless I'm missing something |
| 15:22 | <manu-db> | darobin: I'll tell them to stop doing that, then. |
| 15:22 | <manu-db> | the current algorithm will move that <span> block into body, right? |
| 15:23 | <darobin> | yeah |
| 15:23 | <darobin> | unless there's something I'm not thinking of, <head> is really restricted |
| 15:39 | <tantek> | manu-db - you care about emails that are "Best Views In Gmail" ? |
| 15:39 | <tantek> | "Best Viewed In Gmail" |
| 15:39 | <tantek> | clearly we need buttons for that to embed in email signatures |
| 15:42 | <manu-db> | tantek: I don't quite understand your question. I care that Google is asking developers to create invalid markup. There's nothing that specifically limits that usage to Gmail. It could work with any e-mail client that supports HTML content (which is most of them). |
| 15:43 | <manu-db> | tantek: They also claimed that their partners didn't like Microdata, which is why they adopted JSON-LD as the primary way of marking up that data. |
| 15:44 | <tantek> | Google is suggesting invalid markup in email? Tell me again about how often HTML email validates. |
| 15:46 | <manu-db> | tantek: Well in this particular case, the markup could be moved around by the HTML processing algorithm in such a way that the Microdata expresses something completely broken (like if they did <title itemtype="..."> ... <span itemprop="reservation" itemtype="..."></span></title> |
| 15:47 | <manu-db> | (meaning, what the developer thinks the markup means is going to be interpreted by a Microdata processor in the wrong way) |
| 15:48 | <manu-db> | tantek: Guidance to developers should really be - "just put it in the body" |
| 15:48 | <manu-db> | tantek: but they probably didnt' want to do that because they wanted the JSON-LD and Microdata to look the same. |
| 17:10 | GPHemsley | wonders why Ms2ger thinks the Mozilla HTML5 bug doesn't serve a purpose |
| 17:13 | <Ms2ger> | Do you have any? |
| 17:13 | <GPHemsley> | that's a personal question |
| 17:13 | <GPHemsley> | ;) |
| 17:14 | <GPHemsley> | but yeah, isn't it used as a tracking bug for all the other bugs? it's a good way (in theory) to keep track of all the HTML spec-related bugs in one place |
| 17:15 | <GPHemsley> | particularly because it's one of the blockers for the living standards bug |
| 17:15 | <GPHemsley> | s/particularly because it's/it's also/ |
| 17:15 | <Ms2ger> | There's way too many such bugs to have them all tracked that way |
| 17:17 | <GPHemsley> | well, this tends to be a meta bug to track meta bugs, IIUC |
| 18:05 | <GPHemsley> | (annevk:) (In reference to bz's WebAppSec post which I didn't get CC'd on) <object> is a hybrid element that could be any one of image, audio/video, or plugin contexts, and the spec says that. |
| 18:06 | <GPHemsley> | I don't think it's a nested browsing context, but I could be wrong |
| 18:06 | <GPHemsley> | (I'm not on the WebAppSec mailing list) |
| 18:08 | <GPHemsley> | oh, apparently <object> is actually an image, a nested browsing, or a plugin context |
| 18:08 | <GPHemsley> | spec doesn't mention audio/video |
| 18:09 | <GPHemsley> | but it seems the <object> definition could use some updating to tie in better with mimesniff (though admittedly mimesniff is not in the best state to be tied in with yet) |
| 18:10 | GPHemsley | needs to get things out of his head and into the spec |
| 20:04 | <Hixie_> | anyone understand https://www.w3.org/Bugs/Public/show_bug.cgi?id=21870 ? |
| 20:04 | <Ms2ger> | Sure |
| 20:05 | <Ms2ger> | Look at the "Content attributes:" part of the green box |
| 20:05 | <Hixie_> | yeah? |
| 20:05 | <Hixie_> | what about it? |
| 20:05 | <Ms2ger> | Last line only has the name, no description |
| 20:06 | <Hixie_> | under <menu> ? |
| 20:07 | <Ms2ger> | No, button |
| 20:07 | <Hixie_> | oohhhhhhh |
| 20:07 | <Hixie_> | thanks |
| 20:07 | <Ms2ger> | Np |
| 20:07 | <Ms2ger> | You should really start looking at the links ;) |
| 20:08 | <Hixie_> | i do...... i swear |
| 20:08 | <Hixie_> | sometimes |
| 20:12 | <jgraham> | Just upgraded critic on critic.hoppipolla.co.uk |
| 20:12 | <jgraham> | It is possible that breakage has occured; please report any issues |
| 20:30 | <Hixie_> | mounir: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=11937#c14 |
| 21:31 | <GPHemsley> | Hixie_: For future reference, what's the quickest way to get your attention on something? (Choices include IRC, e-mail, bug, skywriting, etc.) |
| 21:32 | <Hixie_> | IRC if i'm around |
| 21:32 | <Hixie_> | e-mail direct to ian⊙hc (not cc'ed to a mailing list) if i'm not |
| 21:33 | <Hixie_> | if you need to catch me when i'm not working, g+ is a good way to get me too |
| 21:33 | <GPHemsley> | heh... when are you not working? |
| 21:33 | <Hixie_> | like last month :-) |
| 21:33 | <GPHemsley> | ah, ok |
| 21:34 | <GPHemsley> | and I can judge whether you're around on IRC by whether you're "away"? |
| 21:34 | <Hixie_> | no |
| 21:34 | <Hixie_> | i'm always /away :-( |
| 21:34 | <GPHemsley> | oh |
| 21:34 | <Hixie_> | i use it to track what people are saying in other channels |
| 21:34 | <GPHemsley> | how does that work? |
| 21:35 | <Hixie_> | i have a bunch of things that cause irssi to add stuff to the away log |
| 21:35 | <Hixie_> | like if anyone says "hixie" |
| 21:35 | <Hixie_> | and then every now and then i look at hte away log |
| 21:35 | <Hixie_> | but i can't do that if i'm not /away as far as i can tell |
| 21:36 | <GPHemsley> | I see... that seems rather hackish |
| 21:36 | GPHemsley | uses X-Chat |
| 21:36 | <Hixie_> | very hackish |
| 21:36 | <GPHemsley> | but anyway, since you're here now |
| 21:36 | <Hixie_> | anyway, you can tell if i'm on irc by pinging me and seeing if i respond |
| 21:36 | <GPHemsley> | what were your reservations about defining "resource" again? |
| 21:37 | <Hixie_> | dunno how to do it well |
| 21:37 | <GPHemsley> | what were the consequences of doing it poorly, again? |
| 21:40 | <Hixie_> | depends on how it's used |
| 21:41 | <Hixie_> | if you say "a resource is an apple" and somewhere else you say "browsers much support downloading resources" then you've just required that browsers support downloading physical objects |
| 21:46 | <GPHemsley> | Hixie_: and if I stick to the digital realm with something like "a resource is a container of data, often represented as a byte sequence, that may have one or more items of metadata associated with it"? |
| 21:47 | <Hixie_> | so a bucket with dictionaries in it is a resource? :-) |
| 21:49 | <GPHemsley> | "...a digital container of data..."? |
| 21:50 | <Hixie_> | so when i hold an apple in my hand? :-P |
| 21:50 | GPHemsley | slaps Hixie_ with a circa 2003 trout |
| 21:50 | <Hixie_> | :-P |
| 21:51 | <GPHemsley> | I will force user agents to download your hand if you don't watch out |
| 21:52 | <GPHemsley> | in other news, do you have any opinion on codifying these other contexts? http://wiki.whatwg.org/wiki/Contexts |
| 21:53 | <GPHemsley> | I want to make sniffing talk only about contexts |
| 21:53 | <GPHemsley> | and have each context have its own sniffing algorithm |
| 21:53 | <GPHemsley> | and then not have any "generic" or "general" or "default" sniffing algorithms |
| 21:56 | <GPHemsley> | Hixie_: ^^ |
| 21:56 | <Hixie_> | i'm reading, i'm reading :-P |
| 21:56 | <Hixie_> | patience boy :-P |
| 21:56 | <GPHemsley> | ah, I always worry about you disappearing :P |
| 21:57 | <Hixie_> | a fair concern |
| 21:57 | <Hixie_> | i think the Contexts thing is fine assuming it doesn't affect the interface to other specs |
| 21:58 | <GPHemsley> | I think it may help them too |
| 21:58 | <GPHemsley> | but my first question is really, do you want to put them in HTML, or should I put them in mimesniff? |
| 21:59 | <GPHemsley> | annevk et al. might be able to tell you more about how it relates to CSP and Fetch and other things |
| 22:00 | <GPHemsley> | see e.g. http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0027.html |
| 22:02 | <GPHemsley> | basically, the idea is that you can't fetch something from an HTML page without having a context to fetch it through |
| 22:02 | <GPHemsley> | (I'm picturing "context" as a tunnel or a tube or a lens) |
| 22:03 | <GPHemsley> | same with CSS |
| 22:09 | <Hixie_> | GPHemsley: mimesniffm i think |
| 22:09 | <Hixie_> | or fetch |
| 22:12 | <GPHemsley> | yeah, maybe fetch |
| 22:12 | <GPHemsley> | but I think HTML should at least mention them |
| 22:13 | <GPHemsley> | because they tend to be associated with particular elements |
| 22:13 | <GPHemsley> | I plan to make a list of them, if no one beats me to it |
| 22:13 | <Hixie_> | i'd rather not do anything that is purely editorial in the near future |
| 22:13 | <Hixie_> | trying to deal with feedback of a more serious nature first |
| 22:13 | <Hixie_> | since i'm getting behind on it |
| 22:14 | <Hixie_> | "the perfect is the enemy of the good", and all |
| 22:26 | <GPHemsley> | oh, I wasn't viewing it as purely editorial, but ok |
| 22:28 | <Hixie_> | oh |
| 22:28 | <Hixie_> | what's the normative effect? |
| 22:36 | <GPHemsley> | it's a hook, essentially |
| 22:36 | <GPHemsley> | for other specs to latch on to |
| 22:36 | <GPHemsley> | and to make clear how to treat fetches |
| 22:36 | <GPHemsley> | (you can only fetch within a context) |
| 22:38 | <Hixie_> | i don't really see what this gains us over what we have now |
| 22:52 | <GPHemsley> | clarity and explicitness? |
| 22:53 | <Hixie_> | right, that's editorial :-) |
| 22:53 | <Hixie_> | i'm not denying that editorial improvements have value |
| 22:53 | <Hixie_> | just that right now, for me, they're not a priority |
| 22:53 | <GPHemsley> | alright |
| 22:53 | <Hixie_> | because they're always lower priority than actual normative issues, and right now i'm unable to keep up with normative issues |
| 22:53 | <GPHemsley> | but I'll proceed as if somebody plans to add them somewhere at some point |
| 22:53 | <Hixie_> | with reasonable lag |
| 22:54 | <Hixie_> | if you need more important stuff to work on, we have plenty of stuff that will have more impact :-) |
| 22:54 | <GPHemsley> | I think this is important within the realm of mimesniff |
| 22:54 | <GPHemsley> | though it's debatable where mimesniff itself falls on the importance scale |
| 22:55 | <GPHemsley> | I think the organization of mimesniff is dreadful right now |
| 22:56 | <GPHemsley> | so adding this context stuff will make it less dreadful |
| 22:56 | <GPHemsley> | but if you have other ideas, I'm all ears |
| 22:57 | <GPHemsley> | (like I said, I plan to have a separate sniffing algorithm for each context in that list) |
| 22:58 | <GPHemsley> | (the style context needs one the most, I think, of those that don't already have one) |
| 22:59 | <GPHemsley> | though I do agree that not many people seem to care about mimesniff |
| 23:01 | <Hixie_> | GPHemsley: i think mimesniff is closer to done than you do :-) |
| 23:01 | <GPHemsley> | perhaps |
| 23:01 | <Hixie_> | GPHemsley: put it this way, if you had to edit mimesniff and the entire html spec, how much would you care now? :-) |
| 23:01 | <GPHemsley> | oh, yeah, no, I get it :) |
| 23:02 | <GPHemsley> | but if you have other things for me to do, let me know |
| 23:02 | <GPHemsley> | I'm pondering the GIF thing |
| 23:02 | <GPHemsley> | but that's probably mostly done, too |
| 23:03 | <GPHemsley> | (I have to admit, though, that I feel like I've only just gotten a handle on mimesniff in the last few weeks) |
| 23:03 | <GPHemsley> | (mentally, that is) |
| 23:04 | <Hixie_> | there's a big list of things that need doing, see the wiki :-) |
| 23:04 | <Hixie_> | i can help out more with that tomorrow morning if you want |
| 23:04 | <Hixie_> | right now i gotta go soon |
| 23:04 | <GPHemsley> | alright |
| 23:04 | <GPHemsley> | though I think the specs todo page could use an audit itself |
| 23:05 | <GPHemsley> | (and I'm not sure how many of the things on that list I'm actually capable of tackling) |