| 13:54 | <fresco> | Would it be possible to get a user account for the WHATWG wiki? |
| 13:54 | <fresco> | I'm planning to add the citation_* meta tags to the MetaExtensions page (or at least propose them on the discussion page) |
| 13:56 | <fresco> | There may be resistance to adding them as they duplicate DC meta tags in some cases, but they are in wide use and are recommended for use by Google Scholar https://www.google.com/intl/en/scholar/inclusion.html#indexing (which is the closest thing to a specification that exists for them) |
| 14:01 | <zcorpan> | fresco: what username and email do you want for the account? |
| 14:42 | <MikeSmith> | fresco: the documentation at https://www.google.com/intl/en/scholar/inclusion.html#indexing is better than we have for 90% of the stuff that's already registered |
| 14:43 | <MikeSmith> | and those citation_* values to me see a lot easier to read than the DC things |
| 14:44 | <MikeSmith> | and if Google Scholar actually consumes the citation_* stuff and does something with it, that all sounds good |
| 14:46 | <fresco> | I've added a note to the discussion page as well, as some of them - although being widely used - are not formally documented anywhere |
| 14:46 | <MikeSmith> | yep, just now read that too |
| 14:47 | <MikeSmith> | thanks for taking time to add this stuff |
| 14:47 | <MikeSmith> | I'll get it pushed out to the w3c validator later today or tomorrow |
| 14:48 | <fresco> | Brilliant, thanks Mike |
| 15:41 | <JakeA> | TabAtkins: Didn't realise docment.fonts.check wouldn't accept "helvetica", and it had to be "10px helvetica" or something like that. Why is the size needed? |
| 15:54 | <zcorpan> | JakeA: the spec says to parse as the 'font' property, which requires a size. i don't know the reasoning here though |
| 15:55 | <JakeA> | zcorpan: Yeah, followed the spec there. I never really understood why font: requires it either, but seems to make even less sense in the JS API |
| 15:55 | <JakeA> | It's not like you can use a different font for different sizes |
| 15:55 | <JakeA> | (is it?) |
| 15:56 | <JakeA> | no, you can't |
| 15:57 | <zcorpan> | JakeA: 'font' requires it to disambiguate font-family from the other properties iirc |
| 15:58 | <JakeA> | ahh ok, guess the same reason applies to the JS api |
| 15:58 | <zcorpan> | but you can use different fonts for different weights at least |
| 15:58 | <JakeA> | feels like a hack though |
| 15:58 | <JakeA> | yeah |
| 16:02 | <zcorpan> | is the API shipped anywhere? |
| 16:02 | <JakeA> | Yeah, it's in Chrome stable |
| 16:02 | <mathiasbynens> | annevk (if you’re reading logs): http://l0.cm/encodings/table/ |
| 16:32 | <TabAtkins> | JakeA: The parsing of 'font' is complicated and stupid, but the rules ar enecessary. |
| 16:33 | <TabAtkins> | The size is the last component before the name, and it's distinguishable from all the preceding values, so you can tell when you've hit it, and when you have to switch to the "collect all the tokens and try to parse them as a font-family name" part of the property. |
| 16:33 | <TabAtkins> | Because the font-family part, stupidly, allows idents, numbers, and dimensions. |
| 16:34 | <TabAtkins> | Now, for check(), the font-family name isn't enough - you want to know that the *bold* face of your font is loaded, for example. So you need the whole font shorthand. But that means you have to include the completely worthless font-size in there, which is confusing and annoying, but unavoidable. |
| 16:35 | <TabAtkins> | This is just one of the CSS mistakes from before we knew better. (In particular, we now know that all values coming from the outside world should be strings in the CSS syntax, because we can't predict how they'll parse. We just ran into that with lang values again.) |
| 16:44 | <jarek> | Hi |
| 16:45 | <jarek> | is anybody working on the next version of Touch Events spec? |
| 16:47 | <JakeA> | TabAtkins: Makes sense. It's a shame, but unavoidable unless .check has stricter parsing (which would break over use cases) |
| 16:48 | <TabAtkins> | Yup. |
| 16:49 | <jarek> | "The W3C Web Events Working Group was closed on 5 November 2013, having successfully published the Touch Events specification as a Recommendation. More advanced work on touch, pointer and mouse events continues in the Pointer Events Working Group." |
| 16:50 | <jarek> | ^ is this still actual? Both Google and Apple made it clear they will never implement pointer events |
| 16:51 | <jarek> | s/never/unlikely |
| 16:52 | <jgraham> | My impression is that the problem with touch/pointer interaction standardisation is that several players are actively working against standardisation |
| 16:53 | <jgraham> | So I'm not sure that it really matters which group is doing the work (or not) |
| 16:53 | <jgraham> | I could be wrong though, I don't really follow it |
| 16:54 | <TabAtkins> | The situation is... complicated, but sure, that's not a totally inaccurate characterization. |
| 16:57 | <jarek> | Google is cherry-picking some stuff from the Pointer Events spec (like touch-action and navigator.maxTouchPoints are implemented) |
| 16:58 | <jarek> | I would really prefer to have everything defined in one place |
| 17:01 | <jarek> | jgraham: what do you mean specifically by "working against standardisation"? Apple and its patent claims? |
| 17:02 | <jgraham> | I don't mean anything specifically |
| 17:22 | <fresco> | There are some link relations in https://tools.ietf.org/html/rfc5829 that I'd like to add to http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions so they can be used in HTML. Would that be appropriate? |
| 17:22 | <fresco> | They are already included in https://www.iana.org/assignments/link-relations/link-relations.xhtml |
| 17:55 | <TabAtkins> | fresco: Seems reasonable. |
| 19:19 | <rubys> | TabAtkins: you around? I now get a stack traceback. |
| 19:19 | <TabAtkins> | man what |
| 19:19 | <rubys> | AttributeError: 'ExtendedAttribute' object has no attribute 'arguments' |
| 19:19 | <TabAtkins> | Man what. |
| 19:19 | <rubys> | $ man what |
| 19:19 | <rubys> | No manual entry for what |
| 19:19 | <TabAtkins> | Okay, I'll check this out. I tested this on a simple example that should have matched your stuff. :( |
| 19:20 | TabAtkins | is gonna install a man entry for "what" that just says "lol i dunno" |
| 19:28 | <TabAtkins> | Ah, good, this isn't realted to stringifiers at all, it's something new in the updated widlparser. |
| 19:33 | <TabAtkins> | rubys: Okay, fixed, sorry. Exercising a new code path. |
| 19:33 | rubys | shrugs |
| 19:33 | <TabAtkins> | rubys: There's now some definitional errors, is all. Define href as an attribute, not a stringifier. |
| 19:33 | <rubys> | bugs happen. what matters is that the maintainers are responsive. And you have been VERY responsive. THANKS! |
| 19:34 | <TabAtkins> | And later, when you're defining "stringifier" itself for URLSearchParams, instead do a "dfn" type definition for "stringification behavior". |
| 19:34 | <TabAtkins> | This is not yet documented, but it's what's needed to link up with the plain "stringifier;" syntax. |
| 19:35 | <TabAtkins> | <dfn dfn for=URLSearchParams>stringification behavior</dfn> |
| 19:35 | <rubys> | now I'm back to: |
| 19:35 | <rubys> | FATAL ERROR: Functions/methods must end with () in their linking text, got 'href'. |
| 19:36 | <rubys> | I presume that's because I haven't done the change above? |
| 19:36 | <TabAtkins> | Yup. |
| 19:36 | <rubys> | TabAtkins: perhaps it would be easier if you were to make a pull request? |
| 19:36 | <TabAtkins> | Sure, one sec. I've got it building cleanly now. |
| 19:39 | <TabAtkins> | done |
| 19:40 | TabAtkins | desperately needs to document how to dfn/link to stringifiers; the four different syntax forms make this very confusing. |
| 19:40 | rubys | on a call, just a sec |
| 19:46 | TabAtkins | also wants to spend some time converting all your IDL links to the {{foo}} shorthand. |
| 19:47 | <TabAtkins> | But I wont' do that this week, as this is a fantasai work week. |
| 21:24 | <annevk> | mathiasbynens: I had seen that before, wasn't quite sure what to do with it |