| 00:01 | <jacobolus> | also, max(R, G, B) - min(R, G, B) is an extremely bad proxy for the perceived attribute chroma (which is similar to saturation, but the two have different technical definitions) |
| 00:02 | <zewt> | (if these don't match PS then I'd probably never use them, because they'd be incompatible with every art asset our artist hands me) |
| 00:03 | <jacobolus> | zewt: it's a sad world, right? Adobe can never change their software, because it wouldn't be backward compatible. everyone else has to copy photoshop, or it wouldn't be interoperable |
| 00:03 | <jacobolus> | zewt: and so technical decisions that make no sense in 2012 are entirely impossible to change, ever |
| 00:03 | <cabanier> | jacobolus: people don't want us to change it. There would be an all-out revolt. |
| 00:03 | <zewt> | it makes perfect technical sense, in the context of the real world |
| 00:04 | <jacobolus> | it's just sad, because color is a place where these decisions actually negatively impact every user who tries to create images with them |
| 00:04 | <cabanier> | jacobolus: we can add things |
| 00:04 | <jacobolus> | a lot of technical decisions can be papered over and never seen by the user |
| 00:05 | <cabanier> | jacobolus: like I said, with color, with pulled most of the features because everyone hated it and turned it off |
| 00:05 | <zewt> | (yet there's been no revolt when photoshop changed to stop allowing the navigator to navigate outside the border of the image, which screwed up a bunch of my usage habits; maybe I can pay a mob to revolt for me) |
| 00:05 | <cabanier> | jacobolus: turning it off was harder than the math. A lot of special case code |
| 00:05 | <jacobolus> | zewt: oh really? that was one of my favorite photoshop changes of all time :) |
| 00:06 | <zewt> | it's horrible; I used it all the time to edit around the edge, now it's impossible to even see the edge of the image that way (since it falls underneat the toolbars) |
| 00:06 | <jacobolus> | cabanier: I don't know what specifically you're talking about here |
| 00:06 | <zewt> | also underneath |
| 00:06 | <jacobolus> | zewt: wait, what? |
| 00:06 | <jacobolus> | zewt: dude, press the "F" key |
| 00:07 | <zewt> | i work in fullscreen 100% of the time |
| 00:07 | <jacobolus> | zewt: sorry, I thought you meant the change the other direction |
| 00:07 | <zewt> | did they fix that in cs6 or something? |
| 00:07 | <jacobolus> | could you move past the corners in a document in a window, ever? |
| 00:08 | <zewt> | definitely ... up until something like cs2 |
| 00:08 | <jacobolus> | oh, bummer |
| 00:08 | <zewt> | (and you still can by manually dragging around, the navigator just clips at the edge) |
| 00:08 | <jacobolus> | yeah, that's terrible |
| 00:09 | <cabanier> | jacobolus: I'm technically still on the photoshop team. I can ask them why that decision was made. |
| 00:09 | <jacobolus> | zewt: for some reason I remember that one of the two fullscreen modes used to not to past the edge. but I could be inventing that in my head |
| 00:09 | <jacobolus> | cabanier: doesn't really affect me, but apparently zewt didn't like it :) |
| 00:10 | <jacobolus> | cabanier: if you can bug them about exclusion mode in CIELAB images though... :) |
| 00:11 | <jacobolus> | cabanier: also, if you're working on this css compositing spec, you should add 'linear light' mode if it can be easily done |
| 00:11 | <cabanier> | jacobolus: I will do so. there must be a reason that they grayed it out |
| 00:11 | <cabanier> | jacobolus: ask for it on www-style. |
| 00:11 | <jacobolus> | cabanier: the reason is that it's not thought to be meaningful for A/B channels, since they never get close to the extremes |
| 00:11 | <jacobolus> | and so combining two arbitrary images ends up with uninteresting looking results |
| 00:12 | <cabanier> | have to go... |
| 00:12 | <zewt> | run, run, run |
| 00:12 | <jacobolus> | cabanier: but exclusion mode is a building block, not a tool to be used alone |
| 00:12 | <jacobolus> | cheers |
| 00:12 | <jacobolus> | cabanier: anyway, linear light mode. pretty much my favorite blend mode after "normal" |
| 00:15 | <jacobolus> | gavinc: you're right, it's the Rec 601 primaries (NTSC) used for this formula, now that I think back about it |
| 00:15 | <gavinc> | yay, so it wasn't a choice made in the 90s! It's a choice made in the 70s! |
| 00:16 | <jacobolus> | I don't think there was any software image compositing in the 70s |
| 00:17 | <jacobolus> | still a choice made in the 90s :) |
| 00:17 | <jacobolus> | well, actually of course there was software image compositing in the 70s |
| 00:17 | <jacobolus> | but I don't think with these particular "blend modes" anyhow |
| 00:17 | <jacobolus> | anyway, I gotta run too |
| 00:18 | <jacobolus> | Hixie: sorry to crud up your channel there for a bit |
| 00:18 | <jacobolus> | :) |
| 04:44 | <MikeSmith> | Hixie: I think there was at least one person other than hsivonen who wasn't happy with the proposed <template> parsing |
| 04:45 | MikeSmith | goes to look back at some threads |
| 04:45 | <Hixie> | if it's me it doesn't count :-) |
| 04:45 | <MikeSmith> | hahaha |
| 04:58 | <MikeSmith> | Hixie: not exactly an answer to your question, but I think Scott Gonzalez questioned whether we need a <template> element at all, or need to be trying to do this through markup |
| 04:58 | <Hixie> | url? |
| 04:58 | <Hixie> | if he has an alternative solution that is certainly a good thing to look at |
| 05:00 | <MikeSmith> | Hixie: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0294.html |
| 05:01 | <MikeSmith> | he's scott_gonzalez on IRC |
| 05:01 | <MikeSmith> | dunno what timezone he's in |
| 05:01 | <MikeSmith> | maybe US/West or Central |
| 05:01 | <Hixie> | i think those points have been pretty fully explained by dimitry and company |
| 05:01 | <MikeSmith> | OK |
| 05:02 | <MikeSmith> | yeah I remember ojan replying |
| 05:02 | <MikeSmith> | anyway I guess Scott is the other person I was thinking of |
| 05:03 | <Hixie> | k |
| 05:04 | <Hixie> | <template> has bubbled its way to the top of my queue again but i'm not sure what to do since it seems a bit bad to go behind hsivonen's back on this |
| 05:04 | <Hixie> | especially after just having gone a way hsivonen didn't really want with the alt attribute thread |
| 05:04 | <Hixie> | though at least in that case it was just a naming thing |
| 05:05 | <Hixie> | this one is reather more... fundamental |
| 05:07 | <MikeSmith> | Hixie: I expect hsivonen will be back soon |
| 05:08 | <MikeSmith> | seems like he's been away for 3 weeks or so already |
| 05:09 | <Hixie> | that's what i thought a few days ago, which is why i had waited on the alt thing :-) |
| 05:30 | <zcorpan> | work on this until he's back :-) https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=anywordssubstr&short_desc=%3Ctrack%3E+webvtt&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2 |
| 05:30 | <zcorpan> | =&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= |
| 05:54 | <jacobolus> | cabanier: hey Rik. By the way, I wanted to say that even though I got a bit ranty earlier, I do appreciate the addition of more kinds of image compositing to CSS. It should enable some very cool stuff. :) |
| 05:55 | <jacobolus> | my annoyance at the "luminosity", etc. blend modes is with their technical details (which fall short of what they could be), not with their concept (which is a great one) |
| 05:56 | <jacobolus> | and even just directly copying photoshop's behavior, though perhaps not ideal, is definitely better than not having such features |
| 06:24 | <jgraham> | Hixie: It you are looking for things to do I certianly have reported bugs that I would like fixes for ;) |
| 06:26 | <jgraham> | In related news, I got an apparently working script last night so I will finish it up when I get to the office. Let me know whatever I need to interact with your end (if you didn't already, I didn't check email) |
| 06:27 | <Hixie> | jgraham: i sent you mail |
| 06:27 | <jgraham> | I was thinking of providing a URL that would respond to GETs that would cause an immediate update of the data (with some rate limiting to protect bugzilla) |
| 06:28 | <jgraham> | For long values of immediate (i.e. it would actually do the update async and call back to update your end) |
| 06:28 | <Hixie> | when would i call it? |
| 06:28 | <jgraham> | After someone submits a bug |
| 06:28 | <Hixie> | sure, i can do that |
| 06:28 | <Hixie> | not all bugs go through my script though |
| 06:29 | <jgraham> | Sure, but it would allow a slower update frequency whilst still getting mostly-fresh data |
| 06:29 | <jgraham> | Anyway, need to get ready to leave for the office now if I want to take the bus |
| 06:30 | <Hixie> | k |
| 06:30 | <Hixie> | if you want to do that (which is fine by me) reply to that e-mail and i'll hook in tomorrow at work |
| 06:30 | <jgraham> | Sure |
| 06:41 | <rniwa> | jezz... people are still talking about longdesc :( |
| 06:42 | <zcorpan> | longdesc! longdesc for img, longdesc for iframe, longdesc for video! everyone gets a longdesc! |
| 06:42 | <rniwa> | zcorpan: i propose we add longdesc element and add longdesc content attribute on that. |
| 06:43 | <jgraham> | rniwa: In web standards, the definition of "n00b" is "has endured less than half a decade of longdesc flamewars" |
| 06:44 | <rniwa> | jgraham: i had been following the w3c standards for a while but i had never been aware of longdesc flamewars :( |
| 06:44 | <rniwa> | jgraham: probably because i had avoided joining mailing lists |
| 06:44 | <jgraham> | rniwa: n00b |
| 06:45 | <jgraham> | :) |
| 06:45 | <rniwa> | jgraham: i must say i'm quite amazed that people participating in that discussion can make living... |
| 06:47 | <rniwa> | jgraham: although... on the other hand, the definition of standards n00b might be to consider W3C as too bureaucratic. |
| 06:48 | <rniwa> | jgraham: W3C is nothing like IETF or ISO. |
| 06:59 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=17273#c6 so use case A, i'm pondering about what an api would look like and have trouble with naming |
| 07:00 | <zcorpan> | my idea is: video.XYZ.add(0, 90, 100, 100); would occupy the bottom 10% of the video (so cues are pushed upwards) and video.XYZ.clear(); would clear the areas |
| 07:01 | <zcorpan> | having a property XYZ instead of putting the methods on video directly my thinking is that it would be easier to extend in the future and maybe easier to work with if you save the object as a variable |
| 07:02 | <zcorpan> | anyone have suggestions for the name? |
| 07:12 | <zcorpan> | video.viewport.occupy(...) maybe? |
| 07:33 | <odinho> | occupy video movement? :P |
| 07:34 | <jgraham> | video.viewport.occupy(99%)? |
| 07:34 | <odinho> | jgraham: Oh man, too good :D :D |
| 08:14 | <kennyluck> | So there's no longer WHATWG weekly…. |
| 08:15 | <kennyluck> | For what it's worth, I do appreciate Anne's work. I can see how boring writing such summaries is… |
| 08:18 | <Ms2ger> | Do I hear a volunteer? :) |
| 08:18 | <jgraham> | Pretty sure I heard one |
| 08:22 | <odinho> | Cool, nice that it'll continue kennyluck! |
| 08:23 | <odinho> | Props to you |
| 08:23 | <kennyluck> | Noooooooo |
| 09:07 | <zcorpan> | kennyluck++ |
| 10:32 | <jgraham> | Did someone say status markers on bugs? |
| 10:32 | <jgraham> | (seems to be broken in Opera though :( ) |
| 10:33 | <zcorpan> | :( |
| 10:38 | <jgraham> | It is broken for other people, right? |
| 10:38 | <jgraham> | I mean the whole status thing is missing? |
| 10:40 | <zcorpan> | i see status boxes in 12.01 |
| 10:40 | <jgraham> | Hmm I have -next |
| 10:41 | <jgraham> | But it worked on the spec I had loaded before |
| 10:46 | <Ms2ger> | jgraham, there's no way to change the spec section after the fact, I guess? |
| 10:46 | <jgraham> | Ms2ger: It just uses the URL field at the moment |
| 10:46 | <jgraham> | So editing that ought to work |
| 10:46 | <jgraham> | I didn't try though |
| 10:46 | <Ms2ger> | How often does it update? |
| 10:47 | <jgraham> | At the moment? Never |
| 10:47 | <Ms2ger> | That's not a lot |
| 10:47 | <jgraham> | But I will set up a cron job and give Hixie a hook to trigger an update after a bug is posted |
| 10:49 | <Ms2ger> | Oh, heh, the bugs filed on #head end up attached to the TOC on the multipage parts |
| 10:49 | <zcorpan> | jgraham: this is awesome. thanks |
| 10:49 | <Ms2ger> | jgraham++ |
| 10:51 | <gsnedders> | Why is there no clear documentation of what is stable in ES6 drafts and what is likely to change? >_> |
| 10:52 | <scott_gonzalez> | Hixie MikeSmith: I can read through the <template> discussions again (and my timezone is ET) |
| 10:53 | <MikeSmith> | scott_gonzalez: I remember that Ojan at least had specifically responded to you with some rationale about why markup was needed |
| 10:55 | <scott_gonzalez> | MikeSmith: Is the main benefit having a native solution for Web Components? |
| 10:55 | <MikeSmith> | yes |
| 10:55 | <MikeSmith> | I guess that's not clear from the rest of the thread |
| 10:55 | <MikeSmith> | but that in fact is what this is needed for |
| 10:56 | <MikeSmith> | I don't know that anybody has any other use in mind for it other than that |
| 10:57 | <MikeSmith> | I remember an hsivonen question in that thread that indicated he wasn't aware of that either |
| 10:57 | <scott_gonzalez> | I guess that seems fine. I'm not sure it's really a big win to have a declarative way to define loops and the such. |
| 10:57 | <scott_gonzalez> | Do we expect components that need logic and don't need JS? |
| 10:58 | <scott_gonzalez> | I should probably read the Web Components spec again. |
| 10:58 | <scott_gonzalez> | I only read it once and it was a while ago. |
| 11:00 | <MikeSmith> | scott_gonzalez: I don't think we'd expect components that need logic but don't need JS, no. |
| 11:00 | <MikeSmith> | But I'm not expert on those specs either |
| 11:00 | <MikeSmith> | dglazkov would be the person to ask |
| 11:00 | <MikeSmith> | he's in US/West I think |
| 11:00 | <scott_gonzalez> | ok |
| 11:01 | <scott_gonzalez> | I'm juts having a hard time thinking about how a component would make use of nested templates and looping without having to do a bunch of logic in JS anyway. |
| 11:01 | <scott_gonzalez> | s/juts/just/ |
| 11:01 | <MikeSmith> | right |
| 11:02 | <MikeSmith> | I would think it still need the JS logic too but I could well be wrong about that |
| 11:02 | <MikeSmith> | there is no purely declarative way to do this as far as I can see |
| 11:02 | <scott_gonzalez> | I have an item on my todo list to convert a jQuery UI widget into a web component. |
| 11:03 | <scott_gonzalez> | But I won't be able to work on that for at least 1-3 weeks. |
| 11:03 | <MikeSmith> | that would be a good exercise for sure |
| 11:03 | <scott_gonzalez> | We're in crunch time for a release. |
| 11:03 | <MikeSmith> | OK |
| 11:03 | <MikeSmith> | we should really try to have another face-to-face meeting somewhere early next year to talk about Web Components |
| 11:04 | <MikeSmith> | I'm sure we will be having a discussion at the WebApps WG meeting in November |
| 11:04 | <MikeSmith> | but that will be in France and I think a lot of people will not be traveling to it |
| 11:05 | <scott_gonzalez> | Do you know where the next one after that will be? |
| 11:06 | <MikeSmith> | scott_gonzalez: if we do in fact end up doing it, most likely in Mountain View or nearby I guess |
| 11:07 | <scott_gonzalez> | I can probably attend that. |
| 11:07 | <MikeSmith> | it will just be a matter of seeing if there's enough interest and then somebody taking responsibility for planning it |
| 11:08 | <MikeSmith> | I guess it's probably something we'll talk about at the WebApps meeting in November |
| 11:08 | <scott_gonzalez> | ok |
| 11:11 | <deane> | MikeSmith: Hi, what mailing list do bugs from this component go to? https://www.w3.org/Bugs/Public/enter_bug.cgi?product=Validator%20%28Nu%29 |
| 11:11 | <MikeSmith> | hey deane |
| 11:12 | <MikeSmith> | no mailing list, maybe |
| 11:12 | <MikeSmith> | wait no, www-validator-cvs⊙wo |
| 11:12 | <MikeSmith> | see the QA Contact field |
| 11:12 | <deane> | I see |
| 11:12 | <MikeSmith> | deane: they also go to mike+validator⊙wo |
| 11:13 | <MikeSmith> | so you can just set a watch on that address if you want |
| 11:13 | <deane> | I see |
| 11:14 | <deane> | so there will be double ups with .nu's bugzilla then? Two bugzillas for one validator |
| 11:15 | <deane> | How come it doesn't have the text field and file upload functionality? |
| 11:15 | <MikeSmith> | it does have those |
| 11:16 | <MikeSmith> | and yeah I guess there could be redundant bugs |
| 11:16 | <MikeSmith> | but those a easy to deal with |
| 11:17 | <MikeSmith> | deane: the select menu at http://validator.w3.org/nu/ has "Address", "File Upload", and "Text Field" |
| 11:17 | <MikeSmith> | it requires that you have JS enabled |
| 11:18 | <deane> | Yeah, just noticed that :) |
| 11:20 | <deane> | I wish hsivonen had a mailing list for .nu's bugzilla. I think it's only you and him that get the notifications. |
| 11:30 | <zcorpan> | deane: add hsivonen to your watch list. http://bugzilla.validator.nu/userprefs.cgi?tab=email |
| 11:31 | <deane> | zcorpan: thanks, I'll set that up. |
| 11:50 | <zcorpan> | jgraham: would it be hard to put the bug summary in the link title=""? |
| 11:52 | <jgraham> | zcorpan: I was thinking that too |
| 11:52 | <jgraham> | Easy on my end at least |
| 11:53 | <jgraham> | It would require a different wire format and stuff, but nothing that would be difficult to change I think |
| 12:05 | <zcorpan> | would be nice for sure |
| 12:14 | <jgraham> | I am thinking we should be able to do something similar for tests (maybe a link per section to tests for that section, genertated from whatever manifest data people have added) and that the other stuff that's currently in the status markers isn't that useful |
| 12:14 | <jgraham> | Would be nice if the implementation status could be outsourced to caniuse.com |
| 12:15 | <zcorpan> | yeah |
| 12:16 | <zcorpan> | and finally, it would be nice to have all this for other specs, too (and i want a pony) :-) |
| 12:17 | <jgraham> | I might fix up some code to scrape which tests apply to each section in the next few days |
| 12:19 | <jgraham> | Could map caniuse.com data to section ids (for at least top level sections) and get some implementation status data from there |
| 12:19 | <jgraham> | https://github.com/Fyrd/caniuse/blob/master/data.json |
| 12:38 | <zcorpan> | jgraham: so what happens when a bug is no longer open, does it leave the section box lying around or does it remove it if there's no other data in it? |
| 12:38 | <jgraham> | zcorpan: The box will just end up in the state it would have been in if there had never been a bug |
| 12:38 | <jgraham> | But Hixie did that whole end |
| 12:39 | <zcorpan> | ok |
| 12:39 | <jgraham> | My role in the enterprise is just scraper of data |
| 12:39 | <jgraham> | (for small values of "scrape" since it is XML and CSV rather than HTML) |
| 12:40 | <odinho> | jgraham: That would be ace, in fact. Using caniuse api. |
| 12:40 | <odinho> | s/api/datha |
| 13:56 | <smaug____> | no rniwa |
| 13:56 | <smaug____> | I wonder in which time zone he is in? |
| 13:57 | <Ms2ger> | jp? |
| 14:06 | <jgraham> | Indeed, I was under the impression he works in the Googleplex in MV |
| 14:07 | <smaug____> | Ms2ger: hey, another thing. Since anne is apparently away, do you happen to know how stable prepend()/append() etc are in DOM4 |
| 14:07 | <smaug____> | after/before will change sure |
| 14:07 | <jarek> | is there somewhere a JSON version of this table? http://www.w3.org/TR/SVG/attindex.html |
| 14:07 | <Ms2ger> | I haven't seen feedback on it for ages, so I assume either stable or ignored :) |
| 14:08 | <jgraham> | Not ignored |
| 14:08 | <Ms2ger> | Must be stable, then |
| 14:08 | <Ms2ger> | jgraham, you're denying to comment on whether or not you're implementing? :) |
| 14:09 | <jgraham> | Ms2ger: No comment on whether or not I am commenting :p |
| 14:09 | <Ms2ger> | Dammit :) |
| 14:10 | <smaug____> | somewhere between ignored and stable then.. |
| 14:51 | <gsnedders> | Ms2ger: Oh come on, you know we're implementing it, along with everything else in HTML5/DOM4/CSS3/XSLT2/$otherSpecHere, because how else would we do it first!? |
| 14:52 | <gsnedders> | We implement stuff within days of it getting specced! |
| 14:52 | <gsnedders> | We just have rather long times to market. :P |
| 14:52 | <gsnedders> | s/./ at times./ |
| 15:33 | <Hixie> | jgraham: yeah adding titles seems like a great thing to do |
| 15:33 | <Hixie> | jgraham: i can set something up when i get to the office |
| 15:33 | <Hixie> | would be a slightly bigger pain on my end but nothing unmanageable |
| 15:34 | <Hixie> | jgraham: doing the tests too would be great, that's actually already supported |
| 15:34 | <Hixie> | jgraham: you'd just have to plug into the existing API for updating section markers |
| 15:35 | <Hixie> | i looked into doing implementation status from caniuse at some point but that was gonna be more than trivial so i didn't bother |
| 15:35 | <Hixie> | i'd love to have that automatic too though |
| 16:51 | <odinho> | Hixie: What is needed? A mapping from section to the data? Maybe the upstream data could even get that in. |
| 17:22 | <Hixie> | odinho: yeah |
| 17:26 | <Hixie> | jgraham: yt? |
| 17:33 | <Hixie> | jgraham: i've changed the wire format and database |
| 17:35 | <smaug____> | still no rniwa |
| 17:36 | <Hixie> | jgraham: updated the front-end, too |
| 17:40 | <TabAtkins> | smaug____: rniwa works in our SF office. |
| 17:49 | <Ms2ger> | I've seen rniwa on the list |
| 17:52 | <TabAtkins> | zcorpan: Someone just suggested that inline CAS + parser-inserted elements could do the adjustments synchronously. I don't immediately see any problems with this - it's just adjusting the set of attributes attached to the element during building, essentially. |
| 17:55 | <TabAtkins> | Well, minor problem I suppose - if the inline CAS is late in the document, it'll only apply synchronously to elements *after* it in the stream, I guess. This might be confusing. |
| 17:55 | <TabAtkins> | However, there's no reason at all to put your CAS in late - linked CAS is automatically async, and inlined CAS doesn't need to wait for any elements to load, like JS might. |
| 18:30 | smaug____ | wonders how to deal with this webkit limitation "can't implement this and that because that would leak" |
| 18:30 | <smaug____> | that affects heavily to APIs |
| 18:30 | <smaug____> | and it is very odd limitation |
| 18:31 | <smaug____> | rniwa: FYI, I doubt Gecko would implement undomanager per page approach |
| 18:35 | <Hixie> | man i hate how you can't 'transition' from max-height:0 to max-height:auto |
| 18:42 | <Hixie> | Ms2ger: are there specific urgent bugs you need me to look at? |
| 18:42 | <Hixie> | Ms2ger: (if so, mark them "critical") |
| 18:42 | <Ms2ger> | Don't think so |
| 18:42 | <Hixie> | k |
| 18:42 | <Ms2ger> | Actually, you fixed one of them yesterday :) |
| 18:43 | <Hixie> | the only bugs i remember fixing yesterday were typos that i was fixing while watching tv :-) |
| 18:43 | <Ms2ger> | The Attr bug |
| 18:43 | <Hixie> | oh right |
| 18:43 | <Hixie> | close enough to a typo |
| 18:43 | <Ms2ger> | You should watch more tv, it seems to help you get work done :) |
| 18:44 | <Hixie> | heh |
| 18:44 | <Hixie> | i've been doing lots of stuff recently |
| 18:44 | <Hixie> | rewrote the whoel ruby section :-) |
| 18:44 | <Hixie> | that was like days' worth of work |
| 18:44 | <rniwa> | smaug____: i'm not suggesting that either. |
| 18:45 | <rniwa> | smaug____: i specifically avoided spec'ing how undo inside a text field works |
| 18:45 | <rniwa> | smaug____: given that there are different needs from different vendors |
| 18:45 | <Ms2ger> | Hixie, well, I don't care about ruby ;) |
| 18:45 | <rniwa> | smaug____: we probably need to make undoscope content attribute optional |
| 18:46 | <rniwa> | smaug____: alternatively, we can get rid of "undo()" and "redo()" from undo manager API |
| 18:46 | <smaug____> | rniwa: optional in which sense? |
| 18:46 | <rniwa> | smaug____: and the definition of active undo manager platform dependent |
| 18:46 | <rniwa> | smaug____: that some browsers won't support it |
| 18:46 | <smaug____> | rniwa: no optional features in APIs |
| 18:47 | <rniwa> | smaug____: then, we need to get rid of undo() and redo() from undoManager. |
| 18:47 | <rniwa> | smaug____: i mean... i don't have to use the term optional |
| 18:47 | <rniwa> | smaug____: i can just make it not do anything on browsers that don't support multiple undo managers per document. |
| 18:47 | <rniwa> | smaug____: the thing is... we can have multiple undo managers per document, and that's final. |
| 18:47 | <rniwa> | smaug____: there's nothing we can do about it. |
| 18:47 | <Hixie> | ok i poked at the status boxes' styles a bit |
| 18:47 | <Hixie> | hopefully y'all think they look prettier now |
| 18:47 | <smaug____> | we isn't the idea to give web developers to make whatever kind undo handling they want |
| 18:48 | <smaug____> | page level or field level |
| 18:48 | <rniwa> | smaug____: no. |
| 18:48 | <hober> | undo behavior should match the local platform convention |
| 18:48 | <rniwa> | smaug____: the idea of undo manager is to let browsers know the existence of undo stack in the page |
| 18:49 | <rniwa> | smaug____: if they just wanted to do whatever the heck they want, just add a random entries to undo manager |
| 18:49 | <rniwa> | smaug____: and then mantain your own undo manager |
| 18:49 | <rniwa> | smaug____: then you can do whatever the hell you want. |
| 18:49 | <Hixie> | btw are there any opera people around who have an opinion on <template>? |
| 18:49 | <rniwa> | smaug____: and i don't intend stop you from doing that. |
| 18:50 | <rniwa> | smaug____: all we're asking is to let us not violate platform conventions and let us make our decision as to what can be implemented and what cannot be implemented in our engine. |
| 18:50 | <Hixie> | also i plan to post http://wiki.whatwg.org/wiki/What_you_can_do to alistapart pretty soon so if anyone sees anything wrong with it, please let me know asap |
| 18:51 | <rniwa> | smaug____: i'm totally fine and respectful of the fact gecko (and opera) chose to have a separate undo manager per text field |
| 18:51 | <smaug____> | rniwa: yeah, in practice it is "this is hard to implement in webkit, so lets do a dummy API" |
| 18:51 | <rniwa> | smaug____: and i don't intend to comprose that either. |
| 18:51 | <rniwa> | smaug____: no. |
| 18:51 | <Ms2ger> | Hixie, hmm, I don't see bug annotations, am I just missing them? |
| 18:51 | <rniwa> | smaug____: it's not just hard. it's impossible. |
| 18:51 | <smaug____> | rniwa: what I'm even more worried that since webkit can't handle certain kinds of APIs, that will lead to worse APIs also elsewhere |
| 18:52 | <Hixie> | Ms2ger: they're all gone except in the #introduction box for now |
| 18:52 | <smaug____> | rniwa: it is hard, not impossible |
| 18:52 | <Hixie> | Ms2ger: i'm waiting for jgraham to update his end to send bug titles |
| 18:52 | <rniwa> | smaug____: it is impossible in practice |
| 18:52 | <smaug____> | rniwa: Gecko had similar problems |
| 18:52 | <rniwa> | smaug____: we're not going to adopt Gecko's approach |
| 18:52 | <smaug____> | but then we implemented cycle collector |
| 18:52 | <rniwa> | smaug____: nor are we willing to fix that problem. |
| 18:52 | <smaug____> | other options are also possible |
| 18:52 | <Ms2ger> | Hixie, oh, right |
| 18:52 | <smaug____> | like to gc for everything |
| 18:52 | <rniwa> | smaug____: but we're not going to do that. |
| 18:52 | <rniwa> | smaug____: we have discussed this. |
| 18:52 | <smaug____> | that is your choice |
| 18:53 | <rniwa> | smaug____: and that's our conclusion. |
| 18:53 | <rniwa> | smaug____: yes |
| 18:53 | <rniwa> | smaug____: and i'm asking you to respect that. |
| 18:53 | <rniwa> | smaug____: the matter of fact is that we're going to veto the spec anyway if we kept the spec as is. |
| 18:53 | <smaug____> | rniwa: well, I'm worried that web APIs will be less than optimal because one major browser engine can't handle certain basic things |
| 18:54 | <rniwa> | smaug____: i don't consider this as "basic things" |
| 18:54 | <smaug____> | rniwa: at least would be great to have some documentation what all webkit can't handle |
| 18:54 | <smaug____> | so that we could try to avoid such constructs in APIs |
| 18:54 | <rniwa> | smaug____: maybe. |
| 18:55 | <rniwa> | smaug____: it was my fault. i should have chekced our how our object model works earlier |
| 18:55 | <smaug____> | rniwa: if you have a GCed language like JS, and you design APIs for it, it is quite natural to expect that the underlying implementation can handle cycles |
| 18:55 | <rniwa> | smaug____: we can handle cycles in javascript objects |
| 18:55 | <Hixie> | fwiw, when there's a disagreement like this, at the end of the day, if you can't come to agreement, the way to solve it is to implement what you think is best and then ship it early enough that your implementation gets more traction than the other |
| 18:56 | <Hixie> | and then the "losing" side gets to implement the other API or lose web compat |
| 18:56 | <rniwa> | Hixie: are you talking to us? |
| 18:56 | <Hixie> | yes :-) |
| 18:56 | <rniwa> | Hixie: yeah. |
| 18:56 | <rniwa> | Hixie: my current plan is create a custom build of chromium with this feature |
| 18:56 | <smaug____> | Hixie: well, so far webkit devs have made pretty clear they won't accept any certain kinds of APIs, which cause cycles in C++ |
| 18:57 | <rniwa> | Hixie: and let develpoers play with it. |
| 18:57 | <Hixie> | smaug____: if you just implement that kind of API and get it widely adopted, you'll force the webkit devs to implement such an API anyway, and then your problem is solved :-) |
| 18:57 | <Hixie> | (presumably at great cost to the webkit project) |
| 18:58 | <smaug____> | (I don't know why it is so great cost when all the other engines have the solution) |
| 18:58 | <Hixie> | (disclaimer: i have no idea what exactly we're talking about here in terms of the undomanager api, so i have no opinion on the actual issue) |
| 18:58 | <rniwa> | Hixie: i mean... we're not going to implement it anyway. |
| 18:58 | <rniwa> | Hixie: it's not a matter of whether we work hard or not. |
| 18:58 | <Hixie> | rniwa: if all the other browsers implement it, you'd end up implementing it |
| 18:58 | <rniwa> | Hixie: not really. |
| 18:58 | <rniwa> | Hixie: we can choose not to implement it :) |
| 18:59 | <Hixie> | you can chose to lose lots of market share :-) |
| 18:59 | <rniwa> | Hixie: just like WebGL isn't implemented by IE |
| 18:59 | <Hixie> | yeah, and we'll see how long they manage to hold out |
| 18:59 | <smaug____> | Hixie: as far as I've understood webkit devs say they won't implement certain kinds of APIs. It is not quite clear to me what all cause problems for them |
| 18:59 | <smaug____> | apparently even MutationObserver is hard (and leaky atm) |
| 19:00 | <rniwa> | smaug____: the problem is that our JS engine uses garbage collection but all C++ objects are ref-counted |
| 19:00 | <smaug____> | yes |
| 19:00 | <smaug____> | Gecko works the same way |
| 19:00 | <smaug____> | JS is GCed and C++ refcounted |
| 19:01 | <smaug____> | (but we have cycle collector to kill the cycles ) |
| 19:02 | <rniwa> | smaug____: https://docs.google.com/document/d/1uYHpq7u5Sslj54UgzXjA7pYR53XjidpBcrCa-neOGQs/edit?pli=1 |
| 19:02 | <rniwa> | smaug____: this explains how nodes are managed in webkit |
| 19:03 | <Hixie> | rniwa: for the record, "we can't implement that" is a bit of a weak argument given that we're talking about software. i mean, you can implement it. not wanting to is a different matter. |
| 19:03 | <Hixie> | rniwa: (again, i've no knowledge of the precise issue here, i'm just talking in general terms) |
| 19:03 | <rniwa> | Hixie: well, if we were to implement this, we might as well as write our engine from scratch |
| 19:03 | <Hixie> | mozilla did do that once |
| 19:04 | <rniwa> | Hixie: and we're not going to do that. |
| 19:04 | <rniwa> | Hixie: so it's impossible in practice |
| 19:04 | <smaug____> | cycle collector was added to gc+refcounted engine |
| 19:04 | <smaug____> | it was a bit painful yes |
| 19:04 | <smaug____> | but it is not impossible in practice |
| 19:05 | <Hixie> | "we don't want to do that" is a different argument than "it's impossible". i'm just saying you'll get much better reactions from other vendors if you just say "we don't want to" than if you claim that something is impossible, especially if they have done it. |
| 19:05 | <rniwa> | smaug____: the problem is that cycle collector will regress the performance will introduce a significant complexity to the code base. |
| 19:05 | <rniwa> | Hixie: sure. i guess it's a wording issue :/ |
| 19:07 | <Hixie> | (from a competitive point of view, it seems gecko would be well positioned to introduce a widely-used api that forced you to take that hit to remain relevant, so it seems wise for webkit to get the alternative API used widely before gecko does theirs :-) ) |
| 19:07 | <rniwa> | Hixie: that's why we're already implementing it :) |
| 19:08 | smaug____ | needs to design some awesome new API which is all about cycles :) |
| 19:09 | <Hixie> | rniwa: then you run the opposite risk, namely pissing off other vendors because you're forcing what they consider a bad api down their throat... it seems you're screwed either way :-) |
| 19:09 | <rniwa> | Hixie: it's okay :) |
| 19:09 | <rniwa> | Hixie: i'm used to pissing other ppl off |
| 19:09 | <rniwa> | Hixie: that's my way life :P |
| 19:09 | <rniwa> | way of* |
| 19:13 | <rniwa> | Hixie: at the end of the day, there are things we don't do. like we'll never implement XBL2.0 |
| 19:14 | <Hixie> | if firefox and IE both used it and Amazon, CNN, and eBay all depended on it, you would. |
| 19:14 | <Hixie> | s/used/implemented/ |
| 19:14 | <rniwa> | Hixie: maybe. |
| 19:15 | <Hixie> | come now |
| 19:15 | <Hixie> | there's no "maybe" there |
| 19:15 | <rniwa> | Hixie: or maybe we'll just lose the market share because we decide not to implement it. |
| 19:15 | <Hixie> | uh huh |
| 19:16 | <Hixie> | hober: aren't bugs supposed to get some boilerplate when they're closed? (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16793) |
| 19:30 | <cabanier> | jacobolus: I got some info from the photoshop engineers. |
| 19:31 | <cabanier> | jacobolus: exclusion doesn't give intuitive or useful results in Lab mode. The blending modes are meant to be visually pleasing, not mathematically correct |
| 19:32 | <hober> | Hixie: yes |
| 19:32 | <hober> | Hixie: looks like jay doesn't know that |
| 19:32 | <hober> | Hixie: i will bug him |
| 19:32 | <cabanier> | jacobolus: people who want to emulate the math behind exclusion can do it themselves |
| 19:53 | <Hixie> | hober: k |
| 20:19 | <jacobolus> | cabanier: the reason that's unsatisfying as answers is (1) exclusion mode never gives visually pleasing results, in any color space; it's purely for tricky special effects or as an intermediate step in something else, and really only useful to someone who knows what's going on, and the “usefulness” is identical in RGB or Lab, (2) it's not possible to "emulate" the result in any obvious way, except by through a bunch |
| 20:19 | <jacobolus> | of explicit manual steps, or by doing some math in an external tool, or similar. There's no way to do it that is anywhere near so useful when you're actively working in photoshop and exclusion mode would enable some truly awesome possibilities |
| 20:21 | <jacobolus> | also (3) no one but an expert is using Lab mode anyhow, because none of the tools are very well optimized for it. This is yet another limitation that makes it less pleasant than RGB, and this time an entirely arbitrary one |
| 20:23 | <jacobolus> | but anyway, oh well. I came to accept that it wouldn't happen several years ago. not worth worrying too much about |
| 21:35 | <Hixie> | who's css3 ui's editor currently? |
| 21:35 | <Hixie> | or selectors, i guess |
| 21:35 | <Hixie> | let me rephrase |
| 21:36 | <Hixie> | who is in charge of the :read-only and :read-write selectors? |
| 21:37 | <Hixie> | no tab, no tantek, no ms2ger |
| 21:37 | Hixie | checks his calendar to make sure he's not missing some event or something |
| 21:42 | <hober> | tantek's editing css3 ui, and fantasai is editing selectors 4 |
| 21:47 | <Hixie> | k |
| 21:53 | <Hixie> | heycam: i got some [AllowAny] DOMString arguments, do I just drop [AllowAny] ? |
| 21:54 | <heycam> | Hixie, yes DOMString arguments should always be preferred when an argument doesn't match the other overload types |
| 21:54 | <Hixie> | ok |
| 22:03 | <Hixie> | heycam: so there's no difference between an attribute that's "attribute any foo;" and one where it's "attribute (DOMString | SpecialFoo) foo;" except that in the latter case things like coaxing to DOMString if the input is null or { valueOf: ... } etc are handled by Web IDL? |
| 22:04 | <Hixie> | er, "or", not "|" |
| 22:06 | <Hixie> | heycam: and if so, is there a way for me to define that i want an attribute that on setting always coaxes the input to DOMString but on getting could return "any"? |
| 22:26 | <heycam> | Hixie, for the first question, yes that's right; for the second, unfortunately there isn't |
| 22:27 | <Hixie> | k |
| 22:27 | <Hixie> | is there an equivalent for [AllowAny] for "long" ? |
| 22:27 | <heycam> | no, but if there is no DOMString argument overloaded with it it will select the long |
| 22:27 | <Hixie> | i have a method where UAs treat integers one way, and everything else 0 |
| 22:28 | <Hixie> | do i have to make it take any? |
| 22:28 | <heycam> | I don't think so, let me check though |
| 22:28 | <Hixie> | (HTMLOptionCollection.remove()) |
| 22:28 | <heycam> | so you want f("abc") and f(node) to be like f(0)? |
| 22:29 | <Hixie> | yeah |
| 22:29 | <Hixie> | and f(NaN) |
| 22:29 | <heycam> | ok so I *think* it might be like that currently but I'll just confirm] |
| 22:29 | <Hixie> | and f(0.5) |
| 22:29 | heycam | always forgets what the latest state of all the overload resolution stuff is |
| 22:29 | <Hixie> | but f(60.5) treated as f(60) apparently |
| 22:29 | <heycam> | always truncating? |
| 22:30 | <Hixie> | i've tested four numbers so far |
| 22:30 | <Hixie> | they all seemed to truncate |
| 22:30 | <Hixie> | but what do i know |
| 22:30 | <heycam> | ha |
| 22:30 | <Hixie> | seems like it truncates for all the numbers i care about |
| 22:31 | <Hixie> | -0.1 and -0.9 => 0 |
| 22:31 | <heycam> | ok so that should be right, if you don't have an exact match then it'll prefer a DOMString argument, and if there's no DOMString argument it'll prefer a primitive argument |
| 22:31 | <heycam> | so it's then just down to the normal rules for converting to long |
| 22:31 | <Hixie> | ah cool |
| 22:31 | <heycam> | if they match what you need.. |
| 22:31 | <Hixie> | so if i have a method that takes a long it'll never throw TYPE_MISMATCH? |
| 22:31 | <Hixie> | or whatever hte exception is |
| 22:31 | <heycam> | (TypeError) |
| 22:31 | <heycam> | right |
| 22:32 | <Hixie> | how convenient |
| 22:32 | <Hixie> | ok |
| 22:32 | <Hixie> | cool |
| 22:32 | <Hixie> | thanks |
| 22:32 | <heycam> | cool |
| 22:35 | <Hixie> | it astounds me how good a job we are doing of speccing the web platform these days, compared to where we were 13 years ago |
| 22:35 | <Hixie> | (web idl being a huge part of that) |
| 22:36 | <heycam> | hooray |
| 22:44 | <Yuhong> | http://www.w3.org/2001/tag/2011/12/evolution/ |
| 22:44 | <Yuhong> | http://www.w3.org/wiki/Evolution |
| 22:44 | <Yuhong> | I wonder what happened |
| 22:47 | <Hixie> | hober: your copy/paste resolutions are cute :-P |
| 22:54 | <Hixie> | hober: is there any documentation anywhere that tracks which revisions the w3c spec has adopted and which it hasn't? |
| 22:59 | <Hixie> | hober: also, is there something somewhere i can use to keep track of the decisions that were applied? I'm trying to update the list of ways the specs are forked |
| 23:11 | <Yuhong> | DirectX vs OpenGL again, now against CSS Shaders: http://codeflow.org/entries/2012/aug/22/css-shaders-w3c-microsoft-and-broken-standards/ |
| 23:12 | <jamesr> | the rant is strong with this one |
| 23:13 | <zewt> | yeah i closed the window as soon as i saw every other word bolded with some randomly in weird colors |
| 23:15 | <zewt> | (the distracting animations and mugshot didn't help on the "worth reading" scale, either) |
| 23:26 | <Yuhong> | https://news.ycombinator.com/item?id=4422022 |
| 23:38 | <Yuhong> | jamesr: But considering it is MS fragmenting the web yet again, I am not surprised. |
| 23:38 | <jamesr> | i think the article is really misinformed |