| 00:23 | <heycam> | gsnedders, I could well have missed it |
| 00:24 | <gsnedders> | heycam: Want me to send it again? |
| 00:24 | <heycam> | gsnedders, yep sure |
| 00:24 | heycam | checks the spec now too |
| 00:25 | <heycam> | so that is something that changed recently, the attribute getter one at least |
| 00:25 | <heycam> | due to the crazy on* behaviour |
| 00:26 | <gsnedders> | Oh, I sent the email after the operator getter changed behaviour |
| 00:27 | <heycam> | by operator getter do you mean operation? |
| 00:27 | <gsnedders> | So totally not following any emails to spec mailing lists |
| 00:28 | <gsnedders> | And yes, I do mean operation |
| 00:28 | <gsnedders> | I'm watching TV shows and not paying attention to what I'm typing. |
| 00:28 | <heycam> | yeah I haven't replied on public-script-coord for a couple of weeks :p |
| 00:30 | <gsnedders> | The only thing I read at all nowadays is various testsuite mailing lists. |
| 03:04 | <zewt> | ugh |
| 03:04 | <zewt> | ff8 is doing that horrible "hide the http://" garbage too now |
| 03:04 | <zewt> | horrible idea |
| 03:13 | <zewt> | good, at least i can disable browser.urlbar.trimURLs |
| 06:03 | <yaffle> | Hello! |
| 06:03 | <yaffle> | could somebody help me with event delegation? |
| 06:03 | <yaffle> | my question is: why DOM API doesn't implement binding of event delegation and "stopPropagation" for this, like jQuery does? It seems, that jQuery makes it very good and this is very cool |
| 06:04 | <yaffle> | $(document).on('click', '.test', function () { alert(0); return false; }); |
| 06:04 | <yaffle> | $(document).on('click', '.bu', function () { alert(1); return false; }); |
| 06:04 | <yaffle> | $(document).on('click', '.bu', function () { alert(2); return false; }); |
| 06:04 | <yaffle> | <div class="test"> |
| 06:04 | <yaffle> | <div class="bu"> |
| 06:04 | <yaffle> | bu here |
| 06:04 | <yaffle> | </div> |
| 06:04 | <yaffle> | </div> |
| 06:05 | <yaffle> | clicking on ".test > .bu" will alert(1) and alert(2), but not alert(0) |
| 06:05 | <yaffle> | how to do the same with DOM API ? |
| 07:02 | <hsivonen> | looks like the thread about unprefixing has inspired quite a few responses on www-style |
| 08:01 | <zcorpan> | yaffle: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1257 |
| 08:52 | <krijn> | TabAtkins: http://vimeo.com/32135328 |
| 08:52 | <krijn> | (Sorry about that intro title :() |
| 09:01 | <yaffle> | zcorpan: no, it's not what i need: let's change markup to: |
| 09:01 | <yaffle> | <div class="test"> |
| 09:01 | <yaffle> | <div class="bu"> |
| 09:01 | <yaffle> | <a> |
| 09:01 | <yaffle> | bu here |
| 09:01 | <yaffle> | </a> |
| 09:01 | <yaffle> | </div> |
| 09:01 | <yaffle> | </div> |
| 09:02 | <yaffle> | jQuery implements their own "dispatch", so it can "stopPropagation" even with event-delegation |
| 09:27 | <zcorpan> | yaffle: ok. then, *shrug* |
| 09:30 | <hsivonen> | not the best for truth but probably good for advocacy that Firefox 3.6 no longer shows up on caniuse |
| 09:34 | <hsivonen> | oh. there's an option to show old versions |
| 10:33 | <annevk> | Is there a bug on WebKit on removing document.width and document.height? |
| 10:49 | <jarek> | annevk: but those are used all over the place, removing them would break many websites |
| 10:50 | <jarek> | no, wait... Firefox has done that... |
| 10:50 | <jarek> | https://developer.mozilla.org/en/DOM/document.width |
| 10:51 | annevk | filed https://bugs.webkit.org/show_bug.cgi?id=72591 |
| 10:52 | <annevk> | jarek: only Gecko and WebKit supported them |
| 10:52 | <annevk> | jarek: some Google-demo is still using them it seems, but not much more than that as far as I know |
| 10:58 | <abarth> | annevk: which demo? |
| 10:59 | <annevk> | http://studio.html5rocks.com/#Puzzle because of code in http://studio.html5rocks.com/samples/svg-puzzle/jigsaw.js |
| 10:59 | <annevk> | instead of document.width it should use document.body.clientWidth and same for height |
| 10:59 | <annevk> | abarth: ^^ |
| 10:59 | <abarth> | annevk: thanks. i can try to figure out who to nudge |
| 11:00 | <abarth> | strange, i don't see them in document.idl |
| 11:01 | <annevk> | thanks man |
| 11:02 | <abarth> | ah, they're on HTMLDocument |
| 11:03 | <annevk> | added that to the bug |
| 11:05 | <abarth> | i've got a patch, but i need to see how many tests it breaks :) |
| 11:37 | <yaffle> | http://stackoverflow.com/questions/8162883/dom-events-api-event-delegation-and-stoppropagation |
| 11:39 | <annevk> | I am the only one confused by this thread: http://lists.w3.org/Archives/Public/public-html/2011Nov/0157.html |
| 11:41 | <annevk> | yaffle: use event.stopPropagation() |
| 11:44 | <yaffle> | annevk: event delegation! |
| 11:46 | <annevk> | yaffle: not sure how to interpret tha |
| 11:46 | <annevk> | t |
| 11:46 | <smaug____> | (what has that to do with delegation?) |
| 11:48 | <yaffle> | annevk: i want to use "event delegation", so all event listeners are attached to same element, event.stopPropagation() will not help |
| 11:50 | <smaug____> | stopImmediatePropagation() |
| 11:50 | <smaug____> | though, I'm not sure what delegation means in this case |
| 11:50 | <smaug____> | apparently something different than usually |
| 11:51 | <annevk> | sicking did suggest we should add jQuery-style event handling to the DOM |
| 11:51 | <annevk> | I haven't had time to look at it yet |
| 11:52 | <smaug____> | huh |
| 11:53 | <yaffle> | annevk: wow! sounds good |
| 11:53 | <smaug____> | sicking has all these crazy ideas :p |
| 11:53 | <smaug____> | what is good in jquery event handling? |
| 11:57 | <yaffle> | smaug____: "stopPropagation" support + short syntax for event delegation |
| 11:57 | <smaug____> | DOM events support stopPropagation |
| 11:57 | <smaug____> | what is "short syntax for event delegation" ? |
| 11:58 | <yaffle> | smaug____: but not for "event-delegation" pattern |
| 11:59 | <smaug____> | do you mean .delegate() method in jQuery ? |
| 11:59 | <yaffle> | smaug____: $(document).on('click', '.test', function() { alert(123); }); - will alerts clicking on elements with className "test" |
| 12:00 | <yaffle> | smaug____: yes, in latest jQuery, they move to "on" method, although "delegate" makes the same |
| 12:00 | <smaug____> | document.documentElement.onclick = function (e) { if (e.target.className.contains("test")) { alert(123); } } |
| 12:01 | <yaffle> | smaug____: <b class="test"><a> who will be the target "a" or "b"? </a></b> |
| 12:01 | <smaug____> | depending on the stopPropagation calls ofc |
| 12:01 | <smaug____> | ah, true |
| 12:02 | <smaug____> | ok, my example doesn't work |
| 12:02 | <smaug____> | but something quite similar would |
| 12:02 | <yaffle> | smaug____: document.addEventListener('click', function (event ) { var target =event.target; while (target && !(target.matchesSelector && target.matchesSelector('.test')) { target=target.parentNode;} if (target) {alert(123)} },false); |
| 12:02 | <yaffle> | smaug____: this is what we can do with native DOM, but we can't do "stopPropagation" |
| 12:03 | <smaug____> | I don't understand what you mean with 'can't do "stopPropagation"'? |
| 12:04 | <smaug____> | ah, you want the first listener to call stopPropagation if there are many listeners |
| 12:04 | <smaug____> | er, many elements with .test ? |
| 12:05 | <yaffle> | smaug____: http://jsfiddle.net/sbxBw/3/ |
| 12:06 | <yaffle> | smaug____: many event listeners... |
| 12:07 | <smaug____> | stopImmediatePropagation() should work |
| 12:08 | <smaug____> | hmm |
| 12:08 | <smaug____> | well, that testcase is just about plain normal addEventListener |
| 12:08 | <smaug____> | and calling stopPropagation |
| 12:11 | <smaug____> | I can see some use cases for registering same listener to different targets |
| 12:11 | <smaug____> | but since that is just so trivial to do in scripting, I'm not sure that kind of "delegation" is needed in DOM API |
| 12:13 | <yaffle> | smaug____: stopImmediatePropagation is not what i need))) stopImmediatePropagatin prevends ALL listeners from execution |
| 12:14 | <yaffle> | smaug____: http://jsfiddle.net/sbxBw/4/ updated example )) |
| 12:15 | <smaug____> | in that example you'd just call stopPropagation() in the listener added to element with .bu |
| 12:17 | <yaffle> | smaug____: if i will add listeners to elements with ".bu" - this wouldn't be "event-delegation" =) |
| 12:17 | <smaug____> | how is jquery not adding listener to .bu element? |
| 12:17 | <smaug____> | I must be missing something here |
| 12:18 | <smaug____> | $(document) is just the context, right? and then everything underneath it with .bu and .test will get the listeners you define |
| 12:20 | <yaffle> | smaug____: "click" event will bubbles up to document, so we can listen for him on document, then check event.target or event.target.parentElement or ... |
| 12:21 | <smaug____> | "The .on() method attaches event handlers to the currently selected set of elements in the jQuery object." |
| 12:21 | <smaug____> | that is from jQuery documentation |
| 12:22 | <yaffle> | When a selector is provided, the event handler is referred to as delegated. |
| 12:22 | <smaug____> | so, as far as I see, the example you posted is still just about event propagation and calling stopPropagation |
| 12:22 | <yaffle> | http://api.jquery.com/on/#direct-and-delegated-events |
| 12:25 | <smaug____> | " The handler is not called when the event occurs directly on the bound element, but only for descendants " |
| 12:25 | <smaug____> | so, still about normal event propagation |
| 12:25 | <smaug____> | "runs the handler for any elements along that path matching the selector." |
| 12:26 | <smaug____> | still reading... |
| 12:26 | <smaug____> | I assume I'm missing something here.. |
| 12:28 | <smaug____> | but I can't find anything... |
| 12:28 | <smaug____> | jQuery uses word delegate quite unique way |
| 12:29 | <smaug____> | ah, now I see |
| 12:35 | <smaug____> | one could add the "delegate" listener during capture phase |
| 12:35 | <smaug____> | and then remove it automatically later |
| 12:35 | <smaug____> | that should give the jQuery behavior |
| 13:01 | <yaffle> | smaug____, hm... thanks, good solution |
| 15:40 | <oal> | Is it possible to do :after {content: this.alt; } or something simliar with css? I'd like to add a description below images based on their "alt" attribute. |
| 15:42 | <divya> | ::after { content: attr(alt); } |
| 15:45 | <woef> | Not really recommended though. |
| 15:47 | <oal> | Oh, never thought it would be that simple :) |
| 15:47 | <oal> | woef: Why? |
| 15:48 | <woef> | "The caption is to provide information about the image, while the alt text is to provide alternative content _to_ the image; these are not conceptually the same." |
| 15:48 | <woef> | Basically, there should be a difference in how you use them. |
| 15:50 | <oal> | Got it. Hmm, the cms I use adds alt and title attributes. Should I use the title instead? |
| 15:52 | <annevk> | ::after does not work on <img> |
| 15:52 | <annevk> | you should use <figure> <img> <figcaption> caption </figcaption> </figure> I think |
| 15:53 | <divya> | o thats true |
| 15:55 | <oal> | Ah, thanks, that's why it didn't work! ;) |
| 17:42 | Ms2ger | is bored of the unprefixing thread already |
| 17:49 | <jgraham> | Took a while |
| 17:53 | <jgraham> | "If [the CSS WG] cannot advance specification to recommendation status much faster than it has for the existing CSS Level 3 recommendations, Spock will be around when the last recommendation is published. Without time travel." - heh. Pity about the rest of the email. |
| 17:54 | <AryehGregor> | I want to make a blog post on the progress of my editing specification, preferably somewhere in W3C-land. What blog might I post on? |
| 17:55 | <AryehGregor> | I can make it on the WHATWG blog, but I'd prefer it to be W3C because of Microsoft. |
| 17:56 | <jgraham> | Microsoft read W3C blogs? |
| 17:57 | <tantek> | AryehGregor, put it on your own personal blog, tag it HTML5, and get it syndicated into the planet HTML5 aggregator on W3.org |
| 17:57 | <tantek> | #ownyourdata |
| 17:57 | <AryehGregor> | tantek, I don't have a personal blog. |
| 17:57 | <tantek> | personal wiki then? ;) |
| 17:57 | <AryehGregor> | jgraham, I have no idea, but I'm making an effort to use W3C stuff where possible out of support for CGs. |
| 17:59 | <jgraham> | Doesn't your CG get a blog? |
| 17:59 | <AryehGregor> | Um, maybe. |
| 17:59 | <AryehGregor> | I can check. |
| 17:59 | <jgraham> | I mean it is basically just wordpress |
| 18:00 | <AryehGregor> | That would be logical. |
| 18:00 | <tantek> | Hixie, what was that URL for time duration microsyntaxes where you're gathering examples/data? |
| 18:00 | <AryehGregor> | Is there some way to configure "hg push" to push to multiple repos? |
| 18:00 | jgraham | is pretty sure it does |
| 18:00 | <jgraham> | AryehGregor: That sounds like it would be very confusing |
| 18:00 | <AryehGregor> | Why? |
| 18:00 | <jgraham> | What if the push fails to one repository? |
| 18:01 | <Hixie> | tantek: http://www.whatwg.org/specs/web-apps/current-work/temp |
| 18:01 | <AryehGregor> | Then it prints an error for that one and tries another? |
| 18:01 | <tantek> | thanks |
| 18:01 | AryehGregor | doesn't know if git allows this either, but it seems useful for mirroring |
| 18:01 | <Hixie> | tantek: btw, i have one problem with the duration thing separate from the syntax, that i wonder if you could help me with |
| 18:01 | <Ms2ger> | hg push a && hg push b |
| 18:01 | <tantek> | Hixie - should I copy/paste that into a wiki page? |
| 18:02 | <Hixie> | sure |
| 18:02 | <tantek> | and edit / comment? |
| 18:02 | <tantek> | ok |
| 18:02 | <Hixie> | tantek: it seems that a year month day hour minute second duration can be boiled down to a number of months and a number of seconds |
| 18:02 | <Ms2ger> | Aliases are nice for that |
| 18:02 | <Hixie> | tantek: but how would one expose this in an api in a way that wouldn't be misused all the time? |
| 18:02 | <tantek> | except that months are not a consistent amount of time :/ |
| 18:02 | tantek | really dislikes the # of months duration |
| 18:02 | <jgraham> | Pretty sure you can only push to one repo at a time with git |
| 18:03 | <Hixie> | tantek: if we exposed durationMonths and durationSeconds, people expecting short times would only look at the seconds |
| 18:03 | <jgraham> | Because I think practically it would be confusing when it failed and you were left with some repos updated and some not |
| 18:03 | <Hixie> | tantek: and then if someone ever typos a number of months instead of minutes, they'll find the months are ignored, and will increase the seconds or something and go on their merry way... and later when someone who _does_ handle months and seconds comes along, they'll find the data is bogus |
| 18:03 | <tantek> | we could define a "month" duration as always being 30 days |
| 18:03 | <Hixie> | tantek: yeah |
| 18:04 | <Hixie> | tantek: another option would be to say that you can _either_ give durations of years+months, _or_ days,hours,minutes,seconds |
| 18:04 | <Hixie> | tantek: but can't mix and match, at least not for now |
| 18:04 | <tantek> | Hixie, well, ISO8601 let's you mix and match, so... |
| 18:04 | <tantek> | lets you |
| 18:04 | <Hixie> | tantek: we're already profiling ISO8601 anyway, *shrug* |
| 18:04 | <tantek> | agreed, profiling/subsetting is good. |
| 18:04 | <tantek> | we can at least try to be consistent |
| 18:05 | <tantek> | can we punt on an API for durations for the moment? |
| 18:05 | <tantek> | and see if there is sufficient interest in that at all from implementers? |
| 18:05 | <AryehGregor> | Ms2ger, yeah, I figured that out. Works well enough for me. |
| 18:05 | <Hixie> | tantek: (another problem with mixing and matching is that what is 1month30days? on feb 1st, yf you add days then months you end up at the start of april, but if you add months then days, you end up at the end of march) |
| 18:06 | <Ms2ger> | Also, interesting how often people mention HTML4 on www-style |
| 18:06 | tantek | needs to reference ISO8601 to answer that :/ |
| 18:06 | <tantek> | or perhaps iCalendar |
| 18:06 | <tantek> | since iCalendar also has durations |
| 18:06 | <tantek> | and defines what happens when you have a dtstart and a duration |
| 18:06 | <Hixie> | tantek: for duration, if we don't add an api, i'm worried people will roll their own |
| 18:06 | <Hixie> | tantek: and that's a non-trivial parser to write |
| 18:06 | <tantek> | Hixie, if people roll their own, we can then use that as experience to design a good one |
| 18:06 | <Hixie> | tantek: especially if we add the new syntax |
| 18:07 | <tantek> | so far people haven't even implemented the *simpler* API of datetime |
| 18:07 | <Hixie> | tantek: but even if they do roll their own, they'll still have the problem of what to do with months and seconds, so i don't think it would solve the earlier problem |
| 18:07 | <Hixie> | tantek: this would actually be simpler than the old api |
| 18:07 | <tantek> | we can define duration canonicalization |
| 18:07 | <Hixie> | tantek: in practice |
| 18:07 | <tantek> | as part of the parsing |
| 18:08 | <Hixie> | tantek: anyway, the advantage of not allowing months and seconds to be mixed is we can always allow it later if we find it's easy or important to deal with after all |
| 18:08 | <Hixie> | tantek: are there use cases for mixing them that we know of today? |
| 18:08 | <tantek> | if we're going to split them, I'd prefer days and seconds |
| 18:08 | <tantek> | since those are much more precisely / universally defined |
| 18:08 | <Hixie> | not sure what you mean by "split" |
| 18:08 | <tantek> | as the two granularities |
| 18:08 | <Hixie> | days is just a multiple of seconds |
| 18:09 | <tantek> | your distinction of months and seconds |
| 18:09 | <tantek> | instead use days and seconds |
| 18:09 | <Hixie> | ? |
| 18:09 | <tantek> | you speak of months and seconds |
| 18:09 | <Hixie> | months are the problem, not days |
| 18:09 | <tantek> | and I'm saying instead, let us speak of days and seconds |
| 18:09 | <Hixie> | days are trivial |
| 18:09 | <tantek> | not if we define a month to be 30 days |
| 18:09 | <Hixie> | 1 day = 86400 seconds |
| 18:09 | <Hixie> | if we defined 1 month = 30 days then we have no problem |
| 18:10 | <Hixie> | except that a month isn't 30 days |
| 18:10 | tantek | needs to reference iCalendar to determine that |
| 18:10 | <Hixie> | (feb 1 + 1 month = march 4th? not) |
| 18:11 | <Hixie> | icalendar doesn't allow years and months anyway |
| 18:11 | <tantek> | for durations? |
| 18:11 | <Hixie> | yeah |
| 18:11 | <tantek> | interesting |
| 18:11 | <annevk> | wow http://www.reddit.com/r/politics/comments/mfrs2/nypd_are_blocking_a_sidewalk_and_asking_for/ |
| 18:11 | <tantek> | perhaps we should take that path then |
| 18:11 | <Hixie> | (though tehy do support weeks) |
| 18:12 | <Hixie> | (which seems to be an iso8601 extension?) |
| 18:12 | <jgraham> | annevk: DOCUMENT_POSITION_CONTAINED_BY (16, 10 in hexadecimal). |
| 18:12 | <tantek> | as a week = 7 days ? |
| 18:12 | <Hixie> | seems that way |
| 18:12 | <jgraham> | annevk: Either say 16 or 0x10 |
| 18:12 | <tantek> | I'm find with limiting duration to the iCalendar subset |
| 18:12 | <tantek> | I believe that covers current use-cases |
| 18:12 | <Hixie> | let me look at the use cases again |
| 18:12 | <tantek> | and if someone wants to justify months etc. later with other use-cases that we can't do with days or weeks, they can document it |
| 18:13 | <tantek> | current use cases are around music song lengths, movie lengths, etc. and iCalendar. |
| 18:13 | <tantek> | let's punt on months |
| 18:13 | <Hixie> | well, not supporting months at all would certainly be an interesting approach |
| 18:13 | <Ms2ger> | jgraham, patches welcome :) |
| 18:13 | <divya> | annevk: these two photos are CLASSIC https://twitter.com/aaronsw/status/137191356778020864 |
| 18:13 | <Hixie> | TabAtkins: does not supporting months at all seem reasonable to you? |
| 18:13 | <Hixie> | (tab and i were talking about this yesterday) |
| 18:14 | <hober> | sounds good to me |
| 18:14 | <tantek> | Hixie, when defining something seems odd/weird, it's often a sign that there aren't sufficient use-cases to constrain it properly |
| 18:14 | <Hixie> | (and he's the only person to have sent me his opinions on that survey yet! ;-) ) |
| 18:14 | <tantek> | thus I have no problems leaving out months |
| 18:14 | <Hixie> | tantek: certainly |
| 18:14 | <tantek> | it's the more design-conservative thing to do |
| 18:14 | <tantek> | and simply leave it open to being justified by use-cases in the future and adding it then |
| 18:14 | <tantek> | we can make sure the rest of the syntax is forward/backward compatible |
| 18:15 | <tantek> | (though I have a feeling that in the decade+ of iCalendar development/usage not needing months, we're not going to need months for duration either) |
| 18:15 | tantek | will adjust the Time element whatwg wiki page accordingly for duration |
| 18:16 | <Hixie> | tantek: btw, since you're going through the htmlwg process for this, do you know if the chairs have a timetable on this issue? |
| 18:17 | <tantek> | my understanding is that they are open for alternative change proposals, but due to the nature of the consensuses at the F2F, they are willing to move more quickly than usual if there are no objections |
| 18:18 | <Hixie> | what do they think of as "quickly"? |
| 18:18 | <tantek> | I'm presuming quickly = weeks rather than months |
| 18:19 | <Hixie> | oh ok |
| 18:19 | <Hixie> | so there's no rush on this |
| 18:19 | <Hixie> | ok |
| 18:19 | <tantek> | oh wait is the HTML WG call going on right now? |
| 18:20 | <tantek> | or was it at 9am |
| 18:20 | <annevk> | an hour earlier |
| 18:20 | <tantek> | shoot |
| 18:20 | <hober> | you missed it |
| 18:20 | tantek | missed the call. |
| 18:20 | <tantek> | was time/data discussed at all? |
| 18:20 | hober | missed it too |
| 18:20 | <tantek> | sorry I had meant to attend. don't even have the different time zone excuse. |
| 18:22 | <tantek> | also, Hixie, for the details of my Time change proposal, other than the syntaxes as documented on the Time element wiki page, I've left the details to be specified by the editor, and from what I can tell, that is acceptable to the group (assuming no objections are raised). |
| 18:22 | <annevk> | divya: also WTF |
| 18:22 | tantek | would rather not overconstrain the editor's job. |
| 18:23 | <annevk> | divya: unless parody, in which case, funny |
| 18:23 | <Hixie> | tantek: i expect to have updated the spec long before the chairs get around to a decision, if they're working on the time scale of weeks rather than hours |
| 18:23 | <divya> | annevk: sadly not |
| 18:23 | <tantek> | Hixie, ok, I will attempt work with your time scale. |
| 18:23 | <annevk> | yeah I was wondering why you just wouldn't update the spec |
| 18:23 | <Hixie> | tantek: i've been making good use of your wiki page :-) |
| 18:23 | <annevk> | same for <dialog> btw |
| 18:23 | <annevk> | seems everyone wants it anyway |
| 18:24 | <annevk> | and pretty much everyone wants the new <time> |
| 18:24 | <Hixie> | annevk: i've not had many days actual work time on the spec since tpac unfortunately |
| 18:24 | <rniwa> | annevk: I talked with someone working on accessibility a couple of days ago, and he really liked dialog element 'cause it'll make modal content more accessible |
| 18:24 | <Hixie> | annevk: for <dialog> i had planned to wait for the chairs, but now it's interfering with fullscreen i might just get on with it |
| 18:25 | <Hixie> | annevk: (we've been waiting months already) |
| 18:25 | <Hixie> | annevk: once i'm done with the <time> thing we should talk about how to figure out dialog and fullscreen to make sure they work together |
| 18:27 | <annevk> | someone needs to figure out the CSS model we want |
| 18:27 | <annevk> | I don't really care |
| 18:27 | <annevk> | I think hober was going to ask www-style |
| 18:27 | <annevk> | hober: will you get that out today? |
| 18:28 | <tantek> | Hixie, I'm traveling today (from Seattle back to SF) but will try to write-up some more on duration while offline. |
| 18:28 | <tantek> | Including iterating on the list of examples you posted |
| 18:29 | <tantek> | I'll start with updating the duration addition in the wiki to drop months (and thus presumably years as well). I can add weeks for iCalendar compatibility (that seems reasonable to me). |
| 18:29 | <tantek> | (re: Time element wiki page on whatwg) |
| 18:29 | <Hixie> | tantek: i'd be interested in your opinions on those examples (especially, "1h" vs "1 h", and whether to allow any subset of the english word for the unit, as in "1 hou", "1hours"), but no need to worry about things like the dropping months stuff, i have that in hand |
| 18:29 | <hober> | yeah, it'll go out today |
| 18:30 | <Hixie> | tantek: i've actually already written much of the spec text for this other than for the extended duration syntax |
| 18:30 | <tantek> | Hixie, that's great to hear. |
| 18:30 | <Hixie> | haven't regenned the spec yet though so if you want to see it, you'll have to look in the source of http://www.whatwg.org/specs/web-apps/current-work/working-copy which is rather hard to find stuff in :-) |
| 18:30 | <gavinc> | the duration syntax is what ISO 8601... and some other stuff? |
| 18:31 | <Hixie> | (search for "duration" and search for a comment after the <data> element's definition) |
| 18:31 | <Hixie> | gavinc: a small subset of ISO8601's syntax, and something more readable based on what tantek was proposing |
| 18:31 | <Hixie> | gavinc: i'm trying to keep the new syntax similar enough to the ISO syntax that one parser can do both without having to have different modes for both syntaxes |
| 18:31 | <Hixie> | gavinc: while still making the syntax easier to read |
| 18:33 | <annevk> | Hixie: you need to have a mode because the HTML one has to throw out stuff the other allows |
| 18:33 | <Hixie> | annevk: like what? (fill out the form and mail it in! :-) ) |
| 18:35 | <tantek> | annevk, the <time> duration microsyntax should be a superset of ISO8601 duration syntax as profiled by iCalendar. If you find / think of an exception to that, please let us know ASAP. |
| 18:35 | <Hixie> | webkit doesn't support the vw unit? :-( |
| 18:37 | <beverloo> | No, vh/vm neither. |
| 18:38 | <beverloo> | (logically) |
| 18:40 | <annevk> | tantek: the moment you get into superset/profile/subset relationships, using a modeless parser is flawed |
| 18:41 | <tantek> | I'm not sure I have data either way to assess that statement. |
| 18:42 | <annevk> | tantek: a) the parser would be non-conforming because it either accepts more or less than it is supposed to and b) because of that authors might create content outside the restrictions |
| 18:43 | <Hixie> | annevk: can you give an example? i don't understand what you mean |
| 18:43 | <annevk> | tantek: e.g. URLs are restricted in HTTP, but because of the way browsers deal with all URLs, a lot of the restrictions HTTP places on them have been removed from wget/curl to be more compatible with browsers |
| 18:44 | <annevk> | if ISO allows 1hour/1h and HTML just allows 1h; you cannot use an identical parser for that |
| 18:44 | <Hixie> | ISO allows only 1H, i'm proposing that our syntax also allow "1 h" |
| 18:44 | <Hixie> | (and maybe "1 hour", depending on what people think should be allowed) |
| 18:45 | <Hixie> | seems like one parser could pretty easily handle both |
| 18:45 | <annevk> | so the HTML parser cannot be used for ISO in that instance |
| 18:45 | <Hixie> | that's certainly the case, yes |
| 18:45 | <gavinc> | Hixie: Wouldn't ISO have to be prefixed with P? eg P1H? |
| 18:45 | <Hixie> | nobody is suggesting that the html duration parser would be a good generic ISO8601 parser |
| 18:45 | <Hixie> | ISO8601, after all, supports about six bazillion variants we have no intention of even mentioning |
| 18:45 | <Hixie> | same applies to all the date and time formats in the HTML spec in fact |
| 18:45 | <Hixie> | gavinc: yes |
| 18:46 | <annevk> | "i'm trying to keep the new syntax similar enough to the ISO syntax that one parser can do both without having to have different modes for both syntaxes" |
| 18:46 | <annevk> | I guess I'll see what ends up in the spec |
| 18:46 | <annevk> | I did fill in the survey |
| 18:46 | <annevk> | btw |
| 18:47 | <annevk> | just now |
| 18:47 | <Hixie> | cool! |
| 18:47 | <Hixie> | thanks |
| 18:47 | <Hixie> | i meant that one parser could do both syntaxes when used in an html page |
| 18:47 | <Hixie> | not that you could use the parser for ISO8601-only cases outside HTML |
| 18:47 | <Hixie> | sorry for the ambiguity |
| 18:48 | <tantek> | Hixie - I didn't see a form on that page, just text examples |
| 18:48 | <gavinc> | and I've lost track of the survey |
| 18:48 | <Hixie> | i was using form in the old fashioned sense |
| 18:48 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/temp |
| 18:49 | <Hixie> | something that can be filled in |
| 18:50 | <annevk> | i.e copy/paste, fill in the open questions |
| 18:50 | <tantek> | got it |
| 18:51 | <tantek> | good ol' test case driven spec development ;) |
| 18:54 | <tantek> | Hixie, I'm not sure about allowing whitespace |
| 18:55 | <gavinc> | So, would 1MT1M be uh, something to add? or not considering supporting etc? |
| 18:55 | <tantek> | between # and unit |
| 18:55 | <tantek> | gavinc we are currently considering excluding months |
| 18:55 | <tantek> | per the above discussion |
| 18:55 | <Hixie> | gavinc: you mean as opposed to P1MT1M? or? |
| 18:55 | <tantek> | in short, iCalendar doesn't have it, nor do any current use cases need it |
| 18:55 | <Hixie> | tantek: sadly we still have to think about how to parse it, just in case we add it later |
| 18:56 | <tantek> | Hixie, agreed. |
| 18:56 | <tantek> | so currently, 1MT1M would be invalid. |
| 18:56 | <gavinc> | Hixie: Yeah, cause P1MT1M would be fine, yes? |
| 18:56 | <tantek> | no, that would also be invalid |
| 18:56 | <tantek> | since we are not supporting months (the P1M part) |
| 18:56 | <Hixie> | gavinc: modulo months being invalid in general, P1MT1M would be valid ISO-based syntax |
| 18:57 | <Hixie> | gavinc: i don't think we'd want to say that "1MT1M" (or "1DT1H" to move away from the ambiguous and controversial cases) would be conforming, though i imagine we'd parse it as if the P was there, since it's unambigous what it means |
| 18:58 | <gavinc> | Hixie: So not all valid ISO durations would be conforming? |
| 18:58 | <tantek> | Hixie, agreed with parsing it, but similar to CSS forward compatible parsing, we would ignore values with months as unsupported. |
| 18:58 | <tantek> | gavinc - no one supports "all valid ISO durations" |
| 18:58 | <Hixie> | gavinc: definitely not, there's like six bazillion different ISO duration syntaxes |
| 18:58 | <gavinc> | heh, yes I'm aware |
| 18:58 | <tantek> | nor does anyone support "all valid ISO dates" |
| 18:59 | <annevk> | what is the reason why durations and date/time are gobbled together? |
| 18:59 | <tantek> | so yeah, we're subsetting |
| 18:59 | <annevk> | s/why// |
| 18:59 | <tantek> | in the fine tradition of RFC 3339, W3C Date-time-note etc. |
| 18:59 | <tantek> | annevk - because alternatives are worse? |
| 18:59 | <gavinc> | and mixing start datetime and duration to form a single interval |
| 18:59 | <Hixie> | annevk: in reality? i think because schema.org used <time datetime=""> for durations and imdb used schema.org and now we might as well support it, because, why not |
| 19:00 | <annevk> | Hixie: ah :( |
| 19:00 | <annevk> | tantek: having separate attributes would have made sense to me |
| 19:00 | <tantek> | annevk - I think we discussed this in person at TPAC |
| 19:00 | <annevk> | tantek: putting all kinds of magic into a single attribute that has a different syntax when specified on e.g. <del> or <ins> seems wrong |
| 19:00 | <tantek> | a duration attribute |
| 19:01 | <tantek> | yeah that bothers me too |
| 19:01 | <annevk> | but if schema.org already did it... |
| 19:01 | tantek | would be ok with a duration attribute. but also ok with overloading datetime attribute. |
| 19:01 | <tantek> | well, schema.org already went much further / worse |
| 19:01 | <annevk> | then again, I hear schema.org is doing RDFa now |
| 19:01 | tantek | wants to avoid that rathole. |
| 19:01 | <tantek> | annevk, if you want to make a case for a duration attribute, I'm open to it. |
| 19:03 | <Hixie> | jsut make sure to define what happens when both are specified :-) |
| 19:03 | <gavinc> | Question, looking over the <time> wiki page. Did the conversation around supporting intervals already come up? I only care a little bit |
| 19:03 | <tantek> | Example of an interval? |
| 19:04 | <gavinc> | 2011-11-15/2011-11-17 |
| 19:05 | <Hixie> | gavinc: that's just a start time plus a duration |
| 19:05 | <Hixie> | gavinc: (or, two times) |
| 19:05 | <gavinc> | Well, that wasn't. That was two times |
| 19:05 | <gavinc> | yeah |
| 19:05 | <gavinc> | But can also be a mix of duration and a time |
| 19:05 | <tantek> | That's an event |
| 19:05 | <Hixie> | i think composition is better handled in the vocabulary that uses <time> |
| 19:05 | <Hixie> | though i did look at ISO8601's ideas here |
| 19:06 | <tantek> | Use two elements |
| 19:06 | <Hixie> | turns out the syntax is unambiguous enough that we can add it later if there's a use case |
| 19:06 | <tantek> | Agreed on composition |
| 19:07 | <gavinc> | That's kinda of the question, to say mark up a meeting, we'd recommend two <time> elements one for the start and one for the end with relations of start and end time, vs a single <time> and an interval |
| 19:09 | <tantek> | Keep time atomic |
| 19:10 | <Hixie> | gavinc: in practice even vEvents in iCalendar use two times rather than an ISO8601 interval |
| 19:10 | <gavinc> | Yes, one of the reasons I mentioned I don't care all that much |
| 19:11 | <gavinc> | Haven't seen too many intervals in the wild and they can always be decomposed |
| 19:13 | <gavinc> | also, I think Hixie was saying there are huge number of ISO formats... I don't think there are for duration. For whole datetimes sure. |
| 19:13 | <Hixie> | there's like 8 |
| 19:13 | <tantek> | Hixie if we add a duration attribute I'd say it's ignored if there is a datetime attribute |
| 19:13 | <gavinc> | For duration? |
| 19:17 | <Hixie> | gavinc: ok, three for duration, plus 4 for intervals, of which three include duration, so a total of 9 interval formats |
| 19:17 | <tantek> | If we're adding a duration attribute to keep datetime consistent across elements, we'd also need to add a timezone attribute for the separate timezone case as well. |
| 19:17 | <Hixie> | er, 10 interval formats |
| 19:17 | <tantek> | I'll think about it some more and write something up |
| 19:17 | <Hixie> | tantek: datetime="" on <time> already has nothing to do with datetime="" on <ins> |
| 19:17 | <tantek> | Ok |
| 19:17 | <Hixie> | tantek: even back with the old <time> element they had quite different rules |
| 19:18 | <Hixie> | and formats |
| 19:18 | <tantek> | Ok that's good to know |
| 19:18 | <tantek> | Was there any desire to harmonize them? |
| 19:18 | <Hixie> | not from me |
| 19:18 | <Hixie> | but then my desire was to kill <time> so what do i know :-P |
| 19:18 | <gavinc> | Hixie: but if we throw out intervals... then it's just 3 duration formats |
| 19:19 | <Hixie> | gavinc: well technically in ISO8601 the duration formats are just a component of time intervals. But yes, three duration formats. |
| 19:20 | <AryehGregor> | So using functional methods like .forEach() overrides the value of this. Is there some way to work around this, other than rewriting with C-style for loops or rewriting all uses of "this" to something else? |
| 19:20 | <gavinc> | gavin: ... oh, yeah it's all in the interval section isn't it. ew |
| 19:20 | <gavinc> | s/gavin/Hixie/ |
| 19:20 | <Hixie> | AryehGregor: .bind(), iirc |
| 19:21 | <AryehGregor> | How would that be used? |
| 19:23 | tantek | going offline for a bit. |
| 19:23 | <Hixie> | i believe you do func.bind(this) and it returns a function with the right |this| |
| 19:28 | <Hixie> | though the spec for bind() looks complicated |
| 19:43 | <annevk> | <ins datetime=2004> makes some sense |
| 19:44 | <annevk> | but I don't really care that strongly |
| 19:44 | <annevk> | whenever I get around to even using <ins>, I almost never use any of its attributes |
| 19:45 | <divya> | yeah it needs to be something that tools do |
| 19:45 | <divya> | not humans |
| 19:45 | <Hixie> | yeah <ins> is more there out of inertia than real usage |
| 19:46 | <Hixie> | it has just enough to make it pointless to remove |
| 19:46 | <Hixie> | like <samp> and others |
| 19:46 | <Hixie> | anyway. bbiab. |
| 19:54 | <AryehGregor> | What defines that document.createElement("span") returns something whose prototype is HTMLSpanElement instead of HTMLElement or Element? |
| 19:55 | <Ms2ger> | HTML |
| 19:55 | <AryehGregor> | Where? |
| 19:55 | <Ms2ger> | Let's see if I can find it |
| 19:56 | <Ms2ger> | http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#element-definitions |
| 19:56 | <AryehGregor> | That seems kind of vague. |
| 19:57 | <Ms2ger> | Patches welcome :) |
| 20:07 | <tantek> | Divya, your point about something that tools do was made about HTML an markup in general, and has been shown historically to be wishful at best. It's a tired argument that continues to be falsified in practice. |
| 20:08 | <divya> | tantek: i dont remember dates or times so it would be neat if tools do it for me |
| 20:09 | <divya> | and with git versioning you could technically mark when every character was inserted/deleted |
| 20:09 | <tantek> | You can say that about lots of things. "would be neat if" |
| 20:10 | <tantek> | The other perspective to take is that people in practice will be hand authoring so let's make the syntax as simple easy and reliably predictable as possible. |
| 20:10 | <divya> | yes i am not sure if html markup is the right place for versioning content. |
| 20:10 | <divya> | that is my concern. |
| 20:11 | <divya> | (talking specifically of ins datetime="") |
| 20:11 | <divya> | nothing more. |
| 20:11 | <tantek> | Ins and del serve a limited function in practice. |
| 20:11 | <Ms2ger> | Would be neat if authors didn't do stuput things :) |
| 20:11 | Ms2ger | can't tpye |
| 20:11 | <Ms2ger> | (stuput? Really?) |
| 20:11 | divya | thinks it would be neat if Ms2ger could type |
| 20:11 | <tantek> | Some bloggers / news sites use ins/del for updates etc. |
| 20:12 | <Ms2ger> | dvyai: mm... |
| 20:12 | <divya> | definitely |
| 20:12 | <divya> | hahah |
| 20:12 | <divya> | i do that myself. |
| 20:12 | <tantek> | We've already improved ins del in html5 by allowing only dates (it used to require full datetimes) |
| 20:12 | <divya> | oh good. |
| 20:13 | <Ms2ger> | Pff, html5 |
| 20:13 | <Ms2ger> | That's so last decade |
| 20:13 | <tantek> | We could further improve it by permitting year only and year month only as well just as we are improving the time element |
| 20:14 | <tantek> | So you could write as annevk did above |
| 20:18 | <annevk> | Ms2ger: did Gecko finally remove CDATASection? |
| 20:19 | <TabAtkins> | Hixie: Not really. For example, using <time> with durations to machine-markup a timeline that you then use script to pass through and provide a visual rendering for. |
| 20:19 | <annevk> | Ms2ger: I think there might be some kind of bug on that subject already |
| 20:28 | <jgraham> | AryehGregor: You can pass this to forEach as an additional argument |
| 20:28 | <Ms2ger> | Hmm, thought that other bug had been fixed already |
| 20:28 | <Ms2ger> | And Gecko hasn't removed it yet, I need to get around to that |
| 20:28 | <AryehGregor> | jgraham, oh, cool, thanks. |
| 21:07 | <kennyluck> | AryehGregor, (re What defines that document.createElement("span") returns something whose prototype is HTMLSpanElement instead of HTMLElement or Element?) I think this one is probably what you are looking for → http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#create-an-element-for-the-token |
| 21:13 | <Philip`> | kennyluck: That's for the parser, which isn't involved in createElement |
| 21:14 | <kennyluck> | Ah, indeed. |
| 21:20 | <WeirdAl> | annevk: ping, spec question on XHR2 |
| 21:21 | <WeirdAl> | https://bugzilla.mozilla.org/show_bug.cgi?id=525816#c32 |
| 21:26 | <annevk> | your interpretation is correct |
| 21:26 | <annevk> | they are mutual exclusive events |
| 21:26 | <WeirdAl> | phew :) |
| 21:26 | <WeirdAl> | thanks |
| 21:28 | <WeirdAl> | Does the spec explicitly state that anywhere? |
| 21:32 | <adtykfhyipoh> | sicking I need some help |
| 21:32 | <zewt> | to descramble his nick |
| 21:33 | <adtykfhyipoh> | hey can you help me |
| 21:33 | <smaug____> | better to just ask the question |
| 21:33 | <adtykfhyipoh> | Oh yeah and I just use this clump of letters as my username it's not cryptic |
| 21:33 | <smaug____> | someone may help |
| 21:33 | <adtykfhyipoh> | so I have a form that's action is a php file, but instead of linking to that php file it just downloads it |
| 21:33 | <adtykfhyipoh> | why is that |
| 21:34 | <zewt> | (is sicking the designated random-php-question guy? heh) |
| 21:34 | <adtykfhyipoh> | no but he just joined so I thought he would be online to see my question |
| 21:35 | <kennyluck> | lol |
| 21:36 | <Philip`> | I think asking random specific people for help is generally considered rude |
| 21:37 | <adtykfhyipoh> | yeah I know but I am 9 years old so watcha gonna do. Anyways, can I have help? |
| 21:38 | <kennyluck> | adtykfhyipoh, you should probably ask someone from #php |
| 21:38 | <adtykfhyipoh> | k |
| 21:38 | <Hixie> | re tab's use case above, we ran into each other at lunch and realised that that use case is possible to handle using just <time datettime="year-month">, so it's not a strong use case for months in durations after all |
| 21:41 | <annevk> | WeirdAl: Progress Events might say that |
| 21:42 | <annevk> | WeirdAl: file a bug / email if you think it should be stated somewhere (preferably including a suggestion as to where) |
| 21:42 | <WeirdAl> | I'll have to think about where. |
| 21:43 | <WeirdAl> | ah ha! |
| 21:43 | <WeirdAl> | "The error, abort, and load event types are mutually exclusive." - from the progress event spec |
| 21:43 | <WeirdAl> | of course, it doesn't mention timeout ;) |
| 21:43 | <annevk> | i guess it could go in the events summary section of XHR |
| 21:43 | <WeirdAl> | we might just need to define "exclusive progress events" or something like that |
| 21:44 | <annevk> | well the specs algorithm takes care of the details |
| 21:44 | <WeirdAl> | in both specs, stating that when an exclusive progress event fires, no other can |
| 21:45 | <annevk> | it's already stated, just needs an informative note about their mutual exclusiveness I think |
| 21:45 | <Hixie> | gavinc: oops, i missed one. There are four alternative duration formats, and one of the ones I had mentioned earlier it turns out can take either a comma or a decimal point so it's actually five formats. |
| 21:45 | <gavinc> | Hixie: Those zany Germans |
| 21:45 | <WeirdAl> | ok - I'll take a look this weekend, annevk |
| 21:46 | <bfrohs> | Question about <input type=hidden> -- Are Line Feeds and Carriage Returns allowed in the value? They are specifically disallowed in Text state and Search state, but no mention is made for Hidden state. And, if not, is there an acceptable HTML solution for storing form data from a textarea? |
| 21:46 | <annevk> | WeirdAl: thanks |
| 21:46 | <gavinc> | Hixie: Anecdotally I don't think I've seen any use of decimals other then in the seconds field |
| 21:47 | <Hixie> | anecdotally i've not really seen any of these in wide use :-P |
| 21:48 | <Hixie> | bfrohs: yes, they are allowed |
| 21:48 | <Hixie> | iirc |
| 21:48 | <Hixie> | bfrohs: for legacy reasons you may wish to escape them though as some browsers normalise them away |
| 21:48 | <Hixie> | bfrohs: i forget if we fixed that or not |
| 21:48 | <Hixie> | in the spec |
| 21:48 | <bfrohs> | Hixie: Thank ya much |
| 21:49 | <zewt> | annevk: progress events itself doesn't say anything normative about event sequences, right? (eg. which events must be mutually exclusive) |
| 21:50 | <gavinc> | Hixie: That's fair. A lot of the time interesting durations have been encoded either with start and end dates, or as a decimal seconds field |
| 21:52 | <Hixie> | yeah, personally if i was making a machine-readable format i'd just use floating point seconds, and if i was making a human-readable format i'd do something less impenetrable than iso's formats :-) |
| 21:59 | <gavinc> | Python time deltas work rather nicely. They don't have months either. http://docs.python.org/library/datetime.html#timedelta-objects |
| 22:14 | <bfrohs> | Hixie: About escaping CR/LF, did you mean to use and , or to use another escaping mechanism that's recognized server-side? |
| 22:14 | <Hixie> | as this is for working around browser limitations, i'm not sure, you'd have to test the browsers to find out what is necessary |
| 22:15 | <bfrohs> | Gotcha, thanks again |
| 22:17 | <TabAtkins> | Yeah, given the lunchtime discussion, and the fact that multiple other well-known timedelta formats don't allow months or higher, I say just drop them. |
| 22:17 | <Hixie> | anyone know if tantek put up his opinions on that "survey" i had put out earlier? |
| 22:17 | <TabAtkins> | Unless it's hidden on the wiki, no. |
| 22:17 | <Hixie> | i'm still torn on supporting "1ho" "1hour" and "1hours" |
| 22:17 | <TabAtkins> | But not "1hou"? |
| 22:17 | <Hixie> | i'm leaning towards not conforming, and probably not supported in the parser either |
| 22:18 | <Hixie> | i mean the whole question of supporting any suffixes longer than the minimum required for disambiguating |
| 22:18 | <Hixie> | the difficulting is really with "1mi" vs "1min" |
| 22:18 | <TabAtkins> | Well, now that we don't even need "min" and "mo" to disambiguate, I think it's fine to stick with single-letter prefixes. |
| 22:19 | <Hixie> | yeah, maybe that's the best way to go |
| 22:20 | <Hixie> | should datetime="1h " be conforming? (trailing whitespace) |
| 22:21 | <TabAtkins> | Yes. |
| 22:21 | <Hixie> | note that datetime="PT1H " is not (the ISO8601 equivalent) |
| 22:21 | <TabAtkins> | Trailing whitespace in unambiguous formats should always be ignored. |
| 22:21 | <Hixie> | the question is about conformance, not parsing |
| 22:21 | <TabAtkins> | Yeah, I don't see a reason to make it non-conforming. |
| 22:22 | <TabAtkins> | Makes some authoring patterns easier if it's allowed. |
| 22:22 | <TabAtkins> | Similar to allowing a trailing comma in object literals. |
| 22:22 | <Hixie> | k |
| 22:22 | <Hixie> | note that for integers (e.g.) min="1 " is not conforming |
| 22:23 | <Hixie> | but then those formats don't have internal whitespace either |
| 22:23 | <Hixie> | so that's not a big deal |
| 22:23 | <Hixie> | ok, agreed that the extended form for durations can have leading and trailing whitespace |
| 22:23 | <TabAtkins> | Yes, exactly. The authoring pattern I'm referring to isn't relevant there. |
| 22:24 | <TabAtkins> | (Where you're mapping an array or object directly into a string and each component ahs a space put after it.) |
| 22:26 | <Hixie> | should 1.1h be allowed? |
| 22:26 | <Hixie> | (fractional units that aren't seconds) |
| 22:26 | <Hixie> | if we support fractional seconds, it provides no additional difficulty as far as i can tell to support fractional everything else |
| 22:26 | <TabAtkins> | I don't think there's much need, but I don't think it's problematic either. |
| 22:27 | <zcorpan> | the <template> thing, can it parse into a document fragment? |
| 22:27 | <TabAtkins> | zcorpan: As opposed to a document? |
| 22:28 | <zcorpan> | yes |
| 22:28 | <Hixie> | i guess i'll stick to integers for now |
| 22:28 | <zcorpan> | there was an argument about document being too heavy weight |
| 22:28 | <TabAtkins> | zcorpan: I don't think there's much difference for the use-cases either way. |
| 22:28 | <TabAtkins> | If any. |
| 22:29 | <slightlyoff> | document fragment doesn't imply new intercepters, new script context, etc. |
| 22:29 | <slightlyoff> | which is nice |
| 22:30 | <zcorpan> | feel free to suggest it on the list. i'm off to bed |
| 22:31 | <astearns> | 1.5h seems much more likely than 1.1h |
| 22:35 | <TabAtkins> | But 1.5h20m seems... weird. |
| 22:46 | <AryehGregor> | New and much spiffier idlharness.js, comments appreciated: view-source:http://w3c-test.org/webapps/DOMCore/tests/submissions/AryehGregor/interfaces.html |
| 22:46 | <AryehGregor> | Er: http://w3c-test.org/webapps/DOMCore/tests/submissions/AryehGregor/interfaces.html |
| 22:46 | <AryehGregor> | (although you'll want to view source also) |
| 23:01 | <jamesr_> | Hixie, a time interval expressed as a # of seconds is really difficult to to convert to a human readable form. it's not actually possible to say what "January 14 2015 11:00:04" + 31556926 seconds will be |
| 23:01 | <jamesr_> | since leap second tables don't exist yet for 2015 |
| 23:01 | <Hixie> | in practice, people ignore leap seconds |
| 23:02 | <jamesr_> | saying "plus one year" would actually be more machine readable, in that sense, although it wouldn't express a fixed number of seconds |
| 23:03 | <Hixie> | (in fact, in practice, outside of our datacenters, physics labs, and similar situations, most people are in fact unaware that leap seconds exist at all.) |
| 23:03 | <jamesr_> | well i figured if we were gonna go semantic web we might as well go full retard^Wpedantic |
| 23:04 | <Hixie> | we're not going semantic web :-) |
| 23:05 | Philip` | wonders if the relevant use cases were listed somewhere (since presumably the desired behaviour is totally different if it's for e.g. calendar scheduling) |
| 23:06 | <Hixie> | yeah, in the wiki |
| 23:06 | <Hixie> | basically, the length of calendar appointments and music tracks |
| 23:06 | <Hixie> | and expressing those to a search engine |
| 23:06 | <Hixie> | or local page script |
| 23:09 | <Philip`> | http://wiki.whatwg.org/wiki/Special:RecentChanges looks like an awful lot of spam :-/ |
| 23:10 | <rillian_> | wiki spam has gotten terrible in the last few months |
| 23:10 | <Hixie> | AryehGregor: is there a way to disable user pages on media wiki, do you know? |
| 23:10 | <rillian_> | we have a bot posting all traffic to wiki.xiph.org to irc |
| 23:10 | <rillian_> | so we can nuke it as it comes in |
| 23:12 | <tantek> | regarding the wiki spam - based on the patterns I suspect it's coming from the same IP |
| 23:12 | <tantek> | (have seen similar problems and blocked per IP on the microformats wiki) |
| 23:13 | <tantek> | if someone more admin-like than me has access to the logs, we could probably do some IP specific blocking |
| 23:13 | <tantek> | rillian_ we have a similar bot for microformats.org/wiki posting wiki edits to #microformats |
| 23:14 | <tantek> | it's quite handy for both quickly purging spam, and seeing what areas have interest/activity |
| 23:15 | <rillian_> | yep. as long as the traffic isn't too hard |
| 23:15 | <rillian_> | er, heavy |
| 23:16 | <tantek> | hence my question about IP address - typically after blocking 1-2 IPs this stuff gets stopped. |
| 23:16 | <tantek> | I think the same spammer is attacking wiki.openwebfoundation.org |
| 23:16 | <Hixie> | i nuked a bunch of them |
| 23:16 | <Hixie> | anyone want admin privs? |
| 23:17 | <Hixie> | anyone not have admin privs? :-) |
| 23:17 | <rillian_> | sorry, have enough spam filters to clean already :( |
| 23:17 | <Hixie> | hehe |
| 23:17 | <tantek> | Hixie - I think I already have admin privs, but I'm not sure how to get the IP addresses of the folks creating spam accounts. |
| 23:18 | <Hixie> | i just block the accounts and check the "prevent this ip" checkbox |
| 23:18 | <Hixie> | it seems to do the right thing |
| 23:18 | <tantek> | hmm... |
| 23:18 | <tantek> | I thought that was the default - will double-check |
| 23:18 | <Hixie> | it is i think |
| 23:18 | <rillian_> | there's a special priv to be able to access the IP address table, iirc |
| 23:19 | <tantek> | Hixie - go ahead and max-out my admin privs if they're not already. |
| 23:19 | <Hixie> | looks like they are maxed out |
| 23:21 | <AryehGregor> | Hixie, no specific feature allows that, but you could probably configure it that way. |
| 23:22 | <Hixie> | how about preventing creation of new pages for non-admin users? |
| 23:22 | <Hixie> | i don't mind us giving admin rights away to anyone who wants them, basically |
| 23:22 | <AryehGregor> | Hixie, you should be able to do $wgNamespaceProtection[NS_USER] = 'protect' or something to stop non-admins from editing user pages. |
| 23:22 | <Hixie> | but just moving the bar to "you have to ask someone who is already an admin" would likely go a long way |
| 23:23 | <Hixie> | that would be a start i guess |
| 23:23 | Hixie | pokes around |
| 23:23 | <AryehGregor> | I think you'd be best served installing better automatic spam account filters rather than trying to lock down the wiki more. |
| 23:23 | <AryehGregor> | Wikis become a lot less useful as they get locked down more. |
| 23:24 | <Hixie> | yeah, that would be good too |
| 23:24 | <Hixie> | anyone around want to do that? |
| 23:24 | <Hixie> | if anyone wants to volunteer to play with the wiki, mail me |
| 23:25 | <Hixie> | should a duration of "P" be considered 0 seconds, or a failure? |
| 23:25 | <Hixie> | (same for "" and " ") |
| 23:25 | <TabAtkins> | I vote failure. |
| 23:25 | <TabAtkins> | Though, hm. |
| 23:25 | <mkanat> | For media? |
| 23:25 | <TabAtkins> | Maybe not. |
| 23:25 | <TabAtkins> | mkanat: No, for <time> durations. |
| 23:26 | <mkanat> | Ah. No opinion, then. :-) |
| 23:26 | <TabAtkins> | Hixie: Actually, I vote 0 seconds. |
| 23:26 | <Hixie> | on what grounds? |
| 23:26 | <TabAtkins> | To allow authoring cases like serializing an object containing duration pieces, and not having to worry about no duration pieces being passed. |
| 23:26 | <Hixie> | presumably you agree that "3s X" should return failure |
| 23:26 | <Hixie> | hm, good reason |
| 23:27 | <TabAtkins> | Yes, I agree with that. |
| 23:27 | <Hixie> | that argues for it being conforming, too |
| 23:27 | <TabAtkins> | Yeah, sure. |
| 23:27 | <Hixie> | not sure i would necessarily want to encourage authors to write <time></time> though |
| 23:27 | <Hixie> | and mean zero seconds |
| 23:27 | <Hixie> | as opposed to "not yet filled in" |
| 23:27 | <zewt> | do no browsers implement File with DataTransferItem yet, or is my test code just broken? |
| 23:27 | <zewt> | ("no" = chrome + firefox) |
| 23:28 | <TabAtkins> | Hixie: Make the lacuna value be something other than the empty string? |
| 23:28 | <tantek> | Btw I specifically included fixed point numbers for durations |
| 23:29 | <tantek> | P or "" should be invalid |
| 23:29 | <tantek> | It's more likely to be a typo than intended |
| 23:30 | <tantek> | 1.5h is slightly more human readable than 1h30m |
| 23:31 | <TabAtkins> | tantek: You think so? I'm split, but I think it's a corner case. Most decimal hours are less readable than h+m |
| 23:31 | <tantek> | Tabatkins yes I do think so. Based on publishing example seen |
| 23:32 | <tantek> | Examples* |
| 23:32 | <smaug____> | 1h30min is more readable, IMO |
| 23:33 | <smaug____> | that could be locale dependent |
| 23:34 | <Hixie> | 1h30 is the norm in locales like france, fwiw |
| 23:34 | <Hixie> | zewt: i'm not aware of any implementations, but i'm often the last to know |
| 23:34 | <zewt> | k |
| 23:34 | <Phrogz> | TabAtkins: Thanks for the mailing list clarification on SVG-in-IMG-in-Canvas. (Before I got spec-spanked by Boris.) |
| 23:34 | <zewt> | just wanted to make sure it wasn't implemented everywhere and I was doing something silly |
| 23:34 | <Hixie> | i think i'm gonna go with no time units being an error, and no fractions in non-second units, for now at least |
| 23:40 | <Hixie> | i guess since we recently made ".1" a valid float value, "1m.1s" should be valid? |
| 23:40 | <TabAtkins> | Yes. |
| 23:40 | <Hixie> | hm, it looks kinda bad |
| 23:41 | <TabAtkins> | No, it's fine! |
| 23:41 | <Hixie> | as in, it looks like "1m. 1s" |
| 23:41 | <zewt> | (sigh, do I really have to convince someone that synchronous APIs in workers exist) |
| 23:41 | <zewt> | "mailing list busywork" |
| 23:42 | <TabAtkins> | zewt: That person doesn't disbelieve that sync APIs exist. |
| 23:42 | <zewt> | sure seems to |
| 23:42 | <TabAtkins> | zewt: They think that they *shouldn't*, or maybe just that *this* sync API shouldn't. |
| 23:42 | <TabAtkins> | And I think that all the sync apis should be promise-based instead. |
| 23:42 | <zewt> | "Considering the current messaging API and the allowed host APIs, I strongly disagree." <- that guy |
| 23:43 | <TabAtkins> | I'm not sure what sentence is supposed to mean in the first place. |
| 23:43 | <TabAtkins> | Rather than writing a ranty explanatory email, perhaps ask him? |
| 23:44 | <zewt> | gmail sure makes it a challenge to trim quotes |
| 23:44 | <zewt> | delete a blank line, and an inner quote suddenly loses its block marker entirely |
| 23:44 | <TabAtkins> | zewt: Use solely plain text. |
| 23:44 | <TabAtkins> | Much easier. |
| 23:45 | TabAtkins | apparently doesn't believe in guis. |
| 23:45 | <zewt> | then i have to toggle back and forth all the time, otherwise it'll send my mails as ugly non-flowed 80-column text as if it's the 90s |
| 23:45 | <TabAtkins> | I don't see a problem with this. ^_^ |
| 23:50 | <Hixie> | "P1DT1H" is valid and should be parsed as 25 hours. |
| 23:50 | <zewt> | TabAtkins: i claim a slight irony in HTML folks preferring fixed-format messages that can't be reflowed for the user's system :) |
| 23:50 | <Hixie> | "P1D1H" is invalid, but i intend to also parse it as 25 hours |
| 23:50 | <TabAtkins> | zewt: Even more, us CSS people *hate* css-styled emails for the most part. |
| 23:50 | <Hixie> | "P1H1D" is again invalid (order matters for the iso variant), but again i intend to also parse it as 25 hours |
| 23:50 | <TabAtkins> | Hixie: Yes, seems fine. |
| 23:50 | <Hixie> | now the question: |
| 23:51 | <Hixie> | "P1HT1D". parse it the same way? (i.e. ignore the T in this case?) |
| 23:51 | <TabAtkins> | zewt: We all use ascii formats like Markdown or similar. |
| 23:51 | <TabAtkins> | Hixie: Yes, parse the same way, I think. |
| 23:51 | <Hixie> | and how about "P1H1DT" and "PT1HT1S"? |
| 23:51 | <Hixie> | i.e. T not in between components, or multiple Ts |
| 23:52 | <TabAtkins> | Hixie: P1MT1M is still not allowed, right, as you're not doing month durations? |
| 23:52 | <Hixie> | also, how about two TTs in a row |
| 23:52 | <Hixie> | TabAtkins: correct, the T is completely pointless here, only allowed for ISO compat |
| 23:52 | <zewt> | TabAtkins: not advocating CSS in emails--people *don't* need advanced formatting in email |
| 23:52 | <TabAtkins> | Hixie: Ignore a single T, sure. Don't see any reason to accept multiple Ts. |
| 23:53 | <TabAtkins> | Hixie: Though, just "remove all P and T from the string before processing" is simple and easy. |
| 23:53 | <Hixie> | well not accepting multiple Ts requires keeping track of whether we got one or not |
| 23:53 | <Hixie> | which is fine by me |
| 23:53 | <TabAtkins> | Yeah, so shrug, either way is fine with me. |
| 23:53 | <Hixie> | well presumably you don't want P1TH" to be one hour |
| 23:53 | <TabAtkins> | Ah, true that. |
| 23:53 | <TabAtkins> | But still, skipping all Ts between duration tokens seems fine I guess. |
| 23:53 | <TabAtkins> | And Ps. |
| 23:53 | <TabAtkins> | Or maybe just skip Ps at the beginning? |
| 23:53 | <mkanat> | zewt: This is going to be very hard without CSS: https://bug607829.bugzilla.mozilla.org/attachment.cgi?id=515285 |
| 23:53 | <Hixie> | P is just at the start |
| 23:54 | <Hixie> | (parser will skip whitespace before it) |
| 23:54 | <Hixie> | ok i'll skip any Ts between any two components, but fail if T is used in any other way (between number and unit, at the end, two in a row) |
| 23:54 | <TabAtkins> | Hixie: I don't see why we should fail with Ts at the end or two-in-a-row. |
| 23:55 | <TabAtkins> | "P1hT1mT" and "P1hTT1m" both seem invalid but easy to parse. |
| 23:55 | <Hixie> | well mostly because it's easier to spec that way |
| 23:55 | <Hixie> | ok |
| 23:55 | <Hixie> | will support those then |
| 23:56 | <TabAtkins> | mkanat: Yeah, computer-generated and "active" emails can use HTML well. Human-written emails rarely do. |
| 23:56 | <mkanat> | TabAtkins: Yeah, true. |
| 23:56 | <mkanat> | Unfortunately, my understanding is that gmail strips CSS, making it very hard to standardize such things. |
| 23:56 | <mkanat> | From a client perspective. |
| 23:56 | <TabAtkins> | (The primary effect of using HTML+CSS in human-written emails is to use bizarre font sizes or dark colors that don't work well with my theme.) |
| 23:58 | <TabAtkins> | Or, ugh, to use colors to indicate what's quoted and what's your own writing. |
| 23:58 | <Hixie> | ok i think i have the parser figured out, now to convert it to english |
| 23:59 | <TabAtkins> | Why *anyone* thinks that's a good idea when it trivially doesn't scale past the first reply is beyond me. |
| 23:59 | <zewt> | TabAtkins: i don't think emails should be able to set fonts or font sizes, either |
| 23:59 | <zewt> | setting fixed-width (for code) is okay, but you don't need direct font control for that |
| 23:59 | <TabAtkins> | zewt: So you think that headings and <small> should have no effect in HTML email? |