- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 08 Apr 2010 00:15:05 -0700
- To: "www-style@w3.org" <www-style@w3.org>
CSSOM ----- - Discussed integrating CSSOM with other specs: both defining APIs and using consistent terminology. Anne actioned to write a list of inconsistent and missing terms. - Terms "property value" and "component value" suggested to distinguish the different uses of "value" in the specs. (Both can be shortened to "value" where non-ambiguous, preserving current spec text in most places.) - Discussed various ideas for making the CSS Values API more user-friendly - Set up a wiki page to track CSSOM numbered constants, to help us avoid conflicts in the specs. <http://wiki.csswg.org/spec/cssom-constants> - Discussed CSS editor requirements for CSSOM APIs - RESOLVED: Alex and Daniel will start a CSS Editing Task Force for discussing issues relevant to CSS editors and defining their requirements for an object model. Miscellaneous ------------- - Reviewed open issues on CSS3 color so that dbaron can close them. - Some discussion on animating gradients - RESOLVED: Rename 'image-fit' and 'image-position' to 'object-fit' and 'object-position' since SVGWG considers the former ill-suited to their use. - Tab Atkins ran a long discussion on CSS layout, some specific use cases, and the relationships between template layout and tables, and between flexbox and tables. - dbaron proposes calculating available height similar to available width, which would allow percentage heights to work even when the parent has 'auto' height. Since this would be backwards-incompatible, it seems likely this will be used for the 'fill' keyword instead. - RESOLVED: For CSS2.1 Issue 156, use "Once the font family's weights are mapped onto the CSS scale, missing weights are selected as follows:" as the introductory sentence, then add bulleted list from http://lists.w3.org/Archives/Public/www-style/2010Mar/0538.html - env() date values changed to 'local-date', 'local-time', and 'local-date-time' since they are formatted according to the system locale - 'border-clip' property moved from GCPM to css4-backgrounds ~fantasai ====== Full minutes below ====== Present: Tab Atkins David Baron Bert Bos Tantek Çelik Beth Dakin Arron Eicholz Elika Etemad Simon Fraser Sylvain Galineau Daniel Glazman Brad Kemper Håkon Wium Lie Chris Lilley Peter Linss Alex Mogilevsky David Singer Anne van Kesteren Sam Weinig (Apple) Steve Zilles Scribe: TabAtkins CSSOM ===== plinss: First topic this morning is CSSOM. plinss: And impact on other specifications. Integrating CSSOM and other specs --------------------------------- anne: While editting the spec, I noticed a few problems. anne: One is that there's no real data model. anne: The CSSOM is supposed to have a represetnation of what the stylesheet is like. anne: But in the CSS specifications there is no clear mapping from the syntax to the data model behind it. anne: A clear example is the font-family property. anne: I think most impls internally represent them as strings, but that's not stated anywhere. anne: So when you try to design a value API, you have to state it there. fantasai: The font-family syntax I put up said explicitly that Computed Value should be strings, so I agree. anne: We need Specified Value too. Basically, what you get after parsing. anne: Two, there is surprising lack of consistency in the interface names. anne: Like, an interface named CSSStyleRule, that maps to a css ruleset, but that term isn't really defined in the grammar. anne: I'm not sure if we actually want to change the CSS spec, so this makes sense, or what? anne: What I'm asking is if we want to adjust the terminology so that it's consistent between CSS and CSSOM. anne: I'm guessing we can't change the interface, so it would be CSS that changes in a few points. anne: Also, CSS spec refers to a lot of things as just 'values'. anne: But in CSSOM, that needs to be something separate, like a 'value component', because a property can have multiple of them. anne: The CSS spec is kind of loose with those things. howcome: I agree, the spec shoudl change there. ChrisL: The spec is focused on taking text into CSS, not in reverse. The OM spec should define that. fantasai: No, I think the spec is ambiguous in a lot of places. Bert: There is context where we call many things values, and if we introduce multiple terms for these it would be too confusing. glazou: I heard the same thing when I introduced the [multiple types of selector groupings] dbaron: I objected to that at the time because a term was actually being *redefined*. anne: There are other specs where there are multiple concepts being referred to as the same thing. And that's fine, as long as there's a disambiguation at some point. Bert: That disambiguation is present in the <> forms. fantasai: I recommend 'property value' and 'component value', so they both abbreviate as 'value'. howcome: Agreed, we shouldn't be changing tons of terms in the spec, but the disambiguation is needed. ChrisL: Question about CSS color component. Is that used a lot, and is it memory constrained? anne: We can change it if necessary. Specifics are still mutable. <ChrisL> would prefer to see attribute long red; instead of attribute short red; - color bit depth is increasing now anne: I can work around the lack of terminology, or invent my own, but it would be nice if it matched up. fantasai: Do you have a list of terms that you need? anne: No. fantasai: I think the next step is to come up with that list of terms, so we can make sure it's defined somewhere. anne: The grammar uses the term "statement" to refer to @ rules or rulesets, and the CSSOM spec refers to them as "CSSRules". fantasai: I think CSSOM should be changed there. anne: [describes the terminology, and how it can't be changed at this point] <ChrisL> http://en.wikipedia.org/wiki/Deep_Color fantasai: I'm not saying change the interface name, but you can say that "CSSRule" refers to what CSS calls "statement". anne: I tried to do that before, but it didn't make much sense to me. TabAtkins: I'd heard you talking before that it would be useful for specs to define how they should be reserialized, frex how to turn a gradient back into a string? anne: Yeah, something in the future is for the CSS specs to be aware of the CSSOM in their writing. anne: Like when you serialize the margin property, do you do as few values as possible, or write it out fully? ChrisL: I agree with anne that specs should be aware of the CSSOM and write things in respect to that. Bert: I think that the CSSOM should refer to CSS, not the other way around. anne: There are several CSS specs that include interfaces. Bert: Yeah, I think those should be taken out. anne: I think it would be acceptable for me to have an ever-growing OM spec, but that isn't compatible with how the w3c does recs. plinss: I think we agreed that specs going forward would define interfaces. fantasai: We agreed that they would define serialization, not that they would define interfaces plinss: It makes sense for the OM to define interfaces that are common across many specs, but we also shouldn't wait for a monolithic OM to include all the specialized interfaces that a module might have. Bert: it doesn't have to be monolithic, you can publish a separate spec for each module's OM plinss: We can have two conformance classes, if you support the OM you have to support X and Y, if not you just have to support X. arronei: It's just a few lines in the conformance section to add the conformance requirements. fantasai: But we have several specs in CR that don't include an OM section, and I don't want to pull them back to add that. fantasai: We could create new OM specs just for those. dbaron: That's a lot of specs. anne: I'm fine with including that stuff in CSSOM. fantasai: Half the generic stuff isn't even defined yet, and as for me I have *no clue* what to put in for the OM section fantasai: If you can give me a template that I fill in to add OM stuff, I can do it. But until then, I don't want to have to add them to the spec. plinss: The person editing a given module may have no clue what the OM requires, what's a good idea, and so in that sense it may make sense to have a separate OM module for it. anne: For value APIs, new values, we do want interfaces. Bert: But for new keywords or lengths or numbers, those already exist? anne: Yes. anne: And for backgrounds, it might be sufficient already since it's a comma-separated list. anne: For transforms, animations, they all introduce properties with slightly more complex values that need new value interfaces. plinss: Any new @ rule needs an interface. And depending on how granular we get with the API, we may need to extend it for more things. anne: And the Images module, it would need to define new interfaces for the new things in there. plinss: Any conclusions on this? CSSOM Numbered Constants ------------------------ Bert: There was something about numbering, and them having to be unique. Is there any way to avoid this? anne: The pattern that is used all over most APIs is to use numbered constants. anne: For CSSRule we can't change the pattern. For CSSValue I suppose we could, but we haven't discussed it yet. I think it makes sense to keep it with the familiar way. Bert: Does every @ rule need a new number then? anne: If it exposed the same information as another @ rule, it can reuse a number. plinss: @page introduces multiple different @ rules, which would all need a number. anne: We have @page and friends, @font-face, @media, @import, and stylerules, all with different numbers. anne: So far new @ rules probably want a new number. anne: Like all the @margin rules might share a single number. Bert: Numbers need coordination, which I think we should try to avoid if possible. anne: I think we should just try to coordinate. anne: We managed to do it pretty well for DOM Exceptions. Bert: Who do we have to coordinate with. Just here, or do we have to coordinate with SVG? anne: Officially SVG has to coordinate with us, but I've reserved some space for [something SVG-specific]. [talk about different impls stomping on numbers] <fantasai> make the constant point to a UUID? :) ChrisL: We need an easily referencable page where we can refer to this and stop conflicts. [discussion on using a wiki for coordination] anne: There is a way with WebIDL that you can extend an interface. Bert: You can reference a wiki as an informative reference, but not a normative one. anne: Yeah, sure, it can be informative. That's fine. fantasai: So these numbers are all named constants, and people are supposed to use the names? anne: Theoretically. fantasai: Can we have the named constant return something other than a number? anne: No, the type is a short. anne: Same thing is done with, say, Nodes, but that doesn't chang very often. CSS adds new things somewhat more often. plinss: If you're implemeneting something early, like Paged Media in webkit, should prefixed versions use the same final number? anne: No, it says right now that the CSSWG reserves the first 1000 values. plinss: So proprietary versions should use a number above 1000. ChrisL: Will implementations switch from >1000 to <1000 when they get standardized? anne: When they drop the prefix should be fine. plinss: Should we try to reserve blocks for individual browsers? fantasai: Authors should just use the named constants. smfr: Should the named constants be prefixed? anne: Good question. If you don't prefix, there's a chance that code would still work when it moved to standardization. But if we changed anything, then it could break. anne: Ideally we'd iterate fast enough that we don't run into that situation. anne: If people want to write their thoughts to the list, it would be fine. ACTION: anne to set up wiki page to list CSSOM constants for coordination <fantasai> anne, http://wiki.csswg.org/spec/cssom-constants plinss: Did we come up with a decision for how to do OM sections for new modules? anne: I think for specs in WD, it would make sense to have them in the spec. But perhaps we should defer that a little and discuss the value APIs first. CSSOM Values APIs Part I ------------------------ anne: So currently for the value apis you get a CSSStyleDeclaration object, with a long list of attributes that represent CSS properties. anne: And they all return a string. <smfr> http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface anne: The initial idea we had was that instead of a string it would return something special, that would act like a string but would allow extensions. anne: I brought it up on public-script-coord, where ecmascript guys hang out, but they didn't think it was a good idea. anne: [some examples of breakage] anne: Based on that we have a new idea. The CSSStyleDeclaration object would have a new property called values, which would return a CSSStyleVales object. anne: It would act like StyleDeclaration, but when you access a property, it would return a CSSValue object rather than a string. anne: The object would have a cssText attribute that lets you set a string or get a serialization, which is equivalent to the existing API. anne: So then the question is how to define the new value APIs on top of that. anne: I think we want interfaces for the components. anne: So an interface for %, for lengths, for color values anne: And if you have a width property, that supports both lengths and %, the object returned would implement both. <smfr> http://dev.w3.org/csswg/cssom/#the-cssvalue-interface anne: It would have an .px and .em accessor, but also a percentage accessor so you could set and get %. anne: So how far do we want to go? Each and every property, or start out with a limited subset? anne: And do we need a "type" like CSSRule so you can figure out what kind of value was set? anne: Like, ComponentValue would return a type of lengthEm, lengthPx, etc. Would that be a short, like the other types? Or a string that could be interned, which could be more extensible. anne: If we did numbers, then if we start filling in spots, say if we added a new length, it could be very separated from the other lengths. px could be 12, and rem could be 100. plinss: As long as people use names, the numbers wouldn't matter much anyway. plinss: We could also reserve blocks. szilles: So what's the downside on strings? plinss: Performance. anne: If they're interned, it would just be pointer comparisons. plinss: I'm concerned more with author script stuff. Will I be doing a thousand string comparisons, or a thousand short comparisons? smfr: Potentially, we could have them do atomic string comparisons. <fantasai> You might also want to answer things like "is this a length (any kind)" or "is this a percentage" anne: Can we define constants that are strings? Sam Weinig: Nothing theoretically wrong with it. The strings are essentially immutable. anne: How do we, at the object level, distinguish between value components and things that are separated lists of value components. anne: Like, background-position takes two values. anne: So how do we represent that? plinss: I think it should return a backgroundPosition object that has two values. glazou: We could return an array with the components in the order they appear. plinss: Or an object with queryable values, so it's more extensible. anne: Also, do we want a special interface for shorthands? Like margin should we implement a margin property or only margin-left, margin-right, etc? dbaron: Also there are some non-shorthand values that are rather complex, like shadows or border-image. plinss: We could pretend they are shorthands and expose them as such in the object model. anne: But then we're stuck if a property later becomes a shorthand. fantasai: Like we're going to do with whitespace. smfr: I think the hash-table approach would work for shorthands. fantasai: So, for the 'margin' shorthand you'd be able to look up the 'margin-left' value and 'margin-right' value? <dbaron> A bunch of the complex-valued properties are arbitrary-length lists, which are hard to represent as shorthands. glazou: If possible, harmonize things across properties, so "x" is the same for all the values. sam: In that case you wouldn't have named components, but rather numbered components. fantasai: You could have named components that are lists plinss: We've already had things that take a single value and turned them into lists of that value. anne: A simple example would be background-image, which would return a css url, but also have a way of getting a list of css urls. dbaron: I think the single-value thing should only return the single value if there *is* a single value, and otherwise do whatever happens when it is being a wrong type. glazou: Recursively nested values. <dbaron> What's interesting with url() values is often an absolute URL rather than a relative URL relative to the style sheet. glazou: In the case of color, rgb returns a single color value, which also has .r, .g, .b. glazou: etc. glazou: Editors will *massively* use CSSOM if it is easier to use, but not if they have to reparse/rebuild values into a useful form every time. anne: I think you want interfaces for this. CSSOM for Editors ----------------- glazou: Another thing I want to see in the CSSOM, some things just for editors. glazou: Like not just the reserialized text, but the original parsed text. glazou: Like if the @style attribute has something wrong, browsers currently throw it away and it's hard to get at that. glazou: Browsers don't need that, so they can just return null or whatever, but editors are allowed to return the full thing. sam: Is that confusing for authors? anne: If it's not for browsers, do we need it in the spec? glazou: Yes, if you have multiple editors you want interop. smfr: So what if someone wants to write a javascript editor tool in a normal browser? TabAtkins: Like FireBug would love this. smfr: Isn't this what UnknownRule is for? dbaron: UnknownRule was designed by someone who doesn't understand CSS parsing. plinss: We could just tell browsers to *not* throw away these things. sam: For Firebug and Web Inspector we use internal hooks, and don't need the specced thing. arronei: What if I'm a brand new editor for HTML and CSS? This is where having a spec would be great. sam: The issue is that it would slow down browsers. We can either decide that we have it anyway, or not. smfr: We could have a runtime switch controlled by the OM. It's weird, but shrug. * ChrisL bijectively [discussion about editors and browsers throwing things away] glazou: A live editing tool for HTML and CSS right now is impossible because of this limitation. <fantasai> I don't think UnknownRule or UnknownAnything is necessarily the way to go. You should have a unified API insofar as possible. You can have MalformedRule or something for things that can't be parsed... <fantasai> But if it's clearly propertyname : valueIcan'tUnderstand, you should get an api that works the same as for color: blue; <fantasai> and returns the propertyname and the string representation of the value anne: We've had this discussion before. I thinkwe might want some editing features already, and we might want to move those upward. anne: But I think we need a more concrete proposal for how to modify the OM for editors. glazou: concrete example: firebug, dragonfly, etc, from a given element, you can climb up the cascade to find which element triggered the current rule. But it's not standard! glazou: We all use proprietary interfaces to do it. anne: That's something we can definitely standardize. anne: For changing the parsing engine we need more detailed proposals. dbaron: CSS is harder to get right because you've got comments anywhere. glazou: My own impl preserves comments between rules and between declarations. But that's a big bloat for browsers. plinss: in the early days of gecko I made something that preserved all the information, and if it found a comment somewhere odd, it would shove it forward to the next 'normal' point for comments. glazou: That's not perfect, but yeah it works. glazou: I perfectly understand the browser's concerns wrt bloat and footprint. glazou: But adding nothing at all shuts the door to a whole class of live applications on the web that are everywhere these days. glazou: Wikis are everywhere, styles are everywhere, and we still can't edit styles. anne: We can largely edit it. Not every property, but most of them. anne: I think most editors let you edit the text file. ChrisL: Because the OM isn't up to the task yet. howcome: That's what the spec is trying to fix, right? anne: For WYSIWYG you don't need comments, so I see some conflicts. howcome: I think Anne is trying to get this done, and you're being aggressive to him. glazou: I'm not aggressive, I love what you've done, I just want to see more. smfr: You should both be able to edit the text directly, and move to doing sliders and such, and go back. We need that for our editor. plinss: The Web has a legacy of documents being editted by hand, and we can't just throw that away into a non-hand-editable spec as soon as machines touch it. sam: I think that Anne's work doesn't impede any of this. glazou: I think that when OM was first created, editors weren't in anyone's mind. plinss: Gecko actually got built to be an editor. The fact that it turned into a browser is happenstance. plinss: While we were designing that stuff, we saw the convergence of editors and browsers as the web develops. plinss: We eventually realized that the only difference between gecko being a browser and being an editor was a stylesheet. anne: We just need to find what the cost for benefit is. If browsers already preserve comments, we can look into that, but we can't put comments everywhere. anne: And what about whitespace? glazou: What's important is maintaining what was entered. Like for border-radius, you can't just have everything but the -moz-border-radius thrown away just because that's the only one that was recognized. anne: If someone can define what sort of string would be produced, and browsers are okay with the footprint, we'd be okay. fantasai: I think you would start parsing, and get the property name as an ident. plinss: ident, colon, stuff, semicolon. sam: So basically we'd have something more than unknown rules, for unknown declarations too, and a browser mode that would change that. fantasai: For all rules too. alexmog: Let's have a CSS editing requirement TF and come up with a list of requirements for object model, for editors, and other features, so we can figure out what the goals we're trying to achieve are. alexmog: Right now we're designing a partial object model. We can possible change the OM into something that does what we need, or something completely different for editors. alexmog: [he talks to VS people twice a year about this, various requests] RESOLVED: Alex and Daniel will start a CSS Editing TF. anne: I think if you want it to end up in browsers you want it to reconcile with the OM. glazou: Yes. alexmog: I'm not quite convinced if a high-powered editor needs to be built on the object model. alexmog: Like if there are only a small number of companies building major editors, they may not need a full OM in favor of just a more editing-friendly interface. plinss: The same thing happened with HTML. First browsers didn't remember anything about the HTML, and the object model got thrown away as it was parsed. But we gradually kept around more of the model. plinss: So we need to extend this over CSS. plinss: We didn't build the DOM to build an editor, it just happens to also be useful for this. glazou: We know there are some things that we always can't do, like preserving comments everywhere. <bradk> It would be nice if the various developer tools (FireBug, etc.) preserved (and flagged somehow) properties and values that had typos or spelling mistakes, so that they can be edited and fix in-browser. <dbaron> glazou, http://dbaron.org/css/timing-function-graphs CSSOM Values API Part II ------------------------ anne: We need to have the hash-table concept for values that are space-separated, and a list concept for values that are comma separated? anne: for margin, you'd return a hashtable-like interface with each property TabAtkins: We just need to make sure that properties that later turn into shorthands still work by themselves. sam: My suggestion to anne was to take some of the more complex examples of syntax, break it down into concrete proposals, and put that on the list. fantasai: I suggest border image. glazou: Font stuff too. sam: Whatever is *as hard* for anne as possible. fantasai: shadows and the content property. ACTION: anne to produce concrete examples of complex properties and put it on the list smfr: We also need to define if every property has a canonical form. If someone specifies 'ease' in a timing function, do they get 'ease' back or a bezier function? plinss: As much as possible we should return what the author specified. anne: We could have a .keyword value that would return a keyword if the value corresponds to a keyword. glazou: Same with color - if the author says "red", do we do 'red', '#f00', rgba(255,0,0,1), or what? anne: Browsers try to store as little as possible right now. plinss: For a browser, no matter what gets specified it'll be stored as a [r,g,b] or whatnot, and I'd want back what the author actually said sometimes if possible. anne: We might have a bit that says if the color was originally a keyword or whatnot. anne: Currently there are a number of normalization rules for various things. plinss: I'm concerned that some of them go too far. plinss: If you have multiple ways to pull a value back out of the OM, that's fine, but when serialized to text it should be as close to what the author said as possible. We can change "Red" to "red", don't need bit-for-bit, but the spirit should be the same. smfr: One problem I have with gradients is that there's no canonicalization. TabAtkins: Agreed, I need to add that. CSS3 Color Issues ================= <dbaron> http://wiki.csswg.org/spec/css3-color <smfr> editor's draft: http://dev.w3.org/csswg/css3-color/ dbaron: Currently the editors draft addresses most of these issues, but I haven't yet replied to the emails with these comments. dbaron: First is issue 5. dbaron: At first I thought it was someone who didn't understand the spec, but I realize now that there isn't a good description of what rgba means. ChrisL: And I think it should explain how it interacts with opacity (multiplied together). dbaron: A repeated comment we got was the gamma correction section being out of date; I think I've addressed that. ChrisL: Yeah, looks like it. ChrisL: Beth will send me an email that gamma has changed between Leopard and Snow Leopard. dbaron: The wording of the spec in general isn't great about what conformance requirements are, so there are some issues where I think I can improve that relatively easily. dbaron: Frex, it says "here is how to convert hsl to rgb", but it doesn't say you *have* to do that. ChrisL: yeah, that should be normative. ChrisL: Also there was an issue about color spaces and color width and such. All colors should be sRGB, and 0-255. dbaron: Issue 13 dbaron: Someone suggested we remove the statement about clipping values outside the device gamut, which makes me wonder what to replace it with. ChrisL: I don't think they understood the issue. Do we have a conformance requirement to display colors you can't physically display? dbaron: I think that we might not quite want to clip, but might do some special mapping near the edge. ChrisL: [example with differing gamuts] ChrisL: After doing gamut mapping, if I still end up with values outside the displayable colors, it must be clipped. dsinger: Are you modifying what you remember the user asked for, or what you are trying to display? ChrisL: If it's implying that what is specified goes 1-1 with device gamut, that needs to be changed. dbaron: Right, that's why I want to change "clipped" to "clipped or mapped". ChrisL: "clipped or mapped" isn't fine. ChrisL: You need to say "values outside source gamut should be mapped to device gamut, values outside device gamut must be clipped". dbaron: What's the source gamut? ChrisL: The color space you're coming from, sRGB. dbaron: CSS allows values outside of sRGB. ChrisL: Yes, that's fine. If you have a printer that can do blues outside of sRGB, that's fine, CSS lets you express that. ChrisL: But if you're showing on a screen, you can clip to the device's gamut. dbaron: How is the source gamut related to things here? ChrisL: I should have flagged 'device gamut' more. Once you've mapped to the device gamut, *then* you need to clip anything outside of it. Bert: The device clips them for you, right? ChrisL: Typically the driver clips them for you. ChrisL: You need to introduce the term source gamut and device gamut, and use them separately. dbaron: What is the source gamut? ChrisL: In here, sRGB, or any other color space if we allow more later. dbaron: But we allow things outside of sRGB. ChrisL: Right, nobody is talking about clipping source gamut. ChrisL: I can take an action to give a better description here. szilles: [suggestion for communicating this without using the term gamut] ACTION: clilley to rewrite the paragraph in CSS color concerning gamuts and clipping <smfr> http://wiki.csswg.org/spec/css3-color#issue-18 <smfr> http://lists.w3.org/Archives/Public/www-style/2008Sep/0006.html dbaron: It's one of the later messages in the thread. ChrisL: Marbux is a troll. glazou: We still need to respond to trolls. glazou: Talked to AC people, they said it was no problem. glazou: So we have an answer. It's member-only, but it's not a technical issue, only a legal one. It probably deserves a member-only answer. ChrisL: So resolution is no change? szilles: The "be" change should happen, though, right? dbaron: That's editorial, yeah. ChrisL: So we can say "We agree with the editorial comments from the XSL-FO working group". It makes it clear who we're agreeing with. dbaron: There's a note at the bottom of the system colors section that I think is wrong. dbaron: It says the computed value of a system color is the keyword itself. dbaron: First it's weird that a normative requirement is a note, and I think it's wrong anyway. dbaron: So system colors should compute to a color. ChrisL: Sounds good. ChrisL: I've seen Issue 20 come up in hypertext coordination group before, and so we need to say what we mean by 'deprecated'. dbaron: We mean that impls should still implement it, but new content shouldn't use it. ChrisL: Issue 27, we should discuss it. ChrisL: I assume it's because we can get it out this decade? dbaron: It doesn't have real dependencies; it can go to 2.1 just fine. <dbaron> Sounds like people are all happy with depending on CSS 2.1 Animating Gradients Part I -------------------------- plinss: Next topic is animation of gradients. smfr: I think this came up because the Transitions spec said gradients were animatable. smfr: I think this is a mistake because gradients aren't a property, but rather a type of image, and we don't know how to transition images yet. smfr: Also I think this might be something for the public-fx group to input into as well. ChrisL: Could you send a mail to the list about that? ChrisL: [talks about how animating gradients in SVG is easy] TabAtkins: I've got a goal with shepazu to unify some underlying concepts in CSS and SVG, to make those things easier. image-fit and image-position Part I ----------------------------------- plinss: Next topic is image-fit and image-position fantasai: We can't do much, since that was supposed to be for SVG coord. fantasai: But one thing we can talk about is naming. SVG wanted new names for things. fantasai: We might be able to discuss that. <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html <anne> btw, http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/ howcome: image-* isn't perfect for video either fantasai: fit-aspect-ratio says that you're fitting the aspect ratio to the box. fantasai: As far as the most useful information you can stuff into the property, that's fine. ChrisL: So fit-aspect-ratio and fit-position are good? howcome: No. What if you put it on a <p>? fantasai: No aspect ratio, so it doesn't apply howcome: Are there other suggestions? Bert: Without something pointing to images or replaced content, this sounds too general. dbaron: What's the list of values for this? TabAtkins: For aspect ratio: fill, cover, and contain. For position, a bg-position. howcome: Why isn't image good enough for SVG? dbaron: If I hear "aspect-ratio", I expect something that looks like a ratio. fantasai: Maybe aspect-ratio-fit, but then it's weird to combine them into a shorthand. smfr: content-fit, or just fit? Bert: We had that. TabAtkins: We had content-fit, said it was too general, and changed it to image-fit. <smfr> http://dev.w3.org/csswg/css3-page/#img-fit TabAtkins: This specifically says "replaced elements", which isn't great for SVG. fantasai: When SVG imports it, they can tweak applicability wording for their own purposes. fantasai: In CSS, all values have no effect on non-replaced content. Bert: content-* has another advantage, in that it refers back to the content property, which can produce a replaced element. * fantasai thinks that nobody will find 'fit-content' when they're looking for it if it has neither aspect-ratio nor image in its name <Bert> 'content-fit' not 'fit-content' [naming discussions] <bradk> 'scale-how' and 'position-how' <Bert> (I still prefer 'image-fit', though) <fantasai> 'aspect-ratio-fit' <fantasai> 'fit-aspect-ratio' <fantasai> 'content-fit' <fantasai> 'fit-content' <fantasai> 'fit-scaling' <fantasai> 'scaling-fit' <dsinger> fitting? <dsinger> 'replaced-element-fit-behavior'? <bradk> fitting:have(1) <fantasai> q+ for motion to switch topics until Molly can join the discussion <br type=lunch> <sylvaing> image-spread <mollydotcom> Hi all - guessing you're off for lunch? <TabAtkins> just getting back, actually <mjs> did you guys solve all problems with CSS yet? <anne> we added some problems Animating Gradients Part II --------------------------- [continuing discussion about combining animations and gradients] [specifically, maybe attaching animations to transitions, rather than states?] [dean talking about animations with implicit start and end, like transitions do] [if, say, you animate left when you transition a color, what's the final value of left?] <Bert> (If 'transition-properties' has a value foo, then foo animates, even if the start and end values are the same.) [discussion about new selectors to address the hover/unhover animations] [something more analogous to mouseenter/mouseleave, rather than mouseover like :hover is] [or something that explicitly captures a state transition, like :transition(:hover,:not(:hover))] [combinatorial number of state transitions] [event-based CSS property] [back to keyframes for transitions?] <anne> you could have something like :leave(:hover) or :leave(.test) for when something stops applying... <anne> but keyframes for transitions is prolly an easier solution image-fit and image-position Part II ------------------------------------ plinss: Back to naming of image-fit and image-position, sincy mollydotcom is here. <glazou> mollydotcom, we need your expertise finding names... <mollydotcom> I'm here to talk about that smfr: dsinger had a suggestion that he put into irc earlier smfr: viewing-scale : letterbox | crop | fill; viewing-position : ... <mollydotcom> do you want me to call in or shall I just type? Both hurt, typing less so as my throat is so swollen. <glazou> mollydotcom: see conf call data just above <fantasai> how about we call in, and you type? <fantasai> that way you can hear everything <mollydotcom> ok, I'll call in and say hi and then type <mollydotcom> thanks <fantasai> :) +Molly_Holzschlag <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html mollydotcom: Elika has caught me up a little bit on the issue. mollydotcom: We've been talking about this for a long time. mollydotcom: If someone can pinpoint the terminology that we're struggling with, I can help out. fantasai: We got a message from SVGWG, prompting the discussion. mollydotcom: Main concern with image-fit and content-fit is that we're really not talking about images or content. mollydotcom: It *may* be an image, but it's not traditionally what we call 'content'. mollydotcom: I suggest, for semantic rationale, 'object-fit'. howcome: Steve suggested that over lunch as well. I think it covers the things we're talking about here. mollydotcom: Right, whether it's a video or some SVG or an image or an applet, we can call all those 'object'. <mjs> does 'object-fit' really add any meaning to 'fit'? <mjs> pretty much anything can be arguably an 'object' mollydotcom: I have a problem from an educational perspective with using 'image'. mollydotcom: I think 'object' does add meaning to 'fit'. mollydotcom: I don't think it's true that *anything* can be an object. In the markup world, that always refers to a replaced element or similar. fantasai: Agreed. <mjs> in HTML there is specifically the <object> element, and people would think the property is referring to that smfr: That could also bring up the reference to <object>, which would suggest an exclusion of <video> and similar. mollydotcom: Yeah, that's possible confusion. fantasai: I don't think anyone thinks of a paragraph as an object <bradk> object has another meaning in JavaScript too. <mjs> as a browser implementor, I certainly think of a paragraph as an object <mjs> HTMLParagraphElement to be specific < TabAtkins>As an author, do you think of it that way? <mjs> no idea if authors think of it that way; I would imagine authors would do a lot of scripting would think of every element as an object mollydotcom: To designers, 'image-fit' would say to them that we can't put a java applet in there. mollydotcom: They come at us from a different perspective. <mjs> if the intent is to capture all replaced elements, then maybe it should be replaced-fit smfr: What's the objection to content-fit? mollydotcom: Too broad. <bradk> sometimes, when I'm dealing with an element in JS <TabAtkins> maciej, this will be more than just replaced content when SVG imports the property. mollydotcom: And for content authors, content refers to the text content of the document mollydotcom: It seems to me that 'object' is a happier medium. <mjs> TabAtkins, what does SVG intend to apply it to? everything? <fantasai> object-fit: fill | contain | cover <fantasai> object-position: <bg-pos> <fantasai> ? mollydotcom: To me it looks good, and I think I can have that make sense to people mollydotcom: I think it's much harder to convey image-* howcome: I can live with image-* too, but this is better <mjs> I really doubt that "object" adequately distinguishes the set of SVG, CSS and HTML constructs it applies to, from the set of things it doesn't apply to <TabAtkins> maciej, it seems that there *is* no single word that does it. Everything sucks somehow. * anne doesn't really like object either <mjs> TabAtkins, why not just name the property "fit"? does it need a noun? mollydotcom: We were also talking about scaling howcome: I think 'fit' is just too generic. <Bert> (We had 'fit' at one point, and decided to change it.) fantasai: It seems like it could be a shorthand for fit-position and something else. mollydotcom: Let's throw it in front of the SVGWG and see what they have to say. * TabAtkins Next public-fx telcon! mollydotcom: We talked about fit-scaling <bradk> I still prefer 'scaling-fit' <mjs> random proposal: fit-rule: fill | contain | cover, fit as a shorthand for fit-rule and fit-position mollydotcom: Problem with me is the active word of scaling. It's not quite actively scaling. mollydotcom: fit-scale, alone, makes sense to designers and similar people. mollydotcom: if I say you ahve to scale this particular object, that makes more sense to me than saying 'fit-scaling'. mollydotcom: In PS and you want to keep the aspect ratio, you just click "keep aspect ratio" and just change one value, or do it in %s. mollydotcom: And that's a very familiar paradigm. mollydotcom: So I think the word 'scale' is better, but there's vaguery in all of this. mollydotcom: We just have to pick the one that is closest and most understandable to the most people. <fantasai> fit-scale: fill | cover | contain <fantasai> fit-position: <bg-pos> howcome: So should we just list the alternatives? <fantasai> could append <percentage> to fit-scale <bradk> On a fit-scale of 1-10, I'm about a 5 maybe. <fantasai> 100% would replace none <fantasai> fit-scale: fill | cover | contain | <percentage> mollydotcom: just giving one would preserve aspect ratio mollydotcom: fit-scale: 100% would be the image its actual size mollydotcom: fit-scale: 50% scales it down by 1/2 mollydotcom: Could allow 2 values would allow different scaling for different dimensions Scribe: fantasai howcome writes on the board fit-scale fit-position <TabAtkins> howcome: Are these the two proposals we have? --- object-fit object-position --- iage-fit image-position s/iage/image/ --- aspect-ratio-fit fit-position --- scaling-fit fit-position --- and either of last two with 'fit' in the front howcome adds numbers 1. fit-scale / fit-position 2. object-fit / object-position 3. image-fit / image-position 4. aspect-ratio-fit (or fit-aspect-ratio) / fit-position <mollydotcom> 2 from me smfr: prefer 3, but 2 is ok anne: same steve: 1 or 2, not 3 beth: 2, fallback to 3 if it has to sylvain: 3, then 2 alex: 3, then 2 alex: for the same reason I prefer mouse over pointer bert: 2, 3 arron: 2, then 3 fantasai: 1, then 2 dbaron: 2 then 3 tantek: abstain brad: 2 then 1 tab: 1 then 2 chris: 1 then 2 daniel: 2 then 1 peter: 1 then 2 dsinger: 1 then 2 howcome: 2 then 3 dbaron: 2 was first or second choice from everybody fantasai: my one concern with 1 is that if you want to add percentage scaling, it doesn't work with the object-fit name anne points out that if you made a shorthand with these, the shorthand would be called object <mollydotcom> Anne: you do make a good point <mollydotcom> no shorthand should be called object IMO <mollydotcom> is there going to be a real need to do that? smfr: object-fit-scale, object-fit-position smfr: Could combine them and have object-fit-scale and object-fit-position -Molly_Holzschlag <mollydotcom> bye folks! fantasai: smfr's suggestion would address the shorthand and make more sense with percentages TabAtkins: percentages would make a shorthand impossible to parse RESOLVED: use object-fit and object-position for the properties Advanced Layout Modules ----------------------- TabAtkins: So, this is going to be less direct suggestions and more my plan of action in the future about what to do TabAtkins: I'm a Google employee now, and will soon be chrome liaison TabAtkins: I want to take the layout drafts and turn them into something we wnat to implement and use soon TabAtkins: Specifically, Template, Flex, Grid, and a few others maybe TabAtkins: I've been thinking for a while what the underlying abstractions are in the different layout drafts TabAtkins: and also in the different layout modesl I as an author want to do TabAtkins: I would like to combine into one model, but don't think I can quite do that alexmog: Why do you want to do this? TabAtkins: Because I as an author want to use them. Because laying out in CSS sucks alexmog: But you also want one or more browsers to implement TabAtkins: I'd also hope to implement some of this myself TabAtkins: So, the first model that layout things will be built on is table layout TabAtkins: turns out table layout is super useful for layouts I've done, for doing things I didn't expect before I started playing with it TabAtkins: Table layout by itself is good, I like the way it lays out as a grid TabAtkins: the problem is that it restricts your site markup: you need to put in containers and order things so that it lays out TabAtkins: which can be bad for accessibility TabAtkins: Template layout fixes this TabAtkins: Once you look into it, it looks just like magic on top of table layout TabAtkins: So I want to take Template Layout, slightly change it so that it /is/ magic on top of table layout TabAtkins: That would basically entail setting up the properties so set up a table grid out of pseudo eleents TabAtkins: and hopefully discussing how content is flowed into the pseudo elements TabAtkins: hopefully not a significant change in the draft, just conceptual TabAtkins: Another thing to add would be another table layout model that's sane TabAtkins: fixed table layout is sane dbaron: no it's not, it's just nobody uses it so nobody knows how messed up it is alexmog: Even if I don't understand table layout, I can ...? dbaron: Another problem with table layout is that putting large things into small cells often doesn't do what you want dbaron: eg. have one thing wider than viewport dbaron: makes the whole table wider than the viewport TabAtkins: might be an artifact of auto layout right now TabAtkins: Could consider putting out a new table layout model along with the mathching template model TabAtkins: ... dbaron: I removed support for * widths from Gecko because the implementation didn't do much dbaron: And the HTML4 description of * widths said do what browsers do for percentage widths, and the spec for percentage widths said something else alexmog: WPF does use table layout internally, and it implements * widths alexmog: The advantage is that you can put content into any slot into the table Bert: We could add a third algorithm to table-layout property TabAtkins: Building off of table then lets you use auto or fixed layout if that happens to be what you want Bert: That new algorithm would also allow the flex property in that case Brad: Would you bring that into the table display types, too? TabAtkins: Yes, if we add it to table-layout TabAtkins: the only magic in Template would be to create pseudo elements that represent table parts and putting the content in there TabAtkins: I'm going to start working on the drafts for these TabAtkins: Just wanted to give everyone a heads up howcome: You have an implementation as template layout, right? Bert: Yes, 3 impls. One uses same syntax as the draft <TabAtkins> from alexis deveria Bert: The other impls are the ones from Cesar, which uses an older syntax Bert: And there's an impl from Andrew F. which uses another variant syntax Bert: I like the idea howcome: We need something like this, we haven't talked about this for years howcome: what about multicol? TabAtkins: interact the same way as multicol and tables do now alexmog: If you are creating a new kind of a grid, that grid could supercede grid positioning alexmog: you could use that grid to position floats and have them interact with other content Bert: My template draft has that, the grid is defined by the template grid howcome confirms that grid units are defined in various drafts Tantek: what's the general class of use cases that you're going for? TabAtkins: Overall site layout TabAtkins: I want to make sure that either this directly or this plus other stuff is also useful for applications TabAtkins: e.g. replace Gmail's hacky stuff Tantek: Traditionally, grid-based layouts are really useful for application UI <anne> did he say he's going to base this on top of table layout? <anne> ... also, does that mean someone is going to define table layout first? <fantasai> yes <fantasai> no clue, probably not <glazou> http://glazman.org/howcome-cupertino/ <anne> ... seems somewhat important to define those primitives if we are going to build on top of it <anne> ... we always have long discussions on anything table related and without a clear overall picture of how that works it's just going to get worse Tantek: There are a whole class of applications that are doing ridiculous backflips to do UI Tantek: Having a model that solves those use cases could cause a renaissance of web applications TabAtkins: If we can come up with necessary flexibility with grid then building them together would be great .. (?) Tantek: Consider the use cases together, and consider also the implementors alexmog: I'm not against unifying the grid alexmog: but I don't want to have super-complicated interactions across multiple models dbaron: I don't think gmail is that gridlike dbaron: The layouts tend to be more about taking one piece of UI and pushing it against the edge of the space, and then having the rest of the area taken up by the rest of the app dbaron: You have menus and toolbars and sidebars dbaron: In all these cases you're taking the rectangle dbaron: taking up one part of it with a UI element, and then filling the remaining space Tantek: Check out iPhone apps, they have very different UI models howcome: We haven't really been able to exploit our table model because it hasn't been widely implemented howcome looks pointedly at Microsoft ... discussion of WebKit-specific apps and table layout Tantek: Interface builders have lots of interesting ways of laying out UI elements. It makes sense Tantek: snap-to-grid Tantek: pin one object to anther object Tantek: just spend 15 min with interface-builder howcome: Do we consider apps to be the driving force or documents? fantasai: Both. We need to handle both. Tab talks about grids defined by templates and tables and grids defined by content alexmog: The grid I imagine is independent of content. You either place stuff on the gridlines, or snap to them alexmog: The only thing you need to add is size to fit alexmog: perhaps horizontal lines should fit to content alexmog: that switches grid from trivial to complicated Tantek: grids aren't just for UIs either Tantek: Things like baseline-alignment across the page is super-hard to do today Tantek: Grid would presumably solve that TabAtkins: You could set up a grid with those line TabAtkins: and then with some other mechanism tell text to line up to that TabAtkins: You would need separate grids TabAtkins: Whether layout grid + baseline grid is sufficient or we need author-named grids, not sure fantasai thinks we should have named grids Bert: Anne asked on IRC, so do you have to write the table module first if you are going to do this? Anne: What does 'width' mean, what does 'height' mean TabAtkins: Don't have to define that, can just say "do what you do currently" TabAtkins: and build a new sane table model alexmog would like a sane table model Anne: I think we might get a bid of redundancy because only a few people know what the current one covers and what algorithms are defined that we might want to reuse Steve: One requirement that I have is that I be able to describe the area into which things flow separately from the stuff that's flowing into it. Steve: Right now table is entirely wound around the content that's in the table. I don't want that Steve: I want to describe whatever it is without having the content several, supported by Template module smfr: Can you split content up between boxes? TabAtkins: Not currently. No non-rectangular regions and no disconnected regions TabAtkins: would like to add later howcome: Did you see the very first draft from 1997? TabAtkins: No, just seen since Advanced Layout just before it got split into Template <Bert> http://www.w3.org/TR/NOTE-layout <dbaron> As far as defining table layout, http://dbaron.org/css/intrinsic/ and a spec that Markus was working on both define significant pieces of the width calculation <dbaron> I actually think I like the height calculation that IE6 does more than what Gecko does. * fantasai notes that you're probably the only one who understands the implications of that comment :) TabAtkins: I'm not doing box-to-box flow in order to be conservative in level 3 TabAtkins: I think it would still be useful ... printing ... TabAtkins: Printing does bring up other issues. It does matter. non-rectangular layout is difficult if multiple parts have flexible height TabAtkins: Next layout topic TabAtkins: Also related to table layout TabAtkins: In my current use of tables, I often want to set up a ton of things in a grid TabAtkins: but in my markup they're just a linear progression TabAtkins: and I want them to fill through and automatically find the right number of rows TabAtkins: so like normal table layout except without set rows TabAtkins: either by filling the width of a space, or specifying a number of columns howcome: Another idea is columns first TabAtkins: also want to determine direction of cell flow TabAtkins: When you loosen constraints on tables, then tend to become more similar to flexbox TabAtkins: So does anyone theoretically object to these additions to table stuff? * flowing cells into rows without row containers * cell progression direction: changing direction, changing into columns-primary <bradk> block-progression-direction to flow vertically, possibly dbaron: If you switching block-progression direction, you'll also switch the width and height algorithms dbaron: Do you mean cell-progression-direction as a subfeature of the cell flow idea? TabAtkins doesn't know howcome complains about being forced to change markup to do layouts howcome wants a property for determining whether table is column-primary or row-primary dbaron: One thing I liked about table height algorithms in IE6 is that they were much more similar to the width algorithms howcome: You also had an idea about saying which cells you want to start a new row TabAtkins: If you just want to fill to a specific width, then that doesn't work TabAtkins: but for other cases it works TabAtkins: you can use :nth-child to do a specific number of rows fantasai: A problem with fill to a width is that you layou out your table, splitting into say 4 cols fantasai: but then you find a really big cell and find you can only fit 2 cols fantasai: then you have to go back and relayout the whole table fantasai: (which is already a 2-3 pass algorithm) TabAtkins: Ok, maybe that's not a good idea then. Don't like iterative layouts <bradk> container has 'table-flow: rows(4)' to auto flow table-cells vertically into 4 rows, with as many columns as it takes. TabAtkins: you might also want to flow into multiple rows, but not line up column-wise TabAtkins: They flow and wrap around, and each row is height-equalized TabAtkins: can fake it with inline-block, but doesn't handle all cases TabAtkins: Can't justify to exactly fit the row <Bert> (We did have a tabulation proposal some time ago. It was dropped when leaders() could do 80% of that.) ... Tab shows an example layout alexmog: That's a multi-line flexbox TabAtkins: Almost TabAtkins: box-pack-justify and a flexbox automatically sets all margins to be equivalent TabAtkins: but if you want finer control voer that, you can't express it in those terms TabAtkins: you can't set flex on margins TabAtkins: I think that's only place where flexbox is lacking.. it lays out from the container's perspective but not the children's alexmog: that's the point alexmog: Everywhere else in CSS every element has its own opinion on how it wants to be laid out alexmog: Flexbox allows introducing simple or different layout algorithms because it doesn't interfere with anything else in the system * scribe missed something in the middle there alexmog: The layout is totally governed by the container alexmog: that's why it's a clean, easy-to-implement, easy-to-use spec alexmog: If you let it allows margin collapsing and everything else that happens in CSS, then you create a monster TabAtkins: I would like to dive down and try to design with flexbox, and then bring back anything I find that's insufficient TabAtkins: But I'm willing to put that off and do experimentation dbaron: I think box-pack is pretty rarely used in xul dbaron: What's used instead is having more nested boxes TabAtkins: I do something imilar to flexbox using table layout TabAtkins: For a horizontal nav, I'll use auto or fixed table layout on a <ul> TabAtkins: to either space out the links, or the space between the links TabAtkins: in the first case, the white space between them changes, but their centers are spaced evenly TabAtkins: auto layout almost equalizes the spaces in between Steve: You might want to wrap borders around that white space fantasai: You might want to flex the borders, or you might want to flex the padding TabAtkins: I handle that by either styling the <li> or the <a> inside it Steve: There's another piece of this. If had a set of inline-blocks and turned justification on Steve: The only place it could put space would be in between the inline-blocks Steve: The catch is, you really want some space on the ends to make it look right * fantasai likes her display: tab spec, it solves all these problems <fantasai> http://fantasai.inkedblade.net/style/specs/tabs/ Steve: I'm asking you to think about it as justification Steve: There may be other places you'd like justification fantasai describes a catalog use case that should also be solved by this mechanism TabAtkins: One thing I want to do that I don't have much experience with is what web apps need TabAtkins: Because I'm experienced with web sites, but not web apps <Bert> (There are also Media Queries to deal with different numbers of columns.) Tab shows an example of a site he designed TabAtkins: Here's a bunch of questions. TabAtkins: I'm flowing this into three rows TabAtkins: Right now I can only do with inline-blocks, but that means I can't equalize their heights Steve: What's the difference between flexbox and flowing tables? TabAtkins: Not having a grid in both directions Steve: If I had something I could do this flowing in, having properties that could turn it into the grid... Steve: I guess what I'm trying to say is that I see less similarity to tables for flowing tables than to flexbox Steve: I would expect the flowing cells more in the flexbox world Steve: with additional constraints TabAtkins: That's why I said there seems to be a point where tables and flexbox come to gether TabAtkins: As you add more constraints to flexbox and reduce constraints in tables they get more similar TabAtkins: We could maybe add more possible constraints to flexbox, and have it look more like a table TabAtkins: instead of going from tables towards flexbox Bert: Question about your grid of questions Bert: I would bet that most people fill top-to-bottom, whereas you fill horizontally first Tab explains this is because that was the only way he could hack it up into a grid using existing features <anne> btw, live style sheet editing: http://annevankesteren.nl/test/contenteditable-style.htm Tab explains also why multicol + snap-to-grid wouldn't work: a large item would throw off the alignment Steve: I have a similar use case of parallel translations howcome: That's another good use case for column-major instead of row-major * scribe missed alex's comment TabAtkins: You'd run into the iterative layout problem fantasai pointed out howcome: Have you looked at line-stacking-strategy? <howcome> http://www.w3.org/TR/css3-linebox/#LineStacking TabAtkins: Not recently TabAtkins: One criticism is that it doesn't apply across blocks * sylvaing just heard howcome come up with display:clearance-or-whatever ... TabAtkins: Can you set line-stacking-strategy on body and have it apply to everything? ?: It's never been implemented Steve: InDesign in Japan does that (just not in CSS) howcome: It may not be the solution, but is something you should take into account TabAtkins: I think there's an interesting intersection of table, multicol, flexbox, etc howcome: I think it's great. Come with your youthful energy and work on this. Steve: Something to be said for people solving problems by not being aware they're unsolveable <br enthusiam="yay!" ... > * sylvaing was sadly not informed about the hakon tweetup in time or he would have brought stack of free MSIE EU documentation for the grateful crowd * anne still wants his IE t-shirt dbaron's Auto-Percentage Heights Proposal ----------------------------------------- dbaron: So the way widths work, you have some container dbaron: Then you have something inside that has margin border padding, then something inside that dbaron: You have computation going in from the edge determining the available width, and then when you hit a percentage you take a percentage of that. dbaron: What we've said in the past is that percentage heights are just auto if the container is auto dbaron: But people want percentage heights to just work dbaron: There are several places where this would be more useful dbaron: One is multicol dbaron: You usually want to scroll horizontally off the screen instead of vertically dbaron: My idea is that, as we're doing layout, we keep an idea of what the available width is dbaron: You start with the width of the viewport, subtract out borderpadding, and just keep subtracting in, possibly replacing with a fixed width dbaron: If we did this for height as well, percentages could be useful dbaron: It's not perfect, but it gives you a default in cases where you need a good default alexmog: another use case is block progression direction changes dbaron: And there might be some use cases for doing this with flexbox <TabAtkins> also text direction changes (vertical text vs horiz text) dbaron: I'm not sure what we're doing with this, but I might try adding it under a vendor prefix in Mozilla. TabAtkins: Would it be possible to implement this as how actual percentages work? dbaron: Probably too late TabAtkins: as a different unit or something? dbaron: maybe dbaron: We could use this for height: fill dbaron: and maybe even height: content-fit dbaron: This would only get you the effect of 100% TabAtkins: you could expose fill through calc() and then you can get precentages that way dbaron: A good use case would be max-height: fill dbaron: for columns dbaron: So you fill the screen, and then start growing out TabAtkins: max-height: 100vh would also solve that case, right? dbaron: Assuming your columns are not in something overflow: scroll people seem to like this for height: fill CSS2.1 Issues ------------- Topic: jd's followup to issue-156 <plinss_> http://lists.w3.org/Archives/Public/www-style/2010Mar/0538.html discussion about the proposal fantasai: "Once the font family's weights are mapped onto the CSS scale, missing weights are selected as follows:" <fantasai> use that to replace the introductory sentence, then add jd's bulletted list RESOLUTION: jdaggett + fantasai proposal above accepted http://lists.w3.org/Archives/Public/www-style/2010Mar/0551.html fantasai: Issue 107 - anonymous table boxes proposal is done, bzbarsky has approved this proposal, and it's ready for wg discussion fantasai: please review so we can discuss it later <fantasai> the wrapping on that sucks <fantasai> I will resend from a real email client when I get home GCPM ---- <howcome> http://dev.w3.org/csswg/css3-gcpm/#setting-named-strings-the-string-set-pro howcome: I'd like to publish another a WD howcome: wrt env() function howcome: There was a question of how to get the date and time in the locale of the user howcome: There seems to be a widely-available strftime function dbaron: There's also JavaScript functions that have this functionality dbaron: I'm not sure if it's exactly compatible * fantasai hopes it is, that would be annoying otherwise <dbaron> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Date/toLocaleFormat is a Gecko extension, not part of ECMA glazou: fwiw, toLocalString uses the language of the browser, not the language of the system dbaron disagrees Tantek and Steve want to format date and time howcome tries to explain that it's not the point of the feature dbaron: Some strftime things are local-sensitive and some are not Tantek: Your only choice in howcome's draft is to use the locale-specific version * dbaron thinks "2010年03月31日 16時16分40秒" is a perfectly readable date format! Tantek: I prefer if the env() would return in ISO values Steve: I would too, but i"m not sure it's as useful Tantek: with hyphens howcome: So 2010-03-30 bradk: Wasn't the point to do what the browser does now, but be able to style it further? Steve: I don't mind publishing as long as this is marked as an issue Tantek: You should start with something universal and expand from there bradk: I don't think it's bad. There's a reason why browsers print the locale-specific version. It's not our job to educate the world on universal time formats fantasai: You could call it localtime so that you can add other things later howcome: So local-time and local-date howcome: what if I want both? Tantek: local-date-time <tantek> my personal preference would be for ordinal-date (YYYY-DDD) http://en.wikipedia.org/wiki/ISO_8601#Ordinal_dates <tantek> and on that note - I have to depart. thanks everyone! howcome: Simon proposed to say that border-clip* should go into borders and backgrounds fantasai: We agreed to add this for CSS4 Backgrounds and Borders discussion of where these features belong fantasai volunteers to pull this into css4-backgrounds ACTION: fantasai put border-clip into css4-backgrounds howcome: Can we agree in principle in publishing GCPM as WD? no objections TabAtkins suggests removing repeat Tab: I suggested it originally, and I think it isn't needed TabAtkins: Also, percentages should refer to the height for vertical borders <smfr> i also think that hyphenation should move Peter: ok, I think we're done Meeting closed.
Received on Thursday, 8 April 2010 07:15:41 UTC