- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Jul 2020 23:12:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] Which properties to reset in ::marker`, and agreed to the following:
* `RESOLVED: If property applies to text and no dependency on box geometry it can be set on ::marker and inherits to text of marker`
* `RESOLVED: Other properties which are not explicitly listed as apply to ::marker must not have an effect when set by author. UA might treat as not applying or treat them as set at UA important level but either way author should not be able to effect rendering`
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: [css-pseudo] Which properties to reset in ::marker<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/4568<br>
<dael> oriol: Related to discussion 2 weeks ago where resolved text-transform applies to ::marker and set to none by default.<br>
<dael> oriol: Same for other properties<br>
<dael> oriol: Text-indent property. Seems clear inheriting seems bad<br>
<dael> oriol: Only applies to block container so can effect markers with outside position<br>
<dael> oriol: May not be obvious to authors b/c they're not explicitly setting a display value to generate block. It's done by UA<br>
<dael> oriol: Should follow rec in Tables which says if you set display-inline:block to element you reset text-indent to 0. Since UA gives inline block behavior to outside markers makes sense to reset text-indent to 0<br>
<dael> oriol: fantasai went further and prop to do so with an important flag so until we have clear model of outside marker layout we prevent authors from changing.<br>
<dael> oriol: Also works for me.<br>
<fantasai> https://drafts.csswg.org/css-lists-3/#marker-properties<br>
<dael> oriol: There are other properties but let's discuss this<br>
<Rossen_> q<br>
<Rossen_> ack fantasai<br>
<dael> fantasai: We have a short list of properties that apply to ::marker and makes sense to be clear what we're talking about. Properties that apply to box/linbox and htose that apply to text. Not clear distinguishing<br>
<dael> fantasai: Any property apply to text should inherit through ::marker and apply to text<br>
<dael> fantasai: Those that apply to box or linebox b/c we dont have a layout model these properties should not apply. If they do apply they should be forced to initial value<br>
<dael> fantasai: When we have a proper box model we can make those that make sense apply.<br>
<dael> fantasai: I would change to properties that apply to ::marker and say then list properties that inherit to text and say you can set on ::marker, don't apply there but effect contents. If we take that as principle these questions become more obvious<br>
<fantasai> s/effect/affect/<br>
<dael> AmeliaBR: You argue color doesn't effect marker as a special thing it effect anon text box<br>
<dael> fantasai: yeah<br>
<fantasai> s/effect/affect/<br>
<dael> AmeliaBR: If it effect inline text spans you can set on ::marker and it goes through. Anything for layout box has to be on allow list<br>
<dael> fantasai: I think that's the principle. There's fun with fill and stroke where rely on geometry of box<br>
<dael> AmeliaBR: We don't have impl of that<br>
<dael> fantasai: Fair but still got to be careful<br>
<dael> AmeliaBR: At some point will need to be defined<br>
<dael> fantasai: Prop: Properties that apply tot ext with no dependency on geometry of boxes can be set on ::marker and inherit through to text<br>
<dael> fantasai: Properties that apply to boxes and line boxes do not apply yet<br>
<dael> oriol: But text-align FF sets to end so if you have multi line in outside marker with different widths they will be aligned to r in ltr<br>
<dael> fantasai: text-align doesn't apply to text, it appleis to line boxes. So it would not apply to ::marker. Position of text I believe is undefined. If an impl supports text-align that's fine but need to make sure it's not changable by author such that they can get different results<br>
<faceless2_> q+<br>
<dael> fantasai: Either done through magic or through text-align but forced to that value and can't be changed by author. Once there's a layout model we loosen the restriction<br>
<dael> faceless2_: What about when have replaced content with ::marker we have to propagate properties which allow you to resize<br>
<Rossen_> ack faceless2_<br>
<dael> fantasai: Replaced content is replaced content that's a child of the box. For list-style:image there's sizing rules that are particular ans size the image to 1em if it doesn't have a size, something like that. Would continue to apply<br>
<dael> fantasai: If we want to do something special for images that are list markers we can think about that.<br>
<dael> fantasai: Not sure<br>
<dael> faceless2_: I think was difference between setting content and setting string of content. Bit scratchy on terms. Does seem to vary across impl but a lot of print lets you use image and content. Height is prop to image rather than box.<br>
<dael> faceless2_: Agree in general with you<br>
<dael> fantasai: ON marker set content to URL that's an image. THen marker is replaced element and width and height applies<br>
<emilio> q+<br>
<dael> faceless2_: Yeah, I think that's how it works with marker-content:url Does vary cross impl<br>
<dael> TabAtkins: Yeah, WK based treat the pseudo as replaced. Spec requires anon element.<br>
<dbaron> There was a spec draft of css3-content at some point defining that behavior.<br>
<dael> AmeliaBR: But it is something to define to be similar to how list style with an image would work to make ::marker case more logical if can have it same as content with image. BUt neither is well defined<br>
<fantasai> yeah, and I think there was some interesting questions around web-compat... but if WebKit is able to ship that<br>
<Rossen_> ack emilio<br>
<dael> emilio: I think Gecko always wraps it in an inline. But content URL on element impl disagree<br>
<Rossen_> ack fantasai<br>
<dael> fantasai: I think we should dig more into content url becoming replaced, but let's file a sep issue<br>
<faceless2_> +1 to that.<br>
<dael> Rossen_: With that issue are we ready to resolve?<br>
<dael> Rossen_: I see heads nodding<br>
<dael> Rossen_: fantasai can you give us prop ideally with a list of properties or a term of art?<br>
<dael> fantasai: I think that's something we need to clean up. Two approaches is we inline...the entire fonts spec ans this set of text.<br>
<dael> fantasai: We can also audit all our properties and spec in the applies to line.<br>
<emilio> fantasai: https://github.com/w3c/csswg-drafts/issues/2889 is open for `content: url()` already, fyi<br>
<dael> fantasai: For this I think the prop will be 2. 1) If property applies to text and no dependency on box geo it can be set on ::marker and inherits to text of marker<br>
<dael> Rossen_: Similar to set of properties for ::first-letter?<br>
<dael> fantasai: No b/c can take initial-letter<br>
<dael> AmeliaBR: Might be to selection or highlight<br>
<dael> fantasai: No, they can't change layout<br>
<dael> fantasai: Might be first-line similar<br>
<dael> fantasai: Rule is if property applies directly to text and no dependency on geo you can set it on ::marker and it will inherit to text<br>
<fantasai> s/geo/box geometry/<br>
<dael> Rossen_: Thoughts or objections?<br>
<dael> heycam: Will we define in a ua stylesheet in a spec or make it clear what computed style is?<br>
<dael> fantasai: Compute on ::marker and inherit through<br>
<dael> heycam: So it's about if they apply<br>
<dbaron> There might be two parts to this resolution: what we want to happen, and at what level the spec needs to define it?<br>
<dael> heycam: Does that mean text-align:end is not correct?<br>
<dael> fantasai: That's second resolution<br>
<dael> Rossen_: Objections to If property applies to text and no dependency on box geo it can be set on ::marker and inherits to text of marker<br>
<dael> RESOLVED: If property applies to text and no dependency on box geometry it can be set on ::marker and inherits to text of marker<br>
<emilio> faceless2_: I don't see the webkit / blink quirk you mentioned in http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8312 fwiw. All browsers behave the same<br>
<dael> fantasai: Second If a property that's not in the first category is not listed in the spec than it does not apply to ::marker boxes. If an impl is taking advantage of infrastructre to handle marker layout it needs to bake that in as !important so author can't set<br>
<dael> fantasai: Ex we spec that unicode bidi does apply to ::marker. It can be set. We didn't spec that text-indent does. Gecko uses text-align to position text and that's fine but it needs to set !important on that rule so that author can't set it and et different results.<br>
<dael> fantasai: When we define the box model we can release that restriction. Until then we need to make these so author cannot effect<br>
<fantasai> s/text-indent/text-align/<br>
<dael> oriol: All inherited properties except the ones in the resolution should be set to initial using !important?<br>
<dael> fantasai: I don't know that...are there prop for the box that inherit?<br>
<dael> oriol: text-align chromium just inherits. Should we allow this?<br>
<dael> fantasai: If a property has an effect in an impl and we say it does not apply the property needs to be force set so it acts like it does not apply<br>
<dael> dbaron: Differences are observable in computed<br>
<dael> fantasai: Yeah. Ultimate goal is they do apply but we need to define marker box model for that<br>
<dael> Rossen_: Hopefully not paint in corner<br>
<dael> fantasai: I don't think we will. Force set will be UA initial values. Author might set it on ancestor and we need to make sure it doesn't inherit through in unexpected ways<br>
<faceless2_> @emilio If you set a height on that image, the spec says it should be "content-replacement" and the width/height should apply _to the image_. This is distinct from a list of more than one item, when it becomes a "content-list" - the distinction tab was making. That distinction is not made by the browsers, but if you're going to do ::marker { content: url(file.svg); height: 1em } that's the only way you can adjust the size of the SVG.<br>
<dael> fantasai: Prop: Other properties which are not explicitly listed as apply to ::marker must not have an effect when set by author. UA might treat as not applying or treat as set at UA important but either way author should not be able to effect rendering<br>
<dael> oriol: May or must on inheritence allowing?<br>
<dael> fantasai: Must. Must behave as no effect<br>
<dael> Rossen_: Custom properites as well?<br>
<dael> fantasai: They don't effect layout, no<br>
<dael> Rossen_: Those that can be used by custom layout?<br>
<dael> fantasai: I don't think it effects ::marker<br>
<faceless2_> @emilio https://github.com/w3c/csswg-drafts/issues/4632<br>
<dael> Rossen_: I can have it inside and prop a bunch of properties. If you stop from prop to me I can't do custom layout<br>
<dael> fantasai: Can't do it without display property and it does not apply to ::marker or things within it<br>
<dael> Rossen_: Same with custom paint?<br>
<dael> AmeliaBR: We can't do b-g image b/c that depends on layout. So for now probably<br>
<dael> Rossen_: Making sure we're not in a corner<br>
<dael> AmeliaBR: Any reason to prevent custom properties from having a proper computed value on ::marker? No reason to not let read in JS<br>
<dael> fantasai: Only properties effected are notse not in the previous resolution and not listed in spec but would have effect in impl for some reason. Custom properties don't fit into any of those caregories<br>
<emilio> faceless2_: uhhh, so the spec doesn't match any browser implementation of pseudo-elements? fun!<br>
<dael> Rossen_: Objections to Other properties which are not explicitly listed as apply to ::marker must not have an effect when set by author. UA might treat as not applying or treat them as set at UA important level but either way author should not be able to effect rendering<br>
<faceless2_> Matches at least two print engines though :-)<br>
<dael> oriol: Clarification. THe might in the prop text should be a must<br>
<heycam> (it also is impossible to stop custom properties from inheriting by setting things in the UA sheet, since all doesn't target them)<br>
<fantasai> s/effect/affect/<br>
<dael> RESOLVED: Other properties which are not explicitly listed as apply to ::marker must not have an effect when set by author. UA might treat as not applying or treat them as set at UA important level but either way author should not be able to effect rendering<br>
<fantasai> s/might treat/MUST treat/<br>
<dael> dbaron: Back to previous resolution.<br>
<dael> dbaron: Thing that might still make people unhappy is not substance but level of detail where spec desc.<br>
<dael> dbaron: Best thing to do is have editor apply it and bring back to group to see if we're okay with level of detail. There's a wide range of ways to do that. Seem reasonable?<br>
<dael> AmeliaBR: Qualify our resolution that spec text is subject to final approval?<br>
<dael> Rossen_: We can always amend a resolution<br>
<dael> Rossen_: dbaron comments will go in the 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/4568#issuecomment-664684464 using your GitHub account
Received on Monday, 27 July 2020 23:12:25 UTC