- 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