- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 30 May 2013 17:56:38 -0400
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed shortname renaming plan with plh
- RESOLVED: Publish a new WD of css-masking
- RESOLVED: Minimal expectation is that animations are ignored in
non-interactive media, but implementations are allowed
snapshot them somehow instead
- RESOLVED: 'not', 'only', 'and', 'or' are invalid media types
- RESOLVED: background images are positioned to the scrollable area for
background-attachment:local
- Deferred issue on defining exact color of 3D border styles to L4
- Wrt repetition in media queries, belongs to set of problems to
solve with macros.
- RESOLVED: Allow at-rules inside declaration blocks per
http://lists.w3.org/Archives/Public/www-style/2013Apr/0506.html
- Discussed a few other syntax issues; deferred to F2F
- dbaron requests comments on outline properties:
http://lists.w3.org/Archives/Public/www-style/2013May/0668.html
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Brad Kemper
Philippe Le Hégaret
Alexis Menard
Edward O'Connor
Anton Prowse
Matt Rakow
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Nick Van den Bleeken
Steve Zilles
Agenda: http://lists.w3.org/Archives/Public/www-style/2013May/0710.html
Regrets: Bert, jerenkrantz, sylvaing
Scribe: Anton
Adminstrative
-------------
glazou: extra items?
krit: new WD css-masking?
glazou: ??
plh: Renaming of css-variables? What's the story? Is the expectation
to rename everything in the draft?
glazou: it's dash-1 because it's the first level of the module
glazou: the number doesn't indicate a "level of CSS". It's the level
of a spec.
fantasai: We want to switch from naming using level of CSS, to a system
using "level of module".
fantasai: css3-flexbox should have been css1-flexbox
dbaron: transforms has renamed to CSS Transforms Level 1
dbaron: just the shortname doesn't match yet
<dbaron> fonts should be level 3 because there were font properties in
levels 1 and 2
<dbaron> transforms being level 3 is a mistake
fantasai: we decided to move the number to /after/ the module name, to
avoid readers' confusion about whether it's the level of CSS
that's indicated or the level of the module
fantasai: We set up dev.w3.org first, to test it out
fantasai: probably at some point we'll hand over a rewrite config to
the webmasters for /TR shortnames
fantasai: We will shift the dated URLs as we go along.
CSS Masking
-----------
<darktears> Zakim: ??P82 is me
<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
krit: Would like to publish updated WD
TabAtkins: I'm fine with that.
fantasai: I'd like issue of "having a shorthand to turn everything off"
to be noted in the spec, but I'm otherwise fine
fantasai: in order to turn of masking, you currently need to know all
three systems of masking. (The shorthand 'mask' can only be
used to turn of one set of things.)
fantasai: I'd like to investigate the idea of having a more general
simple switch
fantasai: I'd like to have mask:none turn off all of the masking
everywhere, so that it's easy to turn off masking no matter
how many different masking features we add to the spec.
fantasai: I think that was one of my comments that I sent to the list.
fantasai: I'd like to have a note about the issue in the spec
RESOLVED: Publish a new WD of css-masking
Animations and non-interactive media
------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013May/thread.html#msg650
dbaron: Spec doesn't say what should happen to animations when they print
dbaron: 1) Consensus towards: when printing, pretend the animation
wasn't there
dbaron: but there were some concerns about that
dbaron: 2) Some people wanted an option for "print exactly what I see
on my screen right now"
dbaron: and then there was some third options.
dbaron: I just committed a change to Gecko, for ignoring animations
when printing
TabAtkins: I understand the comments about wanting "screen capture",
but in the general case we should ignore the animations.
It'll work for most cases. Might be bad on certain
badly-designed pages. Not sure
TabAtkins: Question on mailing list about paused animations is interesting.
krit: Cannot sync animations. Not easy to determine what to print
TabAtkins: If author can control a global pause, problem goes away
krit: But there is no global pause
<Tab and krit discuss>
* molly reminds folks that play/pause for motion is an issue in WCAG.
Also, if no printed animations, we need a note for content creators
to ensure any important information still makes it to the page.
<tantek> There may are also a11y guidelines/impacts on animations, being
able to pause, slow or rewind them. There may be some WAI
guidelines on printing animations - probably worth checking.
<tantek> Molly beat me to it :)
krit: Some animations are really hard to time, if you don't have a
global timing function (Which we currently don't).
cabanier: it's reasonable that animations that are in not started but
have fill-mode have their first frame honored
cabanier: this is for animations that have fill-mode: backwards
cabanier: should be easy to implement
glazou: Ignoring the animation makes more sense. The other options are
too hard at the moment.
Rossen: the way we print animated gifs or video, you would actually
print the current frame or whatever
Rossen: I'm not saying it's a precedent we have to follow, but there is
relevant situation there.
glazou: Could this be controlled from CSS? Eg a property about how
animations should print
TabAtkins: User print stylesheet, turn off animations?
dbaron: If there's a right value for the static case, then authors will
want to put the value in for UAs which don't support animations
* fantasai agrees we should use the fallback values
TabAtkins: Is there an implementation issue with snapshotting the animation
at "some point close" to the time the button was pressed?
krit: Can depend on the implementation itself, communication between UI
and engine
<cabanier> who wants that?
glazou: The print button in the chrome, or the print button in the dialog
TabAtkins: The last one.
dbaron: We could do that if we did more work, to have printing CSS code
know how to copy an animation timeline from elsewhere
TabAtkins: I thought the printing code just snapshotted the page
um, no.
TabAtkins: Hmm perhaps this is more complicated than I first thought.
glazou: Most reasonable option is to ignore anims. Could we say that
we /may/ change it in future?
dbaron: Sounds good to me
dbaron: we might even say that implementations are allowed to do something
else if they want to do something more snapshotty
krit: and future specs can say more about how to do that.
glazou: So minimal expectation is that animations are allowed to be
ignored, and implementations are allowed to do better if they
want and we might spec how to do that in future
<dbaron> maybe s/do better/snapshot in some way/ ?
Correction: Minimal expectation is that animations for non-interactive
media are ignored, but implementations are allowed to not
ignore them and we might spec how to do that in future
<cabanier> so a page with animations will print differently in the future?
fantasai: We don't want to imply that snapshotting is necessarily better.
TabAtkins: Snapshotting takes more work than ignoring, it wasn't a question
of what's better or not.
<Rossen> http://www.paulrhayes.com/experiments/clock/#clock
TabAtkins: I'd like to print the frame that's there when you print, in
that example
glazou: No
glazou: In print media, the animation might be there, and there might
not even be a screen to "see" the anim
RESOLVED: Minimal expectation is that animations for non-interactive
media are ignored, but implementations are allowed to not
ignore them and we might spec how to do that in future
MediaQueries: Parsing Media Types
---------------------------------
TOPIC: 'not', 'only' and 'and' as Media types
<glazou> http://lists.w3.org/Archives/Public/www-style/2012May/0794.html
<glazou> http://lists.w3.org/Archives/Public/www-style/2012May/0955.html
<glazou> http://lists.w3.org/Archives/Public/www-style/2013May/0658.html
SimonSapin: I'm in favour of blacklisting these words as media types
TabAtkins: I'd prefer to whitelist the types we have, and never let new
ones be added
TabAtkins: Media types were a horrible mistake
TabAtkins: The only type which makes sense these days is print, which
could have been a media query
<glazou> +1
dbaron: The media types capture a set of binary characteristics.
(paginated? Really small?). Media queries are better at handling
such binary characteristics
TabAtkins: Agree.
dbaron: We actually agreed on a plan to add such characteristics to
media queries. Florian had an action?
dbaron: I agree with TabAtkins that the plan should be to not add anything
in the future
dbaron: But it's a more limited change to just ban the specific few words
<tantek> agreed. media types were unfortunately dated.
dbaron: Anyone recall the error handling rules?
??: Unknown media types evaluate to false
dbaron: "screen, projecton" and misspelt projection? What do we throw away?
glazou: I think we currently keep screen.
dbaron: I would like to include 'or' in the discussion of these few words
<oyvind> "Unknown media types evaluate to false. Effectively, they are
treated identically to known media types that do not match the
media type of the device."
RESOLVED: 'not', 'only', 'and', 'or' are invalid media types
CSS3 Backgrounds
----------------
Topic: background-attachment: local
<glazou> http://lists.w3.org/Archives/Public/www-style/2013May/0516.html
<fantasai explains her post>
fantasai: Proposal is to clarify/change the spec to say that the
background positioning area for scrollable elements with
background-attachment:local is the area which scrolls
and not the scroll frame.
smfr: I just posted to the mailing list
smfr: Scrollable area is not well defined
smfr: Eg shadows affecting scrollbars etc
fantasai: That's equally true for body content, btw so it's not specific
to this issue
<fantasai and smfr discuss>
smfr: What about background-origin
fantasai: would pretend the scrollable area has a border with the specified
border size. Best I can come up with.
<dbaron> I didn't catch fantasai's conclusion there
<fantasai> 0 0 would position negatively, effectively, by that amount
smfr disusses background layers and perf and things
dbaron: <apropos of something just mentioned> Can have multiple bg layers,
in any order
fantasai: Why does this affect positioning? We're not changing the
attachment behaviour here, just positioning
smfr: currently bg is not scrolled with content
fantasai: We're not changing anything about that
<dbaron> fantasai, we're complaining about the background-attachment:
local in its entirety
fantasai: It moves when you scroll, that's the definition
TabAtkins: We're just discussing an edge case: canvas
fantasai: feature already exists and is in spec; we're discussion how
you calculate the image positions
fantasai: I'll propose wording which takes care of interaction with
other bg properties
fantasai: That scrollable area is not defined is a general problem.
??: <... status ...>
fantasai: There are still a handful of open issues in the spec, mostly
minor, but still need fixing.
glazou: Are we OK with the proposal?
smfr: I'm OK with it
RESOLVED: background images are positioned to the scrollable area for
background-attachment:local
<dbaron> "do what http://lists.w3.org/Archives/Public/www-style/2013May/0516.html says" :-)
TOPIC: Color of ridge/groove/inset/outset border styles?
<glazou> http://lists.w3.org/Archives/Public/www-style/2013May/0529.html
glazou: We have no definition of how to do these things!!
fantasai: Defer to level 4
glazou: Then please mark it as an issue
smfr: Ties in with 'lighter' and 'darker' colour functions that we've
discussed before.
dbaron: ridge and groove might have web-compat requirement that don't
match what we'd like to do with lighter and darker
* glazou proposed lighter and darker back in 98 and everyone at that
time replied it was impossible to specify :-)
smfr: I think we changed ridge and groove last year, and we haven't had any feedback
<dbaron> FWIW, Gecko's implementation of 3-D border colors is
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSColorUtils.cpp#40
Variables for Media Queries
---------------------------
Topic: DRYing up Media Queries
<glazou> http://lists.w3.org/Archives/Public/www-style/2013May/0638.html
glazou: Wide discussion on mailing list about this
TabAtkins: Boils down to fact that we do want to do something similar
to the suggestion, but not right now.
glazou: I'm using Media Queries a lot for responsive design support in
BlueGriffon
* smfr would like to know what DRYing is
<fantasai> Don't Repeat Yourself
TabAtkins: Something for level 2?
glazou: OK noted
CSS Syntax
----------
SimonSapin: Most is editorial
SimonSapin: Two issues to discuss here
<SimonSapin> [css-syntax] At-rules mixed in any declaration list?
http://lists.w3.org/Archives/Public/www-style/2013Apr/0506.html
<SimonSapin explains the issue>
glazou: Do we have everything ready in the OM for this proposal?
TabAtkins: A few of these rule types will need to sprout child rule
attributes, but that's about it
SimonSapin: Answer: no we don't
SimonSapin: Would like to do change in error handling as soon as possible
<TabAtkins explains why he agrees with that>
glazou: Do we all agree with SimonSapin's proposal?
RESOLVED: Accept SimonSapin's proposal
<dbaron> I'm fine with the proposal -- reasonable to implement -- there's
an off chance it could break something, and if it does, we'll
find out.
SimonSapin: syntax3 already behaves in this way... should be backport
to CSS21 and CSS Style Attribute
TabAtkins: yes
glazou: So this will override CSS21?
<glazou> we have levels, not versions :-D
glazou: Let's discuss in upcoming F2F, because I'd like Bert's input
<SimonSapin> [CSS21][css-syntax] EOF in string and URL tokens
http://lists.w3.org/Archives/Public/www-style/2013May/0664.html
SimonSapin: Next issue
<SimonSapin explains the issue>
glazou: My own parser makes it valid
SimonSapin: So does syntax3
dbaron: If a definition of variable terminates at EOF in the middle of
a string, does the close quote that's implies get included in
the variable value?
<TabAtkins and dbaron discuss>
dbaron: I'm not crazy about this closing thing
<glazou> var-foo: foo("blah
glazou: If EOF happens there, is it still valid?
dbaron: Should it also contain a closing ) ?? Interesting question
glazou: This is a F2F topic!
<SimonSapin> glazou, third issue, if we have time:
[css3-values] Syntax of attribute values for attr()
http://lists.w3.org/Archives/Public/www-style/2013May/0652.html
TabAtkins: I'll be asking for FPWD of syntax at F2F! *Please* be prepared!!
<dbaron> I'm not sure I'm going to be able to review syntax by that deadline.
Outline Properties
------------------
TOPIC: Principles behind the outline properties
<glazou> http://lists.w3.org/Archives/Public/www-style/2013May/0668.html
dbaron: I don't think this needs meeting time right now, but pls read
message and respond!
glazou: This is related to bounding box etc; makes a good F2F topic
Meeting closed.
Received on Thursday, 30 May 2013 21:57:07 UTC