| 01:57 | <TabAtkins> | Achievement unlocked: wrote a CSS spec pre-preprocessor, so I can preprocess before I preprocess. |
| 02:02 | <zewt> | keep this up and i'm going to :set expandtabs and you'll cease to exist |
| 02:02 | <TabAtkins> | Or I'll just get fatter. |
| 02:02 | <nimbu> | ahahaha |
| 04:23 | <SimonSapin> | TabAtkins: it’s pre-processors all the way down! |
| 05:16 | <SimonSapin> | TabAtkins: http://dev.w3.org/csswg/css-variables/ is apparently not "pre-processed" |
| 09:33 | <cousteau> | what's the support for the <a rel=noreferrer> attribute? (is it standard? when was it introduced? what browsers and versions support it?) |
| 10:09 | <MikeSmith> | cousteau: it's standard. It was introduced at least 5 years ago. I think only WebKit supports it |
| 10:10 | <cousteau> | "5 years ago" means HTML 4.01 or so? |
| 10:10 | <cousteau> | or was it already HTML 5? |
| 10:12 | <MikeSmith> | cousteau: it was added to the current HTML spec back when it was still just called Web Applications 1.0 |
| 10:12 | <MikeSmith> | and so it's a new feature in HTML5 |
| 10:13 | <MikeSmith> | it wasn't in HTML4 |
| 10:15 | <MikeSmith> | http://html5.org/tools/web-apps-tracker?from=1118&to=1119 |
| 10:19 | <gsnedders> | cousteau: HTML4 was 15 years ago :P |
| 10:19 | <cousteau> | gsnedders, no HTML4, HTML4.01! |
| 10:19 | <cousteau> | which would be... let me calculate it |
| 10:19 | <cousteau> | interpolating, I calculate HTML4.01 was 14.85 years ago |
| 10:20 | <cousteau> | (that's not how version numbers work, right?) |
| 10:21 | <Raymondo> | http://blog.whatwg.org/html-is-the-new-html5 |
| 10:21 | <cousteau> | is there a page that can tell me whether my browser supports the rel=noreferrer thing? either a list of browsers or a page with a noreferrer link that links to another page that shows me the http request |
| 10:22 | <cousteau> | a page that displays the whole http request would be enough |
| 10:27 | <Raymondo> | http://jsbin.com/etotur |
| 10:30 | <marcosc> | annevk: when referring to a path component of a URI that needs to be checked for validity, should I use path from RFC3986 or ipath from RFC3987? |
| 10:32 | <annevk> | you should use path from the URL Standard |
| 10:33 | <annevk> | although checked for validity sounds like a spurious concept |
| 10:34 | <cousteau> | hm, both show referrer |
| 10:34 | <Raymondo> | not in chrome |
| 10:34 | <MikeSmith> | cousteau: http://darklaunch.com/tools/test-referer |
| 10:35 | <cousteau> | Raymondo, that's what I was checking |
| 10:35 | <Garbee> | cousteau, I see Mozilla still has an open bug for it to be added. So it at least doesn't work there. https://bugzilla.mozilla.org/show_bug.cgi?id=530396 |
| 10:36 | <Raymondo> | that's interesting. I'm on 25/mac and noreferrer works on that jsbin test |
| 10:36 | <marcosc> | annevk: I need to check if "\u0000!£@$%!$£@!!£!£@£124!23412" is ok to use, it's what I mean by validity |
| 10:37 | <annevk> | marcosc: it'll parse, but you won't get the same in return |
| 10:37 | <marcosc> | that's ok:) Looking at the URL spec |
| 10:37 | <annevk> | also, if you have custom scheme like app:// there might not be path parsing |
| 10:38 | <annevk> | we'd have to add it to the whitelist of relative schemes |
| 10:38 | <cousteau> | Raymondo, btw, thanks for the link |
| 10:38 | <Raymondo> | no prob |
| 10:38 | <annevk> | and then make sure it doesn't invoke host parsing I suppose |
| 10:39 | <cousteau> | Garbee, damn, some Firefox bugs really take their time to get fixed |
| 10:39 | <marcosc> | annevk: in FireFox OS, there is a launch_path, which is the path that represents the first resource to load. The origin can be either http:// based or app:// based |
| 10:40 | <annevk> | origin is unrelated to URL parsing |
| 10:41 | <annevk> | URL parsing requires input and optionally a base |
| 10:57 | <marcosc> | annevk: thanks for the guidance. |
| 10:58 | <annevk> | anytime |
| 11:04 | <annevk> | "As only mutating the prototype chain" Can't wait for TC39 to find out :p |
| 11:09 | <beverloo> | annevk, any ideas about potential compatibility impact given http://crbug.com/177176? Should it be filed as a DOM4 bug for reference? |
| 11:12 | <annevk> | beverloo: well we know this can be an issue |
| 11:12 | <annevk> | beverloo: that's why they're all tentatively added to figure out if we can keep them |
| 11:12 | <beverloo> | I recall them being rolled back in WebKit previously because of a compatibility issue |
| 11:12 | <beverloo> | While this seems minor, there may be more out there. I'd be a shame |
| 11:12 | <beverloo> | but good that it's known! |
| 11:13 | <annevk> | event handlers are a big problem with introducing any new method :( |
| 11:13 | <annevk> | if they're rolled back from WebKit... that news hadn't reached me yet |
| 11:14 | <annevk> | I'll give up when arv_ / slightlyoff give up |
| 11:15 | <beverloo> | They were rolled in again as well, I think we shipped them with Chrome 23 or Chrome 24 (i.e. out on stable for at least a month or two) |
| 11:15 | <annevk> | ah okay |
| 11:57 | <marcosc> | mounir: ping me when you are around |
| 11:58 | <annevk> | he's around |
| 12:07 | <mounir> | yeah, I am |
| 12:07 | <marcosc> | mounir: hi |
| 12:08 | <marcosc> | mounir: required_features and the permissions members in the manifest... I'm a bit confused by them |
| 12:09 | <marcosc> | If an author writes the permissions in English, what is the value of them to a Chinese user? |
| 12:09 | <marcosc> | Or are permissions used somewhere else? |
| 12:09 | <mounir> | marcosc: permissions are keywords |
| 12:09 | <mounir> | not user facing strings |
| 12:10 | <mounir> | some APIs are linked to some permissions |
| 12:10 | <mounir> | the runtime spec do some links |
| 12:10 | <mounir> | like "geolocation" |
| 12:10 | <marcosc> | shouldn't web platform features just be available by default? |
| 12:10 | <marcosc> | like geo |
| 12:11 | <mounir> | marcosc: no |
| 12:11 | <mounir> | marcosc: I mean, depends what you mean |
| 12:11 | <marcosc> | mounir: if we start adding things like that, then it means that you freeze the API access to the platform and everything from the point of release becomes frozen |
| 12:12 | <marcosc> | mounir: if you add an Ice Cream API tomorrow, and it's "Web safe", how will one vendor know to make it available and another not? |
| 12:12 | <marcosc> | vendor A might think, oh, I don't know if we should allow that on the runtime, but vendor B allows it by default |
| 12:13 | <marcosc> | Developers targeting Vendor B's runtime won't do any permission checks, so when their app is run on Vendor A's runtime, the app will fail |
| 12:15 | <annevk> | marcosc: if it's web safe the question won't come up |
| 12:15 | <mounir> | marcosc: I do not know what Firefox OS is doing but how I see it is that stuff like "geolocation" could be a way for the application to say upfront they want to use a permission |
| 12:15 | <mounir> | so the implementation can have a UI that asks the user if he/she wants to give that permission at install time |
| 12:15 | <annevk> | mounir: which is a terrible model btw |
| 12:15 | <mounir> | but that's an implementation detail |
| 12:15 | <mounir> | annevk: sure... |
| 12:16 | <mounir> | but that shouldn't make the app not able to use the permission |
| 12:16 | <marcosc> | mounir: it's not really an implementation detail if it could mean apps run on some platforms and not on others |
| 12:16 | <mounir> | I don't exactly know what FxOS is doing because they kept changing that all the time and it has not really been done in the open... |
| 12:17 | <mounir> | marcosc: if we make a requirement for apps to ask for permissions upfront, there is no incompatibility there |
| 12:18 | <mounir> | we could also make some permissions required to be asked upfront depending on the application privilege |
| 12:18 | <mounir> | I think the first model is simpler but not very fault tolerant |
| 12:18 | <marcosc> | mounir: there might be, if one app supports and API and another doesn't (but the developer has built in some kind of fallback for it) |
| 12:18 | <mounir> | marcosc: that is true |
| 12:19 | <mounir> | but there is error callbacks for that |
| 12:19 | <mounir> | like currently, geolocation can be rejected all the time |
| 12:19 | <mounir> | not having the permission would work the same way |
| 12:19 | <marcosc> | Sure, right now I'm only thinking of the installation step |
| 12:19 | <marcosc> | I'm worried apps will not install across runtimes |
| 12:20 | <marcosc> | and that permissions () |
| 12:20 | <marcosc> | woops |
| 12:20 | <marcosc> | let me try that again |
| 12:20 | <marcosc> | and that permissions (read, readwrite, etc) won't map cleanly to all APIs |
| 12:21 | <marcosc> | Like, for example, that maps ok to contacts, but not too sure about Bluetooth |
| 12:21 | <marcosc> | or to NFC |
| 12:21 | <marcosc> | or even raw sockets |
| 12:21 | <mounir> | marcosc: it doesn't apply to all permissions |
| 12:23 | <marcosc> | mounir: ok, going to think about it. I'll see what some other FxOS apps are doing/declaring. |
| 12:25 | marcosc | also worries about having to capability-tests all APIs for read, rewrite, readcreate, and createonly modes. And define what is available when. |
| 12:29 | <mounir> | marcosc: all of those things should send error events on the DOMRequest if it fails |
| 12:29 | <mounir> | so, instead of capability testing, developers can handle errors |
| 12:30 | <marcosc> | mounir: sure, but I'm thinking from an implementation perspective. If I'm going to publish and API, I now need to define how the API behaves under the four different rules above. |
| 12:31 | <marcosc> | (and then the developer needs to deal with all the different restrictions). |
| 12:31 | <mounir> | marcosc: if there is no read-write aspects (like in most APIs), I guess not |
| 12:31 | marcosc | checks... |
| 12:32 | <marcosc> | so, could be contacts, calendar, media storage, network |
| 12:33 | <marcosc> | system settings |
| 12:34 | <marcosc> | mounir: as a developer, I would just set "give me access to everything" to avoid any potential pain |
| 13:15 | <Lachy> | selectors api is finally going to REC :-) |
| 13:15 | <Lachy> | should be published by tomorrow. |
| 13:16 | <jgraham> | Oh, am I allowed to use it now? |
| 13:16 | <wilhelm> | \o/ |
| 13:17 | <Lachy> | jgraham, not yet. It's best to wait till a few errata have been filed first to ensure stability. |
| 13:21 | <odinho> | :-D I was adventurous and used it today 8) |
| 13:22 | <SimonSapin> | Lachy: is it time to rename it? |
| 13:22 | jgraham | votes CSSPath |
| 13:23 | sangwhan | is waiting for someone to come up with a name that contains the prefix "poly" |
| 13:23 | <odinho> | jgraham: Since there's a CSS global object, it could even be CSS.path() |
| 13:25 | <jgraham> | odinho: That seems quite long. CSS.sel() |
| 13:26 | <jgraham> | Or CSS.me() |
| 13:26 | <jgraham> | as in "Now I will CSS.me() some elements" |
| 13:26 | <darobin> | or CSS() |
| 13:27 | <darobin> | oh, hey, how about we think of "$" as S for selector? |
| 13:27 | <darobin> | then we could have $() |
| 13:28 | <gsnedders> | SimonSapin thinks REC is time to rename something!? |
| 13:28 | <gsnedders> | Really!? |
| 13:28 | <gsnedders> | Can he not hold off till it's RECIND!? |
| 13:28 | <Krinkle> | Hi |
| 13:29 | <Krinkle> | I'm trying to figure out whether browsers are supposed to dynamically re-resolve images/links and stuff when a <base> tag is introduced or document.baseURI otherwise modified. |
| 13:29 | <Krinkle> | http://codepen.io/anon/pen/fshFd |
| 13:29 | <Krinkle> | From reading the spec I think they're supposed to |
| 13:29 | <Krinkle> | but this codepen shows that they don't |
| 13:29 | <jgraham> | Krinkle: Here be dragons |
| 13:30 | <Krinkle> | After the first callback image 2 and 3 remain broken, only after I reresolve it explicitly and set the properties do they render |
| 13:30 | <jgraham> | I'm pretty sure you aren't supposed to reresolve |
| 13:30 | <Krinkle> | even a reflow or accessing .src or .outerHTML doesn't trigger it |
| 13:30 | <Krinkle> | of course I'm not going to reresolve them in production, that's to show the expected result (browsers are supposed to) |
| 13:31 | <jgraham> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=18459 |
| 13:31 | <jgraham> | Krinkle: ^ |
| 13:31 | <Krinkle> | I don't really care much about <base>, it's an old thing as far as I'm concerned, but I'm in this thing where we capture the DOM and log it for later. But the show-later is from a different domain, so I'm thinking of inserting a <base> tag on the client side right before we capture the DOM and save it. |
| 13:31 | <Krinkle> | would be nice if the preview while that is happening is actually correct and not broken |
| 13:32 | <Krinkle> | e.g. that inserting <base> live has the same affect as inserting it, serializing to html, saving it, and parsing that. |
| 13:32 | <jgraham> | Krinkle: IIRC the spec doesn't say that the mere act of inserting or chaging <base> does anything with existing URLs |
| 13:32 | <gsnedders> | jgraham: It does. |
| 13:33 | <Krinkle> | http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#dynamic-changes-to-base-urls |
| 13:33 | <Krinkle> | ^ |
| 13:33 | <jgraham> | Oh, right |
| 13:34 | <jgraham> | So <a> is affected but <img> is not |
| 13:35 | <jgraham> | Anyway, as I was saying, after the base changes, not all things actually resolve against the new base |
| 13:35 | <jgraham> | In particular pushState |
| 13:42 | <jgraham> | Krinkle: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2108 |
| 13:42 | <jgraham> | AFAICT Gecko and WebKit follow the spec in that simple case |
| 13:47 | <karlcow> | http://homakov.blogspot.fr/2013/02/hacking-facebook-with-oauth2-and-chrome.html |
| 13:54 | <annevk> | <img> is affected too actually |
| 13:58 | <jgraham> | In what sense? |
| 13:59 | <jgraham> | src is a reflecting attribute so accessing img.src will change the value of src you get back |
| 13:59 | <jgraham> | But it doesn't actually cause any change to happen |
| 14:01 | <annevk> | sure, loading and changing the URL are different things, but in that respect the same happens to <a> and <img> |
| 14:02 | <jgraham> | Right, I guess the point of that spec section is just that UI should be updated |
| 14:02 | <karlcow> | what is happening when we set the browser to not download images, then load a page with a <base>, change dynamically the <base> and finally ask to see images. |
| 14:03 | <jgraham> | karlcow: YOu should get the image resolved against the base URL |
| 14:03 | <jgraham> | s/base/final base/ |
| 14:03 | <karlcow> | the new base url? |
| 14:03 | <jgraham> | Yes |
| 14:03 | <karlcow> | :) |
| 14:13 | <Krinkle> | And what if we're a regular user that always shows images, and then the base is dynamically changed, should the browser fetch/render the new images if the urls are different now? |
| 14:14 | <Krinkle> | Interestingly, the property accessor does immediately yield the updated value against the new base |
| 14:15 | <Krinkle> | so from that point in time onwards, the src property will return a url that does not match the rendered image |
| 14:15 | <Krinkle> | could be a completely different image, different dimensions, reflow etc. all that stuff |
| 14:15 | <Krinkle> | I wonder what'll happen when trying to capture the image data for base64 or canvas at that point |
| 14:15 | <Krinkle> | e.g. when trying to snapshot the image |
| 14:15 | <Krinkle> | the page* |
| 14:16 | <jgraham> | Krinkle: No, the browser shouldn't try to re-fetch the image after changing the base |
| 14:16 | <jgraham> | The spec is clear on this (and implementations seem to agree) |
| 14:17 | <Krinkle> | jgraham: Can you point me to that point in the spec? |
| 14:17 | <Krinkle> | "For example, the CSS :link/:visited pseudo-classes might have been affected." |
| 14:17 | <Krinkle> | So it does specifify that rendering should change to some degree, at least in the case of css styling towards visit status of links. |
| 14:18 | <Krinkle> | ah "otherwise" |
| 14:18 | <Krinkle> | there it is |
| 14:18 | <Krinkle> | "For instance, changing the base URL doesn't affect the image displayed by img elements" |
| 14:18 | <jgraham> | Yes |
| 14:18 | <jgraham> | Note that that is non-normative, but it correctly describes the lack of a normative requirement to do anything |
| 14:18 | <Krinkle> | that sounds like a case of "specify status quo browser behavior" not the other way around. What do you think? |
| 14:19 | <jgraham> | I think that way round has a great deal of merit :) I also think this is the sane behaviour in this case |
| 14:19 | <Krinkle> | Would it be a good idea to propose a change to the spec that would make it do that? |
| 14:19 | <jgraham> | I don't think so |
| 14:20 | <Krinkle> | k |
| 14:20 | <jgraham> | Refetching images when <base> changes seems like at least a minor compat risk |
| 14:20 | <jgraham> | Plus, I don't really know why you'd want to do that |
| 14:58 | hsivonen | almost faints. a table on the IANA site: https://www.iana.org/assignments/character-sets/character-sets.xml |
| 14:58 | <hsivonen> | also: IANA is not making it harder to get rid of XSLT |
| 14:58 | <hsivonen> | s/not/now/ |
| 14:59 | <zewt> | jgraham: though it looks like there might be some weirdness associated with changing the base url, setting img.src and changing base.href ... guess i'll file a bug |
| 15:00 | <annevk> | hsivonen: well that page is pretty much obsolete, I reckon we could do with the raw view |
| 15:00 | <hsivonen> | annevk: yeah. pretty sad bocu-1 and scsu made it to the registry, though |
| 15:01 | <hsivonen> | such a bad idea to use either for interchange |
| 15:01 | <annevk> | Although perceived as such, I'm no longer sure that registry is intended to serve as a guide for what you should actually implement |
| 15:01 | <annevk> | Especially given how they go about managing it |
| 15:02 | <hsivonen> | annevk: it serves as a reminder of what to blacklist for XSS :-) |
| 15:02 | <annevk> | hsivonen: why wouldn't we just emit a single U+FFFD btw and terminate? |
| 15:11 | <hsivonen> | annevk: that would work, too, conceptually, but I wasn't sure if it violated Gecko's assuptions about how decoders behave. |
| 15:12 | <annevk> | I see |
| 15:38 | <annevk> | hsivonen: FWIW, I think I'll wait a couple of days to see what the response is to the various proposals before changing the specification |
| 16:01 | <marcosc> | jgraham: you know how I was saying that treating JSON as a WebIDL dictionary might be um, interesting ... looks like Moz is basically doing that with their FxOS manifest format. They disregard the data type adherence in their JSON format, and just cast everything as if it's an WebIDL dictionary. |
| 16:04 | <marcosc> | It's neat, because you get all the error handling and type conversion goodness of WebIDL. |
| 16:04 | <marcosc> | of course, they are not explicitly using WebIDL. |
| 16:05 | <marcosc> | But the effect is the same |
| 16:05 | <jgraham> | I see |
| 16:06 | <marcosc> | sorry, if I pretend someone cares, then it doesn't sound like I'm always talking to myself :) |
| 16:10 | <darobin> | marcosc: are you sure they're not using WebIDL? Gecko has the infrastructure for IDL stuff |
| 16:10 | <marcosc> | darobin: I'm pretty sure, I just looked at the code for the processor. https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/AppsUtils.jsm#180 |
| 16:33 | <Ms2ger> | Anyone feel like telling me what the 2^1024 thing is for in http://www.whatwg.org/html/#rules-for-parsing-floating-point-number-values ? |
| 16:39 | <annevk> | http://lists.w3.org/Archives/Public/public-xml-core-wg/2013Feb/0025.html hmm |
| 16:39 | <annevk> | Ms2ger: you're the second person to bring that up |
| 16:40 | <annevk> | Ms2ger: I think it's to establish infinity |
| 16:43 | <annevk> | So question. Which version of FTP is implemented by browsers? http://tools.ietf.org/html/rfc959 |
| 16:51 | <dglazkov> | good morning, Whatwg |
| 16:51 | <dglazkov> | ! |
| 16:53 | <gsnedders> | Ms2ger: The important thing is they're closer to +/-INF than anything else. |
| 16:56 | <annevk> | hey dglazkov |
| 16:56 | <annevk> | dglazkov: I didn't find the inDocument and isSVGElement checks from http://trac.webkit.org/browser/trunk/Source/WebCore/dom/EventRetargeter.cpp#L75 in the spec |
| 16:57 | <annevk> | dglazkov: and I think the spec should probably also have the bit about Mouse/Focus vs other Events to make it clear not all events have relatedTarget |
| 16:57 | <annevk> | dglazkov: tried to catch hayato on #webkit but I think he might not be online there |
| 16:58 | <dglazkov> | annevk: emailing him is probably best. He's in Tokyo, so timezone gap... |
| 16:59 | <dglazkov> | annevk: I have this phrase "Some events have a relatedTarget" in https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#retargeting-related-target. Is this enough? |
| 17:00 | <dglazkov> | annevk: SVG is slightly weird in WebKit. I wouldn't worry about that particular check. |
| 17:00 | <dglazkov> | as for inDocument check, that's in DOM core, right? |
| 17:00 | <annevk> | Your terminology is kinda wrong. It's not called a property. mouseover is not an event but an event type and not all events with a mouseover type will therefore have a relatedTarget attribute |
| 17:01 | <annevk> | dglazkov: is it? |
| 17:01 | <dglazkov> | annevk: I agree on terminology being wrong |
| 17:01 | <annevk> | dglazkov: I don't think the DOM cares where your node is |
| 17:01 | <dglazkov> | annevk: well, yeah. If node is not in tree, it usually doesn't have an event path. |
| 17:02 | <annevk> | dglazkov: I think it would be clearer if we scoped it to MouseEvent and FocusEvent or whatever those interfaces are called and also explicitly dealt with the case when the event does not inherit or implement those interfaces |
| 17:02 | <dglazkov> | at least, that's how web works. |
| 17:02 | <annevk> | dglazkov: uuuh |
| 17:02 | <dglazkov> | annevk: yep. That sounds good. |
| 17:02 | <annevk> | dglazkov: you can have a tree outside of a document... |
| 17:02 | <annevk> | dglazkov: e.g. var x= document.createElement("x") ; x.appendChild(document.createElement("z")) |
| 17:03 | <annevk> | dglazkov: afaik event dispatch should just work there |
| 17:03 | <annevk> | smaug____ can confirm |
| 17:03 | <dglazkov> | annevk: well... it won't in webkit :) That check has been there for a long time. |
| 17:03 | <dglazkov> | in other words, it's not related to shadow dom |
| 17:04 | <annevk> | dglazkov: so inDocument() means the node has a Document ancestor right? |
| 17:04 | <dglazkov> | annevk: yup |
| 17:04 | <annevk> | dglazkov: okay, so if it doesn't the event is still dispatched in WebKit but won't go up or down any tree? |
| 17:04 | <dglazkov> | annevk: yep. |
| 17:05 | <annevk> | okay, you're right that's unrelated to what you're doing |
| 17:05 | <annevk> | Ms2ger: we should test that |
| 17:05 | <smaug____> | annevk: ? |
| 17:06 | <smaug____> | event propagation has nothing to do with elements being in document |
| 17:06 | <annevk> | smaug____: right, so in WebKit it does... |
| 17:06 | <smaug____> | that is a bug in webkit |
| 17:06 | <smaug____> | and rather odd one |
| 17:07 | <smaug____> | let's not add that bug to specs |
| 17:07 | <annevk> | I wonder why there's no test that catches that |
| 17:08 | <Ms2ger> | We've got tests? ;) |
| 17:08 | <smaug____> | I wonder why webkit has such odd behavior |
| 17:09 | <annevk> | http://trac.webkit.org/browser/trunk/Source/WebCore/dom/EventRetargeter.cpp#L91 |
| 17:09 | <annevk> | Found it while reading the code today to understand Shadow DOM |
| 17:11 | <smaug____> | last time I checked Gecko's event re-retargeting (which is used for XBL for example) is quite similar. http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsEventDispatcher.cpp#265 |
| 17:11 | <dglazkov> | let me see... |
| 17:11 | <smaug____> | though XBL doesn't handle relatedTarget as consistently as shadow dom |
| 17:15 | <GPHemsley> | annevk: Do you remember what we decided about the license for the wiki? It's MIT now, but I recall it was something else before that. (Is that the case?) |
| 17:16 | <annevk> | GPHemsley: no, I wanted to transition from MIT to CC0 |
| 17:17 | <GPHemsley> | annevk: Oh, and that never happened? |
| 17:17 | <annevk> | GPHemsley: well I wasn't sure how to do it so I kinda left that for you to do at some point if you could |
| 17:17 | <GPHemsley> | oh |
| 17:17 | <GPHemsley> | oops |
| 17:17 | <annevk> | GPHemsley: actually remembered that earlier today and wanted to bug you about it |
| 17:18 | <GPHemsley> | Well, I don't know if there's any way built in to MediaWiki that automatically licenses old content under one license and new content under another. |
| 17:18 | <GPHemsley> | Would there be legal ramifications if we just did it all in one fell swoop? |
| 17:20 | <annevk> | We'd have to add some kind of disclaimer on existing pages I suppose and only remove that once we clarified with all contributors of that page they're okay with CC0 |
| 17:20 | <annevk> | tantek: you around? How did you do this for microformats? |
| 17:22 | <GPHemsley> | Oh, well, http://wiki.whatwg.org/wiki/WHATWG_Wiki:Copyrights would actually allow us to explicitly state whatever we wanted |
| 17:23 | <GPHemsley> | including, "before date X, things were under another license" |
| 17:23 | <dglazkov> | annevk, smaug____: http://trac.webkit.org/changeset/19897 |
| 17:25 | <annevk> | dglazkov: that looks wrong |
| 17:26 | <dglazkov> | annevk: we build our castles on mistakes of our past. Where were you 6 years ago with your awesome DOM spec!? :) |
| 17:26 | <annevk> | prolly trying to understand the DOM specs of that age |
| 17:26 | <GPHemsley> | annevk: You want me to change the license effective today? |
| 17:26 | <dglazkov> | time machine pls |
| 17:27 | <annevk> | GPHemsley: please |
| 17:27 | <GPHemsley> | annevk: You're the only one who's edited today, so that shouldn't be a problem. |
| 17:27 | <dglazkov> | coming to a theater near you... Anne van Kesteren is THE LOOPER |
| 17:29 | smaug____ | kicks Antti hard |
| 17:29 | <annevk> | smaug____: ? |
| 17:29 | <dglazkov> | hey, hey, no violence. |
| 17:29 | <annevk> | oh it was his patch? |
| 17:29 | <smaug____> | yup |
| 17:30 | <smaug____> | dglazkov: just gentle kick |
| 17:30 | <annevk> | weird that they didn't get compat issues |
| 17:30 | <annevk> | i guess nobody uses events |
| 17:30 | <annevk> | also, I don't understand how this fix works |
| 17:30 | <smaug____> | I think https://bugs.webkit.org/show_bug.cgi?id=12918#c2 is about Firefox < 3.0 |
| 17:30 | <annevk> | if the node is disconnected from the tree when you dispatch the event, how could it ever reach the parents? |
| 17:31 | <annevk> | oh Firefox had a bug too? |
| 17:31 | <smaug____> | event dispatching was rewritten 2006, so it ended up to FF3 which was released IIRC spring 2007 |
| 17:31 | <smaug____> | Gecko < 1.9 had odd event dispatching |
| 17:32 | <annevk> | nice digging dglazkov |
| 17:32 | <smaug____> | (my 3rd big contribution to Gecko was to rewrite the whole DOM event dispatching :) ) |
| 17:32 | <dglazkov> | annevk: oh it's nothing, just a hundred clicks on trac.webkit.org |
| 17:33 | <Ms2ger> | dglazkov, anything takes a hundred clicks there |
| 17:33 | <smaug____> | oh, 3.0 was released 2008 |
| 17:36 | <annevk> | dglazkov: will you file a bug? |
| 17:37 | <dglazkov> | annevk: WebKit bug? I don't think there's much hope for it ever being fixed. We usually don't change a behavior that's been around for over 6 years. |
| 17:38 | <annevk> | o_O |
| 17:39 | <hober> | O_o |
| 17:39 | <dglazkov> | <_< |
| 17:39 | dglazkov | is filing bug |
| 17:40 | <smaug____> | dglazkov: o_O |
| 17:40 | <smaug____> | not changing behavior |
| 17:40 | <smaug____> | that is odd |
| 17:41 | <dglazkov> | don't break the web, right? |
| 17:41 | <annevk> | and don't violate the specs |
| 17:42 | <MikeSmith> | bend the Web |
| 17:42 | tantek | scrolls up |
| 17:43 | tantek | agrees with transitioning the wiki license to CC0. |
| 17:44 | <tantek> | GPHemsley: you can flip the license for all edits as of today and later. |
| 17:44 | <GPHemsley> | tantek: In the process. :) |
| 17:44 | <tantek> | annevk, with microformats we took the approach of flipping the license, and *also* have a template for user pages where individual users could place all their contributions (for all time) into public domain / CC0. |
| 17:45 | <tantek> | then we asked contributors to do so, and as they did, more and more pages full entered the public domain |
| 17:45 | <annevk> | I guess we can see how far that gets us |
| 17:45 | <annevk> | should work pretty well for the pages I author mostly by myself :) |
| 17:46 | <tantek> | see here for details on how we addressed the transitions: http://microformats.org/wiki/Microformats_Wiki:Copyrights |
| 17:46 | <tantek> | (that page itself is of course CC-PD/0 so feel free to copy from it as you feel is useful for the WHATWG wiki :) ) |
| 17:47 | <tantek> | note: this is also why I put the public domain release template on the WHATWG wiki and used it on my user page ages ago: http://wiki.whatwg.org/wiki/User:Tantek |
| 17:47 | <tantek> | note the phrasing: "or any later version published by Creative Commons; with either a waiver of rights, or an assertion that no rights attach to a particular work." |
| 17:48 | <GPHemsley> | annevk, tantek: http://wiki.whatwg.org/wiki/WHATWG_Wiki:Copyrights |
| 17:48 | <tantek> | that made the declaration CC0 compatible even before CC0 was done being launched (I had that phrasing checked by Lessig at the time) |
| 17:48 | <tantek> | GPHemsley - that's a good start. |
| 17:49 | <dglazkov> | annevk: https://bugs.webkit.org/show_bug.cgi?id=110353 |
| 17:49 | <GPHemsley> | tantek: Yeah, I didn't read what you'd written until after. |
| 17:49 | <tantek> | I'd add an encouragement for contributors to add a public domain / CC0 template to their user page to place more of the wiki into CC0. |
| 17:49 | <tantek> | thanks GPHemsley - appreciate this. |
| 17:51 | <annevk> | GPHemsley: sweet, also need to update the footer |
| 17:51 | <GPHemsley> | annevk: One step at a time. ;) |
| 17:51 | <annevk> | thanks dglazkov! |
| 18:04 | <GPHemsley> | annevk, tantek: You can now go ahead and add {{CC0 user}} to your user page. |
| 18:04 | <tantek> | CPHemsely - awesome |
| 18:05 | <tantek> | done. |
| 18:06 | <tantek> | not as pretty as http://wiki.whatwg.org/wiki/Template:Cc-public-domain-release but it will do ;) |
| 18:07 | GPHemsley | shrugs |
| 18:23 | <MikeSmith> | ok ok I'm pretty sure kripken is the same that The Story of Mel, a Real Programmer is about |
| 18:24 | <MikeSmith> | same guy |
| 18:24 | <MikeSmith> | or at least a reincarnation |
| 18:39 | <GPHemsley> | Is anyone else suddenly having trouble accessing wiki.whatwg.org ? |
| 18:40 | <GPHemsley> | ah, there we go |
| 18:45 | <GPHemsley> | annevk, tantek, et al.: If you want to release a pre-existing page under CC0 (provided you have consent from all editors involved), you can use {{CC0 page}}. |
| 18:46 | <tantek> | nice |
| 18:54 | <GPHemsley> | http://wiki.whatwg.org/wiki/WHATWG_Wiki:Copyrights has been updated to be more explicit and helpful. |
| 18:54 | <GPHemsley> | tantek: ^ |
| 18:56 | <tantek> | GPHemsley - see my previous attempt at PD here: http://wiki.whatwg.org/wiki/Category:Public_domain_license |
| 18:56 | <tantek> | (encouraging people) |
| 18:56 | <tantek> | we can probably get hober to also add {{cc0 user}} |
| 18:59 | <GPHemsley> | tantek: I see your point about encouraging users, but I don't think the category page is the place to do it. In fact, I would prefer to deprecate the framework surrounding {{cc-public-domain-release}} in favor of the new templates, if you don't mind. (We don't want to create more confusion than there already is.) |
| 18:59 | <GPHemsley> | tantek: I'll send a message to the mailing list later about the changes. |
| 18:59 | <tantek> | Yes that makes sense. Perhaps deprecate it once the one user (hober) of PD but not CC0 has updated their user page? |
| 19:00 | <tantek> | I figured every change to encourage people was worth doing |
| 19:00 | <tantek> | just to try to get more people to do it |
| 19:00 | <tantek> | like if/when people find the category page from a person's user page, and then wonder how they can get themselves added to that category page. |
| 19:00 | <GPHemsley> | tantek: Well, if the chatter here and the announcement on the mailing list doesn't do it, then probably nothing will. ;) |
| 19:01 | <tantek> | well it's the initial burst vs. long term |
| 19:01 | <GPHemsley> | sure |
| 19:01 | <GPHemsley> | but we can deal with that later |
| 19:01 | GPHemsley | wanders off to eat. |
| 19:07 | <annevk> | hober: please fix your wiki page per above kthxbai :) |
| 19:11 | <divya> | so vague annevk |
| 19:12 | <jamesr> | \angry_simcity_advisor{You can't public GCPM in this state! You will regret this!} |
| 19:14 | <Ms2ger> | Can't, eh |
| 19:17 | <dglazkov> | annevk: you still there? |
| 19:18 | <dglazkov> | annevk: what is a good error to throw when author attempts to register a custom element that is already registered? |
| 19:19 | <dglazkov> | 1) NotSupportedError, as in you can register more than one element with the same name |
| 19:19 | <dglazkov> | can->can't |
| 19:20 | <dglazkov> | 2) InvalidAccessError, as in document.register does not support more than one registration with the same name |
| 19:20 | <annevk> | I guess 1) |
| 19:20 | <dglazkov> | 3) DglazkovError, as in blame dglazkov for this mess |
| 19:20 | <annevk> | or something new |
| 19:20 | <annevk> | 3) works |
| 19:20 | <dglazkov> | :) |
| 19:20 | <annevk> | that table is expandable |
| 19:21 | <dglazkov> | I think I'll go with 1) for now, and we can tweak later |
| 19:21 | <annevk> | sounds good |
| 19:21 | <annevk> | though boring |
| 19:23 | <dglazkov> | :P |
| 19:34 | <GPHemsley> | FYI: I just turned on subpages for the main namespace, so that using a slash in a page name will create a breadcrumbs navigation hierarchy |
| 19:34 | <GPHemsley> | (on the wiki) |
| 19:42 | <GPHemsley> | annevk: Do you suppose it would be a good idea to tag pre-existing pages with {{CC0 page}} if all of their editors have used {{CC0 user}}? |
| 19:42 | <GPHemsley> | i.e. for clarity's sake |
| 19:42 | <annevk> | GPHemsley: yeah think so |
| 19:43 | <annevk> | GPHemsley: avoids having to check |
| 19:44 | <GPHemsley> | annevk: OK, I did [[Fetch]]. |
| 19:54 | <GPHemsley> | Hixie: Wanna get in on the CC0 party? |
| 19:58 | <Hixie> | i'm an MIT guy |
| 19:59 | <Ms2ger> | I thought you were more of a Bath one |
| 19:59 | <Hixie> | to my knowledge, my alma mater never invented their own license, luckily |
| 20:03 | <jgraham> | Hixie: It looks like they will come up with a custom one if you pay them http://www.bath.ac.uk/bathventures/forbusiness/ip-licensing.html |
| 20:03 | <Hixie> | fantastic |
| 20:03 | <GPHemsley> | Hixie: In that case, is it alright if I tag this as CC0? http://wiki.whatwg.org/wiki/HTML_derivatives |
| 20:05 | <Hixie> | sure |
| 20:05 | <Hixie> | you guys spent way too much time worrying about licenses :-P |
| 20:09 | GPHemsley | shrugs |
| 20:11 | <GPHemsley> | annevk: I've updated the fine print in the footer, but I need to find some icon that suggests a hybrid license. |
| 20:14 | <annevk> | Hixie: about as much time as you worry about Twitter ;-P |
| 20:14 | <GPHemsley> | Hixie: So, wait, does that mean you object to the CC0 switch? |
| 20:15 | jgraham | thinks fiddling with the licenses seems rather pointless |
| 20:16 | <annevk> | jgraham: just makes it clearer if some text from the wiki ends up in a spec |
| 20:25 | <GPHemsley> | Hixie: Speak now or forever hold your peace. (I'm about to message the list.) |
| 20:34 | <annevk> | he's fine with it |
| 20:37 | <nimbu> | srsly wtf is this compromise? https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669 |
| 20:37 | <nimbu> | dglazkov: what is this HYPHEN BZNSS?! |
| 20:38 | <GPHemsley> | annevk: Alright, message sent. Wrath is on you now. ;) |
| 20:39 | annevk | braces for impact |
| 20:41 | <annevk> | nimbu: your English is totes weird |
| 20:42 | <TabAtkins> | nimbu: Um, the hell are you going on about? Previously we needed an x- prefix on element names. Now we've reduced it to just a - in the name somewhere. |
| 20:43 | <nimbu> | ughhh complicated |
| 20:43 | <TabAtkins> | ????? |
| 20:43 | <nimbu> | x- was at least clear |
| 20:43 | <nimbu> | it was custom |
| 20:43 | <nimbu> | now who knows |
| 20:43 | <Ms2ger> | is="" is much nicer |
| 20:43 | <TabAtkins> | x- was super unpopular. |
| 20:43 | <nimbu> | only with the vocal trolls TabAtkins |
| 20:43 | <TabAtkins> | nimbu: No, with plenty of people. |
| 20:44 | <nimbu> | ughhhhhhhhh |
| 20:44 | <Ms2ger> | nimbu, calling me a vocal troll, eh? ;) |
| 20:44 | <nimbu> | more fine print!!!! |
| 20:44 | <nimbu> | Ms2ger: only by inference |
| 20:44 | <nimbu> | so good for open web standards!! |
| 20:45 | nimbu | is very very disappoint |
| 20:45 | <TabAtkins> | nimbu: You're weird. A - is really easy, and will be used commonly anyway - libraries should preface their element names with a prefix to avoid conflicts. |
| 20:45 | <TabAtkins> | Basically, this is just letting you use your own prefix, rather than forcing it to be an x- prefix. |
| 20:45 | <Ms2ger> | "Content Feature Schema for Internet Fax" |
| 20:45 | <TabAtkins> | If you feel like using x-, go crazy - it's totally valid. |
| 20:47 | <esprehn_> | In practice everyone was going to prefix anyway, so we were going to end up with x-jq-button, x-ext-menulist, x-ng-tabpane so the x- was just noise |
| 20:47 | <nimbu> | own prefix for greater conflicts. |
| 20:48 | <nimbu> | so we cannot repurpose namespaces for this |
| 20:48 | <astearns> | nimbu-feedback-button |
| 20:48 | <nimbu> | we just gotta reinvent the wheel |
| 20:48 | <nimbu> | :) |
| 20:48 | <nimbu> | it would just be great screaming WTF asdf` |
| 20:48 | <nimbu> | err |
| 20:48 | <nimbu> | astearns: |
| 20:48 | <esprehn_> | astearns: I'm sure adobe will jump on mx ;) |
| 20:48 | <esprehn_> | <mx-vbox> |
| 20:49 | <nimbu> | <wtf-h1> |
| 20:49 | <nimbu> | <-h2> |
| 20:49 | <astearns> | esprehn_: I think we'd switched to spark- |
| 20:49 | <nimbu> | bah some day this pile of wood called a house is gonna fall crashing down |
| 20:50 | <TabAtkins> | nimbu: If you actually suggest namespaces, you're trolling. |
| 20:50 | <nimbu> | it was invented to solve this problem no? |
| 20:50 | <nimbu> | maybe in a different context |
| 20:50 | <esprehn_> | nimbu: dash isn't valid at the start |
| 20:50 | <Ms2ger> | Mm, namespaces |
| 20:50 | <TabAtkins> | That was the intention, yes. It failed really badly for well-known reasons. |
| 20:50 | <nimbu> | and why are we assuming this custom element thing wont |
| 20:50 | <TabAtkins> | It was a terrible implementation of a solution. |
| 20:51 | <Ms2ger> | nimbu, you're making an assumption there... |
| 20:51 | <nimbu> | o k thanks esprehn_ |
| 20:51 | <nimbu> | Ms2ger: valid point. |
| 20:51 | <TabAtkins> | nimbu: Because we know why namespaces failed, we know that self-selected short prefixes *don't* fail (they're very successful in lots of things on the web, including large libraries), so it seems we have history on our side? |
| 20:51 | <nimbu> | but i am just wondering why we keep reinventing wheel assuming its just gonna get better™ |
| 20:51 | <nimbu> | i merely liked that : syntax |
| 20:51 | <TabAtkins> | We're actually copying the wheel. It's just a better wheel, but everyone keeps suggesting the shitty broken wheel. |
| 20:51 | <nimbu> | not that uri at the beginning and other nonsense |
| 20:52 | <TabAtkins> | nimbu: Then you're not suggesting namespaces, so you shouldn't say that. ^_^ |
| 20:52 | <Ms2ger> | Heh, http://dev.w3.org/csswg/css3-preslev/Overview.src.html |
| 20:52 | <nimbu> | ok : syntax then |
| 20:52 | <nimbu> | hyphen is just way out there. |
| 20:52 | <nimbu> | so easy to make mistakes with. |
| 20:52 | <TabAtkins> | Colon doesn't work for other reasons - it parses differently in HTML and XML, and in XML it's already used by Namespaces (and invalid in tag names). |
| 20:53 | <TabAtkins> | I have no clue what you're going on about with hyphens being hard. |
| 20:53 | <TabAtkins> | Ms2ger: What's the "heh" about? |
| 20:53 | <nimbu> | <h1class=hi-there> |
| 20:53 | <Ms2ger> | I just saw it for the first time in years |
| 20:53 | <TabAtkins> | nimbu: ...? |
| 20:54 | <nimbu> | wont be an error coz hyphens just mean custom elements? |
| 20:54 | <TabAtkins> | nimbu: That's an element with name "h1class", and an attribute called "hi-there". |
| 20:54 | <nimbu> | o k |
| 20:54 | <nimbu> | and = is assumed as? |
| 20:55 | <TabAtkins> | A syntax error, and ignored (if i recall the parser correctly). |
| 20:55 | <Ms2ger> | That's actually an element with local name "h1class=hi-there" |
| 20:55 | <TabAtkins> | I didn't think = was a valid character in names. |
| 20:55 | <Ms2ger> | Names? |
| 20:55 | <Ms2ger> | This is HTML |
| 20:55 | <nimbu> | http://html5.validator.nu/ |
| 20:56 | <TabAtkins> | ...and? |
| 20:56 | <nimbu> | tells me it is an element name |
| 20:57 | <nimbu> | SIGHHH |
| 20:57 | <nimbu> | whatever |
| 20:57 | <TabAtkins> | Indeed. |
| 21:00 | <esprehn_> | equals is valid, so is a bunch of unicode |
| 21:01 | <esprehn_> | <jqπwidget> |
| 21:01 | <nimbu> | that wont be valid custom elm |
| 21:24 | <JonathanNeal> | If any of you have an interest in haml, jade, or sass, I'd dig feedback on a markup I'm experimenting with, something like jade and zen meet sass https://gist.github.com/jonathantneal/4998574 |
| 22:11 | <JonathanNeal> | Hixie: I loved your 2003 pitch for ::outside, whatever happened? |
| 23:31 | <GPHemsley> | ...did I just get BitBucket spam? |