- 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