- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 20 Nov 2014 18:01:30 -0500
- To: www-style@w3.org
Re-naming flex-basis: auto --------------------------- - RESOLVED: Accept fantasai's proposal for flex-basis: auto changes (auto means main-size and add a keyword for automatic sizing) Unicode-range syntax --------------------- - It was quickly agreed that the text could move to the Fonts spec. - There was disagreement between jdaggett and TabAtkins as to if this additional normative text was necessary for the spec, however, implementors stated that they did want the text available to them. A compromise was reached where it would be in an appendix so that regular authors wouldn't normally encounter it. - RESOLVED: Move the <urange> definition to an appendix in the Fonts spec. CSS3-UI ------- - RESOLVED: Drop pseudo classes from CSS3-UI in favor of Selectors 4 - RESOLVED: For clarity, all future pseudo-classes should be in a Selectors module - RESOLVED: Drop XFORMS related pseudo-elements. - A tracking of the moved and removed pseudo-elements and pseudo- classes is available here: https://wiki.csswg.org/spec/css4-ui#more-selectors - RESOLVED: Drop content: icon and the icon property - RESOLVED: pull nav-index from level 3 and put it on a wiki - Tantek requested that individuals add the URLs for discussions related to nav-index here: https://wiki.csswg.org/spec/css3-ui?&#issue-25 - There wasn't time to discuss the text-overflow issue, so discussion will continue on the mailing list. Box-Tree API ------------ - RESOLVED: Create a taskforce to work on box-tree API and extensible CSS APIs ===== FULL MINUTES BELOW ====== Present: Rossen Atanassov Tab Atkins David Baron Bert Bos Tantek Çelik Dave Cramer Alex Critchfield John Daggett Simon Fraser Sylvain Galineau Daniel Glazman Dael Jackson Brad Kemper Chris Lilley Peter Linss Mike Miller Simon Pieters Anton Prowse Florian Rivoal Simon Sapin Alan Stearns Greg Whitworth Steve Zilles Regrets: Adenilson Cavalcanti Bruno de Oliveira Abinader Dirk Schulze Mike Sherov Ian Vollick Lea Verou Scribe: dael plinss: Let's get started. Anything to add to the agenda? Florian: TabAtkins raised something about :has-focus. I'd like it added. plinss: Okay. No problem. Re-naming flex-basis: auto --------------------------- <smfr> http://lists.w3.org/Archives/Public/www-style/2014Jul/0008.html plinss: Who wants to talk on this one? * fantasai proposes rossen lead TabAtkins: It's fantasai that wants to talk and she's not here yet. I'm not ready to talk on this yet. dael: [reads fantasai IRC comment] Rossen: I wasn't ready to talk either, but since it's there let's talk. plinss: We can defer. Rossen: I still haven't seen a mass response from developers on this. I did see leaverou say a week or so ago that she chatted with fantasai and gave her feedback. Rossen: That's just one sample. Rossen: If at all possible I'll keep pushing to change to the first option rather than the second which breaks compatibility and I believe is more confusing. That was the issue. Rossen: Where are we, like I said, I'm still waiting on feedback on it. If someone wants to add something we can discuss, otherwise we can defer. fantasai: I think leaverou's feedback was why not content size. I asked other implementors and they posted these: <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Nov/0040.html <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Nov/0041.html <fantasai> third author - http://lists.w3.org/Archives/Public/www-style/2014Nov/0055.html fantasai: Someone else posted...let me find that. fantasai: A little bug seems like...it seems like it doesn't change backwards compatibility. The Mozilla bug was leaning toward not changing to main-size. dbaron: We've had the change that's been in the spec in nightly, but we pulled from beta given the set of regressions it caused. There's a decent compatibility risk, we've had things show up. dbaron: At this point my memory is a bit muddled between which changes caused what regressions. fantasai: What I've heard is Microsoft and Mozilla are worried about compatibility. Author side liked the other option, they don't like dealing with backwards compatibility problems and content as a keyword makes more sense. We're used to 'auto' computing to something. That's the feedback from dev I've pinged, I haven't heard feedback supporting the first. fantasai: Given that, I'd propose where auto means main-size and add a keyword saying 'I want automatic sizing' with content or content-size as the keyword. plinss: So we have a proposal. Opinions? TabAtkins: I like this less, but I won't fight it. It's fine. plinss: dbaron? dbaron: I'm fine with...I'm not into the issue that much, but if people think it's less of a backwards compatibility issue, I'm in favor. fantasai: It definitely will. It doesn't change meaning, just creates new syntax for something you previously couldn't access directly. plinss: Objections? Rossen: I don't want to break backwards compatibility. RESOLVED: Accept fantasai proposal for flex-basis: auto changes (auto means main-size and add a keyword for automatic sizing) Unicode-range syntax --------------------- <jdaggett> basic problem, CSS 2.1 defined UNICODE-RANGE token <jdaggett> 2.1 tokenization: http://www.w3.org/TR/CSS21/syndata.html#tokenization <jdaggett> UNICODE-RANGE u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})? <jdaggett> unicode-range descriptor of @font-face rule uses this <jdaggett> sometimes interferes with other syntax in places outside @font-face rules <jdaggett> like selectors: u+a { color: green } will get tossed by the parser jdaggett: The basic problem is in CSS2.1 the unicode-range token was defined. I put in the tokenization syntax above. jdaggett: The descriptor exists. The problem is sometimes this interferes with other grammar like selectors. jdaggett: I put a test case with the problem (below). It fails in Chrome and Firefox. <jdaggett> testcase: http://people.mozilla.org/~jdaggett/unicoderangetokenization.html jdaggett: The basic resolution was to dump the unicode-range token and replace with something like An+B syntax. <jdaggett> telcon discussion in july: http://lists.w3.org/Archives/Public/www-style/2014Jul/0051.html <jdaggett> The resolution was to dump UNICODE-RANGE token, replace with production "something like An+B" <jdaggett> quick review unicode-range descriptor syntax <jdaggett> list of comma-delimited <urange> values <jdaggett> ex: unicode-range: u+f2e, u+100-1f3, u+2?? <jdaggett> three basic types - single codepoint, range, wildcard <jdaggett> defined in CSS3 Fonts: http://dev.w3.org/csswg/css-fonts/#urange-value <jdaggett> TabAtkins wants to define <urange> in Syntax: dev.w3.org/csswg/css-syntax/#urange-syntax <jdaggett> seems like a verbose explanation of the same thing jdaggett: Basically there's 3 types. There's single codepoint, range, and wildcard. It's currently defined in CSS3 Fonts, but TabAtkins wants to define the <urange> production in syntax spec. I put in the URL to existing and proposed above <jdaggett> and the grammar simply lists a bunch of possible token sequences <jdaggett> <urange> = <jdaggett> u '+' <ident-token> '?'* | <jdaggett> u <dimension-token> '?'* | <jdaggett> u <number-token> '?'* | <jdaggett> u <number-token> <dimension-token> | <jdaggett> u <number-token> <number-token> | <jdaggett> u '+' '?'+ <jdaggett> but the algorithm is simply saying "take this jumble of tokens and reinterpret them as a sequence of..." <jdaggett> ends up being different (and incorrect) version of existing definition <jdaggett> and it's totally out of context since the Fonts spec explains what these ranges represent <jdaggett> and how they are used jdaggett: In the new description you have something like this (above) jdaggett: It ends up being different and not entirely correct. I think it's out of place too since you need information from Font spec, too. It's also just not in the spec where this thing is described how it's used. jdaggett: Resolving to remove the unicode-range token is fine, but this new syntax and algorithm doesn't make a lot of sense to me. It's really hard to read and implementors have to look at both Syntax and Font specs to use it correctly. Since it's only used for the unicode-range descriptor, we don't need it spread across specs. jdaggett: I'd suggest, in the process of removing the unicode-range token, we redefine <urange> to link to this and avoid linking to syntax spec. * fantasai thought we already removed the token? <ChrisL> agree it makes sense for all the spec of urange to be in css3 fonts TabAtkins: There's several issues here. The location of the <urange>, I don't care where it's defined. I put it in syntax because it's a spec I edit and it's a weird complex thing that I put with a bunch of other weird complex things, but if you want it in Fonts, fine. Don't care. TabAtkins: If you want it in fonts, that's fine. Not an issue. TabAtkins: You also said it's incorrect, but you haven't pointed out where. I ported the definition of the old parsing and modified it in a few small places. It should be as correct and match the old unicode-range. We don't accept wider or narrower then the old version. TabAtkins: The definition itself is ugly, I agree. This is what happens when you mix syntaxes. jdaggett: It's not necessary. TabAtkins: It is. You can't use the existing Font spec that defines roughly how it looks because it doesn't map into a string of tokens properly. It's ugly and terrible and that's why it says this isn't for authors to read and I have a note to read other bits and that this bit is just for implementors. <fantasai> You could put it into an appendix jdaggett: You're not giving precise mapping. If you look at the algorithm it just says reinterpret as these other things. The grammar is so complex because the syntax is hairy and we can't it capture easily. What you wrote is what an implementor will get from the existing test and this doesn't add clarity. TabAtkins: The token definitions I've pulled out are non-obvious, but they are what an implementor needs to recognize. Asserting we don't need to write that is wrong. We absolutely need to write that or each implementor will need to recognize those independently. <zcorpan> I agree with TabAtkins on the above. jdaggett: What's my objection is that the grammar is useless. The algorithm isn't whats used, it's saying reinterpret as hex digits. TabAtkins: That's what we need when we remove the old version. <ChrisL> So why was the special token removed? Why not have an opaque blob for that one thing? <dbaron> ChrisL, because it matched things that it wasn't supposed to match, like some selectors <ChrisL> thanks, dbaron <dbaron> ChrisL, we were having trouble telling authors why u+i was a valid selector and u+a was not <zcorpan> ChrisL e.g. u+a {} <ChrisL> got it dbaron: I think we need to say how a token stream needs to be interpreted. I think part of the controversy was TabAtkins making changes about what's valid and invalid. TabAtkins: Which I dropped back from. I found it easier to do explicit parsing that matches the old text. It matches everything it did before. Nothing that didn't match before matches now. jdaggett: dbaron, why do you think the algorithm is necessary? jdaggett: The production will be longer than it is now. dbaron: It will, yes. TabAtkins: If we were doing this today we wouldn't use this syntax. We would use something more compatible. We're stuck with it. It's fine. It's nice and usable. However describing it in syntax now that we've removed the token, it's messy, but that's for implementors to deal with. TabAtkins: Developers doesn't have to worry about the messy, they get a nice simple way. <jdaggett> u+2f3f? is not captured with the current syntax Florian: One question. Even though it's hard, can you have the new syntax be separate? Is this approach useful or redundant? TabAtkins: Depends on how much work you're willing to do. dbaron: And how precise the other text is. Florian: So having two definitions that say the same thing, is that useful? Maybe making one an informative note explaining the other. TabAtkins: The pretty author text, that's the informative. The normative is the algorithm. fantasai: We might want it in an appendix, also. TabAtkins: That's reasonable. <dbaron> I think the complexity of expressing this makes me wonder if we should instead keep the token and teach selectors how to handle unicode-range tokens as selectors. jdaggett: It's basically useless information. I think we need to allow for variations in number of tokens, blah blah blah. TabAtkins: That's captured by dimension with optional ? clause. jdaggett: That's 2F3. How's that captured. TabAtkins: It's a valid dimension. <zcorpan_> u+2f2f? -> IDENT(u) DIMENSION(+2, f2f) DELIM(?) jdaggett: This isn't helping anything. An implementor is thinking the algorithm and what are the set of tokens I'm getting and I'll reinterpret as a string. The algorithm captures existing syntax. <SimonSapin> As an implementer: yes, making this weird messy grammar explicit is useful TabAtkins: That's the point. The point is to describe the syntax in terms of CSS language. I think you're imagining that implementors can just image the underlying pieces. If unicode is defined as a higher level, I need to define it in terms of tokens. TabAtkins: You're arguing for us to reintroduce the unicode-range token. That's what we don't want because it's a complex structure that's interfering. So we're left with this messy one. jdaggett: You're describing what the spec could describe by saying instead of unicode-range, there's this, this, and this. You've described it and the extra description doesn't help anyone. TabAtkins: Except implementors who want to be interoperable. Florian: I think at this point TabAtkins and jdaggett's positions are clear. I think we need to hear from other people. SimonSapin: As an implementor it helps to have the token explained. jdaggett: Why? SimonSapin: It's what I need to implement. dbaron: If we remove the token, we need this. However, I'm having second thoughts on removing this. We need to leave it and teach selectors how to deal. ChrisL: How would you do that? TabAtkins: The selectors would need to interpret some types of urange as one type selector plus another type selector. That's not for all uranges. TabAtkins: If we need the ugliness somewhere, I'd rather isolate it into the one place it needs to be. Since I have to write a proper parse of Selectors, I dread having to deal with this. plinss: I agree. dbaron: One of the things that is level breaking about TabAtkins proposal is it requires remembering textilization of unicode tokens. TabAtkins: That's already required for hex colors. dbaron: I don't remember having to do that. <zcorpan> dbaron gecko isn't interoperable with IE on hex colors in quirks mode. quirks spec sides with IE currently <zcorpan_> https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk http://w3c-test.org/quirks-mode/hashless-hex-color.html TabAtkins: The quirks spec has a funky thing. It needs to spec a hex color without the hex in front. So to do that you need numbers and idents so you don't drop the leading zeros. Florian: There's a comment saying Gecko isn't compatible with IE on this. TabAtkins: I think we are compatible with IE last I remember. <zcorpan_> 123 = #112233 in IE/spec, but #000123 in gecko/blink plinss: So we have disagreement as to if this needs to be there, but several implementors want it there. I think we have agreement this should be in font spec as an appendix. Can folks live with that? jdaggett: I'm fine with an appendix. plinss: Objections? jdaggett: With the caveat where I think this can be simplified. RESOLVED: Move this definition to an appendix in the Fonts spec <zcorpan> dbaron i guess the quirk spec could be changed though <TabAtkins> Ah, so we're compat with Gecko. Interesting. <TabAtkins> But I tend to suspect that quirks compat leans heavier toward the IE result. <zcorpan> TabAtkins possibly but clearly we can get away with not matching IE here <TabAtkins> zcorpan, sure. We don't *need* numeric representation if dbaron is okay with allowing U+00000000000002 being valid and equivalent to U+0002. <TabAtkins> Oh, well, I suppose I'd need to record some more flags from scinot numbers. <TabAtkins> Right now I translate them directly into numbers. If we drop the representation, I'll need to record that they were scinot and what power they had. <zcorpan> TabAtkins dbaron maybe we should explore killing representation of tokens if having the representation is bad <TabAtkins> zcorpan: I know that our implementor switching us to the Syntax spec wanted to avoid using representation, for memory reasons. It would be nice to avoid. <SimonSapin> TabAtkins, +1 to dropping number representation if possible CSS3-UI ------- Florian: A bunch of small issues, but maybe not too small. The first was discussed at TPAC, but not resolved. Drop the definition of pseudo classes because they're better defined in Selectors. Florian: There's also pseudo-elements. I have two separate points, first one is pseudo-classes are in Selectors 4 and are either identical or have clarified language. Florian: We kind of agreed, but didn't record a resolution. Maybe its been resolved already, but I don't think so. plinss: Objections? <andreyr> no objection tantek: No objections. I think this does need different review from the normal element tree for reasons like the valid/invalid experience we had. No objections to moving them to Selectors 4, I want to figure out how we get more and earlier review to fix them. tantek: I guess that's more of a request for input instead of a proposal. tantek: My comment also applies for moving the pseudo-elements to the pseudo-elements spec. So that same comment/request applies. Florian: So can we resolve on pseudo-classes and move on? plinss: Objections? RESOLVED: Move pseudo-classes from CSS3-UI to Selectors 4. tantek: And this is just for existing ones? plinss: I think in general pseudo-classes should be in some level of selectors. <fantasai> http://dev.w3.org/csswg/selectors4/ fantasai: New ones have been dropped into selectors 4. We just never removed those. tantek: So I'd like that recorded as well. Florian: I'm having a hard time hearing, but I think I'm okay with what I've heard. RESOLVED: For clarity, all future pseudo-classes should be in a Selectors module tantek: Should we do the same with pseudo elements, and move them to the pseudo element spec as well? Florian: For pseudo-elements, I'd agree with tantek's suggestion if we were to keep them at all, but I suggest we drop them entirely since they only apply to XFORMS. <ChrisL> xforms is not really relevant anymore Florian: Bert was tasked with...we lost tantek * Florian waits for tantek to get back online glazou: I don't think there's a single XFORM with a pseudo-element <Bert> (I checked the most likely implementations and did not find pseudo-element support.) <Bert> (Except for XSmiles, which is not maintained.) plinss: I'm not clear is tantek is trying to get back. Florian: So Bert reported it hasn't been used since 2008. <ChrisL> drop it Florian: I contacted betterFORMS which had been suggested on the list as an XForms implementation potentially using these pseudo elements. They don't use them, nor do they know anyone who does. They covert XForms into HTML and style that. So with no known implementations, I suggest we drop them instead of moving them. glazou: I agree with that. plinss: Anyone want to keep 'em? <Florian> Tantek? RESOLVED: Drop XFORMS related pseudo-elements. Florian: Unfortunate that we lost tantek plinss: We'll revisit if he objects. Florian: Similarly the icon value and property don't have implementors and there's no interest. So I suggest we drop them. plinss: Push to level 4 or drop entirely? Florian: I think drop, but I can push if there's interest. So far I've found no interest. plinss: implementors? Anyone want to implement this? Florian: I asked on the list and Google and Microsoft were no if I remember correctly. Florian: Yes, TabAtkins and gregwhitworth say no plan. No other comments. dauwhe: These were in Generated Content and had no interest either <ChrisL> drop smfr: I don't think webkit has interest. plinss: So drop entirely? Florian: We can pull back if someone becomes interested. <smfr> drop dauwhe: I'd say drop <andreyr> drop glazou: drop RESOLVED: Drop content: icon and the icon property Florian: Last drop request is the nav-index. Florian: Directional nav properties are fine, but the index has problems. This has a bit of interest, so I'd suggest move it to level 4, but I think it would hold back CSS3-UI dbaron: We had various discussions with WAI about this. I don't know if they'd be upset about moving to 4, but we should get the results of that discussion in somewhere. ChrisL: Florian, you mentioned some interest? Florian: I vaguely remember that the same people with interest in directional nav had interest, but I don't remember exactly who. <ChrisL> that argues for moving to level 4 rather than dropping, then <tantek> I've been tracking "future" / "postponed" UI related pseudo-classes and pseudo-elements here https://wiki.csswg.org/spec/css4-ui#more-selectors <tantek> gah <tantek> is my IRC getting through at least? <tantek> ??? * smfr tantek yes * Bert sees Tantek on IRC <dbaron> tantek, just got 4 lines at once <tantek> It's in the CSS3-UI issues page folks <tantek> Could someone please check that instead of wondering where it is? <tantek> Search https://wiki.csswg.org/spec/css3-ui for nav-index <tantek> It links to various discussions and things, <tantek> since searching email fails. glazou: In terms of TV, people are more interested in direction then index. If it's implemented it's not used and I'm not sure if it's implemented everywhere. fantasai: I remember some discussion about nav-index and the problem was it's global to the page with no hierarchy. If we can we should try and fix that. It seems that would be better in 4. <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jun/0364.html <fantasai> glazou's email that was this investigation^ glazou: The problem is the use case. Last time I read about that it said this is useless because people are using the arrow keys on the remote. glazou: I think we ping these people to find out if it's used. If it's unused we should drop it and it's worthless to invest time. People have implemented the direction nav, but not the others. fantasai: And we're not talking about dropping direction. glazou: I don't think anything but direction is used. Florian: People still discuss it, so I don't want to drop completely, but we can push to 4 and discuss again when we try and stabilize that. If it's clear no one wants it we can drop immediately. I'm fine with either. <fantasai> minutes from last nav-index discussion with a11y folks: http://lists.w3.org/Archives/Public/www-style/2011Nov/0712.html fantasai: I'd like to push to level 4 with an issue about the things brought up at the last a11y disucssion. Florian: tantek you're back? tantek: Yes. Florian: So, the question is, do we drop nav-index now, or move it to level 4, or stabilize it now. No one seems in favor of stabilizing it now tantek: I haven't seem implementors interested. The potential opportunity is to fix it and make it better then tabindex because it doesn't have backward compatibility problems. And the folks with directional nav stylesheets could use it in the same stylesheet. If that's interesting enough I think we can put it into level 4. If there's no interest, we can drop. tantek: I'll move the text to a wiki and let it evolve passively. tantek: So does anyone in the group, especially those with the directional properties, have interest? <ChrisL> (it seems not) <tantek> for reference: https://wiki.csswg.org/spec/css3-ui?&#issue-25 <tantek> please add more URLs there <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg440 <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg441 glazou: The implementors I dealt with during my time at Samsung had no interest in nav-index. Florian: I don't remember for Opera. I don't think they have stated not being interested, but they haven't expressed interest loudly either. tantek: That's important data. I'd also like to hear from TabAtkins who looked at tabindex. Is it worthwhile? TabAtkins: I don't think so. I think we should fix HTML and then CSS. tantek: Okay, so I'd rather it move to W3C wiki with other semi-abandoned properties so if anyone else wants to get it later, it's good. <Bert> q+ to suggest asking WAI PF for a joint telcon or at least advice stevez: It seems to me that at the protocol group someone talked about the nav-index so check with him to see if there's interest. The question is if they thought it would fix tabindex. fantasai: I linked the F2F discussion. They brought up a lot of problems, I'm not sure how much it was "I want this" tantek: fantasai, can you add your urls to this wiki page? dbaron: I also linked to the follow-up threads. <tantek> Please add your URLs about nav-index here: https://wiki.csswg.org/spec/css3-ui?&#issue-25 <tantek> dbaron and fantasai ^^^ <dbaron> tantek, there's also a separate https://wiki.csswg.org/ideas/nav-index Florian: There seems to be consensus on moving this to a wiki. plinss: sounds reasonable. tantek: If you care about it, put it on the wiki RESOLVED: pull nav-index from level 3 and put it on a wiki Florian: One more. There is a clarification that we need on text-overflow. The prose seems to be contracting itself when the property is used with a single value and you are scrolling the thing that's being ellipsed. Florian: The text appears to be contradicting as to if it applies to both sides or just on the end side. Implementations do end side only. If you have double value it's fine. tantek: This isn't a one minute issue. I believe there was discussion on this with fantasai two years ago we got this to work with Gecko. If the spec has prose problems, I'm going to go with Gecko. tantek: At the time our tests showed no other implementors, IE, Webkit, or Presto were even trying to do something interesting. Florian: Presto does the same as Gecko for the single value, and does not support double value. Others don't do anything interesting indeed. Rossen: This isn't one minute. It's a good topic. Florian: I agree. We can't do this now. tantek: Continue offline. <tantek> we didn't get to :has-focus either - on that topic please review *all* the new CSS UI related selectors being considered/implemented: https://wiki.csswg.org/spec/css4-ui#more-selectors Box-Tree API ------------ plinss: One quick topic myself. We've had some discussions about creating a taskforce for the box-tree API. I don't think we have a resolution for it. plinss: Objections? <ChrisL> +1 <dauwhe> +1 <sgalineau> +1 RESOLVED: Create a taskforce to work on box-tree API and extensible CSS APIs tantek: I want to point out we didn't get to :has-focus. There's a whole bunch of CSS Selectors being implemented. I dropped a link above, give it a look. plinss: That's it for the week, thanks everyone.
Received on Thursday, 20 November 2014 23:01:59 UTC