- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 28 Nov 2011 13:58:01 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Unless you're correcting the minutes, *Please respond by starting a new thread with an appropriate subject line.* Variables --------- Reviewed Tab's new proposal for CSS Variables. Florian noted this was the first time everyone in the room was arguing over details of a variables proposal and not everyone was arguing against having it. PF-CSS Joint Meeting -------------------- PFWG Discussion notes on CSS accessibility: http://www.w3.org/WAI/PF/wiki/CSS/Spec_Review/Discussion Discussed reordering content and keyboard navigation. Discussed prioritization of reviews. ACTION fantasai update current work page with more granularity by stability rather than priority. Discussed using user stylesheets to work around broken sites, esp. using http://dev.w3.org/csswg/css3-conditional/#at-document Discussed animation prevent/pause controls, and warning about seizures. Discussed adding new Media Queries that could query accessibility-related preferences. Discussed flexibility of new layout models. Discussed width-responsiveness of large data tables. Discussed using MQ and 'rem' to make font-size-responsive designs. Discussed styling of form controls, multi-resolution cursors, multi-col, reading generated content and list markers, and providing fallbacks for icons. ====== Full minutes below ====== http://www.w3.org/2011/10/31-css-irc#T22-07-08 http://krijnhoetmer.nl/irc-logs/css/20111101#l-1936 http://krijnhoetmer.nl/irc-logs/css/20111102 Scribe: Bert Variables --------- Tab: We talked about it in Seattle. I revised things since. Tab: Let's go over it. Tab: Variables were @-rules before. Tab: That has scoping problems, etc. Tab: So new idea is to define data-* properties. Tab: Can be any name after data-. Need to define the syntax exactly. Tab: Later. Tab: They have arbitrary name and arbitrary value. Tab: Attaches these properties to an element. Tab: Follows cascade, inheritance, exactly like every other property. Markus: So always inherited? Tab: Yes, always inherited. Tab: A data- property doens't do anything by itelf. Tab: But you can use them by referring to them. Tab: Example 1: Tab: Sets data-border-color on :root. Tab: Inherits to everything. Tab: An H1 later on has this property. Tab: Can refer to is: background: data(border-color) Tab: Example 2: [...] Tab: This model is easier to understand, at least when you understand cascade and inheritance. :-) Tab: Libraries can declare their own variables. Tab: With this system you just set it on the root, and won't interfere. jdaggett: name collision? Tab: Still possible, but addresses the majority of them. jdaggett: So each of these data-* are in the cascade and visible to any element. dbaron: Yes, all inherited. jdaggett: So if you set then inside a class... Tab: Then nothing outside that class they are not there, that's inheritance. dbaron: Scopes well for a library that deals with a subtree. Tab: Such as widgets. dbaron: There are other kinds of libraries. jdaggett: You say it resolves name collisions, but it simplifes, eliminates global scopes. PeterL: Not eliminated problem, bur reduced. howcome: when do you know a value is invalid? Tab: At computed value time. Tab: Say it resolves to color: foo Tab: At that point it is not a valid value, and the initial value will be used. Not the previous rule. <glazou> so I think this is clearly the cleanest and best CSS-integrated variables proposal since 1998 ; it's easy to understand, easy to edit, fast and easy to deploy from a web site point of view ; love it fantasai: memory usage? Tab: Shane tried and said it was no so bad. [break] <glazou> so no resolution here ? <glazou> Bert: no resolution to publish variables ? <Bert> we continue later. <Bert> first the joint meeting with PF <glazou> thanks Bert PF - CSS joint meeting ---------------------- Janina: We appreciate your time. Janina: We haven't talked to you as often as we should. Been busy with HTML5 and other things. Janina: We have a task to look at other groups' work. Janina: We have been trying to make up for lost time in CSS. Janina: Created a wiki with CSS modukes. Janina: Checked 50-60% so far Janina: Several issues, of diff. types. Janina: Some can be done in e-mail. Janina: Should get started on the overarching issues. Janina: Some might involve others than just CSS and PF. Janina: CSS is important to accessibility. Janina: CSS should be an accessibility success story. Janina: Having looked at the modules, Janina: (can we project them?) Janina: We should start to understand CSS 3. Janina: An overview would be useful. <dbaron> should we mention the snapshot? Janina: Michael will have a list in a second. <MichaelC> -> http://www.w3.org/WAI/PF/wiki/CSS/Spec_Review/Discussion PFWG Discussion notes on CSS accessibility Janina: We're concerned about reordering content. Janina: Not a bad idea, but may negatively impact the reading order, with braille and screen readers, may affect tab order. Janina: May need a solution. Janina: We should be able to influence the reading order. PeterL: Maybe not thinking about the same terms with the same meaning. dbaron: Can you give what you think it means? Cynthia Shelly: Concern is, let's take an example: flexbox Cynthia: taborder still follows source order, but screen order is different. Cynthia: Several places in CSS do that. Cynthia: ARIA and script can help. Cynthia: But is at different level, in HTML. dbaron: Authors who want to use different orders for some reasons, do that intentionally. Cynthia: that breaks it for sighted users. Tab: reordering is very useful for repairing source order. Cynthia: Yes, good use cases, but Cynthia some use cases not thought through, especially sighted keyboard users. Cynthia: (who can't use a mouse) Alex: Semantic order and visual order. Alex: If we believe the semantic order is the right order, then follow that, otherwise follow the visual order. cynthia: Focussable elements inside that, and keeping keyboard and screen in sync. is problematic. Cynthia: May need some things in CSS to change the tab order or flow. Rather in CSS than HTML. JamesCraig: Related properties that we wanted an explanation of: nav-index, nav-right... <fantasai> http://www.w3.org/TR/css3-ui/#nav-index <fantasai> http://www.w3.org/TR/css3-ui/#nav-dir Tab: Editor is Tantek, but not here now. Florian: Semantic order and visual order both are meaningful. One is not right or wrong. Florian: May need to tab throught source order *and* through visual order. Cynthis: Application dependent. let user choose. Tab: Rearranging focussable things... Tab: At least blocks of things rearranged with media queries. Janina: Author must indeed be able to rearrange layout. Janina: But some users may need to consume it differently. markus: A media-query-driven tab-order. Janina: Perhaps. We don't have a slution. cynthia: main requirement is that it is in CSS layer, not HTML. fantasai: Isn't that the nav-index property? Tab: The existing property is not quite right. We have been working on similar things. This is less useful as it can be. Tab: So we can do some work on it. michael: a question on priorities of CSS specs. jdaggett: yes we like to know that too :-) <dbaron> should also note that http://www.w3.org/TR/CSS/ gives an overview of the stable stuff tab: They can easily end up reordered. fantasai: there is no good answer to that. * Ms2ger notes obsolescence notices MichaelC: So we prioritize our own time on the reviews. fantasai: specs that head to LC vs other specs. fantasai: We can break down WD in to 3 categories of stability. fantasai: I have been writing that up in a blog post ACTION fantasai update current work page with more granularity by stability rather than priority. <trackbot> Created ACTION-398 MichaelC: User style sheets: MichaelC: User can override author, but MichaelC: if author uses an inaccessible design, MichaelC: it is not so feasible to override it. Janina: is there some way to make those overrides more accessible. Janina: be more pro-active. Tab: I expect W3C cannot do much; is a UA issue. Tab: Browsers should do it better. Not standardization issue. MichaelC: style sheets keyed off of class etc. So difficult to override. fantasai: We are working on conditional rules. fantasai: Can designate a block for a particular URL or domain. howcome: can even put all those in a single file. howcome: the file may be huge, though. Tab: Accessibility related issues for user style sheets, there can be sites that share those. <dbaron> http://dev.w3.org/csswg/css3-conditional/#at-document howcome: we can disable floats, go black&white, in Opera, e.g. janina: With a little bit of your help we can close that gap better. fantasai: We need more specific ideas of what to do. MichaelC: Animations: MichaelC: user must be able to stop any movement. MichaeC: We didn't see that in marquee or animation. MichaeC: Or need a script interface for that. Tab: For animations, that can be done. Tab: You can set the marquee property to off, too. <fantasai> turning off can be done easily, not pausing Tab: Dean Jackson is working n animations and starting stopping them. Tab: Seems to be addressed. dbaron: What do you want exactly? MichaelC: Give users their own choices. MichaelC: Preventing animations from starting, rather than stopping them. MichaelC: Need one of the two. Simon: What about javascript-driven animations? No css involved there at all. dbaron: Do you want a script interface for the page to stop animations or a script interface for the page to tell the user that they stopped animations? MichaelC: A global stop is useful. Also useful to stop animations at case by case basis. arron: Need to stop/start, or also speed? MichaelC: No guideline for controlling speed, though it would be useful. Simon: Browser doesn't know that javascript is doing an animation. MichaelC: That is for the author to solve, not for CSS. MichaelC: For CSS animations, the browser knows that there is an animation. dbaron: User style sheet is some extent physical model, some extent conceptual model. dbaron: Easy to express in CSS that nothing animates. * {animation: none !important} Tab: Withing CSS animation, we are mostly already addressing this, or will address it soon. Tab: May be an avenue for a new JS interface. Tab: Some UA pref to read. fantasai: Earlier discussion, some years ago, to extent MQ with user prefs. fantasai: A MQ-type thing can address several concerns. Would need a module. fantasai: Need to thing what an author would want to query. fantasai: Maybe a task for PF, to list the things. MichaelC: We can take an action for that. dbaron: privacy concerns as well. fantasai: Let's collect them in one place and have a common interface to them. <MichaelC> PFWG-ACTION-929 [PF takes the action] [Tantek joins] James: nav-index and precedence, and nav-index vs layout order. cynthia: and please a summary of what nav-index is for. tantek: Author may rearrange spatially the elements and therefore needs to change the navigation from the browser default. tantek: Author can change nav-index along with layout. tantek: Both in same style sheet. tantek: nav-index is for sequential navigation. tantek: nav-up, etc. is for directional navigation. tantek: Can do better than the browser default that way. tantek: E.g., mobile phones with four nav keys, or TV remote tantek: Is in addtion to, but not instead of other mechanisms. cynthia: tab order in keyboard interface. And how about flexbox? Tantek: I need not be a tab key, it is abstract. Tantek: CSS would override the mark-up, the same way as it overrides the layout. Tab: tabindex would be expressed in terms of CSS. Tantek: The HTML attribute tabindex would be like the default. Tantek: Would have a UA default style that uses that. Tantek: I know Opera has implemented nav-index, nav-* Tantek: They don't have flexbox. Tantek: So cannot see combination currently. dbaron: navindex may need something else to move chunks around as a whole. dbaron: Not sure this is like z-index. dbaron: But need to think about it. Tantek: nav-index and tabindex have the same problems. Tantek: Putting it in CSS keeps the layout and order in sync. TatneK: But may be able to do better. Tab: [somebody] is working on this. Problem is changing things locally instead of globally. Tab: Tantek, You want to talk to Ryosuke Niwa (rniwa at google) James: We recommend tabindex=0 and tabindex=-1 James: latter says it is not navigable. James: New extensions, since 3 years. James: They are not covered in nav-index. <dbaron> (Also, I'd note that tabindex=0 and tabindex=-1 should, in CSS, be keywords rather than magic numbers.) cynthia: run-time only. Tab: You know it at the time you declare stuff in CSS. MichaelC: Can elements in the middle of animations while users interact with them? Tab: yes, they can. Tab: But you could pause animations while matching :focus or :hover Cynthia: Were would the focus be? Say in the middle of a swipe. dbaron: In general, animations don't add anything that Javascript soesn't do already, just more declarative. dbaron: No new conceptual problems, but declarative gives more control. MichaelC: Author can add features in same declarative way. MichaelC: Critical topic: MichaelC: Seizures can be provoked by animations. MichaelC: Need a warning to authors in the spec. MichaelC: Not usual, but this is an important case. JohnJ: Where do we put that? MichaelC: Some visible location. ACTION sylvain to add warning (with link) about seizures to Animations spec. <trackbot> Created ACTION-399 Tantek: maybe add things to a validator based on that note? James: certain frequencies Tantek: automated tools help with catching more of them. JohnJ: The warning will often be incorrect. James: WCAG has the frquencies. ACTION Jansen to investigate automated tools for detecting seizure-inducing animations/transitions. <trackbot> Created ACTION-400 Tantek: capture suggestions for validators. Tantek: Responsibility on module editros. MichaelC: Great, that is more than I asked for. MichaelC: In some environments layout may be awkward. MQ can obviously help. But are there other ways to address that? MichaelC: MQ is sort of a sledgehammer approach, not all authors will do that. MichaelC: Say a table that automatically adjust narrow width, handle overflow. MichaelC: Could be several kinds of effects. Markus: We recommend MQ currently. fantasai: Multicol handles it automatically. fantasai: flexbox can wrap. fantasai: There are some modules that address it, others that don't and that is a concern of mine as well. dbaron: We want layout systems with some flexibility. But we don't know how to build perfectly flexible systems. dbaron: MQ offers authors the choice. Markus: Some specs, by their nature, need MQ as the way out. Tab: Some layout can handle it automatically, for others it is MQ. fantasai: Should first try automatic. For more extreme cases, or for more optimized methods, go to MQ. James: Maybe some author examples. James: Font-size can be large, can influence column size. James: Use rem e.g., James: Things an author should consider. fantasai: Excellent point, We should adopt better examples. fantasai: And also build in flexibility as much as we can. James: min-width in rem is important. dbaron: In general using em is good to deal with unexpected font-sizes. Markus: One requirement is that text is flexible Markus: If more space is available, could get bigger. <fantasai> calc+vm unit :) MichaelC: Something about tables, not sure what our issue is. James: exposing CSS tables as a table api fantasai: yeah, that is totally wrong dbaron: people who use tables for layout, in a grid-like table, should have a mark-up that is *not* a table. Steve: Firefox exposed CSS tables as table API. Steve: Was some feedback from IT vendors that it should be like that. dbaron: Gecko's accessibility api operates off the rendering tree instead of the content tree, which I've always considered to be a major design flaw. dbaron: I think Gecko's design is wrong to use rendering tree for accessibility api. But that is the way it has always been. Steve: If it's a CSS table, it appears as a table in the API, but it should expose that it as a layout table to the user. cynthia: But if an author used it for a data table... cynthia: I've seen data tables done with DIVs in the past. James: Seems a bug. Rendering should not affect accessibility tree. Steve: Table flattened. Tab: Currently only tables in 2.1, no module for it. Tantek: For data tables with limited flexibility: what if there is not enough width? Steve: Make it a block, and it reflows, doesn't it? Steve: I can give you some examples. Tantek: caltrain.org has a table that breaks on blackberry. Tantek: I'd love to hear some solutions. James: Any wide content will have that problem. James: Part of the issue, as opposed to multicol, is that the columns here have a meaning. Cynthia: related issue, indeed. cynthia: something to think about over a beer... <Stevef> tantek: Responsive Data Tables http://css-tricks.com/9096-responsive-data-tables/ <Stevef> related accessibility article http://www.accessibleculture.org/articles/2011/08/responsive-data-tables-and-screen-reader-accessibility/ MichaelC: Next issue: MichaelC: Can font-size be part of MQ? dbaron: MQ happens before style sheet, so the em is always the users' default font size. dbaron: It is easy to use the user's font size as part of queries, but hard to actually query for it directly dbaron: You can query for exact value or a range. fantasai: You can ask how many ems fit on the screen. dbaron: You can query across units, but hard. dbaron: Many Web pages don't render unless font is 16px, but that is different tissue. fantasai: What is the use case for querying the font size, and not the size of the screen wrt size of font? MichaelC: Can make things relative to a base font size. MichaelC: Authors typically make font smaller. MichaelC: A base font size that authors wouldn't need to scale down. dbaron: that is history. fantasai: Designers indeed lower font-size. No automatic way out of that. fantasai: But rem unit (font size of root element) can soon be used everywhere. fantasai: Author can override it, but user can then scale without breaking the design. James: You can use that in a media query? Check screen vs rem? fantasai: Yes. You cannot find out what the rem is in terms of px, but can find out how many rem per screen. fantasai: You don't have the px value, but you can use the rem and don't need the px. Note: rem and em are equivalent on the root element and in Media Queries RichS: Can MQ dynamically change the style on the page? dbraon: yes, dynamic. If user resizes window, style changes. RichS: Might want to have on mobile some way to add captioning based on environment. RichS: Would that be MQ, or an API? Tab: MQ is preferred, can then still do it from JS as well. <dbaron_> http://dev.w3.org/csswg/cssom-view/#dom-window-matchmedia http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface MichaelC: Last issue on our list: MichaelC: Positioning module. fantasai: We have multiple modules about that. arronei: Discussed a module with abspos and centering, will publish soon. fantasai: We have several related modules. fantasai: We will intergate requirements as appropriate, if you can give them to us. MichaelC: We'll take an action item. fantasai: This is the right time for those. fantasai: as they're mostly in the brainstorming/design/exploring stages <MichaelC> PFWG-ACTION-930 MichaelC: Next issue: multi-col MichaelC: It is very positive for accessibility. MichaelC: Does it only waork in paged media? fantasai: It works also in continuous media, but not so well. MichaelC: Need to fix the height and have it overflow to the right fantasai: that's the only way to really have it work well in scrolling media, but you can also have a paged presentation on a screen. MichaelC: Howcome has a demo for that. howcome: Wikipedia has references in two columns, and the reading order doesn't matter, so columns without fixed height are fine. MichaelC: So work is ongoing. Any action? TabL: working on ways to fix it now, such as paging. fantasai: If you have any suggestion on how to make it work better for continuous media, we'd be happy to consider for L2 MichaelC: control of styling of form controls. dbaron: short answer to that is, we know, and it's a lot of work MichaelC: Because authors too often replace the control with script. janina: Often you find you can fill out a form, but cannot submit... Tab: Too much differnece between devices and UAs. Difficult to specify what you can style. Tab: Would love to do it. Tantek has it on his list. Tantek: If you have specific example, please send them to me. James: We have a spec, ARIA. Tantek: Web authors often make their forms less accessible with certain libraries they use. I want to find out why they use those. Tantek: In some case the libraries themselves can be updated, with ARIA. Tanek: So multiple strategies. Tantek: I can use help, esp. collecting examples James: HTML5 allows some more than before. tantek: WAI-ARIA Implementation in JavaScript UI Libraries (2009) http://www.paciellogroup.com/blog/2009/07/wai-aria-implementation-in-javascript-ui-libraries/ MichaelC: My last one today: MichaelC: Mouse cursor vs resolution. MichaelC: OS often have different variants. Tab: UI module says to size to OS default if there is no intrinsic size. Tab: Works great with SVG image. Tantek: You can use multiple urls for a cursor. Tantek: But not so precise as to which is used. Tantek: Could put in a rule for picking the right size. tantek: What wording can we put in there? MichaelC: We can probably come up with wording together. James: SVG works on some. Didn't scale on windows. dbaron: Tantek's suggestion seems too magical. dbaron: We have proeprties that take images and say to take the first you can handle. dbaron: That is clear, but this complicates it. Tantek: May also define a new cursor format with multiple resolutions. [several: there is such a format] <fantasai> .ico Tab: Image Value spec has default object resolution text. Tab: Handles mutli-resolution images. * ed notes that svg + mediaqueries would also work for selecting different raster- or vectorimages for a particular resolution * ed that is, media-queries inside the svg file James: I will take an action. <fantasai> http://www.w3.org/TR/css3-images/#sizing <dbaron> http://dev.w3.org/csswg/css3-images/#default-sizing <MichaelC> PFWG-ACTION-931 fantasai: [looking at MichaelC 's other issues] fantasai: can use MQ for most. fantasai: resolution variations can be done manually with @media fantasai: high-contrast would be solved the same way once we have user queries Janina: Any other issues? Tab: The generated content one. Steve: Concern was: text generated looks on screen as content. Mixing presentation and content. Steve: It is read aloud. Steve: No alternative text for a bg image on :after. Steve: I have asked some people in CSS WG already. Steve: I have concern about how it is processed in browsers. James: can use attr() James: Other issue with CSS speech. Not want to speak the generated text. James: ARIA required attribute can trigger a background. <fantasai> ... Can use CSS Speech 'speak: none' to hide generated content you don't want spoken James: If it looks like an asterisk on screen, can you make it render as something else in speech? fantasai: Render to another canvas. Our speech model is that you pick up generated content in speech stream but not background images. fantasai: Can speak: none to turn it off. fantasai: Can also use css speech to add aural icons. fantasai: The model we have for somebody to access a doc via speech is not to use the DOM, but to read the audio canvas. James: One of my concerns is that Speech is very focused to books, think DAISY, not so much screen readers. Cynthia: list numbers is an example. Many screen readers do that wrong right now. fantasai: This is defined in the Speech module. fantasai: I will help Tab to add it to CSS3 Lists module as well. fantasai: Expectation is to be able to read those markers. dbaron: Lot of browser bugs, but also misuse of generated content. dbaron: It shouldn't be used for essential things. dbaron: Not entirely happy with how list numbers work. Tab: Things like adding a PDF logo before PDF links. Tab: Is that decorative? It is informative. Tab: It is usefully exposed. fantasai: Use the content property, with both a url and a string. <fantasai> [href$=".pdf"]::after { content: url(PDF.png), "[PDF]"; } Janina: We should deal with favicon better. Janina: The Apache icons for different types of files? Janina: Seems a similar case. Janina: You can extend that in the Apache config, maybe in other systems, too. Tab: That is outside of CSS. fantasai: Browser knows the media type. fantasai: Could present that. fantasai: That is not the favicon. dbaron: Browser doens't have the media type until it fetches it. James: You mean the default index in Apache, Janina? Janina: yes. MichaelC: Need we follow up on generated content later? James: An action for me to check the content property with text fallback. <MichaelC> PFWG-ACTION-932 MichaelC: We're done. Janina: to be continued :-) Multi-col --------- howcome: Longstanding issue. howcome: Didn't get feedback from designers. howcome: Should two spanners collapse margins? howcome: Difference in collapsing, floats continuing in next spanner, and block formatting context. Florian: IE does one, we do another. Alex: Both options a and b make sense, not c. fantasai: They all make sense. howcome: may need to go to LC again. howcome: If Alex is OK, let's do A. [fantasai draw on whiteboard] <tantek> http://instagr.am/p/SZJjj/ fantasai: If spanners span different # of columns, fantasai: you get option a. fantasai: If they have same # of columns, you get different layout. fantasai: c is like in single-column layout. fantasai: Most natural. fantasai: b is like a special kind of BFC, different from others. <dbaron> (Is anyone actually talking about column-spanning elements that span some number of columns other than all? If so, scary.) Alex: If these spanning elements were floats, Alex: would they collapse? Alex: They should behave like floats, not collapse. Florian: It is a corner case. fantasai: Don't think so. fantasai: But floats inside them is. Alan: Article title followed by section title, I don't want things to collapse. fantasai: But if it is a single col, it collapses. Brad: [missed] Alex: I want spanners to be like something else, not something new. Alex: which is like BFC in normal flow? Alex: Make them behave like in normal flow. fantasai: BFC doesn't collapse with its children. howcome: strawpoll? PeterL: Can't decide now. ACTION: fantasai and kimberley to write blog post describing the situation to designers and ask them for expected behavior Variables (cont'd) ------------------ ScribeNick: fantasai TabAtkins: cyclic dependencies - easy to resolve TabAtkins: shows example 4 TabAtkins: We can detect this cyclic dependency easily at computed value time, and we resolve these to all initial value TabAtkins: both variables result in initial value in all places they are used :root { data-one: calc(datatwo) + 20px) data-two: calc(data(one) - 20px) } Bert: Isn't the property evaluated when it iused, ratherathen when it is declared? TabAtkins: They're calculated on the element at computed value time * fantasai is getting confused with all the cycles TabAtkins: Var cycles are resolved at computed value time. Inheritance happens after computing. TabAtkins: There's an example below where something that looks cyclic isn't because of this detail TabAtkins shows example 5 TabAtkins: <one><two><three/></two></one> one { data-foo: 10px; } two { data-bar: calc(data(foo) + 10px; } three { data-foo: calc(data(bar) + 10px); } TabAtkins: two resolves easily from the inherited 10px TabAtkins: three is defined to use bar, but the value it sees is the successfully computed 20px. TabAtkins: Cyclic dependencies only occur when variables on the same element have cycles. Markus: If you accidentally do this, how do you know? TabAtkins: Web Inspector can provide that info to the author. fantasai: You can search for all data-* properties that compute to 'initial' <dbaron> we could in theory even provide a console warning Alan: What if data-foo is a color? TabAtkins: bar won't be invalid except at the point where it's used. plinss ask about resolution TabAtkins: The data variables are treated as a stream of tokens, except for data substitution, until they're used <dbaron> fantasai, it shouldn't compute to initial, since an invalid data property needs to make the property using it (which may not use it as a *whole*) get its initial value <fantasai> dbaron, that resolves itself <fantasai> dbaron, it'll either be the entire value of the property, in which case that property gets initial <fantasai> dbaron, or it won't be valid because it's not the entire value of the property, in which case that property gets initial <fantasai> dbaron, either way you get initial :) <dbaron> fantasai, initial as a keyword is valid within font-family dbaron: "The keywords 'initial' and 'default' are reserved for future use and must also be quoted when used as font names. UAs must not consider these keywords as matching the '<family-name>' type. " http://www.w3.org/TR/CSS21/fonts.html <dbaron> "as" != "in" <dbaron> font-family: initial foo, cursive; is still valid John may have reservations about substituting variables within other data properties howcome: If you wanted a variable that equalled 10% on this element, you couldn't do that. TabAtkins: no TabAtkins: that would require more plumbing to make it work howcome: Don't think it's a req, just want to understand the model. howcome: Do you think there will be lots of invalid values? You go back to initial. TabAtkins: You will usually not run into this problem, because ... TabAtkins: You cannot resolve the data type of a data property at parse time TabAtkins: There are places where a particular token can masquerade as different things depending on the context it's used TabAtkins: If you use 'red' in color, it becomes a color. If you use it in list-style, it's treated as a counter name jdaggett: so you have to do 2 parsing steps TabAtkins: In most cases, no. jdaggett: Your processing model doesn't make sense to me. TabAtkins: I'm pretty sure it works <dbaron> It makes sense to me. jdaggett: Not clear to me when exactly these values are calculated <dbaron> You parse it into a token stream <dbaron> and handle any tokens that are the "data(" function <dbaron> and then save the token stream <dbaron> IMO, anyway jdaggett: What dbaron said makes sense. What Tab says makes no sense... TabAtkins: you can also optimize by storing the parsed (not just tokenized) version for reuse in the same context fantasai: That's an additional optmiziation. Rossen: What if I have data-foo: inherit? <Bert> (So this requires that calc() is defined in Values and Units so that calc() can be used inside calc().) arronei: in this case it would be invalid TabAtkins: ... Rossen: More natural way to me would be to have it on your parent. Rossen: similar way to look at it is as inherit jdaggett: Flip side is you can never make a variable carry 'inherit' jdaggett: The keyword has special meaning Florian: I'd like to point out that this is the first time everyone in the room is arguing over details of a variables proposal and not everyone is arguing against having it TabAtkins explains the transformation from 'data-foo' to 'foo' inside data() discussion about property/value syntax plinss: I strongly feel they should be consistent on both sides, not different when defining vs referencing jdaggett: It looks too much like a property. Should look different. plinss: Prefer parentheses approach data(foo): red; <shans> peter's proposed syntax is to do something like one { data(foo): 10px; } <shans> two { data(bar): calc(data(foo) + 10px); } TabAtkins: Either way, I'm cool with having discussions about syntax of it later, as long as we're cool on the processing model. howcome: Can this mechanism be abused for prefixed properties? fantasai: I think this would be difficult howcome: what if ua's did special things with certain variable names? TabAtkins: That would violate the spec plinss: Make sure you explicitly forbid it TabAtkins: I defined explicitly that these are non-special, can wordsmith later if necessary plinss: Just about out of time. plinss: I like the fact that this model fits the CSS way of doing things plinss: And not creating another weird variables model plinss: I think this is going to be harder to explain to people plinss: People don't really understand the cascade TabAtkins: Most of my example are setting variables on the root, and I plan to add notes "just set it on root, don't think about it anymore" plinss: And don't set it on *. fantasai: I remember getting a proposal for a variables-type thing that, very similar to this, used cascading/inheritance. fantasai: Person was very clear that s/he wanted inheritance behavior of the variables. alexmog: How do you undefine a variable? TabAtkins: Could set it to 'initial' TabAtkins: Alternatively, set it to itself. That'll create an immediate cycle. TabAtkins: Can I publish this? plinss: Think there should be other people to decide for FPWD, but editor's draft should be ok. Markus: It's on dev.w3.org, it's already an editor's draft. TabAtkins: But now I can talk about it, that the CSSWG has an editor's variables draft <dbaron> [Daniel and I are debating another variables issue in the back of the AC meeting room, on the assumption that you were going to end 4 minutes ago] howcome asks for confirmation that this is *the* variables draft Yes plinss: FXTF on Thursday Meeting closed.
Received on Monday, 28 November 2011 21:59:39 UTC