| 00:14 | <hober> | jgraham: it's important to have something to watch while eating your popcorn |
| 00:31 | <Hixie> | if you're that hard up on entertainment, i'm pretty sure we can help you out |
| 02:05 | <hober> | 3 hours left on the polyglot poll |
| 04:03 | <TabAtkins> | What's the url for the polyglot poll? |
| 04:03 | <TabAtkins> | Since there's an hour left, I suppose. |
| 04:42 | <MikeSmith> | TabAtkins: https://www.w3.org/2002/09/wbs/40318/polyglot-status-preference-poll/ |
| 04:42 | <zewt> | is "polyglot" what you name something when you want nobody to have any idea what the heck it is |
| 04:43 | <zewt> | sounds like what you'd call a low-resolution 3d rendering of the results of a sneeze |
| 04:46 | <TabAtkins> | Oh, right, I got kicked out of HTMLWG and never got put back in, because TV was being petty and then just forgot. |
| 04:46 | <TabAtkins> | Welp. |
| 04:56 | <MikeSmith> | I find http://krijnhoetmer.nl/irc-logs/whatwg/20131210#l-769 from tantek and I see he's asking why the validator reports rel=syndication as an error even thought it's listed in the microformats wiki, but I don't know why he said "and similarly for" |
| 05:31 | <Hixie> | TabAtkins: you lucky bastard |
| 05:32 | <TabAtkins> | Hixie: Hehehe |
| 06:19 | <MikeSmith> | so there are now 263 meta@name values listed at http://wiki.whatwg.org/wiki/MetaExtensions#Registered_Extensions |
| 06:20 | <MikeSmith> | the validator code only knows about only 145 at this point |
| 06:20 | <MikeSmith> | and I already thought that was excessive |
| 06:22 | <MikeSmith> | compare that to 56 link@rel values the code know about |
| 06:38 | <TabAtkins> | Hixie: You pinged me about maybe needing new selectors? |
| 07:25 | <MikeSmith> | Hixie: I'm trying to make sure I understand the expected results for http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/001.html and the steps the UA takes to get there. |
| 07:25 | <MikeSmith> | I'll paste in what I think the steps are |
| 07:25 | <MikeSmith> | 1. The iframe finishes loading for the first time, with its contentDocument.location.href set to http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/inner-address/inner.html and its contentDocument.baseURI set to "http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/inner-base/";. |
| 07:26 | <MikeSmith> | 2. The 001.html parent document finishes loading, and `frames[0].location = 'javascript:location.assign("test.txt")'` gets called. |
| 07:26 | <MikeSmith> | 3. The determine the new URL for the iframe, "test.txt" is resolved relative to the iframe's baseURI. |
| 07:26 | <MikeSmith> | 4. So the iframe is reloaded with its contentDocument.location.href set to "http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/inner-base/test.txt"; |
| 07:26 | <MikeSmith> | *3. To determine the new URL... |
| 07:36 | <MikeSmith> | jgraham: how do I make wptserve serve a particular text file with a "Content-Type: text/plain; charset=utf-8" header, instead of with just "Content-Type: text/plain"? |
| 08:03 | <zcorpan> | why are shared workers being moved/removed? |
| 08:05 | <zcorpan> | http://krijnhoetmer.nl/irc-logs/webapps/20131112#l-661 ... sounds like "nobody has run the tests." "let's remove the spec." |
| 08:12 | <MikeSmith> | wtf |
| 08:12 | <MikeSmith> | I don't remember that happening |
| 08:14 | <MikeSmith> | that means just for the CR draft? |
| 08:14 | <MikeSmith> | so they're now going to maintain a separate other draft? |
| 08:20 | <MikeSmith> | Hixie: I don't understand how in onload="frames[0].location = 'javascript:location.assign("test.txt")'" setting the location attribute to some value actually has any effect |
| 08:21 | <MikeSmith> | since, first off, it's defined as readonly |
| 08:22 | <zcorpan> | MikeSmith: it's [PutForwards=href] |
| 08:22 | <MikeSmith> | aha |
| 08:23 | <MikeSmith> | I have no idea what PutForwards means. I guess I need to read the WebIDL spec |
| 08:23 | <zcorpan> | it means it's actually setting location.href |
| 08:23 | <MikeSmith> | I see |
| 08:25 | <MikeSmith> | zcorpan: so why does the PutForwards mechansim exist? for backward compatiblity or convenience? |
| 08:25 | <zcorpan> | MikeSmith: both |
| 08:26 | <MikeSmith> | ok |
| 08:26 | <zcorpan> | MikeSmith: for location it's backcompat, but we also added it to elm.style (and other .style in cssom) for convenience |
| 08:27 | <MikeSmith> | OK, that makes sense I guess |
| 08:28 | <zcorpan> | so the lesson with the workers thing is that "all tests must pass" CR exit critiera sets terrible incentives |
| 08:29 | <zcorpan> | but we knew that already |
| 08:30 | <zcorpan> | i wonder why we keep repeating the same mistakes |
| 09:19 | <MikeSmith> | zcorpan: because get tired of fighting |
| 09:22 | <MikeSmith> | tired of having to restate what should already be obvious, and then getting explanations back that are really just rationalizations that get more an more convoluted each time |
| 09:31 | <MikeSmith> | zcorpan: so now I'm curious what literal "PutForwards=value" means, with literal "value" (which is not an actual attribute name for any attribute of the object) |
| 09:31 | <MikeSmith> | WebIDL doesn't seem to explain that |
| 09:31 | <MikeSmith> | or it does and I'm missing something |
| 09:34 | <MikeSmith> | like at http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#htmllinkelement |
| 09:34 | <MikeSmith> | [PutForwards=value] readonly attribute DOMSettableTokenList sizes; |
| 10:50 | <Ms2ger> | MikeSmith, DOMSettableTokenList has a value attribute |
| 10:50 | <MikeSmith> | ah ok |
| 10:51 | <Ms2ger> | zcorpan, sounds like webapps is being productive again |
| 10:55 | <jgraham> | zcorpan: AIUI the motivation was that there was only one actively maintained implementation of sharedworkers (assuming presto doesn't count), so if you want IPR protection for workers it makes sense to remove shared workers temporarily, push dedicated workers alone to rec. and then do shared workers once more people implement it |
| 10:56 | <jgraham> | It certainly isn't work that I would bother doing, but it's rather hard to object to Microsoft doing the work to achieve a goal that they care about more than everyone else |
| 10:56 | <jgraham> | Of course if Mozilla have landed a half-decent shared worker implementation, that changes things a lot |
| 10:58 | <jgraham> | (although I have argued that getting 100% of tests passing shouldn't be on the critical path for Rec. it does make some sense that you can't make it to Rec. if there is only a single serious attempt at implementing something) |
| 11:04 | <zcorpan> | jgraham: ok. though i don't follow why presto doesn't count |
| 11:06 | <jgraham> | I think possibly only because no one had actually done the work to run the tests in presto |
| 11:06 | <jgraham> | I suppose it also depends on what you think that the point of requiring testing at all is |
| 11:08 | <jgraham> | In terms of interop, presto isn't that important anymore (sadly). In terms of proving the spec is implementable it seems as valid as ever |
| 11:20 | <zcorpan> | has anyone run the tests anywhere? |
| 11:20 | <zcorpan> | why isn't presto important anymore? |
| 11:22 | <jgraham> | Because it isn't part of any mass-market product under active development that is primarily designed to interact with open web content |
| 11:23 | <Ms2ger> | "It works OK in Chrome. #FiveWordTechHorrors" |
| 11:23 | <jgraham> | zcorpan: I thought someone had, but now all I can find is http://www.w3.org/wiki/Webapps/Interop/WebWorkers which suggests that you signed up to run the tests |
| 11:24 | <zcorpan> | jgraham: i signed up for being test facilitator, that's different |
| 11:25 | <jgraham> | zcorpan: Not sure that Art thinks it is :) |
| 11:25 | <Ms2ger> | Oh, better, from heycam: "WG Decision on Polyglot Note #FiveWordTechHorrors" |
| 11:31 | <MikeSmith> | heh |
| 11:32 | <zcorpan> | i thought ie implemented SharedWorker? http://www.browserstack.com/screenshots/2e164dbe58d4ffcbea245a487284966ff9f3243b suggests not |
| 11:34 | <jgraham> | I guess Microsoft wouldn't want to drop the spec if they did |
| 11:34 | <zcorpan> | they have written tests and provided spec feedback on shared worker, iirc |
| 11:35 | <jgraham> | Maybe it got dropped from IE11 |
| 11:36 | zcorpan | finds http://blogs.msdn.com/b/ie/archive/2011/07/01/web-workers-in-ie10-background-javascript-makes-web-apps-faster.aspx |
| 11:37 | <zcorpan> | their concern was addressed (see first step in the constructor) |
| 12:03 | <annevk> | "This is important for content-management scenarios." lol |
| 12:04 | <annevk> | hober: looks like Apple voted in block too! |
| 12:24 | <MikeSmith> | annevk: yeah indeed they sure showed up in force |
| 12:26 | <MikeSmith> | if anybody had taken time to much real lobbying the vote would have easily gone the other way |
| 12:26 | <MikeSmith> | but oh well |
| 12:34 | <SteveF> | MikeSmith: I concur |
| 12:36 | <MikeSmith> | SteveF: yeah the Paciello block wasn't a big help here either.. |
| 12:37 | <SteveF> | less a block more of a unit |
| 12:38 | <MikeSmith> | anyway as Jesus said during the sermon on Mt. Jerusalem, "What done, it be done." |
| 12:41 | <darobin> | MikeSmith++ |
| 12:41 | <darobin> | I reckon that the fact that no one bothered to carry out any serious lobbying pretty much speaks for itself, but maybe that's just me |
| 12:46 | <MikeSmith> | each care bear carries only some much care essence and he has to spend his care essence wisely |
| 12:49 | <MikeSmith> | spending, say, five years of care essence on trying to get past the stonewall the W3C has built up against document-license fairness can suck a lot of care essence out of anybody |
| 12:56 | <zcorpan> | it seems importScripts doesn't do anything in browsers if called in an event handler or so |
| 12:58 | darobin | looks for some care essence to hand over to MikeSmith, seems to be out again |
| 12:58 | <zcorpan> | Hixie: is importScripts intended to always work, or just in the initial run? |
| 12:59 | <darobin> | SteveF: seems that someone's finally noticed https://twitter.com/stowball/status/410724374811910146/photo/1 |
| 13:00 | <SteveF> | darobin: yeah saw that |
| 13:04 | <darobin> | "America Cares Bear (2003) is a happy, patriotic, and energetic bear" — bah, even the care bears have gone to shit |
| 13:07 | <MikeSmith> | Ms2ger: heh |
| 13:07 | <Ms2ger> | ? |
| 13:11 | <MikeSmith> | oops |
| 13:12 | <MikeSmith> | sorry, I had started by planning to ask you if I filed a Mozilla bug about http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/001.html which component should I file it against |
| 13:14 | <Ms2ger> | core::dom, I guess |
| 13:14 | <MikeSmith> | I think the bug is that the baseURI of the iframe document is ignored when calling location.assign("foo.txt") |
| 13:14 | <MikeSmith> | Ok |
| 13:15 | <MikeSmith> | not sure if I that's really the bug or not |
| 13:16 | <MikeSmith> | mostly I wanted to file the bug just so others would have to read through the spec and try to figure out where the spec says exactly what should happen, so then I could know too |
| 13:17 | <MikeSmith> | btw related to that I'm trying to figure out what case Hixie means when he says, 'Chrome/Safari never give a page a URL starting with the "javascript:" scheme' |
| 13:17 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=13720#c20 |
| 13:18 | <MikeSmith> | but I guess I can just ask him when he's back |
| 13:19 | <zcorpan> | MikeSmith: it's not resolved against the iframe's document's baseURI, it's resolved against the API base URL of the entry settings object |
| 13:20 | <zcorpan> | MikeSmith: so i think it depends on which script is calling assign |
| 13:20 | <MikeSmith> | oh |
| 13:20 | <MikeSmith> | hmm, that complicates things |
| 13:22 | <zcorpan> | why? |
| 13:23 | <annevk> | zcorpan: no special provisions for importScripts in the spec |
| 13:24 | <jgraham> | darobin: I think it should be taken as an indication that almost everyone has disangaged with the HTMLWG, not as anything related to polyglot in specific |
| 13:25 | <zcorpan> | annevk: right |
| 13:25 | <jgraham> | That is, I think the vote (the fact that it happened, the pattern of the results, the actual outcome) are all warning signs that the W3C should heed |
| 13:25 | <darobin> | jgraham: wait — the HTMLWG still exists? |
| 13:26 | <annevk> | What's this W3C thing I keep hearing about? Sounds like a nasty place |
| 13:27 | <MikeSmith> | zcorpan: I meant because what you said would seem to indicate that I probably should add another test or tests for different assign cases. |
| 13:33 | <MikeSmith> | annevk: "nasty" makes it sounds more exciting than it is |
| 13:34 | <annevk> | heh |
| 13:34 | <zcorpan> | MikeSmith: there's always reason to test different cases :-) |
| 13:40 | <MikeSmith> | zcorpan: sure, but it conflicts with my "maximum grade, minimum effort" life/professional philosophy |
| 13:43 | <MikeSmith> | zcorpan: anyway, while we're on the subject of me creating additional work for myself, it's been proposed to me that we add a new validator Preset schema-selection option "Automatically by doctype" |
| 13:44 | <MikeSmith> | so I wanted to ask what you and hsivonen think of that |
| 13:44 | <zcorpan> | MikeSmith: so basically the user can opt-in to the old behavior? |
| 13:44 | <MikeSmith> | yeah |
| 13:44 | <MikeSmith> | or a third-party app that uses the REST API could |
| 13:44 | <zcorpan> | MikeSmith: would it do nothing in xml? |
| 13:45 | <MikeSmith> | no, it would do something in xml too |
| 13:45 | <MikeSmith> | why would you think it would not? |
| 13:45 | <zcorpan> | currently in xml it ignores the doctype and chooses schema based on the root element's namespace |
| 13:46 | <MikeSmith> | right, true |
| 13:46 | <MikeSmith> | and we could keep that as the default |
| 13:46 | <MikeSmith> | that is chooses the XHTML5 schema for html-namespace docs |
| 13:47 | <zcorpan> | who is asking for this? and why? |
| 13:48 | <MikeSmith> | the people in the W3C team working on the Validator Suite |
| 13:48 | <MikeSmith> | because for some reason they seem to be convinced that would be better for their users |
| 13:49 | <MikeSmith> | and I have run out of care essence to spend trying to convince them otherwise |
| 13:50 | <zcorpan> | ok |
| 13:51 | <MikeSmith> | anyway yeah it would require me to write some new code for the xml-parsing path that sniffs the doctype (in addition to the existing namespace sniffing) |
| 13:51 | <annevk> | MikeSmith: are they making these feature requests on www-validator⊙wo? |
| 13:52 | <annevk> | MikeSmith: if not, I recommend requiring all requests to be public so they can be scrutinized by the public |
| 13:52 | <MikeSmith> | annevk: no that one came from IRC discussion |
| 13:53 | <MikeSmith> | annevk: yeah that'd be better |
| 13:53 | <zcorpan> | MikeSmith: has anyone asked for doctype sniffing in xml specifically? |
| 13:54 | <MikeSmith> | no, but the use-case doesn't seem unreasonable to me on the face of it |
| 13:54 | <zcorpan> | MikeSmith: https://hsivonen.fi/doctype/#xml |
| 13:55 | MikeSmith | reads |
| 13:58 | <darobin> | zcorpan: I'm not sure that that otherwise good text from hsivonen applies to this case |
| 13:58 | <darobin> | I mean, you clearly shouldn't dispatch to an SVG or an HTML renderer based on the DOCTYPE |
| 13:59 | <darobin> | but for validation it *could* make sense to decide, say, between using the XHTML 1.0 or 1.1 schema based on that |
| 13:59 | <darobin> | not that I would ever care, but, you know, if that's what you're doing it seems relatively sensible |
| 13:59 | <annevk> | Validation should be against latest version with warnings for unsupported features |
| 13:59 | <annevk> | It shouldn't be about schemas published in specs |
| 13:59 | <darobin> | well that's what I initially suggested |
| 14:00 | <MikeSmith> | yeah, that's what the default is in teh validator |
| 14:00 | <darobin> | I just think there were some concerns about things being acceptable in XHTML 1.something that weren't anymore |
| 14:00 | <darobin> | annevk: anyway, you're preaching to the choir here baby :) |
| 14:01 | darobin | doesn't ever use validation for that matter |
| 14:01 | darobin | points MikeSmith to his inbox, hopes that gives him a bit of care bear essence back |
| 14:02 | <annevk> | Again, I recommend requiring W3C internal to make public requests |
| 14:02 | <annevk> | Either via bug reports or www-validator |
| 14:02 | <annevk> | No need for this to be Team-only |
| 14:03 | <darobin> | yeah, I don't think that this is meant to be team-only, as far as I've been involved it's just stuff that came up live and informally at TPAC |
| 14:03 | <MikeSmith> | right |
| 14:04 | <MikeSmith> | anyway yeah I'll suggest we take it to www-validator at this point |
| 14:06 | <MikeSmith> | honestly though part of the downwise of that is I also get the people chiming in who think, say, polyglot is a good idea and this would make a nice companion piece to that |
| 14:10 | <MikeSmith> | and then my teammates would have further evidence to assert, See, somebody else wants it too |
| 14:11 | <annevk> | @mattur <3 |
| 14:13 | <jgraham> | heh |
| 14:15 | hsivonen | wrote https://hsivonen.fi/doctype/#xml before writing a line of code for the validator |
| 14:15 | <hsivonen> | pre-emptively arguing against future bogosities |
| 14:16 | <MikeSmith> | heh |
| 14:16 | <MikeSmith> | hsivonen is secretly the "This is the year 2014" guy |
| 14:17 | <hsivonen> | I don't know who that is |
| 14:17 | <MikeSmith> | hsivonen: the message about <center> on public-html |
| 14:17 | <MikeSmith> | he started his message with "This is the year 2014" or something close to that |
| 14:17 | <hsivonen> | but pro tip: cite W. Eliot Kimber when you need a more-SGML-than-thou argument to support your position |
| 14:18 | <hsivonen> | MikeSmith: I see |
| 14:20 | <MikeSmith> | hsivonen: yeah for markup-related stuff the argument "It's such an enormously bad idea that even W. Eliot Kimber agrees we shouldn't do it" is a pretty good line of argument |
| 14:21 | <MikeSmith> | not that Eliot's a fool, it's just that he's not known for preferring simple solutions |
| 14:21 | <darobin> | hahaha |
| 14:34 | <MikeSmith> | hsivonen: so you think adding a "Automatically by doctype" schema-selection Preset option is enough of a really bad idea that we shouldn't add it? |
| 14:34 | <MikeSmith> | if so and zcorpan figures the same, then I feel confident going back and just saying No |
| 14:34 | <hsivonen> | MikeSmith: I'm inclined to think so based on the text/html experience |
| 14:35 | <MikeSmith> | OK |
| 14:37 | <MikeSmith> | so I'll decline and suggest they take it to www-validator for public discussion if they want a second opinion |
| 15:32 | <jgraham> | Ms2ger: https://critic.hoppipolla.co.uk/showcomment?chain=879 <- are you happy with that> |
| 15:32 | <jgraham> | s/>/?/ |
| 15:34 | <Ms2ger> | wfm, I guess |
| 15:36 | <jgraham> | Ms2ger: Thanks |
| 15:37 | <jgraham> | So just a bunch of reviewing to do and a couple of issues for hallvord |
| 15:39 | <Ms2ger> | Where's hallvord when you need him :) |
| 15:40 | <jgraham> | I was actually wondering just the same thing :) |
| 16:59 | <annevk> | The standard is fully interoperable. #FiveWordTechHorrors |
| 17:02 | <Hixie> | looking for feedback on https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475 which is a proposal for redefining the concept of "focus" in HTML |
| 17:03 | <Hixie> | TabAtkins: ^ mentions a new selector |
| 17:03 | <Hixie> | MikeSmith: around now if you want to talk about those jsurl tests |
| 17:04 | <jgraham> | annevk: "We consider the testsuite complete", perhaps? |
| 17:04 | <annevk> | :-) |
| 17:04 | <annevk> | jgraham: you can join twitter now |
| 17:04 | <gsnedders> | "Only ECMA Members submit tests" |
| 17:04 | <jgraham> | Yep that works too :p |
| 17:05 | <jgraham> | annevk: ^ |
| 17:05 | <annevk> | hahaha |
| 17:05 | <annevk> | Ecma* |
| 17:05 | <annevk> | please tweet that gsnedders |
| 17:05 | <gsnedders> | *members |
| 17:07 | <gsnedders> | annevk: Okay, okay, done. |
| 17:16 | <annevk> | hsivonen: are we measuring which encodings are used on the web? Would be useful for https://bugzilla.mozilla.org/show_bug.cgi?id=912466 |
| 17:18 | <jgraham> | (I think the real open web platform five word tech horror is "wanted: spec for hit testing") |
| 17:19 | <Hixie> | MikeSmith: what i meant in https://www.w3.org/Bugs/Public/show_bug.cgi?id=13720#c20 is demonstrated by http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2688 |
| 17:19 | <Hixie> | annevk: "we proved interop without tests" |
| 17:20 | <jgraham> | heh |
| 17:20 | <jgraham> | Or really not |
| 17:20 | <jgraham> | Too true to be actually funny :| |
| 17:20 | <annevk> | it's sad because it's true? |
| 17:21 | <Hixie> | i thought we were going for horror, not funny :-) |
| 17:23 | <jgraham> | Well yes, but my reaction wasn't quite right :) |
| 18:12 | <matjas> | some emoji, like “🇺🇸” ('\u{1F1FA}\u{1F1F8}') consist of multiple Unicode code points. is it possible to match these using CSS `unicode-range`? |
| 18:12 | <matjas> | (use case from https://medium.com/p/179cfd8238ac) |
| 18:13 | <MikeSmith> | Hixie: thanks for the live dom viewer link. I see what you're talking about now (Firefox sets the location.href to "javascript:'test'" as expected but Chrome sets it to "about:blank") |
| 18:13 | <Hixie> | the spec sets it to about:blank too |
| 18:14 | <MikeSmith> | oh |
| 18:14 | <Hixie> | the problem with setting it to javascript: anything, aside from it just being scary, is that it makes it hard to figure out what the url resolution algorithms should do |
| 18:14 | <MikeSmith> | ah OK |
| 18:14 | <MikeSmith> | I thought you were sayign something different in the bug |
| 18:14 | MikeSmith | re-reads |
| 18:15 | <annevk> | matjas: U+1F1F* or U+F1FA, U+1F1F8 |
| 18:15 | <Hixie> | e.g. should href="//%0Aalert(cookie)" alert? |
| 18:15 | <Hixie> | basically we're trying to move javascript: out of the web as much as possible |
| 18:15 | <Hixie> | so e.g. it's out of the fetch algorithm and just down into navigation now |
| 18:16 | <MikeSmith> | ok |
| 18:16 | <MikeSmith> | I see now that's the title of the bug |
| 18:16 | <matjas> | annevk: wouldn’t that match them separately, too? |
| 18:16 | <MikeSmith> | "Define javascript: processing entirely inline, and make it only happen in the navigation algorithm; then, remove special-casing elsewhere, and make it non-conforming in those places" |
| 18:16 | <Hixie> | yeah |
| 18:17 | <Hixie> | come to think of it, not sure we did that last one |
| 18:17 | <matjas> | annevk: U+1F1FA U+1F1F8 is a single glyph, but each of them is a valid separate glyph too |
| 18:17 | <Hixie> | annevk: what's the story on conformance of schemes? |
| 18:17 | <MikeSmith> | heh I'm and supposedly the reporter of that bug so I should suppose I should have known that was the title |
| 18:17 | <Hixie> | i change titles all the time |
| 18:17 | <Hixie> | it's probably not what you wrote originally |
| 18:17 | <Hixie> | your original title was probably something like "<select> element has a typo in paragraph 2" |
| 18:18 | <MikeSmith> | well also I didn't actually report it originally, I split it out from some other bug that somebody else reported |
| 18:18 | <Hixie> | i'm not very good about keeping bugs on topic :-P |
| 18:18 | <annevk> | Hixie: I was going to wait with that until the new registry plan |
| 18:18 | <Hixie> | annevk: ok |
| 18:18 | <Hixie> | i plan to look at that sometime soonish |
| 18:18 | <annevk> | I'm not in a rush, still need implementers to start looking at implementing the URL Standard |
| 18:19 | <annevk> | matjas: unicode-range describes what's in the font |
| 18:20 | <matjas> | so your example is how you’d use unicode-range to say, this font has a glyph for U+F1FA, one for U+1F1F8, and another one for U+F1FA immediately followed by U+1F1F8? |
| 18:21 | <annevk> | matjas: there's no way to express combining marks support in fonts |
| 18:21 | <annevk> | matjas: presumably you'd include a font that supports combining marks if you want that effect |
| 18:21 | <annevk> | I guess this is not really combining marks, there's another term... |
| 18:22 | <annevk> | ligatures |
| 18:22 | <matjas> | right, it sounds like a ligature |
| 18:24 | <MikeSmith> | Hixie: so I'm still not clear though on what you meant by the comment, 'Note that Firefox doesn't quite match these; in particular, the spec, the tests, and Chrome/Safari never give a page a URL starting with the "javascript:" scheme.a' |
| 18:24 | <annevk> | yeah, there's no way for selecting a font that has an ffi ligature over one that hasn't either |
| 18:24 | <annevk> | doesn't seem like a big deal |
| 18:25 | <Hixie> | MikeSmith: i mean that "the document's address" in the spec, the tests, and Chrome/Safari is never a URL that starts with "javascript:" |
| 18:25 | <matjas> | annevk: well i liked mroth’s use case |
| 18:26 | <matjas> | (search for “standard CSS unicode-range” on the page i linked to before) |
| 18:26 | <annevk> | "double-byte Unicode characters" o_O |
| 18:28 | <annevk> | matjas: I don't understand why giving the range for those code points would not select the proper font and apply the ligature |
| 18:28 | <MikeSmith> | Hixie: ah OK, yeah, that's clear. For some reason I wasn't parsing the sentence right when I was reading it bugzilla |
| 18:28 | <matjas> | yeah he got some terms mixed up |
| 18:28 | <matjas> | hmm, good point |
| 18:29 | <annevk> | matjas: oh god, conflating DOM perf and rendering perf now |
| 18:29 | <annevk> | rewrite jQuery in pure JavaScript? maha |
| 18:30 | <gsnedders> | Hey, my site nowadays just uses <canvas>, and I implement CSS in JS! |
| 18:31 | <matjas> | annevk: wat. where do you see this? |
| 18:31 | <matjas> | ah, same page, hah |
| 18:31 | <annevk> | matjas: tracker looks cool though |
| 18:32 | <annevk> | matjas: was the use case showing the emoji stuff cross-platform? |
| 18:32 | <matjas> | no, he made something different for that: http://emojistatic.github.io/ |
| 18:33 | <matjas> | annevk: the use case was getting emoji to display in the colored AppleEmoji font rather than in a regular black/white fallback font where possible (i.e. on systems) |
| 18:34 | <matjas> | iiuc |
| 18:34 | <annevk> | that should happen automatically really |
| 18:34 | <matjas> | yeah, but browsers suck |
| 18:35 | <annevk> | so for that you're asking for a new feature for unicode-range that might not even be needed there? |
| 18:35 | <annevk> | you're not going to fix browsers by adding more features |
| 18:35 | <annevk> | that's standards 101 |
| 18:37 | <matjas> | not asking for it, just wondering what the answer to mroth’s question one, as i had no idea :) |
| 18:38 | <matjas> | thanks for clarifying |
| 18:41 | <annevk> | nw |
| 18:42 | <annevk> | matjas: that article has some serious terminology issues |
| 18:42 | <annevk> | matjas: as well as incorrect assumptions |
| 18:42 | <annevk> | "(since after all, this was the problem that Unicode was supposed to solve to begin with)" |
| 18:43 | <annevk> | even if that was goal, that was abandoned by Unicode 2 and I suspect combining marks were a thing before that |
| 18:51 | <MikeSmith> | Hixie: about http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/001.html here's my latest attempt at trying to write out the steps so that I can understand what's supposed to be the expected result and why |
| 18:51 | <MikeSmith> | 1. The UA finishes loading loading the iframe for the first time, with the iframe's contentDocument.location.href set to http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/inner-address/inner.html and the iframe's contentDocument.baseURI set to "http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/inner-base/";. |
| 18:52 | <MikeSmith> | 2. The UA finishes loading 001.html and calls `frames[0].location = 'javascript:location.assign("test.txt")'`. |
| 18:52 | <MikeSmith> | 3. The API base URL specified by the entry settings object is the base URL of iframe's document (which is the responsible document specified by the entry settings object); that is, the API base URL is "http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/inner-base/";. |
| 18:52 | <MikeSmith> | 4. So the UA resolves location.assign("test.txt") relative to "http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/inner-base/";, and the UA reloads the iframe with its contentDocument.location.href set to "http://www.hixie.ch/tests/adhoc/html/navigation/javascript-url/inner-base/test.txt"; |
| 19:15 | <Hixie> | MikeSmith: sounds right |
| 19:16 | <Hixie> | MikeSmith: between steps 2 and 3 are some interesting substeps involving navigating and creating a new script and running it, which matters for step 3, since the script in step 2 has an API base URL of blabla-outer. |
| 21:48 | <Hixie> | GPHemsley: yt? |
| 21:56 | <GPHemsley> | Hixie: Sup? |
| 21:57 | <Hixie> | GPHemsley: i just posted a question on some bug or other. i was wondering what the state of mimesniff was. |
| 21:58 | <GPHemsley> | Hixie: You want the answer here or in the bug? |
| 21:58 | <Hixie> | here's fine |
| 21:58 | <Hixie> | (i'm looking into the issue of video sniffing) |
| 21:59 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=11984 was the bug |
| 21:59 | <GPHemsley> | Lack of interest = lack of progress; I have one issue to fix for bz and one issue to investigate for GNOME's libsoup; everything else is TBD |
| 22:00 | <Hixie> | not getting traction in terms of browsers implementing just the prescribed set of sniffing rules? |
| 22:00 | <Hixie> | or? |
| 22:00 | <GPHemsley> | yeah, that's part of it |
| 22:00 | <GPHemsley> | another part is that much of it already matches what browsers do, I think |
| 22:01 | <GPHemsley> | and another part is that one browser wants to do one thing and another browser wants to do another thing, and neither wants to change |
| 22:01 | <Hixie> | that's good |
| 22:01 | <Hixie> | that's bad |
| 22:01 | <GPHemsley> | another part is deferring to you for various parts |
| 22:02 | <GPHemsley> | and another part is lack of time/desire to investigate browser behavior |
| 22:02 | <GPHemsley> | so it's a multi-faceted problem |
| 22:02 | <GPHemsley> | but generally speaking, no one has expressed anything to me in a while regarding mimesniff |
| 22:02 | <GPHemsley> | so I've worried about other things instead |
| 22:02 | <Hixie> | fair enough |
| 22:03 | <Hixie> | well we should probably tidy up the stuff that is implemented (whether by everyone or just by some), at least |
| 22:03 | <GPHemsley> | but apparently GNOME's libsoup is being rewritten, so I've gotten a bit of contact the last few days |
| 22:03 | <GPHemsley> | yeah |
| 22:03 | <Hixie> | HTML is definitely relying on this spec, fwiw |
| 22:04 | <GPHemsley> | another thing was waiting on Ms2ger to update anolis to maintain attribute order in its output... >_> |
| 22:04 | karlcow | wonders why HTTP response headers have never been accessible through JS apart of document.referrer |
| 22:05 | <matjas> | karlcow: node.js, though </trollbait> |
| 22:06 | <karlcow> | :) |
| 22:06 | <karlcow> | blame marcos and annevk discussions about "Link" and CSS. I was thinking so many issues could have been taken care of through polyfill and scripts. |