| 00:08 | <eric_carlson> | Hixie: ping? |
| 01:37 | <JonathanNeal> | Why does <address> only scope to <article> but not other sectioning content? http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-address-element |
| 04:02 | <Hixie> | eric_carlson: here |
| 04:43 | <eric_carlson> | Hixie: if <track>.kind is changed from a known to an unknown value, what should <track>.track.kind return? |
| 04:43 | <Hixie> | same as if it started with an unknown value, i hope |
| 04:43 | <Hixie> | but let me check what the spec says |
| 04:56 | <eric_carlson> | Hixie: that is what I assumed logically, but I wasn't sure from the spec text |
| 05:13 | <Hixie> | eric_carlson: so it looks like "text track kind" is defined from the current attribute value here: http://www.whatwg.org/specs/web-apps/current-work/#sourcing-out-of-band-text-tracks |
| 05:14 | <Hixie> | eric_carlson: and track.kind is defined in terms of "text track kind" here: http://www.whatwg.org/specs/web-apps/current-work/#dom-texttrack-kind |
| 05:15 | <Hixie> | eric_carlson: so yeah, whenever the content attribute is invalid or missing, the DOM attribute will return "subtitles" |
| 05:15 | <eric_carlson> | Hixie: great, thanks for the confirmation! |
| 05:15 | <Hixie> | np |
| 08:47 | <hsivonen> | does yandex.ru offer @yandex.ru email to its users like @yahoo.com emails are user emails? |
| 08:48 | <hsivonen> | unlike @google.com emails |
| 08:53 | <Philip`> | hsivonen: http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fpassport.yandex.ru%2Fpassport%3Fmode%3Dregister - "Usename: [ ] @ Yandex.ru" - looks like it |
| 08:56 | <hsivonen> | Philip`: ok. thanks |
| 09:01 | <hsivonen> | hmm. Roy T. Fielding is the editor of the W3C DNT spec: http://www.w3.org/TR/2011/WD-tracking-dnt-20111114/ |
| 09:01 | <hsivonen> | I'm a bit surprised. I had no idea he worked on that stuff. |
| 09:01 | <Dashiva> | I know why it's called DNT, but "Tracking Preference Expression (DNT)" still looks silly |
| 09:03 | <hsivonen> | hmm. the IDL isn't [Supplemental] |
| 09:04 | <Philip`> | Dashiva: Doesn't seem much sillier than the European Organization for Nuclear Research (CERN) |
| 09:04 | <hsivonen> | might be a good idea for someone who knows WebIDL better than I do to check the implements/supplements situation of the DNT spec |
| 09:05 | <hsivonen> | Philip`: or UTC |
| 09:06 | <hsivonen> | while I realize there's the UTx pattern, UTC looks like a compromise between English and French by choosing a permutation that makes sense for neither |
| 09:17 | <heycam> | hsivonen, I think what's there works |
| 09:18 | <heycam> | hsivonen, though I think people prefer the shorter "partial interface Navigator { ... }" these days |
| 09:23 | <Ms2ger> | Yeah |
| 09:23 | <Ms2ger> | That's a respecism, I think |
| 09:24 | <hsivonen> | ok |
| 10:46 | <annevk> | oh yes SSID strings just gained meaning |
| 10:47 | <annevk> | http://googleblog.blogspot.com/2011/11/greater-choice-for-wireless-access.html |
| 11:01 | <Philip`> | Using "ends with _nomap" as a flag doesn't sound the most highly scalable solution when someone else in the world invents a second SSID flag |
| 11:05 | <hsivonen> | Philip`: they'll just have to accept that their flag might not be the last one |
| 11:05 | <hsivonen> | I wonder what font rasterizer the Google Docs PDF reader uses |
| 11:05 | <annevk> | there's a maximum length of 32 characters |
| 11:06 | <annevk> | it's gonna be fun if there's more flags |
| 11:06 | <hsivonen> | the rasterizer manages to produce the kind of ugliness that's familiar to Windows users, but surely Google isn't running that stuff on Windows |
| 11:06 | <annevk> | is naming your SSID "_nomap" sufficient? |
| 11:07 | <hsivonen> | what's the deal with people freaking out about SSID-based mapping anyway? |
| 11:07 | <hsivonen> | what's the model of threat to privacy? |
| 11:09 | <krijn> | TabAtkins: okay if we publish your #fronteers11 video this week? |
| 11:10 | <hsivonen> | krijn: btw, I occasionally see an old snapshot of http://krijnhoetmer.nl/irc-logs/ in Opera Mini. Did you change caching headers? Did Opera make their caching over-aggressive? What has happened? |
| 11:11 | <krijn> | Old as in a day old? |
| 11:11 | <hsivonen> | krijn: yes |
| 11:12 | <Philip`> | hsivonen: You might move to live in a secret new location to evade a stalker/criminal/etc, but would take your wireless router with you, and the stalker/etc could later query Google's access point database to figure out where you are now living |
| 11:12 | <krijn> | hsivonen: that cache is only updated once a day |
| 11:12 | <krijn> | I think |
| 11:13 | <hsivonen> | krijn: ok. it's annoying not to find the link to the latest log there from time to time |
| 11:13 | <hsivonen> | Philip`: ok. that's a reasonable use case |
| 11:14 | <Philip`> | Or you might carry an access point around with you (as an ad-hoc network or 3G-wifi-bridge thing) and people could discover where you had been in the past |
| 11:15 | <hsivonen> | Philip`: that's a reasonable use case, too |
| 11:16 | <Philip`> | Or you might just be paranoid and hate Google |
| 11:16 | <krijn> | hsivonen: it should update around 00:15 CET each day |
| 11:17 | <krijn> | Ah, I see, yeah, if there's no activity in a channel in those 15 minutes, the log isn't created yet |
| 11:29 | <hsivonen> | krijn: can that be fixed easily? |
| 11:29 | <annevk> | hsivonen: you should bookmark /irc-logs/whatwg |
| 11:29 | <annevk> | it redirects to the latest |
| 11:29 | <krijn> | What annevk said |
| 11:29 | <hsivonen> | annevk: I suppose. Back when I set up my Speed Dial, I expected to read #html-wg logs, too, but there's nothing interesting there typically |
| 11:30 | <hsivonen> | krijn: it would be nice to have a link from the log page to the previous log, too |
| 11:31 | <Ms2ger> | annevk, well, that only works if you stay up past midnight |
| 11:32 | <krijn> | hsivonen: yeah, I should build that some day.. Even though the archive is static now |
| 11:34 | <hsivonen> | I updated my Speed Dial using a device with better bookmark management ergonomics. Let's see how long it takes for change to propagate to Opera Mini on the legacy phone |
| 11:46 | <gwicke> | hello, I am trying to find or generate a stand-alone Javascript version of the HTML parser at validator.nu |
| 11:46 | <gwicke> | tried GWT, but did not find any up-to-date pointers on the build process |
| 11:47 | <gwicke> | ideally, I am looking for something less obscured than the GWT-generated one at livedom.validator.nu |
| 11:47 | <annevk> | gwicke: http://www.davidflanagan.com/2011/10/html-parsing-wi.html |
| 11:48 | <gwicke> | annevk: thanks!! reading.. |
| 11:49 | <hsivonen> | gwicke: you need to adapt the HtmlParser-compile-detailed script or the HtmlParser-compile-detailed.launch Eclipse launch setup to the path on your system and the details of your GWT version |
| 11:50 | <gwicke> | hsivonen: I did not see those in the tarball |
| 11:50 | <hsivonen> | gwicke: it's in the hg repo |
| 11:51 | <gwicke> | oh- only found an old svn one so far |
| 11:51 | <hsivonen> | https://hg.mozilla.org/projects/htmlparser/ |
| 11:52 | <hsivonen> | gwicke: where was the link to the old svn repo? |
| 11:52 | <gwicke> | http://wiki.whatwg.org/wiki/Validator.nu_parser |
| 11:53 | <gwicke> | hsivonen: and thanks for the hg location! Did not find it at http://about.validator.nu/htmlparser/ |
| 12:00 | <hsivonen> | gwicke: thanks. I fixed both pages |
| 12:02 | <hsivonen> | mattur's email archeology is awesome: https://twitter.com/#!/mattur/status/136411627695251456 |
| 12:02 | <gwicke> | hsivonen: it looks like David's parser might be better for my needs, but if I succeed in generating the JS through GWT I'll send you a script that is adapted to Debian |
| 12:02 | <hsivonen> | gwicke: ok |
| 12:03 | <hsivonen> | I feel that I now have to try the optimizations that David didn't try before he proceeded with a new implementation |
| 12:03 | <annevk> | hsivonen: RT'd that from @WHATWG :) |
| 12:03 | <hsivonen> | annevk: good |
| 12:08 | <annevk> | hmm |
| 12:08 | <annevk> | merging fullscreen and dialog |
| 12:08 | <annevk> | for styling anyway |
| 12:08 | <annevk> | yikes |
| 12:09 | <hsivonen> | annevk: unintended turn of events! |
| 12:10 | <hsivonen> | annevk: but it does make sense |
| 12:11 | <annevk> | does seem like there's plenty of overlap |
| 12:11 | <annevk> | at least for modal dialogs and fullscreen |
| 12:12 | <hsivonen> | annevk: foresee politics about modal dialogs being an HTML WG issues fullscreen having been discussed in the WHATWG |
| 12:14 | <hsivonen> | it's awesome how crufty the output is default sample document in http://buzzword.org.uk/2010/md2rdfa/ |
| 12:17 | <Ms2ger> | annevk: foresee politics |
| 12:17 | <Ms2ger> | ftfy |
| 12:18 | <gwicke> | hsivonen: I get a lot of messages about annotations not resolving, like java.lang.ClassNotFoundException: nu.validator.htmlparser.annotation.Virtual |
| 12:18 | <gwicke> | but it still seems to work |
| 12:18 | <hsivonen> | gwicke: yeah |
| 12:18 | <gwicke> | ;) |
| 12:18 | <hsivonen> | gwicke: I don't know why the GWT compiler fails to find those |
| 12:19 | <gwicke> | I am not of much help on Java or GWT unfortunately |
| 12:22 | <gwicke> | I added a wildcard classpath (/usr/share/java/*) to make it work, not sure if that is considered good form |
| 12:23 | <hsivonen> | gwicke: make it work in what sense? |
| 12:24 | <gwicke> | to make it find the classes it needs |
| 12:24 | <hsivonen> | gwicke: and the compilation result worked? |
| 12:24 | <gwicke> | libcommons-collections3 and the gwt classes |
| 12:24 | <gwicke> | yes |
| 12:24 | <hsivonen> | gwicke: interesting |
| 12:24 | <gwicke> | will get you a link to pastebin in a moment |
| 12:25 | <gwicke> | http://pastebin.com/rn1csAcq |
| 12:25 | <hsivonen> | there's supposed to be enough stuff under super/ to cover for JDK classes that aren't in GWT |
| 12:26 | <hsivonen> | gwicke: ok. if you include /usr/share/java, distributing the compilation result might violate the license of your JDK impl. YMMV. IANAL. |
| 12:27 | <gwicke> | hrm.. |
| 12:27 | <gwicke> | can try to narrow it down |
| 12:33 | <gwicke> | getting java.lang.NoClassDefFoundError: org/apache/tools/ant/types/ZipScanner |
| 12:37 | <gwicke> | This works without wildcard on Debian unstable: http://pastebin.com/p6bMjmpP |
| 12:51 | <hsivonen> | gwicke: hmm. that must be requirement for the GWT compiler itself |
| 12:53 | <gwicke> | might be- I am not using the prescribed build setup for GWT, which might include additional paths. The gwt packages only list the jre as dependencies. |
| 12:56 | <hsivonen> | gwicke: I might goofed when I included GWT compiler input in -cp |
| 12:56 | <hsivonen> | might have goofed |
| 12:56 | <hsivonen> | interesting developments around schema.org: http://lists.w3.org/Archives/Public/public-html-data-tf/2011Nov/0117.html |
| 13:01 | <gwicke> | hsivonen: if you mean the $APPDIR/* bits, then those seem to be needed |
| 13:01 | <gwicke> | at least it fails to compile if I remove them |
| 13:05 | <hsivonen> | gwicke: there might be some other way to pass those to the compiler only so that the VM running the compiler doesn't see them |
| 13:06 | <gwicke> | ok, will let you know if I find something |
| 13:55 | <Ms2ger> | Btw, Opera guys: not nice that you didn't include a -moz-double-rainbow line |
| 13:56 | miketaylr | files a bug |
| 13:57 | <zcorpan> | we can't know what syntax you're using if it's not supported yet |
| 13:58 | <hsivonen> | do I recall correctly that -webkit-border-radius matched what got standardized? |
| 14:03 | <annevk> | Ms2ger: doesn't matter, we did it first |
| 14:03 | hsivonen | is about to publish a blog post about that |
| 14:03 | <Ms2ger> | annevk++ |
| 14:03 | annevk | thought we were going to keep it a secret easter egg |
| 14:03 | <hsivonen> | prefixes-- |
| 14:04 | <annevk> | hsivonen: I think what got standardized was something I made up that matched exactly nobody |
| 14:04 | <Ms2ger> | annevk, blame karlcow |
| 14:04 | <hsivonen> | annevk: ok |
| 14:04 | <annevk> | I made something up, refined by fantasai, that allowed you to set all longhands using just border-radius |
| 14:04 | <annevk> | nobody had that |
| 14:16 | karlcow | is waiting for a disco-ball extension with rotation speed and shyniness |
| 14:31 | <hsivonen> | I blogged about vendor prefixes: http://hsivonen.iki.fi/vendor-prefixes/ |
| 14:34 | <annevk> | karlcow: fyi, Mozilla is implementing the same API |
| 14:34 | <annevk> | karlcow: I think the mutation stuff is quite settled now |
| 14:41 | <karlcow> | annevk: context? same API? |
| 14:43 | <astearns> | hsivonen: "I think browser vendors should adding more prefixed CSS features" needs a word |
| 14:45 | <jgraham> | "burn in hell for" is four words |
| 14:45 | <jgraham> | </joke> |
| 14:45 | <hsivonen> | astearns: thanks. fixed |
| 14:46 | <karlcow> | "The situation is harmful for Firefox for mobile, Opera Mobile and IE on Windows Phone. Yet, Mozilla, Opera and Microsoft are going along with the prefixing scheme. At one point, Microsoft planned to implement a -webkit-CSS feature for IE on Windows Phone, but people out of principle told them not to and they backed down." |
| 14:46 | <karlcow> | I think we should all implement in our engines a -*- and been done with it. and let the mess happens |
| 14:48 | <annevk> | karlcow: DOM mutations |
| 14:49 | <karlcow> | Aaaaaah |
| 14:49 | <karlcow> | in "The specification contains currently a placeholder on how Mutation Events are implemented in Chrome but this is likely to change again." |
| 14:49 | <karlcow> | ok fixing |
| 14:51 | <karlcow> | thanks annevk |
| 14:59 | <jgraham> | hsivonen: "experimetal" |
| 15:02 | <jgraham> | hsivonen: But generally very nice article |
| 15:08 | <gsnedders> | hsivonen: You are aware we support one -apple- feature relating to widgets? |
| 15:10 | <hsivonen> | gsnedders: no, not aware until now |
| 15:10 | <gsnedders> | -apple-dashboard-region |
| 15:11 | <gsnedders> | http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0007/css_properties.txt was current |
| 15:13 | <gsnedders> | Note also -xv- (XHTML Voice) and -wap- (WAP). |
| 15:23 | <gsnedders> | Also interesting is that Apple are shipping Speex in iOS now. Though the audio side has never been that interesting, given the number of major companies already shipping Vorbis. |
| 15:27 | <zewt> | wow, ff8's addon thing on update is 10x clunkier now |
| 15:30 | <jgraham> | zewt: ? |
| 15:30 | <zewt> | much less streamlined than it used to be |
| 15:31 | <jgraham> | Maybe I don't actually have any addons in my firefox installs but I don't remember noticing that they regressed the UI |
| 15:31 | <zewt> | extension state list made me go woah-way-too-much-info, so i'd expect typical users to give up and just mash "ok" |
| 15:37 | <zewt> | heh err |
| 15:37 | <zewt> | ff8: BlobBuilder now has a getFile() method that returns the content of the blob as a file. |
| 15:37 | <zewt> | ... why? |
| 15:38 | <zewt> | guess i should bring that up in the blob ctor thread (probably implies a File ctor too) |
| 15:46 | <Ms2ger> | karlcow, X-Forwaded-For? |
| 15:53 | <karlcow> | Ms2ger: I typoed? |
| 15:53 | <Ms2ger> | Yep |
| 15:53 | <karlcow> | ah |
| 15:53 | <karlcow> | ForwaRded |
| 15:53 | <karlcow> | heh |
| 15:53 | <karlcow> | fixing |
| 15:53 | <Ms2ger> | Ta |
| 15:56 | <karlcow> | ok in the process of being published again. |
| 15:56 | <karlcow> | Thanks Ms2ger |
| 16:02 | <annevk> | so did Mozilla ship BlobBuilder prefixed? |
| 16:02 | annevk | hides |
| 16:02 | <Ms2ger> | We may have |
| 16:03 | <Ms2ger> | annevk, we did |
| 16:03 | <JonathanNeal> | good morning :) |
| 16:04 | <annevk> | Ms2ger: prolly a good thing :) |
| 16:04 | annevk | will read hsivonen's post later; hopes there's new words |
| 16:07 | <zcorpan> | i'm glad css prefixes didn't end up using namespace URLs at least |
| 16:07 | <JonathanNeal> | I like vendor prefixes, they helped get us this far. |
| 16:08 | <JonathanNeal> | we couldn't have done it waiting around for the spec, the web exists in a state of experiment, but none of that will matter in two years when most browsers update themselves. |
| 16:08 | <jgraham> | JonathanNeal: Everyone loves nothing working on non-webkit mobile browsers |
| 16:09 | <JonathanNeal> | that's the real complaint, isn't it. |
| 16:09 | <jgraham> | Well partially yes |
| 16:09 | Ms2ger | hasn't been convinced that implementing webkit's prefixed junk is the right solution |
| 16:10 | <gsnedders> | JonathanNeal: We have enough problems on desktop too |
| 16:10 | <jgraham> | But the underlying issue is that "best viewed in X browser" wasn't good when it was spelled out on the homepage |
| 16:10 | <jgraham> | It isn't better because it is buried in the CSS |
| 16:10 | <JonathanNeal> | http://css3please.com/ - afaik it has had linear-gradient sitting there. |
| 16:11 | <JonathanNeal> | So anyone using this service, not modifying the code, has just been waiting for other browsers to catch up to what seems to be the standard. |
| 16:11 | <JonathanNeal> | in the meantime, they're benefit from the browsers that do support the feature. |
| 16:12 | <JonathanNeal> | why is benefiting from the early adoption of a browser a bad thing? if the other browsers can't keep up, that seems less webkit's fault and less the author's fault. there was a time a lot of us rolled our eyes because opera had yet to add gradients. |
| 16:13 | <zcorpan> | JonathanNeal: did you read the blog post? |
| 16:13 | <JonathanNeal> | the entire thing |
| 16:14 | <jgraham> | JonathanNeal: The point is not to make people wait |
| 16:14 | <zcorpan> | the problem is with people using only -webkit- and then not updating their pages, then when other browsers implement the feature, it still doesn't work in existing content that uses a single prefix |
| 16:14 | <JonathanNeal> | yea, but i agree with the first counter argument at least. |
| 16:14 | <jgraham> | The point is to solidify around what people ship rather than having a harmful committee-driven Process |
| 16:16 | <JonathanNeal> | hmm, i thought whatwg proved you could work around the harmful committee-driven process. |
| 16:16 | <Philip`> | Experimental features should have timebomb prefixes, like "-moz-expires20120515-foo" which will stop working in Mozilla browsers after the given date, to force authors to update their pages to the standard which should have been released by that time |
| 16:18 | <Ms2ger> | Philip`, yeah, it's called -moz- |
| 16:18 | <jgraham> | Someone suggested making any use of experimental features add a red norification bar to the page |
| 16:18 | <jgraham> | I can't see Google going for it though |
| 16:20 | <Philip`> | Ms2ger: That doesn't make it clear to authors that it'll stop working in the near future, so they'll complain if it ever gets removed, so it'll probably never get removed |
| 16:21 | <Ms2ger> | That doesn't follow |
| 16:21 | <JonathanNeal> | i'm also not crazy about the original webkit gradient implementation. |
| 16:22 | <Ms2ger> | AFAIK, Mozilla has removed support for all the prefixed stuff some time after implementing the unprefixed version |
| 16:22 | <JonathanNeal> | it's really up to the vendors to remove their own prefixes. |
| 16:23 | <JonathanNeal> | including webkit |
| 16:23 | <Ms2ger> | Well, relying on webkit to do what's good for the web... |
| 16:23 | <JonathanNeal> | it really seems like folks are upset webkit is doing so much and it is being adopted so widely. |
| 16:24 | <gsnedders> | I don't think people mind WebKit doing so much: it's when you get so many websites including only webkit prefixes that it hurts other browsers. |
| 16:25 | <gsnedders> | Heck, it's still fairly painful for Opera with border-radius which we've been shipping for years, lots of new content only include -webkit- and -moz- prefixes. |
| 16:25 | <JonathanNeal> | so, we're not blaming webkit for that, right? |
| 16:25 | <Philip`> | People got upset when Microsoft was doing so much (e.g. ActiveX, and DX filters in CSS, and expression(), etc, which wouldn't really work with any other browser implementation) and it got adopted somewhat widely |
| 16:25 | <JonathanNeal> | gsnedders: that surprises me, because authors should prefer to use the prefixless border-radius. |
| 16:26 | <miketaylr> | but they don't |
| 16:26 | <gsnedders> | I don't think there's really that much blame directed at WebKit. |
| 16:26 | <gsnedders> | JonathanNeal: They don't. Most articles on the web talk only about -webkit- and -moz-. |
| 16:26 | <Philip`> | JonathanNeal: I imagine authors use whatever they read in the blog post written about the features in 2006 and not updated since |
| 16:26 | <JonathanNeal> | Philip`: the other browsers came up with a better way to do it, didn't they? |
| 16:26 | miketaylr | had an issue yesterday with orkut.com with only -moz-border-radius and -webkit-border-radius |
| 16:26 | <JonathanNeal> | also, isn't webkits code open, anyone can see how they do it, very unlike ms |
| 16:27 | <gsnedders> | JonathanNeal: Just having the source doesn't mean you can instantly dive in and understand it. |
| 16:27 | <miketaylr> | how does having access to source code help me have a less crappy experience on mobile gmail? |
| 16:27 | <JonathanNeal> | well, the worst thing i see happening that could be the browsers fault is not dumping the old prefixes. |
| 16:27 | <gsnedders> | Heck, even with open source products most people just black-box reverse engineer them. It tends to be quicker. |
| 16:28 | <gsnedders> | JonathanNeal: And they're not going to dump them when huge amounts of content rely upon them. |
| 16:29 | <JonathanNeal> | so your solution is to allow old implementations to exist on the web |
| 16:29 | <JonathanNeal> | but vendor-prefix-less? |
| 16:30 | <gsnedders> | JonathanNeal: I never gave a solution. |
| 16:30 | <jgraham> | There are two situations |
| 16:30 | <jgraham> | a) there is not enough content to have any compat implication |
| 16:30 | <Ms2ger> | Philip`, please do reply to http://www.w3.org/Bugs/Public/show_bug.cgi?id=14421 :) |
| 16:30 | <jgraham> | b) there is enough content to have a compat implication |
| 16:31 | <jgraham> | In case a) there is no problem |
| 16:31 | <JonathanNeal> | what is enough content? |
| 16:31 | <jgraham> | In case b) we currently have the situation where that content will typically remain broken in non-first0implementor browsers forever |
| 16:31 | <zewt> | for one thing, you can't talk about css vendor prefixes and javascript vendor prefixes together--they're separate beasts and the practical annoyance is very different |
| 16:31 | <Philip`> | Ms2ger: Maybe you should remind me in a morning (UTC), then I might avoid other distractions and spend the day dealing with my backlog of canvas things :-) |
| 16:32 | <gsnedders> | Did someone not have a blog-post recently about breaking the web? |
| 16:32 | <zewt> | (you can easily wrap it away in the JS case, eliminating a large portion of the annoyance) |
| 16:32 | <Ms2ger> | Philip`, that would involve me getting up early, no? |
| 16:32 | <jgraham> | The alternative for case b) is to work out how to evolve the API whilst allowing other browsers to render the legacy content |
| 16:32 | <Philip`> | Ms2ger: Or going to bed later than me, so I'll see it when I wake up |
| 16:33 | <Philip`> | I suppose I could always try to be less disorganised with my life, but that sounds like hard work |
| 16:33 | <zewt> | well, of course early implementations should never have no prefix--whether it's a vendor prefix or a generic one |
| 16:33 | <JonathanNeal> | jgraham: you could give users the ability to read the other prefixes |
| 16:33 | <Ms2ger> | Heh |
| 16:33 | <JonathanNeal> | you could have a switch "drop vendor prefixes" |
| 16:33 | <JonathanNeal> | or authors, rather. |
| 16:33 | <JonathanNeal> | in their css |
| 16:33 | <jgraham> | JonathanNeal: I don't understand what that would help with |
| 16:33 | <tantek> | good morning, I'm at the W3Conf in Seattle/Redmond. Any other whatwg'ers here? |
| 16:34 | <JonathanNeal> | jgraham: with the switch on, browsers are allowed to read other vendor prefixed css |
| 16:34 | <jgraham> | Why would we want to let *authors* choose? |
| 16:34 | <miketaylr> | when would a user not want that on? |
| 16:34 | <jgraham> | The whole point is that authors can't be trusted with prefixes |
| 16:35 | <tantek> | channel is irc://irc.w3.org:6665/w3conf |
| 16:35 | <jgraham> | Because they never fulfil the "don't use this for stuff you don't mind breaking or promise to keep up to date forever" part of the contract |
| 16:35 | <JonathanNeal> | jgraham: well, then let browsers read everybody's prefixes. |
| 16:35 | <JonathanNeal> | i don't see harm in that either |
| 16:35 | <jgraham> | OK |
| 16:35 | <JonathanNeal> | but i wouldn't drop the prefixes. |
| 16:35 | <jgraham> | Then why not s/-whatever-// |
| 16:36 | <jgraham> | if browsers can read them all anyway |
| 16:36 | <JonathanNeal> | jgraham: they don't read them all anyway, yet. |
| 16:36 | <JonathanNeal> | thus http://lea.verou.me/prefixfree/ |
| 16:38 | <jgraham> | I know they don't |
| 16:39 | <jgraham> | But what is the advantage of everyone reading -webkit-foo compared to dropping the -webkit- part? |
| 16:39 | <JonathanNeal> | jgraham: -webkit-gradient(linear, left top, left bottom, from(#444444), to(#999999)); |
| 16:39 | <JonathanNeal> | versus -webkit-linear-gradient(top, #444444, #999999); |
| 16:40 | <JonathanNeal> | even webkit tweaked things, mind you they changed the property name a little, but who's to say a browser should be left to get it right. |
| 16:41 | <JonathanNeal> | as features become more complicated, we won't want five versions sitting on the same property value. |
| 16:41 | <JonathanNeal> | i'll admit that another argument for vendor prefixing is writing valid non-prefixed code and no one even cares about valid css |
| 16:42 | <JonathanNeal> | i throw in *ie hacks all the time anyway |
| 16:42 | <JonathanNeal> | the article never mentioned being "valid" |
| 16:43 | <jgraham> | JonathanNeal: As far as I can tell what you are proposing would require everyone to support every syntax variation for all eternity |
| 16:44 | <dglazkov> | good morning, Whatwg! |
| 16:44 | <JonathanNeal> | i'm probing the ideas |
| 16:44 | <JonathanNeal> | hopefully not in vain |
| 16:45 | <karlcow> | hmm reading the log |
| 16:45 | <karlcow> | and enjoying the dated extension |
| 16:45 | <karlcow> | -vendor-YYYYMMDD- |
| 16:45 | karlcow | has a big smile :p |
| 16:47 | miketaylr | would screw it up as -vendor-MMDDYYYY- |
| 16:47 | <Philip`> | -vendor-YYYY-MM-DD-, then |
| 16:47 | <jgraham> | -vendor-I-realise-I-am-a-bad-person-for-doing-this-and-will-probably-have-to-say-hail-Marys-or-something-and-anyway-this-prefix-will-expire-on-26-11-2011-and-hey-youre-using-less-or-sass-and-not-reading-this-arent-you-dammit- |
| 16:47 | <miketaylr> | mmm dashes |
| 16:49 | <Ms2ger> | Throw in some underscores |
| 16:49 | <Philip`> | Then someone will write an article saying "to future-proof your site, you should write <style>#foo { -moz-2012-01-01-foo: ...; -moz-2012-01-02-foo: ...; -moz-2012-01-03-foo: ...; ... }</style>" |
| 16:49 | <karlcow> | -vendor-⌚- tick tick |
| 16:49 | <Philip`> | so we'd need to put a nonce in there too |
| 16:51 | <miketaylr> | http://twitter.com/#!/chriseppstein/status/136485985029603328 |
| 16:51 | <miketaylr> | heh |
| 16:53 | <miketaylr> | of course, if you're going to use a tool to get from foo to vendor-foo anyways, might as well kill vendor-foo |
| 16:55 | <tantek> | yeah that's about right |
| 16:55 | <tantek> | such tools obscure the risk that web designers are taking that the properties will change (hint: they do) |
| 16:55 | <tantek> | so if you use such tools, get ready for your sites to break more often and your clients to get pissed. |
| 16:56 | <jgraham> | That argument is isomorphic to "the tools will save us" |
| 16:56 | <Ms2ger> | Please describe the isomorphism in detail. |
| 16:56 | <JonathanNeal> | so perhaps browsers should natively do what prefixfree does for them? |
| 16:57 | <jgraham> | Ms2ger: Happily this isn't an exam so I can ignore you :) |
| 16:57 | <Ms2ger> | :< |
| 16:57 | <JonathanNeal> | except i still don't like the idea of having multiple ways of doing the same thing on a single property. |
| 16:57 | <jgraham> | (I mean Chris Eppstein's argument in case that wasn't obvious) |
| 16:58 | <Philip`> | That "that is a 'the tools will save us' argument" argument seems to rely on an assumption that tools will never save us in any situation and we don't even need to consider the actual situation in hand, which seems less reasonable than merely assuming tools won't save us in every situation and so we ought to examine the specific cases |
| 16:59 | <jgraham> | Philip`: Think of it as an attempt to shift the burden of proof |
| 16:59 | <JonathanNeal> | at least you're not blaming webkit |
| 17:00 | Ms2ger | blames webkit |
| 17:00 | <jgraham> | In this case the burden of proof seems to be firmly with the people claiming that prefixes aren't a problem because tools |
| 17:00 | <Ms2ger> | You missed some words there |
| 17:00 | <Ms2ger> | Maybe "they are" |
| 17:00 | jgraham | wishes he knew what should be added to "because tools" but twitter |
| 17:00 | <JonathanNeal> | miketaylr: as an aside, looking at the kindle stats revealed how much of a not-ipad killer it was going to be. |
| 17:01 | <JonathanNeal> | *kindle fire |
| 17:01 | <JonathanNeal> | i can't remember if the price or the resolution were lower. :P |
| 17:02 | <tantek> | prefixes are for experimentation and implementation/designer feedback. not for production. |
| 17:02 | <tantek> | if you depend on prefixed properties for production work, you bear the resulting risk/instability. |
| 17:02 | <JonathanNeal> | tantek: so shame on me for using them in production? |
| 17:02 | <JonathanNeal> | i thought it's my risk to take.. |
| 17:02 | <miketaylr> | but in practice, it's the users who take on the risk |
| 17:02 | <miketaylr> | the author finishes their site, moves on to the next one |
| 17:02 | <JonathanNeal> | what risk? |
| 17:02 | <JonathanNeal> | of not getting rounded edges? |
| 17:03 | <JonathanNeal> | that's the risk i was taking |
| 17:03 | <miketaylr> | layout? |
| 17:03 | <JonathanNeal> | the example was used earlier regarding border radius, so the risk is "you might not get rounded edges on this/these boxes". |
| 17:04 | <jgraham> | The risk of the site looking crappier or, in some cases not working at all |
| 17:04 | <jgraham> | Arguably it is the browser vendor who actually take the risks |
| 17:04 | <JonathanNeal> | i think anyone using a prefix inherently knows they are saying "only in" |
| 17:04 | <jgraham> | Typically the user can choose to use a different browser |
| 17:04 | <zewt> | except welcome to the real world |
| 17:04 | <jgraham> | Although of course they may have strong reasons not to |
| 17:05 | <JonathanNeal> | so when i wrote "-moz-border-radius" a few years ago, i knew i was only giving that experience to firefox at the time. |
| 17:05 | <zewt> | your users didn't |
| 17:06 | <tantek> | JonathanNeal - yes - your tradeoff to make, but as an author/designer, you bear the responsibility, not the tools. |
| 17:06 | <JonathanNeal> | of course, my IE users never saw them. |
| 17:06 | <zewt> | you mean your FF users suddenly saw that they went away after a (theoretical) upgrade changed/removed it |
| 17:07 | <JonathanNeal> | zewt: thank goodness we don't live in an era that fears progressive enhancement, otherwise they could have said "no, no border radius in firefox until ie has it" |
| 17:07 | <JonathanNeal> | zewt: had i been irresponsible, then yes, they may have lost the rounded edges later. |
| 17:08 | <karlcow> | JonathanNeal: simple example with no-damages on user experience do not help to solve the issue we are discussing. |
| 17:08 | <zewt> | the advantage of prefixes, as i've always seen them, is that they localize the oddities of that implementation, so other vendors don't have to worry about them, and so the "final" API isn't bound down by them (for some never-actually-existing value of "final", heh) |
| 17:08 | <JonathanNeal> | zewt: yes |
| 17:08 | <karlcow> | the article from hsivonen was about vendor extension. Period. Be in CSS, DOM, HTTP etc. |
| 17:08 | <JonathanNeal> | karlcow: what would you rather discuss? wasn't border-radius a valid example earlier? |
| 17:09 | <zewt> | JonathanNeal: this isn't "progressive enhancement", it's progressive deenhancement, where users actively see features going *away* as they upgrade |
| 17:09 | <karlcow> | If your site relies heavily on CSS transition for example, it will fall apart in other browsers. |
| 17:09 | <karlcow> | border-radius is not a valid example |
| 17:09 | <JonathanNeal> | okay so only things that affect the UI |
| 17:09 | <JonathanNeal> | eg transitions and transforms? |
| 17:10 | <JonathanNeal> | display modes |
| 17:10 | <karlcow> | except if the prose in your page says: Click on this button when the box is rounded and you will be credited of 10 dollars |
| 17:10 | <karlcow> | if you see what I mean |
| 17:10 | <karlcow> | consequences for User experiences |
| 17:11 | <JonathanNeal> | well, my users were happy, especially the ones who got the better experience |
| 17:12 | <karlcow> | and for one careful designer who will deploy them elegantly, there are thousands more who will not. And the millions of users depend on these thousands. |
| 17:12 | <JonathanNeal> | later i added the webkit-border-radius and later i dropped both for border-radius. but i understand that point is now void as you accept it isn't a problem. |
| 17:12 | <zewt> | the main problem i see with prefixes, in practice today, is that most web apis don't gravitate towards something "final" and fixed anymore |
| 17:12 | <zewt> | so under traditional prefixing, those apis just stay prefixed permanently, which is silly |
| 17:12 | <JonathanNeal> | zewt: or is it that browsers just develop new technologies faster. |
| 17:13 | <JonathanNeal> | then form the csswg |
| 17:13 | <zewt> | no, it's that most specs aren't aiming towards "finalize everything, set it in stone and head towards REC", they just loop between WD/LC forever (and that's okay) |
| 17:14 | <zewt> | so the basic notion of "we'll remove the prefix when it's finalized" breaks down |
| 17:15 | <JonathanNeal> | so why won't it finalize? |
| 17:15 | <zewt> | it seems to become something more like "we'll remove the prefix when it seems like the API has mostly settled down, even though it's not final", at least for JS APIs (the CSS side I'm not sure)--but that's a lot fuzzier |
| 17:15 | <JonathanNeal> | that seems more the css spec writers fault. |
| 17:17 | <zewt> | perhaps css specs are more able to be finalized than js APIs; I don't know |
| 17:18 | <JonathanNeal> | so now it's not about css vendor prefixes anymore? |
| 17:18 | <Ms2ger> | No |
| 17:19 | <zewt> | power cycle: go |
| 17:20 | <JonathanNeal> | future of the web: go: http://www.hurtownia-kontakt.pl/ |
| 17:21 | <JonathanNeal> | well, drop the prefixes, it will only make my life easier, i suppose. |
| 17:21 | <zewt> | i don't know if the reason css prefixes stick around too long is for similar reasons as with JS APIs. |
| 17:22 | <JonathanNeal> | i don't relate the two |
| 17:22 | <JonathanNeal> | more people theme than write functionality, and when they write functionality, they rarely step into something vendor prefixes. |
| 17:22 | <JonathanNeal> | *prefixed |
| 17:24 | <zewt> | heh ff8 upgrade losing random cookies, it seems |
| 17:28 | <JonathanNeal> | Well, we can drop the prefixes on our own servers and use something like prefixfree, while we wait for browsers to drop the vendor prefixes, if that is what you are suggesting. |
| 17:28 | <zewt> | (i'm not suggesting anything) |
| 17:29 | <zewt> | if i have any suggestion, it's that people stop saying "vendor prefixes", and clearly say "css prefixes" or "api prefixes" |
| 17:30 | <zewt> | (eg. this is mostly about css prefixes, yet this has found its way to the WebGL list, and people there already seem to not understand prefixes badly enough that this could confuse them) |
| 17:31 | <JonathanNeal> | well, we're using the terminology from the original blogpost. |
| 17:31 | <JonathanNeal> | and they are commonly referred to as vendor prefixes. |
| 17:31 | <zewt> | and as i just said, "vendor prefixes" includes both CSS and scripting, so people should be more clear than that if they mean one in the other in particular |
| 17:33 | <zewt> | (perhaps the argument is meant to apply to scripting prefixes too; i havn't had time to read the whole thing, but on a quick look it doesn't seem to be) |
| 17:33 | <JonathanNeal> | vendor css prefixes, vcssps |
| 17:33 | <JonathanNeal> | or is it css vendor prefixes? |
| 19:25 | <roc> | hsivonen: so, what kind of response did you get? |
| 19:28 | <hsivonen> | roc: the vast, vast majority of commenters agree |
| 19:29 | <hsivonen> | roc: a couple asked about -draft- prefix (I should have written a pre-emptive rebuttal for that) |
| 19:29 | <roc> | where's this feedback? |
| 19:30 | <hsivonen> | roc: twitter @mentions |
| 19:30 | <hsivonen> | roc: so not very nyanced |
| 19:30 | <Rik`> | yes, -draft- will be misspelled -drat- :) |
| 19:31 | <hsivonen> | roc: Tab seemed to suggest adding ways to work around the problem instead of fixing the problem, though the point might have been lost in a tweet |
| 19:35 | <hsivonen> | s/nyanced/nuanced/ |
| 19:35 | hsivonen | apparently can't spell |
| 19:35 | <smedero> | I assumed you were referring to a nyan-cat influenced version of nuanced |
| 19:37 | <timeless> | hsivonen: you're just thinking in suomi |
| 19:37 | <timeless> | or trying to type that way |
| 19:38 | <hsivonen> | timeless: you've diagnosed the problem correctly |
| 19:39 | <timeless> | (this is why finns have trouble in the real world, they convert all foreign language words into Finnish spelling based on Finnish pronunciation) |
| 19:39 | <timeless> | otoh, you're doing much better than most in that you're catching your mistakes :) |
| 19:39 | timeless | still remembers Micorophones + Mirophones @ Nokia |
| 19:40 | <timeless> | (actually, those made me proud of my Finnish coworkers, even they winced at the site of those on big projected slides in our main auditorium) |
| 19:40 | <Ms2ger> | s/site/sight/ |
| 19:41 | <hsivonen> | timeless: the way the use the Finnish writing system to one's advantage is to memorize the *correct* foreign spellings by thinking about them as pronounced by Finnish text-to-speech rules |
| 19:41 | <timeless> | Ms2ger: eep, oops |
| 19:41 | <hsivonen> | hehe |
| 19:41 | <roc> | hsivonen: I'm worried about reducing the ability of authors to know that a feature is experimental or engine-specific, or our ability to explain it to them. I wish there was as good a way to do that without prefixes, but I can't think of one. |
| 19:42 | <hsivonen> | roc: it doesn't matter. even if authors know a feature is experimental or engine-specific, they will still use it if it solves their client's problem right now |
| 19:43 | <Rik`> | ship behind a pref? |
| 19:43 | <hsivonen> | roc: the only true way to keep stuff experimental is not to ship it in the release channel so that it can't solve the client's problem right now |
| 19:43 | <roc> | hsivonen: there is often more than one way to solve a problem |
| 19:44 | <hsivonen> | Rik`: when we did that with the HTML parser, people started talking about flipping the pref on forums that were uncomfortably visible |
| 19:44 | <Rik`> | whatever the forum, it's still a small amount of users |
| 19:45 | <roc> | I think prefs are OK because most users aren't going to flip any prefs |
| 19:45 | <timeless> | roc: devs will use the first way they find that solves their problem |
| 19:45 | <timeless> | and they will demand users flip prefs |
| 19:45 | <timeless> | we've seen really bad advice on flipping prefs |
| 19:46 | <hsivonen> | I'm worried that they ask users to flip prefs, yes |
| 19:46 | <timeless> | if you're going to do pref flipping, at least require the pref be per domain |
| 19:46 | <timeless> | so that you don't have one site randomly cause behavior changes to another site the user visits |
| 19:46 | <hsivonen> | EMC told their extranet users to flip the HTML5 parser pref |
| 19:46 | <hsivonen> | (to off) |
| 19:46 | <timeless> | lol |
| 19:46 | <roc> | I don't think we've ever seen more than 10% of Firefox users flip any given pref |
| 19:47 | <timeless> | you don't think 10% of firefox users is a bad number? |
| 19:47 | <roc> | I don't think it's enough for sites to depend on the pref being flipped |
| 19:49 | <roc> | "they will still use it if it solves their client's problem" ... well, some will. But some won't, and some will construct cross-browser fallbacks if they know to. |
| 19:49 | <hsivonen> | roc: those that will are Mozilla's, Opera's and Microsoft's problem |
| 19:50 | <timeless> | hsivonen: and Nokia's, and RIM's |
| 19:50 | <timeless> | at least you big guys get to do something about it |
| 19:50 | <timeless> | the rest of us just suffer |
| 19:52 | <roc> | hsivonen: Understood. Making things worse for the others is what I'm concerned about. |
| 19:53 | <roc> | in that there's costs to what you're proposing as well as benefits |
| 19:53 | <hsivonen> | roc: mozRequestAnimationFrame might already have made some things on the Web function less well for other browsers |
| 19:54 | <hsivonen> | roc: even when the other vendors have kept on the treadmill and implemented it with their prefix |
| 19:54 | <hsivonen> | roc: though the difference is probably non-obvious to users |
| 19:54 | <hsivonen> | roc: the stuff Mozilla has added lately makes the difference non-obvious when authors fall back to standard stuff |
| 19:54 | <roc> | wouldn't the other browsers just keep using timers? |
| 19:55 | <hsivonen> | roc: yes, so animations would be less efficient than in Firefox |
| 19:55 | <hsivonen> | roc: even if the vendor have done their homework |
| 19:55 | <roc> | that's not making them function less well for other browesrs |
| 19:55 | <hsivonen> | roc: well, either there's a benefit from mozRequestAnimationFrame or we wouldn't need the whole thing |
| 19:56 | <roc> | I agree that we could have done better by making requestAnimationFrame unprefixed much earlier |
| 19:56 | <timeless> | fwiw, IRCCloud isn't particularly interested in spending time chasing mozWebSocket or whatever it is |
| 19:56 | <hsivonen> | roc: likewise, the new chunked XHR response types allow people to write code that uses less memory in Firefox even once the other vendors catch up |
| 19:56 | <timeless> | they might chase it eventually, or just wait for it to be unprefixed |
| 19:56 | <timeless> | (instead, they're using Flash, which otoh, in theory is portable) |
| 19:56 | timeless | saw mozRequestAnimationFrame or perhaps the standardized one mentioned in a slide deck this week |
| 19:58 | <roc> | hsivonen: I totally agree that we should unprefix stuff much more aggressively |
| 19:58 | <timeless> | actually, it was https://developer.mozilla.org/en/DOM/window.requestAnimationFrame |
| 19:58 | <roc> | in some cases, even as aggressively as "before shipping in a release" |
| 19:59 | <AryehGregor> | There's no equivalent for PCRE's x option in JS, is there? Allowing you to write regexes where whitespace is ignored? |
| 19:59 | <AryehGregor> | So you can do multiline with comments, etc.? |
| 19:59 | <timeless> | AryehGregor: sounds right |
| 19:59 | <timeless> | you can use RegExp("hi" /*hi ... */ + "lo") |
| 20:00 | <timeless> | i guess that kinda depends on your definition of "no equivalent" |
| 20:00 | <Philip`> | You could write a regexp to strip whitespace and comments from regexps |
| 20:00 | <timeless> | if you're going to do that, you might as well do it my way.. |
| 20:03 | <hsivonen> | roc: one reason why I think flagging non-standard feature has almost no value is that I view CSS features and APIs that one of the top engines create and authors adopt as features that haven't been standardized *yet* |
| 20:03 | <hsivonen> | roc: that is, I think nothing should stay in a state where it's both in use and non-standard |
| 20:04 | <roc> | Google and Microsoft buy usage |
| 20:05 | <timeless> | doesn't mozilla sponsor jQuery/jQuery-mobile like everyone else? |
| 20:05 | <hsivonen> | well, there are cases where it makes sense to try to block bad stuff by not implementing |
| 20:05 | <roc> | I don't see how that's compatible with what you just said |
| 20:06 | <Hixie> | "buy usage"? |
| 20:06 | <hsivonen> | roc: it makes sense if there's an alternative that drives the thing that isn't implemented into a "not in use" category |
| 20:07 | <roc> | Hixie: spend money evangelizing features, or in many cases actually make cash payments to get people to use features |
| 20:07 | <zewt> | i'd expect that if you have to do that, something is wrong with the feature, heh |
| 20:07 | <hsivonen> | roc: anyway, I think vendor A shouldn't have to guess if a feature they launch is going to end up stonewalled by vendors B and C and therefore should have been prefixed from the beginning |
| 20:07 | <roc> | they don't have to guess |
| 20:07 | <roc> | we can communicate |
| 20:08 | <hsivonen> | roc: because if the feature that vendor A launches is one that B, C and D want to implement, everyone is better off by not having it prefixed |
| 20:08 | <roc> | totally agree |
| 20:08 | <roc> | I think we should go to the CSS WG right now with a list of features we want to unprefix today |
| 20:09 | <timeless> | hsivonen: how do you deal with breaking api changes in such a model? |
| 20:09 | <hsivonen> | roc: great |
| 20:09 | <timeless> | consider the disaster that is webSockets |
| 20:09 | <hsivonen> | timeless: you don't make breaking API changes when the API is used so much that the breakage would be too great |
| 20:09 | <roc> | websockets had breaking API changes because the protocol was totally insecure |
| 20:09 | <hsivonen> | timeless: that disaster is a "disaster" that's available through Java and Flash every day |
| 20:10 | <zewt> | roc: well, security fixes trump compatibility when the collision is unavoidable |
| 20:10 | <hsivonen> | websockets also had breaking changes because the IETF WG felt they could bikeshed it to no end |
| 20:10 | <timeless> | what hsivonen said |
| 20:10 | <zewt> | that doesn't really reduce the importance of compatibility, it's just something yet higher |
| 20:10 | <timeless> | fwiw, IRCCloud apparently only supports up to version X of Chrome and not later |
| 20:11 | <timeless> | (using WebSockets) |
| 20:11 | <zewt> | that sounds more like "doesn't work at all", since almost everyone autoupdates chrome |
| 20:11 | <Hixie> | roc: the websockets protocol wasn't insecure |
| 20:11 | <timeless> | zewt: i think it's the difference between Released and Canary or Dev |
| 20:11 | <timeless> | not certain |
| 20:11 | timeless | doesn't know the versions of Chrome well enough to care |
| 20:11 | <Hixie> | roc: it was a variant that the ietf was considering that was insecure |
| 20:11 | <roc> | Hixie: it could be used to poison badly-written proxies, couldn't it? |
| 20:12 | <Hixie> | roc: but that was itself a breaking change from what had been specced |
| 20:12 | <roc> | maybe I'm misremembering, in which case, I stand corrected |
| 20:12 | <Hixie> | roc: as far as i am aware, what i specced couldn't. |
| 20:12 | <roc> | ok |
| 20:13 | Hixie | is rather sad that we went to the ietf for websockets |
| 20:13 | <hsivonen> | pro tip to the IETF: just rubber-stamp what Hixie specs :-) |
| 20:14 | <hsivonen> | Hixie: I'm sad about it, too |
| 20:14 | <timeless> | anyway, yeah, it /looks/ like IRCCloud only supports Chrome 15 and not higher |
| 20:14 | <Hixie> | they ended up adding a year and no new features to the technology, while simultanteously removing some security features, increasing the likelihood authors would get it wrong, and making it more complicated |
| 20:14 | <timeless> | 15 is what normal people would have, with 16, 17 and 18 being things you could have (I have Canary/17) |
| 20:14 | <Hixie> | anyway |
| 20:14 | <Hixie> | that's water under the bridge |
| 20:15 | <zewt> | periodically grumbling about water under the bridge is useful, to help remind people to build dams in the future :) |
| 20:15 | <timeless> | heh |
| 20:15 | <timeless> | the Chinese dams have been um.. interesting |
| 20:16 | <Hixie> | roc: i'm curious about what vendor-prefixed vendor-specific technologies microsoft and google have been sponsoring before they are accepted by other vendors... do you just mean demos? |
| 20:16 | <roc> | Web Audio API |
| 20:17 | <hsivonen> | roc: that one had particularly uncool naming |
| 20:17 | <roc> | yeah, that was branding genius\ |
| 20:17 | <hsivonen> | roc: Firefox's API should have been promoted as both "Web" and "HTML5" |
| 20:17 | <roc> | make sure to grab "Web <simplest possible noun> API" for your next feature |
| 20:17 | <zewt> | is that the weird stuff google search uses for voice input? (which always worried me--how is it inputting sound with only a click, when I never gave it permission to do that) |
| 20:18 | <hsivonen> | roc: at least our out-of-spec <menuitem> stuff is promoted as HTML5 content menus |
| 20:18 | <Hixie> | roc: who's using that? |
| 20:18 | <TabAtkins> | krijn: Please publish! |
| 20:18 | <Hixie> | zewt: yeah, i don't understand why webkit doesn't do that for _every_ input control, that feature makes no sense to me |
| 20:19 | <hsivonen> | *context menus |
| 20:19 | <zewt> | i don't understand what security team would allow a feature to input sound without an explicit user confirmation |
| 20:19 | <timeless> | zewt: who needs security teams for features? :) |
| 20:19 | <zewt> | cough |
| 20:19 | <timeless> | omi, shiny |
| 20:19 | <timeless> | push push push |
| 20:19 | <Hixie> | zewt: it's just a flag you can set to enable voice input on a particular control, it's no more of a security risk than keyboard input |
| 20:19 | <roc> | Hixie: it's not quite "in use" on the public Web for non-demos as far as I know, but Google's certainly trying to get it there, and it is in use in Chrome apps |
| 20:19 | <zewt> | let's just turn on filesystem api for C:\ and be done with it :P |
| 20:20 | <timeless> | zewt: the Linux people will say "sure, go ahead, we don't have a C:!" |
| 20:20 | <zewt> | Hixie: of course it is, i don't randomly type sensitive information into a webpage, but nobody is going to realize that everything being said in the room is being recorded |
| 20:20 | <Hixie> | roc: well chrome apps using a chrome api is like firefox extensions using xbl or xul, doesn't seem a huge deal. and having use in demos seems a positive thing. |
| 20:21 | <zewt> | i don't know if that API is globally enabled or whitelisted to google.com or what |
| 20:21 | <Hixie> | zewt: are we talking about the same feature? i'm not aware of anything that does what you describe. |
| 20:21 | <zewt> | Hixie: the mic button on the google.com search page |
| 20:21 | <zewt> | i don't know what the API is like under the hood, if it's possible to mask the voice input overlay in any way, etc |
| 20:21 | <Hixie> | zewt: that feature only allows the user to use the mic instead of the keyboard to insert text into a form control, the page doesn't get any of the audio, only the text |
| 20:21 | <hsivonen> | Hixie: I think -webkit-CSS demos are hurting Firefox when Firefox implements the same features as -moz-CSS |
| 20:21 | <roc> | If you look at people's notes from this conference http://www.newgameconf.com/ there is no sense that the Google evangelists were portraying Web Audio API as a non-standard experiment |
| 20:22 | <Hixie> | zewt: plus it's opt-in, the mic isn't even on until the user clicks the mic icon |
| 20:22 | <Hixie> | hsivonen: i think prefixes are a terrible idea, been saying so for ages |
| 20:22 | <timeless> | zewt: it probably uses flash in some cases :) |
| 20:22 | <zewt> | Hixie: that seems of less use, then, but okay |
| 20:22 | <zewt> | roc: i wouldn't expect someone calling an api "web audio api" to do such a thing :P |
| 20:23 | <Hixie> | roc: that's certainly unfortunate, but then it _is_ being developed in a w3c wg, no? |
| 20:23 | <timeless> | roc: gah, that site's design requires webfonts in order not to render badly |
| 20:23 | <roc> | Anyway, I don't want to bash Microsoft and Google about this. The point is that usage can be and is bought. Every time Microsoft releases a new platform they have tons of apps built by Microsoft dollars. Microsoft paid NBC to stream the Olympics over Silverlight. That sort of thing. |
| 20:24 | <zewt> | roc: does MS really do that for non-proprietary tech? |
| 20:24 | <roc> | so making decisions based on observed "usage" could just give control to people who can do that |
| 20:24 | <zewt> | after all, if an API is open and implemented and useful, you don't really *have* to do that |
| 20:24 | <Hixie> | well, silverlight was a platform they wanted to have win, i think it's pretty reasonable if you're going to have a vendor-specific tech to try to make it succeed :-) |
| 20:25 | <Hixie> | not that a vendor-specific tech is imho a good thing, but that's a separate issue |
| 20:25 | <Hixie> | we can hardly claim it's unfair for a company to try to compete |
| 20:25 | <Hixie> | even if what they're competing with is vendor-neutral |
| 20:25 | <Hixie> | competition makes us stronger |
| 20:25 | <roc> | I don't see why they wouldn't do the same for their extensions to the Web |
| 20:25 | <zewt> | competition sometimes makes us stronger; it doesn't always work out that way in the end :) |
| 20:26 | <zewt> | not that that makes any difference to what we're doing |
| 20:26 | hsivonen | has to step away from the computer |
| 20:26 | <Philip`> | Surely competition only makes you stronger if the competition loses, which isn't a certainty |
| 20:27 | <zewt> | philip: unfortunately, the more common end result is nobody "wins" and tech is fragmented, which means everyone loses |
| 20:27 | <TabAtkins> | I think that prefixes are still a good thing for the web. What is bad is that (a) features stay prefixed for too long, and (b) CSS doesn't have a good way to abstract over prefixes, unlike JS. |
| 20:27 | <TabAtkins> | We can fix (a) by pushing harder on the CSSWG to not bikeshed the hell out of things. |
| 20:27 | <zewt> | (which is a result I'll take over proprietary tech winning outright, but) |
| 20:28 | <TabAtkins> | We can fix (b) with something like Mixins. |
| 20:28 | <roc> | Hixie: hypothetically, if there were two competing standards, and one was better than the other in every way, but the other got more usage initially because its backer spread a lot of money around, and it won, then that wouldn't be good for the Web |
| 20:28 | <zewt> | TabAtkins: it seems to me that prefixing was introduced before people started accepting the fact that APIs rarely become "finalized" and etched in stone, and the way things are prefixed just never caught up to deal with that change |
| 20:29 | <roc> | if Microsoft had spread more money around and had a free hand to use their full range of anticompetitive tricks, and Silverlight had then won, that wouldn't have been good for the Web either |
| 20:29 | <roc> | competition is generally good, but it doesn't always produce optimal results |
| 20:30 | <zewt> | roc: "fair competition is good" is a more useful statement, I think |
| 20:30 | <zewt> | unfair competition, not so much--whatever "unfair" means |
| 20:30 | <roc> | depends on the definition of "fair" |
| 20:30 | <zewt> | yep |
| 20:30 | <roc> | you're likely to define it to make that statement a tautology |
| 20:31 | <AryehGregor> | roc, Silverlight is completely incompatible with the rest of the web platform and is so large that it's effectively impossible to standardize, so it's not comparable to the properties/methods/etc. we're talking about. |
| 20:31 | <roc> | TabAtkins: we should go through the set of non-CR CSS proposals and identify a set that we should unprefix today |
| 20:31 | <TabAtkins> | roc: I agree with this. |
| 20:31 | <roc> | AryehGregor: sorry, I'm just riffing on "competition makes us stronger" |
| 20:31 | <TabAtkins> | roc: Come to MTV and we can work on it. ^_^ |
| 20:31 | <Hixie> | roc: well, depends on whether they want their extensions to win specifically or whether they just want the ability in the platform |
| 20:32 | <AryehGregor> | Competition in its purest sense is incompatible with the notion of copyright. After all, copyright is a legal monopoly. |
| 20:32 | <Hixie> | roc: in google's case, while there may be specific engineers who get attached to specific ideas sometimes (me included!), as a general rule, the desire is to get interoperable implementations of particular abilities into the platform, and not any one particular tech or another. |
| 20:32 | <Hixie> | roc: can't say what microsoft's goals are, though |
| 20:32 | <roc> | you always want your extension to win, because you're first to market with your extension which gives you an advantage |
| 20:32 | <AryehGregor> | So we're definitely talking about only limited competition here in any event. |
| 20:32 | <zewt> | AryehGregor: eh, that's a misunderstanding of "copyright"; you can make that argument a lot more convincingly against patents |
| 20:33 | <roc> | by "you" I include myself |
| 20:33 | <TabAtkins> | In CSS we're still occasionally having to slap MS's hand about pushing their *particular* impl quirks. |
| 20:33 | <Hixie> | roc: i think if there were two competing standards, and one was better than the other in every way, then it's unlikely google would spend money on the other. again, dunno about microsoft. |
| 20:33 | <zewt> | you can leverage copyright against competition, but if anyone actually wants to do *that* it's the w3c :) |
| 20:34 | <roc> | TabAtkins: this should only take 30 minutes |
| 20:34 | <roc> | Hixie: I used to believe that, but I don't now. |
| 20:34 | <AryehGregor> | zewt, one of the axioms of perfect competition is that all sellers are selling interchangeable products, so . . . |
| 20:34 | <TabAtkins> | roc: Wanna organize a time this week? Anyone else you believe should be in on it? |
| 20:34 | <zewt> | copyright doesn't prevent creating interchangeable products |
| 20:34 | <AryehGregor> | Perfect competition is incompatible with R&D, really. The point is, it's not necessarily always desirable. |
| 20:35 | <AryehGregor> | zewt, it either prevents creating interchangeable products, or creates barriers to enter the market (violating another axiom of pure competition). |
| 20:35 | <TabAtkins> | roc: I've been meaning to talk with you about measurement/position APIs as well. Sometime soon. |
| 20:35 | <AryehGregor> | I.e., you have to expend a lot of resources to create an interchangeable product and thereby enter the market. |
| 20:35 | <roc> | How about me, David and Boris come up with a list (we're all in Auckland this week), you come up with a list, and we'll propose unprefixing the intersection of those lists? :-) |
| 20:35 | <AryehGregor> | But I'm quibbling. |
| 20:36 | <TabAtkins> | roc: Ah, didn't realize you were all down there! Sounds good. |
| 20:36 | <AryehGregor> | roc, TabAtkins: How about the policy is changed to "the second shipping implementation removes prefixes if it looks pretty much compatible"? |
| 20:36 | <AryehGregor> | Instead of "remove prefixes at CR"? |
| 20:36 | <AryehGregor> | Obviously, I'm talking on a per-property basis, not per-spec. |
| 20:36 | <TabAtkins> | AryehGregor: Why not "when we have two impls, cut everything that's not ready for CR and push the rest up"? |
| 20:37 | <AryehGregor> | TabAtkins, . . . because then you'll have a new standard like every three months for every time a single small group of features get implemented? |
| 20:37 | <TabAtkins> | AryehGregor: ...and? |
| 20:37 | <zewt> | and that's horrible? heh |
| 20:37 | <AryehGregor> | I don't think that will work well with W3C policy. |
| 20:37 | <AryehGregor> | Process, you know. |
| 20:38 | <AryehGregor> | I'm all in favor of annual snapshots. |
| 20:38 | <AryehGregor> | Anyway, got to go. |
| 20:38 | <Hixie> | roc: i'm not aware of ever having seen that situation, so i have no data one way or the other |
| 20:38 | <TabAtkins> | Nah, it can work within the Process if you're proactive about it. |
| 20:39 | <Hixie> | roc: as i've said before, though, if you ever see a case where you think google is pushing for inferior tech, please tell me about it so i can see what's up |
| 20:42 | <zewt> | TabAtkins: i think it's more than "two compatible implementations exist for some feature" to warrant unprefixing, though |
| 20:42 | <zewt> | if two vendors quickly implement a new, in-development spec, you want to let it sit around prefixed for a while--let the spec bake, let people play around with the implementations to improve it, before locking it in place by unprefixing |
| 20:43 | <zewt> | even if it's just "two compatible implementations and an OK from the spec editor" |
| 20:44 | <TabAtkins> | zewt: I agree. |
| 20:44 | <zewt> | (it might be possible to lay out stricter criteria, but it's probably not possible to get them right the first 2-3 attempts) |
| 20:45 | <TabAtkins> | I don't think there's much reason to be strict about it. A general policy and people eager to apply it should be enough. |
| 20:46 | <zewt> | basically "the editor says OK to locking that part of the spec into backwards-compat" (hopefully implying "we've used the API in practice enough to give that kind of sign-off") |
| 20:46 | jgraham | thinks the response to "we should do X" of "let's have a f2f meeting!" is part of the problem |
| 20:46 | <zewt> | letting people use judgement? :O |
| 20:46 | <jgraham> | Or part of a problem at least |
| 20:53 | <TabAtkins> | jgraham: Bah. Pair programming is the best programming. |
| 20:54 | <Ms2ger> | Pff |
| 20:55 | <zewt> | let's waste half of every programmer :P |
| 20:55 | <TabAtkins> | I think that single programming is wasting half of a programmer. |
| 21:01 | <jgraham> | I have no evidence that statement is false. But not all tasks are programming and waiting for optimum conditions for any single task doesn't maximise overall throughput |
| 21:01 | <TabAtkins> | You may have noticed the smilie after my statement, in any case, indicating a lack of seriousness. |
| 21:02 | <jgraham> | I already find it pretty concerning that the CSS WG has like 4 F2F meetings a year and has to schedule special extra time at TPAC |
| 21:02 | <jgraham> | TabAtkins: I really didn't. And still haven't |
| 21:03 | <jgraham> | Oh you mean the original statement |
| 21:03 | <jgraham> | Yeah, fair enough |
| 21:06 | <astearns> | jgraham: the CSS WG needs all that time for the unbounded pagination demoing |
| 21:06 | <TabAtkins> | SO MANY PAGES |
| 21:06 | <TabAtkins> | On that note, pagination 100% needs to be broken down into more primitives. |
| 21:06 | <TabAtkins> | Maybe Regions too? |
| 21:07 | <jgraham> | astearns: I thought that was the point of TPAC, not just the CSS meeting |
| 21:07 | <astearns> | jgraham: yes, it overflowed |
| 21:24 | <roc> | "two compatible implementations" is a very large improvement on "one implementation", and delaying unprefixing beyond that may very likely hurt more than it helps --- see hsivonen's observations |
| 21:28 | <zcorpan> | why do people care about whitespace for quasis but not for innerHTML or normal markup? |
| 21:30 | <krijn> | TabAtkins: we will, thanks! |
| 21:31 | <TabAtkins> | zcorpan: People care about whitespace for quasis? |
| 21:35 | <zcorpan> | some do, apparently |
| 21:35 | <Ms2ger> | I was wondering the same |
| 21:35 | <jgraham> | +1 on the wondering |
| 21:37 | <jgraham> | AryehGregor: BTW what you really want is commit-on-a-branch-then-review |
| 21:39 | <TabAtkins> | Bleh, filing a bug with Moz Legal is too much work. I'll just make up my own example. |
| 21:51 | <zewt> | roc: "two compatible implementations" without "plus editor's OK" would be bad, I think; human judgement must be in the equation somewhere |
| 21:52 | <zcorpan> | why does http://blog.webmproject.org/2011/11/video-codecs-101.html ues flash? |
| 21:52 | <astearns> | "two compatible implementations" seems to me to imply a test suite. The tests don't always come that soon, unfortunately |
| 21:53 | <espadrine> | zcorpan: Is there a way to have embedded youtube videos in html? |
| 21:53 | <gsnedders> | astearns: "both work on Gmail"/"both work on FB Chat" works in lieu of a test-suite :P |
| 21:53 | <espadrine> | afaik html5 youtube is only available on their website |
| 21:53 | <astearns> | grr |
| 21:54 | <zcorpan> | espadrine: the flash embed code uses html if the user has opted in, iirc |
| 21:54 | <zcorpan> | espadrine: anyway that's not youtube afaict |
| 21:54 | <zcorpan> | or maybe it is |
| 21:55 | zcorpan | opts in |
| 21:55 | <zcorpan> | ok, ignore me! |
| 21:57 | <espadrine> | zcorpan: I ignore you ;) |
| 21:58 | svl | hasn't opted in (blocking all youtube cookies actually) and has lately been getting youtube webm videos on random blogs. |
| 21:59 | <gsnedders> | Hixie: How do you justify the Dart/TC39 split then that has obviously happened within Google? |
| 21:59 | <Hixie> | "justify"? |
| 22:00 | <gsnedders> | s/justify/explain/ really |
| 22:00 | <Hixie> | differing visions of what is best for the web |
| 22:01 | <gsnedders> | I mean, if the aim is to get bigints, classes into the web platform, that could've been done (and was being done, by Google, before people got pulled from TC-39!), but the aim is obviously just to use Dart. |
| 22:02 | <Hixie> | "the aim" implies a premise that is false |
| 22:03 | <gsnedders> | The point of Dart is to make up for the lack of a number of things in JS, right? |
| 22:04 | <Hixie> | not so much lacking features so much as what, to dart's supporters, are viewed as fundamental design decisions, i believe |
| 22:05 | <Hixie> | http://www.dartlang.org/docs/technical-overview/index.html seems to discuss the goals in more detail than i could do justice on irc |
| 22:06 | <gsnedders> | See, I still don't think anyone else apart from a small number of Google people see anything in Dart as fundamental design decisions. |
| 22:06 | <Hixie> | agreed |
| 22:06 | <gsnedders> | I mean, the only fundamental change is class-based OO instead of prototype-based OO. |
| 22:07 | <gsnedders> | And with some sort of class syntax likely to be introduced in ES6, that's becoming blurred. |
| 22:07 | <Hixie> | i'm not familiar enough with either dart or future js proposals to comment on such specifics |
| 22:08 | <gsnedders> | Kinda disconcerting that what I've heard from multiple people is that Dart exists in large part just to keep Lars Baks at Google. |
| 22:08 | <gsnedders> | Unleashing a new language to the web (esp. if it reaches Chrome) is not a nice thing at all, and that really is a flimsy reason to do so. |
| 22:11 | <Hixie> | while personally i think that the right thing to do on the web is to embrace and extend existing technologies in a vendor-neutral manner, i don't think it's bad to experiment with new things. |
| 22:11 | <Hixie> | i mean, one day i hope html is replaced by something better |
| 22:11 | <Hixie> | and it's not like it's going to come out of a standards committee |
| 22:12 | <Hixie> | i presume the same applies to, e.g., JS |
| 22:12 | <Hixie> | when new things aren't better enough, they fail |
| 22:12 | <Hixie> | q.v. xhtml2 |
| 22:12 | <Hixie> | have faith in the power of the market :-) |
| 22:12 | <Ms2ger> | Pah |
| 22:15 | <gsnedders> | Hixie: Google can single-handedly more-or-less make other browser vendors do things to some extent, though. If Gmail got a new UI only to Dart-supporting browsers, I expect everyone else would look very closely at Dart. |
| 22:15 | <gsnedders> | I mean, if it were FB who started using Dart, nobody would really care, probaly. |
| 22:15 | <gsnedders> | *probably |
| 22:15 | <Ms2ger> | See: spdy |
| 22:15 | <gsnedders> | But because Google control both ends of the stack… |
| 22:15 | <Hixie> | yeah, i was about to say |
| 22:15 | <Hixie> | see spdy |
| 22:15 | <zewt> | well, spdy isn't being pushed |
| 22:15 | <erlehmann> | gsnedders, if that is true, where is my webm-enabled proprietary browser? :3 |
| 22:15 | <Hixie> | you wildly overestimate google's power here :-) |
| 22:15 | <Hixie> | webm is another example |
| 22:15 | <gsnedders> | erlehmann: YouTube supports H.264 too. |
| 22:16 | <gsnedders> | erlehmann: So from a content POV they aren't pushing it in the same way. |
| 22:16 | <Hixie> | not only that, but there's a huge difference between webm and dart |
| 22:16 | <zewt> | (i wish something like spdy would be pushed, though I'm not familiar enough with spdy to know if I'd want it in particular to be) |
| 22:16 | <Hixie> | with webm, pretty much everyone at google thinks it's better than h.264 for the web |
| 22:16 | <erlehmann> | zewt, go read about it. then read about SCTP |
| 22:16 | <Hixie> | whereas with dart, views are really quite mixed on the matter |
| 22:16 | <zewt> | i've read about it, but i don't know how it is in practice |
| 22:17 | <zewt> | (havn't heard of sctp) |
| 22:17 | <Ms2ger> | Hixie, I remember an announcement about removing H### support from Chrome... Is that still going to happen? |
| 22:17 | <Hixie> | dunno, i'm not part of the chrome team |
| 22:17 | <Hixie> | i would assume so |
| 22:17 | <jgraham> | I'm not sure he is underestimating google's power |
| 22:18 | <jgraham> | You have the position to be very evil, if you choose |
| 22:18 | <gsnedders> | I mean, the SPDY example isn't really relevant: you're still serving the same content over HTTP. |
| 22:19 | <timeless> | gsnedders: just slower and with less security? |
| 22:19 | <zewt> | spdy isn't user-visible (or rather, the user-visibility of it is subtle) |
| 22:19 | <gsnedders> | But if you start serving Dart over SPDY to browsers which support both and stop updating the JS/HTTP version… |
| 22:19 | <gsnedders> | timeless: See what zewt said. |
| 22:20 | <zewt> | webm vs h264 is also not user-visible (or again subtle--mostly a difference in legal issues, and secondarily in coding efficiency, neither of which most users will notice) |
| 22:20 | <timeless> | well |
| 22:20 | <timeless> | that's unfair |
| 22:20 | <timeless> | these are all transports |
| 22:20 | <timeless> | making them user visible is all about some content provider only providing better content via one transport |
| 22:21 | <timeless> | that applies to SPDY and WEBM and Dart |
| 22:21 | <timeless> | or Silverlight if you ha ve |
| 22:21 | <jgraham> | If helps if you want to portray your browser as fast that it can load your sites faster than the competition by using a proprietary protocol |
| 22:21 | <zewt> | if google decided to make things visibly lessened when on h264 (lower the bitrate a lot) or when on http instead of spdy (disable features when not on spdy), then they could push those features; of course, that's out-of-line from the features themselves |
| 22:21 | <timeless> | jgraham: sure |
| 22:21 | <zewt> | and yeah, that's the sort of thing google could use their weight to push things where most others can't |
| 22:22 | <zewt> | of course, they'd also be lessening their own products in the process (making gmail not as good in Firefox or IE or whoever they're trying to pressure), so it's not without cost to them |
| 22:22 | <annevk> | roc: I think the stacking makes sense now, thanks for explaining; I do think we should restrict it to subtrees (either of the element or the Document, depending on where it is set) |
| 22:22 | <timeless> | zewt: they're killing gmail-java for blackberry |
| 22:22 | <zewt> | annevk: so you can't fullscreen a->b->c->d and then stack a a->b->c2 fullscreen on top of it? |
| 22:22 | <annevk> | roc: If we do not restrict it to subtrees you get really weird scenarios and I'm not even sure that's possible given the UI and API constraints |
| 22:23 | <zewt> | (sounds reasonable, if that's what you mean) |
| 22:23 | <timeless> | and they killed gmail ui=2 for IE6 iirc |
| 22:23 | <Hixie> | jgraham: gsnedders argues that google can single-handedly change the web technology stack, but as far as i can tell, that is simply untrue -- either due to inability, as i would tend to believe, or due to policy, which is certainly also possible -- and there are multiple examples of cases demonstrating this imho, as discussed above. |
| 22:23 | <zewt> | timeless: heh, that one I'm not going to shed any tears over :) |
| 22:23 | <gsnedders> | Hixie: I'd argue it's done to policy in alrge part. |
| 22:23 | <gsnedders> | *large |
| 22:23 | <annevk> | zewt: yes |
| 22:24 | <gsnedders> | And that's the scary thing. |
| 22:24 | <Hixie> | jgraham: (microsoft certainly also have had cases where they would have liked a technology to take over the web, and they have certainly not had policy to stop them, and they've had far _more_ leverage than google does, e.g. 99% market share for their browser, and they have equally failed to single-handedly do such things.) |
| 22:24 | <Hixie> | gsnedders: if it was just policy, microsoft would have replaced html with silverlight long ago, imho |
| 22:24 | <timeless> | zewt: well, i believe they offer Chrome as a download |
| 22:25 | <gsnedders> | Hixie: Having open-source code for Dart especially makes it far easier for Google than it ever was for MS, though |
| 22:25 | <timeless> | gsnedders: i'm not sure on that point :) |
| 22:25 | <Hixie> | gsnedders: that's certainly a novel argument |
| 22:26 | <zewt> | timeless: there's a reasonable ulterior motive there, too, though--not wanting to have to maintain compatibility with IE6 |
| 22:26 | <timeless> | zewt: hey, not all reasons for doing something have to be evil |
| 22:26 | <timeless> | i'm just noting that a vendor clearly can try to persuade users to move |
| 22:26 | <timeless> | and has shown its willingness to do so |
| 22:26 | <gsnedders> | Hixie: Is it? Opera could never ship Silverlight on Linux/MIPS, so MS could give us all the insentive in the world and we wouldn't. With Dart that isn't so clear-cut. |
| 22:26 | <timeless> | heck, even MS does! |
| 22:27 | <timeless> | the SharePoint team forced users to upgrade by dropping IE6 support! |
| 22:27 | gsnedders | tries at the very mention of SharePoint |
| 22:27 | <timeless> | gsnedders: incentive, i think |
| 22:27 | annevk | missed neologisms in hsivonen's post |
| 22:27 | <Hixie> | gsnedders: mono? |
| 22:27 | annevk | is slightly disappointed |
| 22:28 | <Hixie> | annevk: ? |
| 22:28 | timeless | thought ms gave some support to mono |
| 22:28 | <timeless> | and just because some teams at MS or Sun weren't very good at doing what needed to be done to force something |
| 22:29 | <gsnedders> | timeless: Yes, that's how you spell it. :P |
| 22:29 | <timeless> | doesn't mean some other team at some other company can't get something similar done w/ similar or even slightly less resources |
| 22:29 | <Hixie> | gsnedders: anyway, there's one way to make this a non-issue |
| 22:29 | <Hixie> | gsnedders: get more market share :-P |
| 22:30 | timeless | thinks MS/Sun made marketing / strategic mistakes |
| 22:30 | <timeless> | not so much technological, but more political |
| 22:30 | <gsnedders> | Hixie: I dunno — it's not so much market-share-as-vendor that's relevant here as it is market-share-as-content-provider. |
| 22:30 | <annevk> | Hixie: hsivonen sometimes coins awesome words |
| 22:31 | <annevk> | or phrases |
| 22:31 | <Hixie> | gsnedders: you need both in order to effect market-changing leverage, imho |
| 22:31 | <Hixie> | annevk: oh, i get it |
| 22:31 | <Hixie> | annevk: i thought you meant he'd used some and you'd not noticed them or something |
| 22:31 | <Hixie> | annevk: and i was wondering which ones i'd missed! |
| 22:32 | <annevk> | heh |
| 22:32 | <gsnedders> | Hixie: Google has enough as market-share-as-vendor to have the leverage, IMO. So it's really just everyone who needs to cut into that. |
| 22:32 | <gsnedders> | Controlling both ends of the stack leads to some interesting cases… |
| 22:34 | <roc> | SPDY is being pushed |
| 22:34 | <roc> | we're implementing it |
| 22:35 | <roc> | I think we're going to help standardize it |
| 22:35 | <gsnedders> | I still think SPDY was pushed live too soon and could've been improved upon… |
| 22:35 | <timeless> | gsnedders: you're in favor of IETF bikeshedding? :-) |
| 22:35 | <gsnedders> | roc: Are you still going to be willing to change it after shipping if standardizing decides to make changes? |
| 22:35 | <roc> | annevk: dunno what you mean by "restrict to subtree" |
| 22:36 | <roc> | gsnedders: depends on the changes. I assume we'd be willing to make some changes |
| 22:36 | <Hixie> | gsnedders: shipping is standardisation. if a committee decides to change the spec after it's shipped interoperably, that's just dumb. |
| 22:36 | <Ms2ger> | Hixie, remember, this is IETF territory |
| 22:36 | <roc> | I hope that if we encounter something stupid that we think should be changed, we won't just go ahead and implement the stupid thing. But I'm not doing the work. |
| 22:36 | <timeless> | Ms2ger: i'm sure he wants to forget :) |
| 22:37 | <gsnedders> | Hixie: Effectively Google has standardized SPDY on its own without consulting anyone by shipping, and that's what I don't like. |
| 22:37 | <Hixie> | what timeless said |
| 22:37 | <timeless> | thanks :) |
| 22:37 | <Hixie> | gsnedders: dude, you can hardly say google didn't consult anyone |
| 22:37 | <Hixie> | gsnedders: nobody might have been interested, but that's an entirely different matter |
| 22:38 | <Ms2ger> | If nobody's interested, that might be a sign that you aren't heading in the right direction |
| 22:38 | <Hixie> | completely agreed |
| 22:38 | <Hixie> | we saw this with svg, too |
| 22:38 | <timeless> | heh |
| 22:38 | <timeless> | +1 |
| 22:38 | <Ms2ger> | ^ |
| 22:39 | <Hixie> | where svg was headed in the wrong direction, and the browser vendors ignored it because we had enough on our plate and weren't interested |
| 22:39 | <Hixie> | and then later on it was too late, and so that's what we implemented |
| 22:39 | <Hixie> | it's not limited to one-vendor situations |
| 22:39 | timeless | ponders |
| 22:40 | <Ms2ger> | I guess you could count the SVGWG as one vendor |
| 22:40 | <annevk> | roc: tree is <div id=a> <div id=b/> <div>; one #a goes fullscreen, #b can; but if #b goes fullscreen, #a can't |
| 22:43 | <zewt> | given that the typical UI that would put #a fullscreen is no longer visible if #b is fullscreen, that seems sane |
| 22:43 | <annevk> | yeah, I'm not even sure how you'd get a trusted click in the first place |
| 22:43 | <zewt> | also it makes the "stack" work like a "stack" in both senses of the word |
| 22:43 | <roc> | annevk: I'm not sure why any restrictions in the spec are needed here |
| 22:44 | <zewt> | eg. the list of fullscreened elements is a stack, and it's also a stack in terms of the DOM nodes (top-down) |
| 22:44 | <annevk> | roc: otherwise figuring out fullscreenchange events get harder I think |
| 22:44 | <zewt> | (whether it's actually needed for a sane API/implementation, no idea) |
| 22:44 | <annevk> | roc: you did not define those in your change proposal |
| 22:46 | <roc> | what's the problem? you run the algorithm, then figure out what's fullscreen in each document and fire fullscreenchange at it |
| 22:46 | <roc> | alternatively we could just fire fullscreen at the document and never at the element |
| 22:46 | <roc> | fullscreenchange I mean |
| 22:47 | <roc> | if you want to catch loss-of-fullscreen you need to register at the document anyway |
| 22:47 | <annevk> | there's no problem, the algorithm is just more complicated |
| 22:47 | <annevk> | and probably unnecessarily so |
| 22:48 | <roc> | then let's simplify things by firing fullscreenchange at the document always |
| 22:49 | <annevk> | e.g. if B embeds two documents and fullscreen changes from one of those documents to the other |
| 22:49 | <annevk> | the stack situation gets more complicated |
| 22:50 | <timeless> | is it changing using JS? |
| 22:50 | <annevk> | JS could have a reference, sure |
| 22:51 | <annevk> | so yeah, UI-restricted does not make sense and this situation could definitely arise |
| 22:56 | <annevk> | roc: I think the main complication last time I looked at this was the tree walking |
| 22:56 | <annevk> | roc: instead of just walking upwards (if you restrict to subtree), you also have to walk downwards again |
| 22:56 | <annevk> | roc: I guess it's not a huge deal if you feel strongly |
| 22:57 | <roc> | are you talking about the document tree or the DOM node tree? |
| 22:57 | <roc> | I don't see how the DOM node tree is relevant at all |
| 22:58 | <annevk> | the "tree" of Documents |
| 22:58 | <annevk> | actually browsing contexts, and that's not a tree either |
| 22:58 | <roc> | it's not? |
| 22:59 | <annevk> | it has popups and weird things, kind of depends on how you look at it |
| 23:00 | <roc> | I agree the document tree walking gets more complicated, but your <div> example had only one document so I didn't understand it |
| 23:00 | <annevk> | oh yeah for the single document case it's not a huge deal either way |
| 23:00 | <annevk> | I just meant to illustrate the concept |
| 23:02 | <annevk> | anyway, I should get to bed and get used to the timezone here :) |
| 23:03 | <annevk> | hopefully next time I'll manage to express my point at the start |
| 23:03 | <annevk> | nn |
| 23:32 | <Hixie> | tantek: yt? |
| 23:36 | <Hixie> | tantek: yt? |
| 23:53 | <Hixie> | jeez, iso 8601 defines way the heck too many formats |
| 23:53 | <Hixie> | the joke about the great thing about standards being that there's so many to chose from is supposed to apply to _alternative_ standards, not to standards within a single specification |