| 00:34 | <TabAtkins> | marcosc_: Good response. ^_^ |
| 00:42 | <marcosc_> | TabAtkins: thanks :) |
| 05:47 | <hsivonen> | dear lazy IRC, have non-Gecko engines already implemented the fragment parsing fixes for SVG and MathML contexts? |
| 06:09 | <annevk> | JakeA: it seems we might implement Notification.getClones() as Notification.get() so the getClones() name is not final at all |
| 06:10 | <annevk> | hsivonen: .<script>document.body.innerHTML = "<svg></svg>";w(document.body.firstChild.namespaceURI)</script> in Live DOM Viewer suggests Chrome does |
| 06:11 | <JakeA> | annevk: cool, I don't think it needs "clones" in the name. I'm assuming .get() still returns a sequence? |
| 06:12 | <annevk> | hsivonen: IE10 does too |
| 06:12 | <annevk> | JakeA: a promise for an array |
| 06:12 | <zcorpan> | annevk: you need svg.innerHTML |
| 06:12 | <annevk> | zcorpan: oops |
| 06:13 | <annevk> | <svg></svg><script>document.body.firstChild.innerHTML = "<rect>";w(document.body.firstChild.firstChild.namespaceURI)</script> |
| 06:13 | <annevk> | Chrome still does, IE10 does not |
| 06:15 | <JakeA> | annevk: cool. I think we'll still go with getAll, means we can introduce a singular later if needed |
| 06:25 | <MikeSmith> | hsivonen: If you could comment over at https://www.w3.org/Bugs/Public/show_bug.cgi?id=21818#c8 as well I'd appreciate it. (I hope to get that change reverted.) |
| 06:37 | <othermaciej> | MikeSmith: what’s the problem with it? |
| 06:37 | <othermaciej> | is the http-equiv version valid in non-XML? |
| 06:38 | <othermaciej> | it seems like it is |
| 06:38 | MikeSmith | looks back at the bug |
| 06:39 | <othermaciej> | Leif’s arguments seem kinda reasonable - if the http-equiv form is allowed in HTML, and the charset= form is allowed in XML for compatibility, and the http-equiv form works in at least a few more places, it seems reasonable (to me) to allow the http-equiv form in XML for compatibility as well |
| 06:42 | <MikeSmith> | othermaciej: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> is still valid for text/html files but only to allow for legacy content that still has it |
| 06:42 | <MikeSmith> | the logic is, we don't want to further proliferate it |
| 06:43 | <othermaciej> | any form of charset declaration in XML is also presumably for some legacy-related reason |
| 06:44 | <MikeSmith> | well the charset= form is the best-practice form from text/html and it's allowed in XML just as a nod to "ease migration" or however Hixie_ worded it |
| 06:45 | <othermaciej> | migration in which direction? :-p |
| 06:45 | <MikeSmith> | it's certinaly not there to encourage people to attempt to do the polyglot thing |
| 06:45 | <MikeSmith> | yeah, true about migration in which direction |
| 06:46 | <MikeSmith> | I think we should just not make it it all any more ugly than it already is |
| 06:47 | <MikeSmith> | the only use case that's been put forward for <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" /> is polyglot |
| 06:48 | <MikeSmith> | othermaciej: anyway as usual hsivonen says it better than me https://www.w3.org/Bugs/Public/show_bug.cgi?id=21818#c10 |
| 06:49 | <zcorpan> | <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" /> doesn't help anything for polyglot |
| 06:50 | <zcorpan> | if anything it probably has worse compat |
| 06:50 | <annevk> | Polyglot is not dead yet? |
| 06:50 | <annevk> | o_O |
| 06:59 | <SamB> | annevk: you mean besides among those who just didn't get the memo yet? |
| 07:03 | <MikeSmith> | zcorpan: true but I guess somewhere in the tangle of words in the description and comments in that bug advocating for it, there's some discernable rationale of why he believes it's helpful for polyglot |
| 07:05 | <zcorpan> | wait, <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" /> is not allowed. <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> is allowed |
| 07:06 | <zcorpan> | i thought you were discussing the +xml vs text/html part |
| 07:08 | <zcorpan> | Hixie_: why is https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533 more messy for img? img already has crossorigin |
| 07:08 | <annevk> | I wonder what the pay off is in investing such large amounts of time in something that is ultimately useless |
| 07:08 | <annevk> | zcorpan: because you do multiple fetches |
| 07:10 | <zcorpan> | maybe this is a good time to test whether other elements also do multiple fetches in browsers |
| 07:12 | <annevk> | zcorpan: well there's that, but I mostly meant with <picture> |
| 07:13 | <annevk> | zcorpan: that will require multiple Request objects to be exposed |
| 07:13 | <annevk> | zcorpan: I can imagine you might different settings per alternative |
| 07:13 | <zcorpan> | annevk: right now <img crossorigin> is applied for all candidates |
| 07:14 | <zcorpan> | annevk: like <video crossorigin> (which also affects <track>) |
| 07:14 | <zcorpan> | annevk: what options are there? |
| 07:14 | <annevk> | zcorpan: sure, but we're discussing something more open-ended for control over headers and such |
| 07:15 | <annevk> | zcorpan: and allows setting priority per fetch-channel |
| 07:15 | <zcorpan> | annevk: when would you want different settings for different candidates? |
| 07:58 | <galaxyAbstractor> | Hey, I've looked around on the whatwg site for a bit, maybe I'm blind, but is there somewhere where one can read old versions of standards? https://bugzilla.mozilla.org/show_bug.cgi?id=422526 mentions when globalStorage was removed and replaced by localStorage, and I would like to read more about the standard that was globalStorage, since I'm doing some research on various standards |
| 07:59 | <hendry> | galaxyAbstractor: guess you could checkout http://svn.whatwg.org/webapps/ ? |
| 08:00 | <galaxyAbstractor> | hendry: ah, thanks, I didn't know that existed, I'll take a look at that |
| 08:00 | <jgraham> | You might be better off with https://github.com/whatwg/html-mirror |
| 08:00 | <jgraham> | Same thing but mirrored into git |
| 08:01 | <zcorpan> | galaxyAbstractor: also http://platform.html5.org/history/ |
| 08:02 | <zcorpan> | MikeSmith: time to add some stuff to that? |
| 08:02 | <annevk> | zcorpan: not sure, but I don't want to preclude things at the low level |
| 08:02 | <galaxyAbstractor> | jgraham: zcorpan: Thanks |
| 08:02 | <annevk> | zcorpan: I could imagine you'd use the same URL for all candidates and vary based on a header |
| 08:03 | <zcorpan> | annevk: that's ClientHints and was rejected because conneg |
| 08:03 | <MikeSmith> | zcorpan: time for somebody to :-) https://github.com/whatwg/platform.html5.org/ patches welcome etc |
| 08:03 | hendry | notices https://github.com/whatwg/streams ... how is that different to a Websocket? |
| 08:04 | <MikeSmith> | completely |
| 08:04 | <annevk> | zcorpan: it was? Anyway, I don't think we should stop people from playing with it in libraries |
| 08:04 | <zcorpan> | MikeSmith: i guess that document is a possible replacement for http://html-differences.whatwg.org/#changelog |
| 08:05 | <MikeSmith> | zcorpan: yeah it could be for sure |
| 08:07 | <zcorpan> | annevk: there was a respimg f2f in paris last year and i think dbaron explained how conneg had failed in the past so then ClientHints sort of died |
| 08:07 | <foolip> | annevk: will you have time for fullscreen bugs today? |
| 08:07 | <MikeSmith> | hendry: https://whatwg.github.io/streams/#rs-intro see for example |
| 08:07 | <annevk> | foolip: I want to fix attributes first |
| 08:07 | <zcorpan> | annevk: anyway, if you use ClientHints you just use <img src> |
| 08:08 | <foolip> | annevk: ok |
| 08:08 | <annevk> | zcorpan: I meant that you'd let the browser decide but you want your server to do things based on a header |
| 08:08 | <foolip> | I'll try my own suggestions and see how it goes |
| 08:08 | <annevk> | zcorpan: not necessarily client hints |
| 08:08 | <galaxyAbstractor> | I found this: http://www.whatwg.org/specs/web-apps/2005-09-01/#client-side but that warning is kinda annoying since it's covering a large area of the screen and it doesn't seem possible to close it either :\ |
| 08:09 | <annevk> | foolip: parentDocs makes sense, the checking later seems somewhat scary since it means you can already have resized before you realize you cannot resize |
| 08:09 | <hendry> | MikeSmith: i don't get it. what's the use case? |
| 08:10 | <zcorpan> | annevk: oh. ok. why would you do that instead of varying the URL? |
| 08:10 | <annevk> | zcorpan: I don't know, but the idea of exposing Request objects for each fetch is to allow folks to figure out these things |
| 08:11 | <foolip> | annevk: you can still check before the resize, since the resize is after the "continue async" bit |
| 08:12 | <annevk> | foolip: if you are still doing a check before the resize, how is it going to be different? |
| 08:12 | <annevk> | foolip: note that it will always have to be in sync with the main thread because it's checking global state |
| 08:12 | <annevk> | foolip: or would you only check whether it's allowed? |
| 08:12 | <annevk> | I guess resizing would only happen if not already fullscreen, so the whole nesting game applies a bit less... |
| 08:13 | <foolip> | annevk: not doing it before requestFullscreen() returns means that it could take however long is needed to do the check, even if it's all done on the main thread |
| 08:13 | <MikeSmith> | hendry: the use case is to define a stream abstraction and APIs for other specs to reference that use streams |
| 08:14 | <foolip> | I don't know if the cross-process stuff is going to be a problem, that just seemed like a good place to put it in case it needs to be made more async later |
| 08:15 | <zcorpan> | annevk: it's not clear to me why it was ok for crossorigin to be so blunt to apply equally to <track> and <source> for <video> but now we need settings for each individual url |
| 08:15 | <annevk> | zcorpan: it's not clear to me that was okay, but this is lower level |
| 08:15 | <annevk> | zcorpan: this exposes the actual request |
| 08:15 | <annevk> | zcorpan: naturally each of these has its own request |
| 08:16 | <annevk> | zcorpan: for one because they have different URLs |
| 08:16 | <zcorpan> | annevk: sure, i'm fine with exposing each request |
| 08:16 | <annevk> | zcorpan: I recommend following up on one of the WHATWG threads or raising a new one and copying Ben from Facebook and the others that were interested in this |
| 08:17 | <zcorpan> | ok |
| 08:22 | <Ms2ger> | 'String(symbol) will no longer throw; symbol+"" will still throw though.' |
| 08:22 | <Ms2ger> | Wat |
| 08:27 | <annevk> | one uses valueOf the other toString() iirc |
| 08:48 | <annevk> | Browsers make no sense with attributes |
| 08:48 | <annevk> | Ms2ger: we're going to need quite a few tests to ensure interoperability for all these new methods :/ |
| 08:48 | <Ms2ger> | Yay. |
| 08:51 | <jgraham> | Can't tell if sarcastic or looking forward to demonstrating browser crazy. |
| 08:52 | <Ms2ger> | The former |
| 08:53 | <Ms2ger> | Maybe I can coerce abinader |
| 10:26 | <annevk> | there's about 21 attributes/methods to deal with attributes |
| 10:27 | <annevk> | to do get/set/remove/has |
| 10:27 | <annevk> | tears |
| 10:27 | <annevk> | many many tears |
| 10:30 | <hsivonen> | annevk: just in DOM Core? |
| 10:31 | <annevk> | hsivonen: yeah |
| 10:31 | <annevk> | hsivonen: not counting id/className/classList |
| 10:31 | <hsivonen> | annevk: :-( |
| 10:32 | <annevk> | maybe I should write a blogpost about this |
| 10:58 | <zcorpan> | do it |
| 11:29 | <zcorpan> | at least we don't have removeAttributeNodeNS. http://www.w3.org/DOM/faq.html#removeAttributeNodeNS |
| 14:34 | <Domenic> | that page is quite an interesting mirror onto how things were thought of at the time |
| 14:37 | <Domenic> | annevk: blog post++ |
| 15:13 | <annevk> | Hixie_: with the current *.spec.whatwg.org setup, can we still get TLS? |
| 15:13 | <annevk> | Hixie_: ideally TLS + HSTS |
| 15:17 | <zcorpan> | Domenic: indeed |
| 15:17 | <Domenic> | annevk: I looked into it and it's expensive, but doable |
| 15:18 | <annevk> | Would be a nice end-of-year target for WHATWG |
| 15:19 | <Domenic> | http://www.sslshopper.com/best-ssl-wildcard-certificate.html basically |
| 15:19 | <zcorpan> | we could just introduce a member fee |
| 15:19 | <jgraham> | WHATWG has end-of-year targets now? |
| 15:19 | <jgraham> | Is there also a bonus scheme? |
| 15:20 | <jgraham> | Maybe based on the number of spec that reac Rec. |
| 15:20 | <jgraham> | +h |
| 15:20 | <Ms2ger> | annevk gets all the bonus |
| 15:20 | <Domenic> | wait wrong link http://www.sslshopper.com/unified-communications-uc-ssl-certificates.html |
| 15:20 | <Domenic> | hmm last time i googled this it was less confusing |
| 15:21 | <jgraham> | Hmm, why do you need unified not wildcard? |
| 15:23 | <jgraham> | https://www.gandi.net/ssl/standard#multi seems like it could be enough? |
| 15:23 | <Domenic> | well that page on wildcard said wildcard is only one level |
| 15:23 | <Domenic> | yeah something that has us manually update the list of SSLed subdomains would probably also work |
| 15:24 | <Domenic> | or a single wildcard for *.spec.whatwg.org, plus another for whatwg.org, maybe? |
| 15:24 | <Domenic> | or maybe for *.whatwg.org so that https://spec.whatwg.org works too |
| 15:25 | <Domenic> | lol this is most unhelpful SO Q&A ever http://stackoverflow.com/questions/13192200/wildcard-ssl-certificate-registration-with-multi-level-subdomains |
| 15:26 | <jgraham> | Domenic: So I found a more useful SO |
| 15:27 | <jgraham> | http://stackoverflow.com/questions/2115611/wildcard-ssl-on-sub-subdomain |
| 15:32 | <jgraham> | So it seems like you either need a wildcard cert for *.spec.whatwg.org and one for *.whatwg.org or a multidomain cert for all the actual domains we have, or maybe a SAN cert |
| 15:33 | <jgraham> | So I guess the first option is going to be about 20GBP or 30USD/month |
| 15:34 | <Domenic> | what's the difference between SAN and multidomain |
| 15:35 | <Domenic> | also can we get a pretty extended validation one i like it when my address bar is all green and shiny |
| 15:37 | <jgraham> | I think multidomain is one cert that covers N named domains, but SAN allows multiple wildcard. But I'm not sure |
| 15:38 | <Domenic> | FWIW I already got us a (normal) SSL cert for resources.whatwg.org because I wanted to be able to include logos on GitHub pages without getting mixed content errors. |
| 15:40 | <jgraham> | There are also various other subdomains there like developers.whatwg.org |
| 15:40 | <jgraham> | It turns out that using lots of subdomains sucks for SSL |
| 15:41 | <Ms2ger> | So it seems |
| 15:56 | <Domenic> | I could swear last time I looked there was a way to pay like $500/year for a super-wildcard cert. Maybe I was just confused |
| 16:06 | <Domenic> | wildcard + SAN is probably what I was thinking of. See last paragraph of http://en.wikipedia.org/wiki/Wildcard_certificate#Limitation |
| 16:09 | <jgraham> | Wikipedia loses points for suggesting that www.wikipedia.org is more "the same website" as wikipedia.org than meta.m.wikipedia.org |
| 16:41 | <zewt_> | things that are never okay on the web: wakelocks. |
| 16:42 | <zewt_> | (for CPU locks at least, screen locks are more sane) |
| 16:49 | <Hixie_> | as far as TLS goes. If y'all want to manage it, I'm game. But I don't see much point, personally. |
| 16:49 | <Hixie_> | setting up the cert for www.whatwg.org was a huge pain in the ass |
| 16:50 | <Hixie_> | setting up the cert for resources.whatwg.org for me was relatively easy cos Domenic did the hard work iirc |
| 16:56 | <annevk> | the main thing I dislike is the yearly renewal shit |
| 17:02 | <annevk> | Hixie_: http://wiki.whatwg.org/index.php?title=MetaExtensions&curid=1655&diff=9674&oldid=9669 seems like some kind of spam |
| 17:04 | <Hixie_> | who's the editor in charge of this wake lock thread? |
| 17:04 | <annevk> | Hixie_: marcosc_ maybe |
| 17:04 | <Hixie_> | why is that spam? |
| 17:05 | <annevk> | Hixie_: because of the site it links to |
| 17:05 | <Hixie_> | does marcosc_ follow whatwg@? |
| 17:05 | <annevk> | Hixie_: think so |
| 17:05 | <Hixie_> | the site it links to describes meta tags... |
| 17:05 | <Hixie_> | marcosc_: ping |
| 17:06 | <Hixie_> | i mean, i agree that those meta tags are pointless at the end of the dya |
| 17:06 | <annevk> | yeah, but it seems like a tactic to increase the ranking of the domain as none of that is really useful |
| 17:06 | <Hixie_> | but so are most |
| 17:06 | <annevk> | mkay |
| 17:06 | <Hixie_> | i think they've gone to sufficient effort to actually do the right thing that if this is really spam, then let them have it |
| 17:06 | <Hixie_> | it's not like that wiki page is actually going to give them any boost, it has nothing to do with law firms |
| 17:06 | <Ms2ger> | So we not put noreferer on everything? |
| 17:07 | <Hixie_> | go ahead :-) |
| 17:07 | <Ms2ger> | Do* |
| 17:09 | <Hixie_> | i don't think so |
| 17:24 | <TabAtkins> | Ms2ger: Re: String(symbol), they wanted *some* way to do a console.log/etc with a string, but wanted to avoid footguns with people naively doing string manipulation on keys and accidentally stringifying a symbol. |
| 17:29 | <annevk> | man this blog post is long |
| 17:29 | <annevk> | attributes are too complex :( |
| 17:57 | <annevk> | http://annevankesteren.nl/2014/08/attributes |
| 18:05 | <Domenic> | Did the term "global scope polluter" not make it into the standard? |
| 18:08 | <annevk> | I think a different set of people used that term |
| 18:09 | <annevk> | In HTML it's "the Window object is indexed for property retrieval" |
| 18:10 | <tantek> | annevk - how much of the attributes mess is due to namespaces? |
| 18:11 | <annevk> | quite a bit, but I think DTDs did a worse number on them |
| 18:11 | <annevk> | via XML |
| 18:12 | <annevk> | oh, I forgot to mention case-insensitive issues in that post |
| 18:14 | <tantek> | annevk - would a lot of real world pages actually break if we dropped all the namespaces complexities with DOM attributes? |
| 18:14 | <annevk> | yeah |
| 18:14 | <annevk> | this is what we tried |
| 18:14 | <tantek> | crazy |
| 18:14 | <annevk> | to simplify this mess |
| 18:14 | <annevk> | and it failed |
| 18:14 | <Domenic> | it was pretty close |
| 18:14 | <tantek> | who *are* these people?!? |
| 18:15 | <Domenic> | i feel that with some console deprecation warnings, plus a couple years, we could maybe get there |
| 18:15 | <annevk> | enterprise, JavaScript libraries |
| 18:15 | <tantek> | enterprise I can see complaining loudly enough. JS libraries are irrelevant except when actually deployed. |
| 18:15 | <annevk> | well they are deployed :-) |
| 18:16 | <annevk> | jQuery sometimes has crazy stuff |
| 18:16 | <tantek> | then the deployments are what matter |
| 18:16 | <annevk> | yup |
| 18:16 | <tantek> | Domenic: this is why deprecation is still useful in specs |
| 18:16 | <tantek> | it may not always be able to get rid of things, but if it sometimes can, that's still useful enough. |
| 18:18 | <annevk> | yeah, I should probably add some red flags |
| 18:21 | SamB | imagines actual SVGs of red flags ... |
| 18:27 | <tantek> | 🚩🚩🚩 |
| 18:28 | <caitp> | you bet |
| 19:34 | <zcorpan> | json in an html attribute is going to be ugly |
| 19:36 | <zcorpan> | <script src="foo" urloptions="{"foo": "bar", "baz": 5}"> |
| 19:40 | <caitp> | usually people use single quotes when they want to do that |
| 19:41 | <caitp> | to avoid the entity reference sillyness |
| 19:42 | <TabAtkins> | Yeah, that's just general practice. If you're gonna use some type of quote in a literal string, you write the string with the opposite kind of quote. |
| 19:42 | <TabAtkins> | "'", '"', etc |
| 19:46 | <zcorpan> | caitp: sure but (1) json doesn't allow single quotes (2) html serializers usually use double quotes (like innerHTML) |
| 19:48 | <caitp> | TIL JSON.parse actually will throw in that case |
| 19:49 | <zcorpan> | tantek: annevk: problem with deprecating and warning about things that we then don't/can't remove is that it teaches people to ignore the deprecation/warning |
| 19:49 | <tantek> | zcorpan: do you have evidence for that? |
| 19:50 | <tantek> | my experience has been that people work at removing warnings, and asking how to do so. |
| 19:51 | <zcorpan> | tantek: well people used html4 transitional with obsoleted features well after the purpose of html4 transitional was past |
| 19:52 | <zcorpan> | but i guess it didn't trigger any warnings in the validator or anything |
| 19:52 | <boogyman> | s/used/still use/ |
| 19:55 | <tantek> | zcorpan: right, they used html4 transitional DTD *specifically* because that's how they made warnings go away |
| 19:55 | <zcorpan> | tantek: true |
| 19:57 | <zcorpan> | tantek: otoh there are many web developers who completely ignore validation because they know that their stuff works anyway |
| 19:59 | <tantek> | sure, but this is all about thresholds. if enough fixes do happen overtime, stuff can be changed. |
| 20:18 | <Domenic> | yeah, i think validation and console warnings for JS APIs are very different |
| 20:19 | <zcorpan> | hmm maybe i should use a new logo for html-differences. how about a + above a - |
| 20:19 | <zcorpan> | or the other way around |
| 20:21 | <SamB> | zcorpan: you could steal the icon gitk uses ;-P |
| 20:47 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3123 hmmm i dunno |
| 20:50 | <TabAtkins> | Kinda like the first one. |
| 20:50 | <TabAtkins> | Though the second more directly references diff files. |
| 20:50 | <zcorpan> | i think they both look like weird smileys |
| 20:50 | <TabAtkins> | The first does, yeah. |
| 20:51 | <zcorpan> | second thought is to use a 4 but that will just look like channel 4 |
| 20:52 | <zcorpan> | IV |
| 20:52 | <TabAtkins> | Why a 4? |
| 20:52 | <zcorpan> | html4 |
| 20:52 | <TabAtkins> | Ah. |
| 20:53 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3124 |
| 20:56 | <zcorpan> | maybe the - + just needs some tweaking with the size and spacing |
| 20:58 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3125 |
| 21:00 | <jgraham> | Anyone know acolwell? |
| 21:00 | <jgraham> | Or, more specifically, if https://critic.hoppipolla.co.uk/r/951 got review when it landed in blink? |
| 21:01 | <jgraham> | (assuming it did) |
| 21:03 | <Domenic> | can't unsee the smileys |
| 21:03 | <Domenic> | currently looking like cyclops puckering his lips |
| 21:05 | <caitp> | most of the wpt stuff in blink isn't actually in the tree, afaik |
| 21:06 | <caitp> | oh I see what it's saying |
| 21:07 | <zcorpan> | Domenic: how about http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3126 ? |
| 21:08 | <foolip> | zcorpan: what spec is that for? |
| 21:08 | <Domenic> | zcorpan: nice, now the ruby-red eye laser is even more apparent ^_^ |
| 21:08 | <zcorpan> | foolip: http://html-differences.whatwg.org |
| 21:08 | <zcorpan> | Domenic: :-) |
| 21:08 | <foolip> | ah |
| 21:09 | <jgraham> | caitp: https://codereview.chromium.org/245893002 says this already has review, and acolwell has already fixed some issues that people raised, so I wonder if we should just land that patch. |
| 21:09 | <foolip> | maybe a Δ (delta symbol)? |
| 21:09 | <zcorpan> | oooh |
| 21:09 | <jgraham> | At this point the reason against would have to look like "zcorpan or foolip object and are going to do the review" I think ;) |
| 21:10 | <zcorpan> | busy designing logos |
| 21:10 | <foolip> | are we talking about merging https://critic.hoppipolla.co.uk/r/951 ? |
| 21:10 | <caitp> | well you could shoot them an email at their @chromium.org address |
| 21:10 | <Domenic> | oooh I like the delta |
| 21:11 | <jgraham> | foolip: yes |
| 21:11 | jgraham | wonders what these logs are for |
| 21:11 | <foolip> | jgraham: for science! |
| 21:11 | <jgraham> | Are we making a WHATWG spec for button batteries? |
| 21:11 | <jgraham> | *logos |
| 21:16 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3127 hmm, looks like a tent |
| 21:16 | <jgraham> | That's not what a delta looks like |
| 21:16 | <Domenic> | More angular, and the right side higher. http://media-cache-ec0.pinimg.com/236x/d4/af/45/d4af454459ca864e6cba88ed40c33d0c.jpg |
| 21:17 | <jgraham> | The top should be pointy and, possibly, not all the lines should have the same thickness |
| 21:17 | <Domenic> | s/higher/thicker |
| 21:17 | <jgraham> | Right |
| 21:18 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3128 |
| 21:19 | <Domenic> | nice. slightly off-center but very nice |
| 21:20 | <Domenic> | x=30 fixes it |
| 21:20 | <jgraham> | I still think it should be pointy at the top |
| 21:20 | <Domenic> | maybe y = 68 |
| 21:22 | <jgraham> | Oh you used text? |
| 21:22 | <jgraham> | Yeah that would be font differences then |
| 21:23 | <zcorpan> | yeah working on a path now |
| 21:36 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3129 |
| 21:37 | <zcorpan> | variable stroke width would be nice huh foolip |
| 21:38 | <foolip> | :) |
| 21:39 | <foolip> | the kind that I worked on actually made it hard to do this kind of thing, because of offsets for the stroke width changes were specified as a point 0..1 on the whole path, so hitting exactly a join was ~impossible |
| 21:39 | <foolip> | this delta looks nice though, like a delta |
| 21:40 | <foolip> | and a bit like a mountain :) |
| 21:42 | <zcorpan> | how were we making the png versions again? |
| 21:45 | <foolip> | take a photo of the svg with your phone, then reduce to just two colors? |
| 21:48 | <SamB> | zcorpan: no idea how you guys do it |
| 21:48 | <SamB> | rsvg and inkscape both having inadequate parsers ... |
| 21:49 | <zcorpan> | SamB: :-( |
| 21:49 | <zcorpan> | annevk: ^ |
| 21:50 | <zcorpan> | maybe toDataURL? |
| 21:51 | <SamB> | what, no toPNG that skips the data URL and just gives you a big hunk of bytes? |
| 21:51 | <zcorpan> | there's toBlob |
| 21:53 | <zcorpan> | ok logo deployed, thanks for the feedback |
| 21:54 | <zcorpan> | some time ago, opera supported svg favicons and firefox did not. now it's the other way around it seems |
| 21:56 | <SamB> | zcorpan: not really |
| 21:56 | <SamB> | crash your browser |
| 21:56 | <SamB> | now start it again |
| 21:56 | <foolip> | how does one crash ones browser at will? |
| 21:57 | <zcorpan> | hmm firefox shows the favicon on first load but then removes it on reload |
| 21:57 | <SamB> | kill -9 or equivalent |
| 21:57 | <foolip> | and why am I awake? good night |
| 21:57 | <zcorpan> | same here :-) |
| 21:58 | <SamB> | foolip: it's not a real crash, but it's close enough for Session Restore |
| 22:04 | <Domenic> | zcorpan: I made my png with `npm install svg2png-cli -g`; `svg2png my-svg.png --width 100` or something like that |
| 22:06 | <SamB> | Domenic: what does that use for rendering? |
| 22:06 | <Domenic> | SamB: PhantomJS |
| 22:06 | <Domenic> | So, QtWebKit |
| 22:07 | <dsheets> | is PCDATA in <script> in text/html possible? |
| 22:07 | <SamB> | dsheets: you know, it might be best to avoid needing to know the answer to that question |
| 22:07 | <dsheets> | too late |
| 22:08 | <dsheets> | snark not helpful anyway |
| 22:08 | <SamB> | I was being serious! |
| 22:08 | <SamB> | dsheets: what's your context? |
| 22:08 | <dsheets> | SamB, how do you suggest I avoid needing to know the answer? coerce some XML to invalid XML? |
| 22:09 | <SamB> | dsheets: well, there isn't XML in text/html anyway |
| 22:09 | <SamB> | of course, if you're writing a serializer, maybe you really *can't* avoid knowing |
| 22:11 | <dsheets> | i think the answer is "no" |
| 22:11 | <dsheets> | based on http://www.w3.org/TR/html-polyglot/#raw-text-elements |
| 22:11 | <SamB> | DO NOT USE |
| 22:11 | <SamB> | there is no html-polyglot |
| 22:12 | <dsheets> | right, i forgot where i was |
| 22:12 | <dsheets> | mmmm this kool-aid tastes yummy |
| 22:13 | <SamB> | hey, I'm not exactly a party-liner |
| 22:13 | <dsheets> | the fact that there is a party at all disturbs me |
| 22:14 | <dsheets> | i didn't get to pick these tools but html (still) seems less flexible for inline content than alternatives |
| 22:14 | <dsheets> | no magic incantation to turn off CDATA parsing? ok... |
| 22:15 | <SamB> | what, exactly, is the point of trying to get well-formed XML to parse as HTML that kinda-sorta represents the same thing? |
| 22:15 | <dsheets> | it's what the software that i'm hacking does |
| 22:16 | <SamB> | you don't get any of the advantages that XML is supposed to give you that way |
| 22:17 | <dsheets> | it gets not-injecting stuff into my pages by default |
| 22:17 | <SamB> | hmm? |
| 22:17 | <dsheets> | look, it's not my choice and i have to fix this problem |
| 22:17 | <dsheets> | thanks for your help |
| 22:18 | <SamB> | you never even said what the problem was :-( |
| 22:18 | <dsheets> | is PCDATA in <script> in text/html possible? |
| 22:18 | <dsheets> | and the answer appears to be "no" |
| 22:18 | <SamB> | that's not a problem |
| 22:18 | <dsheets> | for me, it is |
| 22:19 | <dsheets> | this stack is conservative |
| 22:19 | <dsheets> | anyway, ta! |
| 22:19 | <SamB> | a problem is more like "i'm trying to X, but whenever I Y, the browser does Z ..." |
| 22:20 | <SamB> | dsheets: anyway, <script> parsing is batshit |
| 22:21 | <dsheets> | hmm? what? because no one has made it sane? in fact, in 2014, there isn't even a way to turn ON PCDATA? |
| 22:21 | <SamB> | it's best to forget the claims that HTML is an application of SGML when going anywhere *near* <script> |
| 22:22 | <Domenic> | not because noone has made it sane... because it was implemented in an insane way and changing it would break the web |
| 22:23 | <SamB> | (there's nothing special about <script> in XHTML though) |
| 22:23 | <dsheets> | Domenic, adding an attribute breaks the web? seems... unlikely |
| 22:24 | <SamB> | dsheets: oh, you can presumably add whatever data- attributes you like, but you can't declare them or anything |
| 22:27 | <SamB> | dsheets: hmm, looking at the spec, I see that #PCDATA is a content-model thing; the closest attribute type I see is CDATA ... |
| 22:27 | <SamB> | (that's the XML spec, of course) |
