- From: fantasai <[email protected]>
- Date: Wed, 10 Apr 2013 18:19:00 -0700
- To: "[email protected]" <[email protected]>
Summary: - Liam to add proposal for advanced line-breaking to CSS4 Text - RESOLVED: Variables move to LC. Inform WebApps, SVG, HTML WGs. - RESOLVED: Do not adopt MQ-style invalidation for Selectors due to Web-compat concerns. - Discussed allowing #123abc to be a valid ID selector, to match HTML5. Need to collect data on this. - RESOLVED: :nth-child()/etc don't require a parent - they're based on siblings. - RESOLVED: Changed specificity of :matches()/:not() to the specificity of the actual matched selector. But see follow-up issue... http://lists.w3.org/Archives/Public/www-style/2013Mar/0332.html - RESOLVED: Define a new selector that matches element that is either completely empty or contains only whitespace. Note: Need naming suggestions. - RESOLVED: Accept the two profiles of Selectors, with "fast" for CSS Selectors and "complete" for Selectors API. ====== Full minutes ====== Present: Glenn Adams Rossen Atanassov Tab Atkins Tantek elik Bert Bos Jim Dovey Arron Eicholz Elika Etemad Simon Fraser Dael Jackson Sylvain Galineau Daniel Glamzna Rebecca Hauck Koji Ishii John Jansen Brad Kemper Philippe Le Hgaret Edward O'Connor Anton Prowse Liam Quin Matt Rakow Simon Sapin Dirk Schulze Alan Stearns Leif Arne Storset Nick Van den Bleeken Steve Zilles Regrets: danielweck, dbaron, florian, leaverou, SimonPieters <RRSAgent> logging to http://www.w3.org/2013/04/10-css-irc Agenda: http://lists.w3.org/Archives/Public/www-style/2013Apr/0197.html Scribe: TabAtkins Administrative -------------- glazou: Three extra agenda items. glazou: First from Tab about Variables, next about text-decor, another from Simon Sapin about scientific notation. Line-Breaking Proposal ---------------------- <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0183.html liam: I'll just go over general purpose. liam: When you add things like hyphenation, etc. you quickly want to use a line-breaking algorithm that considers more than one line at a time. liam: It's more important in print than on the screen, because print has "show-through", where you can see a shadow of what's on the other side of the sheet. liam: This proposal is to let an author/script say "this piece of text is going to be interactively edited"... liam: I imagine a print processor would set this to "batch" - not edited. liam: You care about editted or not because if you insert a word in the middle of a paragraph, and you use a multi-line linebreaking algo, your text will reflow and your insertion point might move up or down a line. liam: Some programs handle this by only reflowing when you finish editing, but it's ugly in the meantime. It's a problem with a long history. liam: Two parts of this proposal: liam: 1) Say your intent, interactive or batch. liam: 2) Second, experimentally, say what algorithm to use. TabAtkins: Is the "interactive" mode about just editting, or about reflowing as well? liam: It only matters if the user is in there. liam: If the text reflows and you care about a particular line of text, that's the same problem you've already got. TabAtkins: Okay, next concern - I thought the problem with the TeX algorithm was it being too complex/slow. Has that changed? liam: It's slow, yes, but normal text is also really mediocre. It has really bad cases that you need markup to fix, because it's meant to be manually checked. liam: Commercial products almost all use an n-line algorithm, that's only slightly slower than the current linear linebreaking (still O(n)). liam: With that, you can get quality of line-breaking close to the best commercial. SimonSapin: Is this related to Adobe's "text balancing" proposal? stearns: Don't think so. You can implement text-balancing in a more complex linebreaking algo, but it's not necessary. glazou: Do you think this is for both print and screen media. liam: Both. TabAtkins: Yeah, I know plenty of people who would want good text on the screen. glazou: I think the next step is an ED. liam: I wasn't sure whether the best step was Text 4 or a new draft. fantasai: I think it should go in Text 4. fantasai: Text 4 needs to be synced up with Text 3 (the text is old, because we branched a while ago). fantasai: Once it's synced up, we can add things to it. liam: When you get to this bit, I'll happily help. ACTION fantasai to add Liam's line-breaking proposal to Text 4. <trackbot> Created ACTION-553 ACTION liam to help fantasai add his line-breaking proposal to Text 4. <trackbot> Created ACTION-554 image-rendering: smooth ----------------------- <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0750.html smfr: Don't think there's anything to say here. TabAtkins: Yes, I'm fine with the editting. Was just on vacation last week, so haven't done it yet. Variables Last Call ------------------- TabAtkins: I asked for LC a few weeks ago, but jdaggett wanted a new WD first to pull out feedback. I've done so, and it was useful. Can I go to LC now? SimonSapin: I have some questions about how the Syntax works with Syntax 3, but I can handle that on the list. It's technical, but I don't think it'll change anything. glazou: objections? Bert: I don't object, but I don't think we need it... RESOLVED: Variables move to LC. Bert: We need to decide as a group what other WGs to talk to. TabAtkins: WebApps. glazou: SVG. glazou: HTML? TabAtkins: Sure, though most of their connection will be through webapps work. RESOLVED: Inform WebApps, SVG, and HTML about Variables LC. * shepazu wants to talk in-depth with Tab about Variables and Params Selectors 4 ----------- <glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0187.html glazou: Speaking of Selectors, I think some sections of the document (time-based pseudos, for example), need a review from the WG. fantasai: I brought that up on www-style/at a f2f, but nobody had comments. glazou: Right. Everyone, if you have spare cycles, read Selectors 4 and give comments. fantasai: First issue is about adopting MQ-style invalidation. fantasai: Currently, any invalid selectors invalidates the entire list. fantasai: Alternative is to just drop the selector that's invalid (split by commas). fantasai: But this seems to be quite web-incompatible, because people depend on this behavior. sylvaing: How do people depend on this? glazou: Right now there are style rules which are fully invalid because of one selector, and authors never noticed the wasted rule. If you change, it'll start applying and change the page. TabAtkins: And there is some history of people using prefixed selectors in the selector list as a browser hack, and this would change the behavior they're depending on. RESOLVED: Do not adopt MQ-style invalidation for Selectors. fantasai: Next issue is whether ID selectors should accept all hash tokens, or just hash tokens with an ident value. fantasai: For example, #1 is a valid hash token, but not a valid id selector. fantasai: HTML now, I believe, allows IDs that start with a number. <tantek> it does glazou: Do you think this has compat impact? TabAtkins: I suspect this is used much less. arronei: Isn't this the same case as the last one? Groups could be invalid currently that would become valid. glazou: If HTML now allows non-ident selectors, then this is a needed change. SimonSapin: Any way to assess the impact of this change? [discussion about using Google resources for this] hober: It's hard to say without data. Rossen: We'd have to run a query and see how many hits we have. Without data, we're uncomfortable committing. tantek: I don't have any hard data, but I can give you anecdotally... tantek: One of the things that happens in mediawiki pages is that whatever you use as a heading/subheading gets turned into an id. tantek: So if you have a heading start with a number, that's the id. tantek: One major complaint I hear is headings that are just numbers. tantek: Whether they're getting styled or not, I have no idea. TabAtkins: I can confirm that browsers are pretty consistent about allowing full hash tokens in Quirks mode, but only restricted ident hashes in Standards mode. glazou: Two members of the WG are asking for data here. ACTION tab to look for data on non-ident hash usage. <trackbot> Created ACTION-555 * sgalineau if this works in quirks the difference makes it harder to switch to standard mode... <tantek> FYI: regarding ID selectors that start with numbers, we do test for the non-support - in the CSS 2.1 test suite: http://test.csswg.org/suites/css2.1/20110323/html4/id-selector-005.htm <tantek> that's why we have interop among browsers for non-support of ID selectors that start with a number. <glazou> http://www.w3.org/Style/CSS/Tracker/issues/317 fantasai: child-index pseudos (:nth-child(), etc.) don't work on unparented elements, such as :root. This makes sense there, because there's not much use in having them apply to root, but there's also the issue of document fragments. fantasai: (the top-level elements in a document fragment won't match :nth-child() etc.) fantasai: The only argument I've heard against it is that the word "child" is in the name, so it should only apply to children. glazou: We deal only with elements in CSS. [tab explains things wrt DocumentFragment case becoming more common, shadow dom, etc] fantasai: We wouldn't be having this argument if it were called :nth-sibling glazou: I would prefer a new pseudoclass. <SimonSapin> not 1 new pseudo-classes, 11 of them TabAtkins: It's silly and confusing to add new pseudo-class that means exactly the same thing except when selecting root or DocumentFragment elements * fantasai agrees strongly with Tab on this point glazou: I don't think it should apply to root. TabAtkins: I'm fine with that, if it applies to docfrags and shadow dom and the like. glazou: I could live with an addition to the shadow DOM spec that says shadow roots act like a parent. TabAtkins: Then we'd have to add the same thing to DOM for docfrags. Tab's proposed spec text: The pseudo-classes defined in this section select elements based on their index in their parent's list of children (or, if they have no parent, by their index in the list of them and their siblings). <SimonSapin> can DocumentFragment contain multiple "root" elements? <oyvind> yes <TabAtkins> no. ^_^ <SimonSapin> ? <oyvind> well, a documentfragment can have multiple child nodes <oyvind> I figured that was what SimonSapin meant :) <SimonSapin> oyvind: yes <SimonSapin> in that case it makes sense for :nth-child() to apply Bert: What does :root match in document fragments? TabAtkins: Nothing, I believe. There's no root element in a docfrag. * sgalineau cannot tell if we are in a rathole or a bikeshed MINUTE BANKRUPTCY Bert: I'm trying to find the similarities between document and docfrag. * SimonSapin agrees with Tab Bert: If we do this for :nth-child, maybe we should do it for :root too. TabAtkins: Nah, no need. :nth-child() is being redefined into just based on siblings. :root is still about document roots, which docfrags don't have. glazou: I'm okay with this change, though I don't like it. RESOLVED: :nth-child()/etc don't require a parent - they're based on siblings. antonp: Can we have a note saying that the name doesn't make much sense anymore? fantasai: Yes. Bert: It seems that your addition makes :first-child apply to the root element, which wasn't the case before. Bert: So should there be text saying that it only applies to docfrags, not roots? TabAtkins: I don't think that's necessary. Incidence of :first-child selectors that accidentally hit the root should be so low as to be effectively zero. fantasai: We'll come back with final phrasing so everyone can comment. Bert: I'm not comfortable with changing things for existing documents. Probably rare for HTML, but there are many other kinds of documents. Bert: There's a use-case for fragments, but not for normal documents. TabAtkins: I'm fine with discussing on the list whether :root and :nth-child/etc should be mutually-exclusive. Bert: That's fine. <glazou> https://www.w3.org/Style/CSS/Tracker/issues/318 fantasai: Next issue is about the specificity of :matches() and :not(). fantasai: Currently the specificity of :matches() is the specificity of the most specific selector inside it. fantasai: dbaron's proposal was to make it the most specific selector that actually matched, so that it truly becomes syntactic sugar for the combinatorial-explosion of multiple selectors. fantasai: I think there's no reason not to take this, except that it's slightly annoying to implement. SimonSapin: I brought up that it's not possible to do this when converting selectors to XPath. SimonSapin: but we should still do it because even in Selectors 3 some corner cases can (probably) not be expressed in XPath TabAtkins: Yeah, while XPath and Selectors are very similar techs, they both have edge-cases that can't be converted. It's fine, I think. RESOLVED: Changed specificity of :matches()/:not() to the specificity of the actual matched selector. <glazou> https://www.w3.org/Style/CSS/Tracker/issues/319 fantasai: Next topic, :empty is pretty useless for most people. fantasai: It only selects elements with no nodes, which means that whitespace makes it not match, even though that gets collapsed away in HTML. fantasai: We can redefine :empty to also match if the element is only filled with whitespace, or we can make a new pseudoclass for it. glazou: I recommend the latter. fantasai: Is there a use-case for the former? Bert: Something with a space isn't empty. glazou: I used :empty as it is for something in Gecko. <tantek> we have a test for :empty that checks to make sure it is NOT applied to an element with only white-space: http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/css3-modsel-151.html <tantek> therefore we have interop on it in current form <tantek> so changing it would break all browsers fantasai: So what would we name it? Bert: :blank? fantasai: I thought we might use that for empty inputs... <tantek> :space <fantasai> tantek, it's potentially empty <tantek> space is pretty empty ;) <tantek> :visibly-empty glazou: What about :almost-empty? <plinss> :mostly-empty <leif1> :insignificant <Rossen> :just-about-empty <TabAtkins> :this-element-intentionally-left-blank * sgalineau approves of all these as aliases <BradK> :good-as-empty <tantek> :empty-or-space <jdovey> :quiet <Rossen> :boring <tantek> :silent <BradK> :white-space szilles: :void TabAtkins: Confusing because void refers to what :empty currently means. SimonSapin: Would this select elements with other empty children? <SimonSapin> <div><div></div></div> fantasai: No, only elements that contain nothing or insignificant whitespace. glazou: We agree on the selector, but still need to come up with a good name. RESOLVED: Define a new selector that matches empty or only whitespace. <glazou> https://www.w3.org/Style/CSS/Tracker/issues/320 fantasai: :matches() was always intended to be able to accept complex selectors (with combinators). fantasai: Right now the Selectors 4 draft has explicitly excluded them, due to performance concerns. fantasai: But this confuses everybody, because they want complex selectors, and ask for new features. fantasai: Also, the performance concerns don't apply to batch processors or Selectors API - only to CSS Selectors. fantasai: So the idea is to define "fast" and "complete" profiles. "fast" is only compound selectors in :matches()/:not(), "complete" is everything. fantasai: We want to mark this as at-risk. fantasai: The alternative is to just include complex selectors and mark the whole thing as at-risk. fantasai: We just want to find out what implementations actually want to do. glazou: I have a problem. It implies that after CR we may have shipped impls of either profile, so inconsistency for the web. glazou: I understand you have the two profiles for Selectors API. glazou: I'd prefer that the fast profile be explicitly limited to CSS Selectors, and complete be for everything. Then we can decide to open up the profiles later. glazou doesn't want individual implementations deciding whether to implement "complete" profile for CSS. SimonSapin: I'm concerned that the same impl could match different profiles based on the use (print vs live, etc.) SimonSapin: Would prefer that we restrict selectors on CSS for all types of implementations. fantasai: I'm fine with this. fantasai: I just want to reduce confusion in the spec. plinss: If we later allow browser to implement the complete profile, there will still be a transitional state, so I'm not sure what we buy here. fantasai: If everyone's ready for it, there will be a short transition period, as opposed to the current undefined transition. glazou: What if we just mark the complete profile as being informative, with it being defined normatively in the future? TabAtkins: I'm opposed to that, because I want Selectors API to pick it up. glazou: I'm okay with that. RESOLVED: Accept the two profiles of Selectors, with "fast" for CSS Selectors and "complete" for Selectors API.
Received on Thursday, 11 April 2013 01:19:28 UTC