| 00:05 | <MikeSmith> | zcorpan: well, it's on the microformats "existing rel values" page, so it remains valid anyway |
| 00:06 | <MikeSmith> | which is true also for pretty much all the other link-relation names that have been dropped |
| 00:06 | <MikeSmith> | so from a user/author POV, it makes little difference in practice if it's dropped from the spec or not |
| 00:06 | <zcorpan> | useless features should be moved to the invalid department imho |
| 00:07 | <zcorpan> | but i don't feel strongly about it |
| 00:07 | <MikeSmith> | it's a wiki |
| 00:07 | <zcorpan> | now time to sleep |
| 00:07 | <MikeSmith> | おやすみ |
| 00:07 | <zcorpan> | don't make me translate that; i'm going to bed |
| 00:22 | <jamesr> | someone is wondering why there isn't a delta on onscroll events |
| 00:25 | <jamesr> | anyone know why? |
| 00:28 | <heycam> | smaug____ may know |
| 00:28 | <smaug____> | jamesr: hmm. I'd say at least because of historical reasons |
| 00:29 | <smaug____> | jamesr: also, what kinds of values would you expect? |
| 00:29 | <smaug____> | and, scroll event happens after scrolling |
| 00:30 | <smaug____> | ...so I'm not quite sure what the delta would mean |
| 00:30 | <smaug____> | especially if the size of viewport changes while scrolling |
| 00:30 | <jamesr> | the difference in scroll offsets relative to the previous scroll event, i suppose |
| 00:31 | <jamesr> | the top/left offsets shouldn't depend on the viewport size |
| 00:31 | <jamesr> | just the possible max values for them |
| 00:32 | <smaug____> | at which point would you calculate offset to top/left? |
| 00:33 | <smaug____> | when user scrolls, or when the scroll event is dispatched? |
| 00:33 | <jamesr> | when the event dispatches |
| 00:34 | <jamesr> | if i scroll down 53px then the next scroll event would have scrollDeltaY = 53 (or -53, i can never remember which way the coord system goes) |
| 00:36 | <smaug____> | jamesr: and if you after that scroll say 10px, scrollDeltaY would be 63? |
| 00:36 | <smaug____> | or 10? |
| 00:36 | <jamesr> | the next scroll event would say 10 |
| 00:37 | <jamesr> | or i suppose each event could have the scrollTop/scrollLeft pair for the thing it was scrolling |
| 00:37 | <smaug____> | that would be tricky to implement, I think |
| 00:37 | <smaug____> | since layout may change during scrolling |
| 00:37 | <smaug____> | so how to decide that 10px was scrolled |
| 00:37 | <jamesr> | well, we have to do layout to scroll at all |
| 00:38 | <smaug____> | it would be easier to report offset to top/left |
| 00:39 | <smaug____> | but, we have that kinds of offset already elsewhere |
| 00:39 | <jamesr> | not sure i agree |
| 00:39 | <jamesr> | in webkit all the scrolls are internally done with deltas |
| 00:40 | <smaug____> | sure, in gecko, scrolling works with deltas too |
| 00:42 | <smaug____> | what would be the use case for adding offsets or deltas to scroll event? |
| 00:49 | <smaug____> | Seems like in gecko adding such delta would be quite easy. But since scroll event is async, I'm not quite sure how useful the delta would be. Perhaps there is some good use case ... |
| 00:50 | <jamesr> | some pages react to scroll events to lazy load parts of the DOM when they are close to scrolling into view, so currently they listen to scroll events and then in the handler have to figure out which way the scroll actually went |
| 00:50 | <jamesr> | there's buffering so it's ok if the event is later |
| 00:52 | <smaug____> | ah, that is a good use case |
| 00:55 | <jamesr> | i'm not totally sure why they want a delta instead of just querying scrollTop/scrollLeft in the handler - maybe that's just a PITA to keep track of |
| 00:56 | <smaug____> | is this some bug report where some web devs want a new feature? |
| 00:58 | <smaug____> | If such additional properties were to added to scroll event, I think cssom-view would be the right place to define that all |
| 00:58 | <jamesr> | an email, but yes |
| 01:00 | <smaug____> | jamesr: but don't they still need to check if the view port has been scrolled long enough before loading some new data to page? |
| 01:00 | <jamesr> | oh? do they cover dom events? |
| 01:00 | <jamesr> | yes, they internally use it to calculate their view offset thingy |
| 01:00 | <smaug____> | in that case delta might not be useful |
| 01:01 | <jamesr> | why's that? they listen to resize to detect viewport size changes |
| 01:02 | <smaug____> | I mean, perhaps having just some flag to indicate the direction might be enough |
| 01:04 | <smaug____> | Though, deltaX/Y are that kinds of flags with a bit more information |
| 01:07 | <smaug____> | so, the delta needs to be calculated when scrolling happens, not when the event is dispatched |
| 01:16 | <jamesr> | does firefox aggregate multiple user scrolls into one scroll event? |
| 01:17 | <jamesr> | or are they 1:!? |
| 01:17 | <jamesr> | 1:1* |
| 01:19 | <smaug____> | IIRC 1:1 |
| 01:20 | smaug____ | tries to remember if there is some special case when handling Win7 touch screen panning |
| 01:21 | <smaug____> | ...there shouldn't be |
| 01:25 | <smaug____> | oh, smoothscrolling may change the default 1:1 |
| 01:33 | <Hixie> | TabAtkins, ap: who should i cc on bugs that affect for webkit's form controls implementation? |
| 01:35 | <Hixie> | (the bug in this case being http://www.w3.org/Bugs/Public/show_bug.cgi?id=11212 ) |
| 01:41 | <MikeSmith> | Kent Tamura |
| 01:41 | <MikeSmith> | maybe |
| 01:41 | <MikeSmith> | oh |
| 01:42 | <MikeSmith> | I meant if it's about HTML5 forms stuff |
| 01:42 | MikeSmith | looks at the bug |
| 01:44 | <Hixie> | it's about required="" on <input typeradio> |
| 02:02 | <ap> | Hixie: yes, tkent is the right person for that. And I'll see the bug anyway, and might CC someone else |
| 02:04 | <ap> | oh, if it's a w3.org bug, I won't see it anyway, I as thinking of webkit.org |
| 02:32 | <Yuhong> | On tables for layout: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10963#c19 |
| 07:38 | <hsivonen> | Hmm. is there some SEO scam that's based on translating Web pages into the mother tongue of the translator |
| 07:39 | <hsivonen> | something like the translations actually being machine translations but the links to them give Google juice to a scam? |
| 07:40 | <hsivonen> | so far, I've always permitted my pages to be translated and the translations seemed legitimate, but now I got a permission request that I don't know what to think of |
| 07:40 | <hsivonen> | kinda sad, though, that I even have to consider the possibility of a scam |
| 07:42 | <hsivonen> | hmm. googling around for the guy sure makes it look like the translations are all about building google juice for hosting-related domains |
| 07:52 | <MikeSmith> | hsivonen: there's some guy like that who has contributed translations of the CSS info hosted at W3C |
| 08:03 | <hsivonen> | MikeSmith: I made this the first time I declined a translation permission |
| 08:41 | <MikeSmith> | hsivonen: if you have not read http://greggkellogg.net/2011/05/05/cme-and-the-semantic-web yet, it's worth reading |
| 08:43 | <MikeSmith> | [[ |
| 08:43 | <MikeSmith> | the fact is, though, that proprietary metadata formats are much simpler to implement and manage. According to a key opinion maker: “I bet the average developer can get a simple XML-based music metadata system up and running in less time than it would take to read the Music Ontology document. We can get most (all?) of the benefits of RDF through simpler means. |
| 08:43 | <MikeSmith> | ]] |
| 08:44 | <hsivonen> | MikeSmith: thanks |
| 08:45 | <hsivonen> | "a key opinion maker" sounds like weasel language, though |
| 08:45 | <MikeSmith> | heh |
| 08:45 | <MikeSmith> | indeed |
| 08:45 | <MikeSmith> | kind of suspicious |
| 08:45 | <MikeSmith> | but the piece overall seems pretty well-considered |
| 08:48 | <MikeSmith> | zcorpan: do you know if Opera has an public plan to implement CSP? |
| 08:49 | <zcorpan> | i don't |
| 08:49 | <MikeSmith> | ok |
| 09:02 | <zcorpan> | bet browsers aren't going to call all keyboard events LegacyKeyboardEvent http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#legacy-key-attributes |
| 09:02 | zcorpan | will review more closely later |
| 09:06 | <hsivonen> | MikeSmith: I commented on the music/SemWeb post. Got stuck in moderation |
| 09:07 | <hsivonen> | MikeSmith: my comment was http://pastebin.mozilla.org/1219593 |
| 09:07 | MikeSmith | reads |
| 09:09 | <MikeSmith> | yeah |
| 09:10 | <MikeSmith> | "astounding uptake" does not seem the most apt description |
| 20:43 | <Hixie> | jgraham: yt? |
| 20:43 | <Hixie> | jgraham: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12299#c9 |
| 21:16 | <Hixie> | Ms2ger: hah, i hadn't noticed it was you filing the bug in http://www.w3.org/Bugs/Public/show_bug.cgi?id=12187. I wouldn't have asked if it was a trick question if I had! :-P |
| 21:17 | <Ms2ger> | :) |
| 21:18 | Ms2ger | is happy to see bugs being fixed :) |
| 21:41 | <AryehGregor> | Has anyone thought about the fact that you can use the CSS cursor property to make it look like the cursor is anywhere you like on the page? Like, security-wise? |
| 21:42 | <AryehGregor> | Maybe there are easier ways to make the cursor look like it's pointing at the wrong thing, though. |