| 07:00 | <Ms2ger> | Is krijn_ down? |
| 07:31 | <krijn_> | Am I? |
| 07:31 | <krijn_> | Meh |
| 07:40 | <krijn_> | I'll let someone in the IT department know! |
| 07:45 | <matjas> | hmm, http://www.whatwg.org/specs/web-apps/current-work/multipage/entities.json is not in https://github.com/whatwg/html-mirror? |
| 07:46 | <matjas> | btw I disabled issues + pull requests on that repository, since it’s meant as a mirror only |
| 07:55 | <Ms2ger> | Is it in svn? |
| 08:05 | <zcorpan> | aw, i was hoping the nipple twister would end up in the spec :-( |
| 08:09 | <krijnh> | Someone needed a nipple twister? |
| 08:15 | <Ms2ger> | Those Dutchies... |
| 09:04 | <zcorpan> | MikeSmith: can we change default assignee in bugzilla for cssom specs? |
| 09:20 | <matjas> | Ms2ger: no, those files are not in SVN either |
| 09:20 | <matjas> | seems weird these files are not under version control |
| 09:24 | <annevk> | GAP IN THE LOGS!!1 |
| 09:30 | <zcorpan> | annevk: good thing there's also logbot |
| 09:32 | <annevk> | matjas: entities.json is imported I think from http://www.w3.org/TR/xml-entity-names/ |
| 09:33 | <annevk> | zcorpan: ! |
| 09:34 | <annevk> | I wish Hixie put a day or so into cleaning up his scripts and open sourcing the whole thing. Would make things a bit more hackable. |
| 09:38 | <gsnedders> | Or just open source them as the mess they are and let others do the tidying. |
| 09:41 | <annevk> | Yeah either way. He'd need to refactor the bits where he puts his password directly in the file though. |
| 09:43 | <matjas> | annevk: +1 |
| 09:43 | <gsnedders> | Or just open source it with [my_password_here] :) |
| 09:44 | <matjas> | gsnedders: +2 |
| 09:45 | <aleray> | hi, I'm interested by the new audio possibilities in HTML5. I've seen some ways to load audio data using XHR. While it works for small files (like 1Mb), chromium always crashes on big files (like 50 Mb). |
| 09:45 | <gsnedders> | aleray: How are you trying to read the file from XHR? |
| 09:45 | <aleray> | is this XHR loading method appropriate for big files? |
| 09:46 | <aleray> | gsnedders, basically what is described at: http://www.html5rocks.com/en/tutorials/webaudio/intro/ |
| 09:47 | <gsnedders> | aleray: Try setting xhr.responseType = "arraybuffer", you'll get a typed array back — might work better? |
| 09:47 | <gsnedders> | Oh, that tutorial already does. |
| 09:48 | <annevk> | aleray: our bad, we haven't figured out how to describe an IO Stream yet and therefore XMLHttpRequest does not expose one |
| 09:48 | <annevk> | aleray: although crashing is never an appropriate response so you might want to file a bug on Chrome |
| 09:49 | <aleray> | gsnedders, in the example i'm trying to follow 'arraybuffer' is indeed the specified response type |
| 09:50 | <aleray> | annevk, ok I will. SO it means that the audio api isn't mature enough yet to be used with large files? |
| 09:50 | <aleray> | oups s/SO/So/ |
| 09:51 | <annevk> | aleray: did you try in Firefox? We might do better... |
| 09:51 | annevk | has not played with Web Audio, but knows why XMLHttpRequest doesn't support streaming data yet |
| 09:51 | <aleray> | maybe I can describe what I'm trying to achieve so you can give me some guidance if you don't mind |
| 09:52 | gsnedders | is surprised that a 50MB file doesn't work fine |
| 09:53 | <aleray> | basically I'm trying to do a two tracks audio editor. I have seven source files of about 50Mb each and I'd like the website editor to be able to place fragments of those files on the two audio tracks to create compositions. |
| 09:54 | <darobin> | who made https://github.com/whatwg/html-mirror ? |
| 09:55 | <annevk> | darobin: foolip |
| 09:56 | <annevk> | aleray: I don't know enough about this, but maybe segmenting the files would make it work better, i.e. implement the streaming yourself |
| 09:57 | <aleray> | gsnedders, annevk does it sound duable for you? My approach at the moment is to play media fragments (like file.ogg#t=10,20) one after the other (not yet a composition, more like a playlist actually). |
| 09:58 | <darobin> | annevk: ta |
| 09:58 | <aleray> | annevk, so cutting the files server side? and still using XHR to load the hard-cutted fragments? |
| 09:58 | <annevk> | aleray: it sounds fine, but honestly I don't know what the memory limits are these days |
| 09:58 | <annevk> | aleray: yeah, I guess, just so you have smaller files |
| 09:58 | <annevk> | aleray: you could also try to experiment a bit to see what the limit is in various browsers |
| 09:59 | <annevk> | aleray: e.g. if you only load one 50MB file, does that work? |
| 09:59 | <aleray> | annevk, thanks. I will try this! |
| 10:15 | <annevk> | smaug____: yo, can you look at the public-webapps thread regarding custom element callbacks? |
| 11:02 | <karlcow> | <Hixie> in other news, i need a term that doesn't really mean anything, but expresses the property of A being something relative to B, without implying a mutual relationship, and that brings to mind the idea of control or authority |
| 11:05 | <karlcow> | A is the teacher of B, A is the father of B, A is the boss of B, A is the captain of B (boat), A is the mountain guide of B, … |
| 11:47 | <zcorpan> | karlcow: teacher means B is student of A; similarly for the others |
| 11:47 | <zcorpan> | karlcow: the spec now has "is familiar with" |
| 11:52 | <karlcow> | zcorpan: agreed. Not sure about the context but "is a teacher" != "is a professor" not bijective. |
| 11:52 | <Ms2ger> | pupil? |
| 11:53 | <karlcow> | ooops |
| 11:53 | <karlcow> | still too early… |
| 11:53 | <karlcow> | Ms2ger: yes :) |
| 12:17 | <Ancil> | annevk: hi |
| 12:18 | <Ancil> | annevk: I have question regarding XMLHTTPRequest and force preflight |
| 12:23 | <Ancil> | annevk: is it required to make preflight request for synchronous XHR with upload event listeners like onloadstart registered |
| 12:24 | <Ancil> | annevk: does a preflight request for both sync and async XHR when upload event listeners are registered |
| 12:24 | <Ancil> | annevk: but Chrome doesn't |
| 12:25 | <Ancil> | annevk: which is the right behavior? |
| 12:27 | <Ancil> | annevk: *Firefox does prefilight for both sync and async XHR with upload listeners |
| 12:28 | <annevk> | Ancil: Chrome never does a preflight for those? |
| 12:29 | <annevk> | Ancil: I think the specification requires one, but I keep forgetting why it does :/ |
| 12:29 | <Ancil> | annevk: Chrome does preflight only for async XHR |
| 12:29 | GPHemsley | wonders if "A trusts B" is not already taken |
| 12:29 | <annevk> | Ancil: might be an oversight in Chrome then... |
| 12:30 | annevk | looks in spec |
| 12:30 | <annevk> | Ancil: ooh, so yeah, that seems like a Gecko bug |
| 12:31 | <annevk> | Ancil: the reason it's not required for sync is because the events won't dispatch anyway |
| 12:31 | <Ancil> | annevk: as per my understanding the spec says the "If the synchronous flag is unset and one or more event listeners are registered on the XMLHttpRequestUpload object, set the upload events flag. " and set force preflight when upload events flag is set |
| 12:31 | <Ancil> | yeah |
| 12:32 | <annevk> | Ancil: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core pretty please |
| 12:33 | <Ancil> | annevk: So the chrome behavior is the right one. |
| 12:33 | <annevk> | Ancil: yeah |
| 12:33 | <Ancil> | annevk: ok, I will log a bug |
| 12:33 | <annevk> | Ancil: ta |
| 12:33 | <Ancil> | annevk: thanks |
| 13:29 | <annevk> | MikeSmith: why are you reassigning resolved bugs? |
| 13:29 | <MikeSmith> | annevk: I'm just pushing buttons |
| 13:29 | <MikeSmith> | it was easier to do it that way |
| 13:29 | <MikeSmith> | the CSSOM bugs |
| 13:29 | <MikeSmith> | changed the default assignee |
| 13:30 | <MikeSmith> | and figured while I'm doing it to change the open ones too |
| 13:30 | <annevk> | It makes the history harder to trace and also spams me |
| 13:30 | <annevk> | Oh well |
| 13:30 | <MikeSmith> | sorry, didn't realize to after I pushed the button |
| 13:31 | <MikeSmith> | I can try to change them back if you want |
| 13:31 | <annevk> | nah leave it |
| 13:31 | <MikeSmith> | k |
| 13:31 | <Ms2ger> | They were probably wrong anyway |
| 13:50 | <annevk> | Couple of my Shadow DOM bugs were resolved with https://dvcs.w3.org/hg/webcomponents/rev/dbf47f602628 as pointer... |
| 13:51 | <annevk> | Thousands of lines of Apple plist disaster... |
| 13:51 | <Ms2ger> | Wow, that's pretty crappy |
| 13:52 | <annevk> | I guess I should just leave it and review again at some point in the future... Trying to figure out what changed seems like a non-starter. Even looking at just the HTML... |
| 13:53 | <Ms2ger> | "Refactor" |
| 13:54 | <Ms2ger> | "Deprecate" |
| 14:06 | <zcorpan> | good news, everyone, http://www.w3.org/TR/html/ now points to HTML5 instead of XHTML 1.0 |
| 14:07 | <darobin_> | it only took... nah, I don't want to know how long it took in fact :) |
| 14:27 | gsnedders | wonders whether he should do as Bachelor's project something like proving various assertions in the HTML parser |
| 14:31 | <gsnedders> | (Things like whether you can ever end up in foreign content while not being) |
| 14:32 | <gsnedders> | (That all the fragment case parentheticals can only happen in the fragment case.) |
| 14:56 | <darobin> | gsnedders: or you could prove that the parser is Turing complete |
| 14:57 | <gsnedders> | That's trivial |
| 14:58 | <gsnedders> | Oh, wait, complete. |
| 14:58 | <gsnedders> | Duh. |
| 14:59 | <gsnedders> | You need a Turing machine is implement the parser, that's clear. |
| 15:04 | <gsnedders> | If you restrict the input to the parser to be finite, I'm fairly certain you don't need a TM to run it. |
| 15:05 | <gsnedders> | And I think you should be able to derive a proof based on that that the language itself is not Turing complete. |
| 15:08 | <darobin> | yes, if you can prove that you don't need a TM to process it (ie turn it into a DOM), then you can prove that it's not TC |
| 15:08 | <darobin> | but I wouldn't be shocked if there were nasty tricks you could do with adoption and such that would actually be universal |
| 15:11 | <gsnedders> | In general, you need a TM to process it because you need the infinite memory to deal with an infinite input stream. |
| 15:12 | <gsnedders> | Adoption is deliberately capped to avoid making it run-away powerful, but its cloning at all might be enough to be able to implement a TM on. |
| 15:12 | <darobin> | mmmm |
| 15:12 | <darobin> | I don't see why infinite memory means you need a TM |
| 15:12 | <darobin> | anything else can have an infinite memory |
| 15:13 | <Ms2ger> | FSMs can't |
| 15:19 | <darobin> | well, not absolutely everything :) |
| 15:20 | <darobin> | but pushdown automata can for instance |
| 15:21 | <Ms2ger> | Well, sure |
| 15:21 | <Ms2ger> | Those are almost Turing machines |
| 15:22 | <darobin> | almost doesn't count |
| 15:22 | <Ms2ger> | All you need is a queue instead of a stack |
| 15:23 | <gsnedders> | Do PDAs not have a finite input, though? |
| 15:24 | <ricea> | P is almost NP :-P |
| 15:24 | <Ms2ger> | That may be the case |
| 15:24 | Ms2ger | doesn't remember much attention given to infinite inputs |
| 15:27 | <gsnedders> | Sure, a PDA can use theoretically infinite stack and infinite states, but the input must be finite. |
| 15:27 | <gsnedders> | I believe only a unrestricted grammar allows infinite inputs, and hence a TM is needed on that basis. |
| 15:28 | <Ms2ger> | Infinite states too? |
| 15:29 | <gsnedders> | I believe so? |
| 15:29 | <Ms2ger> | My definition only allows a finite set of states |
| 15:30 | <Ms2ger> | (Rich, "Automata, Computability, and Complexity", p. 249) |
| 15:30 | <gsnedders> | No, you must need a TM to parse HTML, due to the multiple stacks, surely? |
| 15:31 | <Ms2ger> | Most likely, yes |
| 15:31 | <Ms2ger> | But that's not a proof :) |
| 15:31 | <gsnedders> | No, it's not. :) |
| 15:31 | Ms2ger | wonders if HTML contradicts the pumping lemma |
| 15:31 | <gsnedders> | Need to prove you cannot reduce to one stack. Which I think should be trivial to give an example of. |
| 15:32 | <gsnedders> | Once you've done that, then the proof is easy. |
| 15:34 | <gsnedders> | Ms2ger: It doesn't, if it is (like I think!) an unrestricted grammar. |
| 15:37 | <gsnedders> | (The pumping lemma obviously always holds true for unrestricted grammars.) |
| 15:38 | <gsnedders> | (More interesting, IMO, is whether *conforming* HTML is context-free) |
| 15:40 | <Ms2ger> | Mmm |
| 15:40 | <gsnedders> | *interesting question |
| 15:40 | <MikeSmith> | I would think it should be, as a goal of defining the conformance rules |
| 15:41 | <MikeSmith> | that is, make it a requirement that determines what the conformance rules are |
| 15:43 | <MikeSmith> | rather than what we have now, where the rationale for some of the conformance rules are just arbitrary (which is fine a long as they don't break the must-be-a-content-free-grammar requirement) |
| 15:47 | <MikeSmith> | in other news, nice to see discussions of fine points of implementation realities like http://lists.w3.org/Archives/Public/www-tag/2013Aug/0053.html (from Marcus) taking place on the TAG list. Massive contrast to where the TAG was at only a few months back.a |
| 15:47 | <gsnedders> | MikeSmith: What's the justification for requiring it to be context-free? |
| 15:48 | <gsnedders> | Heh, Marcus has been playing around with audio stuff for ages, mostly doing stuff like data URIs and the audio element. |
| 15:49 | <MikeSmith> | gsnedders: for one thing I guess it makes it expressable in some common formalisms that it otherwise wouldn't be expressible in |
| 15:50 | <MikeSmith> | I don't mean a formalism for expressing parsing rules |
| 15:51 | <MikeSmith> | but instead a formalism for expressing what a conforming document looks like |
| 17:50 | <TabAtkins> | So hey, fun proposals here from heycam about how to make the SVG DOM suck less: http://dev.w3.org/SVG/proposals/improving-svg-dom/ |
| 17:50 | <TabAtkins> | Opinions desired on www-svg |
| 17:50 | <TabAtkins> | Or here, whatever. |
| 17:53 | <GPHemsley> | is there wide support for the 'let' keyword yet? |
| 17:54 | <TabAtkins> | GPHemsley: Supported in FF only right now, I believe. |
| 17:54 | <GPHemsley> | ah, that's what I thought |
| 17:54 | <GPHemsley> | thanks |
| 17:54 | <TabAtkins> | And you have to opt in via some incantation in type='' |
| 17:54 | <GPHemsley> | right |
| 17:54 | <GPHemsley> | var it is |
| 17:54 | <TabAtkins> | I recently switched my hobby hacking to FF just so I could get some of those sweet new features. |
| 17:54 | <Ms2ger> | Fx, you mean? |
| 17:55 | <GPHemsley> | yeah, they're pretty awesome |
| 17:55 | <TabAtkins> | Screw that. |
| 17:55 | <GPHemsley> | Ms2ger: I find that even official text often says "FF" or "Ff" |
| 17:55 | <Ms2ger> | They're wrong :) |
| 17:55 | <TabAtkins> | Quit trying to make Fx happen. It's not going to happen. |
| 17:55 | <zewt> | firefox = ff |
| 17:55 | <zewt> | sorry, that's the reality :P |
| 17:56 | <zewt> | (also, who the heck would think "fx" would be a good abbreviation for firefox? it's terrible) |
| 17:57 | <Ms2ger> | f5x |
| 17:57 | <TabAtkins> | f5x, *maybe*, due to existing precedent. |
| 17:57 | <TabAtkins> | Dammit, Ms2ger, you scooped me. |
| 17:59 | <Domenic_> | svg thing looks very cool |
| 17:59 | <zewt> | TabAtkins Ice Cream(r) |
| 18:18 | <zcorpan> | TabAtkins: hmm, i don't like the no-namespace proposal |
| 18:18 | <TabAtkins> | zcorpan: Yeah, me neither. Just put them in the HTML namespace and be done with it. |
| 18:18 | <TabAtkins> | I'll be writing up my own feedback on the proposal, and it's part of what I'm responding with. |
| 18:18 | <zcorpan> | it's also wrong about createElement which always uses HTML namespace (per spec at least) |
| 18:19 | <TabAtkins> | Ah, that's probably why heycam|away did the null namespace thing. |
| 18:22 | <zcorpan> | i also see little reason to have both graphics and viewport compared to just graphics |
| 18:22 | <TabAtkins> | The main reason, I think, is that there are some attributes that make sense on the root viewport but not nested, and vice versa. |
| 18:22 | <TabAtkins> | So it's weird to reuse the same thing for both. |
| 18:26 | <zcorpan> | *shrug* |
| 18:29 | <Hixie> | heycam|away: http://dev.w3.org/SVG/proposals/improving-svg-dom/ is only an improvement if we remove the old stuff. If we don't, then we're just doubling the complexity. |
| 18:30 | <zcorpan> | yeah, i was about to say, i'm not sure i like the new namespace idea at all |
| 19:06 | <Ms2ger> | Hixie, so, an object that supports indexed or named getters needs to be proxy-like |
| 19:06 | <Ms2ger> | Hixie, so if Window has a indexed getter, it needs to be proxy-like as well |
| 19:06 | <Ms2ger> | (Ignore the named getter, because it ends up in the gps) |
| 19:06 | <Ms2ger> | gsp |
| 19:26 | <TabAtkins> | Hixie: We obviously can't remove the old stuff yet, but the plan is to eventually kill it, yes. |
| 19:26 | <TabAtkins> | By dangling irresistible carrots in the form of not-totally-fucked-up APIs. |
| 19:58 | <gsnedders> | MikeSmith: Why is that a use case? Hixie wouldn't accept that. |
| 19:59 | <Ms2ger> | Hixie doesn't accept a lot |
| 20:39 | <zcorpan> | TabAtkins: when has carrots enabled us to remove anything? |
| 20:40 | <gsnedders> | Ms2ger: Indeed, so MikeSmith need justify himself better. |
| 20:40 | <TabAtkins> | We kill prefixes, for example. Not every time, but often enough. |
| 20:40 | <Ms2ger> | Well, yes |
| 20:41 | <Ms2ger> | Because everyone writes their code expecting the non-prefixed version |
| 20:41 | <Ms2ger> | And usually also all the possible prefixed ones |
| 20:44 | <gsnedders> | -I-will-prefix-your-face: true; |
| 20:48 | <Hixie> | ms2ger: maybe "proxylike" doesn't mean what i think it means? I mean "like WindowProxy". |
| 20:48 | <TabAtkins> | We're killing XSLT, for example. |
| 20:49 | <Hixie> | let's not count that chicken quite yet. |
| 20:49 | <TabAtkins> | Things do die from misuse, as least enough for them to be removed. |
| 20:49 | <TabAtkins> | Hixie: Yeah, sure. |
| 20:49 | <TabAtkins> | s/misuse/lack of use/ |
| 20:50 | gsnedders | has doubts about whether XSLT will so easily die |
| 20:51 | <TabAtkins> | Even if it never does, though, I think the argument that you shouldn't ever duplicate functionality is wrong-headed. |
| 20:53 | <gsnedders> | Cut one off and two appear in its place… The web platform is a Hydra… |
| 20:54 | <TabAtkins> | True. ^_^^ |
| 20:54 | <TabAtkins> | ...I'm gonna pretend the third eye was intentional, and a commentary on gsnedder's quote. |
| 20:55 | <zewt> | *poke* _^^ |
| 21:00 | <Hixie> | TabAtkins: generally i am strongly against duplicating the slightest thing, though i would obviously be open to arguments on a case-by-case basis. but this is a whole different scale of duplication. |
| 21:00 | <TabAtkins> | I know you are, and we've discussed this before, and I think you're really wrong. It puts the potential confusion of authors having to look at two syntaxes over the persistent pain of authors having to use a single, terrible syntax. |
| 21:01 | <TabAtkins> | The SVG DOM can't be defended on *any* pragmatic grounds. Its sole good point is that it already exists. |
| 21:05 | <TabAtkins> | In 5 years, there will be the SVG subset of HTML which works nice and makes people happy, and the weird legacy syntax that nobody likes and is only used by legacy pages. |
| 21:07 | <zcorpan> | if we do this, it should behind a pref for a few years so we can get it right instead of duplicating everything once a year |
| 21:08 | <Hixie> | the problem is that "is only used by legacy pages" is just not how it'll turn out |
| 21:08 | <Hixie> | because "legacy pages" are copied and pasted, are part of templates, are maintained for decades, etc |
| 21:08 | <Hixie> | in practice all it does is mean that authors have to know both languages |
| 21:09 | <Hixie> | and we have to define how they interact, because different templates end up in the same page using both features |
| 21:09 | <Hixie> | etc |
| 21:10 | <TabAtkins> | zcorpan: Yeah, definitely. |
| 21:10 | <TabAtkins> | Hixie: Transition pain is a worthwhile cost sometimes. |
| 21:29 | <Hixie> | TabAtkins: sometimes. |
| 21:29 | <TabAtkins> | That's what I said. ^_^ |
| 21:29 | <Hixie> | i was agreeing :-) |
| 21:30 | <Hixie> | TabAtkins: a lot of the time, when people suggest replacing (duplicating) an api, though, they tend to overestimate the cost of the existing api, overestimate the worth of the new api in comparison, and underestimate the cost of the transition |
| 21:30 | <Hixie> | in part because they forget that the new api will never be as perfect as the design, due to the attrition experienced during initial implementation and deployment |
| 21:30 | <TabAtkins> | It's hard to overestimate the terribleness of the SVG DOM. |
| 21:32 | <zcorpan> | but the new API isn't awesome compared to just using DOM Core |
| 21:33 | <Hixie> | honestly i think the biggest pain of the SVG DOM is really that the whole approach of elements for graphics isn't particularly wieldy |
| 21:33 | <Hixie> | i don't know how much is just api decisions |
| 21:33 | <Hixie> | mathml suffers from a similar, but more obvious, problem |
| 21:36 | <zcorpan> | how much are people using the SVG DOM? |
| 21:37 | <TabAtkins> | zcorpan: Most of the new API is removing baseVal/animVal, and some of the more ridiculously overwrought mistakes, like .numberOfItems |
| 21:38 | <zcorpan> | TabAtkins: that doesn't answer my question :-P |
| 21:38 | <TabAtkins> | zcorpan: Sorry, wasn't answering that question. ^_^ |
| 21:38 | <TabAtkins> | zcorpan: Probably enough that we can't just drop it immediately. |
| 21:38 | <zcorpan> | oh, ok, heh |
| 21:38 | <TabAtkins> | If we could, then yay! Let's just do it. |
| 21:39 | <zcorpan> | let's find out before jumping through hoops we don't know we have to jump through |
| 21:40 | <Domenic_> | isn't d3 using the svg dom? |
| 21:40 | <Domenic_> | that's used by a ton of people, we've built like 5 apps for large banks just in the last 6 months |
| 21:42 | <TabAtkins> | Yeah, the modern untick in popularity, and attendant libraries, are the big thing that would prevent us from doing it, I think. |
| 21:43 | zcorpan | sees https://github.com/mbostock/d3/blob/master/d3.js#L5209 |
| 21:44 | <pdr> | notice d3 doesn't use animValue and instead rolls it by hand |
| 21:49 | <zcorpan> | Hixie: i think non-configurable is the new term for ReadOnly |
| 21:49 | <zcorpan> | new as of ES5 or so |
| 21:49 | Hixie | mumbles something about this being a perfect example of duplication being confusing :-P |
| 21:50 | <heycam> | zcorpan, doesn't createElement() put an element into no namespace when you're in an XML document? |
| 21:50 | <heycam> | that was the main reason I allowed for both in the proposal |
| 21:50 | <zcorpan> | heycam: nope. http://dom.spec.whatwg.org/#dom-document-createelement |
| 21:51 | <zcorpan> | some browsers might still do that, i guess |
| 21:51 | <heycam> | zcorpan, huh! |
| 21:51 | <heycam> | yeah I think I just tested in Gecko and assumed that must be the standard behaviour |
| 21:51 | <zcorpan> | in gecko it depends on the mime type, iirc |
| 21:52 | <heycam> | mime type, and not "is an XML document" flag? |
| 21:52 | <heycam> | (maybe it's the same thing) |
| 21:52 | <zcorpan> | right |
| 21:52 | <Domenic_> | non-writable is the new ReadOnly |
| 21:53 | <Domenic_> | non-configurable is the new DontDelete |
| 21:53 | <zcorpan> | application/xhtml+xml -> HTML namespace, image/svg+xml -> SVG namespace, application/xml -> no namespace |
| 21:53 | <zcorpan> | Domenic_: oh, right |
| 21:54 | <heycam> | createElement() in an image/svg+xml document puts things in the SVG namespace? I don't think that's true is it? |
| 21:54 | <zcorpan> | maybe not :-) |
| 21:54 | <zcorpan> | might just be xhtml+xml |
| 21:54 | <heycam> | might be |
| 21:55 | <zcorpan> | i'm saying this from memory. might be all lies :-P |
| 21:55 | heycam | finds coffee |
| 21:55 | zcorpan | finds a bed |
| 21:55 | <gsnedders> | Per the DOM spec it always does HTML NS. |
| 21:55 | <zcorpan> | yes, that was established |
| 21:56 | <gsnedders> | I can't read, okay! |
| 21:56 | <zcorpan> | we were just making up what we think gecko does instead of testing what gecko does |
| 21:56 | <zcorpan> | because we lack coffee and sleep |
| 21:56 | <zcorpan> | anyway |
| 21:57 | <gsnedders> | Seem legit. |
| 22:01 | <smaug____> | heycam|away: implementations do something and specs say something else. It is not clear what is the right createElement behavior |
| 22:13 | <TabAtkins> | I forget - is there anything super terrible about subclassing DOMString so you can augment it with better stuff, but still have it look like a string? |
| 22:19 | <TabAtkins> | (Context: thinking about the CSSOM Values API again, and just turning it on by default by switching el.style.foo from returning a DOMString to returning this new DOMString subclass. |
| 22:19 | <TabAtkins> | ) |
| 22:20 | <heycam> | TabAtkins, just that that's not really possible |
| 22:21 | <TabAtkins> | Heh, "just". Why not? |
| 22:21 | <heycam> | otherwise I think that would have been a good plan for doing much of the SVG DOM improvements |
| 22:21 | <heycam> | it's not clear what you mean by "subclassing DOMString", really |
| 22:21 | <heycam> | DOMString is meant to represent a JS String value |
| 22:21 | <heycam> | not an object |
| 22:22 | <TabAtkins> | Yeah, can we just return something with String on its prototype chain? Or maybe just has toString set, and the attributes have [PutForward] |
| 22:22 | <heycam> | my spidey sense is telling me this is a bad idea :) |
| 22:23 | <heycam> | nobody really uses String objects etc. |
| 22:23 | <TabAtkins> | The only difference between it and a string would be the typeof/instanceof behavior (probably not actually exercised in real code), and the fact that it can't be falsey (but do we ever return empty strings)? |
| 22:23 | <heycam> | and that you can't compare to String objects for equality with == |
| 22:24 | <heycam> | since that checks for object identity |
| 22:24 | <TabAtkins> | You mean === |
| 22:24 | <TabAtkins> | But yeah. |
| 22:24 | <TabAtkins> | But == works. |
| 22:24 | <heycam> | no... |
| 22:24 | <heycam> | == also checks for object identity if the two things are objects |
| 22:24 | <TabAtkins> | Oh, yeah. |
| 22:24 | <gsnedders> | String *objects* v. string *primitives* |
| 22:25 | <TabAtkins> | I thought you were talkinga bout things like "if(el.x == '5')" |
| 22:25 | <heycam> | ah |
| 22:25 | <heycam> | that would work |
| 22:25 | <gsnedders> | And you never /ever/ want to touch a String object. |
| 22:25 | <gsnedders> | So you never ever want to have String.prototype on a prototype chain. |
| 22:25 | <heycam> | but yeah, the falsey issue and equality checking were the reasons we discounted doing something similar for SVGAnimatedLength |
| 22:25 | <gsnedders> | Because string objects are evil. |
| 22:25 | <heycam> | there is that! |
| 22:26 | <TabAtkins> | gsnedders: Hrm, but I want something that acts like a string, but with more stuff. |
| 22:26 | <TabAtkins> | We could always have it just expose all the string methods manually, and have indexed properties for the characters in its string representation. ^_^ |
| 22:27 | <heycam> | still, I wouldn't think it's out of the question for someone to do: if (el.style.color == el.style.backgroundColor) |
| 22:27 | <heycam> | or something like that |
| 22:27 | <gsnedders> | TabAtkins: No you don't. |
| 22:28 | <TabAtkins> | heycam: True. |
| 22:28 | <TabAtkins> | gsnedders: I don't? |
| 22:28 | <gsnedders> | TabAtkins: No, you don't. |
| 22:29 | <TabAtkins> | I wasn't asking for a repeat. ^_^ |
| 22:30 | <gsnedders> | I didn't! |
| 22:30 | <gsnedders> | I added a comma! |
| 22:30 | <TabAtkins> | Anyway, why don't I? |
| 22:31 | <gsnedders> | What's your use-case? |
| 22:32 | <gsnedders> | (You don't want to use string objects because they appear to be like string primitives, which people are used to, but then aren't in a few subtle ways.) |
| 22:32 | <TabAtkins> | Magically upgrade el.style.foo into a more full-featured object. |
| 22:32 | <gsnedders> | More seriously, how the hell did it get this late? |
| 22:32 | <TabAtkins> | Hahaha |
| 22:33 | <gsnedders> | I need to sleep, man. |
| 22:34 | <gsnedders> | TabAtkins: FWIW, I'd be tempted to try something with making it a new object with a valueOf that returned a string. |
| 22:35 | <gsnedders> | But idk, I haven't thought about it, and I need sleep. |
| 22:42 | <Hixie> | TabAtkins: you don't subclass DOMString, you make a new object for hte attribute, with a PutForwards on the attribute and a serializer on the object |
| 22:42 | <Hixie> | TabAtkins: it's controversial, but i like it. :-) |
| 22:42 | <TabAtkins> | That's fine with me, assuming it works. |
| 22:42 | <TabAtkins> | But it does mean that, for example, el.style.foo.slice(5, 10) doesn't work. |
| 22:42 | <TabAtkins> | While it did work back when you had a string. |
| 22:44 | <TabAtkins> | And I guess that "el.style.color == el.style.backgroundColor" stops working. |
| 22:44 | <TabAtkins> | But it does work if you compare it with a string literal. |
| 22:48 | <heycam> | I wonder if anybody ever gets trapped by `window.location == otherWindow.location` not doing what they expect |
| 22:50 | <TabAtkins> | I could certainly see myself falling into that, but I suppose I shouldn't admit that if that's what I'm wanting to do. ^_^ |
| 23:14 | <TabAtkins> | Hmm... if we manually add the String operations to CSSValue, and add indexed properties for the characters of the string representation, then we'd avoid one of the big possible compat pitfalls. |
| 23:14 | <TabAtkins> | We wouldn't actually be a String subclass, but we'd act like it. |
| 23:20 | <TabAtkins> | heycam: ^^^ Maybe a [StringClass] attribute to automate the "I'm a fake string!" process? ^_^ |
| 23:20 | <annevk> | TabAtkins: I think we went through this once before |
| 23:21 | <TabAtkins> | annevk: There you are! |
| 23:21 | <TabAtkins> | Yes, I was wanting a refresher on the problems. |
| 23:21 | <annevk> | I'm not really here |
| 23:21 | <annevk> | http://lists.w3.org/Archives/Public/public-script-coord/2010JanMar/thread.html#msg21 |
| 23:21 | <TabAtkins> | d'oh |
| 23:21 | <heycam> | I don't think I'd be happy with fake strings, unless there were proper support for them in JS itself, so that == etc. could work |
| 23:21 | <TabAtkins> | Ah, excellent. |
| 23:22 | <TabAtkins> | heycam: Clearly we just need to wait for ES to do the operator-overloading thing. |
| 23:22 | <heycam> | maybe! |
| 23:22 | <TabAtkins> | Which is much closer to happening now. |
| 23:22 | <heycam> | do you have a pointer to any preliminary work on that? |
| 23:23 | <annevk> | Brendan did a presentation at the last TC39 meeting |
| 23:24 | <annevk> | http://esdiscuss.org/topic/typeof-extensibility-building-on-my-value-objects-slides-from-thursday-s-tc39-meeting has the details |
| 23:24 | <heycam> | thanks |
| 23:24 | <annevk> | Yeah, seems like that's what might work for something coolish here. Makes == work anyway. |
| 23:25 | <heycam> | so not being able to do anything useful with rectElement.x etc. was most of the reason for thinking about the "big switch" new SVG DOM |
| 23:26 | <heycam> | if we will be able to treat .x as a string and an object in some sane way, then maybe it's unnecessary |
| 23:29 | <TabAtkins> | rect.x already isn't a string, right? It's an AnimatedLength. |
| 23:30 | <heycam> | right |
| 23:30 | <heycam> | but we want to make it a string |
| 23:34 | <TabAtkins> | I think a combination of stringifier + [PutForwards] may be enough. |
| 23:35 | <TabAtkins> | And it can just have multiple accessors: rect.x.px, rect.x.em, rect.x.string, etc. |
| 23:35 | <TabAtkins> | getters/setters, that is. |
| 23:36 | <annevk> | I feel like I wanted to bug heycam about something, and now I can't remember |
| 23:37 | <heycam> | TabAtkins, I dunno, I feel like I've considered that approach many times but felt it just didn't quite make it, due to == |
| 23:37 | <heycam> | we've actually got the .px stuff in the spec at the moment, though nobody's implemented it yet |
| 23:37 | <TabAtkins> | Yeah, depending on value objects progress, that may not be good. |
| 23:37 | <TabAtkins> | heycam: I just want us to match CSSOM Values API. |
| 23:37 | <heycam> | sure |
| 23:38 | <heycam> | the answer then is not to define the CSSOM Values API like that ;) |
| 23:38 | <TabAtkins> | Heh. |
| 23:38 | <heycam> | are you working on that btw? |
| 23:39 | <TabAtkins> | Still, some lessons need to be taken from the Values API, like how to handle list-valued properties in a way that's consistent between always-been-a-list and turned-into-a-list-later. |
| 23:39 | <TabAtkins> | Kinda. |
| 23:39 | <TabAtkins> | It's been on my list for a while, but I'm bumping it up to help with SVG. ^_^ |
| 23:39 | <heycam> | ok cool |
| 23:43 | <TabAtkins> | As far as I can tell (ignoring the CSS part for a bit, so we just have an SVG clean slate), the only reason to have it as a string is to allow for immediate string operations on the value. Right? |
| 23:44 | <heycam> | yes |
| 23:44 | <heycam> | and for consistency with HTML attribute reflections |
| 23:44 | <TabAtkins> | Hm, okay. |
| 23:46 | <TabAtkins> | Hm, what about, in concert with CSSStyleDeclaration gaining a .values property that returns a new map of property names to the magical objects rather than strings, SVG elements also gain a .values property that returns a new map of attribute names to the magical objects. |
| 23:47 | <heycam> | something like that would be acceptable. better than xAsLength, yAsLength, etc. |
| 23:47 | <TabAtkins> | Yeah, definitely. |
| 23:47 | <TabAtkins> | And we could later do the same thing with HTML, if necessary. |
| 23:48 | <shepazu> | heycam, had you talked with anyone else (at moz or other implementers) about your proposal, and what did they say? |
| 23:48 | <TabAtkins> | (We're already hiding .values from the with(){} of event handlers, so this would catch that too.) |
| 23:48 | <heycam> | no. well I sent it to brian for get some initial comments, but that's all. |
| 23:48 | <shepazu> | just curious |
| 23:49 | <heycam> | and Tab, but he didn't reply quickly enough :) |
| 23:50 | <TabAtkins> | Yeah, sorry, I was slow in replying. :/ |
| 23:52 | heycam | often has that problem, so doesn't blame anyone else for doing so |
| 23:53 | <heycam> | biab |
| 23:55 | <TabAtkins> | Oh, huh, I thought that images rotated along with the text in vertical writing modes. |
| 23:55 | <TabAtkins> | Let's see if FF has the same behavior as Chrome... |
| 23:59 | <TabAtkins> | Oh, FF doesn't do writing mode yet. Wonderful. |