- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 12 Feb 2014 21:16:04 -0500
- To: www-style@w3.org
Charter ------- - Plh reported that we're on track for the charter extension. New Regions WD -------------- - RESOLVED: Publish a new WD of Regions Selectors Poll -------------- - There was heated debate on the validity of the poll to determine naming syntax for Selectors as the text of the poll was changed after about 130 responses to address concerns that people were responding to the presence of ! instead of the larger issue. No decision was reached as to if the poll can be used being mindful of the change in wording or if a new poll needs to be created. Shadow DOM ---------- - Naming a combinator for ident was discussed with suggestions including /ident, #ident, :ident, /ident/, and `ident`. The group leaned toward /ident/. It was the groups opinion that this should stay in Shadow DOM and not move into Selectors for now. Counter Styles API ------------------ - The group discussed the implications of Xidorn's issue of return value for an empty string. Initial feelings were toward having it return initial value. TabAtkins then tested the implementation in Firefox and Chrome later in the call and said they were returning empty strings. The discussion will continue after more people can run tests. Concept of Baselines -------------------- - It was decided this issue did not need telecon time. ::first-letter -------------- - Dbaron will write a proposal for what exactly counts as a first letter referencing unicode. Grid Issues ----------- - TabAtkins indicated he's still working on the issues raised by SimonSapin Inline box, atomic inline-level box, and transformable elements --------------------------------------------------------------- - The group agreed that the test at issue was incorrect because it assumes fragments apply where they currently don't. Line box edge ------------- - Everyone agreed with tantek's proposal. =====FULL MINUTES BELOW====== Present: Glenn Adams Rossen Atanassov Tab Atkins David Baron Bert Bos Tantek Çelik Dave Cramer Bruno de Oliveira Abinader Elika Etemad Sylvain Galineau Daniel Glazman Rebecca Hauck Dongwoo Joshua Im Dael Jackson Brian Kardell Philippe Le Hégaret Peter Linss Edward O'Connor Christopher Palmer Matt Rakow Simon Sapin Dirk Schultz Alan Stearns Leif Arne Storset Regrets: Mihai Balan Justin Erenkrantz Simon Fraser Brad Kemper Simon Pieters Anton Prowse Florian Rivoal Lea Verou Steve Zilles Scribe: Dael Extra Items ----------- glazou: Let's start glazou: As usual, any extra items? glazou: The agenda is pretty full, but if you have something we can retain for next week, that's fine. glazou: We have an item from tantek. <tantek> (hopefully quick, had one positive response from TabAtkins, no objections) ???: Is it worth doing a poll on the call? glazou: You mean selectors? I suggest we do that. glazou: I think the poll is invalid because it was changed. TabAtkins: As I said we know who saw it before the change. glazou: We're just adding items now, and I responded on the list. <SimonSapin> (TabAtkins, present it as two polls with separate results) glazou: So first extra item is the poll. Any others? Charter ------- glazou: Can we have an update on charter extension? Before you said it would be ready before the F2F. plh: I think we're on track and don't expect any surprises. glazou: Any questions? New Regions WD -------------- astearns: Just asking for a new WD. It's been 8 months since the last WD and there's been substantial changes so I'd like to publish. Bert: Is this the split we discussed at the F2F? astearns: Yes. Bert: Okay glazou: So you approve? bert: I do RESOLVED: Publish a new WD of Regions glazou: Given that it's a hot topic, let's insert the selector poll now Selector Poll ------------- glazou: So TabAtkins publisher a poll about selectors. In short it was a question, do you prefer ! as the descriptor or :has. glazou: The problem is originally it was ! or has but after 130 responses he changed the wording. glazou: Lots of people rejected ! glazou: I think the new question is different and I don't think that we can infer anything because of that. glazou: SimonSapin suggested a new poll with three options, ! :has, or ^ glazou: So I think I reject the results of the poll. SimonSapin: I agree results are useless but I think TabAtkins should separate the results of the exit poll. TabAtkins: I can do first 130 of ! vs. :has and the rest as ^ vs. :has glazou: I don't think you can do that. TabAtkins: I think we have an overwhelming result. glazou: This just isn't the same question. TabAtkins: We've had 800 results and most of them picked the same answer as before. * sgalineau would love to discuss the issue instead of arguing about the polling <SimonSapin> sgalineau +1 <dbaron> So if you polled two separate questions at different times, just report the results separately? <SimonSapin> dbaron, this is effectively what happened glazou: Taking my co-chair hat off, as a standards body we aim at doing things right and this isn't done right. We don't change the question in the middle of a vote. glazou: Even if it's only 10% that disagree with what you say is final results. TabAtkins: We're randomly sampling in the first place, so it just doesn't matter if they're two separate polls. <astearns> +1 to Tab's position. The results are useful considered separately. And they both point to the same result. * sgalineau thinks good polling is actually hard and we're unlikely to get anywhere near as much as we think from those things. * sgalineau "design by committee can't decide...let's do a poll!" <SimonSapin> TabAtkins, please give numbers for the separate results on IRC. bkardell: Since I'm on neither side of the discussion, bkardell: I think when they put the poll together what they wanted to gage wasn't if ! is confusing. bkardell: But they wanted an idea of if they like and indicator or like a combinator. bkardell: Overwhelming people picked the combinator. bkardell: We mixed two questions and I think TabAtkins was trying to act in good faith to see if we were asking the right question. bkardell: TabAtkins was saying we can derive that people want a combinator and we can do another poll. glazou: Reading the results, I think people were influenced by the ! and they were rejecting the ! TabAtkins: And that's why the poll was changed to see if that was an issue. * TabAtkins is going to leave the call until people stop ignoring that we're random-sampling this stuff and so it doesn't matter. bkardell: Do we have a reason for not doing what TabAtkins Is suggesting? ???: Is this just avoiding work so we can prove what TabAtkins is saying or have another statement? bkardell: I think we can frame that poll with having just three options and that'll work. * sgalineau 15mn into a one hour call we're still arguing about the poll instead of the issue. glazou: I think it's painful that we can't discuss what a member did without him leaving. glazou: I'm going to stop now, but I'm disputing the results which we're going to specify. glazou: This is impossible to discuss. glazou: We don't have an update on Shadow DOM without TabAtkins. <TabAtkins> I'm still here, I just can't stand listening to people pretend that a poll is "biased" because they don't understand population statistics. glazou: I think saying I don't understand population stats is an insult. plh: I don't think that was the point, though. glazou: I'm saying the sampling isn't valid due to the change. sgalineau: I think there was an issue and we tried to resolve it. We can look at the issue and try and resolve the difference, but I think that we're running in circles and not making progress. glazou: TabAtkins for Shadow DOM? Shadow DOM ---------- TabAtkins: Let me pull the info. TabAtkins: First I'd like to see if we can finalize a named combinator. TabAtkins: I'm assuming that /ident is a decent syntax TabAtkins: It looks good to me and people in the thread. * fantasai doesn't like it fantasai: I don't think that /ident is good because that's usually punctuation. TabAtkins: It's usually just a character so I think a syntax in that pattern isn't a good idea. We have :ident #ident etc. and they're all a compound selector. TabAtkins: If we're going to have that, it should have punctuation at the beginning and end and follow the white space rules of combinators <TabAtkins> `foo` ??: I think a few people liked the idea of brackets. <TabAtkins> /foo/ <fantasai> /ident/ fantasai: We can just use that [above] <fantasai> /ref somethingorother/ <SimonSapin> is '/ ident' the same as '/ident' ? <fantasai> no <TabAtkins> SimonSapin: No, it's not - ". ident" isn't the same as ".ident" <SimonSapin> ok <TabAtkins> SimonSapin: Whitespace is significant in selectors. TabAtkins: I'm fine with that. I like single slash, but 2 is okay as well. <astearns> I'm OK with either as well <fantasai> well, I guess we could define it either way :) hober: I realize we don't have single style comments in CSS, but I worry that using something close to C++ is confusing to authors. fantasai: It's a single slash followed by another slash, though. bkardell: We could also use backticks. <sgalineau> so fantasai would rather have something like /foo/ <sgalineau> ? TabAtkins: I'm down with that. If the WG would like to resolve that's fine. fantasai: I'm still wondering if it should be combinator instead of a pseudo-class, but I haven't read entire thread. TabAtkins: Any other syntax suggestions? TabAtkins: backticks, slashes or pseudo-elements? * sgalineau caught up with IRC. Is OK with /foo/ <bkardell> I am good with `foo` or /foo/ * fantasai doesn't like backticks, they're too light * fantasai visually hober: This isn't strictly combinator syntax. hober: I'm just wondering do we want to allow for future CSS to allow author-defined custom items? TabAtkins: Possibly which makes the ident nice. hober: I'm not sure quite what exclusion there was but I'd rather avoid collisions between the WG and arbitrary definitions. TabAtkins: The way the F2F discussion went was - are technically allowed in HTML, the main space is ident-. TabAtkins: In CSS we use _ the same. TabAtkins: So if your media query has _ it's custom. hober: I'm fine with that for now. TabAtkins: This is a little ugly, but it works. We'll avoid collisions. TabAtkins: Since there's no additional syntax ideas, feel free to butt in. TabAtkins: Are we okay with / on both ends? TabAtkins: I'd like to resolve on that. hober: If we want a combinator in the future we can bring it back. fantasai: I'm not sure if using a combinator rather than pseudo- class is right, but if we're going with a combinator this syntax is good. <TabAtkins> /ref(foo)/ or /ref foo/ or whatever hober: I'd like to authorize TabAtkins to do what he needs, but I'm not sure I want to say this is the right thing to do. hober: Would a watered down resolution to allow you to spec be okay? TabAtkins: I spec'ed it. I want to know if the WG is okay with this direction. fantasai: Is this in selectors or shadow DOM? TabAtkins: Putting it in selectors. fantasai: I'd pref Shadow DOM and let selectors stabilize before shifting things into it. bkardell: Is that because you're not settled on named combinators? <glenn> +1 to what fantasai is saying fantasai: I'm not objecting per se but I'm not sure if this is the right idea. Selectors is almost implemented and this isn't qualified. I'd rather leave it in Shadow DOM so that it can be discussed more. fantasai: I don't want to mix this unstable thing with selectors where we're trying to take unstable things out. TabAtkins: As long as no one is actively objecting to syntax it is good enough for me for now. * fantasai let the shadow dom debate happen in the shadow dom...inion TabAtkins: In other words it sounds like we can move on, glazou: Excellent Counter Styles API ------------------ TabAtkins: Xidorn brought up interesting CSSOM questions TabAtkins: If you don't spec a descriptor in the style sheet, what rule should appear? Null, empty string, or initial value? glenn: Any implementation consistency? TabAtkins: None I've seen. @font-face has it implemented. dbaron: In many ways this is similar to properties, but there's no difference between initial value and unset. dbaron: My feeling is leave it the same as there's not a semantic difference. <dbaron> ... as the empty string fantasai: An interesting question is if you're doing the OM, do you want to rest, or preserve what the editor put in? fantasai: If there's no semantic difference it seems like things that are initial should stay set that way. TabAtkins: That's a separate but related question. You need to spec how these things serialize. TabAtkins: If you omit everything you would omit anything set to initial value too. TabAtkins: I think I like having it reflect initial value and on the serialization side specify you omit the scriptor is it's they're initial value TabAtkins: How does that sound? dbaron: One question is what do they do for @font-face? TabAtkins: I'm not sure. If we want to move on and come back to me I can test for 5 min and come back with data. TabAtkins: So let's do that. I'll come back in a few to tell you what @font-face does in chrome and Firefox. glazou: So we can move on? Concept of Baselines -------------------- dbaron: I don't think this needs telecon time. glazou: Okay, good. ::first-letter -------------- dbaron: We had a long debate about what goes in ::first-letter. dbaron: The spec is specific when punctuation extends the first letter, but not what a first letter is. dbaron: ::first-letter applies to the first letter and also applies to digits, but doesn't mention anything else. dbaron: I think Gecko is the only one that does letter or digits and we occasionally get bugs were people expect it to apply to symbols. dbaron: I remember + and $. dbaron: It would be nice if the spec said what the first letter applied to. dbaron: There's one other quirk with this where we reference character classes we need to say what version of Unicode we're referencing. dbaron: Do people think symbols should be a first letter? Is that a bug in other implementations? fantasai: I think it's fine. The interesting question is do we just include the symbol, or the symbol and the next thing astearns: I would expect only the symbol. bert: That's not what I would expect. SimonSapin: Is this based on unicode categories? dbaron: That would be nice. hober: So we would blacklist a bunch of categories it doesn't apply to? dbaron: That may work, things like white space. fantasai: There's two levels of general classes in unicode, like higher and lower level ones. fantasai: I think we're only interested in doing high level ones. hober: Suppose unicode decided to add a new top level class. I'd rather have that included. I don't anticipate them adding white space. dbaron: I think if they add a new class, we want the old rules to apply. dbaron: Unless someone else wants to, I guess I should write a proposal? Rossen_: I think we're all agreeing. dbaron: Sounds like we're done. TabAtkins: Can we jump back? Counter Styles API ------------------ TabAtkins: In both Chrome and Firefox, unspecified descriptors in @font-face is the empty string. TabAtkins: I'll find a place to spec that. dbaron: Sounds good to me, given that it's what we do for properties. TabAtkins: Cool. TabAtkins: Can we get a resolutions? glazou: Comments? TabAtkins: For any unspecified descriptors in @ rules that font- face and counter style, they're in the OM as the empty string Rossen_: And this is what they do? TabAtkins: In Chrome and fireforx. Rossen_: Can you post that test? <TabAtkins> <!DOCTYPE html> <TabAtkins> <style> <TabAtkins> @font-face { <TabAtkins> font-family: foo; <TabAtkins> src: url(foo); <TabAtkins> } <TabAtkins> </style> TabAtkins: I did that and poked around for font weights. glazou: To be sure, it's when you query the explicit value of a descriptor? TabAtkins: That's a good question. glazou: I don't want to see it affecting a group. TabAtkins: CSSOM defines that and implementations differ. TabAtkins: Right now in chrome you see every property that could apply to any element show up. TabAtkins: That's likely because we're using the same implementation. glazou: Then I have no objections. rossen: Just a second, I'm getting on my computer to test it. TabAtkins: Do you want us to wait, or should we move on and you can report back? Rossen_: It'll take me two minutes. glazou: We'll come back when Rossen_ is ready. Grid Issues ----------- SimonSapin: The biggest issue is how we define size of grid item and grid container. SimonSapin: Did I miss that in the spec, or is it not written? TabAtkins: I'm not ready to handle the issues. We're working on it and will answer as we get there. TabAtkins: We haven't made it there quite yet. Fantasai and I are working together, but were concentrating on flexbox earlier. TabAtkins: As soon as I can I'll do it, but if you want to message me privately with a time line you're looking at, that's okay. SimonSapin: We don't need more time for any grid issues. Inline box, atomic inline-level box, and transformable elements --------------------------------------------------------------- <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014Feb/0356.html glazou: I saw some mailing list answers on this TabAtkins: I think he has asking about the earlier decision that inline-elements are able to be transformed, TabAtkins: And dbaron had a separate question that was tangentially related about the spec only applying to elements related to CSS. TabAtkins: But that's different than the original question. dbaron: My question was that the spec isn't saying what we want it to and we should check that before we nit-pick. dbaron: So we said it shouldn't apply to transforms. many: Yes. ??: I think we want to say we can transform a box, not a collection of elements. TabAtkins: We only transform fragments that are the sole fragment created by a box. TabAtkins: They're the sole fragment by decision not happenstance. dbaron: Didn't we have a long discussion about how transforms apply to fragmented blocks at the F2F? ??: We did, but we didn't agree. The agreement was it shouldn't apply. * Rossen_ I'm good with the previous resolution dbaron: Seems bad that it stops applying as soon as you print. ??: That's a good question. dbaron: I'm okay with not applying to inline, but I'm not okay that it stops as soon as it fragments. TabAtkins: Starting with the base question, is the test wrong because spec says it shouldn't apply to inline? TabAtkins: In other words, the test is wrong. It currently assumes that fragments apply to inline. TabAtkins: Cool. So Gerard is right. We can take this later to decide what the definition of transformable elements should be. TabAtkins: So it sounds like that finishes the issue. glazou: Okay. <dbaron> seems like the spec ought to exclude non-replaced inlines rather than imply that any new formatting primitives ( flexbox, grid, etc.) aren't transformable glazou: tantek you still there? Line box edge ------------- <tantek> http://lists.w3.org/Archives/Public/www-style/2014Feb/0140.html tantek: I made a proposal to change that based on implementations. tantek: I got one positive reply, but I wanted to run it by the group before I edited. ???: It sounded good to me. <fantasai> +1 from me tantek: Thanks fantasai. glazou: Other opinions? fantasai: I think you want to run it by Robert O'Callahan. tantek: I already pinged him. I want to hear from other implementors. tantek: We (firefox) want to match webkit and want to make sure other implementors find it acceptable. Rossen_: It will mean a change for us, but I agree auto behavior makes more sense. <Bert> +1 from me, too glazou: Anyone from webkit? tantek: There's two changes, one webkit already does, one that's a logical consequence of the change. tantek: I don't think anyone does the second behavior yet, but it makes sense. Rossen_: I think that's fine. We can revisit later. glazou: No objections? You've got it tantek. glazou: We've got more time. Anything else? tantek: Did you do charter? glazou: Yes. It'll be under review shortly. tantek: I think the super-group discussion needs to continue. glazou: Yes, from time to time it's extremely bureaucratic. glazou: It lacks a bit, but I don't think all existing super- groups will be in the same category. glazou: They'll be quite different and I'm not sure the current prose will work for everything. tantek: I think glazou is having a positive impact and you should keep going. glazou: We needed something different. This isn't working. glazou: Anything else? glazou: Thank you and talk to you next week.
Received on Thursday, 13 February 2014 02:16:35 UTC