| 07:38 | <Ms2ger> | So, is http://wiki.whatwg.org/wiki/StringEncoding something we want? |
| 07:41 | <[tm]> | hsivonen_: did you ever get you ssh problem figured out? |
| 08:13 | <annevk> | In my @opera.com inbox this morning 'Welcome to the "xml-mime" mailing list' |
| 08:13 | <annevk> | I wonder how that happened |
| 08:24 | <annevk> | So what if you use "ws:/test" as URL in the WebSocket API? |
| 08:24 | <annevk> | Does that fail because there is no base URL per specification or are implementations doing the wrong thing? |
| 08:29 | <zcorpan> | annevk: browsers do the wrong thing |
| 08:29 | <zcorpan> | annevk: we have tests for that, iirc |
| 08:30 | <zcorpan> | annevk: we changed opera to do the wrong thing, to align with the other browsers :-) |
| 08:30 | <zcorpan> | both ws:test and ws:/test resolve to ws://test/ |
| 08:30 | <annevk> | huh? |
| 08:31 | <annevk> | http:/test resolves to http://example.org/test |
| 08:31 | <Ms2ger> | s/intersection/union/ |
| 08:31 | <annevk> | so what you are saying is not at all what I was hinting at and seems even weirder :( |
| 08:31 | <annevk> | Ms2ger: thanks |
| 08:32 | <zcorpan> | annevk: only if there's a base url and the scheme is the same as the base url |
| 08:32 | <zcorpan> | iirc |
| 08:33 | <zcorpan> | http:/test from the address bar becomes http://test/ (in opera anyway) |
| 08:33 | <annevk> | not in <a> |
| 08:34 | <annevk> | but if I use https:/test in <a> Opera treats it as a path! |
| 08:34 | <annevk> | whereas other browsers treat it as https://test/ |
| 08:34 | <annevk> | fuck URLs |
| 08:36 | <zcorpan> | annevk: hey what did you expect? :-) |
| 08:38 | <annevk> | my little pony |
| 08:38 | <odinho> | If they actually behaved correctly, I could make some tests easier. |
| 08:38 | <odinho> | Which goes for basically the whole platform I guess :P :D |
| 08:39 | <hsivonen> | [tm]: I didn't get the Windows SSH problem solved. However, I'm no longer that interested in solving that problem. Now I'm more interested in getting a terminal app that runs under Wine so that other Windows apps running under Wine see it as a Windows program, but the apps running in the terminal would actually run on the host Linux system as Linux executables. |
| 08:40 | <hsivonen> | [tm]: Alternatively, maybe I should get a Windows-based Wine-compatible IRC client instead of using irssi behind SSH. |
| 08:40 | <odinho> | Wow, you want to do strange things. When I have to use SSH in Windows I always use PuTTY. Don't know if that helps. |
| 08:41 | <odinho> | hsivonen: Why do you need all that strange stuff? |
| 08:41 | <jgraham> | Why would anyone not want to run irssi behind ssh? |
| 08:41 | <odinho> | hsivonen: I used mIRC in wine when I was 13. Maybe it still works. |
| 08:41 | <annevk> | odinho: you're older now? |
| 08:42 | <odinho> | annevk: Yeah man. |
| 08:42 | <odinho> | and def. wiser; i.e. don't use mIRC any more. |
| 08:43 | <hsivonen> | odinho: I want to do speech input into IRC. So far, I haven't gotten Platypus working on a 64-bit host system, because I only managed to install 32-bit Dragon under Wine. |
| 08:43 | <hsivonen> | odinho: maybe I should try mIRC under Wine |
| 08:43 | <annevk> | zcorpan: so did we only implement that "hack" for ws/wss URLs? |
| 08:43 | <hsivonen> | Platypus being http://thenerdshow.com/platypus.html |
| 08:43 | <annevk> | zcorpan: or is it not yet in Opera Next? |
| 08:44 | <annevk> | <!DOCTYPE html><A href="https:/test">test</a> |
| 08:44 | <annevk> | <script> w(document.getElementsByTagName("a")[0].href)</script> |
| 08:44 | <annevk> | still yields log: http://software.hixie.ch/utilities/js/live-dom-viewer/https:/test for me |
| 08:45 | <hsivonen> | Free business idea for someone: License the Dragon engine from Nuance and make a Linux-native product around it like the MacSpeech folks did for Mac. |
| 08:47 | <jgraham> | Free business idea for someone that doesn't like making money? |
| 08:47 | <hsivonen> | I'd appreciate advice for how to run 32-bit ELF .exes under WINEARCH=win32 on a 64-bit host |
| 08:47 | <hsivonen> | jgraham: well, Nuance bought MacSpeech |
| 08:48 | <jgraham> | Yeah, but the market for for-money OSX apps is much bigger |
| 08:48 | <hsivonen> | true |
| 08:52 | <[tm]> | hsivonen: would you prefer we update the validator UI to say MathML3 or just MathML (no version)? |
| 08:54 | jgraham | wonders what, if anything, in the spec deals with form submissions to javascript urls |
| 09:04 | <hsivonen> | [tm]: MathML I guess, since MathML3 is not a buzzword |
| 09:04 | <hsivonen> | [tm]: oops. |
| 09:04 | <hsivonen> | [tm]: that would be inconsistent with SVG 1.1 and HTML5 |
| 09:05 | <hsivonen> | [tm]: I don't have a true preference |
| 09:05 | <hsivonen> | [tm]: which one makes more sense to you? |
| 09:05 | <hsivonen> | eventually, I think all of them should go versionless |
| 09:06 | <[tm]> | hsivonen: yeah |
| 09:06 | <[tm]> | i don't have a sitting preference for washy msthml should be at ths point |
| 09:07 | <hsivonen> | [tm]: could make it 3 for now and drop versions from all of them once SVG is ready for that |
| 09:08 | <hsivonen> | i.e. when 1.2 has clearly been superceded with something that makes more sense than 1.1 as a validation target |
| 09:08 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1570 |
| 09:09 | <hsivonen> | looks like http://maps3d.svc.nokia.com/webgl/ will be yet another "Nokia first" thing that they failed to take from research to product before Apple did |
| 09:09 | <annevk> | hsivonen: why not just drop it and have an explanation in the FAQ? |
| 09:09 | <hsivonen> | annevk: that could work, too |
| 09:11 | <hsivonen> | Partnering with an anti-OpenGL vendor probably didn't help Nokia productize the 3D maps. |
| 09:19 | <annevk> | so the ws:/Test or ws:test trick is not that hard I guess |
| 09:20 | <annevk> | when there's no base URL you basically treat everything following the scheme as authority |
| 09:20 | <annevk> | ignoring a single slash |
| 09:20 | <annevk> | seems hacky as hell thoug |
| 09:20 | <annevk> | h |
| 09:21 | <zcorpan> | sounds appropriate for the web |
| 09:21 | <zcorpan> | (also check more than two slashes there) |
| 09:22 | <annevk> | stuff gets weird in Safari then |
| 09:23 | <annevk> | Chrome / Gecko just keep eating those slashes |
| 09:23 | <annevk> | with Chrome you can throw some backslashes in there too |
| 09:28 | <jgraham> | So WebKit retargets the javascript: submit to the top level browsing context |
| 09:28 | <jgraham> | Gecko seems to try to run it in some browsing context with no window object? |
| 09:29 | <jgraham> | and I think Opera just aborts the navigation |
| 09:30 | <zcorpan> | but still runs the javascript: script? |
| 09:30 | <jgraham> | Not afaict |
| 09:30 | <hsivonen> | annevk, matjas: Even though X-UA-Compatible is widely used, surely requesting a particular layout engine (either legacy Trident or WebKit through Chrome Frame) is still harmful for the same reasons why the functionality of X-UA-Compatible went put in the HTML spec in the first place. As for using IE=Edge, it seems that IE10 in the Metro mode makes that obsolete as a means of disabling the Compatibility View button, since there's no such button in the Met |
| 09:30 | <jgraham> | I assume that's what aborting a javascipt URL navigation is (not running the script) |
| 09:31 | <zcorpan> | ah. right. i thought we might have run the script but then not navigating to the return value of the javascript url |
| 09:31 | <zcorpan> | but we don't run it at all |
| 09:32 | <annevk> | hsivonen: I agree it's harmful, developers seem to think otherwise |
| 09:32 | <hsivonen> | (I could be convinced that X-UA-Compatible with IE=Edge only should be valid.) |
| 09:32 | <zcorpan> | maybe foolip killed that as part of his javascript: onslaught |
| 09:32 | <annevk> | hsivonen: activating the IE Chrome-plugin I suppose is another use of it |
| 09:33 | <jgraham> | Perhaps. You have to do something to stop e.g. document.cookie from the original site being exposed |
| 09:33 | <zcorpan> | that and OtherUA=4 |
| 09:33 | <hsivonen> | annevk: why should targeting WebKit like that be OK if targeting a particular Trident isn't? |
| 09:34 | <hsivonen> | (well, at least chrome=1 is the Edge of Chrome) |
| 09:34 | <zcorpan> | hsivonen: people want canvas and stuff in ie8, maybe? |
| 09:34 | <annevk> | hsivonen: right, it's not a particular version |
| 09:35 | <jgraham> | (so I guess we did *something* before foolip started that) |
| 09:35 | <annevk> | Anyone know why HTML does not define navigator.language? |
| 09:36 | <hsivonen> | I tend to agree with the sentiment of http://shaver.off.net/diary/2009/09/28/thoughts-on-chrome-frame/ |
| 09:36 | <foolip> | zcorpan, jgraham, what was the question, exactly? |
| 09:37 | <annevk> | hsivonen: fair enough |
| 09:37 | <annevk> | hsivonen: then I would advise people away from X-UA-Compatible altogether because only allowing IE=Edge is just cargo-cult |
| 09:37 | <annevk> | hsivonen: and might make people believe other values are acceptable too |
| 09:38 | <zcorpan> | foolip: <form action="javascript:(function() { alert(1); return "LOL" })()"><button>OK |
| 09:38 | <zcorpan> | foolip: doesn't do anything in current opera |
| 09:38 | <zcorpan> | foolip: i recall you killed javascript: URLs in various places in opera at some point |
| 09:38 | <MikeSmith> | hsivonen: yeah, I guess making it MathML3 for now and planning to drop the all versions once we get there is best (and I think David Carlisle would probably also like to keep the 3 on MathML in there for now) |
| 09:39 | <zcorpan> | foolip: i don't recall whether it worked in <form action> before, but i have a hunch that it did |
| 09:39 | <foolip> | zcorpan, what I changed was javascript: as inline resources: <video poster>, <bgsound src>, <script src>, <link href> and from CSS |
| 09:39 | <foolip> | <form action> ought to not be handled as an inline resource, but I can't swear it |
| 09:40 | <zcorpan> | ok |
| 09:42 | <hsivonen> | MikeSmith: ok |
| 09:42 | <MikeSmith> | hsivonen: I can go ahead and make the change now and check it in |
| 09:43 | <hsivonen> | annevk: in general, I think validators shouldn't accept browser-specific syntax even if the syntax is popular among authors |
| 09:43 | <hsivonen> | MikeSmith: ok |
| 09:43 | <MikeSmith> | thanks |
| 09:43 | <hsivonen> | annevk: except when it's standard syntax that only one browser has implemented so far and others intend to implement |
| 09:44 | <annevk> | I guess the main thing here is that no other user agent wants anything to do with X-UA-Compatible |
| 09:44 | <hsivonen> | is Chrome Frame accessible yet? |
| 09:55 | <Stevef> | hsivonen: haven't checked chrome frame accessibility for a while, will check |
| 09:56 | <MikeSmith> | annevk: I guess the problem with the broken backreferences in the URL spec is maybe that I'm marking them up wrong in the source |
| 09:56 | <MikeSmith> | I will take a look and compare to other anolis-generated specs to see |
| 09:59 | <annevk> | MikeSmith: if you use <dfn> and <span> you should be fine |
| 09:59 | <MikeSmith> | ok |
| 09:59 | <annevk> | MikeSmith: it seems the URL parsing is a little more correct than I thought by the way; it does include a check for valid scheme characters |
| 09:59 | <MikeSmith> | oh good |
| 10:00 | <annevk> | the details are just not defined and it should probably be done somewhat differently, but overall it seems okay |
| 10:01 | <MikeSmith> | great |
| 10:01 | MikeSmith | looks back at recent checkings |
| 10:01 | <MikeSmith> | annevk: arv was working on that section a while back |
| 10:02 | <MikeSmith> | should try to rope him in again if he has time to help some more |
| 10:02 | <annevk> | I thought arv was just working on the API? |
| 10:02 | <annevk> | hmm |
| 10:03 | <MikeSmith> | ah yeah |
| 10:03 | <MikeSmith> | you're right, yeah |
| 10:03 | <annevk> | I'm still trying to get a somewhat better understanding of the whole thing; then I'll probably write some tokenizer code |
| 10:05 | <MikeSmith> | annevk: I left editorial comments in there in places where I found problems or ambiguities in what was there |
| 10:05 | <MikeSmith> | but most of those are pretty high-level |
| 10:18 | <zcorpan> | jgraham: heh, i typoed the javascript url (used double quotes in a double-quoted attribute value). we do run hte script and navigate it, at least in 11.64 |
| 10:18 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1571 |
| 10:19 | <zcorpan> | also in a recent build |
| 10:21 | <zcorpan> | ok http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1572 doesn't run the script |
| 10:23 | <zcorpan> | chrome seems to run the script in the context of the form's owner document, but doesn't navigate |
| 10:30 | <annevk> | MikeSmith: yeah that's good |
| 10:30 | <annevk> | MikeSmith: now we need to fix them :) |
| 10:30 | <MikeSmith> | yah |
| 10:31 | <MikeSmith> | I will have more time next week to help out myself |
| 10:31 | <zcorpan> | and firefox runs the script in a restricted environment and then navigates (if the script didn't throw) |
| 10:31 | <MikeSmith> | annevk: I'm in meetings all day tomorrow and friday here |
| 10:31 | <annevk> | zcorpan: will you be in Linkoping next week? |
| 10:31 | <jgraham> | Yes, I think the Opera behaviour (do nothing) makes lots of sense |
| 10:31 | <annevk> | MikeSmith: no worries, this is going to take a while I guess |
| 10:32 | <MikeSmith> | yeah |
| 10:32 | <annevk> | but hopefully, after that we can answer most URL questions and only occasionally patch URL parsing |
| 10:32 | <jgraham> | annevk: Swedish people get confused if you s/ö/o/ |
| 10:32 | <annevk> | instead of it being still undefined in 2012 |
| 10:32 | <annevk> | jgraham: lol |
| 10:35 | <annevk> | MikeSmith: what's the URL spec component in the HTML WG? |
| 10:36 | <zcorpan> | annevk: no |
| 10:36 | <MikeSmith> | annevk: https://www.w3.org/Bugs/Public/buglist.cgi?product=HTML%20WG&component=URL%20spec&resolution=--- |
| 10:36 | <MikeSmith> | annevk: but why you want that one? |
| 10:36 | <zcorpan> | jgraham: no we're used to it :-) |
| 10:37 | <MikeSmith> | annevk: I think I moved all the bugs over |
| 10:37 | <MikeSmith> | https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=URL&resolution=--- |
| 10:38 | <MikeSmith> | annevk: I see there's only one bug left in the old component |
| 10:38 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=14569 |
| 10:38 | <MikeSmith> | from arv |
| 10:38 | <MikeSmith> | but it's resolved |
| 10:39 | <MikeSmith> | I'll move that one over too |
| 10:39 | <MikeSmith> | for the sake of completeness |
| 10:41 | <annevk> | don't want it, but maybe nuke it? |
| 10:41 | <annevk> | zcorpan: too bad |
| 10:41 | <annevk> | I'll be in Linkoping next week starting Tuesday afternoon |
| 10:42 | <MikeSmith> | annevk: already just now moved it but anyway it's not going to show up normally (because it's still marked as resolved) |
| 10:42 | <jgraham> | On the other hand, that means you get a desk |
| 10:42 | <jgraham> | Office is pretty full at the moment |
| 10:42 | <annevk> | :) |
| 10:42 | <jgraham> | (well a desk not with gfx) |
| 10:43 | <annevk> | a docxs desk |
| 10:45 | <zcorpan> | annevk: are you staying for friday beer? |
| 10:45 | <Stevef> | hsivonen: chrome frame inherits chrome accessibility support, so much better, but still issues |
| 10:45 | <annevk> | zcorpan: yeah, leaving the country Sunday afternoon |
| 10:46 | <annevk> | zcorpan: no plans, just a plane ticket :) |
| 10:46 | <zcorpan> | annevk: ok. i'll check if i can come on friday |
| 10:54 | <hsivonen> | Stevef: thanks |
| 10:55 | <Stevef> | hsivonen: no problem, thanks for bring it up, I need to update article on chrome frame as I don't want outdated info being assumed as current |
| 11:52 | <zcorpan> | a 404 response with XHR still fires the 'load' event? |
| 11:54 | <annevk> | of course |
| 11:54 | <annevk> | same for <img> |
| 11:55 | <zcorpan> | i know <img> is weird; i didn't expec xhr.onload to be weird (since it didn't exist back in the day) |
| 11:55 | <annevk> | it's not weird |
| 11:56 | <annevk> | load/error/etc. reflect network state, not HTTP state |
| 11:56 | <zcorpan> | not everywhere :-) |
| 11:57 | zcorpan | wonders how <track> 404s should behave |
| 11:57 | <zcorpan> | knee-jerk is "fire error" |
| 11:58 | <annevk> | nooo |
| 12:07 | <zcorpan> | annevk: why not? |
| 12:27 | Ms2ger | wonders if "Left-overs from Hamburg ftf" is going to fall off the agenda before the next ftf |
| 12:42 | <annevk> | zcorpan: what other API does that? |
| 12:51 | <zcorpan> | annevk: <object> |
| 12:52 | <zcorpan> | annevk: i think <video> |
| 12:52 | <zcorpan> | annevk: and <video poster> |
| 12:52 | <zcorpan> | at least per spec and i think in opera |
| 12:53 | <zcorpan> | <style> and <script>? |
| 12:53 | <zcorpan> | i mean <link rel=stylesheet> |
| 12:54 | <zcorpan> | though i may be wrong about those |
| 12:55 | <annevk> | hmm |
| 12:55 | <annevk> | do browsers actually implement that for object? |
| 12:55 | <annevk> | looks very suspicious |
| 12:58 | <zewt> | cool, apparently just creating a 10000x10 webgl canvas crashes firefox immediately |
| 13:00 | <Ms2ger> | Hmm, I thought we had code to limit that |
| 13:01 | <SimonSapin> | zewt: I’ve once had my screen blink and the mouse cursor slow down to 3 fps for a few second before having to OS freeze, just by trying google’s mapgl in firefox |
| 13:01 | <zcorpan> | annevk: last time i checked, yeah |
| 13:01 | <zcorpan> | annevk: recall that <object> supports text/html so it wouldn't fall back if it applied 404 text/html |
| 13:02 | <zcorpan> | annevk: whereas a 404 text/html in <img> still errors since it's not a valid image |
| 13:07 | <zewt> | on an oldish firefox, i'll update later today and retest |
| 13:12 | <annevk> | MikeSmith: I think we should merge parsing and canonicalizing as well |
| 13:13 | <annevk> | MikeSmith: http://lists.w3.org/Archives/Public/public-iri/2011Jun/thread.html#msg24 (and reading of some browser code) suggests that's how it works |
| 13:13 | <annevk> | MikeSmith: unfortunately with some scheme-specific handling |
| 13:17 | <[tm]> | Hmm |
| 13:18 | <[tm]> | annevk: ok but abarth_ write it put that way when he first drafted it so i guess i had assumed out was informed by implementation |
| 13:19 | <[tm]> | but maybe not so much as i had thought |
| 13:19 | <zewt> | it sure is constant stress reading email these days, with 2-3 second delays on every single action in gmail |
| 13:21 | <annevk> | [tm]: need to ask abarth why he split it, indeed |
| 13:27 | <jgraham> | zewt: Maybe Google do it deliberately so that people who aren't Google employees are so stressed the whole time they can't get anything useful done and so don't come up with Google competitors |
| 13:29 | <zewt> | "SSE" is an unfortunate abbreviation for server-sent events |
| 13:30 | <zewt> | now all we need is an API that works out to "MMX" |
| 13:37 | <annevk> | MikeSmith: the other thing I think we should do is turn rename "parsed URL" to "URL" and have the other be "URL string" or some such |
| 13:38 | <annevk> | MikeSmith: then the parser sets the components of URL one by one, and the API just follows from there |
| 13:40 | <[tm]> | annevk: yeah, agreed |
| 13:41 | <[tm]> | annevk: maybe "candidate URL string" |
| 13:43 | <[tm]> | o "URL candidate" |
| 13:43 | <smaug____> | MM is obviously MultiModal, but the X... |
| 13:44 | <Ms2ger> | XML |
| 13:45 | <zcorpan> | XML stuff usually have the X first though |
| 13:45 | <annevk> | XQueryX doesn't |
| 13:46 | <zcorpan> | that's a thing? |
| 13:46 | <annevk> | (in a way) |
| 13:49 | zcorpan | stops reading that |
| 13:50 | <zcorpan> | having just seen inception, i'm disappointed they didn't go a level deeper with the xml thing |
| 13:58 | <zewt> | wouldn't that be xslt |
| 14:02 | <[tm]> | that would be using xslt to generate xslt |
| 14:02 | <annevk> | known to happen |
| 14:08 | <[tm]> | annevk: clear sign of mental illness when it happens |
| 14:09 | <[tm]> | shutter island |
| 14:56 | <annevk> | weird |
| 14:57 | <annevk> | in Gecko about:blank has no path of "blank" |
| 15:16 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1574 |
| 15:17 | zcorpan | notices chrome has location.origin and location.ancestorOrigins |
| 15:30 | <Ms2ger> | kennyluck, I disagree, I found that sentence within half a minute ;) |
| 15:48 | <kennyluck> | Ms2ger, huh OK. I can't recall how much time I spent on finding that sentence when I had the same question. 5 mins maybe. |
| 15:49 | <Ms2ger> | Probably just luck on my part :) |
| 15:51 | <kennyluck> | it is certainly better than most CSS 2.1 prose. Every time I read something about the box model in CSS 2.1, I feel like I learn something and then unlearn something. |
| 16:22 | <SimonSapin> | kennyluck: I’m a bit lost as well, in the css3-syntax/tinycss thread |
| 16:25 | <[tm]> | SimonSapin is an interesting nick |
| 16:25 | <SimonSapin> | [tm]: it’s just first name plus last name |
| 16:26 | <SimonSapin> | how is it interesting? |
| 16:26 | <SimonSapin> | (just curious) |
| 16:27 | <[tm]> | just never seen that co |
| 16:28 | <SimonSapin> | co? |
| 16:28 | <[tm]> | just never seen that combination i guess |
| 16:28 | <[tm]> | but i don't get around much |
| 16:29 | <SimonSapin> | I see several in this channel |
| 16:30 | <Ms2ger> | I see MikeSmith |
| 16:30 | <[tm]> | those are all simple sumon |
| 16:30 | <[tm]> | those are |
| 16:30 | <[tm]> | simple simon |
| 16:31 | Ms2ger | wonders how much [tm] had to drink |
| 16:33 | <[tm]> | lack of sleep is the more effecting thing |
| 16:33 | <jgraham> | affecting |
| 16:33 | <jgraham> | Although I guess you could argue for either in this case |
| 16:34 | jgraham | wonders about navigations triggered in unload steps |
| 16:34 | <[tm]> | i hate insu |
| 16:35 | <jgraham> | Simple WebKit model or complex Gecko model that might cover one more usecase |
| 16:35 | <[tm]> | i hate English |
| 16:35 | <zcorpan> | [tm]: you high again? |
| 16:35 | <[tm]> | so |
| 16:35 | <zcorpan> | man |
| 16:35 | <zcorpan> | it's wednesday |
| 16:35 | <[tm]> | pretty much always me |
| 16:36 | <jgraham> | In Tokyo it's Thursday |
| 16:37 | <[tm]> | every day is Mikey day in Tokyo |
| 16:37 | <kennyluck> | SimonSapin, it will be of course helpful if you identify places where you get lost. |
| 16:37 | <kennyluck> | I |
| 16:37 | <kennyluck> | h |
| 16:37 | <kennyluck> | op |
| 16:37 | <kennyluck> | |
| 16:38 | <kennyluck> | |
| 16:38 | <kennyluck> | |
| 16:38 | <kennyluck> | oops |
| 16:38 | <kennyluck> | shit |
| 16:38 | <jgraham> | You hop? |
| 16:38 | <jgraham> | Plus a diagram of hopscotch? |
| 16:38 | <[tm]> | you sloths in sweden should get off your lazy assess |
| 16:38 | <kennyluck> | SimonSapin, I was hoping my last message is as clear as I could be. |
| 16:38 | <[tm]> | and visit me in Tokyo |
| 17:33 | <[tm]> | yes |
| 17:34 | <[tm]> | you welcome any time off then thedes |
| 17:35 | <[tm]> | these guys make a movie to catch up |
| 17:35 | <kennyluck> | SimonSapin, did you reply that particular part of my message because it's the least confusing? |
| 17:35 | <Velmont> | Lachy: mind confirming here when it is? I'll leave office now. |
| 17:35 | <Velmont> | sry, supposed to be /msg |
| 17:36 | <[tm]> | lov |
| 17:36 | <[tm]> | secret love message |
| 17:37 | <kennyluck> | SimonSapin, I think it would still be helpful for you to give a correct statement as to what's sort of the impact of '$foo: bar' as compared to 'foo: bar'. |
| 17:37 | <Velmont> | [tm]: Jealous? :P |
| 17:41 | <TabAtkins_> | kennyluck: SimonSapin: Agree. If you're doing error-handling correctly, the impact of "$foo:bar;" should just be to ignore up to the semicolon. If you're not doing error-handling correctly, that's your fault. |
| 17:46 | <SimonSapin> | kennyluck: TabAtkins_: 'var-foo: bar' requires no change in tinycss. Given a bit more thought, '$foo: bar' could be implemented in a parser mixin/subclass that overrides the parse_declaration method. This would be opt-in so that older UAs that do not expect it do not break |
| 17:47 | <TabAtkins_> | SimonSapin: Are you talking about old versions of tinycss breaking, or old consumers attached to new tinycss breaking? |
| 17:47 | <SimonSapin> | the later |
| 17:48 | <SimonSapin> | older versions of tinycss should already have a correct error handling and drop the declarations |
| 17:48 | <TabAtkins_> | Ah, ok. I care much less about that situation, since as you say, you can just have something internal that decides whether or not to expose them. |
| 17:48 | <SimonSapin> | yes, I also think that it should not matter for the spec |
| 17:49 | <kennyluck> | SimonSapin, though there's still a (hypothetical) case of tinycss UA that needs to serilze declarations and in that case there's no way to get '$foo: bar' because it's dropped right? |
| 17:49 | <SimonSapin> | and if older tinycss broke, that would be my fault for not implementing error handling correctly |
| 17:50 | <SimonSapin> | kennyluck: serialization is not currently supported. future versions may have a (possibly opt-in) way to preserve stuff that is otherwise ignored, to enable serialization |
| 17:51 | <kennyluck> | SimonSapin, how is it not supported? I don't think there's any problem to get the tokens out of a Declaration object. |
| 17:51 | <SimonSapin> | but let’s not worry about it until someone asks for it. Have a note in tho docs at most |
| 17:52 | <kennyluck> | SimonSapin, Declaration.value, to be exact. |
| 17:52 | <SimonSapin> | kennyluck: unlike property values, Declaration objects do not have a as_css() or serialize() method. You would have to re-escape the property name yourself in case it contains special characters |
| 17:53 | <SimonSapin> | yes, no problem for property values and selectors |
| 17:53 | <kennyluck> | SimonSapin, where are as_css() and serialize() defined? I only looked at css21.py. |
| 17:54 | <SimonSapin> | there is no .serialize(). The token-related classes in token_data.py have .as_css() |
| 17:55 | <SimonSapin> | including TokenList, the type for declaration.value and ruleset.selector |
| 17:55 | <SimonSapin> | kennyluck: http://packages.python.org/tinycss/parsing.html |
| 17:56 | <kennyluck> | SimonSapin, I couldn't find the object for property values. What class is that? |
| 17:56 | <kennyluck> | TokenList? |
| 17:56 | <SimonSapin> | yes |
| 17:56 | <SimonSapin> | http://packages.python.org/tinycss/parsing.html#tinycss.css21.Declaration |
| 18:02 | <kennyluck> | TabAtkins_, SimonSapin, I only worry that for whoever wants to build a sort of an intermediate layer, a bit like tincyss, if he/she uses the current css3-syntax, he/she will end up implementing a layer that can't support '$foo: bar', because css3-syntax correctly doesn't ask UA to "Append the current input token to the value of the current declaration." |
| 18:02 | <kennyluck> | TabAtkins_, SimonSapin, I am saying this because, well, I didn't expect the CSS 2.1 core grammar to have any use before I read a bit of tinycss's source code. |
| 18:03 | <kennyluck> | s/correctly/currently/ |
| 18:03 | <SimonSapin> | kennyluck: how would you have implemented a parser without it? Based on appendix G ? |
| 18:04 | <TabAtkins_> | kennyluck: And that's perfectly fine. There's nothing wrong with amending the grammar/parser when we add new things. |
| 18:04 | <kennyluck> | SimonSapin, you can always keep the tokens. Equivalently it would treat everything in between two semicolons in a ruleset as a declaration. |
| 18:05 | <kennyluck> | TabAtkins_, that's perfectly fine unless someone later will cite tools as reasons why we shouldn't change the grammar and such. |
| 18:05 | <SimonSapin> | TabAtkins_, kennyluck: yes, changing tinycss is fine. I remembered in the middle of the thread that I already have an overkill mechanism (based on multiple inheritance) for parser features that can be enabled/disabled |
| 18:06 | <SimonSapin> | (dynamic multiple inheritance, even. It’s only missing meta-classes :p) |
| 18:07 | <TabAtkins_> | kennyluck: Again, if they're doing error-handing correctly, that's not an argument. |
| 18:08 | <kennyluck> | TabAtkins_, the argument is that If I am building a tinyCSS UA, it's never going to give me '$foo: bar' as a Declaration so I either have to create my own and that's troublesome. |
| 18:08 | <SimonSapin> | kennyluck: a Declaration object is a name, value and optionally !important. I can’t fit '$foo: bar' is this class as-is. I could however have Rule.declarations be a mixed list of Declaration and ... something else with an unparsed TokenList |
| 18:09 | <SimonSapin> | for minifiers |
| 18:10 | <kennyluck> | SimonSapin, that will indeed be better so I don't need to rebuild my own paper in this hypothetical scenario. |
| 18:10 | <TabAtkins_> | kennyluck: Okay? Yes, if the grammar changes, your parser needs to change as well or it won't recognize the new things. That's fine, because your UA won't *break* in the presence of changes, it just wont' see the new stuff. |
| 18:10 | <TabAtkins_> | That's how everything works ever. |
| 18:10 | <kennyluck> | TabAtkins_, that will break if my tinycss UA is a minimizer. |
| 18:11 | <TabAtkins_> | Explain? |
| 18:11 | <SimonSapin> | kennyluck: give me a few minutes, I’ll write a feature proposal for tinycss |
| 18:11 | <kennyluck> | Since tinycss stole my stoken! How am I going to get those if tinycss doesn't provide those. |
| 18:12 | <SimonSapin> | kennyluck: it will! If someone implements the feature |
| 18:12 | <TabAtkins_> | Yes, that's still fine. *You're using an out-of-date parser, so you don't get to see the new hotness features*. But the rest of your stuff doesn't break. |
| 18:12 | <kennyluck> | This scenario is of course very theoretical, but I hope it explains this a bit. |
| 18:13 | <SimonSapin> | I would probably implement it myself if someone asks for it |
| 18:13 | <kennyluck> | TabAtkins_, I am building a minimizer, that does't seem to be acceptable at all. |
| 18:13 | <SimonSapin> | but apparently this is only theoretical |
| 18:13 | <kennyluck> | yes |
| 18:14 | <TabAtkins_> | kennyluck: I don't know what to argue, then. You're saying that we shouldn't ever make any changes to the parser *ever* because of minimizers, even backwards-compatible changes. |
| 18:14 | <TabAtkins_> | I can't accept that position. |
| 18:15 | <kennyluck> | TabAtkins_, I am arguing that we should make it clear to a creator of something like tinycss that there's nothing unchangeable in css3-syntax. |
| 18:16 | <SimonSapin> | kennyluck: gotta go now. I’ll send you the feature spec for preserving everything in tinycss once I write it. |
| 18:17 | <TabAtkins_> | Making it clear won't help. If you put a CSS parser between the raw text and the browser, then you're necessarily limited to the intersection of things they support. |
| 18:17 | <kennyluck> | TabAtkins_, 's why I've been saying that the CSS 2.1 grammar, deceptively promised to be a never-changing one, should be clearly marked as obsoleted. |
| 18:18 | <TabAtkins_> | Yes, the prelude in Syntax will state that it replaces the parsing section of 2.1. |
| 18:18 | <kennyluck> | TabAtkins_, well. The point is to make sure that the intermediate thing supports whatever it can support and don't cite a CSS spec and say "the spec promised this". |
| 18:19 | <TabAtkins_> | 2.1 never promised no changes either. ^_^ |
| 18:19 | <Ms2ger> | Bert did! |
| 18:19 | <TabAtkins_> | The editors did, and it was a silly promise that we can't hold to. |
| 18:19 | <kennyluck> | TabAtkins_, it does. |
| 18:19 | <kennyluck> | "All levels of CSS — level 1, level 2, and any future levels — use the same core syntax. " |
| 18:21 | <TabAtkins_> | I see how that sentence could be read as such. But the intent of the sentence is just that we won't make backwards-incompatible changes that make new stylesheets unusable in old browsers. |
| 18:22 | <Ms2ger> | I doubt that was what was meant |
| 18:24 | <kennyluck> | Whatever the intent is, it is a truth that people constantly cite this as a reason against a grammar change, which I find quite annoying, even if I don't prefer the '$foo: bar' syntax. |
| 18:41 | <kennyluck> | TabAtkins_, by the way, if you want to say a UA not implementing error handling is faulty, you should eliminate the latte part of "user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below" immediately. |
| 18:41 | <TabAtkins_> | No, that is necessary, in some form, to allow conformance checkers to just bail with a "your CSS isn't conforming" message at the first error. |
| 18:42 | <TabAtkins_> | But it's trivially obvious that it's not web-compatible to bail on the first error if you're actually using the CSS to display somethin. |
| 18:42 | <kennyluck> | TabAtkins_, is there a real need somewhere? |
| 18:42 | <kennyluck> | Or can we limit it to conformance checkers instead of all potential UA? |
| 18:43 | <TabAtkins_> | It's also acceptable for CSS transformers, like server-side minifiers, to bail when they see something they don't understand. |
| 18:43 | <TabAtkins_> | What's not allowed is that they recover from the error in a way we dont' specify, because then we can't predict their behavior. |
| 18:44 | <kennyluck> | TabAtkins_, if you are saying this you are sort of contradicting what you said in "If you're not doing error-handling correctly, that's your fault." |
| 18:44 | <TabAtkins_> | Nope, not at all. |
| 18:45 | <TabAtkins_> | "Not doing error-handling correctly" is the "recovering in a way that we dont' specify" thing. That's not cool. |
| 18:45 | <zcorpan> | TabAtkins_: that's not really required, you can just say that conformance checkers have to report at least one error if there are any and none if there aren't any |
| 18:46 | <TabAtkins_> | zcorpan: I just copy-pasted from HTML, so shrug. |
| 18:47 | <kennyluck> | TabAtkins_, CSS 2.1 doesn't allow this for what it's worth. |
| 18:48 | <zcorpan> | TabAtkins_: i think html still has that because a streaming parser would want to abort in the face of errors that aren't streamable |
| 18:48 | <TabAtkins_> | I doubt this actually stopped anybody. |
| 18:48 | <TabAtkins_> | zcorpan: Ah, if that's the only reason then I can kill it, since CSS is streaming-friendly. |
| 18:49 | <kennyluck> | zcorpan, what kind of error is that? |
| 18:49 | <zcorpan> | kennyluck: <head></head><link><html class="foo"><html class="bar"> |
| 18:50 | <zcorpan> | has three :-) |
| 18:50 | <zcorpan> | but there are more cases like that |
| 18:50 | <kennyluck> | zcorpan, ah, I see. |
| 18:50 | <zcorpan> | x</body> y |
| 18:50 | <kennyluck> | thanks |
| 18:54 | <zcorpan> | TabAtkins_: html also has the clause for conformance checkers along the lines i wrote above |
| 18:54 | <TabAtkins_> | Yeah, I copied that as well. |
| 18:55 | <zcorpan> | ok |
| 18:55 | <TabAtkins_> | I just took the prelude sections from HTML's parser and made a few edits and deletions to make it vaguely suitable for CSS. I'll go through and edit it properly later. |
| 20:11 | <Ms2ger> | MikeSmith / [tm]: is there a bugzilla component for idlharness.js? |
| 21:45 | <SimonSapin> | kennyluck: what do you think of this? https://github.com/SimonSapin/tinycss/issues/2 |