| 03:13 | <JonathanNeal> | Can anyone show me an example of traditional typographical shorthand notation where a slash is used to separate the font size and line height? |
| 03:26 | <JonathanNeal> | > The syntax of this property is based on a traditional typographical shorthand notation to set multiple properties related to fonts. — http://www.w3.org/TR/css3-fonts/#font-prop |
| 03:32 | <boogyman> | JonathanNeal: I don't know that it specifically relates to the optical size / line-height relationship, but rather the means of defining multiple characteristics |
| 03:46 | <JonathanNeal> | @boogyman, would you know why that syntax was used then, over say, spaces? |
| 03:49 | <boogyman> | I can speculate that since those are the two "numeric" characteristics, it was easiest to describe using the non-standard delimiter. eg, the other characteristics don't really overlap at all |
| 04:12 | <astearns> | JonathanNeal: I have seen 10/12 etc. notation for size/leading, usually in books on pre-desktop-publishing usage |
| 08:18 | <annevk> | "I presume, then, you have a W3C approved, feature-complete alternative implementation to SMIL with solid reasons for deprecating the specification." |
| 08:52 | <MikeSmith> | "I'm simply not confident you have the chops to lead the way in the area of web development standards." |
| 08:59 | <philipj> | What are you quoting from? :) |
| 09:02 | <annevk> | blink-dev <3 |
| 09:03 | <annevk> | I hadn't really read past the initial bit of the email, but it's a real gem |
| 09:03 | <annevk> | "SVG is the only really capable image format that offers superb scalability and flexibility inside the XHTML framework." |
| 09:04 | <annevk> | "I'm coming to a place where I don't care if Web & CSS animations will walk my dog and cook my breakfast." |
| 09:11 | <roc> | who? |
| 09:21 | <annevk> | roc: I don't know who this person is, it's just the last email in the SMIL deprecation thread on blink-dev |
| 10:13 | <nox> | annevk: I don't usually care about tone, but wow. |
| 10:29 | <jochen__> | annevk: does fetch talk about 3xx redirects at all? |
| 10:29 | <annevk> | jochen__: yes |
| 10:29 | <annevk> | jochen__: https://fetch.spec.whatwg.org/#http-fetch step 5 |
| 10:31 | <jgraham> | nox: People like that are an occupational hazard of working on web standards |
| 10:32 | <nox> | jgraham: I don't even comprehend why he would mention that the deprecation is bad because Blink is FOSS. |
| 10:33 | <nox> | "As an aside but wholly related, here's a gem in the form of a significant SMIL bug report dating back to 2011 that still hasn't been fixed. Given this and what I consider an ill-considered deprication announcement I'm simply not confident you have the chops to lead the way in the area of web development standards." What. |
| 10:33 | <nox> | Oh MikeSmith had pasted that part, never mind. |
| 10:58 | <jochen__> | annevk, maybe I'm blind that step 5 already doesn't tell what to do with the referrer, no? |
| 10:58 | <annevk> | jochen__: yeah, we probably need to update that somehow |
| 10:58 | <annevk> | jochen__: if redirects affect the referrer |
| 10:58 | <annevk> | jochen__: which I guess they do |
| 10:59 | <annevk> | jochen__: seems like something that's not well defined at the moment |
| 10:59 | <jochen__> | at least not in fetch |
| 10:59 | <jochen__> | i'm pretty sure that http says what to do on downgrade |
| 11:03 | <annevk> | https://tools.ietf.org/html/rfc7231#section-5.5.2 doesn't say much |
| 11:04 | <jgraham> | nox: Logical arguments aren't a strong feature of the "you're all inept and shouldn't be allowed to do this work" rants |
| 11:12 | <annevk> | mkwst: any ideas on how to move https://github.com/whatwg/html/pull/323 forward? |
| 12:41 | <zcorpan> | it's annoying that github issue referencing doesn't work when it's in the PR title |
| 12:56 | <nox> | If only that was the only annoying thing. |
| 12:58 | <MikeSmith> | amen |
| 13:06 | <jochen__> | annevk, ship it and see what explodes? |
| 13:06 | <annevk> | jochen__: :-) |
| 13:07 | <annevk> | jochen__: try shipping something where A can only navigate B if A is B |
| 13:11 | <zcorpan> | jgraham: is it known that files with spaces in the file name get 404ed by wpt-serve? |
| 13:27 | zcorpan | looks at https://github.com/w3c/wptserve/blob/master/wptserve/handlers.py but can't see anything obvious to fix |
| 13:34 | <yoav_> | annevk: comments on not rejecting invalid values as per https://github.com/whatwg/dom/pull/114#issuecomment-159568709 ? |
| 13:36 | <annevk> | yoav: not really, having a bit of a hard time seeing what an ideal API might be here given the constraints |
| 13:38 | <yoav> | OK |
| 14:01 | <zcorpan> | jgraham: filed https://github.com/w3c/wptserve/issues/69 |
| 14:04 | <zcorpan> | yoav: i suppose all-truthy strings is OK since code is going to care about legacy clients, and strings makes it more self-documenting than mystery falsy values |
| 14:05 | <yoav> | zcorpan: OK, so now the main question is whether invalid values should be rejected? |
| 14:06 | <zcorpan> | yoav: yeah. it was Domenic who wanted that, mostly? |
| 14:08 | <Domenic> | I still think it would be nice. If we're not going to do a solution that tries to sync what's actually added with what's supported, then we should just go with relList.supportedValues = ["foo", "bar", "baz", ...] or relList.supports("foo"), and accept that spec authors will have to be careful to synchronize supportedValues with reality. |
| 14:09 | <zcorpan> | relList.supports('foo') would be OK with me. we can write wpt tests that check that the claim matches the actual support |
| 14:10 | <Domenic> | does it return a boolean or an enum? |
| 14:10 | <zcorpan> | boolean. it doesn't have the problem that add() has because supports() doesn't exist today |
| 14:11 | <zcorpan> | hmm wait |
| 14:11 | <zcorpan> | there was this other case also |
| 14:11 | <zcorpan> | <a>.relList or other going from n/a to having a set of supported keywords |
| 14:12 | <Domenic> | I don't really understand how that's ever going to make sense |
| 14:12 | <Domenic> | If it's going to have a set of supported keywords we should do that now |
| 14:12 | <Domenic> | But I don't see why it ever would |
| 14:13 | <zcorpan> | to check for <a rel=noopener>? |
| 14:13 | <Domenic> | Then we should define the set of supported keywords for <a rel> now |
| 14:13 | <zcorpan> | yes, we should |
| 14:14 | <Domenic> | Then we can go back to .add :P. (Or supports I guess, whatever.) |
| 14:14 | <Domenic> | Next question: does "supports" mean "is specified" or does it mean "has some affect on browser processing" |
| 14:14 | <zcorpan> | and does classList.supports() exist at all, and if it does, what does it return? |
| 14:15 | <zcorpan> | the latter |
| 14:15 | <Domenic> | e.g., what does a.relList.supports("tag") return |
| 14:15 | <Domenic> | OK so a.relList.supports("tag") is false |
| 14:15 | <Domenic> | I think classList.supports("anything without a NUL byte") is true |
| 14:16 | <zcorpan> | right (re "tag") |
| 14:16 | <zcorpan> | why? (and why "anything without a NUL byte"?) |
| 14:17 | <Domenic> | because the browser now includes the class name you added in the list of things CSS selectors match, and because http://stackoverflow.com/a/6732899/3191 |
| 14:18 | <Domenic> | although clicking through that StackOverflow answer to the spec I can't find the NUL byte clause |
| 14:18 | <zcorpan> | having a DOM API be affected of css syntax seems a bit weird |
| 14:19 | <zcorpan> | you can use class without using css |
| 14:20 | <Domenic> | Is it weirder than having a DOM API be affected by the preload spec? |
| 14:20 | <zcorpan> | i don't know what that is referring to |
| 14:21 | <zcorpan> | but maybe besides the point :-) |
| 14:21 | <Domenic> | a.relList.supports("preload") is determined by the fact that the preload spec says "preload" rel has normative impact |
| 14:21 | <Domenic> | despite .supports() being a DOM API |
| 14:22 | <Domenic> | Let me summarize this on the issue tracker... where's the latest place... |
| 14:22 | <zcorpan> | ok, sure, but classes don't do anything on their own, so they're not "supported" in that sense. unless we had classes with default styling, maybe |
| 14:25 | <zcorpan> | there isn't a use case for supports() on classList, it just gets the API by accident because it's also a DOMTokenList |
| 14:25 | <zcorpan> | maybe we should have a new interface |
| 14:46 | <annevk> | Domenic: zcorpan: note that two classes means four classes due to DOMSettableTokenList |
| 14:48 | <zcorpan> | yeah |
| 14:48 | <zcorpan> | except we might only need 3 |
| 14:49 | <annevk> | zcorpan: HTML has been patched for both DOMTokenList and DOMSettableTokenList users to add a concept of supported tokens |
| 14:49 | <Domenic> | ... why *isn't* classList a DOMSettableTokenList |
| 14:50 | <annevk> | Domenic: I think because className exists |
| 14:50 | <Domenic> | Why isn't everything a DOMSettableTokenList |
| 14:50 | <Domenic> | Stupid /topic |
| 14:50 | <annevk> | We might be able to do that... |
| 14:51 | <zcorpan> | annevk: yes. but there's no DOMSettableTokenList other than <iframe sandbox>, is there? |
| 14:51 | <annevk> | zcorpan: maybe not with supported values |
| 14:52 | <annevk> | zcorpan: but there's <a>.ping and <link>.sizes |
| 14:52 | <Domenic> | It would be nice to rationalize everything to [PutForwards=appropriateProperty] DOMSettableTokenList |
| 14:52 | <zcorpan> | oh ok yeah. and dropzone |
| 14:53 | <Domenic> | Then we could teach new web developers classList and never teach them className |
| 14:53 | <Domenic> | I guess [PutForwards] isn't that great of a behavior to teach |
| 14:54 | <Domenic> | Still, the fact that we have so many different patterns for this same idiom is weird |
| 14:54 | <zcorpan> | switching to [PutForwards] and DOMSettableTokenList everywhere seems good |
| 14:56 | <annevk> | Is it only HTML that uses DOMTokenList? |
| 14:59 | <Domenic> | annevk: yes in Blink; where's Gecko's codesearch again? https://code.google.com/p/chromium/codesearch#search/&q=DOMTokenList%20file:%5C.idl&sq=package:chromium&type=cs |
| 14:59 | <Domenic> | Wait lol Blink doesn't even use DOMTokenList anywhere |
| 15:00 | <Domenic> | Except as a base class for DOMSettableTokenList |
| 15:01 | <Ms2ger> | Domenic, mxr.mozilla.org |
| 15:03 | <Domenic> | Oh Blink has classList at least nevermind |
| 15:03 | <Domenic> | But yeah seems like's yes for Gecko as well https://mxr.mozilla.org/mozilla-central/search?string=DOMTokenList&find=.idl |
| 15:05 | <annevk> | Domenic: I'll file an issue suggesting this simplification and then we can see what folks say |
| 15:08 | <annevk> | https://github.com/whatwg/dom/issues/119 |
| 15:10 | <annevk> | https://github.com/whatwg/html/issues/358 |
| 15:54 | <zcorpan> | The HTML Working Group has published a W3C Recommendation of W3C DOM4. |
| 15:56 | <Domenic> | I guess the good part is that it'll become increasingly obvious what a joke it is given all the changes since the last snapshot. |
| 15:57 | <Ms2ger> | Domenic, changes? Why? The W3C has declared everything in DOM4 is implemented perfectly interoperably! |
| 15:57 | <zcorpan> | ok so can we fix Document vs HTMLDocument already? |
| 15:58 | <Domenic> | Document vs HTMLDocument seems like Attr as a Node... someone needs to try the current spec, nobody but Servo is brave enough to d oso |
| 15:58 | <annevk> | zcorpan: can you? |
| 15:59 | <annevk> | zcorpan: even if we are to admit defeat, defining the appropriate Document object for each context and then what properties each must expose is quite a big undertaking |
| 15:59 | <Ms2ger> | Is there a new reason to give up? |
| 15:59 | <zcorpan> | i meant fix as in implement what is specced now |
| 16:00 | <zcorpan> | i can't do it because i'm not a browser dev :-] |
| 16:02 | <Domenic> | jsdom is working on it! |
| 16:08 | <gsnedders> | zcorpan: become a browser dev! |
| 16:13 | <gsnedders> | jgraham: can you prod https://github.com/html5lib/html5lib-python/pull/198 such that Critic realises it exists and creates a review for it? |
| 16:14 | <gsnedders> | jgraham: also opinions welcome on whether it's worthwhile rewriting the history even more |
| 17:05 | <annevk> | Domenic: JakeA: https://twitter.com/phuunet/status/669515142057598976 |
| 17:06 | annevk | yawns |
| 17:06 | <annevk> | MikeSmith: http://www.publickey1.jp/blog/15/html5whatwgw3c_tpac_2015.html is quite popular on Twitter, anything noteworthy? |
| 17:09 | <JakeA> | *sigh* |
| 17:14 | <Domenic> | Replied |
| 17:15 | <Domenic> | Google translate says that WHATWG is mostly mentioned in their "future of HTML" section |
| 17:16 | <zcorpan> | http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2015%2FREC-dom-20151119%2F&doc2=https%3A%2F%2Fdom.spec.whatwg.org%2F |
| 18:30 | <zcorpan> | annevk: see https://code.google.com/p/chromium/issues/detail?id=324922#c6 for why i dislike quirks mode test cases :-) |
| 18:41 | <JonathanNeal> | Anyone here good at math? I am trying to calculate things like cover and contain in JavaScript. |
| 18:58 | <boogyman> | JonathanNeal: did you get a more authoritative opinion to your question about font shorthand notation? |
| 18:59 | <JonathanNeal> | boogyman, yes. You can read the thread here: https://twitter.com/tabatkins/status/669384360903073792 |
| 19:00 | <boogyman> | ah, so I wasn't too far off |
| 19:01 | <boogyman> | good to know, thanks. |
| 19:10 | <JonathanNeal> | I used to know how to do the math. Something about getting the aspect ratios, min/max, produce result. |
| 19:33 | <zcorpan> | JonathanNeal: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3766 ? (the centering can probably be done in better ways, and maybe the other thing also) |
| 19:52 | <JonathanNeal> | zcorpan: thanks, I’ll review that. |
| 20:04 | <smaug____> | is there some "process" to backout spec changes |
| 20:04 | <smaug____> | I mean in those cases when a change was either clearly wrong or controversial, it probably should be backed out sooner than later |
| 20:05 | <Domenic> | No process, what do you think this is :P. Submit a PR or open an issue requesting an editor does it? |
| 20:08 | <smaug____> | I was kind of hoping some nice tool where one could easily backout changes :) |
| 20:08 | <smaug____> | not sure who should have rights to use such tool |
| 20:09 | <smaug____> | (tokenlist.add changes just came to my mind) |
| 20:10 | <Domenic> | Yeah, I mean, `git revert` is a pretty good approximation of that tool |
| 20:17 | <gsnedders> | jgraham: so yeah, I want to html5lib-python#198 asap given it allows us to get up-to-date with tests with no failures |
| 20:18 | <smaug____> | "navigation context" isn't any real spec thing, right? |
| 20:18 | smaug____ | tries to understand web perf wg specs |
| 20:19 | <gsnedders> | smaug____: I've certainly never heard of it! |
| 20:19 | <smaug____> | bah, how does one change github issue title? |
| 20:20 | <gsnedders> | press the edit button to the left of it? |
| 20:20 | <smaug____> | doesn't work |
| 20:20 | <gsnedders> | hmm, wfm |