| 07:48 | <annevk> | WHATWG has more followers than commits again |
| 07:54 | <annevk> | Hixie_: fwiw, it's fine to call something delete() |
| 08:03 | <zcorpan> | are css variables scoped to the stylesheet they're declared in? |
| 09:05 | <annevk> | zcorpan: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23234 on the XMLHttpRequest issue you found btw |
| 09:05 | <zcorpan> | annevk: ok. didn't know whether it was intentional |
| 09:05 | <annevk> | zcorpan: hah, entire spec doesn't include the word "scope" |
| 09:06 | <annevk> | zcorpan: it seems I expect HTML to take care of that, but parsing algorithm there doesn't actually return a Document or take a Document to modify |
| 09:06 | <annevk> | zcorpan: which might be a bug in HTML... |
| 09:06 | <zcorpan> | fantasai said they're scoped to all stylesheets that apply to a particular document, but are also scoped to elements, due to being defined as acting like normal properties that cascade and inherit |
| 09:08 | <MikeSmith> | from reading the parsing algorithm, I find that the HTML parser never does any special conversion of U+000C, right? |
| 09:09 | <MikeSmith> | I mean as far as normalizing it into a newline or whatever |
| 09:09 | <zcorpan> | MikeSmith: i think that's right |
| 09:10 | <MikeSmith> | zcorpan: OK, thanks |
| 09:10 | <zcorpan> | the preprocessor doesn't do anything with it, the tokenizer lets it through |
| 09:10 | <MikeSmith> | OK |
| 09:11 | <MikeSmith> | I notice in contrast that the CSS Syntax spec requires CSS parsers to change it to newline |
| 09:11 | <zcorpan> | and http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inbody inserts it |
| 09:12 | <zcorpan> | yeah |
| 09:12 | MikeSmith | reads |
| 09:16 | <zcorpan> | MikeSmith: so in CSS a newline isn't exposed in any way, so whether the preprocessor converts it or the the tokenizer handles it is purely an impl choice, and the spec picks one of them |
| 09:17 | <MikeSmith> | ah, OK |
| 09:17 | <MikeSmith> | makes sense |
| 09:22 | <annevk> | "I visited the top 10 websites according to https://en.wikipedia.org/wiki/List_of_most_popular_websites. For each page, if I could locate a searchbox, I typed "cats". I'm more of a dog person but we're trying to simulate a typical internet user." |
| 09:22 | <annevk> | <3 |
| 09:27 | <MikeSmith> | heh |
| 09:30 | <hober> | heh |
| 09:36 | <zcorpan> | annevk: where's that quote from? |
| 09:36 | <annevk> | zcorpan: blink-dev |
| 09:41 | darobin_ | wonders if searching for dogs breaks the web |
| 09:42 | <annevk> | zcorpan: how do setProperty et al interact with shorthands? |
| 09:44 | <annevk> | Hixie_: I read my bug email, not planning on reopening for now as I don't have the info |
| 09:44 | <MikeSmith> | zcorpan: r? https://critic.hoppipolla.co.uk/r/309 https://github.com/w3c/web-platform-tests/pull/328 |
| 09:45 | <annevk> | Btw, I wrote up http://wiki.whatwg.org/wiki/Zip#URLs yesterday. I would appreciate some feedback as to what other topics are worthy of consideration given these alternatives. |
| 09:51 | <MikeSmith> | jgraham: if I push the "Prepare Rebase" button at https://critic.hoppipolla.co.uk/r/308 does it do a squash first? |
| 09:54 | <MikeSmith> | hmm from reading https://critic.hoppipolla.co.uk/tutorial?item=rebase I guess not |
| 09:55 | <zcorpan> | annevk: setProperty with a shorthand runs setProperty for each longhand with the appropriate value for each |
| 09:57 | <annevk> | zcorpan: internal algorithm or actually invokes? |
| 09:59 | <zcorpan> | annevk: internal algorithm. "When a method or an attribute is said to call another method or attribute, the user agent must invoke its internal API for that attribute or method so that e.g. the author can't change the behavior by overriding attributes or methods with custom properties or functions in ECMAScript." |
| 09:59 | <zcorpan> | annevk: i'll change the spec to separate the algorithms so this is clearer |
| 10:00 | <zcorpan> | filed a bug |
| 11:16 | <annevk> | krit: I can explain more here if you want, but it sounds like you got the model backwards |
| 11:31 | <krit> | annevk: sure, yes please do! |
| 11:32 | <annevk> | krit: well, I guess I'd have to know what was unclear in my last email |
| 11:32 | <krit> | annevk: well, first when do you do fetching? From your last mail, it is just when you have external resources? |
| 11:33 | <zcorpan> | does anyone have a pointer to the spec that defines Navigation Controller, if it exists (publicly)? |
| 11:34 | <hober> | zcorpan: there isn't one |
| 11:34 | <zcorpan> | ok, thanks |
| 11:34 | <hober> | zcorpan: at least, not at w3c or whatwg |
| 11:34 | <annevk> | krit: fetching happens when the spec says to do fetching |
| 11:34 | <annevk> | krit: e.g. for <img> it happens when the element is inserted into the document |
| 11:35 | <krit> | annevk: ok, sure. Fetch itself is passive and needs to be triggered |
| 11:36 | <annevk> | krit: it's not really clear to me how the fragment stuff works in SVG, I'd have thought you'd know |
| 11:36 | <annevk> | zcorpan: https://github.com/slightlyoff/EventWorker/ |
| 11:36 | <krit> | annevk: lets keep it at images first |
| 11:36 | <krit> | annevk: You fetch an SVG. Fetching is invoked by <img> tag |
| 11:37 | <krit> | annevk: this SVG has "references" to other images |
| 11:37 | <annevk> | krit: that's kinda backwards thinking already |
| 11:37 | <annevk> | krit: you fetch something, turns out it's SVG |
| 11:37 | <annevk> | krit: is how it works |
| 11:37 | <zcorpan> | annevk: thx |
| 11:37 | <krit> | annevk: k |
| 11:38 | <annevk> | krit: you get SVG back so then the browser starts processing the SVG |
| 11:38 | <krit> | annevk: So this SVG would be marked as SVG image (for instance by flagging). Not by Fetch, but byt the algorithm of <img> |
| 11:38 | <krit> | annevk: and this would happen after recognizing it is an image |
| 11:38 | <annevk> | krit: yeah, I think that would be the way to do it |
| 11:39 | <krit> | annevk: k. So this SVG document has a flag now that it should not load further images |
| 11:39 | <annevk> | krit: you get a resource back, check if the MIME type is "image/svg+xml", then if it is you pass it to the SVG subsystem with an "image mode" flag which hands you back pixels |
| 11:40 | <krit> | annevk: yes. Getting into what SVG image does internally now |
| 11:40 | <krit> | annevk: Internally it is still an Document, which just happens to return pixels |
| 11:40 | <krit> | annevk: and this document is marked as "image mode" |
| 11:40 | <annevk> | krit: so the SVG processing model needs to account for this "image mode" flag, e.g. it does not execute script, does not iterate its event loop, does not fetch resources |
| 11:41 | <krit> | annevk: I agree |
| 11:41 | <krit> | annevk: now we have an SVG <image> element inside this "image" makred SVG document |
| 11:41 | <krit> | annevk: <image> now needs to check this flag |
| 11:42 | <krit> | annevk: it is "image" mode, so we have a restriction on fetching |
| 11:42 | <krit> | annevk: now the URL needs to be parsed |
| 11:42 | <krit> | annevk: and it happens to be an http URL |
| 11:42 | <krit> | annevk: in this case SVG needs to specify that we get a network error, right? |
| 11:43 | <annevk> | krit: yeah, I imagine SVG would define "SVG fetch" |
| 11:43 | <krit> | annevk: lets come back to SVG fetch after understanding the concept… because if you don't write the spec for it it is sadly me :D |
| 11:44 | <annevk> | which has these steps: 1. If mode is "document mode", return the result of fetch with the same arguments. 2. Magic. |
| 11:44 | <krit> | annevk: exactly step 2: magic... |
| 11:44 | <krit> | annevk: network error on htttp requests |
| 11:44 | <krit> | annevk: is that about right? |
| 11:45 | <krit> | (so far) |
| 11:45 | <annevk> | Well, I guess the interesting case is fragment identifiers when there's no <base> getting in the way. |
| 11:46 | <krit> | annevk: ah right, first we need to resolve the absolute URL, right? |
| 11:46 | <annevk> | Apart from the fragment identifer case. Step 2 would be to termine if URL's scheme is not "about" or "data". |
| 11:46 | <krit> | annevk: so if http request, create absolute URL |
| 11:46 | <annevk> | Parsing the URL happens before Fetch. |
| 11:46 | <krit> | annevk: right, ok |
| 11:47 | <krit> | annevk: so lets exclude blob for now, we just have about, data and http ? |
| 11:47 | <krit> | annevk: or better, just allow these three and reject all others. |
| 11:47 | <annevk> | krit: there's also file and ftp |
| 11:48 | <annevk> | krit: why would you allow http? |
| 11:48 | <annevk> | krit: I thought the whole point was to not have network requests? |
| 11:48 | <krit> | annevk: oh, you already do special casing during parsing? |
| 11:49 | <krit> | annevk: so you do not transform all URLs to absolute URLs? |
| 11:49 | <annevk> | krit: yes you do |
| 11:49 | <krit> | annevk: means you really check for about, data, or # |
| 11:49 | <krit> | annevk: and reject everything else |
| 11:50 | <krit> | annevk: I am not sure how useful "about" is, but I'll keep that in mind for later. Lets concentrate on the later two |
| 11:50 | <annevk> | Okay. So I need to know if the fragment case roundtrips through the network layer or not. |
| 11:51 | <krit> | annevk: # (if not resolved to absolute URL which would make sense in this case) should not go through the network layer |
| 11:51 | <krit> | annevk: at least it doesn't in implementations |
| 11:51 | <annevk> | I suspect this would be a better setup: 1. Parse /input/ against /base/ into /url/. 2. If /url/ has same-document fragments, deal. 3. Otherwise, SVG fetch /url/ |
| 11:51 | <krit> | annevk: clarification, it doesn't for WebKit and Blink |
| 11:52 | <annevk> | I'm surprised SVG gets away with not defining critical infrastructure like this. |
| 11:52 | <annevk> | But I shouldn't be |
| 11:52 | <krit> | Ancil: as a general setup, ok makes sense |
| 11:52 | <annevk> | Back in an hour or so, lunch! |
| 11:52 | <krit> | annevk: no you shouldn't be. I think we rely that IRI specifies it for us |
| 11:52 | <krit> | annevk: k |
| 11:52 | <annevk> | No it doesn't |
| 11:52 | <krit> | :) |
| 12:24 | darobin | wonders if simply mentioning widgets counts as trolling |
| 12:33 | <TabAtkins> | zcorpan: No, css custom properties are properties. They scope exactly the same way that any other property does. |
| 12:34 | <TabAtkins> | (That is, not at all.) |
| 12:34 | <TabAtkins> | (scoped stylesheets dont' scope properties, they scope selectors) |
| 12:39 | <annevk> | krit: FWIW, IRI (which is obsolete these days) defines no more than URL, i.e. parsing of a string |
| 12:42 | <krit> | annevk: I checked, So we define that certain attributes take an IRI (RFC3987) or an FuncIRI (special case of IRI) for many element xlink:href is referenced |
| 12:43 | <krit> | annevk: couldn't find another reference yet |
| 12:43 | <annevk> | krit: yeah, that's about the level of detail I would expect, which is to say nothing at all |
| 12:46 | <krit> | annevk: to come back to your parsing, you have 1. Parse /input/ against /base/ into /url/ |
| 12:46 | <krit> | annevk: is that something that can be referenced? |
| 12:46 | <krit> | annevk: is it in url.spec.whatwg.org? |
| 12:48 | <annevk> | krit: http://url.spec.whatwg.org/#concept-url-parser |
| 12:50 | <krit> | annevk: k, SVG fetch: /data/ |
| 12:51 | <annevk> | krit: you fetch a URL, it returns data |
| 12:54 | <krit> | annevk: ok, and from here it can be recursive…. if the data is an SVG interpreted as image, I set the "image" mode. This again just allows the current algorihtm on parsing and possibly fetching |
| 12:56 | <krit> | annevk: Now the case we do not have a dataURL and not a fragment in the same document |
| 12:56 | <krit> | annevk: in this case we do not fetch |
| 12:56 | <annevk> | krit: are you talking about <svg:image> referencing a data URL or some such? |
| 12:56 | <krit> | annevk: yes |
| 12:57 | <annevk> | krit: it's not really recursive, for <svg:image> you need to define what to do with the returned data, and I suppose you might want to vary that based on the "image mode" |
| 12:58 | <annevk> | krit: try to think specs the same way the code works; you need the same abstractions and concepts |
| 13:00 | <krit> | annevk: I am usually working on CSS, if you are not defining the Syntax, then you possibly justw want to specify the behavior, not the implementation :P |
| 13:00 | <krit> | annevk: but I get your point |
| 13:01 | <annevk> | krit: CSS has lot of these issues actually |
| 13:01 | <annevk> | krit: maybe it's epidemic |
| 13:01 | <krit> | annevk: hehe, possibly :) |
| 13:02 | <annevk> | (Though TabAtkins seems to fix it up, bit by bit.) |
| 13:02 | <krit> | annevk: thank you very much for your help so far. I'll work on the draft next week and will definitely poke you a lot then ;) |
| 13:02 | <krit> | annevk: yeah, Tab is fixing the web :) |
| 13:03 | <annevk> | krit: no worries, I'll be in Boston next week for TC39, so times will be a bit different |
| 13:03 | <krit> | annevk: I am back in europe. So no improvement :) |
| 13:04 | <annevk> | krit: you stay in France for a bit after the CSS WG? I thought you were based in SF for some reason... |
| 13:04 | <krit> | annevk: not based in SF anymore. Working from Germany now |
| 13:05 | <krit> | annevk: still working for the same team, just remotely :) |
| 13:05 | <annevk> | Ah I see, nice |
| 14:10 | <annevk> | So, did anyone take a look at this yet: |
| 14:10 | <annevk> | http://wiki.whatwg.org/wiki/Zip#URLs |
| 14:11 | <annevk> | I think zip-path is a clear winner. Incidentally I also once again had to became wiki-syntax master :/ |
| 14:13 | <TabAtkins> | annevk: Have any guidance over what kinds of switches we would need to expose in a CSS "fetch(<url-string> <stuff-goes-here>)" function? |
| 14:14 | <annevk> | TabAtkins: I think that depends on how you solve that SVG thing I discussed a while back with roc and I think krit too |
| 14:15 | <TabAtkins> | Okay, so I'll need to read that. Too many interesting discussion that happen while I'm minuting. :/ |
| 14:15 | <annevk> | TabAtkins: http://lists.w3.org/Archives/Public/public-fx/2013AprJun/thread.html#msg17 |
| 14:18 | <annevk> | TabAtkins: I think you want a way to opt into CORS, a way to opt out of credentials, and maybe a way to opt into CORS and credentials, not sure about this one (by default if someone opts into CORS you want him to opt out of credentials) |
| 14:19 | <annevk> | TabAtkins: but that above discussion is relevant, @font-face already opts into CORS so doesn't need this (other than maybe opting out of same-origin credentials) |
| 14:26 | <krit> | annevk: Wouldn't it be enough to have the same values as the crossorigin attribute on <img>? Or should it be more detailed? |
| 14:27 | <annevk> | krit: yeah, kinda depends on the use cases you have |
| 14:27 | <krit> | annevk: probably |
| 14:27 | <annevk> | krit: people have been asking about ways to opt out of credentials also for normal requests though |
| 14:28 | <annevk> | krit: it seems there's a few constructs in CSS where it would've been good to always do CORS, but e.g. for background-image I don't really know what the benefit would be |
| 14:28 | <annevk> | krit: well, maybe once we have that drawElement() API, then background-image would taint stuff cross-origin I suppose |
| 14:34 | <espadrine> | is there a test suite for css3-values? |
| 14:34 | <krit> | annevk: with drawElement() you mean element() ? |
| 14:35 | <annevk> | krit: no I meant for <canvas> |
| 14:36 | <annevk> | krit: don't think element() is a problem as it doesn't allow for reading |
| 14:36 | <krit> | annevk: oh, you want to draw an abritary element to a canvas? |
| 14:36 | <krit> | annevk: then you would need to taint the canvas |
| 14:36 | <annevk> | krit: I don't really, but there've been requests, Gecko supports drawing a document's canvas on a <canvas> etc. |
| 14:36 | <krit> | annevk: but I suppose that is why you want CORS |
| 14:37 | <krit> | what do you mean with document's canvas on a <canvas> ? |
| 14:37 | <krit> | annevk: oh, you mean the whole surface |
| 14:37 | <krit> | annevk: Gecko supports that? |
| 14:38 | <annevk> | krit: for extensions only |
| 14:38 | <krit> | annevk: ok |
| 14:39 | <krit> | annevk: Blink supports drawing ot SVG onto a canvas without tainting |
| 14:39 | <annevk> | krit: but yeah, otherwise I'm not sure what the point is to have fetch() for background-image, it seems that thread I referenced from public-fx has the only use case for it thus far |
| 14:39 | <annevk> | krit: yeah, that mostly requires SVG to define when it's clean and such |
| 14:39 | <krit> | annevk: yeah, I think so. |
| 14:40 | <annevk> | (plus the places that do "fetch()" implicitly already, such as @font-face) |
| 14:40 | <krit> | annevk: right, this is one reason I asked you all these questions. It must be defined for SVG now |
| 14:40 | <krit> | annevk: right |
| 14:40 | <annevk> | Yeah, drawImage(SVGElement) would be nice |
| 14:40 | <annevk> | Well, SVGSvgElement I suppose |
| 14:41 | <krit> | annevk: at the moment it is a whole SVG document that you need to load with ImageElement |
| 14:41 | <krit> | annevk: but there have been discussion about SVG subtrees |
| 14:42 | <krit> | annevk: but it was easier to estimate security concerns for the former |
| 14:42 | <krit> | s/concerns/requirements. |
| 14:42 | <darobin> | actually, drawImage(SVGElement) would be nice |
| 14:43 | <darobin> | either infer the context from its parent <svg>, or maybe use the canvas to set up a viewport |
| 14:43 | <krit> | dbaron: right. But IIRC we still had some issues we need to work on. But am not sure anymore. |
| 14:44 | <krit> | darobin: —^ :) |
| 14:44 | <darobin> | yeah I figured :) |
| 14:59 | <annevk> | krit: well yeah, the former is "image mode" which is already locked down |
| 15:01 | hober | checks "meet ms2ger irl" off of the todo list |
| 15:01 | <krit> | annevk: was still a chalange :) |
| 15:02 | <wilhelm_> | hober: Any resemblance? http://en.wikipedia.org/wiki/Krang |
| 15:03 | <krit> | annevk: the problem is maybe that there is a spec missing explaining how to do it. So you end up in traps that are easier to find if you already have some text |
| 15:05 | <annevk> | yeah, SVG/CSS is pretty poor processing model wise :/ |
| 15:05 | <hober> | wilhelm_: wow, that's eerily close :) |
| 15:26 | <TabAtkins> | I can at least cross "saw ms2ger from a distance" off the list. |
| 15:26 | <darobin> | TabAtkins: in Paris? |
| 15:26 | <TabAtkins> | darobin: ...somewhere. |
| 15:27 | <darobin> | TabAtkins: c'mon |
| 15:34 | <annevk> | Seems Hallvord dropped some initials since he joined us. |
| 15:48 | <bkardell__> | Hixie_: https://gist.github.com/bkardell/6552215 |
| 15:48 | <bkardell__> | says listing in network and cache sections prevents cache... |
| 15:49 | <bkardell__> | is that at odds with what I (think) you said yesterday? |
| 15:51 | <bkardell__> | sent something to the dev tools team for clarification, but... it's confusing |
| 15:58 | <dglazkov> | good morning, Whatwg! |
| 15:59 | <bkardell__> | Hixie_: nm, seems to actually *do* as you described despite validator - still not my problem yet :-\ |
| 16:01 | <TabAtkins> | Good evening, dglazkov! |
| 17:21 | <annevk> | Hixie_: I emailed es-discuss long about the global this / global object mismatch, I filed https://bugs.ecmascript.org/show_bug.cgi?id=1898 now so it's actually tracked |
| 17:21 | <annevk> | Hixie_: fwiw, it'll be fixed, just unclear what timeframe... |
| 17:22 | <matjas> | abusing WebRTC to read local IPs: https://dl.dropboxusercontent.com/u/1878671/enumhosts.html TIL HTML5 has a built-in `nmap` |
| 17:23 | <Hixie_> | annevk: oh, excellent, thanks |
| 17:23 | <annevk> | matjas: :/ |
| 17:24 | <Hixie_> | you can do an intranet scan using <img> and <meta refresh>, that's not new |
| 17:24 | <Hixie_> | getting the local IP is new, but that's something that's pretty much a prereq of doing NAT traversal, as i understand it |
| 17:45 | <rillian> | Hixie_: I wonder if you could measure the response time accurately enough to distinguish the local ip in an <img> portscan |
| 18:17 | <Hixie_> | rillian: the problem is more that you don't know where to start |
| 18:22 | <reyre> | i've been working on implementing the processing model of WebVTT and it seems to me like the positioning for alignments is reversed, has anyone else encountered this as well? |
| 18:22 | <reyre> | i need a sanity check |
| 18:27 | <Hixie_> | there's a bug open on it |
| 18:27 | <Hixie_> | i think nessy has a plan for it |
| 18:27 | <Hixie_> | check the VTT bugs |
| 18:27 | <rillian> | reyre: the wiki points to https://dvcs.w3.org/hg/text-tracks/ for the webvtt spec |
| 18:27 | <reyre> | Hixie_: okay thanks |
| 18:27 | <rillian> | last change Aug 12 |
| 18:28 | reyre | bookmarking it |
| 18:28 | <reyre> | thanks rillian |
| 18:28 | <rillian> | oh, there's a link at the top of http://dev.w3.org/html5/webvtt/ |
| 18:28 | <rillian> | duh |
| 18:28 | <rillian> | just truncate the url to get the hg repo |
| 18:29 | <Hixie_> | oh no, there's not multiple copies of this now are there? sigh |
| 18:31 | <rillian> | Hixie_: yeah :/ |
| 18:32 | <rillian> | not a living document |
| 18:34 | <rillian> | reyre: the repo has no useful history on the overscan line |
| 18:34 | <rillian> | maybe look in the whatwg repo |
| 18:34 | <reyre> | rillian: okay sounds good |
| 18:36 | <rillian> | matjas: local people no involved with webrtc were appropriately appalled by your link |
| 19:15 | <zewt> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23240: "browsers do lots of bizarre things here, so let's just spec the nice simple thing" |
| 19:30 | <annevk> | UI events :/ |
| 19:30 | <annevk> | I wish someone would just step up and fix them |
| 19:35 | <zewt> | dear google: i searched for OOM, not "zoom", thanks anyway |
| 20:26 | <Hixie_> | annevk: i thought the dom3 events guys were doing that, aren't they? |
| 20:27 | <annevk> | Hixie_: I don't see anything in terms of hit testing, defining the model, defining things in terms of tasks, etc. |
| 20:28 | <annevk> | Hixie_: it's mostly still the old Events spec afaict, nothing "new-style" |
| 20:30 | <Hixie_> | yeah, i think GPHemsley filed bugs about this |
| 23:17 | <Hixie_> | is there a way to make an element with a semi-transparent background blur the stuff it overlaps? |
| 23:17 | <Hixie_> | aero-style? or mac menu style? |
| 23:18 | <zewt> | you can do that with css filters, i think |
| 23:19 | <zewt> | iirc it's catastrophically slow in some implementations (not all are hardware-accelerated) |
| 23:24 | <Hixie_> | doesn't 'filter' apply to the element itself, rather than its background? |
| 23:26 | <Hixie_> | or i should say, rather than what is behind it |
| 23:26 | <Hixie_> | not its background in a CSS sense |
| 23:29 | <Hixie_> | cabanier: ping |
| 23:34 | <zewt> | hmm true |
| 23:36 | <rillian> | Hixie_: you'd have to hack it I think. css filters blur before compositing |
| 23:36 | <zewt> | wonder how that could be done in general ... first thought is a way to create an element whose contents is whatever's composited underneath it, but alpha would break that |
| 23:36 | <rillian> | http://jsfiddle.net/3asZC/539/ |
| 23:37 | <Hixie_> | doesn't seem to affect the backdrop... |
| 23:37 | <zewt> | unless it's just a flat, completely precomposited copy of whatever's under it (thus with no transparency) |
| 23:39 | <zewt> | personally there are few things in UIs i hate more than blurring (hurts my eyes), so I'm okay with it being hard to do :) |
| 23:41 | <Hixie_> | mac menus use it to good effect |
| 23:41 | <zewt> | i don't remember it (and don't see it on my mbp), maybe I turned it off somewhere |
| 23:42 | <Hixie_> | look through a context menu |
| 23:42 | <Hixie_> | or a top-level menu from the menu bar |
| 23:43 | <Hixie_> | it's extremely subtle |
| 23:43 | <Hixie_> | bbl |
| 23:43 | <zewt> | nope |