09:09 | <annevk> | Domenic_: that's a pretty go |
09:10 | <annevk> | Domenic_: oops, compelling reply |
09:10 | <annevk> | Domenic_: thanks! |
10:38 | <annevk> | Woohoo, found more browser differences... |
10:38 | <annevk> | baseURI is apparently cloned in Gecko, not in Chrome. |
10:39 | <annevk> | Whoa, IE doesn't even support baseURI |
10:41 | <annevk> | I wonder if IE supports xml:base... |
10:52 | <annevk> | So, none of Chrome/Safari/IE support xml:base! |
11:14 | <MikeSmith> | annevk: crazy |
11:15 | <annevk> | Since xml:base is kinda crazy, I'd like to call this one an opportunity. |
11:15 | <zcorpan> | apparently my fingers think that </var> is an appropriate way to close any element |
11:16 | <zcorpan> | i guess killing xml:base also means complexity is reduced quite a bit |
11:18 | <SimonSapin> | So can we just remove that last test and move on? http://test.csswg.org/suites/css-style-attr/nightly-unstable/report/results.html |
11:20 | <zcorpan> | ok i've defined how declaration blocks are serialized, with shorthands. anyone want to review the diff before i commit? |
11:23 | <annevk> | Filed https://bugzilla.mozilla.org/show_bug.cgi?id=903372 on removing xml:base from Gecko |
11:24 | <zcorpan> | http://pastebin.com/3LRZVbLP |
11:24 | <annevk> | zcorpan: I don't think it make sense to talk about syntax |
11:25 | <annevk> | "If a property is specified more than once" is a syntax thing, it's not a model thing |
11:26 | <zcorpan> | annevk: yeah, i should probably hook into the cascade there in some way |
11:27 | <annevk> | zcorpan: some complexity can be removed I suppose, but <base> is still there |
11:52 | <gsnedders> | annevk: FWIW, xml:base is required in stuff like RSS/Atom |
12:15 | <zcorpan> | it could be made an RSS/Atom-specific attribute |
12:19 | <zcorpan> | TabAtkins: is there something in css-cascade that i can hook into for the purpose of saying which declarations go in to the CSSOM? it seems to talk about the processing going from an element and matching against it, but for CSSOM that's not what i need |
12:28 | <zcorpan> | TabAtkins: see the top of http://pastebin.com/3LRZVbLP for context |
12:50 | <annevk> | gsnedders: could care less |
12:51 | <zcorpan> | annevk: you mean couldn't? |
12:52 | <annevk> | zcorpan: oops |
12:55 | <gsnedders> | annevk: Does Firefox, at least on Android, not inc. a feed reader? |
12:56 | <annevk> | gsnedders: support for xml:base we need there is way different and less complex |
12:56 | <annevk> | gsnedders: can just be done at the application layer |
15:45 | <MikeSmith> | win 17 |
15:52 | <sangwhan> | Has someone been crazy enough to polyfill CSS exclusions? :) |
15:52 | sangwhan | assumes not |
16:11 | <annevk> | So I wanted to put URL tests into some kind of universal format. But JSON doesn't allow comments. Suggestions? |
16:15 | <SimonSapin> | annevk: for CSS parsing tests I went with JSON + a readme |
16:37 | <Domenic_> | annevk: compelling reply to what? |
17:39 | <TabAtkins> | zcorpan: Actually, that's a lack in Syntax - I'm adding a paragraph now stating that style rules need to ignore duplicate declarations. |
17:39 | <TabAtkins> | zcorpan: Do you need a more abstract hook? |
17:40 | <TabAtkins> | Hm, though, you *do* need something more abstract I think, because Syntax probably doesn't want to do shorthand expansion. |
17:40 | <TabAtkins> | Since the actual list of properties that CSSOM will see should include shorthands (so it can serialize). |
17:42 | <TabAtkins> | zcorpan: Just let me know what you need and I can hook you up. |
20:49 | <Hixie> | did we decide we were going to use IDL for deciding what was visible in workers? |
21:40 | <Hixie> | heycam|away: any opinions on https://www.w3.org/Bugs/Public/show_bug.cgi?id=22646 ? |
22:26 | <Hixie> | fyi, whatwg.org will probably be offline for an hour around 11am-1pm August 14th, PST |
22:26 | <Hixie> | i doubt we'll be able to distinguish this from the times it's offline just randomly, but that's another story |
22:44 | <eXhumed_> | hi! I'm working on a web app that plays multiple <audio> elements in sync. I can do all sorts of operations (play, pause, stop, seek) and they will stay in sync. However, when I add another <audio> element with a local resource as its source, it does stay in sync with the others if I play them from the beginning, but when I seek (change .currentTime) the "local" <audio> element breaks the sync. |
22:46 | <eXhumed_> | (and by "local" I mean having an array with samples, encoding them into a wav file and setting it as the element's .src) |