| 08:15 | <hsivonen> | matjas: sigh. Corrected the correction. :-( Thanks. |
| 08:15 | <hsivonen> | For a different perspective: https://twitter.com/#!/asadotzler/status/166792492778389504 |
| 08:39 | <MikeSmith> | hsivonen: Asa often seems to have a different perspective on things. |
| 08:40 | <freedrull> | should i be able to stream an OGG icecast stream in an audio element? |
| 09:08 | <annevk> | hmm |
| 09:08 | <annevk> | there should not be a initWheelEvent method to begin with I think... |
| 09:15 | <smaug____> | hsivonen: doesn't Asa always have a different perspective on things. |
| 09:15 | <smaug____> | hsivonen: khuey was worried when he agreed with Asa about something :) |
| 09:18 | <annevk> | I have that with some people |
| 10:00 | <roc> | it's kind of sad how easy it is to write simple JS programs that give different results in different browsers |
| 10:00 | <jgraham> | Define "simple js programs" |
| 10:01 | <roc> | I'm glad you asked me that |
| 10:01 | <annevk> | Math.random() |
| 10:01 | <roc> | var p = { get y() { delete this.y; return 4; } }; var y = 1; with (p) { y += 2; } alert(y + " " + p.y); |
| 10:01 | <annevk> | I win! |
| 10:02 | <jgraham> | roc: You lost "simple" when you wrote "with" |
| 10:02 | <roc> | "with" is simple |
| 10:02 | <roc> | it's just evil |
| 10:02 | <jgraham> | It's not simple |
| 10:02 | <roc> | in the spec it is |
| 10:05 | <jgraham> | Ig by "simple" you mean "requires operations that aren't used in any other part of the spec" |
| 10:05 | <roc> | my sadness reflects on the inherent bogosity of the JS language, not the heroic efforts of its implementors |
| 10:06 | <roc> | "with" just pushes the object onto the scope chain. The complexity is all in how it interacts with other features. |
| 10:06 | <roc> | anyway, I agree with you really; the *program* is simple, it's the language that gets fiendishly complicated when these things start interacting |
| 10:07 | <zcorpan> | i get the same result in gecko and opera at least |
| 10:09 | <smaug____> | chrome gives very surprising result |
| 10:09 | <jgraham> | The program only looks superficially simple, it is actually rather complicated. I agree that the langugae shouldn't have constructs that make superficially simple things complex. |
| 10:10 | <smaug____> | or, hmm, both FF/Opera and Chrome interpretations are kind of understandable |
| 10:11 | <smaug____> | I wonder which one is correct per spec |
| 10:11 | <roc> | FF/Opera as far as I can tell |
| 10:11 | <roc> | the spec says to figure out what object and slot the LHS refers to before evaluating the LHS or RHS |
| 10:12 | <smaug____> | makes sense |
| 10:22 | <annevk> | zcorpan: translate attribute link werkt niet |
| 10:22 | <annevk> | zcorpan: is dat omdat developers.whatwg.org nog niet is bijgewerkt? |
| 10:22 | <zcorpan> | annevk: ben moet updaten |
| 10:22 | <annevk> | k |
| 10:35 | <Velmont> | omg. I was holding off on the RWD discussion, hoping it was something I'd not be interested in. Sadly, it's Responsive Web Design, and I've got a ton of backlog if I want to read it all *shrug*. |
| 10:36 | <jgraham> | Velmont: Obviously the right solution is to only read the maiols I sent ;) |
| 10:36 | <annevk> | I'm surprised we keep discussing width/height |
| 10:37 | <annevk> | nobody wants to know location up front? |
| 10:37 | <annevk> | orientation? |
| 10:37 | <annevk> | light conditions? |
| 10:37 | <jgraham> | We don't have *any* way to work out some of those |
| 10:38 | <jgraham> | It surprises me a bit that people are so obsessed with images |
| 10:38 | <annevk> | it's a big step up over > vs /> |
| 10:38 | <jgraham> | Heh |
| 10:38 | <Velmont> | I am too. I have a news paper with many images on it, -- I serve them quite big, it's quite a load. I made another m.site url in order to make one with small images. |
| 10:39 | <Velmont> | Although I'd really prefer to just have one site. |
| 10:39 | <jgraham> | Velmont: But if you had the information you needed to have just one site, being able to serve different sized images would fall out naturally |
| 10:40 | <jgraham> | The only special thing about images is that you might want to replace the whole image when zooming/resizing the window |
| 10:40 | <roc> | obviously you want a media query that reads the light sensor so you can send an appropriately color-adjusted image |
| 10:42 | <jgraham> | Oh, a site that changed the colour temperature through the day to match the outside conditions would be fun. It would screw with people running F.lux though |
| 10:47 | <TabAtkins_> | F.lux is some good stuff. |
| 10:47 | <TabAtkins_> | Hm. How do I indicate that a map interface should be enumerable? |
| 10:47 | <TabAtkins_> | It currently just has a getter. |
| 10:48 | <Velmont> | I'm using RedShift, which I think is the same. |
| 10:48 | <jgraham> | TabAtkins_: Unless you are in an unexpected location, it doesn't seem to be helping you sleep ;) |
| 10:48 | <TabAtkins_> | jgraham: I'm in Paris. |
| 10:48 | <jgraham> | Oh, OK |
| 10:48 | <TabAtkins_> | And it's not for sleep, it just makes my screen less harsh. |
| 10:50 | <jgraham> | Fair enough; lots of people claim it helps them sleep better (but I have nver seem more than anecdote on this point) |
| 11:02 | <TabAtkins_> | Hmm, in webidl, if you specify the "set of named properties" for an interface with a getter, does that automatically make it enumerable? I haven't found anything about that yet. |
| 11:03 | <TabAtkins_> | Ah, yes, section 4.6 specifies that it does. Good. |
| 11:04 | <MikeSmith> | annevk: so you guys really want me to change the CSSOM component to CSS WG product, right? |
| 11:05 | <annevk> | shane and glenn own that spec now I think |
| 11:05 | <MikeSmith> | wow |
| 11:05 | <annevk> | I dropped out of the CSS WG |
| 11:06 | <MikeSmith> | yeah, I knew that |
| 11:06 | <MikeSmith> | all right, I will make it so |
| 11:06 | <annevk> | so yeah, I also stopped editing CSSOM, CSSOM, Media Queries, and CSS Namespaces |
| 11:06 | <annevk> | CSSOM View ^ |
| 11:07 | <annevk> | oh, CSS Namespaces is actually REC, so I guess that doesn't matter |
| 11:13 | <MikeSmith> | annevk: OK, moved all the CSSOM bugs |
| 11:13 | <MikeSmith> | TabAtkins: I know I still need to create those other CSS WG components, and will try to get that done today |
| 11:13 | <MikeSmith> | first I will move Fullscreen |
| 11:16 | <annevk> | oh, let me know when that's done so I can update the spec |
| 11:19 | <MikeSmith> | annevk: hey can't we get the Encoding spec into Webapps while we are at it? |
| 11:21 | <MikeSmith> | annevk: OK, WebApps now has a Fullscreen component |
| 11:21 | <MikeSmith> | I didn't move any bugs because there were no bugs against the current Fullscreen component |
| 11:22 | <annevk> | k |
| 11:22 | <annevk> | I wouldn't mind Encoding to be there, but it's not really an API... |
| 11:25 | <MikeSmith> | wow, 38 components TabAtkins_ wants to add |
| 11:25 | <MikeSmith> | I hope these are really going to be used |
| 11:27 | <TabAtkins_> | MikeSmith: Wait - I haven't given you primary person yet. |
| 11:27 | <MikeSmith> | TabAtkins_: don't need to, I can just get that from the editor's drafts, right? |
| 11:27 | <TabAtkins_> | Sure, that works. |
| 11:27 | <MikeSmith> | OK |
| 11:32 | <MikeSmith> | btw, I also just created a public-css-bugzilla⊙wo list |
| 11:33 | <MikeSmith> | for firehose notifications for all CSS WG components |
| 11:33 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-css-bugzilla/ |
| 11:35 | <annevk> | MikeSmith: can you also send email to www-dom once those bugs are resolved? |
| 11:36 | <MikeSmith> | annevk: which bugs? |
| 11:36 | <annevk> | MikeSmith: applies to DOM, maybe DOM3Events too |
| 11:36 | <MikeSmith> | you mean not just for new bugs? |
| 11:36 | <annevk> | yeah |
| 11:36 | <annevk> | both new bugs and bugs that are resolved should notify the list |
| 11:37 | <annevk> | this also happens on public-webapps |
| 11:37 | <annevk> | I mean there it's implemented that way and it's better |
| 11:37 | <MikeSmith> | OK |
| 11:37 | <MikeSmith> | btw, where should DOM Parsing and Serialization notifications go? |
| 11:37 | <MikeSmith> | it currently goes to public-webapps |
| 11:38 | <MikeSmith> | should it go to www-dom? |
| 11:38 | <annevk> | maybe, I don't really care |
| 11:38 | <annevk> | I guess that would be more consistent |
| 11:41 | <MikeSmith> | OK, I now have it set so that the resolved notifications go to the www-dom list as well |
| 11:41 | <MikeSmith> | and move the parsing and serialization notices to there as well |
| 11:43 | <annevk> | time for a beer :) |
| 11:49 | <MikeSmith> | annevk: please tell Rune he needs a W3C bugzilla account |
| 11:51 | <annevk> | Rune L? |
| 11:51 | <MikeSmith> | yeah |
| 11:51 | <MikeSmith> | for getting notifications about CSS Device Adaptation bugs |
| 11:52 | <annevk> | pinged him on IRC |
| 11:56 | <annevk> | MikeSmith: he has one now |
| 11:56 | <MikeSmith> | thanks |
| 11:57 | <MikeSmith> | please tell Rune I said thanks too |
| 11:57 | <annevk> | done |
| 12:26 | <zcorpan> | Philip`: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15925 |
| 12:29 | <MikeSmith> | TabAtkins: https://www.w3.org/Bugs/Public/describecomponents.cgi?product=CSS |
| 12:29 | <MikeSmith> | I think I got everything added that needs adding |
| 12:29 | <MikeSmith> | I skipped some things like CSS Ruby that are now marked as obsolete |
| 12:30 | <MikeSmith> | and I munged a CSS3 Text and CSS4 Text into one component |
| 12:30 | <MikeSmith> | a |
| 12:30 | <MikeSmith> | and also Images into one component |
| 12:30 | <MikeSmith> | if you really do want separate components for 3 and 4 of those, lemme know |
| 12:31 | <MikeSmith> | I also renamed some of the existing components to drop the "CSS " part |
| 12:31 | <MikeSmith> | so that may break some bookmarked searches or scripts that others have set up |
| 12:32 | <MikeSmith> | if so, I think that would mostly just be for the Animations, Transforms, and Transitions specs |
| 12:53 | <Velmont> | AryehGregor: Meh, I'm not able to install Windows 8 in VirtualBox. I only get «Windows developer Preview» -- Then suddenly some console text that says «You need to restart your computer» and some error codes. Did you get any of that? |
| 12:55 | <zcorpan> | the status box for http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#abstract looks suspicious |
| 13:00 | <zcorpan> | teh other sections in introduction more so |
| 13:01 | <zcorpan> | Hixie: ^ |
| 13:54 | <annevk> | why is the translate feature not aided by e.g. making <kbd> and <code> get translate=no by default? |
| 13:57 | <zcorpan> | no automatic translator skips <kbd> and <code> currently, afaik |
| 14:05 | <hsivonen> | so much email. so little code written. :-( |
| 14:07 | <annevk> | it's pretty bad |
| 14:07 | <annevk> | even after dropping out of www-style |
| 14:11 | <MikeSmith> | hsivonen: you can have one or the other |
| 14:11 | <MikeSmith> | after several days of doing validator hacking, I come back to my inbox to find ~1500 messages |
| 14:18 | <MikeSmith> | I don't know how you guys that a real full-time coders manage to keep up with e-mail |
| 14:20 | <wilhelm_> | I mostly ignore it and hope it goes away. |
| 14:22 | <annevk> | hope haha |
| 14:23 | <Velmont> | I read it, but I have to stop that, I haven't been able to do much today after not reading email during FOSDEM and not on monday. |
| 14:24 | <annevk> | I manage to keep up with html5.org/tools/web-apps-tracker |
| 14:24 | <annevk> | and some of the email related to specs I edit |
| 14:24 | <annevk> | other than that, mwaha |
| 14:25 | <annevk> | why is WordPress complaining about my out of date Opera installation? |
| 14:25 | <Velmont> | annevk: I didn't find the subscribe to email-part of that one... |
| 14:25 | <annevk> | shouldn't Opera do that? |
| 14:25 | <annevk> | amusing |
| 14:34 | <annevk> | because the world needs more Java: http://www.w3.org/TR/2012/WD-WebIDL-Java-20120207/ |
| 14:35 | <hsivonen> | annevk: who is implementing that? Batik? |
| 14:36 | <annevk> | nobody |
| 14:36 | <annevk> | it's intended to be a Note |
| 14:52 | <jgraham> | hsivonen: I am interested to know whether you think that it is specifically the *image* part of the RWD thread that is not a problem worth solving or the general idea that one might like to serve device-specific content without an extra RTT |
| 14:53 | <jgraham> | Where by "device" I might mean a number of things like "screen size (in solid angle)" or "power source" |
| 15:07 | <AryehGregor> | Velmont, no, it worked fine for me first try. |
| 15:08 | <hsivonen> | jgraham: at this time, I'm not saying that any particular part of RWD isn't worth solving |
| 15:08 | <hsivonen> | jgraham: however, considering my own experience as a user, any RWD-related thread tends to have bogus assumptions on the part of authors |
| 15:09 | <hsivonen> | I browse the Web on a HD TV, on a phone, on a tablet, on desktop |
| 15:10 | <hsivonen> | I don't like it that sites assume device px == CSS px on any of these |
| 15:10 | <wilhelm_> | Yikes. The vendor prefixes discussion is … interesting. |
| 15:10 | <hsivonen> | I assume wilhelm_ is referring to http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html |
| 15:10 | <wilhelm_> | Yes. |
| 15:11 | <hsivonen> | jgraham: I particularly don't like it when a site decides to give me fewer news items on their front page on a tablet than on desktop |
| 15:11 | <hsivonen> | jgraham: also, my phone has as much bandwidth (at least in theory) as my office had in 2007 |
| 15:12 | <hsivonen> | jgraham: and people were OK with sending me bits in 2007 |
| 15:13 | <zewt> | phones (in the US, anyway) are almost always on bandwidth quotas, though I doubt that's something they're actually thinking about |
| 15:13 | <hsivonen> | zewt: I don't want the Web platform to be designed to the bugs of the U.S. |
| 15:13 | <zewt> | (externality) |
| 15:14 | <zewt> | hsivonen: too bad, you're stuck with us :) |
| 15:14 | <jgraham> | hsivonen: It probably has worse latency though |
| 15:14 | <jgraham> | In any case it seems to be accepted as OK that app-store apps for iPhone vs Desktop mac should be very different in terms of UI conventions + etc. |
| 15:14 | <zewt> | can whoever came up with google's "new look" be banned for life from creating UIs |
| 15:15 | <jgraham> | So it doesn't seem unreasonable for people to want the same for apps that happen to be implemnted on the web |
| 15:15 | <zewt> | jgraham: native apps follow native conventions; web apps (as a convention) generally don't, so I don't know if that's a meaningful comparison |
| 15:15 | <hsivonen> | jgraham: RWD threads tend to be about the size of photos |
| 15:16 | <jgraham> | hsivonen: I am not that intersted in the size of photos :) |
| 15:16 | <hsivonen> | jgraham: apps send a bunch of JS can match media queries all they want |
| 15:16 | <jgraham> | zewt: Right, but that is because the design needs of the different formats are very different |
| 15:17 | <jgraham> | hsivonen: But then you have to deal with extra latency or doing the wrong work |
| 15:17 | <zewt> | jgraham: no; Android and iPhone apps have different conventions, even though the devices are nearly identical |
| 15:17 | <hsivonen> | jgraham: also, UA strings now reveal desktop vs. phone vs. tablet, so you can adapt app interaction model on the same level of granularity as in the iUniverse |
| 15:17 | <jgraham> | zewt: But my example was OSX vs iOS |
| 15:17 | <zewt> | so? |
| 15:17 | <jgraham> | hsivonen: I am not that happy when the "right answer" is UA sniffing |
| 15:18 | <jgraham> | Because that has never ended well |
| 15:18 | <hsivonen> | "plinss: I think the fact that Mozilla is discussing this publicly is harmful." |
| 15:18 | <zewt> | native apps generally follow the conventions of the platform, whether that's iOS, Android, OSX or Windows; web apps don't |
| 15:18 | <hsivonen> | jgraham: I'm not, either. Is there a media query for touch yet? |
| 15:19 | <jgraham> | zewt: My point is that the different conventions between iOS and OSX are to do with meaningful differences in the abilities of the devices. It is not arbitary decisions like iOS vs Android |
| 15:19 | <jgraham> | hsivonen: No idea |
| 15:20 | <zewt> | just saying that the fact that it's accepted that iPhone vs OSX apps will look different doesn't necessarily imply web pages are expected to be different |
| 15:20 | <zewt> | jgraham: it's the "accepted as OK" part I'm talking about--user expectations--not what possibly should be |
| 15:21 | <zewt> | valid reasons to do things differently on desktop+keyboard+mouse vs. handheld+touch, yes, of course |
| 15:24 | <zewt> | (personally I'd do that with a simple loader that stores a cookie the first time the user visits a site and reloads--the whole "describe everything in an HTTP header" thing is just silly) |
| 15:28 | <hsivonen> | "sylvaing: The people who think prefixing is a good feature, majority of them are in this room." |
| 15:29 | <zewt> | ... i'm not in that room, whatever room it is; obviously prefixing is a good feature |
| 15:29 | <zewt> | (it's prefixing things *forever* that's bad) |
| 15:30 | <TabAtkins_> | Yup. Which is why we landed on this new horrible-but-necessary idea. |
| 15:30 | <zewt> | (well, for JS; for CSS, I might be convinced otherwise, since writing identical CSS lines 3-4 times gets old) |
| 15:30 | <zewt> | what "idea"? heh |
| 15:31 | <wilhelm_> | Is there any consensus on what to do with new, experimental, vendor-specific CSS properties? |
| 15:32 | <hsivonen> | I'm disappointed but not suprised by the stances taken by the chairs in that discussion |
| 15:32 | <zewt> | that's exactly where vendor prefixes are ideal. hard to imagine anyone would debate *that* ... |
| 15:32 | <ksweeney> | if you like them, use them. that's how they become standard. |
| 15:32 | <annevk> | chairs should be neutral |
| 15:32 | <jgraham> | One of the several problems with prefixing is that it's the very antithesis of the Open Web ideal. It makes it trivial and attractive to write sites that work in high-marketshare browsers and fail in equally capable low-marketshare browsers. |
| 15:33 | <hsivonen> | annevk: yeah, right |
| 15:33 | <TabAtkins_> | zewt: For a limited (and to-be-determined) set of properties, all the browsers want to support the -webkit- prefix. |
| 15:33 | <jgraham> | annevk: hahahaha |
| 15:33 | <wilhelm_> | annevk: That's… difficult. (c: |
| 15:33 | <annevk> | just saying |
| 15:33 | <TabAtkins_> | Specifically on mobile. |
| 15:34 | <TabAtkins_> | On account of our effective monoculture that's making it too hard to break into decent mobile marketshare. |
| 15:34 | <hsivonen> | TabAtkins_: It's a problem on desktop, too |
| 15:34 | <annevk> | http://www.w3.org/Guide/chair-roles |
| 15:34 | <annevk> | 'Generally stays neutral in discussion but can participate in technical discussions if announces in advance that will remove his or her chair "hat" at that time.' |
| 15:34 | <TabAtkins_> | hsivonen: The discussion yesterday suggested that mobile was the only place where it mattered enough to swallow this pill. |
| 15:35 | <annevk> | art is pretty good at that |
| 15:35 | <ksweeney> | (For more information, see: agenda, hidden) |
| 15:35 | <zewt> | TabAtkins_: that sounds like effectively deprefixing those properties, and giving them a name that just happens to begin with -webkit- |
| 15:36 | <zcorpan> | i'm happy with what was RESOLVED |
| 15:37 | <hsivonen> | is Florian on Twitter? |
| 15:37 | <karlcow> | annevk: it's why it is called "The Art of Chairing" |
| 15:39 | <annevk> | :) |
| 15:39 | <zewt> | :| |
| 15:39 | <annevk> | hsivonen: @frivoal but not active |
| 15:40 | <hsivonen> | annevk: thanks |
| 15:41 | <zcorpan> | whatever comes out of the <picture> discussion, i sure hope we don't add any more alt="" attributes |
| 15:41 | <zewt> | <picture>? i don't think i want to know, heh |
| 15:41 | <jgraham> | Everyone loves @alt! |
| 15:41 | <jgraham> | It's almost as good as @longdesc! |
| 15:42 | <zcorpan> | don't go there! |
| 15:42 | <zewt> | the primary purpose of alt seems to be to make validators yell at authors, who them ignore it |
| 15:43 | <TabAtkins_> | zewt: The idea is to do this at the same time as you do an unprefixed version. So then yes, it becomes an alternate way to express an unprefix, basically. |
| 15:43 | <zcorpan> | <picture alt="potato"> <img alt="potato" longdesc=potato.html src=1> <source alt="huge potato" longdesc=hugepotato.html src=2> <source alt="tiny, cropped potato" longdesc=tinypotato.html src=3> |
| 15:44 | <TabAtkins_> | zewt: No, alt is great. It's actually done *really well* for me several times, when an image has gone missing but its alt still serves the same purpose. |
| 15:44 | <TabAtkins_> | On my old company's site. |
| 15:44 | <jgraham> | TabAtkins_: It is horrible design though |
| 15:45 | <jgraham> | <image>Alt text here</image> was the way to go |
| 15:45 | <TabAtkins_> | jgraham: Oh god, yes, of course. |
| 15:45 | <TabAtkins_> | It's the worst design ever. But the feature is actually quite useful, contrary to what zewt said. |
| 15:45 | <zewt> | didn't say it wasn't useful. |
| 15:47 | <TabAtkins_> | You said the primary purpose was to do something that authors will ignore. I assumed that meant you found it not useful. |
| 15:48 | <zewt> | if I meant it was the only purpose, I'd have omitted "primary" :) |
| 16:08 | <smaug____> | TabAtkins: why doesn't webkit remove webkit prefixed css properties? |
| 16:09 | <smaug____> | remove/replace with non-prefixed |
| 16:10 | <jgraham> | smaug____: Because it turns out that people depend on it! Who would have though! |
| 16:10 | <jgraham> | +t |
| 16:10 | <Velmont> | Well, people never get the chance to fix things because everyone is always so scared to break stuff though... |
| 16:10 | <smaug____> | sure, but doing it in few steps |
| 16:11 | <smaug____> | first warn for some time |
| 16:11 | <smaug____> | and then remove |
| 16:14 | <TabAtkins_> | smaug____: What jgraham said. There's tons and tons of content on the mobile web that use only -webkit- prefixes on properties that are important for their display/layout. |
| 16:14 | <TabAtkins_> | There's enough of it that the significant fraction that will never be updated is too much. |
| 16:14 | <TabAtkins_> | And there's too many to evangelize the problem away - all the browsers have tried and acknowledged failure. |
| 16:14 | <smaug____> | TabAtkins: has it even been tried ? |
| 16:15 | <TabAtkins_> | smaug____: We know from observation that it will very likely cause serious problems. |
| 16:15 | <TabAtkins_> | And the other browsers (who brought the issue to the WG) believe the same. |
| 16:15 | <smaug____> | TabAtkins: has webkit browsers warned about deprecated css properties ? |
| 16:15 | <smaug____> | s/has/have/ |
| 16:15 | <smaug____> | ever |
| 16:16 | <smaug____> | just to try how it work |
| 16:16 | <jgraham> | smaug____: Where would you do that in an app store app that embeds a webkit view? |
| 16:16 | <TabAtkins_> | I don't know. Don't think so. However, Luke Macpherson and I will suggest doing precisely that when we get back to our offices. |
| 16:16 | <smaug____> | jgraham: app store is not web |
| 16:16 | <TabAtkins_> | jgraham: app store apps aren't viewable in other browsers anyway. |
| 16:17 | <jgraham> | Right, so you have to keep the prefixes working at least in that context |
| 16:17 | <jgraham> | You could make them not work in normal web content though |
| 16:17 | <jgraham> | Anyway the fundamental problem is that the model is broken |
| 16:17 | <smaug____> | I don't care what happens in walled gardens |
| 16:18 | <jgraham> | And broken in a dangerous way |
| 16:18 | <smaug____> | the model is very broken |
| 16:18 | <TabAtkins_> | The WG as a whole disagrees. |
| 16:18 | <smaug____> | it wouldn't be so broken if vendors were more willing to remove prefixes |
| 16:19 | <TabAtkins_> | I would like to remove them more, yes. |
| 16:19 | <jgraham> | TabAtkins_: The WG as a whole is composed both theorists and people who benefit from the brokenness |
| 16:20 | <jgraham> | (as well as people for whom it is a serious problem) |
| 16:20 | <TabAtkins_> | jgraham: Dude, the people for whom it's a serious issue are among the ones that believe the prefixing model is still fundamentally sound. |
| 16:20 | <TabAtkins_> | And that the current problem is caused by a particular, preventable failure case. |
| 16:21 | <jgraham> | In what way is it particular, or preventable? |
| 16:21 | <TabAtkins_> | (Which is allowing a popular, interoperable feature to stay in WD for an extended period of time because the editors didn't drive it forward themselves.) |
| 16:22 | <TabAtkins_> | Had the WG been paying appropriate attention, the troublesome specs would have been picked up by another editor at least a year ago, polished up, and taken to CR so prefixes can drop. |
| 16:22 | <TabAtkins_> | We are now alerted to this problem. |
| 16:23 | <jgraham> | That way of viewing it assumes that the fundamental model is sound |
| 16:23 | <Velmont> | I really haven't heard much opposition to doing -draft3-foobar prefixing though. That would mitigate stuff a bit. Where the specs are responsible to update their -draft- version at each milestone where there is potential breakage etc. |
| 16:24 | <TabAtkins_> | Velmont: Nearly the entire WG disagrees with it for fundamental technical reasons. |
| 16:24 | <TabAtkins_> | Namely, that it doesn't solve the problems at hand at all, and introduces the potential for exciting new types of problems. |
| 16:25 | <TabAtkins_> | jgraham: Sure. Which we do. |
| 16:25 | <jgraham> | It seems to me that the -draftFoo- scheme makes the situation very clear |
| 16:25 | <jgraham> | If it turns out that everyone is using -draft3- and it is needed for webcompat you implement -draft3- in your engine |
| 16:26 | <smaug____> | important thing is to have the prefixes live short time enough, so that no one can rely on them to be there always |
| 16:26 | <TabAtkins_> | smaug____: Yup, exactly. |
| 16:26 | <jgraham> | smaug____: Totally never going to happen |
| 16:26 | <jgraham> | The market dynamics just don't work liek that |
| 16:26 | <TabAtkins_> | jgraham: That doesn't solve anything except make people happier that the frozen prefix isn't the string "-webkit-". |
| 16:26 | <jgraham> | But if you believe they do, I have XHTML 2 to sell you |
| 16:27 | <jgraham> | TabAtkins_: It allows the WG to stop wasting time on -draft4- because it is clear that -draft3- was good enough for authors |
| 16:27 | <smaug____> | adding -webkit-* to other engines would break pages |
| 16:27 | <Velmont> | That's correct. But using -draft- will also make it less cool for engines to tug onto it. For marketing and whatnot. |
| 16:27 | <smaug____> | -webkit-* are used for browser engine detection |
| 16:27 | <jgraham> | smaug____: Evidence suggests otherwise |
| 16:28 | <smaug____> | IIRC adding support for certain -webkit-* properties breaks for example Angry Birds |
| 16:28 | <smaug____> | I mean, you get totally non-working page |
| 16:28 | <Velmont> | smaug____: A little breakage in exchange for a whole lot of new workable sites. |
| 16:28 | <smaug____> | without -webkit-* you at least get some warning |
| 16:31 | <jgraham> | Anyway: there is no incentive for browsers to remove prefixes. They is no incentive for authors not to use them, *particularly* on sites where the market is already unheathily unbalanced. The people who lose out most are end users. None of these facts is going to change. |
| 16:31 | <jgraham> | s/sites/platforms/ |
| 16:33 | <zewt> | perhaps, but that doesn't mean the benefits of them aren't still present |
| 16:33 | <smaug____> | jgraham: the incentive to remove prefixes is to make web APIs better |
| 16:34 | <jgraham> | smaug____: Like I said there is no incentive to remove prefixes. |
| 16:34 | <jgraham> | Indeed people will quite reaonably argue that APIs that change all the time are *worse* |
| 16:34 | <jgraham> | *reasonably |
| 16:35 | <zewt> | ("people will", but not you? heh) |
| 16:35 | <smaug____> | I'm quite disappointed if browser developers don't want to make APIs better |
| 16:35 | <smaug____> | jgraham: we're breaking DOM APIs all the time |
| 16:36 | <jgraham> | smaug____: We break DOM APIs very, very cautiously |
| 16:36 | <zewt> | ... once they're unprefixed |
| 16:36 | <smaug____> | no really |
| 16:36 | <jgraham> | smaug____: What did you have in mind? |
| 16:36 | <smaug____> | isSameNode is one thing |
| 16:37 | <smaug____> | disabling sync XHR in some cases is another one |
| 16:37 | <jgraham> | zewt: Hardly any DOM APIs have ever had a significant amount of content depending on a prefix |
| 16:38 | <zewt> | smaug: and those were done cautiously |
| 16:38 | <jgraham> | smaug____: I thought there was a reason that isSameNode wasn't going to fly. But in any case that is a almost-never-used method |
| 16:38 | <zewt> | smaug: both expecting very few sites to be affected, afaik |
| 16:38 | <jgraham> | sync-XHR we piggybacked onto another change; we didn't make the API better by disallowing syc XHR altogether |
| 16:38 | <smaug____> | jgraham: isSameNode was removed from the spec and from Gecko, and some sites broke |
| 16:38 | <jgraham> | even though we would all have liked to |
| 16:39 | <smaug____> | jgraham: sure we're making sync XHR better |
| 16:39 | <smaug____> | my aim is to remove it at some point in window context |
| 16:39 | <smaug____> | it may take long time |
| 16:40 | <jgraham> | smaug____: Yeah I'll get back to you in a few decades on that one |
| 16:40 | <smaug____> | I don't understand why it couldn't be removed like in 5 years |
| 16:40 | <jgraham> | Because people will still depend on it in 5 years |
| 16:41 | <smaug____> | not if browsers start to warn about it like now |
| 16:41 | <zewt> | if developers actually heed warnings |
| 16:41 | <jgraham> | Also, while I think it is very noble that Gecko are prepared to leverage their desktop market share to try and improve the platform, they can't really do the same on mobile |
| 16:41 | <zewt> | whether they would or not for browser APIs i think isn't known; i've never actually seen it tried (though for sure not *everyone* would) |
| 16:42 | <smaug____> | jgraham: indeed. I'm hoping webkit could do some good work on mobile |
| 16:42 | <zewt> | i still think that browsers should switch to sans serif or play show tunes or something when bad, obsolete APIs are used |
| 16:42 | <zewt> | lsdkjf |
| 16:42 | <zewt> | comic sans |
| 16:42 | <jgraham> | Anyway, the point is this is a very slow, cautious process |
| 16:43 | <smaug____> | the fact that removing bad APIs is possibly slow doesn't mean we shouldn't try to do it |
| 16:43 | <jgraham> | It is not like the CSSWG inventing brand new syntax after prefixed ones have become so widespread as to be unremovable |
| 16:43 | <jgraham> | and required for site-compat |
| 16:43 | <jgraham> | *that* is the problem |
| 16:44 | <zewt> | smaug____: we should try, but I think there's no indication that it's even possible to remove entrenched things like sync xhr |
| 16:44 | <jgraham> | That they look at The Process when making decisions rather than deployed reality |
| 16:44 | <Ms2ger> | Maybe people should start unprefixing stable stuff even if Tab doesn't like them |
| 16:44 | smaug____ | has spent too much time in the garden. A year is a short time there... a tree might start to look interesting in a decade |
| 16:45 | <zewt> | i don't think it matters how you warn or how slowly you go, the existing content using it probably will never go away |
| 16:45 | <zewt> | but I won't say not to try :) |
| 16:45 | <Ms2ger> | Sure will |
| 16:45 | <smaug____> | old code does go away |
| 16:45 | <Ms2ger> | Imagine how much cruft we can remove now geocities died :) |
| 16:45 | <zewt> | some does, much doesn't |
| 16:45 | <smaug____> | web pages designed for NS4 sure don't work in any browser |
| 16:46 | <zewt> | it would be a little interesting to see graphs for that |
| 16:46 | <jgraham> | Geocities didn't die it just moved |
| 16:46 | <zewt> | how much old code on the web eventually gets removed or rewritten, and how much is written once and is then used untouched for a decade |
| 16:46 | <jgraham> | http://reocities.com/ |
| 16:46 | <ksweeney> | jgraham, moved into a 4GB zip file on bittorrent you mean? ;) |
| 16:47 | <ksweeney> | hm…or was it TB |
| 16:48 | <Ms2ger> | And of those pages that have been untouched for a decade, does anybody visit them? |
| 16:49 | <jgraham> | Ms2ger: Well people cared enough to save the geocities content. And people use teh wayback machine |
| 16:50 | <Ms2ger> | I suspect people cared about geocities because of memories, more than because they actually look at those sites |
| 16:51 | <jgraham> | Pretty sure karlcow would have something to say about that line of reasoning. |
| 16:52 | <karlcow> | :) |
| 17:06 | <hsivonen> | Velmont: http://hsivonen.iki.fi/vendor-prefixes/#draftprefix |
| 17:13 | <TabAtkins_> | Ms2ger: I've had to use reocities to look at an old geocities site for the purpose of writing a standard before |
| 17:14 | <TabAtkins_> | And I was sad that some of the images weren't preserved. ;_; |
| 17:15 | <TabAtkins_> | Ms2ger: I'm, um, not the one holding back people from unprefixing. |
| 17:16 | <TabAtkins_> | Ms2ger: The people holding that back for each browser are the ones *in* the WG. |
| 17:17 | <Ms2ger> | For gradients, I'd argue you did stop people from prefixing by rewriting the spec so many times |
| 17:20 | <hsivonen> | TabAtkins_: when you revamp the syntax of something under the pretext that it's ok, because it's prefixed today, you validate the point of view of people who say prefixing is good, because the syntax ended up changing |
| 17:21 | <hsivonen> | TabAtkins_: even if grammar-incompatible revamping doesn't truly validate their position |
| 17:23 | <jgraham> | My point of view is that on the web there are two options: 1) "don't ship" 2) "ship and make any future changes sensitive to the legacy established by shipping". Acting like there is an option 3) "Ship and then make backwards incompatible changes justified by the fiction that the legacy doesn't exist because it has a funny name" is just delusion. |
| 17:23 | <Ms2ger> | ... that the IETF and the CSSWG get away with |
| 17:25 | <jgraham> | The IETF eventually got away with it for websockets because there really wasn't so much legacy and it wasn't that hard to make the transition painless (a server could support both the old and new protocols) |
| 17:25 | <jgraham> | (and there were no client side API changes) |
| 17:25 | <jgraham> | The CSSWG haven't got away with it |
| 17:25 | <jgraham> | That's why we're having this discussion |
| 17:29 | <hsivonen> | jgraham: http://hsivonen.iki.fi/vendor-prefixes/#whattodo is based on a belief that option 3 is bogus |
| 17:33 | <hsivonen> | sigh. http://lists.w3.org/Archives/Public/www-style/2012Feb/0352.html |
| 17:43 | <AryehGregor> | So it looks like no browser actually allows things to intersect in 3D space. |
| 18:51 | <bga> | > iekit6 |
| 18:51 | <bga> | lol |
| 20:25 | <gsnedders> | Hixie, TabAtkins: So my google account (geoffers) got disabled with standard "common reasons inc. ToS violations" message. Any chance either of you could ping anyone? |
| 20:26 | <smaug____> | gsnedders: huh |
| 20:26 | <smaug____> | just give up with Google ? :) |
| 20:26 | <gsnedders> | In other news it turns out Android sucks without a working Google account. |
| 20:27 | <nimbu> | gsnedders: really? I go by fine as long as I dont use the native apps :) |
| 20:28 | <gsnedders> | nimbu: Market is nice, and having contacts synced between devices is nice. |
| 20:29 | <wilhelm_> | gsnedders: Stop violating ToS, then! |
| 20:29 | <gsnedders> | wilhelm_: In what way!? |
| 20:29 | <Hixie> | gsnedders: wtf did you do? |
| 20:29 | <gsnedders> | I haven't even sent an email from my Gmail account in a month or so! |
| 20:30 | <gsnedders> | Hixie: Dunno. Haven't sent an email in a month, try to login this morning and get error. :\ |
| 20:30 | <gsnedders> | And I've not touched + in ages, nor done anything apart from edit contacts which are syned… |
| 20:30 | <Hixie> | is there no link for escalation in the message? |
| 20:31 | <gsnedders> | There is, but no guarantee of a response or anything. |
| 20:31 | <Hixie> | use that mechanism |
| 20:31 | <Hixie> | let me know if it doesn't work |
| 20:31 | <gsnedders> | Hixie: Over what time-span? |
| 20:31 | <bga> | gsnedders i have 4 or 5 google accounts but google dont know about that |
| 20:32 | <Hixie> | gsnedders: keep me updated every 24 hours :-) |
| 20:32 | <Hixie> | gsnedders: do you use any of our ads products? |
| 20:32 | <gsnedders> | Hixie: No |
| 20:32 | <Hixie> | gsnedders: did you have two-factor authentication enabled? |
| 20:33 | <gsnedders> | Hixie: I don't *think* so. |
| 20:34 | <Hixie> | gsnedders: was your password easy to brute force? (e.g. dictionary word, numeric, or short) |
| 20:34 | <Ms2ger> | Or "hunter2"? |
| 20:35 | <nimbu> | hahah wilhelm_ :D |
| 20:35 | <gsnedders> | Hixie: No. |
| 20:35 | <nimbu> | gsnedders: yeah I barely use my phone other than for calls. :) |
| 20:35 | <Hixie> | gsnedders: hm |
| 20:36 | <Hixie> | gsnedders: can you paste the exact message you're getting? |
| 20:37 | <gsnedders> | http://support.google.com/accounts/bin/answer.py?hl=en&p=profiles&ctx=ch_ServiceLoginAuth&answer=40695 |
| 20:38 | <Hixie> | ok go through the "contact us" flow from that page and let me know if you don't hear back in 24 hours |
| 20:38 | <Hixie> | (it might take longer than that, but let's start there) |
| 20:38 | <gsnedders> | Sent a thing there 9ish hours ago |
| 20:39 | <Hixie> | k |
| 20:43 | <Hixie> | gsnedders: have you used any of our photo sharing or video sharing products? (youtube, picasa, panoramio, blogger, etc) |
| 20:43 | <gsnedders> | Hixie: no |
| 20:43 | <Hixie> | k |
| 20:44 | <Hixie> | ever logged in to your account from an internet cafe or other untrusted computer? |
| 20:44 | <gsnedders> | Hixie: Uni computers, but that's as untrusted as it gets. |
| 20:45 | <gsnedders> | (I'd be dubious if anything came off them, though) |
| 20:45 | <Hixie> | how untrusted are those? any chance of a keylogger? |
| 20:45 | <gsnedders> | I'd be really quite surprised. |
| 20:46 | <gsnedders> | Certainly not heard of anything like that. |
| 20:46 | <gsnedders> | And the setup is decent. |
| 20:46 | <Hixie> | hmm k |
| 20:47 | <gsnedders> | (And given the network setup, you'd be hard pushed to get much data out) |
| 20:48 | <Hixie> | do you have an android phone, or an iphone with the google+ app? |
| 20:48 | <gsnedders> | (and local storage is re-imaged daily (or maybe even per login?) so you couldn't get much there for long) |
| 20:48 | <gsnedders> | Hixie: Android phone |
| 20:49 | <Hixie> | does it use the same account? |
| 20:50 | <gsnedders> | Yeah |
| 20:50 | <Hixie> | do you have the g+ app with photo upload enabled? |
| 20:50 | <gsnedders> | Yes and only if it's the default. |
| 20:51 | <Hixie> | not the default |
| 20:51 | <gsnedders> | (Certainly photos aren't uploaded by default?) |
| 20:51 | <Hixie> | hmm |
| 20:51 | <gsnedders> | And nobody's got at my phone, either. |
| 20:51 | <Hixie> | (btw that feature is awesome, you should totally use it if you get the chance) |
| 20:52 | <Hixie> | i can't see what it could be |
| 20:53 | <Hixie> | let me know if they haven't replied by tomorrow |
| 20:55 | <gsnedders> | Hixie: k |
| 22:21 | <jamesr_> | gsnedders, maybe your uni is different than mine, but i wouldn't trust computers at my uni at all for logging in (not that it ever stopped me) |
| 23:47 | <Hixie> | zcorpan pointed me to some spam on the status annotations, so i poked around a bit |
| 23:47 | <Hixie> | and cleared out the obvious spam |
| 23:47 | <Hixie> | yay for having a database that logs every single change and trivially lets me roll back specific changes |
| 23:47 | <Hixie> | my favourite was that #background had the following test: http://www12.0zz0.com/2012/02/07/10/492179392.jpg |
| 23:54 | <nessy> | lol |
