- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Jun 2017 23:28:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `How does 'inherit' keyword behave in a child of ::first-line?`, and agreed to the following resolutions: * `RESOLVED: Take hte behavior described in the issue and work witht o to make sure it works for compat.` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: How does 'inherit' keyword behave in a child of ::first-line?<br> <dael> github topic: https://github.com/w3c/csswg-drafts/issues/1097<br> <dael> fremy: I had been presenting that. We were debating 2 weeks ago on dbaron's reply.<br> <dbaron> s/debating/waiting/<br> <shane> OK we're in now!<br> <dael> fremy: dbaron basically agreed witht he proposal and I think we should prob just resolve ont he behavior from the issue.<br> <dael> fremy: We were debating on best way to enter this into the spec, it's editorial so it's up to the editor.<br> <dael> fremy: We were trying to desc how inherit works when child of first pseudo element.<br> <dael> fremy: To recap: The element is a child of the first-line pseudo and will generate the propety and it will inherit by default.<br> <dbaron> Proposed resolution was: "Inheriting properties of inline fragments that are contained in a ::first-line only inherit from the ::first-line if those properties (1) do apply to ::first-line, (2) do inherit by default, and (3) are not custom properties."<br> <dael> fremy: dbaron felt the approach was right if not the best wording.<br> <dael> fremy: We can work throught he right wording, I guess.<br> <dael> astearns: Anyone with more comments or wants more explination?<br> <tantek> this sounds reasonable, I'm wondering what the interop situ is on this?<br> <dael> fantasai: I'm a little confused why we need to check if they apply to first-line<br> <dael> dbaron: That's what my comment was about. It wasn't about wording but if that should be more general. Normally in CSS applies to don't effect computed values. But applies to pseudo elements does effect computed has been my undderstanding. But we don't say that anywhere.<br> <dael> dbaron: My comment was that if that is the case we should a) say it and b) remove condition 1 since it becomes redundant.<br> <dael> fantasai: It could effect computed value on psuedo element. BUt having properties inherit differently is really hairy. There are a lot of properties where applies to is more general<br> <dael> dbaron: It's possible that we need to seperate applies to and if properties apply to pseudo elements. That's more clear cut.<br> <dael> TabAtkins: I agree. The rest of applies to are editorial pointered, but that's reasonably mechanically relevent<br> <dael> fantasai: There's a lot of prop where we say it applies ot everything, but that's because it inherits. WE could tighten that, but the majority of applies to aren't tight<br> <dael> Florian: And sometimes it's the opposite case where we state the things it doesn't apply to. It's a fuzzy mess.<br> <dbaron> s/psuedo/pseudo/g<br> <dael> fantasai: It's not percise enough. If it's going to determine how things inherit we need to be rigerous. I don't think we should make the spec depend on if a properties applies to. It should be if it's inherit or now.<br> <dael> dbaron: I think we need it for if it applies to pseudo elements, but the specs aren't great on specifying. In Gecko we list every prop that applies to a pseudo in the code. If it's doesn't apply the declarations aren't applied. That's first-letter and first-line.<br> <dael> fantasai: What's that case where we need the distinction?<br> <dael> dbaron: display<br> <dael> fantasai: It's not inheritable.<br> <dael> dbaron: I need to look at examples then.<br> <dael> fremy: I don't have a list of, but user-select would be one.<br> <dael> Florian: Tha'ts not inherited.<br> <dael> dbaron: I think the main reason inheritencec needed restrition was variables.<br> <dael> fremy: Yes, yes.<br> <dael> fremy: Variables, in that case,t hey could apply to any property. But that's condition #3 where we say we don't generate custom properties for first-line. There may be others.<br> <dael> fantasai: If we're going to have this condition I want an example that is inheritable, not a custom prop, and doesn't apply to first-line. If there's no such property we don't need this conditional<br> <dael> fremy: Is there a lsit of properties that inherit?<br> <dael> fantasai: INdexes.<br> <dael> TabAtkins: That's not tracked across specs. It's on the to do list.<br> <dael> astearns: Sounds like we're converging on resolving to take the propsal except possible condition 1 which needs a real world example of why it's needed.<br> <dael> fantasai: Yes. I'm happy to resolve on the rest but I don't want this conditional if it's not needed.<br> <dael> dbaron: Writing mode and direction are the two prop I've found so far that are problematic.<br> <dael> Florian: If you try and change the writing mode on the first-line...yeah. Don't do that.<br> <dael> astearns: The treatment that is currently in the issue, weither or not we have that first conditional, are writing mode still problematic?<br> <dael> dbaron: They're inherited, not custom, but no one interprets them as applying to first-line<br> <dael> fantasai: That's a good/interesting one. First-letter could be in a different writing mode<br> <dael> astearns: To answer tantek from earlier, it sounds like we dont' have interop. Correct?<br> <dbaron> 'white-space' may also be a problem (with ::first-line and 'pre')<br> <dael> fremy: it's correc,t i think. The issue was mostly Chorme allowed a few more properties to inherit and the custom properties weren't blacklisted in FF<br> <dael> astearns: Can we resolve to accept the proposal, possibly excluding condition 1 if there is no compelling example.<br> <dael> Florian: I think we found an example. Which leads to applies to not being specific enough to rely.<br> <dael> fremy: We can agree on the behavior of this issue. I think we can discuss the other issue seperately. We can agree on the behavior and discuss further what applies to means.<br> <dael> Florian: I think having or not having part 1 is a difference of behavior.<br> <dael> Florian: I'm okay resolving this and filing issues agaist specs to tighten applies to.<br> <dael> fantasai: That won't happen in any reasonable time frame. The exclusion list should be explicit for now and then look for a better way to distribute. Most don't take into consideration first-line and first-letter and may say "all applies"<br> <dael> fremy: Ccurrently in psuedo spec there's a list of properties.<br> <fantasai> https://drafts.csswg.org/css-pseudo/#first-line-styling<br> <dael> dbaron: CSS 1 & 2 had a list of what first-line and -letter are for, but I think it was a should<br> <dael> dbaron: That may or may not be different to the applies to line. We discussed about moving it, but we never did.<br> <dael> Florian: Should we point to pseudo 4?<br> <dbaron> s/ what first-line and -letter are for/ what properties apply to ::first-line and ::first-letter/<br> <dael> fantasai: What we need here is a list of properties that aren't inherited from the pseudo elements and we can come up witha more general apploahs, but a good black list is a starting point.<br> <dael> astearns: Sounds like were' resolving on the proposal witha blacklist, but further define how to do it later. This is the behaior we want.<br> <Florian> pseudo-4 isn't good enough for the list. It has the list of "at least these must apply", it does not have "these do not".<br> <liam> [css 2.1 lists for first-letter, font properties, color property, background properties, 'word-spacing', 'letter-spacing', 'text-decoration', 'text-transform', and 'line-height', and then says, UAs may apply other properties as well. ]<br> <liam> [ https://www.w3.org/TR/CSS2/selector.html#first-line-pseudo just before 5.12.2 first-letter ]<br> <Florian> https://drafts.csswg.org/css-pseudo/#first-line-styling<br> <dbaron> It could have a list of "these apply", a list of "these do not apply" and a note that if it's on neither list you should contact the spec editor.<br> <Florian> https://drafts.csswg.org/css-pseudo/#first-letter-styling<br> <dael> tantek: I think I like the rough approach. I asked about interop because everytime we've tried to do this in the past there has been compat issues. If someone wants to try this with simple examples it could illuminate the likelyhood of this approach. I'd propose someone writes tests to test their assumptions and show how bad the situation is.<br> <dael> tantek: It's a hard problem<br> <fantasai> dbaron: That's a decent approach :)<br> <dael> astearns: Proposed resolution is try and specify this behavior and see how that proposed behavior and interop goes.<br> <dael> RESOLVED: Take hte behavior described in the issue and work witht o to make sure it works for compat.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1097#issuecomment-306954578 using your GitHub account
Received on Wednesday, 7 June 2017 23:28:43 UTC