| 08:31 | <annevk> | new callback syntax |
| 08:31 | <annevk> | yay |
| 08:49 | <annevk> | DOM updated to use new callback syntax |
| 09:07 | <zcorpan> | note to forums.whatwg.org users - if you have 0 posts then it's likely that your account has been deactivated. if you want it activated again, ping me |
| 09:09 | <annevk> | can you format that into a tweet? |
| 09:20 | <zcorpan> | 0-post forums.whatwg.org accounts have been deactivated (to kill sleeping spam accounts). Ask @zcorpan if you want yours activated again. |
| 09:22 | <annevk> | thanks |
| 09:23 | <zcorpan> | cheers |
| 09:40 | <Ms2ger> | No tests for FileAPI yet? |
| 09:55 | <MikeSmith> | Ms2ger: none that I could find |
| 10:06 | <annevk> | if someone has an idea for http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-nodefilter |
| 10:06 | <annevk> | let me know |
| 10:07 | <annevk> | could split out acceptNode into a callback interface and leave the rest an interface |
| 10:07 | <annevk> | that's not what UAs do today though |
| 10:55 | <Ms2ger> | annevk, seems like you only semi-updated EventListener |
| 11:18 | <zcorpan> | annevk: https://bitbucket.org/annevk/webvtt needs a better name |
| 11:36 | <root_op> | I couldn't find a more suiting channel for SVG questions so I decided to make an attempt here; |
| 11:37 | <root_op> | Basically I have five path elements with some coordinates to note my points. I then have five use elements that use these path elements to mirror them. |
| 11:37 | <root_op> | Together they make an anagram that I've been sketching on for some time. |
| 11:38 | <root_op> | Although I need an easy way to resize the entire group of objects, something I just can't seem to pull through with. Any ideas? |
| 11:38 | <root_op> | I intend to use the graphic inline on an HTML5 page, so it would be swell if I could have it's size decided dynamically by the CSS I link with. |
| 11:39 | <root_op> | Also, if anybody knows of a better suiting channel please let me know. |
| 12:47 | <root_op> | Nevermind, I found the solution being preserveAspectRatio="xMinYMin meet" viewBox="0 0 580.17876 228.1876" |
| 14:47 | <annevk> | zcorpan: like? |
| 14:49 | <zcorpan> | dunno, i'm not good at naming :-P |
| 14:50 | <annevk> | thanks Lachy |
| 14:51 | <annevk> | I think if I change the name the URL changes as well |
| 14:51 | <annevk> | anyway it's just source code |
| 14:51 | <annevk> | http://quuz.org/webvtt/ is the public facing site |
| 14:56 | <annevk> | I guess NodeFilter can just become a callback interface as well |
| 14:56 | <annevk> | actually, that would prevent NodeFilter.XXX from working |
| 14:56 | <annevk> | hmm |
| 14:59 | <annevk> | Ms2ger: what did I miss? |
| 15:00 | <annevk> | anyone an idea what's wrong with http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#eventtarget ? |
| 15:08 | <zcorpan> | callback interface |
| 15:09 | <annevk> | yeah that exists now |
| 15:11 | <zcorpan> | you're using the wrong syntax |
| 15:12 | <zcorpan> | s/interface// |
| 15:13 | <annevk> | hmm |
| 15:13 | <annevk> | heycam suggested this syntax |
| 15:13 | <annevk> | and http://dev.w3.org/2006/webapi/WebIDL/#dfn-callback-interface defines it |
| 15:17 | <zcorpan> | oh, i thought heycam used "callback EventListener { ... }" in email |
| 15:23 | <smaug____> | nothing in the web platform is stable, not even the language used for defining the APIs :) |
| 15:46 | annevk | files a bug on the NodeFilter stuff |
| 16:10 | <annevk> | it's so hard to read Leif's email |
| 16:10 | <annevk> | I almost missed he actually pointed out something new |
| 16:10 | <annevk> | well new to me |
| 16:10 | <annevk> | Trident/WebKit look for a BOM before paying attention to the encoding label |
| 16:30 | <annevk> | so if you buy into those implementations, should the BOM then be handled before you hit the encoding layer? |
| 16:30 | <annevk> | pretty much any steps that involve determining the encoding of a resource already deal with a BOM |
| 16:30 | <zewt> | be good to know just how many sites it actually matters for... |
| 16:31 | <annevk> | so they might as well pick the appropriate encoding to decode the resource with and remove the BOM before passing it on |
| 16:32 | <annevk> | I don't know, but the current divergence is not good |
| 16:33 | <annevk> | the longer this continues the more likely it is you get some situation where you have to pick between two sets of resources authored in different ways |
| 16:33 | <zewt> | i'm still in favor of utf-16 triggering comic sans |
| 16:35 | <annevk> | out of scope :p |
| 16:35 | <zewt> | as are most dreams |
| 16:35 | <annevk> | only pipe dreams |
| 16:36 | <zewt> | puff puff |
| 16:38 | <annevk> | I should add the remaining multi-octet encodings, got an email about a missing one |
| 16:44 | <AryehGregor> | annevk, for insertNode in a Comment, IE9 throws a HierarchyRequestError or some other exception? |
| 16:45 | AryehGregor | hopes to get a monitor today so he can move back to using his familiar old desktop and remember how to do stuff like connect to EC2 |
| 16:46 | <annevk> | AryehGregor: hierarchy |
| 16:46 | <annevk> | AryehGregor: I thought I mentioned that |
| 16:46 | <AryehGregor> | (and, like, stay on IRC and not get disconnected when my laptop sleeps) |
| 16:46 | <AryehGregor> | annevk, you did, but I wasn't totally sure that's what you meant. Thanks. |
| 16:46 | <annevk> | coolio |
| 16:47 | <annevk> | btw, your tests are being used |
| 16:47 | <annevk> | that's what got me to pay attention to those Range issues again :) |
| 16:48 | <annevk> | so thanks for making them and keeping them up to date |
| 16:48 | <AryehGregor> | :) |
| 16:48 | <AryehGregor> | The mutation ones should probably be split up among tests for the various relevant methods. |
| 16:48 | <AryehGregor> | You mean used at Opera? |
| 16:51 | <annevk> | yeah |
| 16:51 | <annevk> | mutations needs a lot of work :( |
| 16:52 | <annevk> | that it's pretty difficult doesn't help :( |
| 16:54 | <annevk> | hopefully there's a lot more text about it at the end of Q1 |
| 16:54 | <annevk> | and if not I should really start planning to do it |
| 17:00 | <AryehGregor> | None of my test ranges started in a non-detached comment, so there was actually no test coverage for insertNode into a comment. |
| 17:01 | AryehGregor | needs a JS code coverage analyzer |
| 17:02 | <gsnedders> | Surely you just care about DOM code coverage? |
| 17:02 | <gsnedders> | Which you should be able to get with any code coverage tool and browser source. |
| 17:02 | <gsnedders> | Time to play around with AryehGregor's WebIDL test framework thing. |
| 17:03 | <AryehGregor> | gsnedders, oh, well, *browser* source. Yes, that's valid too. |
| 17:03 | <AryehGregor> | I was thinking of cases where I write spec implementations in JS. |
| 17:04 | <AryehGregor> | Browser source coverage would be interesting to know also, but there would likely be more false positives, since there are lots of non-spec-related things going on. |
| 17:05 | <AryehGregor> | Whereas my JS implementations tend to have one or a few lines of code for every spec line, so code coverage more closely corresponds to spec coverage. |
| 17:07 | <gsnedders> | AryehGregor: Bugs in idlharness.js, want emails or just other to patch it? |
| 17:07 | <AryehGregor> | gsnedders, feel free to patch it yourself. An e-mail or Bugzilla bug about it would be nice, though. |
| 17:08 | AryehGregor | really wishes we used Bitbucket or github or something so we could do forks and pull requests instead of having this "commit access" idea |
| 17:09 | <AryehGregor> | jgraham, by the way, did you ever think of using hg-git+Gerrit for code review for the W3C stuff in Mercurial? |
| 17:11 | <gsnedders> | AryehGregor: On a related topic, I wonder if we should include Typed Array support right in it, along with the basic DOM stuff it includes. |
| 17:12 | <AryehGregor> | What basic DOM stuff does it include? |
| 17:12 | <gsnedders> | AryehGregor: create_suitable_object has Node in it |
| 17:13 | <AryehGregor> | Oh, it does? |
| 17:14 | <AryehGregor> | Seems so. |
| 17:14 | <AryehGregor> | I forgot that was even used anywhere, but I guess it is. |
| 17:25 | <annevk> | hmm, somewhat less useful view than I hoped http://www.delicious.com/stacks/view/EwV9c8 |
| 17:27 | <annevk> | AryehGregor: http://dvcs.w3.org/hg/domcore/rev/2bab24def8d9 seems to be losing some markup |
| 17:27 | <AryehGregor> | Where? |
| 17:28 | <annevk> | Comment is no longer linked |
| 17:28 | <AryehGregor> | Oh, bleh. |
| 17:29 | <annevk> | also, I try to stick to 76 characters a line for useful diffing |
| 17:32 | <zewt> | --- |
| 17:32 | <zewt> | death to pretending the world is 80x25 |
| 17:37 | <annevk> | until someone invents a better diff, 76 is rather nice |
| 17:37 | <AryehGregor> | Surely 79 characters is fine for diffing? |
| 17:38 | <zewt> | hmm? diff doesn't care about line length |
| 17:38 | <AryehGregor> | That's what I normally use. |
| 17:38 | <AryehGregor> | zewt, if you're using an 80-character-wide terminal, 80-char lines will wrap when you prefix them with + or -. |
| 17:38 | <zewt> | so? |
| 17:38 | <annevk> | less readable |
| 17:38 | <zewt> | if you're using an 80-column terminal then you need to get out of 1992 and make your terminal bigger |
| 17:39 | <annevk> | the point is you need a fixed width |
| 17:39 | <annevk> | might as well be around 80 |
| 17:39 | <zewt> | wrapping code to <80 columns is invariably a recipe for gross code |
| 17:39 | <zewt> | i use around 120-150 |
| 17:39 | <annevk> | this is prose and it reads rather well at 80 |
| 17:39 | <AryehGregor> | annevk, pushed a fix. |
| 17:39 | <annevk> | AryehGregor: oh, it seems fine actually, looked at the wrong file |
| 17:40 | <annevk> | AryehGregor: though if I can make a request, I'd prefer no line-breaks in element usage |
| 17:40 | <AryehGregor> | What do you mean? |
| 17:40 | <annevk> | AryehGregor: having <span\ntitle=...> is annoying when doing straightforward search & replace |
| 17:40 | <annevk> | I likewise try to avoid breaking on terms |
| 17:41 | <AryehGregor> | I don't break my lines manually, so . . . |
| 17:41 | <AryehGregor> | How do you break lines? What editor do you use? |
| 17:41 | <annevk> | I break them manually |
| 17:41 | <annevk> | because I don't really trust my editor :) |
| 17:42 | <annevk> | TextWrangler at the moment |
| 17:43 | AryehGregor | uses vim and has it break lines automatically |
| 17:44 | <AryehGregor> | That's part of why I developed my macro system for the editing spec source, so that it wouldn't break tags onto multiple lines and mess up search-and-replace. Although it was mostly because the anolis syntax is infuriatingly wordy, especially if most of the refs are cross-spec. |
| 17:44 | <AryehGregor> | (not as bad for DOM, very bad for editing) |
| 17:45 | <annevk> | yeah maybe we should get someone hired somehow to fix that |
| 17:46 | <annevk> | better spec tools would be nice |
| 17:54 | AryehGregor | kicks compiz and/or Unity and/or lightdm and/or Ubuntu |
| 17:54 | <AryehGregor> | At least I only have to restart the window manager and not the computer, right? |
| 17:54 | <AryehGregor> | Anyway, as I was going to say before my window manager got borked: annevk, how does my proposed normalize() algorithm replace when there's no need, any more than the current one does? |
| 17:56 | <annevk> | oh |
| 17:56 | <annevk> | the current one is far from perfect |
| 17:57 | <annevk> | maybe we should start paying attention to the mutation observer stuff once we actually start writing that text |
| 17:57 | <annevk> | but since I know it's coming I sort of want new text to take it into account |
| 18:00 | <AryehGregor> | Mm. |
| 18:00 | <annevk> | that's how I usually feel about it too |
| 18:05 | <AryehGregor> | annevk, is there some reason we don't want splitting a text node to add the new text node before replacing data? If we did that, it would be easy to avoid the problems caused by both splitting and replacing data modifying ranges. |
| 18:05 | <AryehGregor> | Just modify them in the split algorithm before removing the data. |
| 18:06 | <AryehGregor> | Then when you do the replace data, there will be no boundary points in the replaced data, so nothing will change. |
| 18:07 | <AryehGregor> | Is there a reason why we do "For each range whose start is X, do Y. For each range whose end is X, do Y." instead of "For each boundary point that's X, do Y."? |
| 18:07 | <AryehGregor> | Practically speaking UAs are probably going to implement it the first way, but it's longer, and you have to look closely to verify that the same thing is being done to starts and ends. |
| 18:08 | <annevk> | I guess the MutationRecord order would change |
| 18:09 | <annevk> | But basically I do not know |
| 18:09 | <AryehGregor> | I think I cheated when I did it by saying "except when called by splitText", but that's lame. |
| 18:09 | <AryehGregor> | Should I change the split algorithm accordingly? |
| 18:09 | <annevk> | As for describing ranges, the reason I changed it this way was because this seemed more in line with how ranges are described (and prolly implemented) |
| 18:10 | <AryehGregor> | It's twice as long and involves copy-pasting, though, although I agree it's definitely more in line with how it will be implemented. |
| 18:10 | <annevk> | AryehGregor: yeah we can change it for now, but add a note that this needs to be tested when the new world order arrives |
| 18:10 | <AryehGregor> | Anyway, doesn't matter much to me. |
| 18:10 | <AryehGregor> | Okay, will do. |
| 18:14 | <AryehGregor> | annevk, why do you use </p>? It's longer markup and creates more text nodes. |
| 18:16 | <annevk> | usually I try not to, but force of habit when I do |
| 18:16 | <AryehGregor> | k. |
| 18:17 | <volkmar> | annevk: regarding mozilla bug 673922, do you know if the conversation went to a list? |
| 18:17 | <volkmar> | I doubt it went to www-style (at least, I haven't seen it) |
| 18:18 | <volkmar> | but I wonder for public-geolocation |
| 18:18 | <AryehGregor> | Do we really need a note here? I mean, do we have any reason to think implementations followed the spec's order to start with? |
| 18:18 | <annevk> | volkmar: haven't seen it on geolocation, don't follow www-style |
| 18:18 | <annevk> | AryehGregor: i meant in the form of <!-- dragon potential --> |
| 18:18 | <annevk> | AryehGregor: if you feel that's overkill, fine |
| 18:19 | <AryehGregor> | I'll add a comment saying why we order it that way and pointing to the bug, how about that? |
| 18:19 | <annevk> | sounds good |
| 18:20 | <volkmar> | annevk: and why do you think geolocation is appropriate? |
| 18:20 | <volkmar> | I would have pick the DAP WG instead... |
| 18:20 | annevk | opens bug again |
| 18:20 | <annevk> | volkmar: they define orientationchange |
| 18:21 | <annevk> | oh |
| 18:21 | <volkmar> | really? |
| 18:21 | <annevk> | or is that called deviceorientation |
| 18:21 | <annevk> | http://dev.w3.org/geo/api/spec-source-orientation.html |
| 18:21 | annevk | thinks this is confusing |
| 18:22 | <volkmar> | this is a bit different from orientation given that it's much more the screen orientation instead of the device |
| 18:23 | <annevk> | oh right, my bad |
| 18:23 | <volkmar> | though, that spec would be more appropriate in DAP I believe |
| 18:23 | <annevk> | I'd say CSS but then CSS is pretty poor when it comes to APIs |
| 18:24 | <annevk> | anyway if you're going to add a comment to that bug say I had deviceorientation and orientation confused |
| 18:26 | <volkmar> | ok |
| 18:28 | <AryehGregor> | annevk, can I go ahead with the insertNode changes to match non-Gecko browsers? |
| 18:28 | <annevk> | I think so |
| 18:29 | <annevk> | smaug____'s case was pretty weak |
| 18:29 | <annevk> | imo of course |
| 18:31 | <AryehGregor> | I see his point, but I think it's mostly "we shouldn't punish Gecko for adhering to DOM 2 Range when other browsers only deviated because Acid3 was wrong". That's fair enough, but pragmatically I agree we want to follow the majority of browsers regardless of history, and this way probably makes more sense anyway. |
| 18:37 | <annevk> | we should add the domintro boxes at some point |
| 18:37 | <annevk> | last time I added a whole lot while traveling |
| 18:37 | <annevk> | should do that again :) |
| 18:45 | AryehGregor | discovers he can't use EC2 because it requires a key pair that's only on his nonfunctional desktop, sigh |
| 18:45 | AryehGregor | just doesn't test in IE for now |
| 18:48 | <annevk> | if you have live dom viewer URLs it's very easy for me to test |
| 18:49 | <annevk> | or stuff that works in the live dom viewer, or an actual test online |
| 18:49 | <annevk> | using vmware at the moment and it's pretty sweet |
| 18:53 | <AryehGregor> | I don't really *need* to test anything right now. |
| 18:53 | <AryehGregor> | I'd use VMWare, but then I'd have to give Microsoft a nontrivial amount of money. |
| 18:54 | <AryehGregor> | (EC2 presumably forwards some money to MS, but not nearly as much given how little I use it.) |
| 18:55 | <annevk> | Google presumably has some kind of unlimited use license |
| 18:56 | <AryehGregor> | That doesn't help me. |
| 18:57 | <annevk> | too bad |
| 18:57 | <annevk> | maybe you can get one with compliments from the IE Team? |
| 18:58 | <annevk> | doesn't seem like a totally insane idea to give away Windows to people who write standards for it |
| 18:59 | <AryehGregor> | It's not a big deal, EC2 works fine. |
| 19:07 | <AryehGregor> | annevk, if you download in Live DOM Viewer right now, what does IE say? |
| 19:07 | <AryehGregor> | Chrome says "[object Text],2,[object HTMLHeadElement],2", which is simplest, so I'll probably go with that. |
| 19:07 | <AryehGregor> | Just want to check that IE says the same. |
| 19:07 | <annevk> | [object Text],2,[object Text],2 |
| 19:08 | <zewt> | ms has those VMs for testing IE, though I didn't quite manage to get them running in vmware |
| 19:08 | <AryehGregor> | Bleh. |
| 19:09 | <zewt> | they loaded, but iirc the mouse didn't work |
| 19:09 | <AryehGregor> | I'll go with Chrome since it's easiest and this is a silly corner case. |
| 19:09 | <AryehGregor> | This is IE9 you're testing? |
| 19:09 | <zewt> | (which is strange; that's something that normally just works, even without magic vmware drivers) |
| 19:10 | <annevk> | AryehGregor: yes |
| 19:10 | <AryehGregor> | Thanks. |
| 19:11 | <AryehGregor> | Opera is interesting: [object Text],2,[object Text],0. |
| 19:11 | <AryehGregor> | That's pretty neat, actually. |
| 19:11 | <AryehGregor> | Maybe I'll go with that. |
| 19:12 | <AryehGregor> | Actually, probably not, since it will prevent us from matching IE or Chrome in non-corner cases. |
| 19:18 | <AryehGregor> | The non-Gecko behavior for insertNode() is actually surprisingly nontrivial to spec. |
| 19:18 | AryehGregor | just hit a second corner case he has to handle |
| 19:20 | <AryehGregor> | annevk, now what does IE say in Live DOM Viewer? |
| 19:20 | <AryehGregor> | WebKit and Opera both say "[object HTMLHeadElement],0,[object HTMLHeadElement],1", so I suspect I'll have to change the spec. Actually, I definitely need to if I want insertNode to always make the range contain the inserted node. Bleh. |
| 19:23 | <annevk> | [object Text],2,[object Text],2 |
| 19:23 | <annevk> | hmm |
| 19:23 | <annevk> | [object HTMLHeadElement],0,[object HTMLHeadElement],1 |
| 19:23 | <AryehGregor> | Thanks. |
| 19:23 | <annevk> | IE does some weird ass caching |
| 19:23 | AryehGregor | takes a different tack |
| 19:24 | <AryehGregor> | Yeah, "download" only works the first time. You have to restart to get it to work again. |
| 19:24 | <AryehGregor> | Annoying. |
| 19:24 | <annevk> | oh, all browsers? |
| 19:24 | <AryehGregor> | No, IE9. |
| 19:24 | <AryehGregor> | Works fine in non-IE. |
| 19:29 | <annevk> | "fixed" |
| 19:30 | <annevk> | internet options -> "browsing history" settings -> "every time i visit the website" |
| 19:32 | AryehGregor | wishes he had known about that like a year ago |
| 19:40 | <AryehGregor> | Looks like WebKit now has only about two distinct insertNode() bugs. |
| 19:40 | <AryehGregor> | Per spec. |
| 19:40 | <AryehGregor> | As does Gecko, one of them newly added. |
| 19:45 | <annevk> | so I just found a site with a BOM and a HTTP charset that says something else |
| 19:46 | <annevk> | reported as a bug against Opera; works fine in WebKit/Trident |
| 19:46 | <Velmont> | MikeSmith: Your bug is most probably fixed in next release. |
| 19:48 | <annevk> | broken in Gecko too, but in a more subtle way as Gecko has different error handling |
| 19:48 | <annevk> | though the characters are incorrect as far as I can tell |
| 19:51 | <annevk> | there's this quote (from Sam Ruby I think) about the closer the data is to the resource the better it gets |
| 19:51 | <annevk> | but it doesn't go at all like that |
| 19:51 | <annevk> | anyone? |
| 19:53 | <annevk> | found it |
| 19:53 | <annevk> | "I have a theory that, in general, the accuracy of metadata is inversely proportional to the distance between the metadata and the data which it proports to describe." |
| 19:53 | <annevk> | http://intertwingly.net/blog/2004/09/23/Copy-and-Paste |
| 19:54 | <annevk> | combined with Trident/WebKit giving that piece (BOM) more authority in this case, it seems it would apply |
| 19:56 | <zewt> | but it's very ugly for a BOM marker (in-file metadata) to take priority over external metadata (HTTP), while having <meta> lower priority |
| 19:56 | <zewt> | that is, meta < http headers < BOM |
| 19:57 | <zewt> | (personally I find meta charset being lower priority than HTTP headers really annoying, but we're stuck with it...) |
| 20:00 | <zewt> | i suppose being able to completely disable prescan is a plus, it's just annoying that I have to explicitly fiddle with .htaccess to remove charset for others |
| 20:00 | <AryehGregor> | Hmm. Testing range mutation for normalize() would actually require work, since my pre-fab DOMs are already normalized and not very interesting to test. |
| 20:01 | <annevk> | AryehGregor: please also push to bitbucket |
| 20:01 | <AryehGregor> | Oops, forgot. |
| 20:01 | <annevk> | that's the one I pull from |
| 20:02 | <annevk> | and I think Ms2ger too |
| 20:02 | <AryehGregor> | There should be some way to automate that so I don't have to run two pushes every time. |
| 20:02 | <AryehGregor> | Otherwise I'll forget. |
| 20:02 | <annevk> | thanks |
| 20:02 | <annevk> | you could write a commit script |
| 20:03 | <annevk> | or push or whatever you want |
| 20:03 | <annevk> | or just use bitbucket and let us update the other one |
| 20:04 | <annevk> | zewt: not sure it matters much what takes precedence in implementations |
| 20:04 | <annevk> | zewt: it's all error handling |
| 20:05 | <zewt> | don't follow; if the precedence is wrong then you end up on the wrong encoding and mojibake away |
| 20:06 | <annevk> | I mean with respect to "ugly" |
| 20:07 | <zewt> | it's only "error handling" for parts of the charset detection which are "deprecated" (in the loose web sense of "you shouldn't be using this anymore") |
| 20:07 | <annevk> | the order is important, but it only comes into play if the author does something wrong |
| 20:08 | <zewt> | not necessarily |
| 20:09 | <zewt> | for example, in the ideal world that we don't live in, if HTTP < META < BOM, then it could be logical to say "charset=utf-8" in the HTTP header, and then override it with UTF-16LE using the BOM |
| 20:09 | <zewt> | even though they say different things, whether that's actually wrong or ugly or not is arguable |
| 20:09 | <annevk> | ideal world -> no legacy encodings exist |
| 20:10 | <zewt> | (so long as the result is interoperable and properly defined) |
| 20:10 | <zewt> | that's a higher level of idealism :) |
| 20:13 | <zewt> | anyway, since the only time I'd ever use legacy encodings is for testing, i'd just shrug and go with whatever is easiest to get interop on |
| 20:14 | <annevk> | this is a fairly invasive change for non-WebKit/Trident browsers |
| 20:14 | <annevk> | and for standards too |
| 20:15 | <annevk> | File API / XHR / HTML |
| 20:17 | <annevk> | I guess I'll file a bug tomorrow on HTML and maybe XHR, cc a bunch of people and see what they say |
| 20:19 | <mkanat> | I suppose the advantage is that BOMs are almost always authoritative, but that when they're not, it's going to confuse the heck out of developers what's going on with their pages. |
| 20:20 | <zewt> | it's hard for the BOM to be wrong, since that's what editors pick up |
| 20:20 | <mkanat> | Yeah, that was my thought as well. |
| 20:20 | <zewt> | meta could do that too, but doesn't in practice |
| 20:20 | <mkanat> | But it's impossible to predict every situation a developer is going to be in. |
| 20:20 | <annevk> | my hex editor is fairly agnostic :p |
| 20:20 | <zewt> | (i'm sort of surprised Vim doesn't pick up meta charsets, though) |
| 20:24 | <annevk> | kind of weird how such a fundamental difference has been largely overlooked |
| 20:24 | <annevk> | thanks to Leif Halvard Silli for pointing it out |
| 20:29 | <mkanat> | Probably it's because so few text editors actually add BOMs to their UTF files. |
| 20:30 | <mkanat> | And in the ones that don't understand it, it looks like strange garbage, so developers have become averse to them. |
| 20:30 | <annevk> | didn't work well with PHP either |
| 20:31 | <annevk> | {BOM}<?php header(... would fail |
| 20:31 | <annevk> | not sure if that changed |
| 20:32 | <zewt> | BOMs are pretty heinously evil, since text files are fundamentally streaming data |
| 20:34 | <zewt> | they're common enough that it's a big stream for php to not discard them for utf-8, though |
| 20:34 | <zewt> | uh |
| 20:34 | <zewt> | strange |
| 20:34 | <zewt> | (damn you muscle autocomplete) |
| 21:01 | <AryehGregor> | Yay, the spec for compareBoundaryPoints gets START_TO_END and END_TO_START backwards. |
| 21:01 | <AryehGregor> | I think. |
| 21:01 | <AryehGregor> | To be investigated further tomorrow. |
| 21:22 | <annevk> | AryehGregor: if you fix that, also define the constants more similarly to compareDocumentPosition |
| 21:22 | <annevk> | (or change compareDocumentPosition I guess) |
| 21:32 | <TabAtkins> | volkmar: orientation locking has never come up in CSS. It might make sense, but as Anne says, the csswg is bad at APIs. However, we do have the @viewport spec, where it might be appropriate. But a pure-JS api, as discussed in bug, might be better. I dunno. |
| 21:35 | <annevk> | btw |
| 21:35 | <annevk> | my plan is to put the tables outside the text |
| 21:36 | <annevk> | also for the single-octet stuff for consistency |
| 21:36 | <annevk> | I think will simply reuse the format Unicode.org has so people can easily compare |
| 21:36 | <volkmar> | TabAtkins: I would prefer a pure JS API |
| 21:36 | <TabAtkins> | Given the use-cases, I suspect a pure JS api would probably be best as well. |
| 21:37 | <TabAtkins> | Static pages generally shouldn't be caring about their orientation. |
| 21:37 | <volkmar> | yes, that was my idea too |
| 21:37 | <volkmar> | and I don't see any reason why a page want to change it's stylesheet depending on the orientation |
| 21:37 | <TabAtkins> | In other words, I want a normal site to take whatever orientation I put my phone in. I'm okay with apps forcing a particular orientation when they need to. |
| 21:37 | <volkmar> | there are already ways to do that depending on the size |
| 21:37 | <TabAtkins> | Yeah. |
| 21:38 | <TabAtkins> | (Where "app" is defined as "something with functionality largely driven through JS", or something like that.) |
| 21:39 | <volkmar> | actually, regarding this API, the proposal of .preventDefault() had some support but it doesn't seem very good to me |
| 21:40 | <volkmar> | there might be use cases of an app who wants to know of orientation changes (though, I don't see them) |
| 21:41 | <TabAtkins> | There's already a device orientation api for that, no? |
| 21:41 | <volkmar> | yes |
| 21:41 | <TabAtkins> | Then that's good enough. |
| 21:41 | <TabAtkins> | (Presumably - I haven't looked at that api.) |
| 22:07 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=12897#c18 (BOM thing was already filed and rejected by hsivonen) |
| 22:07 | <annevk> | I think I will file a new bug on the subject though to make it somewhat clearer |