| 00:00 | <TabAtkins> | There've been proposals to add a value that explicitly turns off a decoration inherited from an ancestor, and I know this was in a spec at some point, but I can't find it now. |
| 00:02 | <boogyman> | So,would it be possible to define pseudo-elements as shadow-dom, then someone can apply the full gambit. |
| 00:02 | <TabAtkins> | ? |
| 00:04 | <boogyman> | " text decorations are inherited separately from the text-decoration property" |
| 00:05 | <TabAtkins> | Yeah, what does shadow dom have to do with this? |
| 00:06 | <boogyman> | If the pseudo-element created via ::after{ content:"something"; } becomes shadow-dom, doesn't that mean text decorations could be applied as I expect |
| 00:06 | <joeedh> | Hi. Is it possible for canvas2d's .drawImage method to change the clipping region? |
| 00:06 | <TabAtkins> | Shadow dom inherits text decorations just like normal dom. As far as CSS is concerned it's all one big mushed up tree. |
| 00:07 | <TabAtkins> | joeedh: What do you mean? |
| 00:08 | <joeedh> | Let's say I've rendered a bunch of vector paths into seperate canvas instances, and I want to composite them together. |
| 00:09 | <joeedh> | At this point the paths are already rendered, but I still want to be able to use them for clipping. |
| 00:10 | <boogyman> | So, is there an adhoc solution? |
| 00:10 | <joeedh> | For example, I might want to draw a thick blurred stroke over a filled path, but not have the stroke draw outside of that path. |
| 00:11 | <TabAtkins> | drawImage doesn't do anything with clipping (besides being able to dictate the source and destination rectangles). It's *affected* by clipping, but clipping itself can only be affected by using the vector stuff directly. |
| 00:11 | <TabAtkins> | boogyman: Dont' set text-decoration on ancestors. |
| 00:12 | <joeedh> | TabAtkins: eek. |
| 00:13 | <joeedh> | TabAtkins: the multiple-canvas layered approach can give you a huge speedup. but I need some way to affect clipping. |
| 00:13 | <TabAtkins> | I'm not sure of implementation status, but you can always do your vector stuff into a Path2D object, and then use that for both stroking/filling in one canvas, and clipping in another. |
| 00:14 | <Philip`> | joeedh: You might be able to put the filled-path image on a transparent canvas, then composite the stroked image with source-atop or something like that (so that it only draws to pixel that are opaque in the filled image) |
| 00:14 | <joeedh> | actually, I came up with that idea after writing a prototype GPU vector graphics rasterizer, since that's how it's design was evoloving. |
| 00:14 | joeedh | wanted to make the canvas2d version of his idea work, since otherwise he might have to drop mobile support for his app. |
| 00:15 | <TabAtkins> | Yeah, sounds like compositing should do the trick for you actually. |
| 00:15 | <joeedh> | Philip: that sounds like it should work. |
| 00:20 | <joeedh> | ooh it worked |
| 00:30 | <gsnedders> | Am I the only one who gets confused when Philip` reappears? |
| 00:30 | <Philip`> | No, I do too |
| 00:31 | <gsnedders> | What are you actually doing now? I presume working somewhere not-web-related? |
| 00:31 | <MikeSmith> | I’m very glad to see Philip` around whenever he shows up |
| 00:32 | <MikeSmith> | but yeah Philip` seems like you been showing up a bit more lately |
| 00:32 | <Philip`> | gsnedders: Yes (or at least in a non-web-related part of a quite-web-related company) |
| 00:34 | <MikeSmith> | company.. I had in mind that you were still operating in academia |
| 00:34 | <MikeSmith> | but I guess you probably got your PhD ages ago and moved on |
| 00:35 | <MikeSmith> | I seem to remember you were doing work in astrophysics or simiarl |
| 00:35 | <Philip`> | Yeah, I think I spent enough time in university and it seemed best to move on :-) |
| 00:36 | <Philip`> | Maybe you're thinking of jgraham? (I was just doing CS) |
| 00:39 | <MikeSmith> | ah yeah I guess I had conflated that part with jgraham |
| 01:27 | <gsnedders> | Philip`: I'm curious as to what :P |
| 01:27 | <gsnedders> | MikeSmith: but yeah, jgraham did astrophysics |
| 01:27 | <gsnedders> | though that must've been… what, 2008 when he finished? |
| 01:28 | gsnedders | wonders how long ago Philip` graduated now… |
| 02:30 | <joeedh> | argh college. |
| 02:32 | joeedh | accidentally educated himself to graduate level. he does research and, well, the thought of doing a phd program isn't very inspiring |
| 02:34 | <joeedh> | especially CS phd programs, if you know what I mean |
| 03:06 | <gsnedders> | joeedh: tbf, if you're calling it college, I assume you're American where PhD programmes are far longer |
| 03:06 | <joeedh> | yeah |
| 03:15 | <joeedh> | we have terrible universities. I don't like studying under professors who are less educated than I am. |
| 03:27 | <joeedh> | btw, does anyone else hate the antialiasing filter most SVG renderers use? |
| 03:31 | joeedh | once had to import a bunch of icons into Blender, just so he could render them with it's better AA reconstruction filters. |
| 03:31 | <pdr> | joeedh, what antialiasing filter? |
| 03:33 | <joeedh> | if you antialias by rendering your work bigger and downsizing (supersampling) it's the filter used to downsize. |
| 03:36 | <joeedh> | https://en.wikipedia.org/wiki/Anti-aliasing_filter . it's the trade off between blurryness, on the one hand, and jaggies. |
| 03:37 | <joeedh> | . . .if you have coworkers who use Illustrator, but provide you with .svg's, it's very embarassing when you can't render them cause the AA filter is too blurring, in pretty much all SVG apps. |
| 03:38 | <joeedh> | . . .especially when rendering said .svg is part of the build process, and you have to then render in their machine's Illustrator (or blender), and embedd the result as an image in the svg, but not too bit or not too small. . . |
| 03:39 | <joeedh> | there are some good examples of blender's filters here: https://www.blender.org/manual/render/blender_render/antialiasing.html |
| 03:44 | <pdr> | joeedh, interesting. I wouldn't have expected any AA filtering beyond what's used to draw the paths themselves. |
| 03:45 | <joeedh> | if the paths are supersampled, they have to be filtered by definition. |
| 03:46 | <joeedh> | if the paths use some other method, you should still be able to effect a filter (make it look more sharper or more blurrier). |
| 08:20 | <MikeSmith> | zcorpan: thanks for your patience in https://github.com/whatwg/html/issues/644#issuecomment-188647346 (the <time> text issue) |
| 08:21 | <MikeSmith> | I seriously did not know that style and script and title had that behavior for the text IDL attribute |
| 08:21 | <MikeSmith> | or possibly I knew once and forgot |
| 09:06 | <annevk> | nox: is there any API where the named properties are enumerable? |
| 09:28 | <annevk> | There are plenty in HTML apparently |
| 09:28 | <annevk> | Should have looked there before asking |
| 10:13 | <annevk> | Since MIME Sniffing is no longer actively maintained, I plan on landing the proposed PRs in https://github.com/whatwg/mimesniff/pulls when the basic issues with them have been resolved. |
| 10:13 | <annevk> | So now would be a good time to take a look there and object. |
| 10:13 | <annevk> | After that I'll try to make some additional edits so it looks more or less like the other WHATWG projects. |
| 10:19 | <ritsyy> | annevk: there is this bug too https://www.w3.org/Bugs/Public/show_bug.cgi?id=28094 , will file a PR for this |
| 10:43 | <nox> | annevk: Why wouldn't it work for Window? |
| 10:44 | <annevk> | nox: because a "named getter" on Window actually acts on its NamedProperties object (or whatever it's called) |
| 10:45 | <annevk> | nox: so there's a level of indirection between the placement of the extended attribute and where it needs to act |
| 10:46 | <nox> | annevk: That seems like it doesn't concern whether they are enumerable or not. |
| 10:50 | <annevk> | nox: I guess that would make sense, since it's such a special case |
| 10:51 | <nox> | annevk: I mean the special case is just about where the named properties actually are, right? |
| 10:51 | <nox> | Not whether they should be enumerable, no? |
| 11:05 | <JakeA> | annevk: is request.origin described anywhere, or is it just hand-waving? |
| 11:09 | <annevk> | JakeA: not as an API, thus far |
| 11:10 | <annevk> | JakeA: https://fetch.spec.whatwg.org/#concept-request-origin exists though |
| 11:11 | <JakeA> | annevk: gotcha, cheers |
| 11:30 | <annevk> | nox: yeah, but maybe it should, or maybe IDL shouldn't define this at all since it's only for the Window object, it's rather weird |
| 11:30 | <annevk> | nox: oh well, probably something for the eventual IDL fixup |
| 11:33 | <nox> | annevk: It's for all Global interfaces, no? |
| 11:34 | <annevk> | nox: sure, but there's only one where it matters |
| 11:35 | <annevk> | nox: this is similar to Unforgeable for interfaces, in practice only Location is using that (we're changing that setup now so it can be removed for interfaces from IDL) |
| 11:43 | <nox> | annevk: Ah. |
| 11:43 | <nox> | annevk: Why, btw? And what's the replacement? |
| 11:50 | <annevk> | nox: putting Unforgeable directly on all members, plus some prose that is specific to Location |
| 11:50 | <annevk> | (also, no other object should ever use this setup) |
| 11:51 | <nox> | annevk: Y, I hate prose. :( |
| 11:51 | <nox> | annevk: Prose is bad for codegen. :( |
| 11:51 | <annevk> | You cannot codegen Location anyway |
| 11:52 | <nox> | How so? |
| 11:52 | <annevk> | Because it's super exotic |
| 11:52 | <nox> | I'm wondering what we miss in Servo then, because there is nothing about it that we don't codegen. |
| 11:52 | <annevk> | probably the web's security model? |
| 11:52 | <nox> | What's so exotic about it that it can't be codegen? |
| 11:52 | <Ms2ger> | Yep |
| 11:53 | <Ms2ger> | We just return null for cross-origin contentWindow |
| 11:53 | <nox> | How is that exoticness specific to Location? |
| 11:53 | <Ms2ger> | Very simple, very broken |
| 11:53 | <annevk> | Ms2ger: heh |
| 11:53 | <nox> | Ms2ger: That's not Location though, so I'm confused. |
| 11:53 | <Ms2ger> | You're supposed to be able to access contentWindow.location |
| 11:53 | <nox> | But not the rest? |
| 11:54 | <Ms2ger> | No other IDL objects, at least |
| 11:54 | <Ms2ger> | See annevk's long-winded spec :) |
| 11:54 | <annevk> | nox: https://github.com/whatwg/html/pull/638 has details |
| 11:54 | <nox> | Ms2ger: But in codegen, doesn't that concern contentWindow more than location? That's all the magic of WindowProxy no? |
| 11:55 | <annevk> | Ms2ger: if I could make it shorter I would |
| 11:55 | <Ms2ger> | annevk, not meant as a value judgement |
| 11:55 | <annevk> | Ms2ger: in fact, I patched ECMAScript so I could [[HasProperty]] overrides |
| 11:55 | <annevk> | remove /\ |
| 11:55 | <annevk> | fair |
| 11:55 | <Ms2ger> | Shit's complex, yo |
| 11:56 | <annevk> | yeah, as bz said this needs some tests |
| 11:56 | <Ms2ger> | Desperately |
| 11:56 | <Ms2ger> | bholley wrote some long ago, right? |
| 11:57 | <annevk> | yeah there are a couple of tests |
| 11:59 | <gsnedders> | presto-testo might have some |
| 11:59 | <gsnedders> | unfortunately I think the majority of the Presto tests for this were in /core/security which didn't get released |
| 11:59 | <gsnedders> | and in random bug folders, which equally didn't get released |
| 12:00 | <gsnedders> | because there were a decent number |
| 12:00 | <gsnedders> | could always prod someone and try and get these ones released at least, I guess |
| 12:00 | <annevk> | I wonder if Presto had the correct security model |
| 12:01 | <annevk> | I guess I could download and find out, but my curiosity is not that strong |
| 12:01 | <Ms2ger> | gsnedders, do you know if the core/standards/cookies/ were submitted? |
| 12:02 | <gsnedders> | Ms2ger: I think not. Do they not rely on .htaccess? |
| 12:02 | <Ms2ger> | Dunno, saw some php |
| 12:02 | <gsnedders> | oh, maybe just that then |
| 12:02 | <gsnedders> | IIRC they're also not very useful |
| 12:04 | <gsnedders> | annevk: IIRC there was some property on the Location class that allowed access, which was then checked in the impls of [[HasProperty]], [[GetProperty]], etc. |
| 12:04 | gsnedders | hasn't read the new spec though |
| 12:05 | <annevk> | gsnedders: were the properties on Location own properties? |
| 12:05 | Ms2ger | finds a stack of location.hash tests written with th.js |
| 12:06 | <annevk> | But that sounds somewhat reasonable |
| 12:06 | <gsnedders> | annevk: yeah, they will have been |
| 12:06 | <annevk> | But devil is in the details here of course, new standard also does not match browsers exactly, but should violate less ECMAScript invariants |
| 12:07 | <gsnedders> | annevk: Presto never moved to using getters on the prototype after they were introduced (in Futhark, IIRC) |
| 12:08 | <gsnedders> | But really I think there was decent test coverage, even if the expectations might need changed in a few places |
| 12:16 | <Ms2ger> | gsnedders, r? https://github.com/operasoftware/presto-testo/pull/52 |
| 12:16 | <Ms2ger> | Or frivoal_ |
| 12:21 | <gsnedders> | LGTM |
| 12:21 | gsnedders | wonders who wrote them |
| 12:21 | <gsnedders> | given the subject matter I'd have thought jgraham, but wrong code-style for that |
| 12:21 | <Ms2ger> | TIL that dos2unix is 4000 lines of C and still sees active development in 2016 |
| 12:23 | <frivoal_> | Looks good to me as well. The only missing thing seems to be the delay.php file |
| 12:52 | <jgraham> | gsnedders: hallvors wrote half and I wrote half some time later |
| 13:25 | <hallvors> | jgraham: wow, you added tests to that test suite later on? I didn't know - thanks :) |
| 13:26 | <hallvors> | So are those tests in web-platform-tests now? |
| 13:27 | <jgraham> | hallvors: Yep |
| 13:28 | <hallvors> | Nice. I remember working on them. Thought it would be a small and simple test suite - then more and more odd corner cases came up :) |
| 13:29 | <hallvors> | Also funny that gsnedders can tell us apart by coding style ;) |
| 13:29 | <JakeA> | Domenic: The web animations spec uses promises that reject with an AbortError to signal cancellation https://github.com/w3c/web-animations/issues/141 - hoping this can change before it ships in Chrome/Firefox |
| 13:29 | hallvors | is probably less consistent than jgraham |
| 13:29 | <jgraham> | Although now I've said that I don't actually recognise any of the tests |
| 13:30 | <jgraham> | I *for sure* converted them to testharness.js format. I thought I added more at the same time |
| 13:30 | <hallvors> | You're just too good at blending in and adapting your code to existing stuff ;) |
| 14:21 | <wanderview_pto> | JakeA: what do you think about adding an "install completed timestamp" to the ServiceWorker object? could also just be something exposed via devtools |
| 14:21 | <JakeA> | wanderview_pto: not against adding it. We already expose it in devtools |
| 14:22 | <wanderview_pto> | JakeA: I was about to write a bug for our devtools to add it, then wondered if we should just expose it to content |
| 14:22 | <wanderview_pto> | could be useful for devs during development |
| 14:23 | <JakeA> | wanderview_pto: would also allow you to stop handling fetches if your SW is "too old", or something. Dunno if that's useful, but it doesn't seem like a bad thing. Maybe a lower-level feature is a way to get the response object for the SW |
| 14:24 | <JakeA> | wanderview_pto: we discussed in the past being able to get these things as cache objects, although they mustn't be writable |
| 14:28 | <wanderview_pto> | JakeA: oh, you mean to get the sw script cache... does the response have a timestamp as a header or something |
| 14:28 | <wanderview_pto> | ? |
| 14:28 | <JakeA> | There's almost always a date header |
| 14:28 | <wanderview_pto> | JakeA: it might be best to have an update time and then the response date header.... so you can compare and see if you got a cached copy or something |
| 14:28 | <wanderview_pto> | or maybe that doesn't make sense |
| 14:29 | wanderview_pto | is a c++ developer. |
| 14:29 | <annevk> | Domenic: here is an idea |
| 14:29 | <annevk> | Domenic: we rename StructuredClone to StructuredCloneWithTransfer |
| 14:30 | <annevk> | Domenic: we rename InternalStructuredClone to StructuredClone and make the memory argument optional, defaulting to the algorithm creating something if it was not given |
| 14:30 | <annevk> | Domenic: then we don't need StructuredCloneOnly |
| 14:31 | <wanderview_pto> | annevk: can a url fragment contain a "/" character? |
| 14:32 | <annevk> | Domenic: and we'll rename Transfer to TransferHelper since you really need StructuredCloneWithTransfer if you want to transfer something |
| 14:32 | <annevk> | wanderview_pto: yeah I think so |
| 14:34 | <wanderview_pto> | annevk: I think our URL parser in gecko gets confused by that... |
| 14:34 | <annevk> | Domenic: at some point I'd also like to figure out a better way for the deepClone stuff but... |
| 14:34 | <Domenic> | annevk: that sounds pretty good yeah |
| 14:34 | <wanderview_pto> | JakeA: I guess I'll write a spec issue |
| 14:35 | <annevk> | Domenic: I was pretty pleased with it too after I wrote it all out 😃 |
| 14:39 | <wanderview_pto> | https://github.com/slightlyoff/ServiceWorker/issues/842 |
| 14:49 | <wanderview_pto> | annevk: oh... I take it back... our url parser is not confused, I'm just not running the parser |
| 14:54 | <JakeA> | wanderview_pto: yeah, I think you're right, it might be good to know the last successful update check too |
| 15:03 | <wanderview_pto> | JakeA: I like the idea of being able to feed it back to the server as a diagnostic... although I guess maybe you could do that other ways... with a fetch() in the install event |
| 15:04 | <JakeA> | wanderview_pto: we have a lot of places the spec says things like "if there hasn't been an update attempt in 24hrs…" so I don't see why we wouldn't expose that |
| 15:05 | <wanderview_pto> | yea |
| 15:05 | <wanderview_pto> | JakeA: although what I am suggesting is install time, not last update attempt time |
| 15:05 | <gsnedders> | hallvors: I spent enough time fixing flakey tests and reviewing tests I can often guess the author by code style :) |
| 15:05 | <gsnedders> | hallvors: some are more distinctive than others, I did wonder if those were you ;) |
| 15:05 | <JakeA> | wanderview_pto: <why not both meme> |
| 15:06 | <wanderview_pto> | seems reasonable... that could go on the registration of course |
| 15:19 | <beverloo> | annevk, out of interest, where do the `noscreen` and `sticky` flags from the Notification API come from? |
| 15:19 | <beverloo> | annevk, do you know if anyone is interested in supporting them? |
| 15:25 | <annevk> | beverloo: not sure, check the commit log? |
| 15:25 | <annevk> | beverloo: prolly Firefox OS... |
| 15:30 | <beverloo> | https://github.com/whatwg/notifications/issues/22 |
| 15:32 | <beverloo> | annevk, I'll file an issue to consider removing them, unless Mozilla has plans to support them (given the Firefox OS updates) |
| 15:38 | <wanderview_pto> | annevk: on a scale of bad to terrible, what do you think of just looking for a "#" symbol in a string url to determine if a fragment exists in an http or https url? |
| 15:39 | <annevk> | beverloo: I think it's reasonable to remove them |
| 15:39 | <wanderview_pto> | trying to find an easy way to assert that a fragment is not there in a place where its hard to use the real parser |
| 15:39 | <annevk> | wanderview_pto: do you know you have a proper URL at that point? |
| 15:39 | <wanderview_pto> | annevk: yes |
| 15:40 | <annevk> | wanderview_pto: probably reasonable then |
| 15:40 | <wanderview_pto> | awesome! |
| 15:40 | <wanderview_pto> | thanks |
| 15:40 | <annevk> | wanderview_pto: though I'd add a comment of sorts |
| 15:50 | <ritsyy> | annevk: for this https://www.w3.org/Bugs/Public/show_bug.cgi?id=28094 do you think changing it to something as suggested in comments as "Set computed MIME Type to Computed MIME Type" would be right? at many places it would be changed then, i think |
| 15:51 | <annevk> | ritsyy: yeah, that is generally the way we assign to variables |
| 15:51 | <annevk> | ritsyy: if it is the first instance you would use "Let x be y", later on in the algorithm you would have "Set x to z" |
| 15:52 | <annevk> | ritsyy: does that make sense? |
| 15:57 | <ritsyy> | annevk: the battery went off sorry,it would be changing both of the steps of initializing plus assigning it, sounds good, thanks! |
| 16:12 | <gsnedders> | ooh, PyPy 4.1 will support lxml fully. hopefully can move to using PyPy for stuff like BS and wpt lint and such like |
| 16:19 | <annevk> | Domenic: so annoying GitHub doesn't allow you to flag feedback as addressed, now all feedback is hidden and I've no idea whether I addressed it |
| 16:24 | <Ms2ger> | I'd suggest reviewable.io, but it can't handle large files |
| 16:24 | <nox> | Ms2ger: Oh you still have problems? |
| 16:24 | <nox> | Oh right, large as in the HTML spec? |
| 16:24 | <Ms2ger> | nox, with manifest.json, yeah, so I assume HTML too |
| 16:25 | <nox> | Ms2ger: Did you file an issue about that? |
| 16:25 | <Ms2ger> | I haven't |
| 16:25 | <nox> | You should, maybe they aren't aware of it. |
| 16:25 | <Ms2ger> | Well, they error out explicitly |
| 16:26 | <nox> | Oh. |
| 16:32 | <gsnedders> | It's a known limitation for them. |
| 16:46 | <gsnedders> | odinho: plz release the cross-origin DOM tests from t/core/security |
| 18:16 | <annevk> | Domenic: cross-origin objects is still mostly ready, though it depends on landing some changes to ECMAScript |
| 18:16 | <annevk> | Domenic: StructuredCloneWithTransfer has a couple of outstanding issues, some which need input |
| 18:17 | <annevk> | Guess I could try to quickly fix the issues with some of the other PRs I had |
| 18:50 | <odinho> | gsnedders: uh, okay. I can take a look at it later. |
| 18:52 | <gsnedders> | odinho: idk, I just need someone still at Opera who might do something :P |
| 18:53 | <odinho> | Well, better try to get all stuff you need out, because I might not be there forever, y'know ;) |
| 18:54 | <odinho> | I'll probably be moving to England for at least 7 months start of 2017 at least. Will probably do something else there. Not sure. |
| 18:55 | <gsnedders> | Meh, I regret not fighting more when I was on the inside :( |
| 18:56 | <gsnedders> | odinho: related: if you could actually get t/core/security released entirely to a few trusted people, that'd be fantastic. I know there's reasons why it's not all been released publicly |
| 18:57 | <gsnedders> | odinho: also maybe t/core/bts? |
| 18:57 | <gsnedders> | I'm not entirely sure why t/core/bts didn't manage to get out before, though |
| 19:00 | gsnedders | forgets what else was on t/core |
| 19:07 | <odinho> | gsnedders: Something about /bts being embarrasing I think I heard once many ages ago. And maybe that it is of dubious value(?). |
| 19:09 | <gsnedders> | I think bts is an open secret by this point, really. It's been talked about in here often enough. It certainly has some reasonably large testsuites in it, though. |
| 19:10 | <gsnedders> | And really, it's of more value released than it is on t. :) |
| 19:52 | <zcorpan> | MikeSmith: i would have provided a link but i was on my phone :-) |
| 19:54 | <gsnedders> | zcorpan: plz join odinho in my quest to release more |
| 19:59 | <zcorpan> | gsnedders: yeah i suppose i should take some time to release more tests |
| 19:59 | <gsnedders> | zcorpan: like just dumping stuff in presto-testo is better than nothing, y'know |
| 19:59 | <miketaylr> | remember that one time they ~*almost*~ opened up the BTS |
| 20:00 | gsnedders | expects that would've happened had Presto not been killed |
| 20:00 | <miketaylr> | but that was blocked on a jira upgrade or something |
| 20:00 | <miketaylr> | then... no dice. |
| 20:17 | <Domenic> | "525 additions, 545 deletions not shown because the diff is too large. Please use a local Git client to view these changes." nooo |
| 20:26 | <boogyman> | ol |
| 20:38 | <smaug____> | did Chrome have some way to get some GC statistics from a web page |
| 20:38 | <smaug____> | or was it about memory usage or what was it |
| 21:49 | <odinho> | :))) |
| 22:37 | <jgraham> | odinho: If you are going to be in England I should preemptively invite you toat least visit Mozilla. Or, y'know, apply for a job if "something else" meant "not work for Opera" |
| 22:48 | <Domenic> | TabAtkins: you really think it's best that details's disclosure triangle is some new kind of list item type!? |
| 22:48 | <TabAtkins> | I think it's fine? I don't understand what about it warrants a "!?"? |
| 22:49 | <Domenic> | TabAtkins: well, it's definitely not a list item? |
| 22:49 | <TabAtkins> | The disclosure triangle is, in basically all ways, equivalent to a list marker. |
| 22:49 | <Domenic> | how so? |
| 22:50 | <TabAtkins> | The 'display' property has no semantic connotations. The "list-item" value is exactly identical to "block", except it also generates a ::marker pseudo on the element. (Theoretically - browsers haven't jumped on implementing that in a controllable way, but still.) |
| 22:51 | <TabAtkins> | The triangle is a bit of non-DOM stuff that is attached to the element, and which isn't ::before or ::after, and which probably doesn't need the full set of properties that ::before/after allow. |
| 22:51 | <Domenic> | hmm |
| 22:51 | <TabAtkins> | ::marker seems to be a pretty good match for it, mechanically. |