| 00:24 | TabAtkins | just discovered that we finally put a name to "logical width" and "logical height" - measure and length, respectively. |
| 00:25 | <TabAtkins> | This makes talking about layout modes much easier, yay! |
| 00:25 | <TabAtkins> | (I define "easier" as letting me say things like "if the flexbox's layout axis and measure axis are the same...") |
| 00:35 | <AryehGregor> | MS is repeating their lies again about how they take action on all the feedback they receive and other browsers don't. |
| 00:37 | <AryehGregor> | Heh, the most prolific bug filer only filed 200 bugs? |
| 00:37 | <AryehGregor> | I could find 200 spec bugs to file if I spent a few days at it. |
| 00:37 | <AryehGregor> | They'd all get closed "will not fix for version 9", though, so I won't bother. |
| 00:37 | <zewt> | hey, closing bugs as "won't fix" is taking action |
| 00:38 | <gsnedders> | I've only filed just under 300 bugs over the past almost-two-years at Opera |
| 00:38 | <AryehGregor> | Yes, but the thing is, Mozilla and WebKit don't do that because they're willing to take patches. |
| 00:39 | <AryehGregor> | So it's never "won't fix" unless they'd refuse to accept patches. |
| 00:39 | <zewt> | well, it's also frustrating when projects encourage bug reports but almost never do anything with them |
| 00:39 | <gsnedders> | AryehGregor: Plenty of closed-source software doesn't won't fix stuff like that, just has stuff for an indefinite milestone |
| 00:39 | <zewt> | gsnedders: happens on all software, open- and closed-source alike |
| 00:39 | <Philip`> | AryehGregor: You could write a script to report a bug for every one of your reflection test failures |
| 00:40 | <zewt> | IMO, saying "won't fix" is better than leaving bugs open forever with no honest intention of doing anything with them |
| 00:40 | <AryehGregor> | Philip`, excellent idea. |
| 00:40 | <AryehGregor> | I reported two bugs, and they said "we've confirmed the issue and are looking into it" and then said nothing further for months. |
| 00:40 | <Philip`> | Maybe "won't fix" should be a priority level, not a resolution status |
| 00:40 | <gsnedders> | Philip`: And then we can resolve almost all of them as duplicates? :P |
| 00:40 | <zewt> | well, there's "won't fix any time soon" and "won't fix because we don't consider it a bug"--different types of wontfix |
| 00:41 | <TabAtkins> | Hmm. I wonder if it makes more sense to have flexboxes define their layout axis to be their measure axis. |
| 00:41 | <AryehGregor> | zewt, not if you get a lot of volunteer contributions. Then there's no one with the ability to reliably predict what bugs will be fixed. |
| 00:41 | <AryehGregor> | No one at Mozilla can say "nobody here is going to decide to fix this bug". |
| 00:41 | <AryehGregor> | It's not like a typical proprietary setup where you've got some kind of manager who can say "Okay, we're not going to assign the resources to fix it this cycle." |
| 00:42 | <zewt> | well, the result with projects like mozilla is there are so many bugs--since it's a huge project with millions of users to report them, disproportionate to the amount of resources--that reporting bugs ends up feeling like a waste of tiem |
| 00:42 | <zewt> | also time |
| 00:42 | <AryehGregor> | I don't feel like reporting bugs at Mozilla is a waste of time. I reported 17, and 10 are resolved. |
| 00:43 | <AryehGregor> | Some of them were INVALID or WORKSFORME or DUPLICATE, but that's a legitimate resolution. |
| 00:43 | <AryehGregor> | Three were FIXED, of which two were fixed because I supplied patches. |
| 00:43 | <zewt> | my experience is more of tickets being left untouched for years, heh |
| 00:44 | <zewt> | which I wasn't surprised at, since the number of tickets is so overwhelming, but just the same |
| 00:44 | <AryehGregor> | I've reported 15 bugs against WebKit, of which nine are UNCONFIRMED, one is ASSIGNED (for months now), four are FIXED, one is INVALID. |
| 00:44 | <AryehGregor> | My Mozilla bugs are generally not untouched, they generally get a comment or a CC added or something and then no one fixes them. |
| 00:44 | <AryehGregor> | At least someone looks at them. |
| 00:45 | <AryehGregor> | (But maybe the average bug-filer doesn't have such a nice experience, I dunno.) |
| 00:45 | <TabAtkins> | AryehGregor: I can look at your UNCONFIRMED bugs and at least set them to NEW. |
| 00:45 | <AryehGregor> | (I actually pick approximately the right component and so on, which I've been told helps.) |
| 00:45 | <AryehGregor> | TabAtkins, https://bugs.webkit.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&emailreporter1=1&emailtype1=exact&email1=Simetrical%2Bwebkit%40gmail.com&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&c |
| 00:45 | <AryehGregor> | mdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= |
| 00:45 | <AryehGregor> | Argh. |
| 00:45 | <AryehGregor> | I hate Bugzilla search URLs. |
| 00:46 | <TabAtkins> | https://bugs.webkit.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&emailreporter1=1&emailtype1=exact&email1=Simetrical%2Bwebkit%40gmail.com&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&c |
| 00:46 | <TabAtkins> | Dammit, misclick. Sorry. |
| 00:46 | <AryehGregor> | https://bugs.webkit.org/buglist.cgi?query_format=advanced&emailreporter1=1&emailtype1=exact&email1=Simetrical%2Bwebkit%40gmail.com |
| 00:46 | <AryehGregor> | That's the shortest version that works properly. |
| 00:47 | <zewt> | the fact that bugzilla blocks search engines from indexing it also makes me not inclined to report tickets--I have no idea why they do that, and I'm not jumping hoops through bugzilla's own clunky search |
| 00:47 | <TabAtkins> | zewt: It's an understandable reason, actually. |
| 00:47 | AryehGregor | has reported 74 bugs at bugzilla.wikimedia.org, it seems |
| 00:48 | <TabAtkins> | You don't want it to be easy to find security bugs, but you can't always know a bug is a security bug until after it's been reported. |
| 00:48 | <AryehGregor> | TabAtkins, that seems like an incredibly weak reason. |
| 00:48 | <TabAtkins> | You can't revoke searching of a page, so the only way to prevent indexing security bugs is to prevent indexing *all* bugs. |
| 00:48 | <TabAtkins> | Shrug, that's the reason. |
| 00:48 | <AryehGregor> | Something like half of my Wikimedia bugs are FIXED, but that's not really fair, since I have like a thousand MediaWiki commits. |
| 00:49 | <zewt> | ... that doesn't make sense, since you can still search with bugzilla's own search (it's just annoying and cumbersome) |
| 00:49 | <AryehGregor> | TabAtkins, says who? |
| 00:49 | <AryehGregor> | zewt, no, because then it will be hidden from search results right away once someone spots it's a security bug. |
| 00:49 | <AryehGregor> | If it were in Google's cache, it would still be available for a while. |
| 00:49 | <TabAtkins> | AryehGregor: I forget who it was that told me, but it was at the recent CSS testing f2f. |
| 00:50 | <gsnedders> | Can anyone see if http://stuff.gsnedders.com/es/getterparsing.html passes in recent WebKit nightlies? (not Chrome) |
| 00:51 | <Philip`> | If someone wanted to discover security bugs, surely they could just poll ?id=(current max + 1) every ten seconds to find new bugs and then watch for ones that suddenly become invisible? |
| 00:51 | <zewt> | heh |
| 00:51 | <Philip`> | Seems a bit silly for them to use a search engine to access it |
| 00:52 | <AryehGregor> | Chromium's issue tracker seems to say I've reported 24,536 issues. I suspect it's wrong, but I'm willing to take the credit: http://code.google.com/p/chromium/issues/list?can=1&q=reporter%3ASimetrical%2Cgmail.com |
| 00:53 | <zewt> | it's very unreasonable to expect people to search for existing tickets before reporting bugs, and then to make it hard to search tickets, heh |
| 00:53 | <AryehGregor> | Mozilla's bug tracker makes it pretty easy to search existing bugs when opening a new bug. |
| 00:54 | <TabAtkins> | Philip`: Indeed, that was explicitly mentioned as a trivial way to defeat the measure. Shrug. |
| 00:54 | <AryehGregor> | I always make sure I do, even when the bug is something like "img/video/audio/source.setAttribute() on src trims whitespace". |
| 00:54 | <zewt> | as I recall, it spits a zillion generally entirely unrelated results at you--sorry, but if I can't google site:bugzilla.mozilla.org, searching is unreasonable |
| 00:54 | <AryehGregor> | Which reminds me, let me look into that. |
| 00:55 | <AryehGregor> | Quite a surprising bug. |
| 00:55 | <zewt> | anyhow, it's just one thing that demotivates me to report tickets--if I was interested in getting directly involved in Mozilla development (and fixing my tickets myself) I might be more inclined to jump hoops |
| 00:55 | <AryehGregor> | You'd think setAttribute() and getAttribute() wouldn't be element-specific at all, but apparently not. |
| 00:55 | <TabAtkins> | Argh, all this longdesc crap would be gone if we had a non-void image element that contained accessibility equivalent. |
| 00:55 | <gsnedders> | TabAtkins: object? :P |
| 00:56 | <TabAtkins> | That's a crap idea and you know it. |
| 00:56 | <AryehGregor> | data:text/html,<!doctype html><script>var img = document.createElement("img"); img.setAttribute("src", " "); alert(img.getAttribute("src").length);</script> |
| 00:56 | <gsnedders> | Does nobody have WebKit nightlies here? :( |
| 00:56 | <AryehGregor> | That alerts "0" in Firefox 4b11. |
| 00:56 | <TabAtkins> | <canvas src><p>stuff</p></canvas>, perhaps, with the src pointing to an image that is loaded as the default image in the canvas (rather than transparent black). |
| 00:57 | <AryehGregor> | gsnedders, do you only have a Linux computer handy, or what? |
| 00:57 | <gsnedders> | AryehGregor: Yeah |
| 00:57 | <AryehGregor> | Then I'll go to the effort of installing the latest nightly on my parents' Windows laptop. |
| 00:58 | <gsnedders> | AryehGregor: And WebKit/GTK has all kinds of dependencies on unreleased version of GNOME (as it almost always does, because as its developed part of the GNOME suite it feels free to depend upon all the latest and greatest stuff), so it's a massive pain |
| 00:58 | <zewt> | i should probably poke at WebKit more; the few times I've looked at WebKit and Mozilla internals, WebKit seems a whole lot less ... stressful to experiment with |
| 00:59 | <AryehGregor> | The Gecko code I've seen is fairly good. Or maybe I just can't tell, because I don't know C++ worth squat. |
| 01:00 | <AryehGregor> | But adding maxlength support to textarea was about five lines of code changed, which speaks to the quality of the design of at least that tiny piece of it. |
| 01:00 | <gsnedders> | AryehGregor: Hmm, I guess I can try using the Qt port |
| 01:00 | <zewt> | not so much that it's bad code, just seems like a much heavier design |
| 01:00 | <AryehGregor> | (although it turns out the maxlength implementation mishandled line breaks, which was formerly irrelevant because inputs are one-line, and that had to be fixed in a separate patch) |
| 01:02 | <AryehGregor> | gsnedders, two PASS, then four "FAIL (did not throw)". |
| 01:02 | <AryehGregor> | This is r79501. |
| 01:02 | <AryehGregor> | Do you need anything else, or should I delete it? |
| 01:02 | <gsnedders> | AryehGregor: k, thx |
| 01:03 | <gsnedders> | AryehGregor: That's everything |
| 01:03 | <AryehGregor> | k. |
| 03:04 | <boblet> | anyone know what’ up with Lachan’s HTML 5 Reference? has it run out of steam, or just on ice for a while? |
| 08:34 | <annevk> | would be nice if we could kill the Name and QName checking from DOM methods... |
| 08:35 | <annevk> | lots of complexity there that we're really better without |
| 08:36 | <annevk> | and probably checking the exact character boundaries will show that some UAs implement 4th and others implement the 5th edition of "1.0" and we'll never get anywhere |
| 08:37 | <hsivonen> | annevk: do we know if anything on the Web depends on checking them except Acid3? |
| 08:38 | <zewt> | . o O ( thread fatigue ) |
| 08:38 | <hsivonen> | annevk: maybe we should still throw if the first character is '<'? |
| 08:38 | <hsivonen> | zewt: the script loading thread? |
| 08:38 | <zewt> | none other :P |
| 08:38 | <annevk> | ooh, Acid3 |
| 08:39 | <annevk> | win |
| 08:41 | <zewt> | have to consciously stop myself from responding point-by-point when it doesn't seem like it'll help--else threads just spin in circles at exponentially-increasing speed forever |
| 08:42 | <zewt> | circles of emails that take half an hour or more each to write, heh |
| 08:42 | <hsivonen> | everything except the original "fetch upon setting .src, fire progress events and change readyState" solution scares me |
| 08:43 | <zewt> | i think my last update is actually much simpler, at least spec-wise |
| 08:46 | <hsivonen> | I feel I should reply to the thread, but I'm still sick and don't have the energy, so I'm debugging a memory leak instead |
| 08:47 | <annevk> | that does sound easier o_O |
| 08:50 | <zewt> | i've tried to look at how the readyState one would be expressed in the spec, and it seems to require a bunch of cascading changes |
| 08:54 | <hsivonen> | zewt: I think of readyState as something that will appear on all fetchables eventually |
| 08:56 | <annevk> | really? bah |
| 08:56 | <annevk> | readyState is so ugly |
| 08:56 | <zewt> | i'd much rather see Progress Events on all fetchables (but with a different name than "load", since that one's taken) |
| 08:56 | <hsivonen> | annevk: It's ugly but being able to query the state of fetchables is reasonable and reinventing the wheel seems less reasonable than using what's already invented |
| 08:57 | <hsivonen> | zewt: readystatechange? |
| 08:57 | <zewt> | what? |
| 08:57 | <hsivonen> | zewt: "readystatechange" is not "load" |
| 08:57 | <zewt> | onreadystatechange is not equivalent to onload, since you have to check readyState |
| 08:58 | <zewt> | which, agreeing with anne, is ugly |
| 08:58 | <hsivonen> | exorcising ugliness from the Web platform tends to lead to duplication which is worse |
| 08:58 | <zewt> | annevk: FWIW, it'd be nice if Progress Events would use a different name than "load" for "completed", so it can be applied more often without having to pick different event names (due to onload being taken) |
| 08:59 | <annevk> | progress events is completely constrained by legacy or some such :/ |
| 08:59 | <zewt> | perhaps too late to help now, but something that came to mind |
| 08:59 | <annevk> | I have finally applied the "fire" change |
| 08:59 | <zewt> | well, where "onload" already means "fetch complete", that's fine |
| 09:00 | <annevk> | in theory "onload" could handle both |
| 09:00 | <zewt> | I'd have used "onfetch", since "onload" tends to mean both "fetched and loaded" (eg. image decoded, script executed) |
| 09:00 | <annevk> | just have to type test... |
| 09:00 | <annevk> | the "what if" scenarios are interesting |
| 09:01 | <annevk> | no legacy encoding crap is always the first thing that comes to mind |
| 09:01 | <zewt> | being able to apply progress events to all elements would be neat, to be able to get progress notifications for things like large images |
| 09:01 | <annevk> | that should work now |
| 09:01 | <annevk> | and we should maybe do that at some point |
| 09:02 | <zewt> | i forget--does onload for images happen after fetch or after decode? |
| 09:02 | <zewt> | (eg. does onload fire after fetching a corrupt image) |
| 09:02 | <annevk> | once it's shown its merit with XHR |
| 09:02 | <annevk> | not for corrupt |
| 09:02 | <annevk> | well, I dunno |
| 09:02 | annevk | is sleepy |
| 09:04 | <annevk> | guess it's time to DOM Core XHR |
| 09:08 | <annevk> | gonna be pain :/ |
| 09:14 | <matijsb> | go sleep man :) |
| 09:15 | <karlcow> | at least a power nap |
| 09:16 | <alrra> | is there a reason for why the charset attribute that specifies the encoding should be within the firs 512 bytes and not... let`s say 125 bytes ? (just curious) |
| 09:16 | <alrra> | first~ |
| 09:19 | <zcorpan> | i guess that should be 1024 bytes these days |
| 09:19 | <zcorpan> | the meta prescan scans the first 1024 bytes (previously 512 bytes) |
| 09:23 | <annevk> | oh, by pain I just meant it's a lot of work |
| 09:23 | <annevk> | no worries :) |
| 09:24 | <hsivonen> | alrra: there are three reasons for 1024 instead of 512: 1) WebKit 2) Dreamhost 3) a particular unit test |
| 09:25 | <hsivonen> | alrra: I'd say the strongest reason is Dreamhost's broken Apache |
| 09:26 | <zewt> | annevk: what's ('d be) the difference between DOM Core XHR and the current XHR specs? |
| 09:27 | <zewt> | (which I see you're also editor of) |
| 09:27 | <annevk> | I just nuked the exceptions section |
| 09:27 | <annevk> | dispatch is gonna be fire |
| 09:27 | <annevk> | those kind of things |
| 09:27 | <annevk> | oh, and terminology becomes a top-level section |
| 09:28 | <annevk> | teehee |
| 09:28 | <annevk> | consistency among specs I edit |
| 09:29 | <alrra> | hsivonen: ok, tnx :) |
| 09:30 | <abarth> | annevk: i'd like to express my excitement that Opera is implementing the HTML5 parsing algorithm |
| 09:31 | <abarth> | annevk: would you be willing to pass on my positive thoughts to the appropriate folks? |
| 09:32 | zcorpan | gets a bunch of emails from microsoft connect, all of which have "Field Resolution changed from [None] to [Won't Fix]" |
| 09:34 | <annevk> | abarth, sure thing; jgraham is among them :) |
| 09:34 | <abarth> | jgraham++ |
| 09:42 | <jgraham> | abarth: Thanks :) |
| 09:45 | <hsivonen> | zcorpan: what kind of bugs? |
| 09:46 | <annevk> | the stream of people on twitter being excited about developers.whatwg.org doesn't really seem to stop o_O |
| 09:47 | <annevk> | I hope they all read it :) |
| 09:48 | <hsivonen> | annevk: except naysayers say nay in the www-archive land: http://lists.w3.org/Archives/Public/www-archive/2011Feb/0051.html |
| 09:49 | <abarth> | hsivonen: i just pushed a couple more tests to http://code.google.com/p/html5lib/source/detail?r=576e61e5b7e0c2f23de9afcbeb0a979c5da23190 |
| 09:51 | <hsivonen> | abarth: thanks. I'll check if those pass |
| 09:53 | <hsivonen> | abarth: <table><tr><td><svg><desc><td></desc><circle> assumes the broken spec |
| 09:53 | <abarth> | maybe we should have a version in pending spec change? |
| 09:53 | <abarth> | those are just tests we added since we last synced with html5lib |
| 09:53 | <abarth> | you could also delete it from html5lib if you don't like it :) |
| 09:54 | <abarth> | i'm just likely to forget and add it again next time i sync the tests |
| 09:54 | <annevk> | hmm |
| 09:54 | <annevk> | that was easier than expected |
| 09:54 | <annevk> | only events and exceptions |
| 09:54 | <hsivonen> | abarth: I pushed a test that assumes the spec gets fixed into pending-spec-changes.dat |
| 09:54 | <annevk> | hmm |
| 09:54 | <hsivonen> | abarth: yesterday that is |
| 09:54 | <abarth> | yeah, webkit fails that one :) |
| 09:55 | <abarth> | hsivonen: https://bugs.webkit.org/attachment.cgi?id=83623&action=review |
| 09:55 | <jgraham> | Seems I need to update my copy of the tests :) |
| 09:55 | <annevk> | hsivonen, yeah, well... |
| 09:56 | <abarth> | hsivonen: at some point i or someone on the team will go through and fix these |
| 09:56 | <annevk> | parser spec still evolving :) |
| 09:57 | <annevk> | but thankfully only nits at this point |
| 09:57 | <abarth> | yeah |
| 09:57 | <abarth> | i'd like for it to stop evolving so I can be done with this project :) |
| 09:58 | <annevk> | I guess that's why you proposed hexadecimal entities :p |
| 09:58 | <annevk> | euh, base64-entities |
| 09:58 | <hsivonen> | abarth: from my point of view, I've been tracking the evolution for a couple of years, so I'm a bit annoyed about the stance of leaving in a spec bug because you'd like the spec to stop evolving |
| 09:59 | <abarth> | the problem is that there are many implementations of the algorithm now and people are shipping it |
| 09:59 | <hsivonen> | I'd like for it to stop evolving too, but not with an obvious bug left in just because Chrome shipped |
| 09:59 | <abarth> | its not as plastic as it used to be |
| 10:00 | <abarth> | well, correctness is a matter of opinion |
| 10:00 | <hsivonen> | well, I expect Firefox 4 to ship with the spec bug precognizantly fixed |
| 10:00 | <hsivonen> | abarth: the spec has a clear goal what it's trying to appomplish and it fails to accomplish that goal |
| 10:00 | <abarth> | we want to incentivize folks to implement the spec |
| 10:00 | <hsivonen> | abarth: and the failure is an editorial accident |
| 10:01 | <hsivonen> | so I think it's pretty objectively a spec bug |
| 10:01 | <abarth> | from my point of view, none of that really matters |
| 10:01 | <abarth> | IMHO, it's more important to get perfect interop than for the algorithm to be aesethtically beautiful |
| 10:01 | <annevk> | http://blog.chromium.org/2011/02/amping-up-chromes-background-feature.html -- embrace and extend? |
| 10:02 | <abarth> | annevk: i think exposing extra APIs to browser extensions is fair game |
| 10:02 | <hsivonen> | abarth: it isn't about aesthetic. It's about actually having the recovery properties that have been advertised. And having sane implementability. |
| 10:02 | <jgraham> | FWIW I agree with hsivonen; I think the short term pain of fixing a few implementations is much less than the long term pain of yet another parsing wart |
| 10:02 | <annevk> | abarth, this is beyond extensions though |
| 10:02 | <abarth> | the question of whether we should expose non-web APIs to apps is a tricky question |
| 10:02 | <hsivonen> | abarth: sane implementability meaning none of those contortions in the end tag case |
| 10:03 | <annevk> | though contrary to how Microsoft does these things Google has brought it up for discussion on the WHATWG mailing list long ago |
| 10:03 | <annevk> | it just did not get much traction |
| 10:03 | <abarth> | yeah, there are serious design issues with that feature |
| 10:03 | <abarth> | my position is that we shouldn't be exposing anything to apps that we don't believe is on the track to being part of the web |
| 10:04 | <abarth> | e.g., FileSystem is fair game because that's an active working group item in the W3C |
| 10:04 | <hsivonen> | abarth: seems like a currently losing position in the Chrome team :-( |
| 10:04 | <abarth> | there's a spectrum of opinions not the team |
| 10:05 | <abarth> | i'm a bit more in the open web camp than the median |
| 10:05 | <abarth> | s/not/on/ |
| 10:05 | <zewt> | i hardly even understand what google's trying to do with the whole packaged-apps thing--the single biggest advantage of web apps is not needing to package or install them, heh |
| 10:05 | <zewt> | for certain things like that backgrounding feature yeah, but overall |
| 10:06 | <abarth> | the biggest benefit is the improved security |
| 10:06 | <abarth> | its basically a way for the user to white-list sites they like |
| 10:06 | <abarth> | and a clear path to revoking that whitelist |
| 10:06 | <zewt> | seems like if there are security issues then they should be addressed at the web level, not worked around with a packaging system |
| 10:06 | <hsivonen> | http://berjon.com/blog/2011/02/harmful-trust.html is relevant |
| 10:06 | <abarth> | i haven't read that post |
| 10:06 | <abarth> | these privileges are very small |
| 10:07 | <abarth> | e.g., the ability to use the notifications API |
| 10:07 | <abarth> | we don't want to give that to every web page |
| 10:07 | <abarth> | because its too spammy |
| 10:07 | <abarth> | but if an app is too spammy |
| 10:07 | <zewt> | it should be available to every web page, but require permission |
| 10:07 | <abarth> | its easy to unwhitelist the app |
| 10:07 | <abarth> | it is |
| 10:07 | <abarth> | you can either get it via an infobar |
| 10:07 | <zewt> | right |
| 10:07 | <abarth> | or via being "installed" |
| 10:07 | <abarth> | we don't want infinite infobars |
| 10:07 | <hsivonen> | having notification as an installable privilege I approve of |
| 10:08 | <abarth> | infobars isn't a solution that scales |
| 10:08 | <erlehmann> | gsnedders, why will you delete your blog? |
| 10:08 | <hsivonen> | but even installing is a bit heavy compared to e.g. allowing it for "app tabs" |
| 10:08 | <zewt> | to me the whole "installable web apps"/"web app store" thing seems more like a marketing gimmick (eg. pushback against iPhone apps) than something with strong technical merit |
| 10:08 | <erlehmann> | gsnedders, please dont. |
| 10:08 | <annevk> | yeah, infobars are annoying |
| 10:08 | <annevk> | but .exe is too |
| 10:09 | <abarth> | http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html |
| 10:09 | <abarth> | is an approach that might feel more webby |
| 10:09 | <zewt> | abarth: permission bars need reexamination as more and more APIs become available that require them, but I don't think installable-apps are a general-purpose solution to that problem |
| 10:09 | <abarth> | zewt: sure it is |
| 10:09 | <annevk> | and centralized whitelisting... |
| 10:09 | <abarth> | it might not be the best solution |
| 10:09 | <abarth> | but it is a solution |
| 10:09 | <zewt> | it's a solution; it's just not a general-purpose one |
| 10:09 | <zewt> | basically it takes the web out of web app, heh |
| 10:10 | <abarth> | i'm not sure what the distinction is between a solution and a general-purpose one |
| 10:10 | <annevk> | given Chrome OS it makes sense they went this way I think |
| 10:10 | <zewt> | it's more of a workaround than a solution |
| 10:10 | <annevk> | given that we don't really have a concrete alternative |
| 10:10 | <abarth> | zewt: you're conflating the packaging with the experience |
| 10:10 | <annevk> | still sucks though |
| 10:11 | <abarth> | IMHO, the two things that could really be improved are |
| 10:11 | <abarth> | 1) the centralization via the store. a decentralized model is certainly more web-like |
| 10:12 | <abarth> | 2) non-standard APIs. that kind of defeats the point of the web being an open platform |
| 10:12 | <abarth> | the syntax for requesting permissions don't really matter that much |
| 10:12 | <abarth> | e.g., you could make it all JSON or XML or whatever |
| 10:13 | <abarth> | the current system is basically just a JSON blob that's been self-signed by a public key |
| 10:14 | <zewt> | also, it's not exactly clear how installable apps solve the permissions-problem--what do they do, android-like "ask for lots of permissions at once"? |
| 10:14 | <zewt> | which has very serious drawbacks vs. the "ask permission the first time you use a feature" model currently used |
| 10:15 | <abarth> | why do you think bugging the user all the time with security prompts is better than just asking once? |
| 10:15 | <abarth> | as a first approximation, you might imagine that users answer security prompts randomly |
| 10:15 | <zewt> | asking the user "allow this page to go fullscreen?" in response to the user clicking a fullscreen button is much better than asking when you first install the application |
| 10:16 | <hsivonen> | abarth: things that also bother me: 1) zip file instead of app manifest and 2) being tied to the store instead of having a Paypal billing relationship with the service from then on |
| 10:16 | <abarth> | its not really tied to the store |
| 10:16 | <zewt> | when you install an android app, you're given a huge list of things the app wants to do--you have no idea why it wants any of those permissions (because the permission request is disconnected from actually using the permission) |
| 10:16 | <abarth> | you can use the whole feature without involving the store at all |
| 10:17 | <hsivonen> | abarth: is it tied to Google Checkout? |
| 10:17 | <abarth> | zewt: i agree that the andriod permission system leaves something to be desired. however, that's not what we're discussing |
| 10:17 | <abarth> | hsivonen: no |
| 10:17 | <hsivonen> | abarth: how does billing work? |
| 10:17 | <zewt> | well I asked before--again, what do they do, exactly? |
| 10:17 | <abarth> | hsivonen: the decision tree is as follows |
| 10:17 | <abarth> | 1) Do you wan to use the store? |
| 10:17 | <zewt> | as the two major models I've seen are "ask in advance" and "ask on demand" |
| 10:17 | <abarth> | if no, then you can host it all yourself |
| 10:18 | <abarth> | if yes, then you can select a payment provider |
| 10:18 | <abarth> | one choice is checkout |
| 10:18 | <abarth> | another choice is to use whatever you like |
| 10:18 | <hsivonen> | abarth: I see |
| 10:18 | <abarth> | zewt: the problem with android's permission system isn't "ask in advance". it's other parts of their design |
| 10:18 | <zewt> | also, in general it'd be a very big loss if regular webpages can't access APIs because some APIs are only accessible to packaged apps; it makes sense in certain cases (at least that background-page feature), but not in general |
| 10:18 | <abarth> | hsivonen: the path of least resistance is to use the store and to use checkout |
| 10:19 | <hsivonen> | (It also bothers me that Google made a point of allowing Flash apps in the store) |
| 10:19 | <abarth> | hsivonen: the link i pasted earlier is an experimental implementation of the system without ZIPs and without the store |
| 10:19 | <abarth> | hsivonen: so if those are the parts you don't like, you might be interested in that page |
| 10:20 | <hsivonen> | abarth: ok |
| 10:20 | <abarth> | basically, the zip is replaced with just a JSON blob |
| 10:20 | <abarth> | that you link to with a <link> element |
| 10:20 | <abarth> | and then you ask to be installed with a JS API |
| 10:21 | <zewt> | if there are package-system-based APIs to handle permissions better then I have no inherent problem with that--as long as it doesn't actually *restrict* important APIs from regular web pages |
| 10:22 | hsivonen | makes a mental note of Chrome having an object window.chrome |
| 10:22 | <zcorpan> | now gecko just needs window.firefox |
| 10:22 | <hsivonen> | interesting if adding a global name chrome didn't conflict with any existing scripts out there |
| 10:22 | <abarth> | i'm sure its replaceable |
| 10:22 | <zewt> | though if high-sensitivity APIs are involved I might change my mind for those (eg. a FileSystem object to the user's whole hard drive) |
| 10:23 | <abarth> | zewt: this only works for low-sensitivity APIs |
| 10:23 | <abarth> | the key is revokability |
| 10:23 | <abarth> | and transparency |
| 10:23 | <abarth> | if the web page does something the user doesn't like |
| 10:23 | <abarth> | they should be able to figure out which one did it |
| 10:23 | <abarth> | and then nuke it |
| 10:24 | <abarth> | and, ideally, ding the site's reputation so other users can be saved the hassle |
| 10:24 | <hsivonen> | abarth: the crx-less solution seems reasonable except for granting permissions to URLs instead of an Origin |
| 10:25 | <hsivonen> | (and the vendor-specific entry point, of course) |
| 10:25 | <zewt> | but for example, a fullscreen API would need to ask permission, and that really needs to work on plain-old-webpages |
| 10:25 | <annevk> | abarth, btw, someone tried running your cookie tests but got a syntax error in Python? |
| 10:25 | <zewt> | (every <video> will want to use it) |
| 10:25 | <annevk> | abarth, https://github.com/abarth/http-state/tree/master/tests |
| 10:26 | <abarth> | hsivonen: that's stuff we can clean up. it's behind an experimental flag |
| 10:26 | <abarth> | annevk: send me the error. i can try to fix it |
| 10:26 | <abarth> | annevk: might be too old a version of python |
| 10:26 | <zewt> | abarth: havn't read that whole blog post above yet, but the whole "XSS attacks against trusted pages" only seems important for high-sensitivity APIs |
| 10:26 | <abarth> | annevk: i think it needs 2.6 |
| 10:28 | <abarth> | hsivonen: aaron boodman is interested in socializing the non-CRX approach with other browser vendors. if you have feedback, i can put you in touch with him |
| 10:29 | <hsivonen> | abarth: I have opinions but I'm totally out of the loop as far as the Mozilla Labs App Store stuff goes, so my opinions may be totally non-vendor-representative |
| 10:30 | <abarth> | my understanding is that there are some internal politics in mozilla that impact this topic |
| 10:30 | <zewt> | just skimming (tired) but this just seems mistaken: "The app needs to store books, so it has file system access." ... "Except that all I need now to gain access to the file system of thousands of users is a single XSS bug" |
| 10:30 | <annevk> | abarth, kk |
| 10:30 | <zewt> | it assumes filesystem access to store books == access to the whole filesystem, rather than what we actually have (sandboxed access) |
| 10:30 | <zewt> | eg. that sort of FS access is low-sensitivity, not high- |
| 10:31 | <zewt> | (well, most of the time--it could be high if you're storing sensitive data there, but not in that particular example) |
| 10:32 | <zewt> | in any case, i still feel the real motivations behind "web app stores" are closer to what I described earlier :) |
| 10:34 | <hsivonen> | abarth: I'm so out of the loop that I don't even know what the politics are. |
| 10:34 | <abarth> | i'm not sure how much of this i'm supposed to know |
| 10:35 | <zewt> | heh, i havn't even looked at mozilla development, but based on the age and size of the project I've assumed it's heavily political--which is a strong deterrent to getting involved with it |
| 10:36 | <abarth> | i also don't know whether this issue has changed after betlzner |
| 10:36 | <zewt> | (perhaps "age, size and exposure", all of which tend to contribute) |
| 10:37 | <abarth> | e.g., if you look at https://wiki.mozilla.org/Firefox/Roadmap under "back to mission" |
| 10:38 | <abarth> | you can see some negative thoughts connected with this topic |
| 10:39 | <hsivonen> | abarth: I moved the test case we talked about earlier and changed its expectation: http://code.google.com/p/html5lib/source/detail?r=bd33da7b55f38f95005cb369843e24f190941cd6 |
| 10:40 | <abarth> | hsivonen: thanks. at least its in the middle of the file. that will help me remember not to add it back again :) |
| 10:41 | <jgraham> | hsivonen: So there are now two changes for the spec-as-we-would-like-it and none for the spec as it is? |
| 10:44 | <annevk> | name for From-Origin draft... "Restricting Cross-Origin Embedding"? |
| 10:44 | <annevk> | RCOE |
| 10:44 | <annevk> | nice |
| 10:45 | <annevk> | COER |
| 10:45 | <hsivonen> | jgraham: there are now two "spec as we would like it" tests for one pending spec change |
| 10:45 | <abarth> | CORE |
| 10:45 | <hsivonen> | jgraham: and no test for the current spec situation on that point |
| 10:45 | <abarth> | ROAR |
| 10:45 | <zcorpan> | LOL |
| 10:46 | <abarth> | Random Origin Access Restrictions |
| 10:46 | <annevk> | Cross-Origin Resource Embedding Restrictions |
| 10:46 | <annevk> | :) |
| 10:46 | <abarth> | can you explain this From-Origin thing to be again? |
| 10:46 | <abarth> | its a server => browser header |
| 10:46 | <annevk> | yes |
| 10:46 | <abarth> | that stops the resource from being used excepted by a particular origin? |
| 10:47 | <annevk> | yes, basically turns it into a "network error" |
| 10:47 | <abarth> | I see |
| 10:47 | <abarth> | so CORS => reading |
| 10:47 | <abarth> | ROAR => displaying |
| 10:47 | <abarth> | displaying means as in an image tag |
| 10:48 | <abarth> | does it work for iframes? |
| 10:48 | <annevk> | helps fight bandwidth stealing, enforcing font licenses, and should help with https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information |
| 10:48 | <annevk> | abarth, yes, I think that would make sense |
| 10:48 | <annevk> | abarth, so it can replace X-Frame-... |
| 10:48 | <abarth> | what about deep linking? |
| 10:48 | <annevk> | no |
| 10:48 | <zcorpan> | window.open? |
| 10:49 | <annevk> | that's also navigating |
| 10:49 | <annevk> | afaik |
| 10:49 | <abarth> | so it cares about the embedding context |
| 10:49 | <abarth> | not the referrer |
| 10:49 | <annevk> | right |
| 10:49 | <annevk> | i would not want to limit normal linking |
| 10:49 | <abarth> | makes sense |
| 10:50 | <abarth> | i still think it should be a CSP directive |
| 10:50 | <abarth> | but whatever |
| 10:50 | <annevk> | that works for me actually |
| 10:50 | <zcorpan> | <iframe> seems easy to work around if you get the user to click somewhere |
| 10:51 | <zcorpan> | <a href=//othersite.com/foo target=iframe style=...></a> |
| 10:51 | <annevk> | abarth, though CSP seems quite overloaded |
| 10:51 | <abarth> | Content-Security-Policy: restrict-embedding *.example.com |
| 10:51 | <annevk> | zcorpan, that would still be embedding |
| 10:51 | <abarth> | you'll get some wildcarding for free that way |
| 10:51 | <abarth> | but there's CSP isn't quite baked yet |
| 10:52 | <annevk> | yeah, I read some of the debate |
| 10:52 | <abarth> | i'd like CSP to be successful |
| 10:52 | <abarth> | i think different folks have slightly different visions |
| 10:53 | <annevk> | I don't quite get why Mozilla wants to introduce so many different flags |
| 10:53 | <annevk> | we did something similar with CORS and I hate it |
| 10:53 | <abarth> | they're still thinking in a mode of shipping once every one to two years |
| 10:54 | <abarth> | which means you only get a limited number of wacks at the ball |
| 10:54 | <abarth> | that means the risk of leaving something out is higher |
| 10:55 | <abarth> | according to the firefox roadmap, they're going to change to a more frequent release cycle, but it takes some time to rewire you brain |
| 10:56 | <annevk> | but yeah, this would make sense as a Content-Policy |
| 10:56 | <annevk> | not sure it's always a security policy though |
| 10:57 | <abarth> | we should just rename Content-Security-Policy to Content-Policy then :) |
| 10:57 | <annevk> | this is mostly wanted by the Fonts WG who think this solves licensing |
| 10:57 | <annevk> | yeah |
| 10:57 | <jgraham> | hsivonen: Perfect |
| 10:57 | <annevk> | (but it also solves a bunch of other problems) |
| 10:58 | <annevk> | abarth, I guess there's no real latest draft of CSP right? |
| 10:58 | <abarth> | brandon has promised to have one posted by EOD friday |
| 10:59 | <abarth> | i could write one, but he seems to want to be the editor |
| 11:00 | <abarth> | annevk: here's some random stuff i wrote on the wiki if you want to get a sense for things http://www.w3.org/Security/wiki/Content_Security_Policies |
| 11:00 | <abarth> | its pretty rough |
| 11:02 | <annevk> | thanks |
| 11:02 | <abarth> | i'm really enamored with the connection between deep linking and XSS |
| 11:02 | <annevk> | since I was asked, I guess I'll write up a draft on From-Origin and mention how it can be merged into Content-Policy |
| 11:03 | <annevk> | I'm guessing nobody is going to like all this instability, but I guess if we want something good it'll take a little longer |
| 11:03 | <abarth> | in some sense, the attack surface of your web site is all the URLs that can be deep linked |
| 11:04 | <abarth> | annevk: i don't know if you read webkit-dev, but there was a thread between tab and maciej about the font stuff |
| 11:04 | <annevk> | isn't that like saying the attack surface is your web site? |
| 11:04 | <annevk> | I've followed that bit on webkit-dev I think |
| 11:04 | <annevk> | will check if there's something ne |
| 11:04 | <annevk> | w |
| 11:04 | <abarth> | i don't think anything knew |
| 11:04 | <abarth> | new |
| 11:05 | <abarth> | just that they're both pretty passionate about their points of view |
| 11:05 | <annevk> | I'm glad that Maciej has the saner pov :p |
| 11:05 | <abarth> | if you could block deep linking, you could reduce that attack surface |
| 11:06 | <annevk> | abarth, and reduce a lot of utility as well? |
| 11:06 | <abarth> | depends. does your bank really want deep linking? |
| 11:06 | <abarth> | it mostly wants you to enter through the front door |
| 11:07 | <abarth> | and then to have a smaller attack surface |
| 11:07 | <annevk> | abarth, that might lead to e.g. whitelisting a specific set of search providers |
| 11:07 | <abarth> | yeah, you'd want a design that make it hard to discriminate |
| 11:07 | <abarth> | s/make/made/ |
| 11:08 | <annevk> | come to think of it, embedding restrictions might do the same |
| 11:08 | <annevk> | whitelisting of images.google.com or some such |
| 11:08 | jgraham | is nervous about making blocking deeplinking easy |
| 11:08 | <jgraham> | It feels like it has the potential to be badly abused |
| 11:08 | <abarth> | jgraham: certainly |
| 11:09 | <abarth> | it's just something i've been mulling over |
| 11:09 | <abarth> | it came of thinking about why mobile apps have few vulnerabilities than web apps |
| 11:10 | <abarth> | you can't really deep link into a mobile app |
| 11:10 | <zewt> | even referer checks for image linking, for all that it has reasonable uses, is maddening when it misfires--such as greader not displaying images |
| 11:10 | <zewt> | ... which leads to people whitelisting reader.google.com, making it that small bit harder for other people to make competing tools |
| 11:10 | <abarth> | zewt: referrer is many layers of sadness |
| 11:10 | <annevk> | zewt, yeah, from-origin would have that effect too |
| 11:11 | <zewt> | not to say I have a better idea or that I'd remove referer due to that--but still |
| 11:11 | <annevk> | not sure how we can prevent leaking http status codes and such otherwise though |
| 11:11 | <zewt> | not current on that issue |
| 11:13 | <abarth> | zewt: one approach is to let sites suppress their outgoing referrer |
| 11:13 | <abarth> | anyway, its bed time for me |
| 11:13 | <zewt> | well, in that particular example, if you let people suppress referer on images, you're also breaking fundamental use cases (eg. legitimately preventing image hotlinking) |
| 11:14 | <abarth> | web site can already supress referers |
| 11:14 | <abarth> | its just a PITA |
| 11:14 | <abarth> | that use case already doesn't work |
| 11:15 | <zewt> | i'd imagine that's the second most common use of referers, second to analytics/tracking |
| 11:16 | <zewt> | personally I don't care; to users it's never anything but an inconvenience, but I guess if I was paying for a metered server I might care *shrug* |
| 11:17 | <zewt> | later |
| 12:40 | <annevk> | I guess we cannot make EventListener a Callback=FunctionOnly? |
| 13:03 | <annevk> | any progress on getting Anolis updated btw? |
| 13:03 | <annevk> | I mean the online version and such |
| 13:03 | <annevk> | I'm getting tired with the script Bert maintains |
| 13:06 | <zewt> | heh, funky FF4b11 bug--alert() appears to run at least some parts of the event loop... so some events can be fired during an alert |
| 13:06 | <annevk> | sounds like their synchronous XHR implementation... |
| 13:07 | <zewt> | external async scripts are run if they complete during an alert |
| 13:08 | <annevk> | that sounds worse than what is/was true for synchronous XHR |
| 13:08 | <zewt> | i think they just added tab-modal alerts recently (since b8 anyway), so I guess they're still ironing that out--but I'll easily take tab-modal alerts over window-modal ones, even if it's a little lumpy |
| 13:09 | <zewt> | window-modal alert dialogs may be the single most annoying thing in javascript, so i'm glad to see browsers following opera's lead on that |
| 13:10 | <zewt> | synchronous XHR is allowed from the UI thread? most sync APIs are only exposed in workers |
| 13:11 | <zewt> | legacy api? |
| 13:11 | <zcorpan> | yes |
| 13:52 | <MikeSmith> | oh nice |
| 13:52 | <MikeSmith> | http://labs.qt.nokia.com/2011/02/24/qt-people-our-javascript-platform-is-burning-rubber/ |
| 14:03 | <gsnedders> | annevk: jgraham hostsit |
| 14:03 | <gsnedders> | erlehmann: But there's nothing of interest of it, and it makes me seem a horrible self-centered asshole |
| 14:03 | <annevk> | gsnedders, i know |
| 14:03 | <gsnedders> | annevk: so ask him ?:P |
| 14:03 | <annevk> | gsnedders, maybe I should set up a bribing strategy as I'm going to visit the Swedes soon |
| 14:04 | <annevk> | jgraham is a busy man |
| 14:18 | <annevk> | ms2ger: nice idea :) |
| 14:18 | <erlehmann> | gsnedders, killing off URL that held content s is a bad deed in itself. meditate on that. |
| 14:20 | <erlehmann> | gsnedders, maybe you should write only stuff you would like to read? |
| 14:20 | <Philip`> | gsnedders: It's too late to change how you seem to people, once you've already published stuff |
| 14:21 | <gsnedders> | Philip`: I know |
| 14:21 | <erlehmann> | gsnedders, keep the blog, and get better. it is great to look at past stuff and see that you are better now. |
| 14:21 | <Philip`> | Everything will hang around forever in caches and quotes and archives, so you'll never be able to hide it, and you'll just have the added negative impression that you're no good at archiving your own material |
| 14:22 | <gsnedders> | Meh, it seems to me no worse than physically detroying stuff. No, you can never be sure you've destroyed everything, but, it can still seem worthwhile to try… |
| 14:22 | <erlehmann> | don't |
| 14:22 | <erlehmann> | you will annoy people |
| 14:23 | <Philip`> | Better to keep it where you can control it and add a disclaimer to give readers the appropriate context |
| 14:23 | <erlehmann> | dead links, man. dead links. |
| 14:23 | Philip` | hates ever physically destroying anything, too :-p |
| 14:23 | <erlehmann> | what Philip` said. there are blogs i read who have a warning on articles older than 6 months. |
| 14:23 | annevk | uses URLs for that |
| 14:23 | <annevk> | (though I wouldn't if I started over) |
| 14:24 | <annevk> | (dates in URLs are almost always terrible) |
| 14:35 | <zcorpan> | what's wrong with dates in urls for a blog? |
| 14:48 | <erlehmann> | zcorpan, dates in urls are ugly. |
| 14:48 | <erlehmann> | <http://example.org/the-title>; is almost universally better remembered than <http://example.org/1234-56-78/the-title>; |
| 14:49 | <erlehmann> | where i do not object is if the dates are the title, as with chat logs or {daily|weekly} articles. |
| 14:50 | <annevk> | zcorpan, doesn't seem good to hide metadata in URLs |
| 14:50 | <annevk> | zcorpan, and they make them more lengthy too |
| 14:51 | <erlehmann> | annevk, the great rewriting purge can permanently change the ugly face of your blog. but you know that :) |
| 14:51 | <erlehmann> | i use only the title |
| 14:51 | <erlehmann> | wordpress defaults are a mess |
| 14:51 | <erlehmann> | but it is pretty good at redirecting from wrongly input URLs to the correct one |
| 14:51 | <erlehmann> | apparently |
| 14:52 | <annevk> | my blog has been rewritten too many times already :) |
| 14:52 | <annevk> | now I only try to simplify every now and then |
| 14:52 | <wilhelm> | They provide a useful hierarchy when example.com/2011/, example.com/2011/02/ and example.com/2011/02/foobar/ are all available. |
| 14:52 | <annevk> | wilhelm, but dated hierarchies suck... |
| 14:53 | <annevk> | (my blog works that way though) |
| 14:53 | <annevk> | besides /2011/ and /2011/02/ and /2011/02/html-development I even support /2011/02/24/ |
| 14:54 | wilhelm | disagrees about the colour of this particular bikeshed. :P |
| 14:54 | <Lachy> | wilhelm, it's possible to implement the dated archives without having to have the URLs of the articles themselves include the dates. |
| 15:02 | <erlehmann> | what lachy says :) |
| 15:04 | <jgraham> | Obviously TabAtkins is right and urls should be absurdly long hash strings |
| 15:05 | <jgraham> | Then people won't get the silly idea that they can remember or manipulate them |
| 15:05 | <jgraham> | If I were evil I might wonder if working for a search company gives you a conflict of interest here ;) |
| 15:05 | <AryehGregor> | jgraham, kind of like git's approach to revision identifiers? :) |
| 15:06 | <jgraham> | AryehGregor: Are you suggesting that git should use the commit message as the revision identifier? |
| 15:06 | <AryehGregor> | No, but I like your twisted and evil way of thinking. |
| 15:06 | <AryehGregor> | That wouldn't work, though, because multiple commits might have the same message. |
| 15:06 | <jgraham> | Same with blog post titles |
| 15:07 | <AryehGregor> | Has anyone else noticed that whenever something goes wrong in Windows, it tells you "application X/website X is causing a problem", but whenever it's pretending to do something helpful, it always says "Windows has fixed this problem"? |
| 15:07 | <AryehGregor> | Like: https://bugzilla.wikimedia.org/show_bug.cgi?id=27677#c18 |
| 15:07 | <AryehGregor> | "the website continues to have a problem", "When a website causes a failure or crash" |
| 15:07 | <AryehGregor> | As though websites are able to crash non-buggy web browsers. |
| 15:08 | <zcorpan> | yeah, i was a bit surprised to read the ie crash message first time i saw it |
| 15:09 | <AryehGregor> | It's really the same as how IEBlog posts always try to spin things to dishonestly paint themselves as being better than their competitors. |
| 15:09 | <AryehGregor> | Microsoft is just evil that way, I guess. |
| 15:11 | <AryehGregor> | (note: in contrast to spinning things to honestly or at least semi-honestly paint themselves as being better than their competitors, which is okay, e.g., touting their GPU acceleration or something) |
| 15:11 | <AryehGregor> | (as opposed to claiming that they address all bugs they receive and their competitors somehow don't) |
| 15:11 | <AryehGregor> | (or that they're more standards-compliant because they pass almost 100% of their own test suite) |
| 15:11 | <AryehGregor> | (both of those are just lies) |
| 15:14 | <AryehGregor> | Wow, I just managed to completely crash Chrome. |
| 15:14 | <AryehGregor> | That's the first time I can remember that happening. |
| 15:15 | <zcorpan> | AryehGregor: no, there was a problem with the web site you were visiting |
| 15:16 | <AryehGregor> | Yes, it must be running some malicious code that only happens to be targeted at IE on Windows XP. |
| 15:16 | <annevk> | fwiw, http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html bit raw still, I need some sleep |
| 15:16 | <AryehGregor> | It was probably written by some frustrated web developers who wanted to take out their anger on IE users. |
| 15:16 | <annevk> | (there's no processing model there) |
| 15:16 | <zcorpan> | i thought you said chrome crashed |
| 15:16 | <jgraham> | AryehGregor: It wasn't a google site then? |
| 15:16 | <AryehGregor> | Oh, you were talking about that. |
| 15:16 | <AryehGregor> | Well, actually, it was Chrome preferences. |
| 15:16 | <AryehGregor> | So Chrome kind of has to take the blame either way. |
| 15:17 | <zcorpan> | snap |
| 15:17 | <zcorpan> | i wonder who IE would blame in that situation |
| 15:17 | <jgraham> | AryehGregor: You're not supposed to change preferences if you use Chrome |
| 15:17 | <jgraham> | Didn't you know? |
| 15:17 | <AryehGregor> | annevk, I realize people have bikeshedded over the name a bunch already, but: "From-Origin"? What relevance does that have to the functionality? How about "Restrict-Embedding" or "Limit-Embed" or something? |
| 15:18 | <jgraham> | If only you recognsied the One True Way, you wouldn't have this sort of problem |
| 15:18 | <jgraham> | I hope you have learnt your lesson |
| 15:18 | <AryehGregor> | zcorpan, 'The website "about:preferences" caused a problem' |
| 15:18 | <AryehGregor> | jgraham, I was actually editing my form autofill info. I guess I'm just supposed to have the same name, address, and phone number as every other Chrome user? |
| 15:19 | <jgraham> | You're probably supposed to put all that information in your google account |
| 15:19 | <zcorpan> | that'd be the case if all other chrome users switched to another browser |
| 15:19 | <annevk> | AryehGregor, Embed-Only-From-Origin was the only somewhat appropriate alternative but not liked so far |
| 15:19 | <annevk> | AryehGregor, I hope this can become part of CSP (or CP) |
| 15:20 | <annevk> | until something drastic like that happens I'm not gonna bother renaming anything |
| 15:20 | <annevk> | that'll just cause confusion |
| 15:20 | <AryehGregor> | Meh. |
| 15:21 | <AryehGregor> | I love how Linux updates just modify everything in place instead of requiring a reboot. It makes things so exciting. |
| 15:21 | <AryehGregor> | Large parts of the text on my screen just turned into little boxes. |
| 15:21 | AryehGregor | waits to see if they turn back |
| 15:23 | jgraham | wonders that gsnedders hasn't started singing yet |
| 15:24 | <AryehGregor> | Nope, they didn't turn back. |
| 15:24 | <AryehGregor> | Looks like my Ubuntu Bold font disappeared. |
| 15:24 | <AryehGregor> | Cool. |
| 15:25 | <AryehGregor> | This is why I hate other OSes, they're so boring. |
| 15:25 | AryehGregor | makes his window titles italic instead of bold for now |
| 15:25 | <bfrohs> | 0.o |
| 15:25 | <AryehGregor> | I'm only half-joking. |
| 15:25 | <bfrohs> | Looks like I had better luck with my update than you did haha |
| 15:26 | <AryehGregor> | Most of what I learned about OSes and hardware, I learned from having to fix Linux when it broke. |
| 15:26 | <bfrohs> | That's the best way, if you ask me |
| 15:27 | <AryehGregor> | Now Chrome has lost my open tabs. This is the first time it's seriously annoyed me in . . . a long time. |
| 15:28 | <AryehGregor> | Oh well, nothing important. |
| 15:30 | <Philip`> | Other OSes are annoying since they don't happily let you install a critical security update to your kernel and then not reboot and still remain unknowingly vulnerable |
| 15:30 | <AryehGregor> | Actually, Ubuntu does tell you to reboot on kernel updates. |
| 15:30 | <AryehGregor> | But not on, e.g., libc or X updates, even for security vulnerabilities. |
| 15:31 | <AryehGregor> | So unless you restart all updated programs, you still might be vulnerable. |
| 15:31 | <Philip`> | Ubuntu doesn't count as proper Linux, it's all user-friendly and stuff |
| 15:31 | <AryehGregor> | Of course, it's not like anyone exploits non-Windows desktops much. |
| 15:31 | <AryehGregor> | And for servers, remote execution is the only real worry in most cases, and that's pretty rare. |
| 15:32 | AryehGregor | hasn't rebooted his server in 75 days, although that's mostly because he has no working fallback |
| 15:32 | Philip` | vaguely remembers getting reboot warnings when logging in on one of his Ubuntu servers, but not the other, and on the first one he didn't bother rebooting anyway |
| 15:33 | <Philip`> | Local exploits still seem dangerous on servers, because servers run rubbish PHP scripts that are full of bugs and let attackers upload and execute arbitrary code |
| 15:34 | <Philip`> | (Fortunately attackers seem to usually just use it for adding spam onto all your pages) |
| 16:18 | <annevk> | hmm, I keep forgetting that the "violating the nodes model" bit still needs to be integrated into the various DOM manipulation methods |
| 17:10 | <TabAtkins> | I like it when IE removes a quirk that I didn't even know about. |
| 17:13 | <aho> | i like it when ie removes itself |
| 17:13 | <aho> | :l |
| 17:28 | <gsnedders> | jgraham: huh? me singing? |
| 17:29 | <jgraham> | gsnedders: You're quite right |
| 17:29 | <jgraham> | I should have used more quotation marks |
| 17:29 | <jgraham> | Or, to put it differently, scare quotes implied |
| 17:29 | <gsnedders> | jgraham: But why me "singing"? |
| 17:30 | <jgraham> | gsnedders: Since they let you in to university, I have to assume you have the intelligence to deduce it from the surrounding context |
| 17:31 | <gsnedders> | jgraham: They rejected me almost everywhere I applied. I couldn't it work out from the surrounding context. |
| 17:32 | <jgraham> | gsnedders: AryehGregor mentioned a key phrase that usually sets you off |
| 17:32 | <jgraham> | I can't repeat it for fear of the consequences |
| 17:32 | <gsnedders> | jgraham: turning black? |
| 17:34 | <gsnedders> | jgraham: Because "loving you was like living the dead"? ;P |
| 17:38 | <annevk> | TabAtkins, tab-size is about the amount of space characters that constitutes a tab stop afaik |
| 17:38 | <TabAtkins> | I thought it was the size of a tab character. |
| 17:38 | <annevk> | TabAtkins, it basically makes the fixed 8 spaces for a tab stop in CSS 2.1 a variable |
| 17:40 | <annevk> | http://www.w3.org/TR/CSS21/text.html#white-space-model second algorithm step 2 |
| 17:40 | <annevk> | by default 8 |
| 17:40 | <annevk> | tab-size changes it |
| 17:42 | <TabAtkins> | Oh, hrm, you're right. I thought tabs were fixed size. |
| 17:43 | <annevk> | I'm also late |
| 17:59 | <TabAtkins> | AryehGregor: As I'm sure you know by now, I confirmed all your bugs this morning. |
| 17:59 | <AryehGregor> | TabAtkins, thanks, I guess, for what confirmation is worth. |
| 17:59 | <TabAtkins> | Just bug me next time you submit something and I'll confirm for you. |
| 17:59 | <AryehGregor> | I mean, it's not like it will get anyone to actually look at them, will it? |
| 17:59 | <TabAtkins> | Hey, "new" is more worth paying attention to than "unconfirmed". |
| 17:59 | <TabAtkins> | It means that someone with confirm permissions actually looked at it. |
| 18:00 | <AryehGregor> | For comparison, this is how the Mozilla bug I filed last night got treated: https://bugzilla.mozilla.org/show_bug.cgi?id=636336 |
| 18:00 | <TabAtkins> | I don't think it's fair to compare *anyone* to bz. ^_^ |
| 18:01 | <TabAtkins> | I'm relatively convinced that bz is a supercomputing cluster somewhere in the northwest. |
| 18:06 | <AryehGregor> | I thought he's in the Boston area. |
| 18:06 | <TabAtkins> | ...How did I say "west"? I was explicitly thinking about boston. |
| 18:08 | <Rik`> | TabAtkins: after reading http://my.opera.com/hallvors/blog/2011/02/18/10-years, I checked the same numbers for bz in bugzilla |
| 18:09 | <Rik`> | TabAtkins: he is CCed on something like 45 000 bugs |
| 18:10 | <AryehGregor> | How many did he report? |
| 18:11 | <gsnedders> | I'd say it's partly a matter of how much bugmail you like coping with :P |
| 18:11 | <Rik`> | AryehGregor: "only" 3081 |
| 18:11 | <AryehGregor> | Whee. |
| 18:12 | <TabAtkins> | I'm telling you - supercomputing cluster. |
| 18:13 | <Rik`> | and assignee on 3001 bugs |
| 18:13 | <AryehGregor> | apt-get install --reinstall ttf-ubuntu-font-family fixed my "bold Ubuntu font is boxes" problem, by the way. |
| 18:13 | <AryehGregor> | See, Linux is easy. |
| 18:13 | <AryehGregor> | The obvious solution worked fine. |
| 18:13 | <AryehGregor> | (it's a pretty nice font, by the way) |
| 18:13 | AryehGregor | gets to work |
| 18:13 | bfrohs | loves Ubuntu font |
| 18:15 | jgraham | hadn't seen Hallvord's blog post |
| 18:15 | <jgraham> | But Hallvord is awesome |
| 18:15 | <Rik`> | TabAtkins: is there a support number I should call when this cluster doesn't comment on my bugs under 30 minutes ? |
| 18:17 | <TabAtkins> | Sorry, Moz doens't do phone support anymore. |
| 18:17 | <TabAtkins> | But you can connect to a live chat rep and ask for bz to be rebooted. |
| 18:20 | <AryehGregor> | Oh, I figured out what broke my page only in Firefox and Opera. I was using strict mode and assigning to an undeclared variable. |
| 18:20 | <AryehGregor> | . . . Why didn't that show up in the console until now? Oh well. |
| 18:21 | <aho> | jslint would have mentioned it |
| 18:21 | <aho> | ;) |
| 18:23 | <carlocci> | why doesn't input type="range" allow you to pick a range of values? |
| 18:23 | <TabAtkins> | Because that's not what it's designed for. |
| 18:23 | <carlocci> | shouldn't it be called input type="slider"? |
| 18:23 | <TabAtkins> | It lets you pick a value from a range. |
| 18:24 | <carlocci> | yes, but for example, input type="number" lets me pick a number, "date" lets me pick a date |
| 18:24 | <aho> | elsewhere these things are called slider and range slider |
| 18:25 | <aho> | so yea, "slider" would have been a better name |
| 18:26 | <carlocci> | oh, ok so it's just a slider after all |
| 18:27 | <carlocci> | thank you TabAtkins, aho |
| 18:27 | <gsnedders> | AryehGregor: That wouldn't cause it to break in Opera; we don't support strict mode. |
| 18:27 | <AryehGregor> | Yeah, I figured out a second reason it broke. |
| 18:27 | <AryehGregor> | I was assuming window.getSelection() and document.getSelection() returned the same thing, per spec. |
| 18:28 | <AryehGregor> | In fact, in Firefox and Opera, document.getSelection() returns the stringification of window.getSelection(). |
| 18:30 | <gsnedders> | Assuming stuff follows the spec when testing the spec is a bad idea. |
| 18:33 | <AryehGregor> | I'm writing a different spec. |
| 18:34 | <AryehGregor> | Which happens to be related to DOM Range. |
| 18:34 | <AryehGregor> | I could have written a full test suite for DOM Range before starting on execCommand(), I guess? |
| 18:38 | <AryehGregor> | Ugh, CSSOM implementations are a mess. |
| 18:57 | <TabAtkins> | Okay, I should just switch to always using live dom viewer instead of data urls. |
| 18:59 | <AryehGregor> | Data URLs are easier to copy and paste. |
| 18:59 | <TabAtkins> | live dom viewer creates them for you. |
| 19:00 | <TabAtkins> | (The "Rendered View" header is a link to a data url of the page.) |
| 19:16 | <jwalden> | gsnedders: as far as I know only Mozilla's implemented the arity restrictions for accessors |
| 19:16 | <jwalden> | gsnedders: no complaints that I can remember so far |
| 19:16 | <TabAtkins> | You two need to quit having half your conversations off-room. |
| 19:16 | <jwalden> | TabAtkins: no, I'm just way behind on scrollback |
| 19:16 | <jwalden> | TabAtkins: that was from 16:00ish yesterday, I think |
| 19:17 | <jwalden> | gsnedders: you should make sure to test for {get 1() { } } and { set "string literal"(v) { } } and { get 3.141592654() { } } as well, since those are all things nobody ever supported before es5 said to, I think |
| 19:18 | <jwalden> | [16:55] <gsnedders> Can anyone see if http://stuff.gsnedders.com/es/getterparsing.html passes in recent WebKit nightlies? (not Chrome) |
| 19:18 | <TabAtkins> | I don't feel like trying to back-convert your local time to mine. |
| 19:18 | TabAtkins | hates time zones SO MUCH. |
| 19:19 | <jwalden> | well, the conversion is the identity conversion unless you're out of the bay area right now |
| 19:19 | <jwalden> | http://krijnhoetmer.nl/irc-logs/whatwg/20110224#l-135 was a better idea probably |
| 19:19 | <TabAtkins> | Ah, kk. |
| 19:20 | <aho> | TabAtkins, beats were a good idea |
| 19:20 | <TabAtkins> | aho: The best idea. |
| 19:21 | <TabAtkins> | Everyone in the world knows what I mean why I say "I'm making this statement at @851". |
| 19:21 | <Philip`> | Just use UTC |
| 19:21 | <TabAtkins> | s/why/when/ |
| 19:21 | <Philip`> | then there's no timezones and people won't think you're entirely insane |
| 19:21 | <TabAtkins> | Bah. Millidays! |
| 19:22 | <Philip`> | Is that a restaurant? |
| 19:22 | <TabAtkins> | s/d/w/ |
| 19:22 | <Philip`> | Ah, right |
| 19:23 | <aho> | d=new Date;b=~~((((d.getUTCHours()+1)%24)*3600+d.getMinutes()*60+d.getSeconds()+d.getMilliseconds()/1E3)/86.4); |
| 19:24 | <aho> | @853 it is :> |
| 19:24 | <TabAtkins> | I have the current beat at xanthir.com, so it's easy for me to tell. ^_^ |
| 19:24 | <aho> | heh |
| 19:29 | <gsnedders> | jwalden: We do for getters, but not for setters. The TC was just meant to check for arguments, which is why it doesn't test anything else. |
| 19:29 | <gsnedders> | jwalden: And I believe we do now for setters as well |
| 19:30 | <gsnedders> | jwalden: (though not shipped yet) |
| 19:30 | <jwalden> | cool |
| 19:30 | <gsnedders> | (the inconsistency was always a bug) |
| 19:30 | <jwalden> | and the same spot as us, if you consider "shipped" as in "release" |
| 19:30 | <jwalden> | stable, not beta |
| 20:17 | <AryehGregor> | Okay, so . . . what font does something get displayed in if its font-family evaluates to something that produces no usable fonts? E.g., font-family: ""? |
| 20:17 | <AryehGregor> | The spec doesn't seem to say. |
| 20:19 | bfrohs | believes it is inherited from the parent |
| 20:19 | <AryehGregor> | Yeah, seems so. |
| 20:31 | <TabAtkins> | AryehGregor: The algorithm is defined in 15.2. When none of the fonts can be used, you fall back to a UA-dependent font family. |
| 20:31 | <TabAtkins> | In other words, it's strictly undefined. |
| 20:31 | <AryehGregor> | That's so typical of CSS. |
| 20:32 | <TabAtkins> | s/typical of CSS/typical of CSS 2.1/ |
| 20:32 | <TabAtkins> | There are still places in CSS3 where we have to give up and say "UA-defined" due to legacy constraints, but they should be very rare. |
| 20:33 | <AryehGregor> | Most of CSS 3 is about as vague as CSS 2.1, in my experience. |
| 20:33 | <AryehGregor> | Lots of it is copy-pasted from CSS 2.1 with new features added, in fact. |
| 20:33 | <TabAtkins> | Then complain, please. We do rewrite things when they are pointed out to be too vague. |
| 20:34 | <AryehGregor> | I'll keep that in mind. |
| 20:58 | <rgervais_> | can we do this? |
| 20:58 | <rgervais_> | oh sorry nevermind |
| 20:59 | <aho> | you can do eeeeet |
| 21:09 | <rgervais_> | <input type="submit" /> or <button type="submit"></button> which one and why |
| 21:09 | <AryehGregor> | Either one's fine. Button can have markup in it. |
| 21:10 | <TabAtkins> | If you need the display power of <button>, use it. Otherwise, use whichever you want, because they're perfectly equivalent. |
| 21:10 | <rgervais_> | ok thanks |
| 21:10 | <rgervais_> | when you say "display power" what do you mean specifically? |
| 21:10 | <TabAtkins> | I mean what Aryeh said. |
| 21:11 | <rgervais_> | oh my bad, what do you guys mean "markup" then? |
| 21:11 | <TabAtkins> | <button>I have <b>bold</b> text in my label.</button>. |
| 21:12 | <rgervais_> | got it, you know what's funny |
| 21:12 | <rgervais_> | you used <b> |
| 21:12 | <TabAtkins> | Plus, the label on a <button> is distinct from the submit value, while <input type=submit> has them the same. |
| 21:12 | <TabAtkins> | Yes? |
| 21:12 | <rgervais_> | shouldn't it be <strong> |
| 21:12 | <TabAtkins> | I'm bolding the text, not strongly emphasizing it, so no. |
| 21:13 | <rgervais_> | I remember you guys saying don't use b as that is presentational |
| 21:13 | <TabAtkins> | Don't use <b> for presentational purposes, sure. <b> has a meaning. |
| 21:13 | <rgervais_> | gotcha, so what's it meaning then |
| 21:14 | <TabAtkins> | It means "this text is traditionally bolded in print contexts, but there is no element with the specific semantics I want to express". |
| 21:14 | <TabAtkins> | Same with <i>. |
| 21:15 | <rgervais_> | interesting... |
| 21:15 | <rgervais_> | thanks appreciate the explanation |
| 21:16 | <TabAtkins> | The distinction is more important for <i>, as there are several elements that italicize things by default, like <em> and <cite>. The only element that bolds things by default is <strong> (and headings, but they do more stuff). |
| 21:16 | <TabAtkins> | So like, if you're writing a species's scientific name, which is traditionally italicized, use <i>. |
| 21:17 | <TabAtkins> | Or, if you're making a GUI text editor and want a button that italicizes things, it's probably appropriate to use <i> in its label. ^_^ |
| 21:17 | <hober> | or the name of a ship |
| 21:18 | <hober> | etc. |
| 21:18 | <TabAtkins> | <button><i><i></i></button> |
| 21:18 | <hober> | personally, I always try to annotate <b> and <i> with a class="" value that expresses the italic-giving or bold-giving semantic |
| 21:18 | <hober> | so <i class="ship">Enterprise</i> |
| 21:19 | <hober> | but that's just personal preference |
| 21:19 | <alystair> | augh floats from hell in this design I'm working on, how many hours should you waste before reverting to display:table magic? :P |
| 21:19 | <TabAtkins> | display:table is a tool you should reach for *first*, not as a last resort. Float-based layouts are the devil. |
| 21:20 | <alystair> | THANK GOD |
| 21:20 | <alystair> | freeeeeedom |
| 21:20 | <rgervais_> | it's interesting you guys say this because a number of you said <i> and <b> shouldn't be used anymore in HTML5. and use css for it |
| 21:20 | <TabAtkins> | Remember: using <table> for layout is bad, because you're not writing tabular data. Using display:table for layout is good, because a grid-based constraint layout system is useful. |
| 21:20 | <rgervais_> | and i'm not against <i> and <b> just interesting |
| 21:20 | <alystair> | I like minimal tags, helps me write my code quicker, I'm a fan of <q> personally :) |
| 21:21 | <TabAtkins> | rgervais_: Opinions differ. HTML defines <i> and <b> as conforming elements with the meaning I talked about. |
| 21:21 | <rgervais_> | TabAtkins: yea I got that |
| 21:21 | <TabAtkins> | alystair: Just remember that display:table doesn't work in IE7 or earlier. If that's a problem, then you're stuck, but otherwise have fun. |
| 21:23 | <TabAtkins> | rgervais_: I can't read your username without mentally filling in "Ricky". Do you just happen to share the same last name and first initial? |
| 21:24 | <rgervais_> | TabAtkins: heh of course, I'm just a huge fan of "The Ricky Gervais Show" |
| 21:24 | <rgervais_> | and karl pilkington |
| 21:24 | <TabAtkins> | Ah, kk. |
| 21:24 | <rgervais_> | of course not** |
| 21:29 | <rgervais_> | Karl Pilkington said something like... people who exercise live longer and but he disagrees because a tortoise live 200 something years doing nothing and will have less heart attacks that way |
| 21:29 | <rgervais_> | hilarious |
| 21:29 | <rgervais_> | anyway back to coding.. can I ask more questions? |
| 21:29 | <TabAtkins> | NO |
| 21:30 | <rgervais_> | alright |
| 21:30 | <TabAtkins> | (yes) |
| 21:30 | <rgervais_> | lol here it is.. when's the right time to use <article> |
| 21:31 | <zewt> | walk through <article>a</article> door |
| 21:31 | <TabAtkins> | When you have a <section>, but it qualifies as "independent" - that is, it's the sort of thing that may be appropriate to link direclty to, or view all by itself. |
| 21:31 | <aho> | if it's an article, blog post, individual comments... that kind of thing |
| 21:31 | <TabAtkins> | In the blog use-case, the blogpost itself is an article, as is each comment. |
| 21:31 | <aho> | :] |
| 21:34 | <rgervais_> | gotcha |
| 21:40 | <rgervais_> | well that's it for now, thanks again guys |
| 22:03 | <zewt> | AryehGregor: "the website continues to have a problem" <- heh, reminds me of the "Vista-compatible" spin, as if Vista breaking applications was the application's fault |
| 22:05 | <bfrohs> | zewt: Well, it didn't work in Microsoft's favor. Instead, people refused to use Vista and stuck with XP :P |
| 22:05 | <zewt> | i still use XP, but for different reasons, heh |
| 22:06 | <zewt> | (I'm not Win7-compatible) |
| 22:07 | <bfrohs> | Bummer, Windows 7 is pretty good (in comparison to past versions of Windows). Still prefer Ubuntu though. |
| 22:07 | <zewt> | just a lot of UI breakage that I don't want a lot of time figuring out how to work around |
| 22:07 | <TabAtkins> | I've stuck with XP because my 8-year-old laptop can't run Win7. The desktop I'm building this spring will be Win7, though. |
| 22:08 | <TabAtkins> | ...my laptop is a third my age. |
| 22:08 | <TabAtkins> | ...my laptop is older than my marriage. |
| 22:08 | <AryehGregor> | zewt, I don't think that's actually fair. It's not like they can realistically avoid breaking compatibility with a lot of apps. Windows maintains much better compatibility across versions than any other major OS. |
| 22:08 | <bfrohs> | TabAtkins: Let's hope your marriage lasts longer than that laptop ;) |
| 22:08 | <TabAtkins> | Yeah, there is just a *fuckton* more apps written for Windows than anything else, so there's much more badly-written apps as well. |
| 22:09 | <TabAtkins> | bfrohs: Well, I'm dumping my laptop in a few months, and I don't plan to dump my wife anytime soon... |
| 22:09 | <zewt> | AryehGregor: that's not the objection--rather, 1: there was no deprecation process for people to update in advance, and 2 (more to the point of the above): they tried to pass off the problem as a flaw in the application, rather than something Vista caused |
| 22:10 | <TabAtkins> | zewt: The problem was very commonly a flaw in the application. |
| 22:10 | <TabAtkins> | I don't know if I can express how badly written many Windows apps are. |
| 22:10 | <AryehGregor> | Yes, a lot of them are in fact apps relying on undefined behavior and such. |
| 22:10 | <TabAtkins> | Your position is roughly equivalent to the justification that businesses make for staying with IE6. |
| 22:10 | <AryehGregor> | Of course, maybe Windows should have less undefined behavior. |
| 22:10 | <bfrohs> | Hey, that's sounds like a lot of websites out there... haha |
| 22:11 | <AryehGregor> | But I remember seeing the Wine bug for Dungeon Keeper once. |
| 22:11 | <zewt> | is there an equivalent to godwin's law for drawing comparisons to IE6? heh |
| 22:11 | <AryehGregor> | . . . well, I guess that's not relevant. |
| 22:12 | <TabAtkins> | Dammit, why was CSS not designed to handle orthogonal flows from the start? |
| 22:12 | <TabAtkins> | Answer: because it's hard, and there wasn't sufficient demand. |
| 22:12 | <TabAtkins> | Objection: But I don't like it! [whine] |
| 22:14 | <TabAtkins> | Worst case scenario: horizontal writing-mode contains a vertical flexbox with both horizontal and vertical children. |
| 22:16 | <annevk> | oh sweet |
| 22:16 | <annevk> | Microsoft objects to publishing DOM Core |
| 22:17 | <TabAtkins> | Yeah, that seemed... interesting. |
| 22:17 | <zewt> | microsoft will not condone any attempt to make APIs comprehensible |
| 22:18 | <annevk> | During the F2F they were not against... Not really sure what this is about. |
| 22:19 | <TabAtkins> | I don't understand the objection about "professional" wording. Do they think that that line in the spec is an insult, rather than an ordinary MUST requirement? |
| 22:20 | <annevk> | Did they miss the red marker directly following it? |
| 22:20 | <annevk> | I thought Adrian had a sense of humor |
| 22:20 | <TabAtkins> | No, they mention issue 172. |
| 22:21 | <annevk> | yes, that is what the red marker links to |
| 22:21 | <TabAtkins> | Yeah, I'm just saying that they obviously didn't miss the red marker, then. |
| 22:35 | <hober> | annevk: it's odd that he cites your mail, but there were never any replies to your mail |
| 22:41 | <annevk> | yeah, it would be great if he/they said something back then |
| 22:42 | <annevk> | having the discussion tied to publication is just boring |
| 22:42 | <annevk> | well, annoying |
| 22:42 | <othermaciej> | what's MS objecting to exactly? |
| 22:43 | <annevk> | publishing DOM Core |
| 22:45 | <annevk> | I guess it's good that at least someone spoke up |
| 22:47 | <annevk> | I had expected a few more comments from people working on DOM Level 3 Events |
| 22:47 | <annevk> | Like how this approach is worse or some such. Or that I reverse engineered something utterly wrong. |
| 22:48 | <annevk> | Not really in the trend of "must be useless" is inappropriate and that "2" should really be a "3" though... |
| 22:48 | <zewt> | no comments at all from them seems to suggest that they're ... not paying attention, heh |
| 22:49 | <annevk> | Pretty good email filters then |
| 22:50 | <dydx> | annevk: Hi. I am working to implement offset{Left, Top, Width, Height} for <col>s and <colgroup>s in WebKit (https://bugs.webkit.org/show_bug.cgi?id=15277). |
| 22:50 | <dydx> | annevk: I've briefly read through CSSOM draft, <http://dev.w3.org/csswg/cssom-view>; and am unclear what the values for offset{Left, Top, Width, Height} should be for row-groups, columns, and column groups. |
| 22:51 | <dydx> | annevk: In particular, what the value of these properties should be for the latter two. Can you clarify <http://dev.w3.org/csswg/cssom-view/#offset-attributes>;? |
| 22:55 | <dydx> | annevk: The draft does not explicitly define the phrase "CSS layout box". |
| 22:55 | <annevk> | dydx, yeah, mostly because CSS doesn't |
| 22:55 | <annevk> | I would have expected <col> and <colgroup> to not really represent a box of their own |
| 22:56 | <TabAtkins> | They have backgrounds, so they have a box. |
| 22:56 | <annevk> | but if they do represent a box, the column / and column box |
| 22:56 | <annevk> | they have edges and everything should be clear, no? |
| 22:57 | <dydx> | annevk: Section 17.2.1 of the CSS 2.1 spec. <http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes>; implies columns and column groups have boxes, but by section 17.3 though they conform to a more restrictive CSS box model. http://www.w3.org/TR/CSS21/tables.html#columns |
| 22:58 | <annevk> | CSS is such a sucky spec |
| 22:58 | <TabAtkins> | Everything surrounding tables is crap, definitely. >_< |
| 22:58 | <annevk> | if it actually properly defined what was being "created" quering it wouldn't be so damn complex |
| 22:58 | <annevk> | or damn complex to define |
| 22:58 | <dydx> | TabAtkins: <http://www.w3.org/TR/CSS21/tables.html#columns>; seems to imply that columsn and colmn gourps only influence the table cells |
| 22:58 | <annevk> | because at this point CSSOM is all about plugging holes in CSS |
| 22:59 | <annevk> | yeah, they're not really boxes after all |
| 22:59 | <dydx> | :-( |
| 22:59 | <annevk> | so if you don't want zero you need special behavior like you said |
| 22:59 | <TabAtkins> | dydx: Yeah, brain fart on my side. <col> and <colgroup> don't really generate boxes. |
| 23:00 | <annevk> | dydx, I suggest emailing www-style⊙wo |
| 23:00 | <jgraham> | annevk: "must be useless" is a pretty hard to grok requirement |
| 23:00 | <jgraham> | I wouldn't know how to test it |
| 23:00 | <dydx> | annevk: That is what I thought was being implied. |
| 23:00 | <annevk> | dydx, I really dislike editing CSSOM View for the aforementioned reasons so it might be awhile I suppose :/ |
| 23:00 | <annevk> | jgraham, right, it has a red blob |
| 23:00 | <dydx> | annevk: Do row-groups have boxes? |
| 23:00 | <annevk> | dydx, those do I think |
| 23:01 | <TabAtkins> | Yes, they do. |
| 23:01 | annevk | reads a bit more |
| 23:01 | <jgraham> | annevk: Right, so it seems you should solve the objection by saying "must be zero [TODO: is this what we want here?]" |
| 23:01 | <zewt> | IMO, better to just say "TODO" and not put in a placeholder that we definitely don't want |
| 23:02 | <jgraham> | Do we know we don't want it to be 0? |
| 23:02 | <annevk> | jgraham, it seems like people should appreciate a bit of humor with issues that are clearly open |
| 23:02 | <annevk> | jgraham, yes |
| 23:02 | <jgraham> | Oh, Ok well put in a sensible option |
| 23:02 | <TabAtkins> | I disagree. If there's an answer that has a reasonable chance of being right, better to write it and annotate it. |
| 23:02 | <annevk> | we don't know the answer |
| 23:02 | <zewt> | i don't think "must be 0" has a reasonable chance of being right |
| 23:02 | <annevk> | geez people |
| 23:02 | <annevk> | study the issue |
| 23:02 | <jgraham> | annevk: Humor in specs is dangerous |
| 23:03 | <TabAtkins> | Oh wait, are we talking about timestamps or column boxes? |
| 23:03 | <annevk> | not until Microsoft complained |
| 23:03 | TabAtkins | thought the latter. |
| 23:03 | <zewt> | yeah, it might reveal the fact that there are humans behind the specs :) |
| 23:03 | <jgraham> | Hixie gets away with it because people don't read what he writes closely enough to care |
| 23:03 | <jgraham> | Because it is so long |
| 23:03 | <jgraham> | And the people who do read closely don't care |
| 23:03 | <gsnedders> | And he mainly does it in examples. |
| 23:03 | <jgraham> | Yes that was the other reason |
| 23:04 | <dydx> | jgraham: For completeness, IE7, IE8, and IE9 in quirks mode return non-zero values ofr offsetWidth and offsetHeight (why not for offsetLeft and offsetTop?) for <col>s and <colgroups>. And offset{Left, Top, Width, Height} are Microsoft extensions |
| 23:04 | <jgraham> | dydx: I thought I was talking about currentTime |
| 23:04 | <zewt> | we need threaded IRC clients |
| 23:04 | <jgraham> | But I am quite surprised that no one has complained about the </sarcasm> thing yet |
| 23:05 | <gsnedders> | jgraham: That's too well hidden. |
| 23:05 | <jgraham> | I mean we probably need an ISSUE- and a set of change proposals and everything |
| 23:05 | <zewt> | writing a test set for sarcasm sounds entertaining |
| 23:05 | <jgraham> | zewt: That was called Google Wave |
| 23:05 | <annevk> | dydx, sounds kind of odd |
| 23:05 | <jgraham> | and it sucked |
| 23:05 | <zewt> | ouch |
| 23:05 | <jgraham> | I mean threaded IRC |
| 23:05 | <annevk> | dydx, Microsoft has aligned with the spec before... but if you want it to be different just raise it on the mailing list |
| 23:05 | <jgraham> | Not a test for sarcasm |
| 23:05 | <zewt> | heh :P |
| 23:06 | <jgraham> | All UAs fail the <sarcasm> test since none takes a deep breath |
| 23:06 | <annevk> | dydx, this is a great start, but I'm not editing that spec at the moment so I might forget about it |
| 23:06 | <dydx> | annevk: Well, it looks like Microsoft has changed how these properites behave in standards mode such that they all return 0. |
| 23:06 | <jgraham> | In fact since breating is clearly device specific it has no place in a HTML spec |
| 23:07 | <jgraham> | *breathing |
| 23:07 | <dydx> | annevk: I don't have a strong objection to them being zero since they aren't consider boxes. |
| 23:07 | <gsnedders> | jgraham: I believe I made that argument in IRC when implementing it before. |
| 23:07 | <dydx> | annevk: I just wanted to make sure I was understanding the CSSOM spec, correcty with regards to "CSS layout box" |
| 23:08 | <jgraham> | When we get a CSS media for androids (i.e. humanoid robots) presumably there will be properties to control their breathing |
| 23:09 | <jgraham> | Anyway now I hav made the point in IRC, and knowing that many of the people who like to raise ISSUEs read the logs, I expect a bug by the morning and a request to escalate by the end of the month |
| 23:10 | <annevk> | dydx, I see; I guess I'll email myself saying to make that clearer |
| 23:10 | <annevk> | dydx, i.e. that column column-box does not give you a layout box or some such |
| 23:10 | hober | was seriously considering implementing </sarcasm>'s deep breath as (message "Taking a deep breath...") in the elisp parser |
| 23:10 | <TabAtkins> | hober: You didn't? |
| 23:11 | <hober> | TabAtkins: I haven't built the parser yet |
| 23:11 | <hober> | I'll let you know what I do when I get to it |
| 23:11 | <hober> | (I only have the tokenizer built at this point, and that needs some retooling before it'll really be useful) |
| 23:11 | <dydx> | annevk: Notice, Firefox returns non-zero values for these properties. I also have a test case on the bug <https://bug-15277-attachments.webkit.org/attachment.cgi?id=83230>; which can be used to compare the behavior in various browsers. |
| 23:12 | <annevk> | yeah, CSS is a big mess :) |
| 23:12 | <annevk> | I included a link to the logs in my email to myself |
| 23:12 | <dydx> | annevk: I am unclear from this disucssion, do you even want to consider having these offset properties return non-zero values for columns and column-groups? |
| 23:12 | <annevk> | sure if you want to |
| 23:12 | <annevk> | but then please email www-style |
| 23:13 | <jgraham> | hober: I am totally depending on you for a non-sucky HTML mode for emacs |
| 23:13 | <jgraham> | How can I make you work faster? :) |
| 23:13 | <annevk> | dydx, I have no strong opinion on what anything in the spec should say, I just wanted it defined somewhere |
| 23:14 | <annevk> | dydx, which is also why I work on it less than other specs; most other specs are not build on something so vague |
| 23:14 | <annevk> | (well, the ones I edit) |
| 23:14 | <hober> | jgraham: convince apple it's something I should do during the day. :) |
| 23:15 | <jgraham> | othermaciej: You should let hober make my life better :) |
| 23:15 | <dydx> | annevk: OK. What would you suggest we do at this time then for <https://bugs.webkit.org/show_bug.cgi?id=15277>;? I can hardcode these offset properties to return 0 for <col>s and <colgroup>s |
| 23:15 | <hober> | hahaha |
| 23:15 | <jgraham> | :) |
| 23:15 | hober | doesn't report to maciej |
| 23:15 | <jgraham> | Dammit |
| 23:16 | <dydx> | annevk: If you have an opinion on this. Otherwise, I'll think about it some more. |
| 23:16 | <hober> | but yeah, all that's been on hold during the pack / move / new job bit |
| 23:16 | <annevk> | dydx, aligning with Firefox might make sense |
| 23:16 | <jgraham> | hober: I will have to assume he is skilled at subtley manipulating the people you do work for |
| 23:16 | <hober> | I'm hoping to get back to it in the next month or so |
| 23:16 | <jgraham> | s/work for/report to/ |
| 23:16 | <annevk> | dydx, IE was converging with their model somewhat, and so is everyone else I have the feeling |
| 23:16 | <dydx> | annevk: OK. Then for your reference, this will be incompatible with both CSSOM and Opera |
| 23:16 | <annevk> | right |
| 23:16 | <jgraham> | hober: Seriously though, I look forward to it when it's done |
| 23:16 | <hober> | jgraham: well, he does chair a w3c wg, so clearly subtley manipulating things is high on his skill list :) |
| 23:17 | <hober> | yeah, me too |
| 23:17 | <annevk> | dydx, could you still please email www-style? :) |
| 23:17 | <jgraham> | And I totally understand moving/changing jobs/etc. killing side projects at least in the short term |
| 23:18 | <dydx> | annevk: sure, I can start a conversation about it on the list. |
| 23:18 | <annevk> | thanks |
| 23:18 | <annevk> | bedtime for me |
| 23:18 | <dydx> | annevk: thanks for your time |
| 23:21 | <hober> | jgraham: 22 boxes to go, and we'll be fully unpacked |
| 23:30 | <jgraham> | hober: You should paint them green and sit them on the wall |
| 23:30 | <TabAtkins> | Alternately: paint them cobblestone and do real-life minecraft. |
| 23:31 | <hober> | I'll run those plans by my wife and let you know what she says. :) |
| 23:38 | <Philip`> | hober: Implementing </sarcasm> is dangerous |
| 23:39 | <Philip`> | WebKit had a parser bug due to </sarcasm>, and if someone else implements it and has a bug then that'll be strong evidence that humour in specs is harmful :-( |
| 23:39 | <gsnedders> | Philip`: What bug? |
| 23:40 | <TabAtkins> | The instruction is "treat like an unrecognized tag", so I'm confused as to how that can cause a parser bug. |
| 23:41 | <Philip`> | They didn't treat it like an unrecognised tag |
| 23:41 | <Philip`> | https://bugs.webkit.org/show_bug.cgi?id=45645 |
| 23:41 | <gsnedders> | They took a deep breath and did nothing? |
| 23:41 | <TabAtkins> | Then they didn't follow the spec. |
| 23:41 | <Philip`> | (Does html5lib have a test case for this?) |
| 23:42 | <zewt> | this is perhaps my single favorite browser ticket: http://code.google.com/p/chromium/issues/detail?id=62435 |
| 23:42 | <gsnedders> | Philip`: If Adam pushed his test upstream, yes. |
| 23:45 | <gsnedders> | Philip`: Yes, he did. |