| 00:43 | <MikeSmith> | http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/ is actually a really interesting document |
| 00:44 | <smaug____> | MikeSmith: comments welcome :) |
| 00:44 | <MikeSmith> | smaug____: you participated in that XG? |
| 00:45 | <smaug____> | yup |
| 00:45 | <MikeSmith> | oh cool |
| 00:45 | <MikeSmith> | I see your name in the editors list |
| 00:51 | <MikeSmith> | smaug____: the intro at http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#introduction is the clearest high-level overview as far as explaining to Web-app developers what the proposed features would enable |
| 00:52 | <MikeSmith> | I think I'll point people to that part to read first |
| 00:53 | <smaug____> | yeah |
| 00:54 | <smaug____> | Google wants to do a smaller API first |
| 00:54 | <smaug____> | probably in WebApps WG if possible |
| 00:55 | <smaug____> | and I agree, smaller API first would be good |
| 00:55 | <smaug____> | implementing everything from the XG report is a huge task |
| 01:13 | <MikeSmith> | smaug____: yeah, it's pretty ambitious |
| 01:13 | <MikeSmith> | I would like to see a proposal for that smaller API |
| 09:37 | <webben> | what spec should i be looking at for the replacement for mutation events? |
| 09:42 | <Ms2ger> | DOM4 |
| 09:45 | <webben> | Ms2ger: Ah, cheers. |
| 10:14 | <MikeSmith> | Ms2ger: on http://platform.html5.org/ yesterday, I added links to test suites/test cases where I could find any |
| 10:14 | <MikeSmith> | including to "submitted" tests, not just to approved ones |
| 10:14 | <MikeSmith> | the ⓣ links |
| 10:15 | <MikeSmith> | if you see anything missing that I should add links for, lemme know |
| 10:15 | <MikeSmith> | or fork https://github.com/sideshowbarker/platform.html5.org and make a pull request |
| 10:18 | <MikeSmith> | annevk: all links after Server-Sent Events ones still not working in my Opera |
| 10:19 | <MikeSmith> | and still I have no clue why |
| 10:19 | <MikeSmith> | looked at DOM and it's as expected |
| 10:19 | <MikeSmith> | and no errors logged to console |
| 10:20 | <zcorpan> | wfm |
| 10:24 | <MikeSmith> | zcorpan: weird |
| 10:25 | <MikeSmith> | I see the same problem in both Opera.next and 11.60 |
| 10:41 | <Ms2ger> | Does HTML5 still have classList? |
| 10:41 | <MikeSmith> | did last time I checked |
| 10:42 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-classlist |
| 10:42 | Ms2ger | files a bug |
| 10:45 | <MikeSmith> | Ms2ger: was it meant to be dropped? |
| 10:45 | <Ms2ger> | smaug____, were you working on a ProgressEvent constructor already? |
| 10:45 | <Ms2ger> | MikeSmith, it's moved to DOM |
| 10:45 | <MikeSmith> | ah |
| 10:45 | <smaug____> | Ms2ger: there is a bug open for that |
| 10:45 | <Ms2ger> | Good |
| 10:45 | <smaug____> | Ms2ger: bug 710882 |
| 10:47 | <Ms2ger> | MikeSmith, http://w3c-test.org/html/, http://test.csswg.org/harness/ |
| 10:47 | <Ms2ger> | http://hg.ecmascript.org/tests/test262/ |
| 10:48 | <Ms2ger> | SVG also has tests somewhere |
| 10:48 | <MikeSmith> | yeah, I'll ask Doug about those |
| 10:50 | <MikeSmith> | thanks for the other links -- added |
| 10:50 | <Ms2ger> | https://dvcs.w3.org/hg/webevents/raw-file/6c149e83cd5d/test/touchevents/single-touch.html is apparently the only touch events test |
| 10:51 | <smaug____> | there is another for multitouch |
| 10:51 | <smaug____> | a simple one |
| 10:51 | <smaug____> | somewhere in pettay.fi. Art should move it to w3.org |
| 10:51 | MikeSmith | adds that one for now |
| 10:52 | MikeSmith | finds http://w3c.pettay.fi/webevents/tests/touchevents/ |
| 10:55 | <smaug____> | MikeSmith: yeah, the single-touch.html should be the same as what is now in w3.org |
| 10:55 | <MikeSmith> | ah, OK |
| 11:29 | <Velmont> | zcorpan, MikeSmith: I have the same problem with links after SSE not working on http://platform.html5.org/ |
| 11:30 | <MikeSmith> | Velmont: oh, cool |
| 11:30 | <MikeSmith> | well, not cool |
| 11:30 | <MikeSmith> | but at least we know it's reproducible |
| 11:30 | <MikeSmith> | and not a figment of my imagination |
| 11:30 | <MikeSmith> | oh |
| 11:30 | <MikeSmith> | it's Velmont |
| 11:30 | <Velmont> | MikeSmith: lol :P -- Yes, some bug with links and columns then I guess. I'll see if I can make a reduced TC. |
| 11:30 | <MikeSmith> | file a but please man |
| 11:31 | <MikeSmith> | thanks (about making reduced test case) |
| 11:33 | <annevk> | ah shit |
| 11:33 | <annevk> | I need a bigger harddisk |
| 11:33 | <annevk> | I wonder how much a 256 goes for these days |
| 11:34 | <MikeSmith> | Velmont: hmm, yeah, I see now if I switch from 3-column to 2-column or single-column, the problem goes away |
| 11:34 | <Ms2ger> | TB? |
| 11:34 | <zcorpan> | SSD? |
| 11:34 | <MikeSmith> | Velmont: oh, actually I see it doesn't -- it just moves |
| 11:36 | <MikeSmith> | Ms2ger: thanks for moving those tests |
| 11:36 | <Ms2ger> | Np |
| 11:36 | <MikeSmith> | I had actually been planning to do that but you are far lazier than me |
| 11:36 | <annevk> | yeah SSD |
| 11:36 | <MikeSmith> | Ms2ger: I should send you a copy of my TODO list |
| 11:37 | <annevk> | I'm on 128 now and with this new Windows 7 installation within VMWare it's beginning to crack down |
| 11:37 | <Ms2ger> | I'd been planning to do that for months as well :) |
| 11:38 | <MikeSmith> | heh |
| 11:38 | MikeSmith | adds some more test links |
| 11:39 | <MikeSmith> | sweet |
| 11:39 | <MikeSmith> | those tests even use testharness.js |
| 11:42 | <annevk> | I guess I'll call the shop that ordered my MacBook, see if they can do something |
| 11:42 | <Velmont> | It's seemingly affected by the height of the browser window... |
| 11:42 | <annevk> | hah, I do have 8GiB of memory |
| 11:43 | <MikeSmith> | Velmont: I see |
| 11:43 | zcorpan | also has 128 and 8 |
| 11:43 | <Velmont> | Less height = less linky goodness, more height = more linky goodness. |
| 11:43 | <MikeSmith> | aha |
| 11:44 | <Velmont> | Smells optimization. |
| 11:44 | <MikeSmith> | devs getting too smart for their own good |
| 11:45 | <MikeSmith> | it is great to have proper column-break support, though (outside of the link bug) |
| 11:46 | <MikeSmith> | things don't look so great if a browser breaks the column right after a <dt> instead of before it |
| 11:48 | <MikeSmith> | anybody know if Hallvord has tests for Clipboard API and events? |
| 11:48 | <MikeSmith> | also, any tests somewhere for requestAnimationFrame |
| 11:48 | <annevk> | zcorpan: does platform.html5.org also work for you on the second column? |
| 11:48 | <zcorpan> | yes |
| 11:48 | <annevk> | Ms2ger: Gecko did remove initCustomEvent, right? |
| 11:48 | <annevk> | zcorpan: oh |
| 11:49 | <Velmont> | zcorpan: What screen size? |
| 11:50 | <Ms2ger> | Not sure |
| 11:51 | <Ms2ger> | Doesn't look like it |
| 11:52 | <MikeSmith> | and still haven't found any Web Messaging tests |
| 11:59 | <smaug____> | annevk: I'm not removing any init*Event methods from gecko |
| 12:00 | <smaug____> | I mean, not right now |
| 12:00 | <zcorpan> | Velmont: worked with various zoom levels |
| 12:01 | <MikeSmith> | heh "I still can't believe javascript - the f**ing backbone-language of the web - doesn't offer an API for mutating URLs." |
| 12:01 | <Ms2ger> | It does now, doesn't it? |
| 12:12 | <annevk> | I wonder what Marat wants the DOM4 editors to say |
| 12:12 | <annevk> | smaug____: kk |
| 12:12 | <Ms2ger> | "bz is right" |
| 12:12 | <smaug____> | :) |
| 12:17 | <MikeSmith> | is the URL API actually supported already? |
| 12:18 | <Ms2ger> | smaug____, do you remember if we landed the Gecko patch? |
| 12:18 | <MikeSmith> | oh, it is in Gecko |
| 12:19 | <annevk> | meh |
| 12:20 | <annevk> | not exactly cheap |
| 12:20 | <MikeSmith> | how do I get an actual console with completion in Dragonfly? |
| 12:21 | <bga> | lol http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html |
| 12:21 | <smaug____> | Ms2ger: which gecko patch? |
| 12:21 | <smaug____> | Ms2ger: for URLs? |
| 12:21 | <Ms2ger> | Yeah |
| 12:21 | <smaug____> | I don't think so |
| 12:22 | Ms2ger | checks |
| 12:23 | <annevk> | bga: what? |
| 12:23 | <bga> | do you want standardize all things in the world? |
| 12:24 | <Ms2ger> | Nope |
| 12:24 | <Ms2ger> | bga, yes. |
| 12:24 | <bga> | anyway api is bad |
| 12:24 | <annevk> | send feedback! |
| 12:24 | <bga> | sec |
| 12:33 | <Velmont> | MikeSmith: ...? Go to the console tab? It should have tab completion. |
| 12:34 | <MikeSmith> | Velmont: don't seem to do completion for me the way it used to.. Maybe I need to upgrade my Dragonfly |
| 12:35 | <MikeSmith> | oh |
| 12:35 | <MikeSmith> | working as expected in my Opera.next |
| 12:35 | <MikeSmith> | weird |
| 12:36 | <Velmont> | It works here in 11.60. But then again, -- you can run any other DragonFly in the browser, -- Opera doesn't really bundle DragonFly but downloads it from the web and uses appcache to store it. AFAIR. |
| 12:42 | <MikeSmith> | Velmont: yeah, I knew that and thought it also auto-updated |
| 12:43 | <MikeSmith> | how do I tell what version of Dragonfly I have? |
| 12:46 | <MikeSmith> | oh, found it |
| 12:46 | <MikeSmith> | Settings > About in Dragonfly |
| 12:59 | <kennyluck> | webben, (re. what spec should i be looking at for the replacement for mutation events?) and the undomanager spec maybe? |
| 13:01 | <bga> | annevk beta version :) http://pastie.org/3079269 |
| 13:02 | <bga> | full decomposition |
| 13:04 | <annevk> | bga: URIs are called URLs in APIs |
| 13:05 | <annevk> | no opinion other than that really, emailing whatwg⊙wo seems best |
| 13:05 | <bga> | fixed |
| 13:08 | <annevk> | for people with opinions on encodings and conformance checkers: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15332 |
| 13:08 | <annevk> | (already added hsivonen) |
| 13:31 | AryehGregor | gloomily contemplates 427 unread conversations in his spec inbox |
| 13:33 | <annevk> | I was gonna say that it's not a lot of email, but I guess it's a bit more email than 427 if that's conversations |
| 13:34 | <annevk> | MikeSmith: what would r12a want? |
| 13:34 | <MikeSmith> | dunno |
| 13:34 | <Ms2ger> | Is wwrw the new wwjd? |
| 13:35 | <MikeSmith> | annevk: he's already not happy about the reporting that v.nu does for UTF-16 |
| 13:35 | <gsnedders> | Oh, I guess it's Merry Hixieday today! |
| 13:36 | <MikeSmith> | annevk: actually, I think he's not happy about what the spec says about use of UTF-16 |
| 13:36 | <Ms2ger> | Indeed it is |
| 13:36 | <annevk> | wwrw? |
| 13:37 | <annevk> | AryehGregor: I guess you're married now, so congratulations again! |
| 13:37 | <AryehGregor> | Thanks. |
| 13:37 | <gsnedders> | AryehGregor: Congrats! |
| 13:38 | <Ms2ger> | ^What they said |
| 13:38 | <annevk> | MikeSmith: we could make an exception for UTF-16, though everyone tells me it's a world of hurt |
| 13:38 | <annevk> | MikeSmith: making an exception for tis-620 and such though... dunno |
| 13:38 | <MikeSmith> | yeah |
| 13:40 | <MikeSmith> | about conformance-checking tools, Richard has an online tool that he's put a lot of work into and that represents what he thinks the proper type/level of reporting should be, so he kind of uses that a benchmark |
| 13:41 | <MikeSmith> | http://validator.w3.org/i18n-checker/ |
| 13:44 | <MikeSmith> | oh hey |
| 13:44 | <MikeSmith> | for non-UTF8 docs, it does actually report "Non-UTF-8 character encoding declared" |
| 13:44 | <MikeSmith> | so maybe I need to STFU |
| 13:45 | <Ms2ger> | That certainly would make life less interesting |
| 13:45 | <MikeSmith> | heh |
| 13:45 | <annevk> | so if serve "7A 00" as utf-16be only IE outputs "z" |
| 13:45 | <MikeSmith> | and expanding that message shows among others things "UTF-16 is also a character encoding based on Unicode, but is little used on the Web, and generally best avoided." |
| 13:45 | <annevk> | everyone else gives "稀" |
| 13:46 | <annevk> | if I serve it up as utf-16 (without BOM) everyone defaults to utf-16le |
| 13:47 | <MikeSmith> | man, Richard puts a lot of work into this stuff -- he's added more since the last time I checked: "Using non-UTF-8 encodings can also have unexpected results on form submission and URL encodings... It is not a requirement to use UTF-8, but the HTML5 specification recommends its use, and you should consider it." |
| 13:48 | <MikeSmith> | and also "What to do: Replace the http-equiv and content attributes in your meta tag with a charset attribute" |
| 13:48 | <annevk> | utf-16le with FE FF 7A 00 results in "稀" in WebKit/IE |
| 13:48 | <annevk> | Gecko gives "�竿" and Opera "�z"... |
| 13:49 | <gsnedders> | Oh nice. :\ |
| 13:51 | <annevk> | for utf-16be with le BOM it's kind of the same |
| 13:51 | <annevk> | conclusions: BOM is more important |
| 13:51 | <annevk> | utf-16le == utf-16 in WebKit/Trident |
| 13:51 | <annevk> | (afaict) |
| 13:56 | <annevk> | gsnedders: just to be sure, PHP just looks at octets right? |
| 13:56 | <gsnedders> | annevk: yup |
| 13:56 | <annevk> | gsnedders: that is I can write PHP using ASCII octets and follow the ?> with utf-16 octets |
| 13:57 | annevk | uses PHP to set a header |
| 13:57 | <gsnedders> | annevk: PHP has no concept of anything except ASCII |
| 13:57 | <annevk> | and it also doesn't mangle anything right? |
| 13:57 | <annevk> | in that sense it's kind of neat |
| 13:57 | <annevk> | maybe also vulnerable and what not, but neat |
| 13:58 | <gsnedders> | annevk: indeed |
| 13:59 | <annevk> | thanks |
| 14:51 | <annevk> | emailed utf-16 research to the WHATWG list |
| 14:51 | <annevk> | took a while to write it all out |
| 14:56 | <zewt> | annevk: using html mail set to a fixed-width font for tables makes them more readable for a lot of people, fyi |
| 14:58 | <annevk> | wait I'm using html email? |
| 14:58 | <divya> | ouch |
| 14:59 | <annevk> | I'm writing plain text as far as I know |
| 14:59 | <annevk> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-December/034260.html confirms |
| 14:59 | <zewt> | no, i mean if you have stuff that needs to be viewed as fixed-width, it's best to include an html version so you can set that |
| 14:59 | <zewt> | else you get the default of "whatever the user's viewer is set to", which will often be proportional |
| 15:00 | <zewt> | setting fonts in email has few legitimate use cases, but this is one of them |
| 15:00 | <annevk> | AryehGregor: please read IDL before filing a bug |
| 15:00 | <annevk> | AryehGregor: in particular (Node or DOMString) is valid |
| 15:00 | <annevk> | afaik |
| 15:00 | <AryehGregor> | You mean WebIDL? |
| 15:00 | AryehGregor | looks |
| 15:01 | <AryehGregor> | Is that a recent change? |
| 15:01 | <annevk> | yes |
| 15:01 | <AryehGregor> | Oh, I see. |
| 15:01 | <annevk> | in any event, I disagree with the premise of your bug |
| 15:02 | <annevk> | I'm not going to define experimental IDL in prose if I expect IDL to define it at some point in the near future |
| 15:02 | <AryehGregor> | Well, as long as there's at least a concrete proposal for the syntax that's expected to be looked at soon. |
| 15:03 | <AryehGregor> | Then I don't have an issue with it, if it's going to be resolved soon. No need to have strict ordering in that case. |
| 17:55 | <AryehGregor> | Is there any JS-visible difference between "interface Foo { void foo(); }; interface Bar { void bar(); }; Foo implements Bar;" and "interface Foo { void foo(); void bar(); };"? |
| 17:56 | <AryehGregor> | I mean, does "implements" just mean "pretend all the interface members are really on the other interface too"? |
| 17:57 | <bga> | depends how you implement OOP |
| 17:58 | <AryehGregor> | How so? |
| 17:58 | <bga> | var Bar = { bar: }; var Foo = { __proto__: Bar, foo: } |
| 17:58 | <bga> | 1st case |
| 17:59 | <AryehGregor> | I'm asking what the WebIDL spec requires. |
| 18:01 | <smaug____> | AryehGregor: there is certainly difference. In the latter case "Bar" in window would be false |
| 18:02 | <smaug____> | (but I don't recall what WebIDL says about prototypes) |
| 18:02 | <Ms2ger> | AryehGregor, if you add [NoInterfaceObject], I think not |
| 18:02 | <AryehGregor> | Alternatively, is it the same as "interface Foo { void foo(); void bar(); }; interface Bar { void bar(); };"? |
| 18:03 | <smaug____> | hmm, what does WebIDL say about instanceof |
| 18:04 | <Ms2ger> | Read it :) |
| 18:04 | <AryehGregor> | I don't think it says anything. |
| 18:04 | <AryehGregor> | It just uses the ES5 definition, doesn't it? |
| 18:04 | <Ms2ger> | Anyway, you probably shouldn't use implements without [NoInterfaceObject] |
| 18:15 | <AryehGregor> | The IDLs for CSSOM and HTML have circular dependencies. :( |
| 18:15 | <AryehGregor> | (well, not exactly, but an IDL for CSSOM depends on one from HTML and vice versa) |
| 18:18 | <Philip`> | Solution: put all web technologies into a single spec |
| 18:18 | <GPHemsley> | Is there a reason that WHATWG specs exclude <head> and <body> in their source? |
| 18:19 | <GPHemsley> | oh, wait, they |
| 18:19 | <GPHemsley> | 're not WHATWG |
| 18:19 | <GPHemsley> | I'm looking specifically at this: http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html |
| 18:19 | <AryehGregor> | New WebIDL question: is there any difference between "interface Foo {}; partial interface Foo { void foo(); };" and "interface Foo {}; [NoInterfaceObject] interface Bar { void foo(); }; Foo implements Bar;"? Except that the former doesn't work if you want multiple interfaces to get the member? |
| 18:20 | <AryehGregor> | GPHemsley, the <head> and <body> tags are optional in text/html. No reason to include them unless you want attributes on them, usually (there are some other possible reasons). |
| 18:20 | GPHemsley | never likes the "it's optional, so I leave it out" <s>excuse</s> explanation |
| 18:21 | <GPHemsley> | also, why not take advantage of <header>? |
| 18:21 | <zewt> | typically the burden is to explain why to include something that's optional, not why to exclude it |
| 18:21 | <GPHemsley> | (etc.) |
| 18:22 | <GPHemsley> | zewt: Something like the difference between <head> and <body> seems pretty fundamental to me |
| 18:22 | <GPHemsley> | structurally/mentally-speaking |
| 18:22 | <webben> | GPHemsley: Wot? |
| 18:23 | <GPHemsley> | "just because you CAN do something doesn't mean you SHOULD" |
| 18:23 | <webben> | GPHemsley: Can you describe what the advantage of including redundant syntax would be in this case? |
| 18:23 | <TabAtkins> | I assume we're talking about nested-microdata-in-head? |
| 18:23 | <GPHemsley> | webben: legibility, at least |
| 18:24 | <GPHemsley> | TabAtkins: No, something much less complex. |
| 18:24 | <webben> | GPHemsley: Legibility to whom? |
| 18:24 | <GPHemsley> | me :) |
| 18:24 | <webben> | GPHemsley: Why do you need to be able to read the spec's source? |
| 18:25 | <GPHemsley> | Shouldn't one have the ability to read any page's source...? Otherwise, why aren't the elements just named <1> <2> <3> etc.? |
| 18:25 | <Ms2ger> | GPHemsley, that file is generated, there's no point in optimizing its legibility |
| 18:25 | <zewt> | seems more like "i'm used to doing this so I think it's weird not to simply due to habit" |
| 18:26 | <GPHemsley> | zewt: I'm sure that's part of it, but I think it's more than that. |
| 18:26 | <webben> | GPHemsley: 1) No, why? 2) Because good names makes it easier to know how to use them. |
| 18:27 | <webben> | GPHemsley: Particularly, with respect to 1) if WHATWG should be optimising for anything you could argue it should be performance. |
| 18:27 | <GPHemsley> | Well, thinking out loud, what is the burden on the parser to have determine where the <head> stuff ends? |
| 18:27 | <GPHemsley> | heh |
| 18:27 | <webben> | GPHemsley: There's no special burden on the parser. |
| 18:28 | <GPHemsley> | that's interesting |
| 18:28 | <webben> | GPHemsley: It knows it's left <head> as soon it see a start tag that cannot exist in <head>. |
| 18:29 | <Ms2ger> | The parser has to handle this anyway, so that's not a particularly compelling argument |
| 18:29 | <GPHemsley> | So then the <head> and <body> tags are vestigial and irrelevant now? |
| 18:29 | <TabAtkins> | Basically, yeah. |
| 18:30 | <GPHemsley> | interesting |
| 18:30 | <Ms2ger> | Well, now |
| 18:30 | <TabAtkins> | If by "now" you mean "since at least the last decade, and probably the decade before that". |
| 18:30 | <Ms2ger> | What TabAtkins said |
| 18:30 | <webben> | GPHemsley: I agree if you're trying to optimize for least surprise for fellow developers, then you might want to be explicit about implied elements. |
| 18:30 | <zewt> | since afaik no new tags can ever be added to <head> (because it would cause incompat between browsers that know the tag and those that don't), it sort of dead-ends <head> as a concept anyway |
| 18:30 | <webben> | GPHemsley: But that's not the only possible dimension around which to optimize (esp. production) source code. |
| 18:31 | <GPHemsley> | zewt: Yeah, I'd just read something to that effect. |
| 18:31 | <zewt> | leading to weirdness like people trying to wedge <intent> into <link> |
| 18:31 | <webben> | GPHemsley: (Also, in practice people generally don't remember all the implicit elements. Few people add implied TBODY for example. |
| 18:32 | <zewt> | also, having less boilerplate for simple documents is an overall win |
| 18:32 | <webben> | GPHemsley: Also, people generally don't complain when JS and CSS get minified. |
| 18:32 | <GPHemsley> | ack, ok |
| 18:32 | <GPHemsley> | sheesh |
| 18:32 | <zewt> | webben: i despise minifiers |
| 18:32 | <webben> | (This does have an effect on the web of course - less learning by C+P. But everything involves a tradeoff.) |
| 18:32 | <zewt> | they need to die in a ditch (on fire) |
| 18:32 | <webben> | zewt: "generally" ;) |
| 18:33 | <zewt> | (nothing's worse than trying to greasemonkey around a dumb site bug, to find that everything's a mess because somebody doesn't believe in deflate) |
| 18:33 | <TabAtkins> | Heh, I hate minifiers too. Squeezing a few extra bytes out (most of which will be removed by compression anyway) at the near-total cost of readability is a bad tradeoff to me. |
| 18:33 | <GPHemsley> | yeah... I think the discussion really comes down to who you're optimizing for: a human or a parser |
| 18:33 | <webben> | zewt: People are right not to believe in deflate - because of misconfigured proxies etc a lot of people won't get compressed content. |
| 18:33 | <zewt> | it's basically tossing the benefits of a textual format down the toilet |
| 18:34 | <webben> | Not really. GM has to interact with the DOM, and the DOM is implied. |
| 18:35 | <webben> | (I'm not in favour of minification that alters class names/ids or whatever.) |
| 18:35 | <webben> | i.e. I'm not in favour of minification that breaks the API. |
| 18:35 | <zewt> | i have to interact with the page source, in order to write a script in the first place |
| 18:35 | <webben> | zewt: GM interacts with the DOM not the raw markup, doesn't it? |
| 18:36 | <zewt> | yes, but a human (me) has to write the greasemonkey script in the first place, which requires understanding what the page is doing |
| 18:36 | <webben> | yes, but that requires looking at the DOM not the source. |
| 18:36 | <zewt> | eg. minification doubles as obfuscation (not always unintentionally) |
| 18:36 | <webben> | if you're talking about JS, that's a different story. |
| 18:37 | <zewt> | looking at the DOM doesn't help me read minifuscated javascript source |
| 18:37 | <TabAtkins> | I super-abhore packed JS, though luckily that's much less common these days. |
| 18:37 | <Ms2ger> | Is it? |
| 18:37 | <webben> | there's a case for preserving names in JS minification so when you re-beautify it's easier to read. |
| 18:38 | <webben> | I'm not sure whether the JS constitutes part of the public API of the page or not. |
| 18:38 | <zewt> | ... most pages don't have a "public API" |
| 18:38 | <TabAtkins> | Ms2ger: I used to see it a lot when viewing people's source. Now I very rarely see it. |
| 18:38 | <webben> | zewt: Depends what you mean. |
| 18:38 | <TabAtkins> | Ms2ger: Also, it doesn't seem to figure into people's tutorials these days. |
| 18:39 | <webben> | zewt: I think a lot (most? probably not) of pages do have a public API. |
| 18:39 | <zewt> | if a page has an obnoxious javascript tooltip fade-in, and I want to remove it or make it not fade, i can't say I've ever seen a single page where that would be considered "public API" |
| 18:40 | GPHemsley | silently backs away |
| 18:41 | <webben> | e.g. use of odd bits of semantic HTML, attempts to make pages search-engine/AT friendly |
| 18:41 | <webben> | semantic naming |
| 18:42 | <webben> | zewt: Yeah. I don't think people generally see JS effects as part of the API. |
| 18:42 | <webben> | rather than an implementation detail |
| 18:42 | <zewt> | most of the JS implementation of pages is just considered internals |
| 18:42 | <webben> | exactly |
| 18:42 | <zewt> | and that's usually the sort of thing I end up GM'ing |
| 18:43 | <zewt> | i need to write a script to make twitter stop swallowing browser-owned keystrokes. heh |
| 18:43 | <webben> | I think the solution there is better HTML and CSS features so more of this is declarative rather than imperative. |
| 18:43 | <webben> | declarative and overrideable |
| 18:43 | <zewt> | it's not really okay to preventDefault on alt-t |
| 18:43 | <webben> | And more fine-grained UA control over what sites can do |
| 18:44 | <zewt> | webben: not holding my breath |
| 18:44 | <webben> | Sure. |
| 18:44 | <webben> | Probably wise ;) |
| 18:44 | <zewt> | at least twitter isn't eating alt-d anymore, which iirc it used to |
| 18:45 | <webben> | We do sometimes discuss better features for binding keyboard shortcuts to commands so that UA features can remap user actions to commands. |
| 18:45 | <webben> | I think TV Raman filed some bugs along these lines |
| 18:46 | <webben> | although I have feeling Hixie is punting to HTML.Next |
| 18:46 | <zewt> | twitter's oddly been the only notable site I've ever seen that breaks basic browser hotkeys |
| 18:46 | <webben> | Twitter's web frontend leaves much to be desired. |
| 18:46 | <zewt> | it's a lot better than most high-profile sites |
| 18:46 | <webben> | e.g. hash-bang URL nonsense |
| 18:46 | <zewt> | nothing wrong with that (get over it :) |
| 18:46 | <zewt> | well, caveat |
| 18:46 | <webben> | (No! ;) ) |
| 18:47 | <zewt> | last I looked at that closely, it wasn't particularly optimized and regularly took many extra round-trips for a simple single-message page; that's dumb |
| 18:47 | <webben> | the history api allows you to set arbitrary URLs |
| 18:48 | <zewt> | sure, once it's widely-deployed, which it isn't quite yet |
| 18:48 | <webben> | Yeah, I think it's better to use it where available and use normal URLs where it's not. |
| 18:48 | <zewt> | (not in IE9) |
| 18:48 | <webben> | yeah it being left out of IE9 is regrettable |
| 18:51 | <zewt> | personally i find the ability to control history entries (replace vs. push) in history api to be much more interesting |
| 18:51 | <zewt> | allowing storing more fine-grained state in the URL without spamming history |
| 18:52 | <zewt> | (as well as things that can't be stored in the URL, like open files, though nobody implements that yet) |
| 18:52 | <zewt> | (afaik) |
| 19:20 | <zewt> | annevk: does encoding *to* legacy encodings need to be specified? i'm not even sure how that works for POST data |
| 19:20 | <annevk> | yes |
| 19:20 | <annevk> | for <form> |
| 19:20 | <annevk> | for URL |
| 19:20 | <zewt> | if I POST CJK through a shift-jis page the data is urlescaped Shift-JIS; if I POST CJK through iso-8859-1, the data is UTF-8 (wtf?) |
| 19:21 | <annevk> | POST CJK how? |
| 19:21 | <annevk> | using accept-charset? |
| 19:21 | <zewt> | enter CJK into a form in a page that was served as shift-jis |
| 19:21 | <zewt> | nothing special |
| 19:22 | <annevk> | that's some interesting behavior for windows-1252 |
| 19:22 | <annevk> | I don't think that's correct per HTML |
| 19:22 | <zewt> | er |
| 19:22 | <annevk> | however I don't plan to define how to deal with out of range characters |
| 19:23 | <zewt> | sorry, apache is fucking with me |
| 19:23 | <annevk> | I just plan to define how to go from in-range characters to octets |
| 19:23 | <annevk> | if you have out-of-range characters you will need to do some pre-processing |
| 19:23 | <zewt> | it's taking what I'm giving to AddType and ... changing it, apparently |
| 19:23 | <annevk> | I think <form> does turns them into ? or some such |
| 19:24 | <zewt> | yeah, i've never heard of a standard placeholder like U-FFFD in legacy encodings |
| 19:24 | <zewt> | afk |
| 19:56 | <gsnedders> | annevk: I thought HTML5 already defined it for form, at lesat |
| 19:56 | <annevk> | yeah |
| 19:58 | <annevk> | "For each character in the entry's name and value that cannot be expressed using the selected character encoding, replace the character by a string consisting of a U+0026 AMPERSAND character (&), a U+0023 NUMBER SIGN character (#), one or more characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) representing the Unicode code point of the character in base ten, and finally a U+003B SEMICOLON character (;)." |
| 19:58 | <annevk> | and after that it encodes |
| 19:58 | <annevk> | that's exactly the kind of pre-processing I meant :) |
| 20:31 | <annevk> | AryehGregor: will look in IE tomorrow unless someone beats me to it |
| 20:31 | <AryehGregor> | annevk, thanks. |
| 20:31 | AryehGregor | has an AWS VM somewhere he can use, but is too tired to remember how right now |
| 21:32 | <TabAtkins> | Dammit, I can't find my list of necessary commands for webkit hacking. ;_; |
| 21:33 | <TabAtkins> | That thing took a few hours of wiki-diving and messing around (and two people helping me out) to accumulate. |
| 22:10 | <zewt> | <div style="display: block;" hidden>foo</div> is rendered? :| |
| 22:10 | <Ms2ger> | Yeah |
| 22:10 | <zewt> | lame |
| 22:10 | <Ms2ger> | style attributes override the UA style sheet |
| 22:11 | <TabAtkins> | Everything overrides the UA style sheet. |
| 22:11 | <zewt> | hidden should override display; that's the entire point, as far as I've ever used it |
| 22:11 | <TabAtkins> | Solution: put "[hidden] { display: none !important; }" in your stylesheet. |
| 22:11 | <zewt> | (to show/hide elements without having to stash and restore the original display style) |
| 22:13 | <zewt> | yeah, but doing that manually sort of partially defeats the idea of having it as a standard feature to begin with |
| 22:13 | <TabAtkins> | Kinda, yeah. Unfortunately, CSS doesn't define a notion of UA-important. |
| 22:14 | <TabAtkins> | Which we *should* do, because everyone that uses an explicit UA stylesheet implements it, and in the same way. |
| 22:14 | <zewt> | and it'd be especially annoying if some bits of a page ended up depending on the behavior of hidden *without* that CSS |
| 23:22 | <bencc> | is it possible that a browser will send only part of a websocket package even if the fin bit is 1? |
| 23:22 | <bencc> | maybe if the user closed the browser window |