| 00:03 | <zewt> | hero ku uses git for pushing code; you need to force push to that a lot too |
| 00:03 | <zewt> | also heroku; ios'a new habit of autocorrecting words when you type the *next* word is terrible |
| 00:06 | <TabAtkins> | Huh, Android just autocorrets when you hit space. |
| 00:19 | <zewt> | that's what ios used to do; now it tries to figure out phrases |
| 00:19 | <zewt> | which means you never really know when it'll insert a typo for you |
| 00:35 | <Domenic> | TabAtkins: lookin' good. https://whatwg.github.io/streams/ |
| 00:36 | <Domenic> | Next up I think I need to steal some CSS and/or JS to get the anchor links working |
| 00:36 | <TabAtkins> | Happy to help. |
| 00:36 | <TabAtkins> | The parts of the CSSWG stylesheet are pretty easy to find. |
| 00:37 | <TabAtkins> | http://dev.w3.org/csswg/default.css |
| 00:37 | <TabAtkins> | Look for a.self-link |
| 00:37 | <TabAtkins> | Also: whatwg specs should use the CSSWG toc styling, it's the best. |
| 00:39 | <Domenic> | sweet. will play with this more tomorrow maybe. although at some point i have to consider this yak shaved and keep working on the actual text :P |
| 00:56 | <zewt> | yak shaving considered harmful |
| 01:04 | <Hixie> | TabAtkins: last time you said that css spec styling was the best, i picked a random css spec, and it looked horrible. do you have a specific spec in mind? |
| 01:08 | <Domenic> | was the day April 1? |
| 01:10 | <zewt> | one of them was |
| 05:28 | <annevk> | TabAtkins: dom-core.html is not too important I guess; https://github.com/whatwg/dom/ should be canonical; I use two definitions of throw, one is from DOM, one is from IDL |
| 07:17 | <zcorpan> | Hixie: yoav wants to put a link in his patch to my recent img spec changes. could you regen the spec? |
| 07:21 | <krit> | annevk: I am back online |
| 07:22 | <annevk> | krit: cool |
| 07:23 | <krit> | annevk: I checked mask-image and filter and think that both do not cause any problems if the resources are not allowed to load further resources |
| 07:23 | <krit> | annevk: both do not affect layout |
| 07:23 | <annevk> | krit: having written down the algorithms it does seem like SVG as image has a lot in common with the other cases |
| 07:23 | <annevk> | krit: it's just that rather than returning an element by ID, in that case you simply take the root |
| 07:23 | <krit> | annevk: I presented the problem with clip-path to the WG in Tokyo and the WG decided that the attack pattern is not suitable enough |
| 07:24 | <annevk> | krit: which WG? |
| 07:24 | <krit> | annevk: CSS WG |
| 07:24 | <annevk> | krit: what makes them good at security? |
| 07:25 | <annevk> | You don't go to the CSS WG for security recommendations |
| 07:25 | <krit> | annevk: All I was able to do as spec author is to present the problem, present alternatives and ask for approval… which I did |
| 07:25 | <annevk> | You ask abarth, bz, ... |
| 07:25 | <krit> | annevk: we discussed it |
| 07:25 | <annevk> | WebAppSec copied |
| 07:25 | <krit> | annevk: bz was in the discussion |
| 07:25 | <annevk> | In Tokyo? |
| 07:26 | <krit> | annevk: He did not approve the outcome of the discussion but did not object either |
| 07:26 | <krit> | annevk: no, we discussed the issue before the F2F on the mailing list |
| 07:26 | <annevk> | o_O sounds like a bad outcome to me |
| 07:26 | <krit> | annevk: but irrelevant for the other properties that I care more about right now |
| 07:27 | <krit> | annevk: we can bring up clip-path at any time again |
| 07:27 | <annevk> | k |
| 07:28 | <krit> | annevk: what that means is that mask-image, fill, stroke and filter do not need to check the resource after downloading again |
| 07:28 | <krit> | annevk: something that was important for roc |
| 07:29 | <annevk> | but you do, no? |
| 07:29 | <krit> | annevk: even though he agreed that this is not a big issue if it would be necessary |
| 07:29 | <annevk> | you need to at least do a MIME type check? |
| 07:29 | <krit> | annevk: no, we don't |
| 07:29 | <annevk> | o_O |
| 07:29 | <krit> | annevk: well, this is done AFTER downloading the resource |
| 07:29 | <krit> | annevk: the MIME checking |
| 07:29 | <annevk> | yes |
| 07:30 | <krit> | annevk: the policies prevent downloading the resource in the first place |
| 07:30 | <annevk> | What policies? |
| 07:30 | <krit> | annevk: The CORS policies as implement |
| 07:30 | <annevk> | I have the feeling you're compounding several issues onto one |
| 07:30 | <krit> | annevk: that is common between blink, gecko and WebKit |
| 07:31 | <krit> | annevk: you mean? |
| 07:31 | <annevk> | I don't see what CORS has to do with this |
| 07:31 | <krit> | annevk: right, lets say fetching policies … where CORS is still part of |
| 07:32 | <annevk> | Sure, are you saying fetching mode is CORS for mask/fill/stroke/filter? |
| 07:32 | <krit> | annevk: http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/ResourceFetcher.cpp |
| 07:32 | <krit> | annevk: no, “image" |
| 07:32 | <annevk> | There's no "image" mode |
| 07:33 | <krit> | annevk: that is because implementations use their own terms |
| 07:33 | <krit> | annevk: we check what type we expect |
| 07:34 | <krit> | annevk: font, image, stylesheet, script, SVG document (for <embed>), media |
| 07:34 | <abarth> | i've been reading along, but I need to go to sleep soon |
| 07:34 | <abarth> | can you summarize what the CSS WG decided? |
| 07:34 | <annevk> | You're not making much sense. But I guess what you mean is that mask/fill/stroke/filter use no CORS as mode and that the CSS WG decided that was okay. |
| 07:35 | <krit> | annevk: yes |
| 07:35 | <annevk> | Even if the eventual thing was an SVG resource |
| 07:35 | <krit> | annevk: right |
| 07:35 | <abarth> | that's almost certainly insecure |
| 07:35 | <abarth> | you can't load XML across origins without CORS |
| 07:36 | <krit> | abarth: why wouldn’t you? |
| 07:36 | <abarth> | because XML is a confidential mime type |
| 07:36 | <abarth> | these features also let you probe inside the XML for ids and such |
| 07:36 | <abarth> | which isn't good |
| 07:37 | <krit> | abarth: IIRC we discussed that earlier and you even opened a bug report and closed it right afterwards |
| 07:37 | <krit> | abarth: we had this discussion before Blink fork |
| 07:37 | <abarth> | do you have a link to the discussion? |
| 07:38 | <abarth> | I remember this issue came up before |
| 07:38 | <krit> | abarth: it takes me some time to find it |
| 07:38 | <abarth> | but I didn't remember the details |
| 07:38 | <abarth> | maybe there's some specific thing that makes it safe, but in general its unsafe |
| 07:38 | <krit> | abarth: the point is, that you can not do ID sniffing with CSS |
| 07:39 | <krit> | abarth: if the resource exists, then you download it… there is no way for anyone to check if the ID was found or not |
| 07:39 | <abarth> | presumably you can tell if the mask was applied, right? |
| 07:39 | <krit> | abarth: how? |
| 07:40 | <krit> | abarth: it doesn’t apply, the url is still part of property style |
| 07:40 | <krit> | s/it/the mask/ |
| 07:40 | <abarth> | sure, but the pixels on the screen will be different |
| 07:40 | <annevk> | abarth: for <img> I think we decided it was safe |
| 07:40 | <krit> | abarth: yes |
| 07:40 | <abarth> | if the pixels on the screen are different, the web site can learn that by interacting with the user |
| 07:40 | <annevk> | abarth: <img> does no CORS, and if the return MIME type is image/svg+xml we decode that as a bitmap and render it |
| 07:41 | <abarth> | there was a cute proof-of-concept on hacker news the other day |
| 07:41 | <abarth> | for history sniffing |
| 07:41 | <abarth> | using this technique |
| 07:41 | <abarth> | annevk: yes |
| 07:41 | <krit> | abarth: that one needed visited pseudo selector |
| 07:41 | <abarth> | krit: you don't think you could build the same thing using mask? |
| 07:41 | <krit> | abarth: which sadly is not specified enough |
| 07:41 | <abarth> | meaning make a game |
| 07:42 | <abarth> | where the player makes different clicks depending on if a mask applied? |
| 07:42 | <abarth> | annevk: we wouldn't do that today, but we're stuck with it because of the past |
| 07:42 | <krit> | abarth: hit testing is not applied on mask, but like opacity, you can “hide” objects |
| 07:42 | <abarth> | krit: you're not understanding |
| 07:42 | <abarth> | mask changes the pixels on the screen |
| 07:42 | <abarth> | users react to pixels on the screen |
| 07:43 | <annevk> | abarth: yeah, we could have disallowed the cross-origin case there though and require the crossorigin attribute |
| 07:43 | <abarth> | meaning, they react to whether the mask applied |
| 07:43 | <abarth> | meaning they tell you whether your ID probe worked |
| 07:43 | <abarth> | annevk: exactly |
| 07:43 | <annevk> | abarth: e.g. if the response image/svg+xml but also tainted/opaque, act as if there was a network error |
| 07:43 | <krit> | abarth: sure you can do that |
| 07:43 | <abarth> | hence, you're creating a security vulnerability |
| 07:43 | <abarth> | unless you use CORS |
| 07:43 | <annevk> | abarth: that seems like what we should do for mask et al |
| 07:44 | <annevk> | abarth: if we want to keep the "tainted" cross-origin fetching for non-SVG resources |
| 07:45 | <abarth> | https://news.ycombinator.com/item?id=7855168 |
| 07:45 | <abarth> | is a recent demo of this approach |
| 07:45 | <abarth> | you could build the same thing with mask |
| 07:45 | <abarth> | to probe cross-origin resources rather than history |
| 07:47 | abarth | needs to get to sleep |
| 07:47 | <abarth> | security's no fun |
| 07:47 | <abarth> | :( |
| 07:47 | <annevk> | thanks abarth, I was mostly trying to figure out the overall processing model, but this helps greatly with fetch specifics that we also need to nail down |
| 07:48 | <annevk> | abarth: nn |
| 07:49 | <krit> | abarth: we should discuss that on the mailing list again |
| 07:50 | <krit> | abarth: IIRC the issue was that you can figure out if the ID exists even without CSS.. pure JS |
| 07:51 | <krit> | abarth: the URL of the resource is known at the point |
| 08:00 | <annevk> | krit: I don't understand the aversion to better safe than sorry |
| 08:01 | <krit> | annevk: we always need to find the right balance between security and the expressiveness of authors… We don’t need to make the web as secure as possible but as secure as necessary to protect users |
| 08:02 | <annevk> | Yes, and we have repeatedly learned that not using CORS is bad for users |
| 08:05 | <krit> | annevk: and I think it is good to have people on the other side that challenge the need of overprotection :) |
| 08:06 | <annevk> | Overprotection? |
| 08:09 | <annevk> | krit: anyway, I updated the algorithms in the etherpad |
| 08:09 | <annevk> | krit: they are now generic enough to cover both SVG as image, and whereever else we might need to take hold of a set of nodes |
| 08:09 | <annevk> | krit: if you don't pass in an ID it simply returns the root, otherwise it returns the element identified |
| 08:10 | <annevk> | krit: there's various entry points as well, as e.g. the mask/filter/ case will do its own fetching and then only if type is image/svg+xml hand it off to SVG |
| 08:24 | <krit> | annevk: ? |
| 08:25 | <annevk> | krit: what is unclear? |
| 08:30 | <krit> | annevk: no, wanted to know if this is what you would like to see for mask-image/ |
| 08:30 | <annevk> | krit: yeah, it seems we should actually write out mask image processing |
| 08:30 | <annevk> | krit: because that is more complicated |
| 08:31 | <annevk> | krit: I also wonder if TabAtkins will be in a more convenient timezone at some point so we can fix this stuff in CSS |
| 08:31 | <krit> | annevk: fill and stroke inherit the same behavior… so this could be ironed out for all SVG properties then |
| 08:31 | <krit> | annevk: including clip-path and filter |
| 08:31 | <annevk> | yeah, the algorithm "To get an image or SVG element given a /url/:" |
| 08:32 | <annevk> | it seems that should also take an environment URL and maybe an environment base URL |
| 08:32 | <krit> | annevk: Tab is working on more parameters for url() that allows authors to specify CORS rules |
| 08:32 | <tobie> | Fwiw, tend to agree with jgraham on the to('json') vs. asJSON. |
| 08:33 | <annevk> | krit: sure, again, that is not really important |
| 08:33 | <annevk> | krit: what is important is the basic setup |
| 08:33 | <annevk> | krit: without additional features |
| 08:33 | <annevk> | please try to focus on that |
| 08:34 | <annevk> | tobie: talk to JakeA or Domenic I guess |
| 08:43 | <annevk> | If people want to follow the SVG discussion, we moved to W3C, #svg |
| 10:12 | <MikeSmith> | zcorpan: so, about srcset, I have question that maybe I should hesitate to ask since I'm not sure I want to implement it, but I'll ask anyway |
| 10:13 | <MikeSmith> | which is, should it be a conformance error if the same URL is specified multiple times in the same srcset value |
| 10:14 | <MikeSmith> | in other words, is there ever a use case for specifying a URL with different descriptors in the same srcset value |
| 10:14 | <zcorpan> | MikeSmith: not sure |
| 10:14 | <MikeSmith> | e.g., srcset="image1.png 1X, image1.png 2X" |
| 10:14 | <MikeSmith> | (though probably not that example) |
| 10:15 | <zcorpan> | MikeSmith: can you file a bug? |
| 10:15 | <MikeSmith> | yeah |
| 10:15 | <zcorpan> | thx |
| 10:17 | <MikeSmith> | zcorpan: also I told you before I wasn't storing the URLs anyway. But I changed that and I am now, because I use them for reporting purposes in the error messages |
| 10:17 | <MikeSmith> | and I do that because I can't report the exactly column number of where the error is |
| 10:18 | <MikeSmith> | which is a general deficiency in the way the validator datatype/microsyntax error-reporting is designed |
| 10:19 | <MikeSmith> | most of the time it's not a problem to no report the exacty column number because the attribute values are generally short and not complex |
| 10:19 | <MikeSmith> | but the case for srcset is a bit different |
| 10:21 | <zcorpan> | MikeSmith: yeah i guess you'll highlight the entire value right? |
| 10:21 | <zcorpan> | or the whole tag even |
| 10:22 | <MikeSmith> | right |
| 10:23 | <MikeSmith> | zcorpan: it's less than ideal but it'd be a lot of work to change given the current design of the datatype-checking code |
| 10:23 | <zcorpan> | yeah |
| 10:23 | <zcorpan> | i guess people can figure out what the error is anyway |
| 10:26 | <zcorpan> | maybe you can do a hack and give a relevant extract in the message? |
| 10:27 | <annevk> | Lovely, mask:url(#something) references an element in the document the stylesheet is associated with |
| 10:28 | <annevk> | However, they also allow mask:url(/elsewhere#something) which would parse relative to the stylesheet's URL, then be fetched, ... |
| 10:28 | <smaug____> | what is an opposite of composed? incomposed seems to have also some other meanings. |
| 10:28 | <zcorpan> | MikeSmith: something like srcset="lala 1.5x, foo,, bar 2x" -> Bad value for attribute srcset on element img: Found empty image candidate in `foo,,` |
| 10:29 | <annevk> | I guess you could parse against the stylesheet's URL and then treat it as a document-reference if it's the same as the stylesheet's URL minus the fragment thing... But oh boy |
| 10:29 | <annevk> | smaug____: excited per Google |
| 10:30 | <annevk> | smaug____: also agitated, boisterous, disturbed, excited, fierce, frantic, frenzied, furious, heated, passionate, raging, roused, ruffled, stormy, turbulent, violent, wild, wrathful |
| 10:30 | <smaug____> | boisterousDocument |
| 10:30 | <smaug____> | sounds perfect |
| 10:30 | <annevk> | :-) |
| 10:30 | <MikeSmith> | flustered |
| 10:31 | <annevk> | ruffled as technical term would also be fun |
| 10:31 | <MikeSmith> | unsettled |
| 10:32 | <annevk> | I should probably post about IDNA being updated at some point |
| 10:32 | <annevk> | Now that http://www.unicode.org/reports/tr46/ is published with the revised algorithms |
| 10:32 | smaug____ | is trying to figure out names for the trees where document is the root node, and doesn't contain shadow dom, and the tree which does contain shadow dom. ComposedDoc for the latter |
| 10:33 | <MikeSmith> | raw? |
| 10:33 | <annevk> | smaug____: why does the former need to be different from Document |
| 10:33 | <MikeSmith> | untainted? |
| 10:34 | <annevk> | smaug____: document and composedDocument seems fine |
| 10:34 | <smaug____> | annevk: this is mainly for Gecko internal stuff |
| 10:34 | <smaug____> | in order to force the API user to think whether shadow dom should be handled |
| 10:34 | <MikeSmith> | smaug____: PreComposed? |
| 10:35 | <smaug____> | well, it is not pre |
| 10:35 | <smaug____> | it is Document |
| 10:35 | <MikeSmith> | then Un- |
| 10:35 | <MikeSmith> | UnComposed |
| 10:35 | <smaug____> | perhaps that |
| 10:37 | <MikeSmith> | anyway it seems analogous the character composition, so maybe there are already some names that could be repurposed from the code around that |
| 10:38 | smaug____ | uses un- |
| 10:42 | <MikeSmith> | I naively set out on srcet checking hoping I'd be able to get by without needing to create strings and store strings |
| 10:42 | <MikeSmith> | so much for that plan |
| 10:46 | <MikeSmith> | zcorpan: ah I remember now that's why I was asking you about the URLs. So far the spec has no requirement that would make me need to compare the URLs to one another, so so far I don't need to create strings for them or store them as strings |
| 10:52 | <zcorpan> | you need to store and compare the parsed descriptors though |
| 10:53 | <darobin> | MikeSmith: I had a case not long ago in which better datatype error reporting would have been really nice, it was for a pretty long data: URL |
| 10:53 | <zcorpan> | (but they're not strings, so yeah) |
| 10:53 | <darobin> | and all it told me was that there was a character in there it didn't like (and that I should be careful with quotes and spaces, which wasn't the problem) |
| 10:55 | <annevk> | MikeSmith: still no schemaless validator? |
| 10:56 | <zcorpan> | annevk: that'd be a pretty big leap |
| 10:57 | <annevk> | one small step for the validator, ... |
| 11:42 | <MikeSmith> | darobin: yeah I noticed that same data: URL error-reporting problem |
| 11:44 | <darobin> | MikeSmith: I understand that giving the column number is nigh impossible (and I can imagine why), but if you could somehow surface the faulty character it would help lots |
| 11:46 | <MikeSmith> | darobin: so that's possible at least. I mean obviously we have the problem character available at that point. we just need to add it to the error message |
| 11:46 | <MikeSmith> | the data: URL reporting code is some relatively old part |
| 11:47 | <MikeSmith> | it probably needs some attention in other parts too |
| 11:49 | <MikeSmith> | annevk: I've been moving away from the schema more and more when possible at least. e.g., for srscet the basic srcset-allowed-for-source-and-img constraint is all that the schema specifies, and the schema says the datatype for srcset is just "string". I put the actual real datatype association-and-checking for it into other code |
| 11:50 | <MikeSmith> | in part because srcset is unique in that it basically has two different dataypes depending on whether the "sizes" attribute is also specified |
| 11:51 | <MikeSmith> | and also because I tried it first in the schema and it exposed a bug in jing schema-checking code that I couldn't be assed to try to troubleshoot and fix |
| 11:52 | <MikeSmith> | it actually exposed a case in jing where the behavior was different depending on the *order* of the attributes -- different if sizes was specified before srcset, or after |
| 11:52 | <MikeSmith> | which, I didn't even think that would be possible given the way the parser and jing work |
| 11:53 | <MikeSmith> | but I guess it actually use |
| 11:53 | <MikeSmith> | *is |
| 11:54 | <MikeSmith> | darobin: if you have time to file a bug about the data URL thing, please do. It's an easy fix and I could do it this weekened |
| 11:56 | <darobin> | MikeSmith: I was already on the bugzilla page :) |
| 11:57 | MikeSmith | and darobin putting the MPAA dollars to good use |
| 11:58 | <darobin> | :) |
| 12:15 | <zcorpan> | MikeSmith: note that srcset with w is allowed without sizes |
| 13:01 | <MikeSmith> | zcorpan: yeah I know that :) but the thing is internally in the vnu design I essentially need to handle it as a separate datatype when sizes is there too |
| 13:01 | <zcorpan> | MikeSmith: k :-) |
| 13:03 | <annevk> | zcorpan: http://dev.w3.org/csswg/cssom/#css-style-sheets is somewhat wrong |
| 13:03 | <annevk> | zcorpan: location should be named href and you should have a field url or some such that's the actual location against which urls are resolved and such |
| 13:03 | <annevk> | zcorpan: is the plan that everything else in CSS references this? |
| 13:03 | <zcorpan> | annevk: please file a bug |
| 13:04 | <zcorpan> | annevk: not sure, but it needs to be well-defined at some point |
| 13:05 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26116 |
| 13:05 | <annevk> | I'm trying to figure out fetching for SVG |
| 13:05 | <annevk> | Seems CSS could use some cleanup there too |
| 13:06 | <annevk> | And SVG requires this thing where you load an external SVG document, but don't actually fetch anything from it that isn't a blob or data or other local URL |
| 13:06 | <annevk> | Styles need to be resolved however so that property needs to be supported by CSS too |
| 13:07 | <annevk> | However, it's unclear where in CSS such things would be defined |
| 13:07 | <annevk> | TabAtkins: ^^ |
| 13:08 | <zcorpan> | earlier today i was pondering how <img src=svg> works when it has a late well-formedness error |
| 13:09 | <annevk> | I guess that's not too different from a GIF or some such that has an error late? |
| 13:09 | <annevk> | Ill-defined :/ |
| 14:02 | <zcorpan> | annevk: GIF either goes from unavailable -> error or unavailable -> partially available -> completely available (even if it has late errors, it doesn't make the whole thing corrupt). i think |
| 14:07 | <Domenic> | MikeSmith: zcorpan: maybe <img srcset="pixelized.png 1x, vectorized.svg 1.5x, pixelized-2 2x, vectorized.svg 2.5x"> would be a use case for the same URL multiple times? |
| 14:08 | <zcorpan> | Domenic: maybe, but would you actually do that? instead of <img src="pixelated.png" srcset="vectorized.svg"> ? |
| 14:10 | <Domenic> | i kind of envisioned people creating specific breakpoint images for certain resolutions/densities, and then saying that they'd rather use a vectorized version in between for perfect scaling, instead of letting the browser do it fuzzily. |
| 14:10 | darobin | throws some lowsrc at zcorpan, just for funs |
| 14:12 | <zcorpan> | darobin: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26072 |
| 14:13 | <darobin> | zcorpan: oh man, I was actually joking — but you mean business |
| 14:13 | <Ms2ger> | Good old lowsrc |
| 14:14 | darobin | recalls the jokes, "Hey, unfortunately my ISP is France Telecom, could you add lowlowsrc to the spec please?" |
| 14:15 | <odinho> | :P |
| 14:19 | <yoav> | zcorpan: FWIW, I think that any data URI/cached image can be used as a replacement image until the real resource is downloaded |
| 14:19 | <yoav> | See https://code.google.com/p/chromium/issues/detail?id=382591 |
| 14:19 | <yoav> | zcorpan: And AFAICT, this is inside the "UA resource selection optimization" domain |
| 14:20 | <yoav> | So no need to spec it (even though we can add a note or something) |
| 14:22 | <zcorpan> | yoav: intredasting |
| 14:25 | <zcorpan> | ok wontfixed the lowsrc bug |
| 14:28 | <zcorpan> | annevk: thx for the bug |
| 14:55 | <Domenic> | http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0 redirects to bing?? |
| 14:56 | <Ms2ger> | https://sites.google.com/site/openwebfoundation/ |
| 14:56 | <Ms2ger> | Wat |
| 14:59 | annevk | *blinks* |
| 14:59 | <annevk> | mathiasbynens: https://code.google.com/p/v8/source/detail?r=18683 does not seem good, writing invalid utf-8 should not be an option... |
| 15:00 | <jgraham> | annevk: Traitor |
| 15:00 | <annevk> | jgraham: ? |
| 15:00 | <jgraham> | annevk: Don't worry |
| 15:00 | <annevk> | k |
| 15:00 | <jgraham> | It wasn't funny anyway :) |
| 15:10 | <mathiasbynens> | annevk: felixge said it’s because the V8 team wants to keep the API stable :/ |
| 15:11 | <mathiasbynens> | (note that it’s not just an option – it’s the default) |
| 15:13 | <annevk> | they are crazy |
| 15:21 | <darobin> | V8? Crazy? Noooo |
| 15:25 | <annevk> | heard it here first |
| 15:31 | <zcorpan> | Hixie: i've added picture, i tried running anolis locally and i think the xrefs are OK now. let me know if something's still broken. |
| 15:37 | <TabAtkins> | annevk: What is "this thing where you load an external SVG document"? |
| 15:37 | <annevk> | TabAtkins: I'll need some more context :-) |
| 15:38 | <TabAtkins> | The thing you mentioned me about 2 hours ago. |
| 15:38 | <annevk> | TabAtkins: oh, SVG as image |
| 15:39 | <TabAtkins> | Oh, now I understand your sentence. |
| 15:40 | <TabAtkins> | Referring to a "property" confused me, as it looked like you meant a CSS property, not an abstract property. |
| 15:55 | <Domenic> | Hixie: I'm happy to buy a SSL cert for resources.whatwg.org |
| 15:58 | <jgraham> | https://www.globalsign.com/ssl/ssl-open-source/ might apply |
| 16:03 | <Domenic> | The main use case is avoiding mixed-content warnings on HTTPS sites, like github.io or github.com |
| 16:44 | <mathiasbynens> | Domenic: might as well go for a *.whatwg.org cert then |
| 16:45 | <Domenic> | mathiasbynens: if we can get a free one, sure, but we'd need a $300/year one to cover all the subdomains and sub-subdomains |
| 16:45 | <Domenic> | mathiasbynens: turns out wildcard certs ($100/year) only cover a single level |
| 16:45 | <mathiasbynens> | Domenic: TIL |
| 16:53 | <annevk> | TabAtkins: I've been working with krit on figuring out how we should define those features that can reference both an SVG element and an image and it seems we're closing in on a solution |
| 16:53 | <annevk> | TabAtkins: I guess at some point we should discuss what it'll take to define fetching for CSS properties in general |
| 16:54 | <annevk> | TabAtkins: it seems part of the infrastructure for that is defined in CSSOM today (the concept of a CSS style sheet and its various subconcepts) |
| 17:15 | <TabAtkins> | Yeah, but possibly not enough. More than happy to help figure this out whenever you have time, or to apply whatever you and krit bang out. |
| 17:16 | <TabAtkins> | Dunno if you heard, but we figured out how we want to allow passing flags and whatnot with urls. |
| 17:17 | <TabAtkins> | Within our existing budget of lookahead, I can change parsing to make *quoted* url() functions actually a FUNCTION token, so they can take additional values after the url string. (Unquoted urls would still be the magical weird URL token.) |
| 17:17 | <TabAtkins> | Passed dbaron's initial sanity check, so I'm happy about it. |
| 17:18 | <TabAtkins> | annevk: Also, would appreciate your feedback on the WHATWG bikeshed header, over in my github. |
| 17:18 | <TabAtkins> | Domenic has a couple of questions about variations between your headers and his. |
| 17:20 | <annevk> | TabAtkins: looking now |
| 17:20 | <krit> | TabAtkins: if you mean CORS arguments as part of URL, we didn’t touch it… that would still be up to you and annevk |
| 17:20 | <TabAtkins> | krit: Yeah, that's what I'm talking about. |
| 17:20 | <TabAtkins> | Ok. |
| 17:20 | <annevk> | As far as I can tell we need CORS mainly for @import |
| 17:21 | <TabAtkins> | Yeah, so we can expose the stylesheets. |
| 17:21 | <annevk> | But it might be good to make url() in general forward compatible with it at least |
| 17:21 | <TabAtkins> | But also we'll need them if we ever expose more resources that are cors-restricted by default. |
| 17:22 | <TabAtkins> | annevk: URL good enough for me to refer to it from V&U to define url parsing now? |
| 17:22 | <annevk> | TabAtkins: yeah, think so |
| 17:22 | <annevk> | TabAtkins: but note that you need access to a base URL |
| 17:22 | <annevk> | TabAtkins: you need some kind of environment setup too |
| 17:22 | <TabAtkins> | Right, which the stylesheet should provide. |
| 17:22 | <TabAtkins> | Interesting. |
| 17:23 | <TabAtkins> | I'll read more into it. |
| 17:23 | <annevk> | TabAtkins: well for now it's mostly base URL; but if we expose these properties in script somehow they might want to make blob URLs work somehow |
| 17:24 | <Hixie> | zcorpan: regenning... |
| 17:24 | <Hixie> | Domenic: cool |
| 17:24 | <Hixie> | i wonder how you can get it to me safely |
| 17:24 | <Hixie> | let's see |
| 17:27 | <Ms2ger> | Hixie, pgp, clearly |
| 17:27 | <Hixie> | Domenic: you around? |
| 17:27 | <Domenic> | Hixie: ya just got back |
| 17:41 | <Hixie> | zcorpan: Possible xref problems: |
| 17:41 | <Hixie> | + density</var> be the URL and pixel density that results from <span>selecting an image source</span>, respectively.</li> |
| 17:48 | <zcorpan> | Hixie: fixed |
| 17:49 | <Hixie> | zcorpan: cool, will integrate that too |
| 17:49 | <Hixie> | zcorpan: sorry i haven't been regenning much recently, i'm updating my pipeline |
| 17:49 | <Hixie> | zcorpan: hopefully gonna make it sooo much quicker |
| 17:49 | <Hixie> | i've got the parsing of the spec down to four seconds |
| 17:49 | <zcorpan> | Hixie: it's ok |
| 17:49 | <zcorpan> | nice |
| 17:50 | <Hixie> | takes 90MB to hold the parse tree, but... |
| 17:51 | <SamB> | Hixie: does that involve a lot of redundancy? |
| 17:51 | <zcorpan> | might be less memory to use the v.nu parser in streaming mode |
| 17:51 | <Hixie> | memory is cheap |
| 17:51 | <SamB> | does that support Object Pascal? |
| 17:51 | <Hixie> | it's time that i'm worried about |
| 17:51 | <zcorpan> | SamB: i think only java and c++ |
| 17:52 | <zcorpan> | actually dunno if the c++ version has the streaming mode |
| 17:52 | <Hixie> | SamB: most of the cost is my DOM, i think. The source is only 6MB, so even if i have two or three copies of it, I wouldn't get to 90MB just from that. |
| 17:52 | <SamB> | zcorpan: that's one more language than I expected you to mention |
| 17:52 | <Hixie> | if i used validator.nu's parser i'd do it in Java or C++ |
| 17:52 | <SamB> | Hixie: I didn't expect the source to even be included in that figure |
| 17:53 | <zcorpan> | SamB: firefox uses the c++ parser |
| 17:53 | <Hixie> | i dunno how fast validator.nu is though |
| 17:53 | <Hixie> | SamB: 90MB is the memory usage of the process after it's parsed the spec |
| 17:53 | <Hixie> | so it includes everything |
| 17:53 | <Hixie> | though i recently changed how i read the file to just be an mmap, dunno how that affects it |
| 17:54 | <Hixie> | medium-term i plan to move to a world where i don't copy the strings at all, since that's about 10% of the total time the process takes right now |
| 17:54 | <Hixie> | maybe even 20% |
| 17:54 | <SamB> | Hixie: what proxy for "memory usage" are you using? |
| 17:54 | <Hixie> | i forget the most recent numbers |
| 17:54 | <zcorpan> | https://hsivonen.fi/cost-of-html/ - dunno if it tells you anything you can compare it to |
| 17:54 | <Hixie> | SamB: resident size |
| 17:54 | <zcorpan> | might also be out of date |
| 17:54 | <Hixie> | hm, interesting |
| 17:54 | Hixie | looks |
| 17:55 | <SamB> | and, er, which OS is this? |
| 17:55 | <zcorpan> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html#dependencies-0 should be moved. should i file bugs or is irc ok? |
| 17:56 | <Hixie> | SamB: debian |
| 17:56 | <SamB> | ah, my favorite :-) |
| 17:57 | <Hixie> | zcorpan: file a bug, i'll do it when it's more stable |
| 17:57 | <Hixie> | zcorpan: doesn't hurt to have it there for now |
| 17:57 | <zcorpan> | Hixie: k |
| 17:57 | <Hixie> | zcorpan: i'll review the <picture> section in detail at some point |
| 17:57 | <zcorpan> | Hixie: great, thanks |
| 17:58 | <Hixie> | no, thank _you_! i'm so glad i don't have to do this |
| 17:59 | <SamB> | Hixie: anyway, I think I might look at the private size rather than the resident size |
| 17:59 | <Hixie> | SamB: if i really cared about memory usage, i'd probably just instrument the internals |
| 17:59 | <zcorpan> | Hixie: my pleasure |
| 18:00 | <Hixie> | SamB: my main concern is speed |
| 18:00 | <SamB> | yeah |
| 18:00 | <Hixie> | and four seconds is about 3.99 seconds too slow |
| 18:00 | <Hixie> | :-) |
| 18:00 | zcorpan | gotta go |
| 18:00 | <SamB> | Hixie: maybe you're thrashing the cache |
| 18:00 | <annevk> | TabAtkins: so btw, I'm happy to help out with URL / Fetch integration / CSS model setup |
| 18:01 | <annevk> | TabAtkins: however, I have a pretty serious timezone problem |
| 18:01 | <TabAtkins> | Yeah. ^_^ |
| 18:01 | <Hixie> | SamB: yeah, need to run it under valgrind-cachegrind |
| 18:01 | <Hixie> | SamB: right now i still have a low-hanging fruit in the form of the string copying to deal with |
| 18:02 | <annevk> | TabAtkins: I'll see if I can type out some advice soonish and we can do it the very slow way on www-style |
| 18:02 | <Hixie> | SamB: not gonna try to figure out cachegrind until i've got everything i can out of callgrind :-) |
| 18:04 | <SamB> | Hixie: I'm almost surprised they're distinct frontends, honestly |
| 18:04 | <SamB> | they have a hell of a lot of overlap |
| 18:04 | <Hixie> | yeah? |
| 18:04 | <Hixie> | i've never used cachegrind |
| 18:04 | <Hixie> | then again i'd never used callgrind until a few days ago |
| 18:05 | <SamB> | not saying that they have enough that you can just use cachegrind for everything |
| 18:05 | <SamB> | but they've got more in common than any two other valgrind tools I can think of |
| 18:06 | <TabAtkins> | annevk: The very slow way is better for me, because it means I don't have to hold things in my head until I'm ready to do them. ^_^ |
| 18:07 | <annevk> | TabAtkins: sounds good |
| 18:07 | <Hixie> | SamB: it did seem that way from the docs, yeah |
| 18:10 | <annevk> | <picture> changes not being announced on @WHATWG seems bad |
| 18:10 | <Hixie> | yeah, that's an artefact of my currnet pipeline and how they're being merged in |
| 18:10 | <Hixie> | i'll add it to the list of things to fix |
| 18:10 | <Hixie> | (or, file a bug to remind me) |
| 18:10 | <Hixie> | (put "tools" in the whiteboard) |
| 18:11 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26121 |
| 18:13 | <Hixie> | thanks |
| 21:04 | <aleray_> | hi, I would like to markup seconds (or milliseconds if needed) in rdfa, like <span property="aa:begin" content="5.2">00:00:05,2</span>. how can I specify the content is a float/a second value? |
| 21:05 | <Ms2ger> | I doubt you'll find a lot of rdfa enthusiasts here |
| 21:05 | <scor> | aleray_: use the datatype attribute, for example datatype="xsd:float" |
| 21:06 | <jgraham> | Wow RDFa and XSD? Good thing I left my sense of logic at the door |
| 21:06 | <aleray_> | scor, thanks. probably a stupid question, but Is there anything specific datattype for time? |
| 21:07 | <SamB> | Ms2ger: because people around here don't like RDF, or because they dislike RDFa in particular? |
| 21:07 | <jgraham> | I think yes to both |
| 21:08 | <SamB> | aren't the datatypes the only thing worth using from XML Schema? |
| 21:08 | <scor> | aleray_: is it a duration, or a time that you want to represent? |
| 21:09 | <aleray_> | scor, a timecode: begin and end times |
| 21:09 | <scor> | aleray_: either way, #swig is a probably a better channel to ask your questions |
| 21:10 | <aleray_> | scor, oups, that the chan I inteded to join |
| 21:10 | <aleray_> | thanks |