| 00:05 | <Domenic> | If someone had lots of free time they could implement a working Ctrl+F even in multipage |
| 00:06 | <Domenic> | might be able to get away with doing it all client side by XHRing the singlepage |
| 00:07 | <SamB> | someone proposed doing something like that in `eww' to make it act more like `info-mode' when browsing Texinfo output ... |
| 00:07 | <SamB> | except elisp doesn't have XHR, obviously |
| 00:08 | <Domenic> | the only potentially tricky part would be searching only within text. would need to parse the XHR'd document then use textContent perhaps? hmm but then need to get to nearest scroll position or ID. tricky. |
| 00:08 | <SamB> | which reminds me how I wish browsers would have such features just for users |
| 00:09 | <SamB> | Domenic: DOM does not have source locations, then? |
| 00:10 | <Domenic> | As in, index into textContent string -> nearest parent node? No. |
| 00:11 | <SamB> | hmm |
| 00:11 | <Domenic> | Would need to walk the entire tree, or build an index, both of which seem bad. |
| 00:11 | <SamB> | I was thinking of either byte or line/column ranges for each DOM node |
| 00:12 | <Domenic> | Nah |
| 00:21 | <gsnedders> | Was there not some talk about APIs to control ctrl+f somewhere? Around pdf.js, maybe? |
| 00:31 | <Domenic> | There was, on the whatwg list |
| 00:32 | <Domenic> | It is a good idea IMO. Don't remember if it ever made it into Hixie's queue |
| 00:34 | <gsnedders> | idk, I don't really read mailing lists nowadays, I just read IRC :P |
| 00:34 | <gsnedders> | and spec change logs |
| 03:21 | <SamB> | Hixie: huh, you really have to do your own index entries? |
| 03:21 | <Hixie> | hm? |
| 03:21 | SamB | pulls to make sure that's not changed ... |
| 03:22 | <Hixie> | i'm not sure to what you are referring |
| 03:23 | <SamB> | the comment at the top of html/source |
| 03:23 | <SamB> | 2nd to last bullet |
| 03:24 | <Hixie> | yes? |
| 03:28 | <SamB> | I'd have expected indices to be automatically extracted from the relevant anchors |
| 03:29 | <Hixie> | where possible, it is |
| 03:29 | <Hixie> | but most of the indices have data that just isn't anywhere else |
| 03:29 | <Hixie> | in fact some of the indicies are the source of data used elsewhere |
| 03:29 | <SamB> | ah |
| 03:29 | <Hixie> | e.g. the one-line attribute descriptions you see in the element description boxes are actually sourced from the attribute index |
| 05:52 | <roc> | Hixie: WFM, sorry |
| 06:10 | <jamesr_> | roc: what would your canvas.preferredWidth/Height attributes return? |
| 06:11 | <jamesr_> | i'm not sure what an author would need that they can't get from the CSS size of the <canvas> and window.devicePixelRatio |
| 06:12 | <roc> | the canvas could be in a CSS transform |
| 06:13 | <roc> | also, if the size of the canvas * devicePixelRatio is not an integer, the author can't know what rounding the browser will do |
| 06:13 | <roc> | the latter came up in a Mozilla bug, which is what prompted my email |
| 06:14 | <jamesr_> | the browser doesn't know what the author wants either |
| 06:14 | <jamesr_> | in non-integer cases there are several justifiable choices |
| 06:15 | <jamesr_> | http://jsfiddle.net/r7V9L/ should always stay 1:1 with physical px with browser zoom, respecting the zoom level |
| 06:15 | <jamesr_> | (there's a bug in chrome on hi dpi m achines that causes filtering, but it appears to work in firefox) |
| 06:15 | <jamesr_> | that chooses to clip the content to the canvas |
| 06:15 | <jamesr_> | but you may also want to pad |
| 06:18 | <roc> | That approach works but it doesn't work if you're trying to fill the viewport |
| 06:20 | <roc> | Does that make sense? It depends on resizing the canvas to a CSS size which is known to be a multiple of device pixels. If you need to fill some container, you can't do that. |
| 06:26 | <roc> | to be fair, if you're trying to fill the viewport and you're the toplevel frame in a browser or app it's probably safe to assume that your viewport is actually some multiple of device pixels in size |
| 06:26 | <roc> | in which case you can just obtain the fractional CSS size of your viewport and multiply by devicePxielRatio and you're good |
| 06:28 | <roc> | but it would be nice to have a general solution so we can tell authors "do this" and their content will work in all contexts |
| 06:32 | <jamesr_> | well, if you're trying to fill a container and the container does not line up nicely on physical pixel boundaries you have some choices to make |
| 06:32 | <jamesr_> | and the correct choice is content-dependent |
| 06:32 | <jamesr_> | you can construct the largest physical pixel rectangle fully enclosed by the container |
| 06:32 | <jamesr_> | which may have small gaps on the edges, potentially all 4 edges |
| 06:33 | <jamesr_> | or you can make the smallest physical pixel rectangle that fully contains the container |
| 06:33 | <jamesr_> | and overdraw the edges slightly |
| 06:33 | <roc> | suppose you have a <canvas> element in the page with a CSS border |
| 06:34 | <jamesr_> | or do something else, like have the top left corner be the closest physical pixel to 0,0 that is inside the container and let the right/bottom fully fill (meaning they go slightly outside the container potentially) |
| 06:34 | <roc> | and suppose the canvas rect edges are logically at some subpixel offset(s) |
| 06:34 | <jamesr_> | and if you are larger, you have to decide to clip or extend |
| 06:34 | <roc> | Gecko will not draw a fuzzy border. We snap the border edges to device pixels at render time. |
| 06:34 | <jamesr_> | sure, i think everyone snaps border edges |
| 06:34 | <jamesr_> | but they're a bit of a special case |
| 06:35 | <roc> | obviously the canvas should exactly fill the inside of that border. So our border snapping defines the device pixel rect the canvas should fill. |
| 06:35 | <jamesr_> | if you have a div with a transform next to the canvas what do you do? |
| 06:35 | <roc> | what do you mean "next to the canvas"? |
| 06:36 | <jamesr_> | that's what the author intends |
| 06:36 | <jamesr_> | say it's a flexbox or something with div, canvas, div on a row |
| 06:36 | <roc> | what about it? |
| 06:37 | <roc> | another example is that if the canvas has a CSS background (and no padding or borders), we'll draw the background snapped to some device pixel rect. Again, the canvas will be rendered to fill that exact device pixel rect. |
| 06:38 | <roc> | So the device pixel rect filled by the canvas is defined by us. |
| 06:38 | <jamesr_> | that's true but i don't think the box decoration cases are what authors are most likely to be interested in |
| 06:38 | <jamesr_> | and you want to do that snapping well after the author has had a chance to produce content |
| 06:38 | <roc> | if we expose the size of that rect, authors can use that to set the canvas backing store correctly. If we don't expose it, it's impractical for them to figure out what it is. |
| 06:38 | <jamesr_> | i.e. after you know the pinch zoom + pan offset from the user |
| 06:39 | <jamesr_> | at which point you're probably well past anything running on the javascript thread |
| 06:39 | <roc> | panning isn't an issue. We pan in units of whole device pixels. |
| 06:39 | <SamB> | I was just gonna say, subpixel scrolling would be dumb ... |
| 06:40 | <roc> | pinch zooming is an issue for all these proposals. I wouldn't change the exposed values during a pinch zoom, but I would at the end of the gesture. |
| 06:40 | <SamB> | and, um, the canvas is going to have worse problems during zooming ;-P |
| 06:57 | <JonathanNeal> | Neat idea https://github.com/ThePacielloGroup/html5-h but goodness gracious what a polyfill. |
| 07:30 | <JonathanNeal> | SteveF: did <html5-h> used to be <w3c-heading>? Any reason worth knowing why it was changed? |
| 07:30 | <JonathanNeal> | I should mention, I’m less interested in the prefix change. I did see the explanation for that. |
| 07:30 | <SteveF> | JonathanNeal: name shorter is all |
| 07:31 | <JonathanNeal> | oh okay, thanks. |
| 07:32 | <SteveF> | JonathanNeal: ties in with uber cool XHTML2 <h> |
| 07:32 | <JakeA> | annevk: Wonder if `new Request()` content type should default to "application/x-www-form-urlencoded" for text body content. Doing a simple post via fetch() is a bit of a ballache right now |
| 07:33 | <JonathanNeal> | SteveF: I had wondered, but I try not to presume, especially based on the XHTML 1.1 nostalgia. |
| 07:35 | <annevk> | JakeA: that or multipart/form-data? |
| 07:36 | <JakeA> | annevk: I imagine you'd get that if you provided a formdata object |
| 07:36 | <JakeA> | actually |
| 07:36 | <JakeA> | could FormData have a constructor like new FormData({hello: "world"}) |
| 07:37 | <annevk> | JakeA: yeah it will get that |
| 07:37 | <annevk> | JakeA: another candidate would be URLSearchParams, but that cannot handle Blob/File |
| 07:38 | <JakeA> | annevk: I guess if you provide URLSearchParams as a response body you'd get application/x-www-form-urlencoded, and multipart/form-data if you provide a FormData |
| 07:38 | <JonathanNeal> | I hope you don’t mind, but I’m going to write an alternative polyfill for <html5-h>, SteveF. I can’t get over Polymer, yet. |
| 07:39 | <annevk> | JakeA: I guess |
| 07:39 | <annevk> | JakeA: someone needs to define multipart/form-data |
| 07:39 | JakeA | runs away |
| 08:01 | <krit> | annevk: morning. I looked at the algorithm. It seems 2) disallows load of images if called with /local SVG element flag/ set |
| 08:03 | <krit> | annevk: also, when do we still need the flag? step 3) seems to indicate that Fetch will handle fetching (or better not allowing fetching) of external resources |
| 08:03 | <krit> | annevk: after the discussion with roc, we always allow referencing external elements |
| 08:03 | <krit> | annevk: and disallow fetching external resources in general in certain modes |
| 08:04 | <krit> | annevk: (in which case referencing external elements is a failure as well) |
| 08:14 | <JonathanNeal> | Like http://sandbox.thewikies.com/h/demo.html |
| 08:30 | <JakeA> | Anyone working on the push API here? Any idea why we'd want to allow more than one push registration per serviceworker registration? Really complicates the API |
| 08:33 | <JakeA> | Ohh, that was a bit candyman |
| 08:33 | <JakeA> | sicking: Any idea why we'd want to allow more than one push registration per serviceworker registration? Really complicates the API |
| 08:38 | <sicking> | JakeA: so that you can have separate ones for emails and attachments for example |
| 08:38 | <sicking> | JakeA: so that the user can turn on syncing of emails but not attachments |
| 08:39 | <sicking> | JakeA: Android does something very similar, though it has a terribly hard-to-find UI for it |
| 08:39 | <sicking> | JakeA: oh, wait, sorry |
| 08:39 | <JakeA> | sicking: Isn't that something the site's server would decide? |
| 08:39 | <sicking> | JakeA: push registration, not sync registration |
| 08:39 | <sicking> | JakeA: yes, sorry, i was talking about something else |
| 08:40 | <sicking> | JakeA: for push I believe it has been decided to only allow one push registration per SW |
| 08:40 | <JakeA> | sicking: Ohhh fantastic |
| 08:41 | <sicking> | JakeA: given that we actually have more than me working on push, i've happily punted it to those guys |
| 08:41 | <JakeA> | sicking: Need to keep up to date with that mailing list I guess. Which list is that happening on? |
| 08:41 | <sicking> | JakeA: i believe this was decided at a push face-to-face in madrid a few weeks ago |
| 08:42 | <JakeA> | sicking: Who should I bug for the latest registration code? Hoping to preview it at I/O |
| 08:42 | <sicking> | JakeA: try dougt@moz. I'm not sure who was there from Google |
| 08:43 | <JakeA> | sicking: excellent, thanks! |
| 08:44 | <annevk> | sicking: you in Europe now? |
| 08:44 | <sicking> | annevk: Taiwan |
| 08:44 | <annevk> | sicking: ah okay, that explains the times :-) |
| 08:44 | <sicking> | annevk: i was in Europe on friday |
| 08:44 | <sicking> | yeah :) |
| 08:45 | <annevk> | sicking: so progress notifications, the suggested API seems okay? |
| 08:45 | <sicking> | annevk: got link to proposal? |
| 08:45 | <annevk> | sicking: can't we do something with a writeable property on the object? |
| 08:45 | <annevk> | sicking: https://github.com/whatwg/notifications/issues/17 |
| 08:46 | <sicking> | brb |
| 08:58 | <annevk> | krit: I guess that flag can be removed |
| 08:59 | <annevk> | krit: it seems the caller still needs some flexibility as to what is passed to Fetch |
| 08:59 | <annevk> | krit: well, not Fetch, "image fetch" |
| 08:59 | <annevk> | krit: which will be defined by HTML most likely |
| 09:00 | <krit> | annevk: sounds good to me |
| 09:10 | <SteveF> | JonathanNeal: knock yourself out :-) |
| 09:21 | <annevk> | zcorpan: hey, are you planning on working on the generic "image fetch" algorithm? |
| 09:22 | <zcorpan> | annevk: yeah probably at some point |
| 09:22 | <annevk> | zcorpan: SVG in general wants to use that algorithm also for masks and paint servers and such |
| 09:23 | <zcorpan> | ok |
| 09:23 | <annevk> | zcorpan: so the basic algorithm should probably either return an XML tree or an image |
| 09:24 | <annevk> | zcorpan: or failure |
| 09:24 | <annevk> | zcorpan: and the XML tree is only when the MIME type is image/svg+xml |
| 09:24 | <annevk> | zcorpan: and with scripting disabled |
| 09:27 | zcorpan | pasted the above into https://www.w3.org/Bugs/Public/show_bug.cgi?id=24055 |
| 09:31 | <annevk> | krit: simplified the algorithm some more assuming image fetching will deal with the rest |
| 10:00 | <sicking> | annevk: still there? |
| 10:00 | <annevk> | sicking: yeah |
| 10:00 | <sicking> | annevk: why is progress better to have as a settable property? |
| 10:00 | <sicking> | annevk: rather than as in the proposal? |
| 10:01 | <annevk> | sicking: seems you get a lot of Notification objects with the proposal |
| 10:01 | <sicking> | annevk: the idea is to use tags to replace the existing notification, no? |
| 10:02 | <annevk> | sicking: sure |
| 10:02 | <sicking> | annevk: doesn't that solve it? I thought it was defined that replacing using a tag would not do a full new "user alert" |
| 10:02 | <annevk> | sicking: maybe that's fine, but if we're going to have <button> and such, does that still make sense? Replacing notifications? |
| 10:03 | <sicking> | annevk: yeah, i think replacing still makes sense. For example replacing "you have 4 new voicemails" with "you have 5 new voicemails" |
| 10:03 | <annevk> | It does work. It just seems weird to require replacing the Notification rather than updating it |
| 10:03 | <annevk> | Yeah I guess |
| 10:04 | <sicking> | annevk: having a single model is better than two |
| 10:04 | <annevk> | On the upside it is rather simple that way |
| 10:04 | <sicking> | yeah |
| 10:04 | <annevk> | On the downside I'm not sure how this extends to more arbitrary notifications such as as the new stuff in iOS |
| 10:04 | <annevk> | But I guess that can be done later |
| 10:48 | <krit> | annevk: an SVG Image loaded with <img> does or does not have a browsing context? |
| 10:48 | <krit> | annevk: "A browsing context is an environment in which Document objects are presented to the user." would suggest that it doesn't |
| 10:48 | <annevk> | krit: it doesn't |
| 10:49 | <krit> | annevk: so style sheets can operate without browsing context? |
| 10:49 | <annevk> | krit: a browsing context is a window/tab, content in <iframe> |
| 10:49 | <krit> | annevk: k, thanks |
| 10:51 | <annevk> | krit: it's a bit unclear to me how <style> and such would/should work there |
| 10:52 | <annevk> | krit: I think SVG as image might require refactoring in HTML as well |
| 10:52 | <annevk> | krit: e.g. HTML's <style> element present there would start fetching subresources |
| 10:52 | <krit> | annevk: right, that is my concern with the definition of browsing context... on the other hand... it is not the user who does have access to Document objects |
| 10:52 | <krit> | annevk: so it would fit again |
| 10:53 | <annevk> | It seems browsing contexts are not really relevant here, I was mistaken about that yesterday, but there are some other issues |
| 10:53 | <krit> | annevk: that was my next question... can Fetch define in general that documents without browsing context can not fetch external resources? So "local fetches only flag" is set. |
| 10:54 | <annevk> | No we shouldn't do it that way |
| 10:54 | <annevk> | That doesn't work well for e.g. a document fetched through XMLHttpRequest |
| 10:54 | <krit> | annevk: ok, can do it outside of fetch |
| 10:55 | <krit> | annevk: could you add a flag "local fetches only" to fetch with an issue that it needs to be defined? |
| 10:56 | <krit> | annevk: something that can be referenced |
| 10:56 | <annevk> | there's an open bug |
| 10:56 | <krit> | annevk: but no name for it yet? |
| 10:56 | <annevk> | there's a proposed name in that bug |
| 10:56 | <annevk> | I copied you |
| 10:57 | <krit> | annevk: could you paste the link please? don't see it right now |
| 10:59 | <annevk> | krit: I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26144 on <html:style> |
| 10:59 | <annevk> | krit: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26114 is the bug on defining "local fetches only fag" |
| 11:00 | <annevk> | flag, even |
| 11:00 | darobin | glad annevk hasn't picked up smoking after all |
| 11:00 | <annevk> | :) |
| 11:01 | <darobin> | and anyway if you went to fetch fags the polite thing to do would be to also get some beer |
| 11:01 | <krit> | annevk: thanks! |
| 11:07 | <annevk> | krit: emailed www-svg on <svg:script> definition |
| 11:09 | <annevk> | Now I wonder whether <template> does its magic when fetched through XMLHttpRequest |
| 11:12 | <annevk> | It does |
| 11:19 | <annevk> | krit: I saw you added some notes |
| 11:20 | <annevk> | krit: I'm not sure if you should make things depend on "browsing context" |
| 11:21 | <annevk> | krit: that would do weird things if you fetch image/svg+xml through XHR |
| 11:21 | <annevk> | krit: you probably want "process the resource just retrieved" with mode "limited" or some such |
| 11:22 | <annevk> | krit: and then for each element you define what "limited" means |
| 11:26 | <annevk> | My <template> thing above is now https://github.com/w3c/web-platform-tests/issues/1064 |
| 11:47 | <annevk> | JakeA: can you reply to the WHATWG thread on to()? |
| 11:47 | <JakeA> | annevk: Shall do |
| 11:47 | annevk | doesn't really care |
| 11:48 | <JakeA> | tbh I don't care much either |
| 11:49 | <annevk> | say we have toBlob / toFormData / etc. |
| 11:49 | <JakeA> | toString is the tricky one |
| 11:50 | <JakeA> | I guess toText is fine |
| 11:50 | <annevk> | yeah |
| 11:50 | <annevk> | we'd mimic XHR naming |
| 11:51 | <annevk> | if you invoke one of them, set a flag so the others return a rejecting promise? |
| 11:51 | <JakeA> | I guess that would be our "in the mean time" behaviour. Eventually it'll reject if the stream has already been read |
| 11:52 | <annevk> | yeah, but if you invoke one again or a another while a stream is being read, it seems best to simply reject |
| 11:52 | <JakeA> | Aren't we describing the same thing? |
| 11:52 | <annevk> | <canvas> uses the toBlob() naming too, but there it keeps working |
| 11:53 | <annevk> | but I guess that's fine since you should expect them to do something else on a stream vs a steady object |
| 11:53 | <annevk> | JakeA: we might :) |
| 12:00 | <tobie> | JakeA: toJSON was also highlighted as being problematic and asJSON was suggested instead. |
| 12:01 | <JakeA> | tobie: What's wrong with toJSON? |
| 12:02 | <tobie> | it's used by JSON.stringify |
| 12:03 | <JakeA> | ah fuck |
| 12:04 | <annevk> | then all of them should be as* |
| 12:04 | <tobie> | annevk: agreed. |
| 12:04 | <JakeA> | Just sent that |
| 12:04 | <annevk> | I'm gonna have some lunch while you guys sort it out :) |
| 12:10 | <zcorpan> | ok see you guys in 6 weeks |
| 12:52 | <krit> | annevk: thanks... will add that |
| 13:01 | <annevk> | krit: what's the best way to get SVG updated with respect to all the IRI language? Send email? |
| 13:02 | <krit> | annevk: oh, I am actually working on it right now... do you want to do the edits? |
| 13:02 | <annevk> | mathiasbynens: maybe you should add to http://javascript.spec.whatwg.org/#goals that we want to upstream all the things ideally |
| 13:02 | <krit> | annevk: I probably need a couple of days anyway |
| 13:02 | <annevk> | krit: oh wow, great |
| 13:02 | <krit> | annevk: if you want to edit, ping heycam ... not sure how strict he seed the editing policies |
| 13:03 | <annevk> | krit: I was wondering how easy it would be for me to help editing |
| 13:03 | <krit> | s/seed/sees/ |
| 13:03 | <annevk> | krit: are you guys hosting on GitHub? |
| 13:03 | <krit> | annevk: sadly not :( |
| 13:03 | <mathiasbynens> | annevk: good point, that can never be made clear enough |
| 13:04 | <krit> | annevk: we have a mercurial repository |
| 13:04 | <krit> | annevk: heycam would need your public key |
| 13:05 | <annevk> | mathiasbynens: since that is always the first complaint :) |
| 13:06 | <annevk> | krit: hmm, I guess for now I'll stick to sending feedback then |
| 13:06 | <krit> | annevk: that definitely works. Please do that! |
| 13:06 | <annevk> | krit: not sure I have a public key |
| 13:06 | <annevk> | well, prolly a GH generated one |
| 13:06 | <krit> | annevk: you can also send your private key to heycam ;) |
| 13:06 | <annevk> | hehe |
| 13:31 | <MikeSmith> | what's the difference between "pixel density" and "pixel depth"? do they mean the same thing? |
| 13:32 | <annevk> | MikeSmith: I think pixel depth is an alternative term for color depth |
| 13:33 | <MikeSmith> | ah |
| 13:33 | <darobin> | MikeSmith: two sides of the same thing; pixels representing YouTube comments are pretty dense, whereas those used for, say, Feynman quotes are pretty whoa deeep |
| 13:33 | <MikeSmith> | haha |
| 13:34 | <Ms2ger> | Whereas the pixels used for darobin quotes are a waste of electricity :) |
| 13:34 | <darobin> | aren't we in a sweet mood today Ms2ger |
| 13:34 | <Ms2ger> | I don't do sweet, dear :) |
| 13:35 | <darobin> | what a darling |
| 13:46 | <annevk> | Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26014 |
| 13:48 | <Ms2ger> | Is "The append(name, value, filename) method must run these steps:" supposed to cover the append(ScalarValueString name, ScalarValueString value) signature too? |
| 13:48 | <annevk> | I don't see why not |
| 13:49 | <Ms2ger> | I guess #create-an-entry does handle strings |
| 13:49 | <annevk> | Yes |
| 13:50 | <Ms2ger> | Mm |
| 13:50 | <Ms2ger> | I guess it's fine |
| 13:50 | <Ms2ger> | It feels a little weird |
| 13:58 | <annevk> | Domenic: to(x) -> asX() |
| 13:59 | <annevk> | Will implement that change now |
| 14:30 | Ms2ger | forwards to annevk... "what is an example of a DOM class people would like to be able to subclass?" |
| 14:30 | <annevk> | Ms2ger: I think all of them, basically |
| 15:02 | annevk | wonders what GROSA in https://twitter.com/lucasmourelle/status/479610741058994177 means |
| 15:54 | <JonathanNeal> | Would CSS pseudos like :heading add selector weight? |
| 15:54 | <jgraham> | We have tried and failed to get :heading(N) before |
| 15:56 | <JonathanNeal> | Then let me rephrase; are CSS pseudo elements weighted with elements or class/attributes? |
| 15:57 | <SamB> | jgraham: what would that do? |
| 15:58 | <annevk> | JonathanNeal: what does weighted mean? |
| 15:58 | <jgraham> | JonathanNeal: I don't understand what you mean "weighted" (but that might just mean I don't know CSS terminology) |
| 15:58 | <annevk> | JonathanNeal: do you mean specificity? In which case, yes |
| 15:59 | <SamB> | yeah, pretty sure he meant specificity |
| 15:59 | <JonathanNeal> | I’m referring to selector weight. It typically goes ID.Attribute.Element. |
| 15:59 | <JonathanNeal> | Oh, sorry for using the wrong terminology. |
| 15:59 | <SamB> | JonathanNeal: you talking about how more-specific selectors are supposed to override less-specific selectors? |
| 15:59 | <SamB> | not cascading, mind! |
| 16:00 | <SamB> | /inheritance |
| 16:00 | <JonathanNeal> | Do CSS pseudo elements share the same specificity as elements? eg `:first-child` has the same specificity as `p`. |
| 16:01 | <JonathanNeal> | And gosh, I don’t even know if I just accidentally confused pseudo elements with pseudo classes. |
| 16:01 | <SamB> | hmm, I'd sorta hope :first-child would rank a bit higher ... |
| 16:01 | <SamB> | I think you did |
| 16:02 | <SamB> | I think pseudo-elements don't even *need* higher specificity due to being nested inside real elements |
| 16:04 | <Domenic> | wow such confusion so specificity much selectors |
| 16:04 | <JonathanNeal> | What I really want to know is, was the proposed :heading(N) selector a pseudo element, and if it was, would it have been the same weight as h1-6? |
| 16:05 | <JonathanNeal> | weight/specificity |
| 16:05 | <annevk> | It was a class |
| 16:05 | <Domenic> | so to be clear, when we talk about weight, we're talking about how much they weigh in earth gravity? because they use CSS on the international space station too |
| 16:05 | <annevk> | Since it matched an existing node, it didn't generate one |
| 16:06 | <annevk> | Domenic: it depends on how far away you are from the screen |
| 16:06 | <Domenic> | walked right into that one... |
| 16:07 | <annevk> | JonathanNeal: http://dev.w3.org/csswg/selectors/#specificity |
| 16:07 | <Domenic> | annevk: interesting, re to->as. Might be able to convince myself that whenever you see "stream as x" you should read that as "consume the stream and get back the result as an x" |
| 16:07 | <SamB> | I'm pretty sure that e.g. weighted averages work exactly the same in the ISS as on earth |
| 16:07 | <SamB> | ;-P |
| 16:08 | <SamB> | Domenic: so "stream as opus" means? |
| 16:08 | <Domenic> | annevk: still think using the verb "read" would be better in some way. Although readAsJSON() sounds like it would just read the next chunk (since read() reads the next chunk). Bringing us to the overly-verbose readToEndAsJSON(). So yeah maybe I can convince myself "as" is an abbreviation for "read to end as" |
| 16:08 | <JonathanNeal> | Sometimes I confuse the “S” in CSS with inheritance. Thanks for walking me through things in a manner fitting the Benny Hill theme. |
| 16:09 | <Domenic> | #horse_#whatwg |
| 16:09 | <JonathanNeal> | I’ll be sure to use this conversation in future interviews. “Look at how well I misunderstood the syntax. Impressive, no?” |
| 16:10 | <Ms2ger> | JonathanNeal, did you mean the C? |
| 16:11 | <JonathanNeal> | https://www.youtube.com/watch?v=MK6TXMsvgQg |
| 16:12 | <JonathanNeal> | Domenic: I was reading your thread https://github.com/ThePacielloGroup/html5-h/issues/27 which is how I came to ask these questions (and malfunction). |
| 16:13 | <JonathanNeal> | So I wrote an alternative polyfill that re-arranges the weight on DOM mutations. https://github.com/ThePacielloGroup/html5-h/issues/28 |
| 16:13 | <JonathanNeal> | And as I was thinking about the issue of selector specificity, I came here, and failed. |
| 16:14 | <Domenic> | oh nice, iwas thinking about writing such a thing |
| 16:14 | <SamB> | Hixie: so, how come there's not a README in http://svn.whatwg.org/webapps to give a clue how to rebuild? |
| 16:15 | <JonathanNeal> | Domenic: If you’re interested, I could put it in its own project and make you a co-admin. |
| 16:16 | <Domenic> | JonathanNeal: tempting, but I think I'll have to decline. That would push me over the edge from "caring enough to comment on issues and threads" to "caring enough to do actual work on a good solution," which is more caring than I should really invest. |
| 16:17 | <Ms2ger> | gsnedders, take your laptop outside? |
| 16:20 | <JonathanNeal> | Domenic: such honesty so clear |
| 16:21 | <JonathanNeal> | I should really be contributing to all the responsive element discussions, but I’m easily distracted. |
| 16:39 | <annevk> | SamB: I don't think the scripts are open source |
| 16:40 | <annevk> | SamB: if you ask Hixie privately you can get the details and hopefully his new system will be completely out there |
| 16:44 | <gsnedders> | Ms2ger: I wouldn't be able to see the screen in the sun |
| 16:45 | <Ms2ger> | In Scotland? |
| 16:45 | <Ms2ger> | [citation needed] |
| 16:46 | <SamB> | have you seen how many languages that comic has been translated to, with recolored bunting and everything? |
| 16:46 | <gsnedders> | We're have one of our seven days of sun today. |
| 16:48 | <TabAtkins> | jgraham: I don't think we *failed* to get :heading(n). It just wasn't all that interesting. Nothing blocked it, I don't think. |
| 16:49 | <jgraham> | That sounds like "failed to get" |
| 16:51 | <TabAtkins> | There's a difference between 500 and 503. |
| 16:52 | <jgraham> | Not from the point of view of the end user |
| 16:54 | <TabAtkins> | From the point of view of someone trying to mess about with the relevant standards, though, there is. |
| 16:54 | <TabAtkins> | Here, the standards bodies are the browser. |
| 16:59 | <jgraham> | FWIW I think there were actually technical objections about perf |
| 16:59 | <jgraham> | I would love a :heading(N) selector, so I hope I am wrong |
| 16:59 | <jgraham> | But I don't think it was just a case of "we can't be bothered to look at this" |
| 17:00 | <TabAtkins> | jgraham: Meh, can run outline algo once on the page and attach a short int to every heading. |
| 17:01 | <TabAtkins> | No one will complain if :heading(256) fails to select the correct heading. |
| 17:01 | <SamB> | TabAtkins: indeed |
| 17:01 | <SamB> | that's WAAAY too much nesting |
| 17:01 | <SamB> | and you wouldn't be able to see a heading that small ;-P |
| 17:02 | <jgraham> | TabAtkins: But if the dom changes the depth will change. Possibly in a non-local way |
| 17:02 | <TabAtkins> | Mm, true. |
| 17:03 | <TabAtkins> | Stupid non-static DOM. |
| 17:08 | <annevk> | mounir: so I bought some 99% chocolate, that shit is hardcore |
| 17:08 | <annevk> | mounir: back to 70% for now |
| 17:22 | <TabAtkins> | annevk: Yeah, 70-80 is my limit too. |
| 17:23 | <TabAtkins> | But my friend Emil hates sweet things, and there's a chocolatier near me that does 99% and 100% truffles, which he fell in love with. |
| 17:23 | <jgraham> | YOu know the quality of chocolate isn't a function of its cocoa percentage, right? |
| 17:23 | <jgraham> | Well not a monotonically increasing function at least |
| 17:23 | <SamB> | I assume 0% chocolate is unacceptable, though |
| 17:25 | <jgraham> | 0% chocolate? Well if it's being sold as "chocolate", yes. If it's being sold as "cheese" it's probably better than 30% chocolate. Well depending on which cheese it is. |
| 17:25 | <TabAtkins> | jgraham: Of course, but it's an important factor in the quality. |
| 17:26 | <jgraham> | It's one piece of information that tells you something about the likely taste |
| 17:27 | <jgraham> | SamB: And now I think about it white chocolate is 0% cocoa solids. It's an entirely different product ofc, but can be nice |
| 17:32 | <SamB> | jgraham: huh, so what's it actually made of? |
| 17:32 | <jgraham> | Cocoa butter, sugar and milk, usually with vanilla flvouring |
| 18:24 | <mounir> | annevk: you don't eat 99% chocolate the same way as you eat 70%, you know, right? |
| 18:26 | <jgraham> | Depends how you eat 70%? |
| 18:27 | <Ms2ger> | "Not" |
| 18:40 | Ms2ger | wonders what's up with the data- attributes at https://developers.google.com/web/fundamentals/getting-started/your-first-multi-screen-site/content |
| 18:43 | <caitp> | they make validators happy |
| 19:28 | <gsnedders> | hmm |
| 19:28 | <gsnedders> | something is wrong with Hixie's branches on html5lib |
| 19:29 | <Hixie> | hm? |
| 19:30 | <gsnedders> | all the branches same to include the same initial commit (6825810c65) and then a merge with master |
| 19:31 | <gsnedders> | I presume that commit should be on newtests? |
| 19:33 | <gsnedders> | huh, the following merge commit seems to undo that change |
| 19:34 | <Hixie> | oh that's probably that weird commit i didn't understand |
| 19:34 | <Hixie> | from march? |
| 19:34 | <Hixie> | it seems to be empty? |
| 19:35 | <gsnedders> | https://github.com/html5lib/html5lib-tests/commit/6825810c650a6277933a5db860e973382355a5cc is pretty clearly not empty |
| 19:36 | <gsnedders> | but combined with the merge that follows it, they change nothing |
| 19:43 | <krit> | Hixie: Hi. There are still some appearances of Path() in the spec: "The Path() constructor, when invoked, must return a newly created Path2D object." http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path2d |
| 19:43 | <Hixie> | oops |
| 19:43 | <Hixie> | fiel a bug? |
| 19:44 | <Hixie> | file |
| 19:44 | <krit> | K |
| 19:44 | <krit> | On Bugzilla? |
| 19:52 | <Hixie> | yeah |
| 19:52 | <Hixie> | you can use the form on the spec |
| 19:52 | <Hixie> | bottom right |
| 20:16 | <Hixie> | TabAtkins: it's not so much that no page will be using that feature that matters, it's that no page using that feature will be affected by the removal of that feature |
| 20:17 | <Hixie> | gsnedders: i got a lot of e-mail about the tests, am i supposed to do anything with them? |
| 20:19 | <gsnedders> | Hixie: no, there are just pull requests that you're tagged in |
| 20:20 | <Hixie> | k |
| 20:21 | <jgraham> | Any and all email from github is effectively spam because it generates so much of it that you have to find some other way of following activity |
| 20:24 | <TabAtkins> | Hixie: Yeah, sure. |
| 20:28 | <Hixie> | TabAtkins: i mention that only because it removes the need for handwaving away the crazy pages that use the feature even though it doesn't yet work |
| 20:28 | <TabAtkins> | Ah, yeah, that's the "degenerate cases" I alluded to. |
| 20:29 | <Hixie> | right |
| 20:35 | <SamB> | so, um, there's a <header> element, but there's no way to style it properly? That's ... useful ... |
| 20:35 | <Hixie> | hm? |
| 20:35 | <Hixie> | it should style the same as any other element |
| 20:44 | <SamB> | Hixie: hmm, maybe I'm confused about what :header(n) would do |
| 20:44 | <Hixie> | what's :header(n) ? |
| 20:44 | <SamB> | Hixie: a non-thing, presently |
| 20:45 | <SamB> | or maybe it was :heading(n) |
| 20:45 | <Hixie> | i'm confused... |
| 20:46 | <SamB> | TabAtkins and jgraham mentioned, er, :heading(n) as a proposal that failed to gain traction ... |
| 20:47 | <Hixie> | and from that you concluded that <header> couldn't be styled...? |
| 20:48 | <SamB> | Hixie: no, I just jumped to confusions about what <header> is supposed to be |
| 20:48 | <jgraham> | <header> isn't teh same thing |
| 20:48 | <SamB> | forget I mentioned <header> |
| 20:48 | <SamB> | I was confused |
| 20:48 | <Hixie> | k... |
| 20:48 | <SamB> | so what would :header(n) have been for? |
| 20:48 | <SamB> | er. |
| 20:48 | <SamB> | :heading(n) |
| 20:50 | <TabAtkins> | SamB: <header> isn't a heading, in the <h1> sense. |
| 20:50 | <TabAtkins> | Ok, I see you got that already. ^_^ |
| 20:50 | <SamB> | yeah |
| 20:51 | <Hixie> | it'd probably be a way to directly target headings of a particular depth |
| 20:51 | <Hixie> | in the outline |
| 20:51 | <Hixie> | (i'm just guessing) |
| 20:51 | <TabAtkins> | Yeah, that's what :heading(n) is supposed to do. |
| 20:52 | <TabAtkins> | In <section><h1>foo</h1> <section><h1>bar</bar> </section></section>, :heading(1) would target foo and :heading(2) would target bar. |
| 20:52 | <TabAtkins> | (Actually, because of the section implied by <body>, those are probably :heading(2) and :heading(3).) |
| 20:53 | <SamB> | TabAtkins: hmm, that seems kind of like a bad idea |
| 20:53 | <SamB> | how would you ever get a :heading(1) then |
| 20:53 | <jgraham> | <body><h1> |
| 20:53 | <SamB> | ah |
| 20:53 | <SamB> | nevermind ;-) |
| 20:53 | SamB | slaps forehead. except he's too lazy to actually do it |
| 20:54 | <TabAtkins> | Too lazy to even move your hand. How lazy. |
| 20:54 | <SamB> | still, it seems rather confusing to use h1 that way |
| 20:55 | <SamB> | what would it do with <hgroup>? anything? |
| 20:55 | <SamB> | ignore the descendants, perhaps? |
| 20:56 | <Hixie> | <hgroup> is a heading with the same status as the highest-ranked heading inside it |
| 20:56 | <Hixie> | (h1 is highest, h6 is lowest) |
| 20:56 | <Hixie> | and affects the outline accordingly |
| 20:56 | <SamB> | but, would a :heading() rule allow you to style it sensibly? |
| 20:57 | <SamB> | I guess you could use element-type selectors for that part ... |
| 20:57 | <Hixie> | depends how it would be defined |
| 20:57 | <Hixie> | it's almost certainly academic since i doubt browsers will ever implement a selector that depends on the outline |
| 20:57 | <SamB> | :-( |
| 20:58 | <Hixie> | just like they won't implement a selector that depends on substringing inline text |
| 20:58 | <Hixie> | too expensive |
| 20:59 | <SamB> | substringing inline text sounds a lot MORE expensive |
| 21:00 | <Hixie> | once it crosses the bar of "expensive", exactly _how_ expensive it is is somewhat irrelevant |
| 21:17 | <SamB> | Hixie: well, how hard have they thought about this stuff? |
| 21:25 | <SamB> | Hixie: I mean, obviously they can't recalculate section levels any faster than O(n) while moving a subtree between sectioning levels ... |
| 21:26 | SamB | is imagining an overlayed tree for the outline |
| 21:29 | <SamB> | also, I'm assuming outlining would be lazy; no sense doing it before something wants to see the outline |
| 21:31 | <SamB> | or for irrelevant parts of the tree |
| 21:33 | <SamB> | gsnedders: what's with the huge styling on http://gsnedders.html5.org/outliner/ ? |
| 21:34 | <SamB> | and, ow, that file input thing is much wider than it looks |
| 21:34 | <Hixie> | SamB: the outline tree is worse than O(N) by depth of tree |
| 21:34 | <SamB> | no wonder I got so many file browser dialogs |
| 21:34 | <SamB> | Hixie: I was thinking more in terms of O(n) for nodes visited |
| 21:35 | <SamB> | maybe it's a problem that browsers want to know how tall the page is though :-( |
| 21:38 | <Hixie> | you need to visit quite a lot of nodes to figure out the outline depth of a node |
| 21:38 | <SamB> | at some point, certainly |
| 21:40 | <SamB> | Hixie: hmm, who *does* use the outlining algorithm, anyway? |
| 21:42 | <Hixie> | anyone who wants to e.g. generate a table of contents |
| 21:44 | <SamB> | would there be many compatability problems caused by changes to the algorithm in the spec? |
| 21:45 | <gsnedders> | SamB: idk |
| 21:45 | <gsnedders> | SamB: stop assuming logic! |
| 21:45 | <Hixie> | SamB: compatibility, probably not |
| 21:46 | <SamB> | gsnedders: I wasn't necessarily assuming that |
| 21:46 | <gsnedders> | SamB: I dunno, it was basically hacked together one evening |
| 21:54 | <gsnedders> | jgraham: https://critic.hoppipolla.co.uk/r/431 doesn't match the PR |
| 21:54 | <gsnedders> | jgraham: can you fix that? |
| 21:55 | <Hixie> | gsnedders: btw do all the test updates look ok? or did i make any mistakes? |
| 21:55 | <gsnedders> | Hixie: I'm just looking through all the PRs now :P |
| 21:55 | <gsnedders> | Hixie: I just added them so they were there and didn't get forgotten about mostly |
| 21:56 | <Hixie> | ah ok cool |
| 21:56 | <Hixie> | let me know if you have any questions |
| 21:56 | <Hixie> | i'm staring at the code as we speak so it's a good time for me, it's all paged in :-) |
| 21:57 | <gsnedders> | oh god new AAA tests |
| 21:57 | <gsnedders> | I don't even want to consider this |
| 22:01 | <gsnedders> | Hixie: you wouldn't happen to be in the brief, rare state of understanding the AAA? :) |
| 22:01 | <Hixie> | lol |
| 22:02 | <Hixie> | wait, _new_ AAA tests? |
| 22:02 | <gsnedders> | not by you |
| 22:02 | <Hixie> | which tests are these |
| 22:02 | <Hixie> | oh ok good |
| 22:02 | <gsnedders> | https://github.com/html5lib/html5lib-tests/pull/26 includes new AAA tests |
| 22:02 | <Hixie> | i can run them by my implementation and tell you if i pass them... :-) |
| 22:02 | <gsnedders> | I don't want to review them |
| 22:02 | <gsnedders> | because oh-god-the-AAA |
| 22:03 | <Hixie> | i'm not seeing any formatting elements on that page |
| 22:04 | <gsnedders> | look at the individual commits, near the bottom |
| 22:04 | <Hixie> | https://github.com/revite/html5lib-tests/commit/912be08fa4fd82e2dcee7351f0f468aa9f6fa5c3 ? |
| 22:04 | <gsnedders> | there are two new AAA tests I think there |
| 22:04 | <gsnedders> | that's one |
| 22:06 | <gsnedders> | Hixie: FWIW, I'd rather slightly more descriptive commit messages, like saying what the new tests are testing for |
| 22:07 | <Hixie> | noted |
| 22:07 | <gsnedders> | and like, what spec changes are https://github.com/html5lib/html5lib-tests/pull/42 for? |
| 22:08 | <Hixie> | we've removed a few attributes from the list |
| 22:11 | <SamB> | maybe give revision numbers or, heck, links? |
| 22:11 | <gsnedders> | revision numbers are more what I'm looking for here :) |
| 22:12 | <Hixie> | i've no clue |
| 22:12 | <Hixie> | i just copied-and-pasted the spec table into my code |
| 22:12 | <Hixie> | then checked the results to see if they were what i remembered |
| 22:12 | <Hixie> | and they were |
| 22:13 | <SamB> | Hixie: is it true that the reason you don't have a README or Makefile in http://svn.whatwg.org/webapps that the buildsystem involves proprietary software? |
| 22:13 | <jgraham> | gsnedders: No idea what's going on with that PR, the branch is it supposed to be based on is just master |
| 22:13 | <SamB> | hmm, whoops, grammar fail :-( |
| 22:13 | <Hixie> | SamB: no, i just haven't bothered since there's not much point other people generating the spec |
| 22:14 | <SamB> | Hixie: I just want to try to add some interlinks, or maybe play with the JS stuff |
| 22:14 | <Hixie> | (plus my pipeline right now is a disaster anyway) |
| 22:16 | <Hixie> | gsnedders: https://github.com/revite/html5lib-tests/commit/912be08fa4fd82e2dcee7351f0f468aa9f6fa5c3 passes my implementation |
| 22:18 | <Hixie> | gsnedders: https://github.com/revite/html5lib-tests/commit/42289424296cc238bb8afe4c313650d0724985c0 does not |
| 22:18 | <gsnedders> | Hixie: now tell me which is wrong :) |
| 22:18 | <Hixie> | gsnedders: specifically, i disagree with " |45: Unclosed element "code"." |
| 22:18 | <Hixie> | er |
| 22:19 | <Hixie> | with "45: Unclosed element "code"" |
| 22:19 | <Hixie> | though i don't see why |
| 22:19 | <Hixie> | maybe that's a bug in my implementation |
| 22:20 | <Hixie> | oh, i see why |
| 22:20 | <Hixie> | it's redundant with the previous one |
| 22:21 | <gsnedders> | Hixie: can you add a comment on the commit? I think if you mouse-over the line you'll get some message bubble? |
| 22:21 | <gsnedders> | if the test is wrong/ |
| 22:21 | <gsnedders> | *? |
| 22:21 | <Hixie> | already done |
| 22:21 | <Hixie> | also i hate that github comments accept html |
| 22:22 | <gsnedders> | they do…? |
| 22:24 | <SamB> | gsnedders: insofar as github's flavour of markdown does, yes |
| 22:25 | <gsnedders> | "Update for spec changes changing what SVG attributes are changed" — I'm not sure that's a better commit message |
| 22:25 | <gsnedders> | change the change with changes |
| 22:25 | <Hixie> | CHANGE IT |
| 22:26 | <SamB> | gsnedders: huh? |
| 22:32 | <gsnedders> | Hixie: looking at the readme update, I'm just like, "template contents are represented like that? well, okay" |
| 22:32 | <Hixie> | apparently |
| 22:35 | <gsnedders> | jgraham: "Merge 991cc674 adds merged-in commits. Please push the merge manually and follow the instructions." — I can't do that. |