- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Jan 2019 17:59:08 +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: specify stroke-color and fill-color are accepted in highlight styles` * `RESOLVED: add stroke-width to the set of properties` <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#issuecomment-456253617<br> <dael> Rossen_: AmeliaBR wrote a nice long overview. This is back to the WG<br> <chris> q+ to agree it sounds like stroke-width should not be allowed<br> <dael> AmeliaBR: WE talked about this previously. Question is about which properties should be allowed on highlight pseudo elements like selection<br> <dael> AmeliaBR: Discussion last wek was disagreement about what factors should disqualify a property from that set. WE talked about if something would trigger scrollbars, but feedback from impl is there ar eperformance impacts from recall painting dirty boxes as styles change<br> <dael> AmeliaBR: First question is for the group- what should be allowed in a highlight style and what should be disqualified. From there we can look at specific properties<br> <dael> AmeliaBR: As far as implementations go, we're talking about properties that are defined for SVG but want to extend to all CSS style text. new fill and stroke spec is not finalized<br> <dael> AmeliaBR: Another thing to remember is selecting styles on svg text has lots of interop issues that go beyond this issue. Solving this will not solve all svg text.<br> <dael> AmeliaBR: Non-svg text I don't believe there are any impl that support fill and stroke as def in new spec. We do have impl of webkit prefixed version which has different syntax and relationship between the properties.<br> <dael> AmeliaBR: At the end of my comment I said I'm not sure we can make a decisio on fill ands troke b/c they're not specified. Should we address interop in properties that are impl? The prefixed ones that don't have a spec. That's the question worth asking<br> <dael> AmeliaBR: I outlined a bunch of questions without answers. Anyone want to jump in with an opinion?<br> <dael> fantasai: smfr webkit has stroke and fill for selection?<br> <dael> smfr: Don't recall, but I think we could easily<br> <dael> fantasai: My inclination is for the spec in current state I would go more restrictive for now and add more as requested. WE should do subset of what is impl plus spelling and grammar error. THat's why we have text decor and color<br> <dael> fantasai: Other properties in that list I don't know if they're problematic. I'm happy to include if impl want to impl, but if not there's no reason to put it in the spec unless someone asks.<br> <dael> fantasai: I prefer color, bg color, text decoration, and whatever impl want to implement<br> <dael> fantasai: Then we can consider what else we want to allow. A core set would be good<br> <dael> chris: I previously argued stroke-width, but I withdraw that.I would like to see stroke and fill if impl interest. Makes sense for fill<br> <AmeliaBR> https://codepen.io/AmeliaBR/pen/84c95eb4cd697f031f12487cbf239480<br> <dael> AmeliaBR: as far as what's impl, for SVG text all are supported I think. Haven't tested. That's ^ the test for prefixed ones<br> <dbaron> I think it's also worth trying to write down principles that lead to the choices -- I think one of those principles should be that anything that triggers scrollable overflow probably shouldn't be included...<br> <dael> AmeliaBR: Chrome and Edge support changing stroke-color and stroke-width. FF does now. Don't have safari<br> <dael> myles: Why stroke-width hard?<br> <dael> chris: Causes additional computation so it's not just damaged pixel repair.<br> <dael> smfr: Have to do layout to recalc visual overflow<br> <dael> chris: Also heycam|away from MOzilla said problematic<br> <dael> dbaron: Text decorations also require recomputing visual overflow<br> <dael> chris: True<br> <dael> smfr: We used to cheat, but they can project out<br> <dael> AmeliaBR: We're talking about selection b/c that's where performance comes in. BUt we're using same set of properties for all highlight pseudo classes so that also means spelling & grammar error. If we restrict from performance we might need to split the category so there's flexibility for things like highlighting spelling errors<br> <dael> dbaron: I don't know we're far enough along on interop on this that we're at that point<br> <dael> dbaron: I think it is worth trying to write down principles that lead to these choices. I think anything that triggers scrollable overflow should not be on this list. Discussing ink<br> <dael> smfr: THings that trigger resource loads?<br> <dael> chris: Def. disallowed. IF you're bringing a network transfer you don't want that<br> <dael> dbaron: Reosurce loads are async and you see something else in the interrum<br> <dael> florian[m]: I don't think that's much of a problem. Triggering network since async ins't<br> <dael> dbaron: Worry abotu background is we have to define background position for these<br> <dbaron> s/interrum/interim/<br> <dael> fantasai: Right, this is why I'm against background images. i think stroke and fill images are pinned to geometry of element box so wouldn't have same issue. We could do that for backgrounds in theory<br> <dbaron> s/abotu/about/<br> <dbaron> s/about background/about background images/<br> <dael> fantasai: For these images you don't want the to reset tiling on every element. As you highlight and there's a span it breaks the tiling. Id on't know how you fix that and make it consistent, but also give controls to author. For that reason I think don't allow images. unless geometry is tagged to what's in doc and not selection area, then we can consider it<br> <dael> fantasai: I can come up with definition pegged to document element or controllable by author, but not both.<br> <dael> smfr: I'm not sure original motivation of the issue was<br> <dael> daniel: For completeness. I didn't think this required a re-flow at the time. I was filling out for completeness<br> <dael> AmeliaBR: It's worth discussing b/c we have impl of webkit-text-stroke where some imple support it. There are different decisions out there. BUt that's not a prop in a spec. WE need to discuss properties in the spec and where should images be anchored when painting a span<br> <dael> fantasai: That's specified in the spec now. We had to get it right to make it useful. THere's a property to control that<br> <dael> daniel: I must have missed something. What are we trying to decide on?<br> <dael> fantasai: Wht is the list of properties for section 3.2. I'm happy to include stroke-color and fill-color. THat seems straight forward<br> <dael> AmeliaBR: Only difficulty there is currently the shorthand stroke property which is what's impl if you're switching color to none it's not defined how it effects the stroke-color longhand<br> <dael> fantasai: There is a definition in fill stroke spec. I think it doesn't quite match SVG and we created a shorthand/longhand relationship and we figured it was backwards compat on existing content<br> <dael> fantasai: We're going with fill stroke spec, it doesn't matter if it's shorthand it will reset the longhand. CSS expands and looks at longhand, doesn't look at shorthands. If author says stroke:blue it sets stroke-color:blue<br> <dael> AmeliaBR: So deciding which properties apply you can use stroke shorthand in the property and some parts will have effect and some not?<br> <dael> fantasai: Yeah. We ignore properties not supported<br> <AmeliaBR> s/in the property/in the ::selection rule/<br> <dael> AmeliaBR: I can't remember who said it, but we can start with the more restricted set and expland it<br> <dael> AmeliaBR: I think it's reasonable to say stroke-color and fill-color are acceptable in the highlight styles, implementation can extend that to prefixed similar properties if they choose<br> <dael> daniel: for right now just exclude stroke-width?<br> <dael> AmeliaBR: Yes since that seems the controversial one<br> <dael> daniel: I'm fine with that<br> <dael> AmeliaBR: I do think it's prob a good longterm strat to think about and outline the underlying principles for that set of highlight styles and what should be considered when allowing/disallowing styles.<br> <dael> AmeliaBR: NOt sure who wants that job<br> <dael> fantasai: Main principles is they can't effect layout, including scrollable. Can't trigger resource load (for now). Can in some cases trigger ink overflow b/c we've got text decoration in there<br> <dael> fantasai: Not sure how we want to deal with that<br> <dael> Rossen_: Should we take that later on and try to resolve on this issue?<br> <dael> Rossen_: There was some agreement around having stroke-color and fill-color participlate in highlight styles<br> <dael> Rossen_: Anything else we need before I call for objections?<br> <dael> dbaron: Summary of how our prop disagrees with current impl?<br> <dael> Rossen_: dbaron, We need to include it as part of the resolution? Or capture it someone?<br> <dael> daniel: I have a patch for webkit and I'm implemented itfor stroke-color and fill-color in that patch.<br> <dbaron> can you hear me now?<br> <dael> Rossen_: I just wanted to hear from dbaron<br> <dbaron> reconnecting<br> <dael> dbaron: I was saying I thought it was useful to understand what was going to have to change as a result of the resolution<br> <dael> Rossen_: Wasn't that it needed to be in the resolution, but it has to be clear in the issue what the effect of this is to the current impl<br> <dael> dbaron: Just like to know how far from current impl is the thing we're going to resolve on<br> <dael> Rossen_: Sounds like webkit is implementing. Blink?<br> <dael> AmeliaBR: I think the only issue is we do have impl that support the width effect which we're not including.<br> <dael> AmeliaBR: If there's any ones that don't...FF is only one that doesn't support stroke and fill color changes. But we're talking a mix of prefixed property impl. WE don't have impl of stroke-color as spec.<br> <dael> fantasai: We want to make sure there's a path to change from prefix to standard. If we have features in prefix we don't allow in standard we have to revise<br> <dael> fantasai: We can say stroke-width is supported, but ink overflow may not recalculate<br> <dael> florian[m]: Not sure what effect of not recalc would be<br> <dael> fantasai: Glitchy rendering<br> <dael> dbaron: Typically glitchy rendering at future repaints<br> <dael> Rossen_: Let's see if we can resolve<br> <dael> Rossen_: Are we ready to resolve?<br> <dael> Rossen_: Objections to specify stroke-color and fill-color are accepted in highlight styles?<br> <dael> RESOLVED: specify stroke-color and fill-color are accepted in highlight styles<br> <dael> fantasai: What about stroke-width. If it's supported in prefixed version, what do we do?<br> <dael> dbaron: Does it trim scrollable or only ink?<br> <dael> AmeliaBR: Only ink<br> <dbaron> s/trim/trigger/<br> <dael> fantasai: Which impl support webkit-stroke and fill for selection?<br> <dbaron> s/it/stroke-width/<br> <dael> AmeliaBR: Chrome and Edge. I assume safari, but I need someone to confirm using the codepen<br> <dael> Rossen_: We're certainly supporting<br> <dael> AmeliaBR: Edge doesn't support fill and stroke on SVG text, but FF does<br> <dael> Rossen_: Depends on version of SVG. In last one we released that should be fixed<br> <dael> fantasai: If it's webkit prefix it's strong enough compat that we're going to have support the functionality that maps to. Otherwise we don't give authors ability to transition out<br> <dael> fantasai: We need to figure out what the functionality is and put it in the list. What do other people think?<br> <dael> florian[m]: Reasonable to me, but I'm not an implementor<br> <dael> daniel: What's the question?<br> <AmeliaBR> Correction to my last comment: FF doesn't support selection fill & stroke on SVG text, either. Demo of selections on SVG text: https://codepen.io/AmeliaBR/pen/15e1dec9a9f1887c904adafca7589ff0?editors=1100<br> <dael> fantasai: First is if safari supports webkit prefixed stroke and fill properties in selection. Second is if webkit prefixed stroke-width is supported in selection, does that mean we have to put it in the spec? If we all impl under a prefix we should do it in the regular.<br> <dael> daniel: I'm looking<br> <leaverou> AmeliaBR: codepen seems to work in Safari (and has somewhat better rendering in fact)<br> <AmeliaBR> HTML strokes and selection: https://codepen.io/AmeliaBR/pen/84c95eb4cd697f031f12487cbf239480<br> <dael> daniel: We do support stroke-width<br> <dael> fantasai: Then we have to do it, regardless of it's a good idea<br> <dael> florian[m]: I think so unless other browsers have a good reason<br> <dael> smfr: Might mean selection is slightly slow/choppy because we're doing relayout.<br> <dael> fantasai: Or are you assuming you left space?<br> <dael> smfr: I'll have to check<br> <dael> fantasai: Adding stroke-width to spec or will browsers remove?<br> <dael> smfr: I don't think we'll remove.<br> <dael> dbaron: [missed]<br> <dael> Rossen_: User PoV it's better behavior<br> <dbaron> s/[missed]/I'm fine with adding it./<br> <dael> Rossen_: Objections to add stroke-width to the set of properties?<br> <dael> RESOLVED: add stroke-width to the set of properties<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-459044689 using your GitHub account
Received on Wednesday, 30 January 2019 17:59:10 UTC