| 00:19 | <Hixie> | othermaciej: so i can get any decision reverted if i just have two people complain? |
| 00:26 | <Hixie> | i'm also confused as to why some decisions get made such that the decision doesn't match any proposal, and in others we are told "we only considered the proposals that were provided as CPs" |
| 01:01 | <nessy> | http://www.whatwg.org/specs/web-apps/current-work/multipage/ <- is broken for me... |
| 01:01 | <Hixie> | yeah i'm looking into it |
| 01:01 | <Hixie> | use http://www.whatwg.org/specs/web-apps/current-work/complete/ for now instead |
| 01:09 | <TabAtkins> | Hixie: I can't load the description of how to match A>B in the presence of XBL into my head. Given <details><summary/><div></div></details>, and <template><content includes=summary /><div><content /></div></template>, does "details>div" match the light-dom <div>, the shadow <div>, or both? |
| 01:10 | <Hixie> | off-hand, i dunno, i've paged all that out to long-term storage :-) |
| 01:10 | <TabAtkins> | Dammit. |
| 01:10 | <TabAtkins> | I wish you'd been writing in a proper algorithmic style back then. Expressing an algorithm as a series of "otherwise" clauses in a paragraph is confusing. |
| 01:10 | <Hixie> | yeah me too |
| 01:10 | <Hixie> | i don't recall that being especially difficult though, let me look |
| 01:11 | <TabAtkins> | http://dev.w3.org/2006/xbl2/Overview.html#shadow-content-and-css |
| 01:12 | <Hixie> | ok so we're given <details><summary/><div></div></details> and <template><content includes=summary /><div><content/></div></template> |
| 01:12 | <Hixie> | and the selector is "details > div" |
| 01:12 | <Hixie> | ok, there are two potential <div>s that could match |
| 01:12 | <Hixie> | let's look at the first one, in the bound element dom |
| 01:13 | <Hixie> | it has a details parent, so it definitely matches, irrespective of xbl |
| 01:13 | <Hixie> | now let's look at the other one |
| 01:13 | <Hixie> | its parent is a <template>, so that's what X is in the second paragraph... |
| 01:14 | <Hixie> | "allow-selectors-through" is false by default |
| 01:14 | <TabAtkins> | Assume that it's true. |
| 01:14 | <Hixie> | oh |
| 01:14 | <Hixie> | ok |
| 01:14 | <Hixie> | ok so "allow-selectors-through" is true and we assume there's no other binding applying |
| 01:14 | <Hixie> | so X becomes the bound element |
| 01:15 | <Hixie> | what is the bound element here, <details>? |
| 01:15 | <TabAtkins> | Yeah. |
| 01:15 | <Hixie> | then yes, both <div>s match that selector. |
| 01:15 | <TabAtkins> | That's crazy times. |
| 01:15 | <Hixie> | i'm just answering your question dude |
| 01:15 | <jamesr> | allow-selectors-through is crazytimes |
| 01:16 | <jamesr> | you asked for it |
| 01:16 | <TabAtkins> | I know. ^_^ Still crazytimes. |
| 01:16 | <Hixie> | if you have a problem with the answer you should speak to Hixie of 2003 and 2005 :-P |
| 01:16 | <Hixie> | Hixie of 2011 is mentally ready to merge XBL into HTML and change everything in the process (though not ready in terms of available time, but that'll come) |
| 01:16 | <TabAtkins> | I'll put this down on the "Engineer with a time machine TODOs" list. |
| 01:17 | <jamesr> | warn the passengers of the Titanic? nah. pop a cap in Hitler's ass in 1938? nah. go talk to Hixie about XBL selector matching? HELL YEAH! |
| 01:18 | <TabAtkins> | The Hitler Conservation principle is well-known, so there's no reason to try to fix that. |
| 01:18 | <Hixie> | dude if you're gonna warn me about xbl just warn me it still won't be implemented by 2011 so i can work on stuff that doesn't give me a headache :-P |
| 01:18 | <TabAtkins> | (Any attempt to stop Hitler inevitably ends with WW2 still occurring in roughly the same or worse manner.) |
| 01:20 | <wilhelm> | Indeed. Knock out Clemenceau in 1917 instead. |
| 01:25 | <Philip`> | Yeah, it could have been far worse - Hitler could have had dinosaurs |
| 01:28 | <Philip`> | (http://www.dinodday.com/ - I like their posters) |
| 01:28 | <TabAtkins> | Philip`: Luckily, histories where that happens are usually the direct result of time-travelers, and so are fixable by other time-travelers. |
| 01:30 | <Philip`> | Maybe the reason time travel has never been invented is that whenever someone invents it, they mess up history, so the second person to invent time travel travels back to prevent the first person inventing it |
| 01:30 | <Philip`> | at which point they become the first person and the cycle repeats |
| 01:30 | <TabAtkins> | Yup, and time-cycles eventually result in a quantum fluctuation wiping out the cycle entirely. |
| 01:44 | <nessy> | I liked the futurama where timetravel was only possible forward - and then they found that time repeats anyway |
| 01:54 | <bga_> | http://www.webdevout.net/test?0k |
| 02:13 | <Hixie> | othermaciej: what you describe as what you wouldn't do seems to me to be exactly what was done in both cases where it wasdone |
| 02:14 | <othermaciej> | Hixie: do you think the distinction between "mix and match" vs. "something not proposed at all" is a false one, or that the decisions in question were on the wrong side of that distinction? |
| 02:15 | <othermaciej> | (replies may be slow as I have a ton of bureaucratic paperwork to slog through tonight) |
| 02:15 | <Hixie> | i was trying to say that they were on the wrong side, but i could probably argue the other thing as well :-) |
| 02:17 | <Hixie> | looking at the focus ring one more closely, i don't really understand what was decided |
| 02:17 | <Hixie> | what's the return value of drawFocusRing() now? |
| 02:18 | <jamesr> | a headache |
| 02:18 | Hixie | decides to not try to figure out today and to wait til he gets around to actually implementing the decision |
| 02:32 | <zewt> | Hixie: was it intended that canvas.getContext() cache a null return value from "Return a new object for contextId"? or was it assumed that it would never fail if the context is supported by the UA? |
| 02:34 | <zewt> | (guessing it wasn't intended to receive null as a return value, since null usually isn't considered "a new object") |
| 02:34 | Hixie | looks |
| 02:35 | <Hixie> | it can't cache null |
| 02:35 | <Hixie> | as you say, null is not a new object :-) |
| 02:36 | <zewt> | (and firefox just crashed, so a minute of thrashing to restart it...) |
| 02:36 | <zewt> | should the abstract "return a new object" algorithm never return null? |
| 02:37 | <zewt> | getContext just doesn't seem to describe what happens on error--it seems like the "primary context" should also not be set on error |
| 02:41 | <zewt> | (webgl returns null on error, which is why I care--it doesn't seem like that's valid) |
| 02:42 | <jamesr> | the problem is for webgl context creation should be async |
| 02:42 | <jamesr> | since it's heavyweight and can fail |
| 02:42 | <jamesr> | 2d context creation is assumed to be pretty lightweight and won't reasonably fail |
| 02:43 | <zewt> | they do have "context lost"/"context restored" events, but they're used later |
| 02:44 | <zewt> | i'm trying to convince them to do something saner, but that's hard to do when I can't tell what getContext actually wants them to do :) |
| 02:45 | <zewt> | IMO: getContext should propagate exceptions from context creation, clear the "primary context" on exception if it was just set, and prohibit null as a return value entirely |
| 02:46 | <jamesr> | what would you return in the case of a context initialization failure? |
| 02:46 | <zewt> | nothing--throw an exception |
| 02:47 | <zewt> | it's a synchronous failure |
| 02:47 | <jamesr> | gotcha |
| 02:47 | <jamesr> | so you'd have to block the call until you knew the context was ready |
| 02:47 | <zewt> | but I can't recommend that to webgl when getContext itself doesn't support it |
| 02:47 | <zewt> | it already has to do that |
| 02:48 | <zewt> | since webgl returns null if the context can't be created; now it would just throw an exception instead |
| 02:48 | <jamesr> | right. which is unfortunate for webgl but orthogonal to your concern |
| 02:48 | <zewt> | from talking with them this isn't totally set in stone, which is why I'm trying to nudge this towards something better before it is |
| 02:49 | <zewt> | (which is why I'm nagging hixie on IRC :) |
| 03:07 | <Hixie> | zewt: the abstract "return a new object" algorithm should never return null, it should return a new object. :-) |
| 03:07 | <Hixie> | zewt: how can there be an error? |
| 03:08 | <zewt> | webgl context creation can fail; it doesn't know if it can create a context until you try |
| 03:08 | <Hixie> | why can it fail? |
| 03:08 | <Hixie> | i don't understand how it could possibly fail |
| 03:09 | <Hixie> | you just get an object back |
| 03:09 | <Hixie> | what is there to fail |
| 03:09 | <zewt> | creating the context creates the OS OpenGL context; that may fail |
| 03:09 | <zewt> | (or other 3d library) |
| 03:09 | <Hixie> | that's the UAs problem, it shouldn't expose such failures to web code |
| 03:09 | <Hixie> | web pages aren't going to be able to do any thing useful if getContext() returns null |
| 03:10 | <Hixie> | anyway, gotta go for dinner, will be back in a few hours if you want to discuss further. |
| 03:10 | <Hixie> | or mail me |
| 03:10 | <Hixie> | later |
| 03:10 | <zewt> | later |
| 03:18 | <karlcow> | http://www.youtube.com/watch?v=Z_sl99D2a18 |
| 06:59 | <hsivonen> | Hixie: regarding http://www.whatwg.org/specs/web-apps/current-work/#attr-link-href does href="" define a hyperlink in the <link> case? |
| 08:08 | <Hixie> | hsivonen: no, href plus a rel value does |
| 09:56 | <zcorpan> | Hixie: the ascii art diagram wraps in the spec. and the top and bottom 'borders' of the diagram seem misaligned |
| 10:46 | <Peter`> | dbaron: great job at landing CSS animations! |
| 12:19 | <jgraham> | http://lists.w3.org/Archives/Public/www-archive/2011Apr/0062.html |
| 12:25 | <hsivonen> | jgraham: I find the stance entirely unsurprising |
| 12:36 | <kennyluck> | [[I don't think we have an issue with recognizing other prefixes if they use the correct namespace declaration, just guessing we haven't taken the time to implement it yet.]] - what does this mean? |
| 12:37 | <hsivonen> | kennyluck: I read "have an issue with" as "object to" |
| 12:38 | <hsivonen> | (not as "have a bug in") |
| 12:39 | <jgraham> | kennyluck: I assume it means "we haven't actively decided not to do this" |
| 12:39 | <jgraham> | But it has not been high enough priority to actually get implemented |
| 12:43 | <hsivonen> | was it so that WebKit devs wanted innerText to match what "copy" exports to the clipboard as plain text? |
| 12:43 | <hsivonen> | or am I imagining memories? |
| 12:43 | <jgraham> | That sounds like something I can imagine being true, but I can't say for sure if it is actually a line of argument they used |
| 13:34 | <wilhelm> | Does Mozilla have any publicly available tests for registerProtocolHandler and/or registerContentHandler? |
| 13:36 | <Ms2ger> | I'd hope so |
| 13:37 | <Ms2ger> | http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/test/test_registerHandler.html |
| 13:37 | <wilhelm> | \o/ |
| 13:37 | <wilhelm> | Thanks. |
| 13:38 | wilhelm | stea^H^H^H^Hborrows tests. |
| 13:38 | <Ms2ger> | How about you rewrite them to use testharness.js and submit them? :) |
| 13:41 | <wilhelm> | That's what I'll probably end up doing, yes. :P |
| 13:43 | <Ms2ger> | Excellent |
| 13:43 | <Ms2ger> | Then please do steal them :) |
| 16:54 | <hsivonen> | I have a screen recording of a slideshow as a QuickTime movie with Apple Animation codec |
| 16:54 | <hsivonen> | how do I encode it into WebM in such a way that successive frames that have no change get encoded as one long frame |
| 16:54 | <hsivonen> | with variable frame durations |
| 16:54 | <hsivonen> | ? |
| 16:55 | <hsivonen> | or should I not care and trust that frames that just say "the same as the previous frame" are cheap? |
| 17:04 | <Lachy> | hsivonen, hopefully, the encoder would handle that for you |
| 17:25 | <AryehGregor> | "We’ve worked closely with the Chrome team to implement a recent web standard so we can support a feature called native printing." |
| 17:25 | <AryehGregor> | The words "web standard" link to the CSS 3 Paged Media WD, dated October 2006. |
| 17:25 | <AryehGregor> | Not exactly what I'd call "recent". |
| 17:27 | <TabAtkins> | Compared to CSS 2.1 |
| 17:27 | <AryehGregor> | The first WD of CSS 3 Paged Media was 1999. |
| 17:28 | <TabAtkins> | Okay, you got me there. That predates 2.1. |
| 17:28 | <AryehGregor> | And a bunch of the functionality is already in CSS2. |
| 17:28 | <jgraham> | "a feature called native printing" sounds strange |
| 17:28 | <AryehGregor> | http://www.w3.org/TR/WD-CSS2-971104/page.html |
| 17:35 | <Ms2ger> | Hear hear, CSS2.1 a PR |
| 18:49 | <Philip`> | I wonder why Sam acts as if http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0126.html was new information, when hsivonen already linked to it in his survey response |
| 18:51 | <Ms2ger> | Because Henri didn't introduce it with FORMAL OBJECTION? |
| 18:54 | <Philip`> | I suppose it suggests a good strategy is to repost all the old information that was previously discussed, in case the chairs have forgotten about it and can treat it as new information |
| 18:55 | <Ms2ger> | I'd argue the winning strategy is not to play |
| 18:56 | <TabAtkins> | No, see, the winning strategy is to go first and hope your opponent makes a mistake. |
| 18:56 | <TabAtkins> | 'cause you can just take the middle square, see, and if they mess up you can win it then. |
| 18:56 | <Philip`> | Ms2ger: That strategy doesn't work if everyone else carries on playing without you |
| 18:56 | <Ms2ger> | wfm |
| 19:06 | Philip` | sees http://blogs.msdn.com/b/ie/archive/2011/04/12/native-html5-first-ie10-platform-preview-available-for-download.aspx - now with improved native HTML5 support that consists of four CSS3 modules and ES5 strict mode |
| 19:06 | <paul_irish> | haha. |
| 19:08 | <Ms2ger> | And 300% hardware acceleration |
| 19:33 | <hsivonen> | ooh. is IE10 PP1 really adding Flexbox? which snapshot of Flexbox? |
| 19:35 | <Philip`> | http://msdn.microsoft.com/en-gb/ie/gg192966#_CSS3FlexBox might or might not say |
| 19:37 | <AryehGregor> | Whoa, PP1 already? They're serious about stepping up their release schedule. |
| 19:38 | <tw2113> | now if they could just get people off of XP |
| 19:38 | <AryehGregor> | Or release their new browsers for XP. |
| 19:39 | <tw2113> | that takes logic that MS can't compute |
| 19:39 | <Ms2ger> | +Vista, I hear? |
| 19:39 | <tw2113> | it causes segfaults |
| 19:39 | <zewt> | please stop trying to coerce me into "upgrading" away from an OS that I like to one that I do not like; thanks |
| 19:39 | <bfrohs> | And here I thought SP3 was their attempt to get people off of XP... |
| 19:39 | <AryehGregor> | Do grid and flexbox layouts support very different use-cases? I thought they were similar ideas. |
| 19:39 | <Ms2ger> | zewt, please upgrade to linux ;) |
| 19:40 | bfrohs | agrees with Ms2ger |
| 19:40 | <zewt> | i don't touch linux as a desktop OS, thanks :P |
| 19:40 | <tw2113> | why not? |
| 19:40 | <zewt> | relegated to a terminal, where it belongs |
| 19:40 | <AryehGregor> | Ms2ger, how does that help? IE doesn't work on Linux either. :( |
| 19:40 | <Philip`> | AryehGregor: They say "Higher cadence just means more frequent releases of incomplete software (and larger version numbers). What matters is when consumers and businesses take delivery of robust, production-ready browsers that use the new technology." which doesn't sound like a great endorsement of a stepped-up release schedule |
| 19:41 | <bfrohs> | I have to admit, it's nice to see Microsoft trying to get back into the game. |
| 19:42 | <Ms2ger> | It rather sounds like "It takes us half a year to run all our regression tests by hand, and then another 3 months when we've fixed the regressions, so we can't go faster" |
| 19:43 | <zewt> | "it takes a really long time to WONTFIX all of these bug reports" |
| 19:43 | <Ms2ger> | That, too |
| 19:44 | <hsivonen> | that there are multiple browsers implementing the same prefixed CSS features is sad. I wish we could get rid of the prefixes faster. |
| 19:44 | <tw2113> | well you don't need to use them |
| 19:45 | <AryehGregor> | hsivonen, it's been discussed like six times in the CSSWG, and nobody seems to be interested enough to agree on a solution. |
| 19:45 | <hsivonen> | tw2113: yes, I do. I want cool stuff right now. |
| 19:45 | <AryehGregor> | What they should really do is declare individual features stable even before CR, and commit to not changing the syntax, so that vendors can drop prefixes before the whole spec moves to CR. |
| 19:45 | <tw2113> | :P |
| 19:45 | <hsivonen> | having to have bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=642265 is just sad |
| 19:46 | <tw2113> | my prefix order is this: -moz, -o, -webkit, no prefix |
| 19:47 | <tw2113> | i just let IE render what it can, and use modernizr in some cases |
| 19:47 | <hsivonen> | tw2113: why do you discriminate IE? |
| 19:47 | <tw2113> | because i am not a fan of it at all |
| 19:47 | paul_irish | tries to think of common css3-y stuff that uses a -ms- prefix... |
| 19:48 | <zewt> | historically microsoft has a really well-compressed vendor prefix |
| 19:48 | <zewt> | "" |
| 19:48 | <paul_irish> | in the past IE has refrained from implementing things with a prefix |
| 19:48 | <paul_irish> | yah |
| 19:48 | <Ms2ger> | AryehGregor, isn't that the consensus? |
| 19:48 | <hsivonen> | paul_irish: CSS 2D transforms is an example of a spec that's implemented with a prefix in the top 4 engines |
| 19:48 | <paul_irish> | but ie10 changes that philosophy. |
| 19:48 | <AryehGregor> | Ms2ger, possibly, but no one seems to be doing it. |
| 19:48 | <paul_irish> | also 2d transforms in ie9 yes |
| 19:48 | <hsivonen> | paul_irish: I count that as a failure of the standardization process |
| 19:49 | <paul_irish> | probably. that and msft is way more "careful" about adopting features than everyone else |
| 19:49 | <tw2113> | MS just marches to the beat of their own drummer and i deal with it last |
| 19:49 | <aho> | Peter`, just saw your vendor prefix tweet. ace! :D |
| 19:49 | <Ms2ger> | I'm not too happy about dropping prefixes before we have a test suite, myself |
| 19:49 | <paul_irish> | "Updated my Vendor Prefixed #CSS overview with lots of new Firefox, Opera and IE hotness :-) http://goo.gl/NZY0N " |
| 19:50 | <aho> | thanks for the copypasta ;) |
| 19:55 | <aho> | Peter`, i'm not sure about the meaning of gray/italic entries :f |
| 19:56 | <AryehGregor> | Ms2ger, that's a great philosophy if anyone actually bothers writing tests in a reasonable timeframe. |
| 19:56 | <AryehGregor> | In practice, not so much. |
| 19:57 | <Peter`> | aho: thanks :) The grey ones are the same properties, yet not prefixed anymore |
| 19:57 | <hsivonen> | Ms2ger: that doesn't help much if existing content is of the form -moz-foo: bar; -webkit-foo: bar; -o-foo: bar; -ms-foo: bar; foo: bar; |
| 19:58 | <aho> | ah ok... so... firefox supports... filter? |
| 19:58 | <hsivonen> | aho: different filter, IIRC |
| 19:58 | <Ms2ger> | Yeah |
| 19:59 | <aho> | https://developer.mozilla.org/en/CSS/filter |
| 19:59 | <aho> | ah yea... svg filter/mask stuff |
| 20:00 | <bfrohs> | Out of curiosity: 'test suite' or 'testsuite'? Both are used on whatwg wiki. |
| 20:00 | <Ms2ger> | Both are used in my head, too |
| 20:00 | <hsivonen> | Peter`: might make sense to put Firefox's filter and IE's -ms-filter on different rows, since they are really different features |
| 20:01 | <Peter`> | it's a limitation in the system right now, I am aware of the problem |
| 20:02 | <aho> | you could add a tooltip comment for now ;) |
| 20:07 | <aho> | i'd use ⓘ (24d8) instead of that ✍ thing |
| 20:19 | <Peter`> | aho: Good idea, thanks! Both changed. |
| 20:20 | <aho> | :) |
| 20:30 | <bga_> | oh |
| 20:31 | <bga_> | now we have name collision between IE's filter and modern SVG's filter |
| 20:31 | <bga_> | many sites will be broken |
| 20:32 | <TabAtkins> | We've had this conflict for forever. |
| 20:32 | <Ms2ger> | WebKit has even generalized document.all's behaviour for it |
| 20:32 | <bga_> | choose for example `svg-filter` |
| 20:33 | <bga_> | document.all is good |
| 20:33 | <TabAtkins> | This hasn't been a problem so far, because IE hasn't implemented SVG 'filter', and the two versions have massively different syntaxes. |
| 20:35 | <jgraham> | "document.all is good" - uh what? |
| 20:36 | <bga_> | _filter:alpha(opacity = 50); filter: svg filter here |
| 20:36 | <bga_> | or CC |
| 20:37 | <bga_> | jgraham document.all.foo is shorter than document.getElementById('foo') |
| 20:37 | <bga_> | :) |
| 20:37 | <bga_> | developers too lazy |
| 20:38 | <TabAtkins> | Bah. It should be just query('#foo') (on window, so it can be omitted). |
| 20:38 | <bga_> | or $('foo'), yes |
| 20:39 | <TabAtkins> | $ is too opaque, even though it does have a lot of history, imo. |
| 20:39 | <bga_> | or with(document.all){ foo } :P |
| 20:39 | <TabAtkins> | Bleh. |
| 20:39 | <jgraham> | bga_: Every time you use document.all a kitten dies |
| 20:39 | <jgraham> | Well I say a kitten |
| 20:40 | <TabAtkins> | What's wrong with window.foo? ^_^ |
| 20:40 | <jgraham> | It is more like most of the cute animals for a mile radius |
| 20:40 | <bga_> | TabAtkins gecko? :) |
| 20:40 | <TabAtkins> | Pfft. |
| 20:41 | <jgraham> | Hmm, gecko supports that |
| 20:41 | <jgraham> | I'm pretty sure |
| 20:41 | <AryehGregor> | Only in quirks mode. |
| 20:41 | <jgraham> | Same as document.all |
| 20:41 | <jgraham> | (did I already mention that you shouldn't use either?) |
| 20:42 | TabAtkins | uses window.[id] for quick tests because it's just easier. Nothing public, though. |
| 20:45 | <bga_> | main goal is make development easy imho. foo.onclick = _bar or document.getElementById('foo').addEventListener('click', _bar, false) |
| 20:46 | <bga_> | you provide giant stong api with long names |
| 20:46 | <TabAtkins> | Yup, most of the "good" APIs were apparently designed with no consideration for authoring ease. :/ |
| 20:47 | <bga_> | ppl are forced to invent jq like frameworks |
| 20:53 | <jgraham> | bga_: There is "easy" and "easy to shoot yourself in th foot" |
| 20:54 | <bga_> | i know |
| 20:55 | <TabAtkins> | There is also, of course, "omg verbose how did you ever consider this acceptable don't you know we're in Peak ASCII?". |
| 22:28 | <TabAtkins> | Heh, the behavior of transformed elements that are broken across columns is amusing. |
| 22:28 | <TabAtkins> | Particularly when you animate the transform. |
| 22:28 | <Hixie> | url? :-) |
| 22:29 | <TabAtkins> | One sec... |
| 22:29 | <TabAtkins> | 925 on your dom viewer |
| 22:30 | <TabAtkins> | (Sorry, I was doing the test on my windows box, and your "saved" url is too long to easily remember. |
| 22:30 | <Hixie> | hah |
| 22:30 | <Hixie> | nice |
| 22:31 | <TabAtkins> | This makes it somewhat difficult to determine if I need a getQuads() function in addition to getQuad(), for the transformed quad. |
| 22:56 | <Hixie> | othermaciej: yt? |
| 22:57 | <Hixie> | othermaciej: bug 10202's decision requires me to put RFC2119 terminology in a non-normative context. How should I proceed? |
| 23:07 | <Hixie> | othermaciej: for now i just forked the spec so the whatwg one doesn't make that mistake; let me know if i should just fix the w3c one too |
| 23:07 | Hixie | doesn't really dare apply judgement to applying these decisions anymore |
| 23:12 | <othermaciej> | Hixie: do you mean the word "should" in the note? |
| 23:12 | <Hixie> | yes |
| 23:12 | <Hixie> | see most recent diff |
| 23:14 | <othermaciej> | ok, I don't have time at the moment to study this closer but I can this evening |
| 23:14 | <Hixie> | k |
| 23:14 | <Hixie> | it's a trivial editorial matter |
| 23:30 | <zewt> | drawing a total blank here and I've seen it in several specs--what's a spec that has the "if a feature isn't supported, pretend it doesn't exist and don't expose the interface at all" text? |
| 23:30 | <Hixie> | how do you mean? |
| 23:30 | <Hixie> | if a feature isn't supported, how would an interface be exposed? |
| 23:30 | <Hixie> | surely if the interface is exposed, that means the feature is supported |
| 23:31 | <Hixie> | by definition |
| 23:31 | <zewt> | it means as opposed to throwing an exception, i think |
| 23:31 | <Hixie> | not sure what you mean |
| 23:31 | <zewt> | it's a specific bit of text ... dunno, I'll keep poking through specs until I find it |
| 23:33 | <zewt> | ah, here it is |
| 23:33 | <zewt> | When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. |
| 23:33 | <zewt> | (relevant to the webgl GPU-blacklisting thing) |
| 23:34 | <Hixie> | oh, disabled, not not supported |
| 23:34 | <Hixie> | ok |
| 23:34 | <zewt> | same thing from the user's POV :) |
| 23:34 | <jamesr> | i don't think that is true if a feature is disabled due to the hardware limitations clause |
| 23:34 | <Hixie> | only because of that paragraph :-) |
| 23:35 | <jamesr> | in practice, that is |
| 23:35 | <jamesr> | not in spec-ese |
| 23:35 | <zewt> | jamesr: i don't know of any cases of it actually happening |
| 23:35 | <jamesr> | for example everyone has a hardware limitation on canvas dimensions right now |
| 23:35 | <jamesr> | but no user agent pretends that canvas is completely unsupported if the page tries to make a gigantic canvas |
| 23:36 | <zewt> | yeah, it's not applied for every edge case |
| 23:36 | <jamesr> | for webgl in the blacklist, the feature exists exactly as specified - it just happens to never give you a valid context |
| 23:37 | <zewt> | that's a bug, though--getContext() should always return a context |
| 23:37 | <jamesr> | if it returns, yeah it probably should |
| 23:37 | <jamesr> | but a webgl context isn't necessarily one you can render into |
| 23:37 | <zewt> | about to suggest one approach to making that happen on the thread; i suspect implementation problems won't allow it, but it seems like it should work based on the gecko/webkit reasons given so far |
| 23:38 | <zewt> | (going to suggest that permanent gpu-blacklisted failures should be detected at browser launch and disable WebGL entirely as above, and transient "out of resources" should create a "lost" context as Kenneth described) |
| 23:38 | <jamesr> | that doesn't work |
| 23:38 | <jamesr> | the blacklist may be updated while the browser is running |
| 23:38 | <zewt> | how? |
| 23:38 | <jamesr> | it downloads the blacklist from the interwebs |
| 23:38 | <TabAtkins> | The browser polling the blacklist server. |
| 23:39 | <jamesr> | or the user may update their graphics drivers to a version that isn't blacklisted while the browser is running |
| 23:39 | <zewt> | that should just be updated along with browser updates |
| 23:39 | <jamesr> | why? |
| 23:39 | <zewt> | if it's okay to restart the browser for a security update, it's okay to do so for a blacklist update |
| 23:40 | <jamesr> | why? |
| 23:40 | <zewt> | why not? |
| 23:40 | <TabAtkins> | It's not actually okay to restart for a security update. It's just necessary. |
| 23:40 | <jamesr> | because it's a worse user experience |
| 23:40 | <jamesr> | it shouldn't be necessary to restart the browser for a security patch |
| 23:40 | <zewt> | (in principle, Chrome might be able to start new, updated tab backends with things like updated blacklists, without having to restart the front-end) |
| 23:40 | <jamesr> | and if we figure out a way to patch security holes without requiring a browser restart, you can bet we'll do it |
| 23:40 | <jamesr> | we do a similar thing for safebrowsing |
| 23:40 | <jamesr> | we update the safebrowsing lists without requiring browser restarts |
| 23:40 | <Hixie> | jamesr: if webgl is blacklisted, then 'webgl' is not the name of a context supported by the user agent, and the UA will return 'null' in step 2 |
| 23:41 | <jamesr> | (in principle, maybe. it'd be insanely complicated) |
| 23:41 | <zewt> | so create new browsing environments with WebGL disabled |
| 23:41 | <jamesr> | i don't think that's very practical |
| 23:42 | <Hixie> | what isn't practical about it? |
| 23:42 | <jamesr> | Hixie: good point on that |
| 23:43 | <zewt> | yeah, that's true |
| 23:43 | <jamesr> | tying webgl blacklisting state with browsing environments instead of allowing the blacklist to be updated dynamically |
| 23:43 | <zewt> | the WebGL class named would still be in window, but that's not a big deal |
| 23:43 | <Hixie> | oh yeah, you'd want to do it across all browsing contexts at once, sure |
| 23:44 | <jamesr> | so the results of step 2 could change essentially at any point |
| 23:44 | <Hixie> | it's not like it's going to matter anyway, only users that happen to have a webgl context created on a page that then tries to create another while the blacklist is updated and if they have a black-listed card that hasn't already crashed will be affected |
| 23:44 | <Hixie> | and they'll just hit reload |
| 23:44 | <Hixie> | (and find the page has stopped working altogether) |
| 23:44 | <Hixie> | so... |
| 23:45 | <othermaciej> | Hixie: so what are possible resolutions to the "note" containing a "should"? It seems like one is to remove the word "note", and another is to rephrase to not use an RFC2119 keyword if no conformance requirement is intended |
| 23:45 | <zewt> | it would mean that ("WebGLTexture" in window) and canvas.getContext("webgl") could be out of sync, but i think nothing guarantees that anyway |
| 23:45 | <zewt> | (ignoring primary-context-incompatible errors from getContext) |
| 23:45 | <othermaciej> | Hixie: if you want to do either of those things, I'd say run it by the list with an explanation, and if Julian doesn't object, it should be fine |
| 23:45 | <jamesr> | Hixie: the reverse could happen (the user was blacklisted then becomes unblacklisted) |
| 23:46 | <Hixie> | othermaciej: the resolution i use was to apply the decision as it was made for the w3c copy, and fix the text for the whatwg copy to have s/should/will/ and to have slightly better style |
| 23:46 | <jamesr> | Hixie: in which case there's no way for a page to know when to retry the context creation |
| 23:46 | <jamesr> | so the only real option is for the user to refresh the page |
| 23:46 | <zewt> | jamesr: if a card is blacklisted while a context is created, is it just "lost" (webglcontextlost) forever? |
| 23:46 | <Hixie> | othermaciej: i don't intend to post to the list, it just wastes my time even more |
| 23:46 | <jamesr> | i believe that's how it should work. i don't know if that's how it does work in the current chrome implementation |
| 23:47 | <othermaciej> | Hixie: yes, I recognize that you forked - if you want to unfork, then I would only ask to post to the list first |
| 23:47 | <jamesr> | the dynamic blacklisting stuff is relatively new |
| 23:47 | <Hixie> | jamesr: yeah |
| 23:47 | <Hixie> | othermaciej: k. i'll leave it as is for now. |
| 23:47 | <othermaciej> | Hixie: if you don't care about unforking on this point, then you don't need to do anything |
| 23:47 | <jamesr> | zewt: meaning that future calls to getContext() would return a reference to the same non-null but lost context, i suppose |
| 23:48 | <Hixie> | othermaciej: as far as forking for these decisions go, that one is going to be the least annoying one by far |
| 23:49 | <zewt> | jamesr: according to the spec, since at that point "webgl" would no longer be a name of a supported context, it would abort in step 2 and return null |
| 23:49 | <zewt> | even if a previous object exists (that happens in 5) |
| 23:50 | <zewt> | http://dev.w3.org/html5/spec/the-canvas-element.html#dom-canvas-getcontext |
| 23:50 | <jamesr> | hm right, you wouldn't make it to step 3 |
| 23:50 | <jamesr> | i'm not totally sure step 2 is when the blacklisting should apply |
| 23:50 | <zewt> | can you think of any problems with it? it seems like the cleanest fix so far, barring any other issues |
| 23:51 | <jamesr> | what would the net delta end up being? |
| 23:51 | <zewt> | (helpfully, it also reduces the amount of changes webgl would need) |
| 23:51 | <zewt> | well, the actual behavior wouldn't change much in this case--blacklisted returns null now and it still would |
| 23:53 | <jamesr> | (note that i still think we need to add a asynchronous context creation path for WebGL. WebGL context initialization can be really expensive and it sucks to block the main message loop while it's going on) |
| 23:53 | <zewt> | webglcontextcreationerror would go away, presumably, since you never actually get to any algorithm that can fire it |
| 23:53 | <zewt> | which might take some people a bit of convincing |
| 23:53 | <zewt> | unless there's a way to wedge it in somehow |
| 23:53 | <jamesr> | (we could add an async path that also updated the canvas' primary context) |
| 23:55 | <zewt> | would that actually help? i don't know the backends at all |
| 23:55 | <zewt> | yeah i guess i could see how that could work (with opengl, anyway, i know webgl isn't actually always opengl under the hood) |
| 23:56 | <zewt> | instead of an async getContext, it could be getContext("webgl", {async: true});, which always returns a "lost" context and fires webglcontextrestored when initialization completes |
| 23:57 | <zewt> | though if "out of resources" error cases become "context lost" then it would need a way to tell the difference between the cases ("still initializing" and "out of resources, don't wait up") |
| 23:58 | <jamesr> | yeah, you really want to have some definitive point where you know whether or not you are gonna get a context |
| 23:58 | <zewt> | could have three context states: "active", "lost" and "initializing" |
| 23:58 | <zewt> | async starts in initializing; if it fails it's lost, as normal |