| 00:32 | <zewt> | hooray @ people trying to squelch discussions they don't like by pushing them to lists nobody reads |
| 02:34 | <MikeSmith> | cabanier: regarding http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0029.html it seems like it might be helpful if you actually responded to some of the specific questions Dominic has asked, and the specific proposals he's made |
| 02:34 | <cabanier> | I did't get that reply |
| 02:41 | <MikeSmith> | cabanier: what reply? you didn't reply to anything he wrote on his previous message to you in that thread |
| 02:42 | <cabanier> | MikeSmith: yes. I didn't get his reply |
| 02:42 | <MikeSmith> | " If we added a canvas fallback element as a parameter to scrollPathIntoView, |
| 02:42 | <MikeSmith> | I don't think we'd need drawCustomFocusRing." |
| 02:42 | <Hixie_> | the bottleneck here is me, anyway, not dominic |
| 02:42 | <cabanier> | MikeSmith: sent my reply |
| 02:43 | <cabanier> | Hixie_: I think we can all agree it's confusing either way. Dominic's proposal is just more confusing :-( |
| 02:45 | <cabanier> | Hixie_: I guess the spec doesn't say that the focus area should scroll into view but isn't that expected behavior? |
| 02:45 | <Hixie_> | no, that would be terrible |
| 02:45 | <MikeSmith> | Hixie_: from where I sit it seems to me we may have lost sight of the original problem that Rich was claiming needed to be solved, which this never seems to have been anything more than a workaround for to begin with |
| 02:46 | <Hixie_> | cabanier: imagine if you focus a control on an animated canvas and then scroll it out of view, it shouldn't keep scrolling back 60 times a second |
| 02:46 | <Hixie_> | MikeSmith: i'm not really sure what the original problem was, to be honest |
| 02:47 | <cabanier> | Hixie_: that would only happen if you focus to it. Once focused, you don't scroll back |
| 02:47 | <cabanier> | Hixie_: that's standard browser behavior |
| 02:47 | <Hixie_> | how could drawFocusRing() know if you have just focused it? |
| 02:47 | <MikeSmith> | also Dominic has made the point that there's nothing canvas-specific about the problem so there should be nothing canvas-specific about the proper solution |
| 02:48 | <cabanier> | Hixie_: the browser knows. by calling drawFocusRing, you associate a region of the canvas with a control |
| 02:49 | <Hixie_> | draw focus ring just draws and update the AT data, it doesn't associate regions. are confusing it with the hit region stuff? |
| 02:49 | <cabanier> | Hixie_: no |
| 02:50 | <cabanier> | Hixie_: by calling the focus ring method, you tell the browser that the underlying element has a certain path |
| 02:50 | <MikeSmith> | Hixie_: not you not knowing what the original problem was doesn't argue well for this being kept in the sited, or worse yet, shipped :-) |
| 02:50 | <cabanier> | Hixie_: so the accessibity software can draw boxes around it. You don't have to continually call drawFocusRing to make that happen |
| 02:50 | <MikeSmith> | *in the spec |
| 02:51 | <Hixie_> | MikeSmith: you any idea how many problems i'm discussing at the same time? ain't no way i can remember this stuff :-) |
| 02:51 | <cabanier> | brb |
| 02:51 | <Hixie_> | cabanier: you continually call drawFocusRing to... draw the focus ring |
| 02:51 | <Hixie_> | cabanier: each frame of the animation |
| 02:53 | <MikeSmith> | Hixie_: not blaming you. just saying this has been kind of a mess from the beginning. but it's one thing to be talking about a mess, and another thing to actually be implementing it and shipping it |
| 02:53 | <Hixie_> | i don't really understand what the mess is here |
| 02:53 | <Hixie_> | this API seems to basically work fine |
| 02:54 | <Hixie_> | it's not pretty, but nobody has suggested anything prettier, so... |
| 02:54 | <MikeSmith> | Dominic has suggested just dropping it |
| 02:54 | <Hixie_> | that's not prettier |
| 02:54 | <Hixie_> | that's even worse |
| 02:55 | <Hixie_> | "sorry people with disabilities, guess you can't see what's focused" |
| 02:56 | <MikeSmith> | that's already the case with non-canvas content |
| 02:56 | <Hixie_> | how so? |
| 02:57 | <Hixie_> | non-canvas content is handled by the UA |
| 02:57 | <MikeSmith> | and clearly you're not describing Dominic's sentiment |
| 02:58 | <MikeSmith> | when I'm back at my PC I'll pull up copies of Dominic's message s in that thread |
| 02:59 | <Hixie_> | k... |
| 02:59 | <MikeSmith> | as far as the real problem not being specific to canvas |
| 02:59 | <cabanier> | Hixie_: back |
| 03:00 | <Hixie_> | MikeSmith: do you mean http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0268.html ? |
| 03:00 | <cabanier> | Hixie_: yes. the author draws the ring |
| 03:02 | <cabanier> | Hixie_: but also tell the UA where the bounds of the element are |
| 03:02 | <cabanier> | Hixie_: this allows the UA to scroll to that area of the canvas |
| 03:02 | <Hixie_> | cabanier: my point is just that you can't scroll 60 times a second. |
| 03:02 | <MikeSmith> | Hixie_: yeah, exactly that one. that message from Dominic |
| 03:02 | <cabanier> | Hixie_: and the a11y software to show where the area of the fallback content is |
| 03:03 | <Hixie_> | MikeSmith: i haven't yet replied to that one (as noted earlier, i'm the bottleneck here) but he's wrong that there's no settings to cause the default rendered focus ring to be different. |
| 03:03 | <Hixie_> | MikeSmith: e.g. on mac you can change its color, on windows you can change its width, etc. |
| 03:03 | <cabanier> | Hixie_: well, what happens if you have a focused HTML element and you animate it offscreen? |
| 03:03 | <Hixie_> | cabanier: what does that mean? |
| 03:03 | <MikeSmith> | ok |
| 03:06 | <cabanier> | Hixie_: does the browser scroll to a focused element if you move it offscreen? |
| 03:06 | <cabanier> | Hixie_: I haven't tried it but likely not |
| 03:07 | <cabanier> | Hixie_: so, the browser won't scroll either to update the focus ring. it should be the same behavior |
| 03:08 | <Hixie_> | the reason it doesn't scroll when you animate a focused element off screen is that the browser is not scrolling to it when it draws the focus ring |
| 03:08 | <Hixie_> | just like drawFocusRing() doesn't scroll to it when you draw the focus ring |
| 03:08 | <cabanier> | Hixie_: it does :-) |
| 03:08 | <cabanier> | Hixie_: well, it *should* |
| 03:09 | <Hixie_> | gotta go, bbiab |
| 03:09 | <cabanier> | Hixie_: I think that's what Dominic is saying too except he just wants the scrolling |
| 03:09 | <cabanier> | k |
| 03:11 | <cabanier> | Hixie_: ah. Dominic's code doesn't scroll! |
| 03:11 | <cabanier> | Hixie_: ok. we need to add that to the spec |
| 03:31 | <DiegoViane> | Zzz |
| 03:54 | <Hixie_> | cabanier: it makes no sense for _painting_ code which is called 60 times a second to scroll. |
| 03:54 | <cabanier> | Hixie_: no |
| 03:54 | <cabanier> | Hixie_: you only scroll if you're offscreen |
| 03:54 | <Hixie_> | cabanier: it makes no sense for _painting_ code which is called 60 times a second to scroll, whether or not you're off-screen |
| 03:54 | <cabanier> | Hixie_: once onscreen, you never scroll again |
| 03:54 | <Hixie_> | so the user scrolls it off screen and you scroll again? |
| 03:54 | <Hixie_> | that makes no sense |
| 03:55 | <Hixie_> | painting code shouldn't scroll |
| 03:55 | <cabanier> | Hixie_: only if you tab again |
| 03:55 | <Hixie_> | the method is called every 16ms, it doesn't know if the element was focused already or not |
| 03:55 | <Hixie_> | i just don't understand why this would even be something we'd consider |
| 03:56 | <Hixie_> | scrolling happens, if it happens, when the user focuses the control; there's other APIs for that |
| 03:56 | <cabanier> | the method doesn't know, but the browser does |
| 03:56 | <cabanier> | what API? |
| 03:56 | <Hixie_> | ...the method is the browser. |
| 03:56 | <Hixie_> | scrollPathIntoView(), for instance |
| 03:57 | <cabanier> | there's no API when you tab into a control. the browser scrolls to it automatically |
| 03:57 | <Hixie_> | or just scrollIntoView(), depending on what needs to be scrolled |
| 03:57 | <Hixie_> | sure, just like there's no non-canvas API when you tab into a control to draw the control's focus ring. |
| 03:57 | <Hixie_> | if you're creating a control in canvas, you have to implement the control |
| 03:57 | <cabanier> | sure |
| 03:58 | <cabanier> | but drawfocusring lets you associate a path with a focused control |
| 03:58 | <cabanier> | so you should scroll towards that path |
| 03:58 | <cabanier> | otherwise the API is not good |
| 03:58 | <Hixie_> | drawFocusRing doesn't associate a path with a focused control. it just draws the focus ring and possibly adjusts AT parameters. |
| 03:59 | <cabanier> | but should a focus ring be scrolled so it's visible? |
| 03:59 | <cabanier> | it should follow the same convention as regular focus rings |
| 04:00 | <Hixie_> | depends on what the author wants. if the author wants that, then that's what the scroll*() APIs are for |
| 04:00 | <cabanier> | why would you ever not want that? |
| 04:01 | <cabanier> | if an element becomes focused, it should always be scrolled into view |
| 04:02 | <cabanier> | while focused, it's ok to scroll out of view |
| 04:03 | <cabanier> | too bad Rich is on vacation |
| 04:06 | <Hixie_> | suppose the user presses some hot key that brings in a control, sliding it in from the top of page. it needs the focus ring drawn on the whole time, but you only want to scroll the viewport to the final location. |
| 04:07 | <cabanier> | yes |
| 04:07 | <cabanier> | that would be problematic |
| 04:08 | <cabanier> | it would only scroll to where it comes in today |
| 04:08 | <cabanier> | doesn't that happen in HTML too? |
| 04:08 | <cabanier> | (I've never tried that) |
| 04:15 | <cabanier> | Hixie_: I just tried it. the HTML control disappears |
| 04:16 | <cabanier> | com'on jsfiddle |
| 04:18 | <cabanier> | http://codepen.io/anon/pen/ckshA |
| 04:19 | <cabanier> | tab to the controls. the second control will fly offscreen when focused |
| 04:19 | <cabanier> | if you turn off the transition, the browser will scroll |
| 05:12 | <zcorpan> | Hixie_: re parameter to scrollPathIntoView, note that scrollIntoView et al now has a parameter to hint about smooth scrolling |
| 05:31 | <zewt> | heh, i recall having major migraine-level headaches trying to deal with old android browser's scrollTo doing async smooth scrolling instead of immediate scrolling |
| 08:20 | <MikeSmith> | zcorpan: btw thanks for the review of the conformance-checker tests |
| 08:21 | <zcorpan> | np |
| 08:21 | <zcorpan> | ping me when you have more |
| 08:21 | <MikeSmith> | will do |
| 08:22 | <MikeSmith> | in the mean time as far a validator stuff I'm planning to add a build option for running the validator with the parser in non-streaming mode |
| 08:23 | <zcorpan> | why? |
| 08:23 | <MikeSmith> | for people who want to run a service that can process docs with non-streaming error recovery |
| 08:24 | <MikeSmith> | so that it doesn't stop with "Can't recover from last error" messages |
| 08:24 | <MikeSmith> | bad idea? |
| 08:24 | <zcorpan> | have people asked for that? |
| 08:25 | <MikeSmith> | http://lists.w3.org/Archives/Public/www-validator/2013Sep/0041.html |
| 08:25 | <MikeSmith> | "I have to pay extra money for each of these rechecks. As an end user, what I expect is being reported for all errors found at the document, and if I have to pay several times to get a full validation report of my document, I find that unfair." |
| 08:26 | <zcorpan> | v.nu also skips subtrees of misplaced elements |
| 08:26 | <MikeSmith> | you mean v.nu as compared to the W3C service? |
| 08:27 | <Ms2ger> | People pay to validate their stuff? |
| 08:27 | <MikeSmith> | heh |
| 08:27 | <MikeSmith> | Ms2ger: some people |
| 08:27 | <zcorpan> | no, both |
| 08:27 | <Ms2ger> | Fascinating |
| 08:28 | <Ms2ger> | On another note, I'll be intermittently available from this afternoon, like the rest of Mozilla |
| 08:28 | <MikeSmith> | zcorpan: that's the same case, right? it wouldn't skip them in non-streaming mode |
| 08:28 | <zcorpan> | MikeSmith: no |
| 08:28 | <zcorpan> | hold on |
| 08:29 | <MikeSmith> | Ms2ger: please do some magic in your remaining time today to up-priortize the build bug I reported |
| 08:29 | <zcorpan> | MikeSmith: consider <div><li><span invalid=""></span></li></div> |
| 08:29 | <Ms2ger> | MikeSmith, number? |
| 08:30 | MikeSmith | nods |
| 08:30 | <zcorpan> | Error: Element li not allowed as child of element div in this context. (Suppressing further errors from this subtree.) |
| 08:30 | <MikeSmith> | Ms2ger: hang on will get it |
| 08:30 | <Ms2ger> | MikeSmith, have you tried turning it off and on again? ;) |
| 08:30 | <MikeSmith> | Ms2ger: 923196 |
| 08:31 | <MikeSmith> | Ms2ger: tried kicking it |
| 08:31 | <MikeSmith> | zcorpan: lemme try that right now in non-streaming mode |
| 08:31 | <zcorpan> | MikeSmith: i think it has nothing to do with streaming :-) |
| 08:32 | <zcorpan> | MikeSmith: hsivonen implemented the suppressing to make the validator more useful |
| 08:33 | <zcorpan> | because it's useless to give lots of errors of a subtree that might go away when the author fixes the first error |
| 08:33 | <MikeSmith> | ok |
| 08:33 | <MikeSmith> | yeah, same error in non-streaming mode |
| 08:34 | <MikeSmith> | and yeah I see your point |
| 08:34 | <zcorpan> | maybe people expect the validator to whine about the invalid="" attribute there, though, i dunno |
| 08:35 | <zcorpan> | i guess the guy who pays per validation wants as many errors as possible |
| 08:35 | <MikeSmith> | heh |
| 08:36 | <MikeSmith> | yeah, though it sounds funny to put it that way |
| 08:36 | <MikeSmith> | anyway I was not planning to spend a bunch of time on it |
| 08:37 | <MikeSmith> | implementing the switch to provide a non-streaming mode would probably take me 30 minutes |
| 08:38 | <zcorpan> | maybe you could suggest a different payment strategy, so instead of number of validations, you pay for actual processing time in the validator. |
| 08:39 | <MikeSmith> | interesting |
| 08:39 | <MikeSmith> | yeah that would make a lot more sense |
| 08:40 | <MikeSmith> | a person whose page has 900 errors on it will take more time to process than a person whose page has one or none |
| 08:40 | <MikeSmith> | and more machine resources |
| 08:42 | <zcorpan> | isn't it more about the size of the page? the same checks need to be made whether it gives an error or not |
| 08:42 | <MikeSmith> | not for the case of microsyntax checking |
| 08:42 | <MikeSmith> | and probably other cases too |
| 08:43 | <MikeSmith> | but yeah I guess it's much more about the size of the page |
| 08:43 | <MikeSmith> | in general |
| 08:43 | <MikeSmith> | ah I see what you're saying |
| 08:43 | <MikeSmith> | yeah even for microsyntax checking |
| 08:54 | <zcorpan> | MikeSmith: this is interesting: "The W3C errors jumped to 45 errors so I undo that action." http://wordpress.org/support/topic/w3c-validation-stray-end-tag-div-errors |
| 08:55 | <zcorpan> | MikeSmith: one fatal error is considered less bad than 45 non-fatal errors |
| 08:55 | MikeSmith | looks |
| 08:56 | <MikeSmith> | heh |
| 08:56 | <MikeSmith> | wow |
| 08:58 | <MikeSmith> | I can seriously imagine paying customers complaining about that actually |
| 08:59 | <MikeSmith> | "I paid you last month for validation of my page and it said I had only one error. This month I validate the same page and it says I have 45 errors!!" |
| 08:59 | <MikeSmith> | regression |
| 09:00 | <zcorpan> | so i guess that's a bad property of suppressing errors in general, it's moving the perceived goalposts which is probably very depressing |
| 09:00 | <MikeSmith> | very glad I'm not involved at all with trying to monetize validation |
| 09:00 | <MikeSmith> | zcorpan: yeah |
| 09:00 | <MikeSmith> | the bottom line is that many people are validating their pages for the wrong reasons to begin with |
| 09:01 | <zcorpan> | like "one error? sure lemme fix it. 45 errors!? GTFO if i fix one more will it be 900 errors?" :-) |
| 09:03 | <MikeSmith> | haha |
| 09:03 | <MikeSmith> | yeah, like that |
| 09:06 | <zcorpan> | i recall hsivonen talking about a parsing mode that is streaming but doesn't do the spec's recovery for non-streamable errors (a few years ago) |
| 09:07 | <MikeSmith> | huh? that sounds |
| 09:07 | <MikeSmith> | ...just like the existing default behavior |
| 09:08 | <MikeSmith> | well not default in the parser, but default in the v.nu code |
| 09:08 | <zcorpan> | i mean doing different recovery than the spec. so e.g. <body><html class=foo> would not set the class attribute on the root element, </body> </html>x would drop the space and insert the x in body |
| 09:08 | <MikeSmith> | ah |
| 09:10 | <zcorpan> | it would not validate the attributes on the <html>, but it would be streaming and non-fatal |
| 09:11 | <MikeSmith> | yeah |
| 09:11 | <MikeSmith> | I don't remember that |
| 09:11 | <MikeSmith> | was it just a thought experiment or had he implemented something? |
| 09:12 | <zcorpan> | it was probably around the time the spec's parser was first specified |
| 09:13 | <zcorpan> | or i might be making it up |
| 09:23 | <zcorpan> | MikeSmith: there's also the opposite problem: a typoed formatting end tag can cause lots of errors because it gets reopened everywhere |
| 09:24 | <zcorpan> | that's also something that non-spec recovery could fix (never reopen formatting elements) |
| 09:29 | <MikeSmith> | zcorpan: yeah |
| 09:34 | <MikeSmith> | I think there are a number of cases where having non-spec handling would give more intuitive errors on the validator |
| 09:41 | <zcorpan> | <p><ul></ul></p> could have a better message too, e.g. by keeping track of whether the last <p> was implicitly closed and by what |
| 09:56 | <MikeSmith> | zcorpan: yeah |
| 10:00 | <MikeSmith> | that one seems tough if we also want to do the same for similar elements that can implicitly be closed |
| 10:01 | <MikeSmith> | potentially have to keep a lot of information around in the parser |
| 10:40 | <zcorpan> | there's a small set of elements that can be implicitly closed, and you only need one flag per element type |
| 10:41 | <zcorpan> | well, and a position for the last token that closed it |
| 10:41 | <zcorpan> | but still, not a lot of information |
| 10:42 | <zcorpan> | maybe you need to keep track of the <p>'s parent too so you can reset the flag when the parent is closed |
| 11:48 | <MikeSmith> | zcorpan: yeah |
| 11:53 | <MikeSmith> | zcorpan: btw about the "Suppressing further errors from this subtree." case that behavior's basically hard-coded into our branch of jing so I couldn't easily provide an option for overriding it even if I wanted to |
| 11:54 | <zcorpan> | why would you provide an option? |
| 11:56 | <MikeSmith> | I dunno, because that'd be the next thing that somebody would ask for after the recover-from-non-streaming-error option |
| 11:57 | <gsnedders> | zcorpan: Also consider the case where one mis-closed element causes a ton of parse errors because the stack of open elements isn't what is intended. |
| 11:58 | <zcorpan> | i wouldn't provide any options for either of those :-) |
| 11:58 | <gsnedders> | idk! I'm just trying to be useful! |
| 11:58 | gsnedders | curls up and cries |
| 11:59 | <zcorpan> | gsnedders: ? i was replying to MikeSmith |
| 12:00 | <zcorpan> | gsnedders: what case do you mean? |
| 12:00 | <gsnedders> | Oh, don't mind me. I'm not that deeply thinking about this. I could be totally wrong. |
| 12:04 | MikeSmith | curls up and cries while puffing on a blunt |
| 13:54 | <zcorpan> | MikeSmith: i've written some notes on how the parser could be modified to be streaming with different recovery |
| 13:54 | <zcorpan> | http://bugzilla.validator.nu/ says Gateway Time-out for me |
| 14:30 | <zcorpan> | http://lists.w3.org/Archives/Public/www-archive/2013Oct/0009.html |
| 16:56 | <dglazkov> | good morning, Whatwg! |
| 17:05 | <Roujo> | dglazkov: 'morning ^^ |
| 18:41 | <Domenic_> | Hixie_: was there ever consideration for a way of linking buttons and dialogs? e.g. https://gist.github.com/rpflorence/6814517 |
| 18:46 | <Hixie_> | not only was there consideration, it's in the spec. |
| 18:48 | <Domenic_> | lollll |
| 18:50 | <Domenic_> | can't find it in http://developers.whatwg.org/commands.html#the-dialog-element, hmm |
| 18:50 | <Hixie_> | looks like there's no example of it in the spec |
| 18:50 | <Hixie_> | <dialog> <form method=dialog> <input type=submit> </form> </dialog> |
| 18:51 | <Domenic_> | huh... |
| 18:52 | <Domenic_> | what about opening the dialog |
| 18:52 | <Domenic_> | oh nice dialog affects autofocus, that is awesome! |
| 19:00 | <Hixie_> | not sure what you're looking for when opening the dialog |
| 19:05 | <TabAtkins> | Click a button -> dialog opens, presumably. |
| 19:05 | <TabAtkins> | Like <details>, but with a popup. |
| 19:05 | <TabAtkins> | Actually, though, that's basically just <details>. Style it when [open] to look like a popup. |
| 19:06 | <ryanflorence> | so why have both? |
| 19:08 | <TabAtkins> | ryanflorence: I was just now exploring my thoughts, not trying to justify anything. It may be that <details> is enough for this case. |
| 19:09 | <Domenic_> | Feels related to contextmenu attribute on buttons. |
| 19:09 | <ryanflorence> | I missed the beginning of the conversation in here but I started it on twitter, is the feeling we don't need a declarative dialog? |
| 19:10 | <TabAtkins> | Nonono, unrelated. |
| 19:14 | <Domenic_> | Using details for this is no good |
| 19:14 | <Domenic_> | Or rather, very weird. |
| 19:15 | <Domenic_> | Augh I should not try to engage in discussions from iPad keyboard. Shutting up now until my laptop recharges. |
| 19:16 | <ryanflorence> | your command of capital letters on the ipad though is impressive |
| 19:38 | <rektide> | this is insane. the discrepancy between CSSStyleSheet and HTMLStyleSheet make up a vast flabbergasting chasm of WTF. https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet.insertRule?redirectlocale=en-US&redirectslug=Web%2FAPI%2FCSSStyleSheet%2FinsertRule#Example_2 |
| 19:39 | <rektide> | it is way way too hard to get to doing absolutely trivial things like adding a single rule to a document |
| 19:39 | <rektide> | in that it's extremely likely one will run face first into 12 different ways where you cannot quite get there from here- but nice try, that was close |
| 19:39 | <rektide> | awful |
| 19:40 | <rektide> | thanks #whatwg emotional support group |
| 19:40 | <TabAtkins> | There's no such thing as HTMLStyleSheet. There's an HTMLStyleElement, which is a completely different thing from a stylesheet. It *contains* a stylesheet. |
| 19:41 | <rektide> | ah but taht style sheet isn't read only, the property of the HTMLStyleElement is read only |
| 19:41 | <rektide> | ok that's not entirely useless then. my mistake on the name. |
| 19:41 | <TabAtkins> | The stylesheet on <style> is readonly? |
| 19:41 | <rektide> | yes, .style is read only according to mdn |
| 19:41 | <rektide> | errr i probably don't have that property name right do i.. one moment |
| 19:42 | <Jasper> | Hixie_, while we're working on Path for Canvas2D, can I recommend a way to get the current working path and clip path? |
| 19:42 | <Jasper> | Hixie_, if only for debugging |
| 19:42 | <rektide> | .sheet |
| 19:42 | <rektide> | i don't understand why the MDN code is ok |
| 19:43 | <zcorpan> | rektide: the .sheet attribute is readonly, but that just means you can't assign to it. the stylesheet is mutable |
| 19:43 | <rektide> | they appendChild onto the head element, and then look for the last style element. but wouldn't that appended child show up somewhere in the page? |
| 19:43 | <rektide> | with any style elements in the body following after it |
| 19:43 | <TabAtkins> | rektide: Yeah, a readonlya ttribute just means that the object itself can't be replaced. |
| 19:43 | <rektide> | zcorpan: right, somehow TabAtkins quick line made that click, and you said what i just said now |
| 19:43 | <TabAtkins> | It doesn't mean the object there is readonly. |
| 19:43 | <rektide> | ayup ayup |
| 19:44 | <TabAtkins> | Also, that example 2 is really terrible code. |
| 19:44 | <jgraham> | It is not like "mut" in Rust |
| 19:44 | <rektide> | i don't see alternatives! |
| 19:44 | <TabAtkins> | Seriously, detecting Safari for a bugfix by checking for window.createPopup? |
| 19:44 | <jgraham> | </unhelpful-comparison> |
| 19:44 | <rektide> | this is just ugly ugly stuff to do |
| 19:45 | <rektide> | line 27 though in particular |
| 19:45 | <rektide> | i think isn't ugly enough to actuall ywork |
| 19:45 | <rektide> | because the body hight have it's own style elements |
| 19:45 | <TabAtkins> | Why does line 27 exist? You can do "style.sheet" instead. |
| 19:45 | <TabAtkins> | And yes, it's incorrect for that reason. |
| 19:45 | <rektide> | oh yay |
| 19:46 | <rektide> | i'll kill this for loop i added to their codebase |
| 19:46 | <TabAtkins> | It looks like most of the complication in this code is due to unnecessary workarounds caused by misunderstanding. |
| 19:46 | <rektide> | thank you TabAtkins &all |
| 19:48 | <rektide> | oh flip me, why is there no insertRule function on the style sheet |
| 19:48 | <TabAtkins> | There... is. |
| 19:48 | <TabAtkins> | styleEl.sheet.insertRule exists. |
| 19:50 | <TabAtkins> | Also, note that objects are iterated in insertion order. That's specified, and I *think* browsers implement that. |
| 19:50 | <rektide> | once appended to the document |
| 19:50 | <rektide> | in Chrome-unstable |
| 19:50 | <rektide> | ahh interesting |
| 19:50 | <TabAtkins> | Well yeah. Before it's in the document, it doesn't have a stylesheet at all. |
| 19:51 | <TabAtkins> | It's not that the stylesheet lacks an insertRule function, it's the "el.sheet" returns null before el is inserted into the document. |
| 19:51 | <TabAtkins> | rektide: Is this your code in the wiki? Or just code that you're trying to follow/maintain? |
| 19:55 | <Hixie_> | Jasper: you mean the one on the context? |
| 19:55 | <Hixie_> | Jasper: i looked into doing that, i don't recall why i didn't do it... |
| 19:55 | <Hixie_> | Jasper: what do you want to do with it exactly? |
| 19:55 | <Jasper> | Hixie_, just debug |
| 19:55 | <Hixie_> | how? |
| 19:55 | <Jasper> | Hixie_, visualize what my current clip state is, or dump what the current path is |
| 19:55 | <rektide> | these insertRules are firing now but not doing anything |
| 19:55 | <rektide> | TabAtkins: https://github.com/rektide/greyelershian/blob/master/greyelershian.user.js#L44 |
| 19:56 | <Jasper> | Hixie_, perhaps I'd take the clip path and draw it to a separate canvas overlaid on top in transparent red |
| 19:56 | <Jasper> | Hixie_, so, have you seen the absolutely crazy thing I'm building? |
| 19:56 | <rektide> | it's a userscript to make Google notices appear in grey, not red. |
| 19:57 | <Hixie_> | Jasper: to visualise your lip state, just draw a huge rectangle. |
| 19:57 | <Hixie_> | clip, not lip. |
| 19:57 | <Hixie_> | Jasper: i have not |
| 19:58 | <Jasper> | Hixie_, the URL will probably scar you for life |
| 19:58 | <Jasper> | Hixie_, http://magcius.github.io/xserver.js/demo/ |
| 19:59 | <rektide> | missing semicolon spotted. merciful merciful wetware errors. |
| 19:59 | <rektide> | wait no. .gb_jb { background-color: rgb(102, 102, 102); transition: background-color 1.2s } , what is wrong with you |
| 19:59 | <rektide> | oh spaces that's it isnt it |
| 20:00 | <Jasper> | Hixie_, I'm redoing X drawing semantics in canvas so that every window draws to the same front buffer, but clipped to their visible area. |
| 20:01 | <Hixie_> | Jasper: i wish i could tell you i'd never seen someone do this before |
| 20:01 | <rektide> | there's still no change to this style sheet after i insertRule. and nothing is being thrown. |
| 20:01 | <Hixie_> | Jasper: (not necessarily exactly the same, but same idea) |
| 20:01 | <Jasper> | Hixie_, this isn't just the "fake OS" thing with DOM or something. This accurately implements a front-buffer and how windows draw to it. |
| 20:02 | <Hixie_> | Jasper: fair enough |
| 20:02 | <Jasper> | Hixie_, so yeah, sometimes I'm clipped five levels deep and I can't really just draw a rectangle to see my current clip because another client might overwrite it. |
| 20:04 | <Jasper> | It's quite fun to write, too: https://github.com/magcius/xserver.js/blob/gh-pages/src/clients/xeyes.js |
| 20:04 | <Hixie_> | draw a rectangle, then call window.alert() |
| 20:04 | <Hixie_> | or debugger; |
| 20:05 | <Jasper> | Hixie_, I suppose that's an idea... |
| 20:06 | <rektide> | insertRule is not doing anything.... aaagggggggggg |
| 20:06 | <TabAtkins> | rektide: It works fine over here, so I have no idea what the problem is that you're seeing. |
| 20:10 | <rektide> | ah. so the style sheet updates when you insertRule but the HTMLStyleElement doesnt reflect that change |
| 20:10 | <rektide> | one bad assumption on my part |
| 20:10 | <TabAtkins> | Yeah, the text contents dont' change. |
| 20:10 | <rektide> | the rules exist, their priority is just being smashed by someone else i'm guessing |
| 20:10 | <TabAtkins> | Throw an !important on those things. |
| 20:16 | <rektide> | can i run queryselectors on computed styles? |
| 20:17 | <rektide> | or is querySelector truly only for actual attributes? |
| 20:17 | <TabAtkins> | I'm not sure what you mean. querySelector selects elements in the tree that match a given selector. |
| 20:17 | <rektide> | [id="foo"] is an attribute selector for things id'ed as foo |
| 20:18 | <TabAtkins> | If you can do it in a selector in a stylesheet, you can do it in querySelector(). Nothing more, nothing less. |
| 20:18 | <rektide> | i figured the answer was no |
| 20:19 | <rektide> | my ask though, since it's still hazy |
| 20:19 | <TabAtkins> | I still don't know what you were actually asking about, so shrug. |
| 20:20 | <rektide> | was to be able to find all elements that have a style, whether it's directly on the element or whether the element only has that property because it has been cascaded onto it |
| 20:20 | <rektide> | i'm looking for red things |
| 20:20 | <TabAtkins> | You can't do that with a selector. |
| 20:20 | <rektide> | nope you cannot i concur |
| 20:21 | <rektide> | and alas there's nothing fixed i'm going to be able to select on the google homepage. the classes changed since yesterday. |
| 20:21 | <TabAtkins> | Note, for your use-case, that the classes used by Google stuff changes over time, as they're generated by a CSS compiler and have no guarantee of stability. |
| 20:21 | <rektide> | hence my ask for a search function to not have have to get all elements and loop through them myself |
| 20:22 | <rektide> | "find red" would've been handy here |
| 20:22 | <rektide> | i suppose i could search the style sheet for red to select the selector repsonsible |
| 20:22 | <rektide> | fine |
| 20:22 | <rektide> | this isn't ugly |
| 20:22 | <rektide> | twist my arm |
| 20:22 | <rektide> | stupid well indexed systems, showing me off |
| 20:23 | <TabAtkins> | Heh. |
| 20:23 | <TabAtkins> | But seriously, that mdn code needs to be thrown out. It's terrible. |
| 20:23 | <rektide> | it brought me much closer to the end of my rope on this one |
| 20:24 | <rektide> | i'm glad you've identified the 'by order inserted' potential though, that makes me happier that it's probably not flagrantly outright wrong |
| 20:59 | <rektide> | "Object #<StyleSheetList> has no method 'find'" |
| 21:00 | <rektide> | is parity between Array and DOM list'y stuff an objective, or will we not see a .find, .some, &c ? |
| 21:15 | <TabAtkins> | rektide: Everything that looks kinda like an Array but isn't, is a terrible mistake and we're trying to fix them. |
| 21:16 | <rektide> | TabAtkins: godspeed sovereign warriors. thanks for the work, thanks for the reply. |
| 21:16 | <rektide> | glad to hear there's some concordance that the state now ought not be the way of it |
| 21:17 | <TabAtkins> | rektide: I've also revised the MDN function to make it less terrible. It's possible that it's now less portable to old browsers, but that can be fixed by someone else I guess. |
| 22:14 | <dev11> | why when embeding video from youtube I see small black border below the video inside the iframe? |
| 22:17 | <rektide> | are there any structured representations of a CSS color? |
| 22:18 | <rektide> | i need to convert an rgb(r,g,b) into an rgb(r,g,b,a) property. i can do it manually sure but if there's something in the DOM that actually has a structure for what colors are I'd prefer to use that |
| 22:20 | <rektide> | i guess the latter is rgba(r,g,b,a) |
| 22:31 | <rniwa> | Hixie_: yt? |
| 22:39 | <Hixie_> | yo |
| 22:39 | <Hixie_> | (i pumpkinise in 20 minutes) |
| 23:39 | <TabAtkins> | rektide: No, CSS always returns colors as a string that you have to parse. Browsers do this in different manners, unfortunately. |
| 23:39 | <TabAtkins> | rektide: We've been planning for a while to provide a more structured version of this shit. |