- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Oct 2014 16:39:57 -0400
- To: www-style@w3.org
Line Grid --------- - RESOLVED: publish WD of line-grid CSS UI ------ - RESOLVED: add 'caret-color' to css3-ui - A desire to color the background/foreground of selected text lead to a conversation about bringing ::selection back and potential issues with exposing security-sensitive items (such as spell-check) - RESOLVED: Add ::selection to Pseudo-elements 4 - RESOLVED: Outline corners follow border-radius (no additional outline-radius property needed) Geometry Working Draft ---------------------- - RESOLVED: Publish working draft for geometry interfaces z-index and SVG --------------- - RESOLVED: The root SVG element automatically creates a stacking context, as does <foreignObject>. - RESOLVED: SVG elements honor z-index automatically (like flex items), without requiring 'position' Prioritizing image(color) ------------------------- - image() function is undergoing edits for Level 3 randomize() ----------- - RESOLVED: Not pursuing randomness at this time. Animation and calc() of Keywords -------------------------------- - There is generally high interest in animating to/from keyword values, but that means the keywords must be acceptable within calc(), which presents behavioral complications for many keywords - Krit will investigate implementer interest and draft up a preliminary whitelist of keywords that could be included in calc(). - The question of why calc() doesn't have min/max functions was re-answered. ==== FULL MINUTES BELOW ====== Scribe: Bert Line Grid --------- <astearns> http://dev.w3.org/csswg/css-line-grid/#change-log astearns: Mainly I took things out. astearns: I think we should publish with these changes I just linked above. Several: No objection to publishing fantasai: What about the value names for navigation? astearns: I'm happy to discuss the names, but maybe not hold up publication. fantasai: Yes, we renamed to start/end elsewhere. We should do something similar here. RESOLVED: publish WD of line-grid <fantasai> old draft: http://www.w3.org/TR/2014/WD-css-line-grid-1-20140403/#box-snap <fantasai> none of the values are in common except none CSS UI: caret-color ------------------- andreyr: We have been using webkit for the terminal. andreyr: We'd like to control the color of the caret. fantasai: There is interest in coloring the caret. fantasai: There should be something like 'cursor-color'. glazou: And what if you set color on a cursor defined as an image? dbaron: Caret and cursor are not the same andreyr: Yes, I mean the caret. andreyr: Orange is great. TabAtkins: 'caret-color' is fine. andreyr: We have a patch for chromium. hober: In the existing css3-UI thread, hober: Tantek has the notes for this in the planning page, but there hasn't been any edits to any documents hober: Lea raised something. Tantek has some notes for it in UI planning page. hober: So, where would this live? hober: Where would this go? fantasai: css3-ui (which is bit of a mess right now...) <Clilley> how is caret different to cursor: text? Clilley: How is the caret different from the text cursor? TabAtkins: The cursor is the I-beam. TabAtkins: The caret is the editable point in the text. fantasai: It's the one that blinks :-) hober: If you have text in several colors, caret should reflect that as it moves along the text. hober: 'invert' is suboptimal for that. Take the case with compositing. hober: I'm not enthusiastic about implementing 'invert' TabAtkins: 'invert' still fails on gray, anyway. hober: Yes, something with invert only after a threshold... hober: And the case of two authors, author of content and author of content-editable thing, one doesn't know the color of the other. RESOLVED: add 'caret-color' to css3-ui CSS UI: styling selections -------------------------- andreyr: I'd also like to set foreground/background of selected text. glazou: We proposed ::selection for that. fantasai: We all want it, we had it at some point. <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html dbaron: I did half of the required analysis. Most engines have some sort of selection feature. dbaron: I listed five requirements and three solutions. But I didn't do enough testing. dbaron: I think that not all implementations meet the five requirements. dbaron: A useful next step would be to test what implementors do. fantasai: And andreyr wanted to propose equivalent selections for highlighted spelling errors. dbaron: Different DOM selections can maybe be associated with particular styles. TabAtkins: A style without the need to put in a SPAN. hober: A DOM range. Scribe: fantasai glazou: Is this related to what we discussed earlier about selecting non-elements? fantasai: No, it's different, dbaron: This is an extension of ::selection, where you could associate a DOM range with a name, and select (in the same way as ::selection) based on that DOM range dbaron: Want to create it using ranges, then create styles for this. dbaron: The styling would work the same as ::selection, so it's a limited set of things. hober: I love this idea. glazou: Me too. TabAtkins: If we ever explicitly expose browser spell check, it could need to be restricted even further. TabAtkins: That's because of concerns with regard to exposing user dictionaries. dbaron: It would expose user's language and also user's dictionary. Andrey: The problem is that color of underline is hard-coded and we want to change that dbaron: Once we solve for ::selection, we will be most of the way through solving for multiple selection. Though there's a few more issues. hober: I imagined that I wrote an email for a similar thing, but I might not have actually written it... hober: It was a proposal for creating identified DOM ranges and syntax to select it * glazou loves it <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=256773 fantasai: Andrey's immediate problem is changing the color of squiggly underlines; can we do anything about that? <fantasai> ::spelling-error { text-decoration-color: orange; } fantasai: Would that be something that we can do? hober: You shouldn't be able to discover this style by checking. zcorpan: There's spelling errors, and also spelling suggestions. plinss: An extension mechanism should also be able to handle spelling and grammar check, etc. TabAtkins: Things that are security-sensitive need to be built in. TabAtkins: If they're using information not available to the page, you can't build into the page. TabAtkins: That's why I said spell check; if we want customization of it, it has to be built-in. hober: Or you build your own. dbaron: Gecko currently has 9 different types of internal selections. <dbaron> (FWIW, Gecko has 9 different types of custom selection, listed at http://hg.mozilla.org/mozilla-central/file/2255d7d187b2/content/base/public/nsISelectionController.idl#l23 TabAtkins: Wasn't there talk of exposing find to the page? TabAtkins: Ignoring url secondary (we don't know what it is), doesn't seem like any others need to be security- sensitive. fantasai: IME stuff might also expose user dictionaries. fantasai: Aren't there 2 finds? One you're on currently, and others on the page? glazou: Should we resolve to add ::selection back? Who's going to work on it? hober: Which spec should this be in? fantasai: Pseudo-elements Level 4 fantasai: Should probably have L4 just be this and the L3 pseudos. Do fancy extra stuff in L5. dbaron: I'm happy for adding an issue to the spec. Rossen: Stuff is happening in WebApps for selection <Rossen> http://w3c.github.io/editing-explainer/ hober: Editing Task Force. Rossen: Efforts in that direction are toward defining most of the things that we actually want, from what I'm hearing. Rossen: Not sure how much overlap there is. Rossen: Would be good to sync up with them. Rossen: Wouldn't expect us to define ::selection fantasai: We don't define what is selected, but define how the styling works. RESOLVED: Add ::selection to Pseudo-elements 4 glazou: So who is working on this? glazou counts astearns, fantasai, andreyr CSS UI: outline-radius ---------------------- <andreyr> https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-outline-radius andreyr: Mozilla has it implemented, no one else does. dbaron: We agreed at some point that we didn't want this property, just wanted outline to follow border-radius dbaron: The spec says that's what should happen. dbaron: We have a bug on dropping outline-radius and implementing what the spec says, but haven't gotten around to it. krit: The default implementation uses outline of the operating system. krit: It might not be able to allow border-radius. krit: So this would only be for styled outlines, e.g. said it should be solid red. krit: Focus-ring and outlines are basically the same thing. <fantasai> http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines Rossen: We don't have such limitations in Windows, but I can't speak for others... fantasai: CSS3 UI doesn't say anything about border-radius. fantasai: So if we want that behavior, we need to add it to the spec. fantasai: I agree that makes more sense. dbaron: Definitely we discussed this before. I brought up outline-radius, and people said it should just follow border-radius fantasai: So do implementors agree they want to do this? fantasai: Make inner outline radius match border-radius? Rossen: Trying to think if there's fragmented inlines, I'm unsure what should happen in that case... but I do want to match border-radius. krit: Might need to account for http://dev.w3.org/csswg/css-ui/#outline-properties krit: Outline-offset hober: I agree we should do this. If there's a problem, bring it up dbaron: If anyone does this for Gecko, we will have to go through our existing uses of outline-radius, and will find out if there's reasons for wanting something different. krit: Might possibly want rounded outline for square border-radius. hober: Maybe need some text with regard to default outline matching system conventions, which may or may not match border-radius? fantasai: In cases where outline is just outside border, it should match the border. fantasai: For buttons, e.g., focus outline is around just the text sometimes, not the button shape, in that case could say whatever that thing is that is surrounded, it has a border-radius. andreyr: Mozilla had it. I was hoping that others would implement. fantasai: Now you can just say that "your behavior is wrong, here's a patch" fantasai: Mozilla wants to drop outline-radius and just follow border-radius <dbaron> Is outline-radius expansion the same as box-shadow spread expansion? gregwhitworth: Do we have any author feedback on this? ACTION: glazou Ask authors for feedback on this <trackbot> Created ACTION-635 RESOLVED: Outline corners follow border-radius (no additional outline-radius property needed) [lunch break] Geometry Working Draft ---------------------- Scribe: andreyr <krit> http://dev.w3.org/fxtf/geometry/ krit: First up, geometry working draft krit: The main feedback was there shouldn't be interfaces which are described as magic krit: The feedback was to create constructors. krit: Read-only interfaces have constructors now. krit: Any objections? krit: Comments? dbaron: I worry it might be confusing where some properties are writable and some are not dbaron: Did the original proposal have these? krit: The spec has not really changed. krit: We would like to have a working draft. krit: It's intended to have constructor defined in the spec. RESOLVED: Publish working draft for geometry interfaces Stacking context within SVG --------------------------- krit: We would like to have feedback making SVG elements embedded. <TabAtkins> :not(svg|*) > svg { stacking-context: new !important; } <zcorpan> :not(svg|*) > svg|svg { stacking-context: new !important; } Scribe: fantasai [discussion of display property applied to SVG, problem with backwards compatibility due to people applying random other display values and it having no effect] Bert: z-index applies then, don't need to set position: absolute? TabAtkins: Correct. [Discussion is that SVG automatically creates stacking context. Also that SVG allows z-index without requiring position: relative.] [Clilley asks about foreignObject] * fantasai missed the answer Clilley: <foreignObject> should also create a stacking context, and shouldn't intermix with other SVG things RESOLVED: The root SVG element automatically creates a stacking context, as does <foreignObject>. RESOLVED: SVG elements honor z-index automatically (like flex items), without requiring 'position' Rossen: Grid automatically creates a stacking context for grid items. fantasai: I thought that was a pseudo-stacking context. fantasai: For SVG elements, it should be full stacking context. Think grid/flexbox is pseudo-stacking. <fantasai> http://dev.w3.org/csswg/css-flexbox/#painting Rossen: With regards to performance concerns of stacking context in SVG... Rossen: People might use that a lot. It might result in creating too many stacking contexts. krit: We have CSS properties that create a stacking context. Some of them, like transforms, are used very commonly in SVG. krit: So we resolved that properties like transform don't create stacking context unless 3D. Rossen: Should we do the same thing with z-index? ... Rossen: Then we're good. Prioritizing image(color) ------------------------- krit: image() function krit: We had lots of discussion with regard to image() function, syntax thereof, responsive images, etc. TabAtkins: We have that already. fantasai: What's in Images 3 is a superset of that at the moment. We're going to strip it down. randomize() ----------- Tab leads discussion on selecting random values from a list. fantasai: Is that like cycle(), except non-deterministic? [Tab writes on the board] [We discover that the board doesn't erase.] [Tab finds another board] [Which also doesn't erase] [We find some paper, which doesn't erase, but there are multiple sheets] TabAtkins writes: @random foo red, blue random-color(); TabAtkins: This is a random generator. It'll first try to exhaust its list. Then it'll generate from the generator. TabAtkins: If I write el { color: random(foo); } TabAtkins: Do I get a brand new color for every single element? Or a color that changes over time? TabAtkins: Need to specify when the randomness is applied. TabAtkins: Options we consider so far are per-element or per-rule. dauwhe: Why do we want to do this? hober: My use case is that I want to make a really ugly web page. krit: It's for abspos, want randomly-positioned items. Rossen: If the only use case is sprites, one line of JS is a good enough solution. TabAtkins: If we are going to do random, should be something like this, and need to be able to say when randomness is applied. Rossen: What about interoperability testing? TabAtkins: Dunno, we might want to be able to specify seed. florian: Is this stable across page loads? fantasai: I think I'm with Rossen, this should be solved with JS for now. hober: It's already possible to make really ugly webpages, so my use case is already solved without this. plinss: Is this solve-able right now in JS? TabAtkins: Yes. TabAtkins: For per-element, alter .style of the elements; for per-rule, alter the rule in the style sheet. krit: So what's feedback? various: Need more use cases to justify something this complicated for something so simple to do in JS RESOLVED: Not pursuing randomness at this time. plinss: We will pursue it at some random future date. Animation and calc() of Keywords -------------------------------- * krit <shape-radius> closest-side/furthest-side and calc() krit: Got request for shape-radius to have half of farthest-side/ closest-side keyword krit: Would like something like calc(farthest-side/2) krit: And would like to be able to animate that. astearns: Can we do keywords in calc()? TabAtkins: Not yet. But rejecting the white space change request at last F2F makes it easier to do. TabAtkins: These become lengths. fantasai: So does auto keyword for width. fantasai: But the lengths aren't the computed values. TabAtkins: Can't do a transition on it, but could you do a calc on it. fantasai, dbaron: If you can do a calc() on it, then you can do a transition on it. fantasai: We know we want to do this. We've discussed it before. We deferred it from css3-values because it's complicated implementation-wise. fantasai: Right now, you can implement calc() as a tuple of absolute length and percentage. fantasai: If you allow keywords, which have to be maintained as keywords, you need to store calc() as an expression. TabAtkins: So is the implementation work feasible? Because that is what is stopping us. krit: Expanding data structure should be straightforward dbaron: The data structure is the easy part. dbaron: You have to also modify other things to handle, e.g. all things that handle input of 'auto' to handle input of 'auto' with calc() fantasai: Have to consider, e.g. for height of 'auto', have margin collapsing, but non-auto have no margin collapsing, what do you do with calc involving auto? TabAtkins: Might be hard for auto. plinss: Do we want a whitelist or blacklist? Rossen: Probably want a whitelist fantasai: Whitelist isn't per-keyword, it's per keyword-property combination. fantasai: Going to have to modify propdef table again. Though I suspect animate-ability, computed value, and calc()- ability are closely related and could be compressed down. fantasai: So, what action do we give krit? TabAtkins: Make sure implementations are willing to do this. fantasai: And maybe come up with the whitelist. TabAtkins: I want to also see if we can come up with generalizable rules. TabAtkins: Would Firefox be interested in doing this, if we whitelist some keywords? dbaron: Yes, just depends on prioritization. fantasai: There was also min()/max(), which had complications. Are those complications related? dbaron: No, it's different. dbaron: For example, if you have a div that has a 200px-wide image inside it, and has margin-left: 50% dbaron: The div's parent might, depending on other things, have an intrinsic width of 400px depending on other things dbaron: You say this div needs to be 50% + 200px wide, so the total has to be 400px. dbaron: That inversion of logic depends on being able to say that "this element has a length of 200px+50%". dbaron: Once you have a min or a max that has a length on one side and a percentage on the other. dbaron: Then you can't do that. dbaron: This happens most often in table layout, though there are a few other cases. dbaron: I think this was the issue that made me give up on min/max dbaron: The percentage and length thing, you can use a length and a percentage where, essentially, if you have something that is 50% plus 200px, dbaron: If you graph the percentage basis against the result. dbaron: This is some monotonic line. dbaron [draws graph of basis (x) time result (y) line goes from 200px at zero upwards] dbaron: With min/max you can have any continuous and piecewise- linear line [draws a zigzag] dbaron: You might find more than one solution, or none. dbaron: Maybe we need to go back and define table layout and what you do here. dbaron: Or maybe not, just say we don't care... dbaron: I think that was the main issue with min/max <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Oct/0735.html [quick look at css3-values to see if any other issues for discussion, no not really]
Received on Monday, 13 October 2014 20:40:25 UTC