| 00:34 | <jamesr> | heycam: what on earth does "UTC format with millisecond resolution" mean? |
| 00:35 | <jamesr> | i assume it's supposed to be a number |
| 00:35 | <heycam> | jamesr, where does that appear? |
| 00:35 | <jamesr> | from jatinder's telecon notes |
| 00:35 | heycam | looks |
| 00:37 | <heycam> | the UTC format I'm not sure about, I don't remember that being mentioned |
| 00:37 | <heycam> | but the millisecond resolution is probably because we were discussing the use a monotonic clock value as opposed to Date.now() |
| 00:37 | <heycam> | and apparently Date.now() precision varies across implementations |
| 00:37 | <jamesr> | Date.now() also goes backwards |
| 00:37 | <heycam> | right |
| 00:38 | <jamesr> | i personally think the right thing to do is to define an interface for intervals that's unrelated to "real world" datetimes, and unaffected by system clock changes |
| 00:38 | <heycam> | that it goes backwards, and that it sometimes has less than 1ms accuracy were there arguments for exposing the monotonic clock value as the animationStartTime attribute |
| 00:38 | <heycam> | yes I agree |
| 00:38 | <jamesr> | and use it for all this |
| 00:38 | <jamesr> | need to find time to write an email describing it precisely |
| 00:38 | <heycam> | so that reference to "UTC format" I think is bogus |
| 00:38 | <jamesr> | cos there are some tricky bits |
| 00:39 | <AryehGregor> | Is it just me, or has almost none of the WHATWG cabal voted in the LC poll? http://www.w3.org/2002/09/wbs/40318/html5-last-call-poll/results |
| 00:40 | <AryehGregor> | . . . Was I really the first Google rep to respond? |
| 00:40 | <jamesr> | AryehGregor: i don't care about when w3c specs do or do not go to last call, so i haven't voted |
| 00:40 | <AryehGregor> | I don't care either as such, but the drama and hassle of the poll failing seems like it would be counterproductive, so I just voted yes across the board. |
| 00:41 | <jamesr> | what's the hassle of it failing? |
| 00:41 | <AryehGregor> | I expect it would waste some people's time needlessly. |
| 00:42 | <hober> | AryehGregor: I voted |
| 00:42 | <othermaciej> | people should vote |
| 00:43 | <othermaciej> | going to LC is good |
| 00:43 | <AryehGregor> | Why, exactly? |
| 00:43 | <othermaciej> | there are some people who may try to create drama over it |
| 00:43 | <othermaciej> | why is going to LC good? |
| 00:43 | <othermaciej> | I don't necessarily believe in the abstract values of W3C Process, but in material terms: |
| 00:44 | <othermaciej> | (1) Going to Last Call, especially on a large high-visibility spec, can result in a lot of really valuable review feedback |
| 00:44 | <othermaciej> | the SVG 1.2 Tiny Last Call stands out as one that generated a lot of comments |
| 00:44 | <AryehGregor> | "The HTML5 testing effort is making some progress thanks to Microsoft, Opera and others." I wonder how "Microsoft, Opera and others" was arrived upon. |
| 00:44 | <othermaciej> | (2) Going to Last Call signals momentum, which is valuable from a marketing perspective |
| 00:46 | <AryehGregor> | A lot of comments like this one? http://lists.w3.org/Archives/Public/www-svg/2004Oct/0088.html |
| 00:46 | <othermaciej> | heh :-) |
| 00:46 | <othermaciej> | well, in the end, SVG 1.2 Tiny is basically abandoned |
| 00:47 | <Philip`> | Since momentum is velocity times mass, and HTML5 is a massive spec, it doesn't need to be moving very fast |
| 00:47 | <othermaciej> | the WG is picking up from 1.1 instead afaict |
| 00:47 | <othermaciej> | so Hixie's comment was belatedly applied |
| 00:47 | <othermaciej> | in a way |
| 00:47 | <heycam> | othermaciej, there are some worthwhile improvements from 1.2T that will be brought over. but overall, yes, we're continuing evolution from 1.1 |
| 00:47 | AryehGregor | tries to think of some way to nitpick about the relativistic definition of momentum, but can't think of any good ones |
| 00:48 | <heycam> | (although I don't see why <video>/<audio> were less approriate for standardisation within svg than within html!) |
| 01:15 | <AryehGregor> | othermaciej, when would you expect that the W3C would start publishing an HTML6 draft with the new features that were kicked out of HTML5? |
| 01:15 | <othermaciej> | AryehGregor: I do not know |
| 01:16 | <AryehGregor> | Presumably long before HTML5 makes it to CR, unless the W3C wants to not participate in HTML development anymore after all. |
| 01:16 | <othermaciej> | AryehGregor: I believe we would likely have to recharter to do that, and the chairs asked to hold recharter discussions til after we get to LC |
| 01:16 | <othermaciej> | oh yes, my hope is that it's rather soon, though of course, I am not the only one with input |
| 01:21 | <jamesr> | Graham Klyne | Formally Object |
| 01:21 | <jamesr> | i didn't know that was a poll option |
| 01:22 | <roc> | jamesr, heycam: I don't think we should define a new timeline |
| 01:22 | <roc> | I think we should just use the Date.now() timeline |
| 01:22 | <jamesr> | roc: and have everything break when the clock changes? |
| 01:23 | <roc> | yeah |
| 01:23 | <roc> | because that's going to break Web pages anyway |
| 01:23 | <jamesr> | why not try to do better? |
| 01:23 | <roc> | so, don't do that |
| 01:23 | <heycam> | ES5 says "The now function return a Number value that is the time value designating the UTC date and time of the occurrence of the call to now." |
| 01:23 | <jamesr> | who are you directing not to do that? |
| 01:23 | <jamesr> | users with computers that use ntp? |
| 01:24 | <roc> | yep |
| 01:24 | <jamesr> | there's not a computer in the world with a clock that never adjusts |
| 01:24 | <roc> | my understanding is that usually those adjustments can be made without going backwards |
| 01:24 | <roc> | and if that's not true, it should be! |
| 01:24 | <jamesr> | in practice they are not |
| 01:24 | <roc> | then fix that |
| 01:25 | <jamesr> | you're gonna fix leap seconds for us? |
| 01:25 | <jamesr> | that sounds awesome! |
| 01:25 | <roc> | fixing that is actually easier than fixing all the Web pages (and other stuff, I suspect) that depend on Date.now and equivalents not going backwards |
| 01:25 | <jamesr> | well, i don't want to define a Date.now() equivalent either |
| 01:26 | <jamesr> | in some systems there's a distinction between datetime values, which correspond to real-world dates and times, and intervals |
| 01:26 | <roc> | I would handle leap seconds by just holding the clock constant for one second |
| 01:27 | <jamesr> | for animations and performance monitoring you care about intervals only |
| 01:27 | <roc> | it would actually be pretty trivial in the browser to record the last reported time and never report anything less than that |
| 01:27 | <roc> | that would handle most of the issues |
| 01:27 | <jamesr> | and most animation libraries do that for Date.now() |
| 01:27 | <roc> | if someone's clock is just wrong, well, you lose |
| 01:27 | <jamesr> | it's not useful for the performance monitoring case |
| 01:27 | <jamesr> | because it biases measurements |
| 01:27 | <roc> | for animations and performance monitoring you don't care about a 1-second pause once a year |
| 01:28 | <jamesr> | yes, but in the real world NTP clock adjustments are much more frequent than that |
| 01:28 | <jamesr> | ntp and other clock adjusting processes |
| 01:28 | <roc> | how frequent? and how large? |
| 01:28 | <jamesr> | there were quite a few reports of inconsistent timestamps from early navigation timing implementations |
| 01:29 | <jamesr> | i think typically on the order of seconds |
| 01:29 | <roc> | links? |
| 01:32 | <jamesr> | roc: here's one thread on the issue http://lists.w3.org/Archives/Public/public-web-perf/2011Apr/0029.html |
| 01:35 | <roc> | thanks |
| 01:35 | <roc> | the conclusion in that thread seems satisfactory |
| 01:35 | <jamesr> | another issue is that the APIs available to say "please tell me the current time relative to the unix epoch" are more expensive and less precise than the APIs for "please tell me how long it was since some point in this process' past" as the latter is often just reading off a cpu counter |
| 01:36 | <roc> | jamesr: I thought Chrome used a hybrid approach? |
| 01:36 | <roc> | a hybrid approach is easy enough to do |
| 01:36 | <jamesr> | yeah, but since we have to slew there can be some error |
| 01:36 | <roc> | that's similar to what Boris suggested and the thread concluded, really |
| 01:36 | <jamesr> | on windows the slewing error can accumulate into the measurable range |
| 01:37 | <roc> | We could use the same "document time" for animation too |
| 01:37 | <jamesr> | yeah, if such a thing existed |
| 01:37 | <jamesr> | something like 'milliseconds since the document was created, ignoring any changes to the system clock' |
| 01:38 | <roc> | I mean what that thread ended up concluding |
| 02:49 | <JoePeck> | is there any particular reason the "placeholder" attribute is a "must not" for <input type="number">? |
| 02:49 | <JoePeck> | http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state |
| 06:28 | <MikeSmith> | JoePeck: dunno, but I guess because it's not intended to be rendered as a text-input box |
| 06:28 | <MikeSmith> | but instead as a select-like control |
| 06:34 | <MikeSmith> | no Opera Next updates recently? |
| 06:35 | <Hixie> | othermaciej: (1) we're already getting about as much feedback as we can handle, so if announcing LC gives us more feedback, how do you propose we handle it? |
| 06:35 | <Hixie> | othermaciej: (2) HTML5 has no problem with marketing. It has too _much_ marketing, if anything. |
| 06:36 | <Hixie> | hsivonen: agreed on "shortcut"; file a bug and i'll make the spec say you can precede "icon" with "shortcut" |
| 06:49 | <othermaciej> | Hixie: if those are your sentiments then of course you are free to vote no, abstain, not vote, or whatever |
| 06:51 | <Hixie> | oh i wasn't presenting those as arguments to justify whatever i do with the poll, just responding to what you wrote |
| 06:51 | <Hixie> | i'm curious as to your answer to (1) though |
| 06:54 | <MikeSmith> | the main value of a last call round is that at the end of it we produce a formal record of the comments we received and how we responded to them |
| 06:55 | <MikeSmith> | so that we can prove to the W3C Director that we have done what we're supposed to, and so that we can get the director's approval to transition to CR |
| 07:40 | <hsivonen> | Hixie: ok |
| 07:46 | <hsivonen> | so far, polyglot and RDFa are the least consesus-enjoying deliverables on the poll |
| 08:08 | <othermaciej> | Hixie: so far I have yet to see an amount of feedback that you can't handle, but I suppose it is possible |
| 08:08 | <othermaciej> | Hixie: the drafts other than HTML5 itself have also not necessarily gotten the level of review and feedback that they should have |
| 08:09 | <zcorpan> | i know html4-differences needs proper review |
| 08:09 | <zcorpan> | i'm going through it myself to find omissions |
| 09:10 | <ifette> | Hixie: still up? |
| 09:11 | <ifette> | Hixie: The WebSocket protocol uses the term "CONNECTING" exactly once, to say that only one WebSocket connection may be in a CONNECTING state at any point in time |
| 09:11 | <ifette> | the definition is not given anywhere for what it means to be CONNECTING |
| 09:11 | <ifette> | As such, I'm either going to define the state of the WebSocket connection in the protocol, or just rip that out and leave that constraint for you to put in the API. |
| 09:12 | <ifette> | It's pretty trivial for me to define the state of the connection, so I'm happy to do that, but then it's potentially doubly defined (in both the protocol and the api). |
| 09:12 | <ifette> | E.g. I have now in the protocol text that says if the server's handshake is validated, the state of the WebSocket connection is OPEN |
| 09:12 | <ifette> | I don't think that conflicts with your text, but I'm not sure if it causes any problems... |
| 09:16 | <zcorpan> | ifette: i recall somebody pointing out that that DOS protection doesn't make sense for other applications of websocket |
| 09:17 | <zcorpan> | ifette: so maybe we should move it to the API spec |
| 09:28 | zcorpan | notes there are 6 issues on HTML5 that are OPEN |
| 09:28 | <zcorpan> | othermaciej: can we go to LC with OPEN issues? |
| 09:28 | <othermaciej> | zcorpan: yes |
| 09:28 | <zcorpan> | oh |
| 09:28 | <othermaciej> | zcorpan: er the timeline, they are all classified as LC issues rather than pre-LC issues |
| 09:29 | <othermaciej> | i.e. we are treating them as LC comments submitted early |
| 09:29 | <zcorpan> | ah, ok |
| 09:42 | <zcorpan> | Hixie, MikeSmith: which whatwg svn revision does http://dev.w3.org/html5/spec-LC/ correspond to? |
| 09:43 | <MikeSmith> | zcorpan: hang on, checking now |
| 09:44 | <MikeSmith> | r6139 |
| 09:45 | <zcorpan> | thanks |
| 09:45 | <hsivonen> | no new feedback about rel="" checking overnight |
| 09:45 | <hsivonen> | I guess this means that people *really* care about rel="shortcut icon" but not at all that much about the long tail of rel stuff |
| 09:47 | <hsivonen> | does anyone happen to have test cases for rel=" shortcut icon " or rel="icon shortcut" to see how those behave in IE? |
| 09:49 | <zcorpan> | good thing Julian is paying attention |
| 09:50 | <zcorpan> | MikeSmith: i didn't know spec-LC existed yet |
| 09:50 | <MikeSmith> | yeah |
| 09:51 | <hsivonen> | it seems that Chrome's autoupdater manages to move users from the old version to the new version in about 10 days |
| 09:52 | <hsivonen> | I wonder how many days it takes for other browsers |
| 09:52 | <hsivonen> | Opera and Safari would be particularly interesting |
| 09:52 | <hsivonen> | so far, Firefox and IE seem to take > 365 days :-( |
| 09:54 | <hsivonen> | maybe that's not a totally fair comparison considering how the updates have been offered to users of old Firefox and IE versions |
| 09:54 | <hsivonen> | but the end result is that Firefox 3.5 and 3.0 as well as IE7 and IE6 are still in the top 12 browser versions |
| 09:54 | <jgraham> | It is presumably entirely a result of the fact that Chrome doesn't ask it just does |
| 09:55 | <hsivonen> | jgraham: yes |
| 09:55 | <hsivonen> | clearly, asking the user is bad for the Web |
| 09:55 | <jgraham> | And of the fact that the corporate penetration of Chrome is rather small |
| 09:56 | <jgraham> | It is a high risk strategy of course |
| 09:56 | <ifette> | jgraham: for corporations, they can deploy a group policy (in windows) to control chrome updates should they choose |
| 09:56 | <jgraham> | If you make an update that people don't like they will be very annoyed |
| 09:57 | <jgraham> | ifette: Right, but my point is that if there was a high level of chrome usage in those situations the average update time would go up as a result |
| 09:57 | <hsivonen> | jgraham: the alternative is that people run vulnerable versions (worse than annoyance) or that old versions need to get security patches forever |
| 09:57 | <jgraham> | hsivonen: Oh I agree from the user point of view |
| 09:57 | <hsivonen> | jgraham: does Opera have multiple concurrent security patch tracks for desktop? |
| 09:57 | <ifette> | or that you never get to use any of the cool new HTML5 features because old browsers stay around forever :) |
| 09:58 | <MikeSmith> | zcorpan: about finding omission in the diffs doc, http://goo.gl/EOq6H is a list of resolved validator.nu bugs and might be useful for compasion |
| 09:58 | <MikeSmith> | zcorpan: comparison purposes |
| 09:58 | <hsivonen> | jgraham: that is, if you are running Opera and want to run a security patched browser, what choices do you have except to always install latest Opera or to quit running Opera and to subscribe to another browser's patch stream? |
| 09:59 | <jgraham> | hsivonen: Well I'm not sure what the policy is or whether I could tell you if I was sure :) |
| 09:59 | <MikeSmith> | zcorpan: as far as changes made to the validator.nu backend in response to spec changes |
| 09:59 | <hsivonen> | I wonder what happens when Chrome changes the UI in a noticeable way for the first time |
| 10:00 | <ifette> | hsivonen: we've already changed it multiple times. I'm running Chrome 13, and it looks rather different than Chrome 0.2. |
| 10:00 | <ifette> | One could ask the same question of what happens when we change google.com or gmail.com |
| 10:01 | <hsivonen> | ifette: hmm. I haven't noticed any UI changes |
| 10:01 | <jgraham> | hsivonen: There have been some that I noticed but they are rather subtle |
| 10:01 | <hsivonen> | ifette: but I don't run Chrome as my main browser so I don't pay as much attention as a primary user might |
| 10:01 | <ifette> | look at wikipedia for screenshots :) new tab page, going from two menus (wrench + page) to one (wrench) |
| 10:01 | <ifette> | etc |
| 10:02 | <zcorpan> | MikeSmith: thanks |
| 10:02 | <ifette> | With Chrome we chose to be more like the web than desktop software. You don't get to choose to run an old version of gmail, you don't worry about updating, etc. |
| 10:02 | <jgraham> | It's pretty clear as a model that it allows you to quickly move to local maxima |
| 10:02 | <hsivonen> | ifette: with google.com I wish Google didn't offer old versions, so we wouldn't have the problem of Google sending an old google.com UI to a new version of Firefox :-) |
| 10:03 | <zcorpan> | MikeSmith: it's still ok for me to fix bugs in html5-differences right? |
| 10:03 | <ifette> | :) touche |
| 10:03 | <jgraham> | It's not really clear what happens if you try to do something like Skype or Winamp |
| 10:03 | <MikeSmith> | zcorpan: yeah, it's separate from the LC poll |
| 10:03 | <jgraham> | And change the UI in big ways that not everyone appreciates |
| 10:03 | <zcorpan> | MikeSmith: ok |
| 10:04 | <ifette> | jgraham: it happens one way or another. It's really no longer practical to run Office 2000 or Office 97, and yet I hate the new office UI with the giant button. At the end though, I don't really have a choice. |
| 10:04 | <ifette> | There's some differences in how long the old versions last |
| 10:04 | <ifette> | but eventually, the old versions go away. |
| 10:04 | <hsivonen> | ifette: you could run LibreOffice and hate the UI even more |
| 10:04 | <ifette> | lol |
| 10:04 | <jgraham> | ifette: I bet there are still people running old office for just that reason |
| 10:05 | <ifette> | May god have mercy on their computers' souls |
| 10:05 | <jgraham> | There are probably people still running Wordperfect for DOS |
| 10:05 | ifette | hides his terminal with vi open... |
| 10:05 | <jgraham> | Well quite :) |
| 10:07 | <jgraham> | Anyway, to be clear, I think that fast-upgrading users is good. But there are definite downsides |
| 10:08 | <ifette> | There's downsides to everything in life. I want to bring a Durian into the office and eat it because it's tasty, but everyone around me would probably barf and/or hate me for the year that the smell lingers... |
| 10:08 | <ifette> | :) |
| 10:13 | <hsivonen> | looks like 40% of Opera usage comes from non-latest version |
| 10:19 | <hsivonen> | doh. I can't do math. more like 30% |
| 10:20 | <hsivonen> | better than the situation with Firefox, it seems |
| 10:32 | <zcorpan> | what does xhr do if you do a same-origin request that redirects to a different origin? |
| 10:33 | <hsivonen> | is chaals asking about the LC vote on public-html? or about some other vote? |
| 10:34 | hsivonen | thought the chairs wanted every person to respond individually to the LC poll |
| 10:35 | <jgraham> | hsivonen: He is asking about the LC vote |
| 10:36 | <jgraham> | AIUI he is asking how the votes from individuals relate to the votes from Members in the case where individuals are representatives of those Members |
| 10:36 | <hsivonen> | oh. right. doh. I already responded and thought this was by person |
| 10:37 | <jgraham> | Which seems like a reasonable question because I don't think we have had a poll previously where Member opinions were sought and individuals were also allowed to vote |
| 10:37 | <hsivonen> | jgraham: indeed. this is very confusing |
| 10:38 | <jgraham> | (I infer that Member opinions are being sought since we need N Members to vote to reach quorum) |
| 10:38 | <jgraham> | (But the operation of this poll is quite opaque to me) |
| 10:43 | <othermaciej> | I believe our intent is to count the number of Members responding for purposes of quorum |
| 10:43 | <othermaciej> | so people who are affiliated with various Member orgs should feel free to respond individually and independently |
| 10:45 | <hsivonen> | othermaciej: you "believe"??? |
| 10:45 | <jgraham> | othermaciej: Why? Why not one vote per Member if that's what you plan to count? |
| 10:46 | <matjas> | zcorpan: “con for <!--[if IE]><html class=ie><![endif]-->: conditional comments before X-UA-Compatible meta makes IE ignore the meta, IIRC.” → Thanks! Let’s see if I can find a link |
| 10:46 | <hsivonen> | othermaciej: FWIW, I thought the poll was per-person when I responded, because the polling system wasn't in the per-Member mode |
| 10:46 | <othermaciej> | hsivonen: I am qualifying my statement because I did not actually draft the poll |
| 10:46 | <hsivonen> | i.e. the system said "you are identified as Henri Sivonen" |
| 10:46 | <othermaciej> | so I don't want anyone to get mad at me if they disagree |
| 10:46 | <othermaciej> | but… it says: |
| 10:47 | <othermaciej> | "Since Last Call publication is necessary for progress of the group and this is a non-technical question, we will decide it by counting votes. A quorum for these votes is at least 50 working group participants, including at least half of the 54 participating W3C member organizations. Provided we have a quorum and at least 2/3rds of the non-blank votes are 'yes', the question carries." |
| 10:47 | <hsivonen> | as opposed to saying "you are identified as Henri Sivonen representing Mozilla Foundation" |
| 10:47 | <othermaciej> | the relevance of citing that this is a non-technical question is that this is the Process criterion for whether votes are by individual or by org |
| 10:47 | <hsivonen> | huh? |
| 10:48 | hsivonen | goes read the Process |
| 10:49 | <hsivonen> | othermaciej: can you point me to the relevant part of the Process? |
| 10:50 | <othermaciej> | more relevantly: Paul Cotton is the one who did draft it, and he encouraged multiple Microsoft employees to respond, so I think it is very likely that he would agree with my interpretation |
| 10:50 | <othermaciej> | http://www.w3.org/2005/10/Process-20051014/policies.html#Votes |
| 10:51 | <othermaciej> | "A group may also vote to make a process decision. For example, it is appropriate to decide by simple majority whether to hold a meeting in San Francisco or San Jose (there's not much difference geographically)." |
| 10:51 | <jgraham> | I don't think the real question is "can multiple individuals from the same Member respond", since clearly it is set up so they can |
| 10:51 | <othermaciej> | going to LC is a process decision |
| 10:51 | <jgraham> | I think the question is "what do the votes mean in this case" |
| 10:52 | <othermaciej> | "Given that there is a formal vote from a member organisation, is it OK for other employees of that organisation to give individual votes (as would be the case if they were just invited experts)?" |
| 10:52 | <othermaciej> | that was the question on public-html |
| 10:52 | <othermaciej> | the short answer is "yes" |
| 10:52 | <jgraham> | Right. I agree with that |
| 10:52 | <othermaciej> | the longer answer is "yes, it is not only ok, but encouraged" |
| 10:52 | <jgraham> | I still don't understand why it has been set up this way |
| 10:52 | <othermaciej> | the longer than that answer is that we will count the individual votes |
| 10:53 | <othermaciej> | the odd quorum requirements and 2/3 threshold were picked to match the survey for when HTML5 published its FPWD |
| 10:53 | <jgraham> | Right and that is confusing because individuals representing Members aren't really independent votes in most cases |
| 10:54 | <jgraham> | So on questions where there is explicit vote counting going on having a Member's influence weighted by its number of participants seems strange |
| 10:55 | <othermaciej> | http://www.w3.org/2002/09/wbs/40318/wd-html5-spec/ |
| 10:56 | <othermaciej> | the intent was to match this |
| 10:56 | <othermaciej> | note, that survey was counted by individual, though organizational quorum was also checked |
| 10:57 | <othermaciej> | I suppose in one respect we failed, because that survey was set up to be by-org |
| 10:57 | <othermaciej> | I will have to get back to you |
| 10:57 | <jgraham> | Yes, that survey has the setup I would expect |
| 10:57 | <jgraham> | Or at least closer to it |
| 10:59 | <hsivonen> | othermaciej: FWIW, if the Chairs decide to run this in a per-Member mode, I think a new poll set up the right way and with a deadline further in the future would be appropriate |
| 11:00 | <othermaciej> | I will check with my co-chairs to make sure I am not confused about the intent |
| 11:00 | <hsivonen> | othermaciej: for example, I won't be around to revise my response to defer to dbaron before the deadline, since I'll be away from office Fri-Sun |
| 11:01 | <othermaciej> | I will certainly advocate that if we change the survey midstream, we also extend the deadline |
| 11:01 | <othermaciej> | your concern is understandable |
| 11:03 | <hsivonen> | fwiw, this is now the second poll in a row where the instructions have confused me |
| 11:04 | <hsivonen> | it could be that my reading comprehension really sucks and that I should go into a more lawyerly mode when reading the poll instructions |
| 11:04 | <hsivonen> | or it could be that the Chairs post really confusing instructions |
| 11:04 | <othermaciej> | what was the last poll where the instructions confused you? |
| 11:05 | <hsivonen> | othermaciej: the wording about choosing "one option" |
| 11:05 | <hsivonen> | othermaciej: which turned out to mean that the response to each question was in a radio button mode |
| 11:05 | <hsivonen> | othermaciej: but I initially thought it had some bearing across questions |
| 11:06 | <othermaciej> | which poll was this? |
| 11:06 | <hsivonen> | maybe my reading comprehension indeed simply sucks |
| 11:06 | <othermaciej> | the license one? |
| 11:06 | <hsivonen> | othermaciej: the license poll |
| 11:06 | <othermaciej> | ok |
| 11:06 | <othermaciej> | for future polls, I will try to read the wording with my human interface designer hat on |
| 11:25 | jgraham | will respond to the poll as an individual for now |
| 11:43 | zcorpan | has voted |
| 12:12 | <jgraham> | If I have an interface with a caller that accepts DOMString and another that accepts a long and I call an object implementing the interface with an object that has both a valueOf and a toString method, what gets called? |
| 12:13 | <jgraham> | That is one interface, two methods on that interface implementing callers for different types |
| 12:13 | <jgraham> | heycam|away: ^ |
| 12:14 | <zcorpan> | so why is <fieldset name> valid but <img name> is not? |
| 12:19 | <Lachy> | jgraham, WebIDL has a note about that ambiguity |
| 12:20 | <jgraham> | In related news, why are we adding callers for named properties to new APIs? |
| 12:20 | <jgraham> | No one should be using callers there anyway |
| 12:20 | <jgraham> | Lachy: Pointer? |
| 12:20 | <Lachy> | http://dev.w3.org/2006/webapi/WebIDL/#dfn-distinguishable |
| 12:20 | <Lachy> | See the note just below that |
| 12:22 | <jgraham> | The spec should just Do The right Thing in this specific case |
| 12:23 | <jgraham> | Which is to act like property lookup and prefer index properties |
| 12:23 | <jgraham> | But also, we shouldn't add any more of these caller s |
| 12:59 | <zcorpan> | anyone have input on http://www.w3.org/Bugs/Public/show_bug.cgi?id=12689 ? |
| 13:28 | <smaug____> | huh Google instant is just terrible |
| 13:35 | <hsivonen> | smaug____: how? |
| 13:36 | <smaug____> | hsivonen: when you move mouse over the result page, all sorts of popup-like things are shown |
| 13:36 | <smaug____> | (the preview of the pages) |
| 13:37 | <smaug____> | if I know which link I'm going to click, I don't want to see any those previews |
| 13:37 | <smaug____> | they just slow down user interaction |
| 13:38 | <hsivonen> | smaug____: I think that feature is called something other than "instant" |
| 13:39 | <hsivonen> | (I don't get it on my "instant") |
| 13:39 | <Philip`> | It's the Google Slower feature |
| 13:39 | <zcorpan> | Google Ininstant |
| 13:40 | <smaug____> | hsivonen: well, I managed to disable that feature by disabling google instant |
| 13:40 | <smaug____> | Philip`: indeed |
| 13:47 | <hsivonen> | looks like Graham Klyne accidentally Formally Objected again to the alt doc |
| 13:50 | <hsivonen> | I wonder which validator bug I should fix next... |
| 13:50 | <zcorpan> | new xml parser? |
| 13:51 | <zcorpan> | hmm i want anolis xdoc xref for http://www.w3.org/Bugs/Public/show_bug.cgi?id=12696 |
| 13:51 | <jgraham> | "being told my document is invalid is demeaning and negatively affects my self-worth"? |
| 13:52 | jgraham | presumes hsivonen has at least one bug report like that |
| 13:52 | Philip` | wonders if a validator's error messages could have a "shut up, I know you don't like this but I'm doing it anyway due to compatibility or laziness or whatever" button next to them, which hides those messages for that user and also provides statistics that can inform updates to the spec's conformance requirements |
| 13:53 | <Philip`> | jgraham: Maybe the validator should always return either "valid" or "not valid yet", to sound more positive |
| 13:59 | <jgraham> | "Your document conforms to a unique syntax that you just invented! Aren't you clever!" |
| 14:00 | <mpilgrim> | jgraham: that's what XHTML2 Modularization was all about |
| 14:02 | <mpilgrim> | Philip`: "your document is a unique snowflake and it deserves to be loved just the way it is" |
| 14:02 | <hsivonen> | frankly, I expected to see more action at http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions over the first 24 hours |
| 14:03 | <hsivonen> | I guess I'm misestimated the level of interest in this stuff |
| 14:03 | <zcorpan> | hsivonen: clearly your next validator task must have more bang for the buck |
| 14:04 | <hsivonen> | zcorpan: "whine about implied tags" might be it, then |
| 14:05 | <mpilgrim> | interest will pick up once people realize what crazy shit got cut from the spec |
| 14:05 | <zcorpan> | good candidate |
| 14:05 | mpilgrim | checks to see if feelgoodvalidator.org is available |
| 14:05 | <mpilgrim> | hixie always said he wanted competing validators |
| 14:05 | <mpilgrim> | not sure this is what he meant |
| 14:06 | <jgraham> | Did he ever say he wanted them to compete on accuracy? |
| 14:06 | hsivonen | tries to figure out if Content-Language is valid this week |
| 14:06 | <hsivonen> | it's not, it seems |
| 14:06 | <zcorpan> | mpilgrim: will it play "aow, i feel good, dadadadadadada" when it validates? |
| 14:07 | <mpilgrim> | no, because html5 audio is a clusterfuck and i refuse to use flash |
| 14:07 | <hsivonen> | oh cool. MikeSmith has already fixed that one |
| 14:07 | <zcorpan> | use <bgsound> |
| 14:07 | <MikeSmith> | hsivonen: which one? |
| 14:07 | <hsivonen> | MikeSmith: Content-Language |
| 14:08 | <hsivonen> | MikeSmith: making it invalid |
| 14:08 | <MikeSmith> | ah |
| 14:08 | <mpilgrim> | so, i honestly haven't been paying attention. has the w3c published their obsolete version of html yet? |
| 14:08 | <MikeSmith> | yeah |
| 14:08 | <zcorpan> | mpilgrim: no |
| 14:08 | <zcorpan> | mpilgrim: 24th |
| 14:08 | <mpilgrim> | really? |
| 14:08 | <mpilgrim> | wow |
| 14:08 | <zcorpan> | if the poll carries |
| 14:09 | <mpilgrim> | is that the final obsolete version, or just another interim obsolete version? |
| 14:09 | <MikeSmith> | hsivonen: I guess I forgot to close that bug |
| 14:09 | <MikeSmith> | hsivonen: oh, or I think I flied a duplicate bug for it myself |
| 14:09 | <zcorpan> | mpilgrim: i assume the latter |
| 14:10 | <mpilgrim> | ok, now that my books' repositories are working again, the #1 request in my inbox is to mention that non-Opera browsers finally support form validation of required fields |
| 14:14 | <mpilgrim> | damn, github is fast |
| 14:26 | <hsivonen> | for the sizes attribute, are these both valid: sizes="any any" and sizes="any 42x42"? |
| 14:27 | <hsivonen> | "The values must all be either an ASCII case-insensitive match for the string "any", or a value that consists of two valid non-negative integers that do not have a leading U+0030 DIGIT ZERO (0) character and that are separated by a single U+0078 LATIN SMALL LETTER X or U+0058 LATIN CAPITAL LETTER X character." |
| 14:27 | <hsivonen> | does that mean that all the values have to be "any" or all the values have to be of the form 42x42? |
| 14:27 | <hsivonen> | or does it mean that they all must be of either form? |
| 14:29 | <hsivonen> | also, is sizes only valid if rel contains the keyword icon? |
| 14:29 | <hsivonen> | what about apple-touch-icon if someone registers it? |
| 14:29 | <hsivonen> | Hixie: ^ |
| 14:39 | Philip` | reads it as "The values must each be [either X or Y]", not "The values must either [all be X] or [all be Y]", and doesn't think he would have thought to interpret it the other way |
| 14:40 | <Philip`> | (not that I'd disagree with disambiguating it) |
| 14:41 | <hsivonen> | hmm. glazou voted to no advancing HTML5 to LC |
| 14:41 | <hsivonen> | citing longdesc as the first thing |
| 14:41 | <kost-bebix> | Hi everyone! When I do a simple test with html5lib with none tree builder set -- it returns me None (instead of simpletree). Why? http://paste.pocoo.org/show/391813/ |
| 14:44 | <othermaciej> | I didn't know he was a longdesc fan |
| 14:47 | <othermaciej> | "This document does not meet the quality level of other LCWDs in the Consortium." |
| 14:47 | zcorpan | would like to extend mpilgrim's question with "why do we have a longdesc attribute?" |
| 14:48 | <MikeSmith> | kost-bebix: dunno, but maybe because if don't tell it what tree builder to use, it doesn't actually build a tree |
| 14:48 | <MikeSmith> | or do the docs say it defaults to using simpletree? |
| 14:49 | <kost-bebix> | MikeSmith: yeah, but it's first example from http://code.google.com/p/html5lib/wiki/UserDocumentation :-) |
| 14:49 | <MikeSmith> | ah |
| 14:49 | <kost-bebix> | I mean, html5lib.parseFragment(u'<a href="asd">dsa</a>') |
| 14:50 | <kost-bebix> | returns None |
| 14:50 | zcorpan | concludes that <html> does not belong in "changed elements" |
| 14:50 | <kost-bebix> | anyway, I think you always need a custom DOM builder |
| 14:50 | <kost-bebix> | so I'll just skip that |
| 14:51 | <zcorpan> | mpilgrim: why do we have a longdesc attribute? |
| 14:52 | <mpilgrim> | is that a serious question? like "why do we have an <img> element" kind of question? |
| 14:53 | <mpilgrim> | i don't know. i'd have to do some archaeology |
| 14:53 | <zcorpan> | it is :) |
| 14:53 | <othermaciej> | my vague understanding of the history is: |
| 14:53 | <mpilgrim> | at one point i tried to do some research into why we have a table summary attribute |
| 14:53 | <othermaciej> | alt was originally added as an attribute, because img was already a void element |
| 14:53 | <mpilgrim> | it was added between drafts and no one knows why |
| 14:53 | <othermaciej> | then people realized this didn't allow markup in the fallback |
| 14:53 | <othermaciej> | so longdesc was the patch |
| 14:54 | <mpilgrim> | people were already using d-links (literally, a link with the single character "d" as the link text) to point to a longer description |
| 14:54 | <othermaciej> | indeed |
| 14:54 | <mpilgrim> | so the use of a URL instead of inline text was probably informed by that as well |
| 14:55 | <mpilgrim> | but i don't know how much discussion there was of the exact semantics, or where that discussion took place |
| 14:55 | <hsivonen> | https://twitter.com/#!/manusporny/status/71212215612620800 |
| 14:56 | <mpilgrim> | based on my table summary research, my educated guess would be "somebody thought of it and they spent 5 minutes discussing the name of the attribute and then they put it in and that was that" |
| 14:56 | <mpilgrim> | but i'm cynical that way |
| 14:56 | <hsivonen> | check out what the tweetworthy embedded data actually is |
| 14:56 | <mpilgrim> | bbiab, meeting |
| 14:58 | <zcorpan> | mpilgrim: it has caused considerably more time afterwards. with that in mind we should probably be careful when adding new stuff to the spec |
| 14:59 | Philip` | likes how most of the structured data is in an rdfs:comment with only whitespace between values and following keys so the only reasonable way to parse it is with regexps |
| 15:02 | <zcorpan> | i don't like having "The head element no longer allows the object element as child." in Changed Elements because i don't want to enumerate all content model changes in Changed Elements |
| 15:02 | <Philip`> | Am I misreading the markup, or is it using rel="gr:..." mostly in places outside of the element that declares xmlns:gr so it should be treated as an unbound prefix? |
| 15:16 | <hsivonen> | Philip`: you are not misreading |
| 15:17 | <Philip`> | What's the RDF.rb Distiller doing, then? |
| 15:18 | <Philip`> | Ignoring prefix bindings entirely? |
| 15:18 | <hsivonen> | Philip`: dunno |
| 15:22 | <linclark> | Philip`: sorry, I missed the link you are referring to, but I might be able to help... which page was it? |
| 15:25 | <hsivonen> | linclark: http://xn--fwg.ws/rdfafail |
| 15:26 | <Philip`> | hsivonen: Opera refuses to open that URL |
| 15:27 | <hsivonen> | Philip`: RFCs are fun |
| 15:27 | <hsivonen> | Philip`: either Opera is wrong or the .ws registry has issues domains that violate IDN |
| 15:28 | <linclark> | Philip`: I checked that with mark birbeck's RDFa parser and it looks like the prefix is actually bound for all the instances it catches. I'll look at the markup to see what is going on |
| 15:28 | <wilhelm> | Philip`: opera:config#Network|IDNAWhiteList |
| 15:29 | <hsivonen> | linclark: gr:typeOfGood is unbound |
| 15:29 | <wilhelm> | :no:jp:de:se:kr:tw:cn:at:dk:ch:li:museum:hu: are whitelisted. But failing to load the punycode URL sounds odd. |
| 15:30 | <Philip`> | wilhelm: Oh, okay, so it's not just Opera objecting to URLs that express negative feelings towards RDFa |
| 15:31 | <hsivonen> | Philip`: is a claim of RDFa FAIL a negative feeling if it is an objective observation? |
| 15:32 | <wilhelm> | Negative feelings backed by objective observation are the best. |
| 15:32 | <linclark> | one problem with the example itself I believe is that it has no mapping for the currency prefix |
| 15:33 | <linclark> | that is coming back as unmapped for me using Check RDFa |
| 15:34 | <hsivonen> | wilhelm: I admit to having negative feelings about RDFa but they are backed by objective observations |
| 15:35 | <hsivonen> | in other news, people on twitter see Chrome's and Opera's close relationship with Flash in an Apple context |
| 15:35 | <linclark> | ok, took me a while to find it in Check RDFa, but typeOfGood is coming back as bound in that. I'll check the markup |
| 15:37 | <hsivonen> | should I bother fixing <style scoped> bugs in the validator? when are we going to drop <style scoped> from the spec? |
| 15:46 | <Lachy> | is there a plan to drop style scoped from the spec? |
| 15:46 | <linclark> | Philip`: honestly, from the markup it seems like you should be right about them being unbound. I'm not sure why the Check RDFa parser returns them as bound. I've asked in swig, will ping here if I get a reply |
| 15:47 | <hsivonen> | Lachy: there probably should be unless there's a plan to implement it |
| 15:53 | <Lachy> | hsivonen, my assumption is that browsers will implement it along with support for the :scope pseudo-class, for which there does seem to be interest in implementing |
| 15:54 | <othermaciej> | Lachy: when we come up with our CR exit criteria, if style scoped still has no implementations then it should be listed as "at risk" |
| 15:54 | <othermaciej> | (in my opinion anyway) |
| 15:55 | <Peter`> | afaik there are plans to implement <style scoped> in WebKit as it's needed for XBL2 |
| 16:02 | <Lachy> | othermaciej, yes, for CR, I agree. But I don't think it should be dropped yet |
| 16:02 | <othermaciej> | well listing as "at risk" doesn't even mean dropping it for CR |
| 16:03 | <Lachy> | I know |
| 16:11 | <linclark> | Philip`: you were right, the prefix should be unmapped |
| 16:11 | <linclark> | it seems RDF .rb and Check RDFa are lax. But those triples wouldn't be registered in any23 or rapper |
| 16:29 | <Philip`> | linclark: Ah, good to know RDFa consumers are no more reliable than RDFa producers :-) |
| 16:30 | <linclark> | Philip`: yeah, it's unfortunate because it makes it hard to tell if you really wrote compliant RDFa. btw, do you know if there are any implementations of microdata consumers yet? |
| 16:30 | <Lachy> | dglazkov, (or anyone else working on webkit) did you end up implementing pseudo-elements in WebKit for <details> and <summary> support? |
| 16:30 | <Philip`> | linclark: I have no idea |
| 16:31 | <dglazkov> | Lachy: yep |
| 16:31 | <Lachy> | what are they? |
| 16:32 | <Lachy> | I tried the ones mentioned in bug 56967, but they don't seem to work in the latest webkit nightly |
| 16:33 | <dglazkov> | Lachy: there's -webkit-details-marker |
| 16:34 | <karlcow> | doh. Lachy. Formal objection… sigh |
| 16:34 | <Lachy> | karlcow, ? |
| 16:34 | <dglazkov> | Lachy: and that's it at the moment |
| 16:34 | <Lachy> | ok |
| 16:35 | <dglazkov> | Lachy: look here for implementation details: http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/HTMLDetailsElement.cpp |
| 16:35 | <dglazkov> | http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/HTMLSummaryElement.cpp |
| 16:35 | <Lachy> | then at this stage, that won't be too incompatible with Opera's plans to reuse list-item and implement ::marker |
| 16:35 | <karlcow> | Formal Objection should be only reserved in very strong technical case. The way it is used in HTMLWG is mesmerizing |
| 16:35 | <dglazkov> | Lachy: probably |
| 16:35 | <dglazkov> | FTDRswaqjuKMOOOOGHFDGFFRTAAA |
| 16:35 | <dglazkov> | oops |
| 16:35 | <dglazkov> | sorry was cleaning my keyboard |
| 16:36 | <Lachy> | dglazkov, though, I'd like still like to get some clearer feedback from you about why you think the shadow DOM approach is better than reusing list-item styles? |
| 16:39 | <dglazkov> | Lachy: because it fits pretty well conceptually. |
| 16:39 | <dglazkov> | Lachy: and honestly I don't really understand list-item approach. I tried chewing on the wall of text you sent earlier, but a tl;dr monkey distracted me |
| 16:40 | <Philip`> | karlcow: Presumably it's used because the only objections that anyone takes seriously are Formal Objections and "I can't live with this", and nobody wants to have to die after losing a decision so they go with an FO |
| 16:42 | <Lachy> | dglazkov, the aim of the list-item approach is simply to make implementation as simple as possible, reusing as much existing CSS implementation as we can, and avoid the various problems we encountered when experimenting with shadow-dom elements for this |
| 16:42 | <karlcow> | silly |
| 16:43 | <sydlawrence> | Repurposing the Hash Sign for the New Web http://www.w3.org/2001/tag/2011/01/HashInURI-20110115 Anyone have any thoughts on this? |
| 16:44 | <dglazkov> | Lachy: .. and I basically say that if there are problems with using shadow DOM, they are bugs we need to fix :) |
| 16:47 | <dglazkov> | Lachy: shadow DOM is my hammer, and by golly these nails are going in |
| 16:49 | <othermaciej> | the shadow knows |
| 16:49 | <dglazkov> | :) |
| 16:50 | <dglazkov> | Lachy: overall, the shadow DOM-based design fits the spirit of other controls in WebKit better |
| 16:50 | <dglazkov> | Lachy: so perhaps it's a tactical decision |
| 16:51 | <Lachy> | dglazkov, webkit still seems to be doing some magic to make the marker stick to the same line as the summary, even when the summary is styled with display: inline; |
| 16:52 | <Lachy> | It doesn't address the issue of <summary>Summary</summary> vs. <summary> Summary</summary> (note the space, which gets inserted into the rendering where it probably shouldn't) |
| 16:52 | <dglazkov> | Lachy: there shouldn't be any magic -- but there could be bugs |
| 16:53 | <dglazkov> | and if the bugs are advanced enough, they are indistinguishable from magic |
| 16:54 | <Lachy> | dglazkov, in fact, it's not possible to style: summary { display: inline; } since it's always seems to be treated as inline-block or something like that; |
| 16:56 | <Lachy> | dglazkov, see http://software.hixie.ch/utilities/js/live-dom-viewer/saved/999 |
| 16:59 | <Lachy> | dglazkov, all those problems I can find with webkit's implementation are avoided using the approach I suggested, since it doesn't introduce any magic, nor rely on a partial/buggy XBL2 or other shadow dom implementation |
| 17:02 | <zcorpan> | hsivonen: i brought up tinyarrows.ws not working in opera with some of our developers and he said they were invalid according to IDNA2008 because they contained punctuation, or something |
| 17:07 | <dglazkov> | Lachy: the new shadow DOM in WebKit is pretty young. We'll fix those bugs. I still don't understand what you say by "magic" |
| 17:08 | <Lachy> | dglazkov, what I mean is that your rendering implementation is doing things that are not fully describable with CSS, and which apparently cannot be overridden with author styles. |
| 17:08 | <dglazkov> | Lachy: if it does, it's a bug |
| 17:08 | <dglazkov> | Lachy: and I am sure there are plenty |
| 17:09 | <dglazkov> | shadow DOM's whole point is that it does not do magic |
| 17:09 | <dglazkov> | from my point of view, the list-item-based impl is the one that has magic |
| 17:10 | <dglazkov> | though this magic is encapsulated into CSS |
| 17:11 | <Lachy> | given it's apparent immaturity though, the unnecessary complexity introduced, and that what you've done with details/summary right now looks like it's going to force us to end up with a mess like the fieldset/legend styling issues, it seems better to avoid the whole issue by taking a simpler approach |
| 17:12 | <dglazkov> | Lachy: how will we end up with fieldset/legend styling issues? |
| 17:12 | <othermaciej> | I would like it if <details> could be implemented with pure CSS |
| 17:12 | <othermaciej> | seems hard to do that if you want nice animations and everything |
| 17:13 | <hsivonen> | zcorpan: It will be interesting to see who caves in first: Opera or registries issuing non-compliant names |
| 17:13 | <Lachy> | dglazkov, because there are cases where it is currently impossible to restyle, and because even when those issues are fixed, there are still undesirable consequences that can all be avoided |
| 17:13 | <othermaciej> | I tried to do it once and the two blockers were inability to address text node children of an element with a selector, and inability to animate to/from auto values in CSS transitions |
| 17:13 | <dglazkov> | othermaciej: shadow DOM supports animations. I am not sure what the distinction here is between pure and impure CSS |
| 17:13 | <othermaciej> | dglazkov: I mean that the rendering of <details> could in theory with a few extensions be implemented solely as rules in the CSS stylesheet |
| 17:14 | <othermaciej> | with no need for a shadow DOM or any custom renderers |
| 17:14 | <othermaciej> | right now I think details/summary in webkit have custom renderers |
| 17:14 | <zcorpan> | hsivonen: yeah |
| 17:14 | <othermaciej> | "div" is an example of an element where the default rendering is defined purely in the stylesheet, mapping to generic CSS rendering |
| 17:15 | <dglazkov> | othermaciej: these just need to be yanked out |
| 17:15 | <othermaciej> | it is cool when more elements can do that |
| 17:15 | <zcorpan> | hsivonen: my guess is that we will continue to follow the spec and only adjust for compat based on how many bugs we get |
| 17:15 | <Lachy> | dglazkov, the only thing that is needed for the approach I'm suggesting is optional support for ::marker pseudo-element (not needed initially), and a shadow element around the content (excluding the summary) for hiding and showing |
| 17:15 | <othermaciej> | I am not sure I understand Lachy's list marker proposal though |
| 17:15 | <dglazkov> | othermaciej: we already whittled away RenderSummary to basically nothing http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/rendering/RenderSummary.h |
| 17:15 | <zcorpan> | hsivonen: i know i don't follow your links when it has a funny character in it :) |
| 17:16 | <othermaciej> | a bonus to implementing rendering of an element purely in CSS is that you can totally customize everything about it as an author |
| 17:16 | <Lachy> | othermaciej, it's easy. summary { display: list-item; list-style-type: -x-disclosure; } and ::marker as currently specced in CSS3 |
| 17:16 | <othermaciej> | Lachy: it's not obvious to me how to make the disclosure triangle animate with that approach |
| 17:16 | <othermaciej> | in my half-assed attempt to implement details in CSS, I made the disclosure triangle an image in ::before content |
| 17:17 | <othermaciej> | so it could be rotated with a transition |
| 17:17 | <Lachy> | othermaciej, it needs to be rendered as a native control anyway by default, per previous discussions, and that native disclosure control would have to handle that itself. But authors can use CSS animations and transforms to animate ::marker themselves if they like |
| 17:18 | <othermaciej> | I don't know what you mean by "as a native control" |
| 17:18 | <Lachy> | I mean, a platform specific disclosure widget |
| 17:18 | <Lachy> | either a triangle like on Mac or plus icon or whatever the platform typically uses. |
| 17:18 | <othermaciej> | that is certainly not how I would implement it in WebKit |
| 17:19 | <othermaciej> | I would make it match the look and behavior on Mac |
| 17:19 | <othermaciej> | on Windows I would probably use a similar triangle UI because Windows doesn't really natively have this control |
| 17:19 | <othermaciej> | I wouldn't use any OS APIs for the drawing in any case |
| 17:19 | <Lachy> | "I would make it match the look and behavior on Mac" - how is that different from what I just said? |
| 17:20 | <othermaciej> | that can be done with the use of a bitmap and an animation curve |
| 17:20 | <othermaciej> | no need for "a native control" |
| 17:20 | <Lachy> | well, we got feedback from our dev rel guys and other discussions on whatwg saying that people want controls that match the platform. |
| 17:21 | <othermaciej> | AppKit does have a disclosure control it provides as some type of NSControl, but we certainly wouldn't use that as part of the implementation |
| 17:21 | <Lachy> | it doesn't matter that much if that's implemented with an actual native control, of simulated with platform specific bitmaps |
| 17:22 | <othermaciej> | I guess what I'm not clear on is why using a list marker is superior to using ::before |
| 17:22 | <Lachy> | but we don't really want a Mac specific disclosure triangle rendering on Linux, or vice versa |
| 17:22 | <othermaciej> | I concede that it totally might be |
| 17:22 | <othermaciej> | but I do not know the reason |
| 17:23 | <Lachy> | We considered using ::before. It was one of my early experiments, but there were problems with it. I can't remember exactly what they were |
| 17:23 | <TabAtkins> | othermaciej: The way to animate the disclosure triangle is to do a transform on ::marker, once ::marker is supported. |
| 17:23 | <othermaciej> | I made a reasonable simulation with ::before |
| 17:23 | <TabAtkins> | In general, I think the platform should stay out of ::before/::after. Those are useful for a variety of things for authors. |
| 17:24 | <othermaciej> | my only problems were that I couldn't easily style just the children of <details> that are not the <summary>, and I couldn't animate to/from an auto value (for the expand/collapse animation) |
| 17:24 | <TabAtkins> | othermaciej: Lea Verou came up with a hack for that - animate max-height from a reasonable guess to 0. ^_^ |
| 17:25 | <othermaciej> | that is not a great hack |
| 17:25 | <Lachy> | dglazkov, this is another problem with WebKit's current approach http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1000 |
| 17:25 | <othermaciej> | animation will look quite wrong if your guess is off by more than a factor of 2 or so |
| 17:25 | <TabAtkins> | Lucky 1000, Lachy! |
| 17:26 | <Lachy> | the content of summary::before is rendered before the marker. list-item and ::marker solve that problem |
| 17:26 | <TabAtkins> | othermaciej: Indeed, it's not perfect. But it's at least *doable* now, until we wise up and actually fix Transitions. |
| 17:27 | <othermaciej> | hmm my demo no longer works because it collides with WebKit's built-in implementation |
| 17:27 | <othermaciej> | but you can see it here file:///Volumes/SnowLeopard/Users/mjs/Work/src/Safari/OpenSource/Websites/webkit.org/demos/hover-summary/example1.html |
| 17:27 | <Lachy> | a web link would be useful :-) |
| 17:27 | <othermaciej> | TabAtkins: Apple has a thing for actually making the UI perfect, not just "close enough most of the time" |
| 17:27 | <othermaciej> | er sorry |
| 17:27 | <othermaciej> | http://www.webkit.org/demos/hover-summary/example1.html |
| 17:27 | <othermaciej> | look at the source |
| 17:27 | <dglazkov> | Lachy: we don't support :before/after with shadow DOM yet |
| 17:27 | <dglazkov> | still working on that |
| 17:28 | <othermaciej> | as an extra weird thing the summary appears on hover in this case |
| 17:28 | <othermaciej> | you get double triangles and clicking doesn't work |
| 17:28 | <othermaciej> | and for some reason it focuses |
| 17:30 | <Lachy> | dglazkov, how do you intend to fix that? |
| 17:30 | <othermaciej> | I think the current WebKit details implementation is worse in UI quality than my old CSS+JS demo |
| 17:30 | <Lachy> | do you intend to allow the shadow dom to define where ::before and ::after get rendered or something? |
| 17:31 | <othermaciej> | I shall have to fix it at some point |
| 17:31 | <Lachy> | othermaciej, your demo works in Opera |
| 17:31 | <Lachy> | but you could fix it to use <div class="details"> instead of <details> |
| 17:32 | <othermaciej> | yah probably |
| 17:32 | <Lachy> | othermaciej, my implementation is here. http://lachy.id.au/dev/2011/details.html |
| 17:34 | <Lachy> | dglazkov, what are you intending to do about keyboard focus? It doesn't look like it currently works at all, making it inaccessible |
| 17:35 | <dglazkov> | Lachy: make it work? :) |
| 17:35 | <dglazkov> | Lachy: looking at your implementation, I don't understand what the fuss is all about |
| 17:36 | <dglazkov> | the only difference that I see is that you use a list-item marker and can't handle the cases of mulitple-missing details elements |
| 17:36 | <Lachy> | dglazkov, what do you mean? |
| 17:37 | <dglazkov> | Lachy: :) that's a difficult question to answer. What do you mean what do I mean? |
| 17:37 | <Lachy> | "multiple-missing details elements" doesn't make sense to me |
| 17:38 | <dglazkov> | Lachy: ah |
| 17:38 | <dglazkov> | Lachy: multiple/missing summary element |
| 17:38 | <dglazkov> | got them confused |
| 17:39 | <Lachy> | the missing summary element needs to be handled by a shadow DOM. i.e. one gets inserted if there isn't an explicit one. |
| 17:39 | <TabAtkins> | Multiple <summary>s are easy - "details > summary:first-of-type". |
| 17:39 | <Lachy> | multiple summary is handled, as TabAtkins said |
| 17:39 | <TabAtkins> | Missing requires a different mechanism, yeah. |
| 17:39 | <dglazkov> | ok, so we still need shadow DOM |
| 17:39 | <dglazkov> | then your only problem is that we use a DIV to represent a marker? |
| 17:40 | <Lachy> | yes, and with the previously mentioned bugs |
| 17:40 | <Lachy> | the <span id="content"> in my demo is also representing a shadow DOM element. |
| 17:40 | <dglazkov> | Lachy: so sounds like the actionable way to proceed is to build some sort of conformance test suite |
| 17:41 | <dglazkov> | Lachy: and make us fix all the bugs |
| 17:41 | <dglazkov> | Lachy: I am not dead-set on the marker being a div |
| 17:41 | <Lachy> | dglazkov, yes. But from an authoring perspective, it would be nice if we could reach some agreement about how the styling is achieved, so that authors don't have to target multiple browsers differently |
| 17:41 | <dglazkov> | Lachy: that's just an implementation detail to me at the moment |
| 17:44 | <dglazkov> | Lachy: sounds like a good goal. What's in the way for WebKit to implement this your way? |
| 17:44 | <dglazkov> | Lachy: support for :marker sounds like one |
| 17:46 | <Lachy> | dglazkov, allowing details and summary to be restyled by authors however they like, including display: inline; which, as I said before, is currently broken. |
| 17:46 | <dglazkov> | Lachy: yeah -- that's where the conformance tests should help |
| 17:46 | <dglazkov> | Lachy: I don't see them as a big deal, they are just steps in the course we're currently on |
| 17:47 | <dglazkov> | Lachy: the marker is different, since it's something we weren't planning to jump on right awawy |
| 17:47 | <Lachy> | there are still some open issues regarding how exactly to hide and show the content, such that the shadow element used to do that doesn't interfere with the rendering in any other way. |
| 17:47 | <dglazkov> | I think display:transparent is the new future weapon of mass construction |
| 17:47 | <Lachy> | there was previous discussion of display: transparent; for that |
| 17:47 | <Lachy> | yes |
| 17:47 | <dglazkov> | with shadow DOM, it will be pretty necessary |
| 17:48 | <Lachy> | I just need to convince our layout team that that's the right approach |
| 17:48 | <Lachy> | just with display: transparent, that is. Our initial experiemental implementation did some oither internal magic to deal with it |
| 17:50 | <dglazkov> | ok. where is :marker described? |
| 17:51 | <TabAtkins> | The Lists spec. |
| 17:51 | <TabAtkins> | Which'll go to LC at the end of the month. |
| 17:51 | <dglazkov> | gimme url or say no more |
| 17:51 | <TabAtkins> | dev.w3.org/csswg/css3-lists |
| 17:52 | <dglazkov> | so the hard question is... who's implementing ::marker in WebKit? :) |
| 17:52 | <dglazkov> | not it |
| 17:54 | <TabAtkins> | dglazkov: Just copypasta the ::before implementation. |
| 17:55 | <Lachy> | dglazkov, are you still planning to implement a pseudo-element to select the details content area? |
| 17:56 | <dglazkov> | Lachy: probably not. That was just me freehanding the design |
| 17:56 | <dglazkov> | morrita-san didn't need it |
| 17:57 | <Lachy> | ok. Do you currently have a shadow DOM element around the content area though that you use to hide/show the content? |
| 17:59 | <dglazkov> | Lachy: nope. |
| 17:59 | <Lachy> | how does it work then? |
| 17:59 | <dglazkov> | Lachy: it's a hack at the moment: http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/HTMLDetailsElement.cpp&l=206 |
| 17:59 | <Lachy> | I see in your code: ensureShadowRoot()->appendChild(DetailsContentElement::create(document()), ec, true); |
| 18:00 | <dglazkov> | basically don't create a renderer if closed |
| 18:00 | <dglazkov> | Lachy: yes, that's the actual <content> element |
| 18:00 | <dglazkov> | it's not renderered or matched in css |
| 18:00 | <dglazkov> | it's essentially an injection point |
| 18:01 | <Lachy> | Oh, right. You mean the <content> element in XBL2? |
| 18:01 | <dglazkov> | Lachy: yup |
| 18:01 | <Lachy> | ok |
| 18:02 | <dglazkov> | Lachy: we should replace that hack with something more natural to CSS, but not sure what yet |
| 18:02 | <dglazkov> | you want to be able to animate opening/closing |
| 18:03 | <dglazkov> | Lachy: but that's a problem we need to solve for shadow DOM in general, so I am not worried |
| 18:03 | <Lachy> | yeah, that would require either a pseudo-element that authors can animate, or authors to insert an explicit <div> or something |
| 18:03 | <dglazkov> | Lachy: right |
| 18:04 | <dglazkov> | Lachy: basically, I am here to move shadow DOM forward. The details/summary is just a byproduct :) |
| 18:04 | <dglazkov> | a yak shave |
| 18:05 | <Lachy> | I'm thinking if the shadow DOM were like this <details><summary/><::details-content>xxx</::details-content></details>, then that would allow authors to do the CSS transitions, but where the UA styles is [open]>::details-content { display: transparent; } [closed]>::details-content { display: none; } |
| 18:06 | <Lachy> | er, not [closed], but you know what I mean |
| 18:06 | <TabAtkins> | Well, skip the child combinator. |
| 18:06 | <TabAtkins> | [open]::details-content |
| 18:06 | <Lachy> | yeah, that too |
| 18:33 | <JoePeck> | is there any particular reason the "placeholder" attribute is a "must not" for <input type="number">? |
| 18:33 | <JoePeck> | http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state |
| 18:52 | <AryehGregor> | JoePeck, mostly these attributes are prohibited unless Hixie saw some specific use-case for allowing them. |
| 18:53 | <AryehGregor> | The idea is that it makes the first version easier to implement, I guess. |
| 18:53 | <AryehGregor> | You only need to implement placeholders for text or similar inputs. |
| 18:53 | <AryehGregor> | The idea of type=number is you get something with little arrows that can increase or decrease it, usually, and it's not obvious how that should interact with placeholders' behavior of "it disappears as soon as you focus the input". |
| 18:54 | <cying> | is it possible to select the last line of a text block before the overflow? |
| 18:54 | <cying> | (i'm wondering how to do multi-line text wrapping with last line ellipsis text overflow) |
| 18:54 | <AryehGregor> | "Select" how? With CSS? |
| 18:54 | <cying> | yes |
| 18:54 | <AryehGregor> | Like :first-line? I don't think that's possible, no. |
| 18:54 | <AryehGregor> | Could be wrong. |
| 18:54 | <cying> | something like... :last-line { text-overflow: ellipsis; } |
| 18:55 | <cying> | i know that doesn't work, but was wondering if anyone was thinking about that for future CSS work |
| 18:55 | <AryehGregor> | TabAtkins might know. |
| 18:55 | <TabAtkins> | No, you can't. However, pretty sure there are plans for a property to control the display of the last-line overflow somehow. |
| 18:56 | <JoePeck> | AryehGregor: thanks for the explanation. |
| 18:56 | <JoePeck> | AryehGregor: I don't think a placeholder is any more confusing with up/down than up/down is with a blank input |
| 18:56 | AryehGregor | shrugs |
| 18:56 | <AryehGregor> | File a bug if you have a use-case. |
| 18:57 | <JoePeck> | AryehGregor: kk, thanks |
| 19:02 | <hober> | AryehGregor: for the record, I play nethack full-screen. :) |
| 19:03 | <AryehGregor> | hober, how many times have you ascended? |
| 19:05 | <hober> | AryehGregor: sadly never |
| 19:05 | <AryehGregor> | Me: http://alt.org/nethack/plr.php?player=Simetrical |
| 19:05 | <cying> | thanks TabAtkins and AryehGregor |
| 19:05 | <cying> | good stuff |
| 20:20 | <AryehGregor> | jgraham, do you think assert_not_throws() would be useful? Just so that if an exception is thrown, the assert failure message can give you an idea of where it failed, if the test function is relatively long. |
| 20:28 | <The_8472> | is there an IRC channel about the CSS specs too? |
| 20:28 | <AryehGregor> | On w3.org there is, but I don't think it's very busy. |
| 20:28 | <AryehGregor> | Here's probably a better place to ask. |
| 20:29 | <The_8472> | mhm. i've found something in the CSS3 columns module that seems to be under-specified |
| 20:30 | <The_8472> | namely what should happen if a float appears before a multi-column block. current browser implementations behave counter-intuitively |
| 20:30 | <gsnedders> | The_8472: sending mail to www-style is almost certainly the right thing to do |
| 20:30 | <The_8472> | ok, i'll do that |
| 21:10 | <The_8472> | ... oh great. stupid mailing list. they don't obfuscate email addresses and won't send it unless i agree to publish -.- |
| 21:11 | <The_8472> | whoever had that idea needs to be shot |
| 21:16 | <TabAtkins> | Um, if you're relying on people obfuscating your email address in order to avoid spam in this day and age, you're doing it wrong. |
| 21:16 | <jcranmer> | I get spam in my inbox like twice a year |
| 21:17 | <jcranmer> | which is not the same number as the number of times I get spam in my email address |
| 21:17 | <TabAtkins> | Precisely. |
| 21:18 | <TabAtkins> | I get a bit more, since I receive a little over 50 spam a day, but still, it's only about one a week that makes it to my inbox. |
| 21:20 | <TabAtkins> | (Currently 30-day average is 55.5/day.) |
| 21:25 | <zewt> | the worst is mailing list archives that strip email addresses entirely; i've spent hours tracking people down because of that nonsense |
| 21:28 | <TabAtkins> | Definitely. |
| 21:33 | <The_8472> | <TabAtkins> Um, if you're relying on people obfuscating your email address in order to avoid spam in this day and age, you're doing it wrong. <- no, i don't rely on that. i don't use my normal addresses to post to such lists |
| 21:34 | <The_8472> | but it would be nice if they did, i'd have to juggle less temporary addresses that way |
| 21:34 | <TabAtkins> | My point is that you should assume that *all* lists aren't obfuscating your address. Public lists like www-style are syndicated by many third parties, which can do whatever they want with your email as well. |
| 21:34 | <TabAtkins> | Just don't use temporary addresses. Get a spam filter and live your life. |
| 21:35 | <Dashiva> | The spammers might even subscribe! |
| 21:35 | <AryehGregor> | Does anyone have any bright ideas on how I can do automated tests for how browsers behave in contenteditable when you hit Enter? |
| 21:35 | <AryehGregor> | WebKit appears to support an insertLineBreak command, but no one else does. |
| 21:35 | <Dashiva> | Would using selenium work? |
| 21:35 | <The_8472> | just... fire a keydown event? |
| 21:35 | <Ms2ger> | War |
| 21:35 | <AryehGregor> | I sort of would like to avoid manual tests here. |
| 21:35 | <Ms2ger> | Watir*? |
| 21:36 | <AryehGregor> | Or something as complicated and heavyweight as Selenium or Watir. |
| 21:36 | <AryehGregor> | Or something as Ruby-dependent as Watir. |
| 21:37 | <AryehGregor> | But I guess the answer then is "no", huh? |
| 21:37 | <AryehGregor> | Oh well. |
| 21:37 | <Ms2ger> | The synth event doesn't work, presumably? |
| 21:37 | <AryehGregor> | How would I do that? |
| 21:37 | <gsnedders> | The answer is no. Gecko/WebKit have elevated privilage modes that introduce JS APIs for it. |
| 21:37 | <gsnedders> | Ms2ger: No, it doesn't. |
| 21:38 | <AryehGregor> | I had hoped that maybe there was a special way to do it that would work for contenteditable. |
| 21:38 | <AryehGregor> | You never know. |
| 21:38 | <Ms2ger> | And we're removing that mode, fwiw |
| 21:38 | AryehGregor | searches mxr for an authoritative list of supported commands |
| 21:38 | <gsnedders> | Ms2ger: Replacing it with what? |
| 21:38 | <gsnedders> | Ms2ger: Because I assume you aren't moving to just having manual tests :P |
| 21:38 | <AryehGregor> | (Ugh, why is mxr always so slow?) |
| 21:39 | <Ms2ger> | No, we'll still provide APIs for tests |
| 21:39 | <Ms2ger> | But currently, any web page can request those privileges |
| 21:40 | <gsnedders> | Ms2ger: Ah. |
| 21:40 | <gsnedders> | Ms2ger: I didn't know normal web pages could. And request how? |
| 21:41 | <Ms2ger> | navigator.enablePrivilege are something like that? |
| 21:41 | <Ms2ger> | s/are/or/ |
| 21:41 | Ms2ger | can't type |
| 21:41 | <AryehGregor> | That sounds scary? |
| 21:41 | <Ms2ger> | Yes |
| 21:41 | <AryehGregor> | I mean, a page that has these privileges can do a lot, no? |
| 21:42 | <Ms2ger> | Why do you think we want to remove it? :) |
| 21:43 | <AryehGregor> | Oh. |
| 21:43 | <AryehGregor> | So how will the tests work? |
| 21:43 | <Ms2ger> | <Ms2ger> No, we'll still provide APIs for tests |
| 21:43 | <Ms2ger> | Look for SpecialPowers |
| 21:43 | <AryehGregor> | Ms2ger, do you happen to know where in the Gecko source I might find an authoritative list of supported edit commands? |
| 21:44 | <Ms2ger> | I can look, what's the API entry point? |
| 21:44 | <AryehGregor> | document.execCommand() |
| 21:45 | <AryehGregor> | Random command to search for: insertHorizontalRule |
| 21:45 | <AryehGregor> | I could probably search for that, actually. |
| 21:45 | AryehGregor | is hg pulling on his ancient mozilla-central checkout |
| 21:45 | AryehGregor | estimated time of completion: forever |
| 21:46 | Philip` | is beginning to get the feeling that AryehGregor may not be a giant fan of Hg |
| 21:46 | <jcranmer> | yep |
| 21:46 | <AryehGregor> | Philip`, actually, in this case I was more thinking of the fact that I haven't updated the checkout for months. I'm pretty sure git wouldn't be too fast here either. |
| 21:46 | <jcranmer> | Philip`: pulling mozilla-central is quite abnormally long |
| 21:46 | <AryehGregor> | Although it might be faster. |
| 21:47 | <jcranmer> | since it's on the order of '0000s of changesets |
| 21:47 | <AryehGregor> | A full kernel checkout from kernel.org takes maybe fifteen minutes on my cable connection, IIRC. |
| 21:48 | <Ms2ger> | (Hmm, insertBrOnReturn) |
| 21:48 | <AryehGregor> | nsHTMLDocument.cpp? |
| 21:48 | <AryehGregor> | (mxr search seems very fast, but viewing files is crazy slow . . .) |
| 21:50 | <AryehGregor> | Looks like the MDC docs are almost complete, nothing new here. |
| 21:51 | <Ms2ger> | http://mxr.mozilla.org/mozilla-central/source/content/html/document/src/nsHTMLDocument.cpp#3099 |
| 21:51 | <AryehGregor> | Yeah, I just found that a couple minutes ago. Thanks. |
| 21:51 | <AryehGregor> | Now, of course, my hg pull has completed. |
| 21:57 | <AryehGregor> | Ah, and the one command I didn't recognize (gethtml) seems to immediately fail if you try to execCommand() it. |
| 22:03 | <TabAtkins> | Too much Mass Effect - I can't make myself un-see GethTML. |
| 22:08 | <AryehGregor> | Oh, insertLineBreak in WebKit is useless to me. It doesn't simulate Enter, it just inserts <br>. |
| 22:09 | <AryehGregor> | So I guess I'll put off speccing that. |
| 22:09 | <AryehGregor> | (we *really* need a way to simulate keyboard input for spec tests) |
| 22:22 | <heycam> | jgraham, as currently specced, the case you mentioned earlier should actually result in a TypeError -- overload resolution is reasonably strict. you've got two types the argument could be (DOMString and long), and the overload resolution algorithm says if you pass in an object for that argument, then you should only consider operations with object or interface types at that position |
| 22:23 | <heycam> | jgraham, that this behaviour is pretty different from the no-overloading case, where any type of argument is accepted and coerced, is one of the reasons I don't like how overloading is handled currently |
| 22:46 | <Yuhong> | I have been playing with the W3C CSS 2.1 test suite in IE using Developer Tools to switch modes. |
| 22:46 | <Yuhong> | It was fun. |
| 22:46 | <linclark> | in microdata, if you have a property that takes an <a> as it's object, can you override the value (which would be the src attribute) by using the content attribute? |
| 22:50 | <TabAtkins> | linclark: No. If you put @itemprop on an <a>, it automatically refers to the @href of the <a>. Either add a <span> to your markup that can take the @itemprop instead (so you can use the textContent), or put in a <meta> instead to supply arbitrary content. |
| 22:50 | <linclark> | TabAtkins: thanks! |
| 22:51 | <linclark> | TabAtkins: do you have any recommendations for microdata references? |
| 22:55 | <TabAtkins> | What level of reference do you want? |
| 22:56 | <TabAtkins> | The spec works reasonably well. I have a blog post <http://www.xanthir.com/blog/b4570>; about it. Otherwise, try html5doctor, perhaps? |
| 22:56 | <linclark> | TabAtkins: I'm probably looking for more advanced, especially comparisons with RDFa |
| 22:56 | <TabAtkins> | Ah, dunno then. |
| 22:56 | <linclark> | TabAtkins: thanks for the link, will read |
| 22:57 | <TabAtkins> | There is only a tiny subset of things that rdfa can do that Microdata can't easily do, related to graphs with circular references. |
| 22:57 | <TabAtkins> | Since most data is tree-structured, the two are equivalent in power, and Microdata is easier to read and write. |
| 22:58 | <linclark> | yeah, I have a bit of experience with RDFa and know it has some real usability issues |
| 23:11 | <TabAtkins> | I don't understand how, sometimes, when I'm pasting from a view-source window into a text editor, a seemingly random smattering of linebreaks are doubled. I think this applies to both chrome and FF. |
| 23:15 | <aho> | sometimes = with windows-style linebreaks (i guess) |
| 23:17 | <TabAtkins> | That's what I'd assume, if I didn't author this text myself in a single editor, so I know the linebreaks should all be the same. |
| 23:23 | <aho> | must be underpants gnomes then |
| 23:23 | <aho> | btw just saw that google io talk which mentioned mdv |
| 23:23 | <aho> | awesome stuff :o |
| 23:24 | <TabAtkins> | Yeah, the one with the two Alexes? |
| 23:24 | <aho> | http://www.youtube.com/watch?v=qzA60hHca9s |
| 23:24 | <aho> | alex russel, ian fette, and someone else |
| 23:24 | <aho> | :> |
| 23:24 | <aho> | http://code.google.com/p/mdv/ |
| 23:24 | <aho> | http://code.google.com/p/experimental-css/ <- also nice :) |
| 23:25 | <aho> | i'm f-ing excited about both things |
| 23:25 | <aho> | heh |
| 23:25 | <TabAtkins> | Alex Komoroske was the other. |
| 23:26 | <TabAtkins> | And yus, it's all exciting! |
| 23:27 | <aho> | i think we might actually see this stuff somewhat soonish on smartphones |
| 23:27 | <aho> | (relatively speaking) |
| 23:27 | <aho> | e.g. once webkit got proxy support we could use that mdv "shim" thing |
| 23:37 | <cying> | TabAtkins: like your response to HTML5 last call poll |
| 23:44 | <TabAtkins> | Heh, thanks, I guess. |
| 23:48 | <aho> | aw man... there are so many talks :I |
| 23:50 | <TabAtkins> | OH: If I were ever to design a hashing function, I'd try to set things up so that hash(0) = 0. Even if that meant appending a final step to the algorithm: |
| 23:50 | <TabAtkins> | "XOR with da39a3ee5e6b4b0d3255bfef95601890afd80709". |
| 23:50 | <gsnedders> | We really need to implement all the ES5 stuff in Carakan… |
| 23:51 | <aho> | how much is missing? |
| 23:51 | <aho> | forEach, map, and friends do work for example |
| 23:51 | <gsnedders> | aho: Object stuff, Function.prototype.bind, and strict mode |
| 23:52 | <aho> | proxies :D |
| 23:56 | <Philip`> | TabAtkins: Why? (It sounds risky to mess with the usual cryptographic hash properties like that) |
| 23:57 | <TabAtkins> | Philip`: A static xor like that won't touch the crypto properties at all. |