- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Jan 2019 17:59:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Add stroke-color and stroke-width to the list of highlight properties`, and agreed to the following: * `RESOLVED: Add stroke-color, stroke-width, fill-color and paint-order` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Add stroke-color and stroke-width to the list of highlight properties<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2362<br> <dael> Rossen_: Discussed a number of times. Seems there's some agreement on the issue<br> <dael> Rossen_: chris do you want to take this?<br> <dael> chris: Been a bit of discussion. General consensus on properties. Suggestion that they're hte long hands. Support that<br> <dael> chris: We've pretty much worked out what this effects.<br> <dael> fantasai: I think we'll look for 2 resolutions. 1 to clarify these are only ink overflow and second is to make them usable with selection<br> <dael> chris: Agree with first<br> <dael> fantasai: Question about applying all long hands. One limitation we have here is we don't want anything that will expose bounderies of box rep. element.<br> <dael> chris: But owuld it? Someone suggested it would but that was fairly quickly shown to be wrong<br> <dael> fantasai: Then we're fine<br> <dael> Rossen_: Prop is add stroke-color and stroke-width, fill-color and paint-order? Is that the list?<br> <dael> chris: I think so. It's in the issue<br> <dael> Rossen_: I'm reading from issue. Making sure I'm not missing anything.<br> <dael> Rossen_: stroke-color, stroke-width, fill-color and paint-order<br> <dael> Rossen_: Objections to adding stroke-color, stroke-width, fill-color and paint-order<br> <dael> RESOLVED: Add stroke-color, stroke-width, fill-color and paint-order<br> <dael> chris: And the suggestion to add the long hands?<br> <dael> fantasai: My understanding from last time is they need to be properties that can be handled at a high performance level. Dashing and filter and fill images and these things...<br> <dael> chris: Dashing has nothing to do with filters or images. It's common in animations so can't say it's not performance<br> <dael> fantasai: Question is would impl be up to implementing that for selections<br> <dael> chris: If you lookin graphical editors there's martching ants and I've seen people use stroke-offset and stroke-array to get that<br> <dael> leaverou: That's commonly done<br> <dael> fantasai: I don't know answer, but I think impl need to say yes they're willing to impl<br> <dael> smfr: [missed] I'm okay with dashing here<br> <smfr> for webkit, dashing has some painting cost, but not serious enough to justify excluding it from this list<br> <smfr> i’m ok with dashing here<br> <dael> [everyone reads]<br> <dael> Rossen_: smfr is okay with dashing<br> <dael> chris: Other implementors?<br> <dael> Rossen_: I'll take that as a silent no<br> <dael> fantasai: Next question is what about paint servers and tiling images. Is that something impl want to do on selection?<br> <dael> Rossen_: Ooph<br> <dael> TabAtkins: That's backgrounds in css<br> <smfr> don’t want selection to trigger an image load<br> <dael> fantasai: CSS only allows color, not image<br> <dael> leaverou: Are background images not allowed for reason of showing element boundries?<br> <dael> TabAtkins: Probably. We got around the issue by only allowing 0 dimensional images, aka colors<br> <dael> chris: I think that's the same for border images<br> <dael> leaverou: I don't think even borders are allowed<br> <dael> fantasai: Right<br> <AmeliaBR> For stroke/fill images, the boundaries (in SVG, anyway) are always the boundaries of the full <text>, not the given span, so it shouldn't be affected by changes in selection span.<br> <dael> Rossen_: So, no on this one? Soft no? To be consistent with previous soft no or weak maybe?<br> <dael> fantasai: Stroke and fill will be based on geometry of element so won't expose border. I don't think it's that useful. prob better not to do them. If someone wants them in the future we can add<br> <dael> Rossen_: Easier to add then remove.<br> <dael> Rossen_: Let's not add for now. THere's enough feedback from silence and pushback that this isn't comfortable at the moment. When they're more widely used we can see if shorthands are warented.<br> <dael> Rossen_: Sound good?<br> <dael> chris: Okay<br> <dael> Rossen_: That's this issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2362#issuecomment-454877928 using your GitHub account
Received on Wednesday, 16 January 2019 17:59:43 UTC