- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 10 Aug 2011 16:28:52 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Add logical keywords to gradients
- RESOLVED: Publish next WD with 'to <keyword>' syntax for gradients
- RESOLVED: No change to how repeating gradients are handled
(use repeat-* functions)
- RESOLVED: Publish updated WD of css3-images with these change
- RESOLVED: Publish LCWD of css3-speech, comment period to end September 30th
- Discussed editing CSS3 Values and Units
- RESOLVED: Assign request for block-in-inline anonymous box pseudo
as an issue to the CSS3 Box module.
- Discussion of flow-from syntax and which property it belongs in.
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Kimberly Blessing
Bert Bos
Arron Eicholz
Elika Etemad
Simon Fraser
Brad Kemper
Håkon Wium Lie
Peter Linss
Alex Mogilevsky
Florian Rivoal
Edward O'Connor
Alan Stearns
Daniel Weck
<RRSAgent> logging to http://www.w3.org/2011/08/10-css-irc
Scribe: fantasai
Administrative
--------------
plinss: Any items to add to agenda?
plinss: got Alex's note about regions flow
Gradient Issues
---------------
TabAtkins: Mainly issues we didn't close on at F2F
TabAtkins: First item is repeating gradients, whether they should be
done by repeating syntax in gradient functions, or by
background-repeat magic
TabAtkins: Other issue is gradient keywords, i've now set the keyword
'to' and either a side or corner
TabAtkins: e.g. 'to bottom left'
TabAtkins: Put keywords back and made corners magic
Florian is happy with this too
smfr: I think it's ok, but why not use 'from' and make the 'from'
optional so we have compat with the old syntax?
TabAtkins: Using 'from' rather than 'to' would give the opposite
directionalitiy thing that confused people
smfr: Only some people
TabAtkins: Since we're changing behavior for corner to corner, so ...
fantasai: I think this is also confusing, with 'to left' I'm not sure
whether a fixed-length gradient is attached to the left or
right edge -- I would guess left edge
Florian: Think this is good enough
fantasai: Another question is animating the gradients, given corners
aren't equivalent to angle gradients anymore?
TabAtkins: They're still equivalent
TabAtkins: It's just a different angle computation
bradk: Does the spec take into account that changing the angle changes
if the box size changes?
TabAtkins: yes. More details to in css4-images -- I pushed animations
out of L3
bradk: How is it defined now?
TabAtkins: Right now images aren't animatable at all, rules are pushed to L4
TabAtkins: Since I pushed cross-fade() to L4, you can't do generic
animations for images anyway, so pushed gradient animations
out too
plinss: If you're animating the width and height of a box independently
and using corner-to-corner gradient, you are by definition of
the gradient angle?
plinss: If you're then simultaneously animating angle of gradient.. if
you compute start point and endpoint, might have animation go
retrograde
TabAtkins: Yeah, that should not happen.
TabAtkins: have similar problems in other situations
TabAtkins: At each step you need to recalculate your range
TabAtkins: Different than snapshotting values at the beginning
Florian: You set your course, and your percentage done changes over time
plinss: Back to keywords issue
fantasai: Would like to push to WD and see if we get any comments
bradk: I like what's happening in linear gradient, still trying to give
full review to radial gradients
bradk: Not ready for LC yet
Florian: The default for linear gradients has been downward for a long
time, which is now either 'to bottom' or '180deg'
Florian: Usually default is 0deg or top
TabAtkins: He's suggesting that we flip the default around they colors
start at the bottom and go upward
TabAtkins: I don't have a problem with this, but don't have a particular
reason to change. It's been default for awhile
bradk: Fallback is still reasonable, because we're changing the syntax
fantasai: We're not changing that part of the syntax
fantasai: I think the default should stay. I think from the top makes
the most sense
bradk: Wouldn't changing it mess up prefixed versions?
fantasai: dbaron already said he won't do that
plinss: In general we're not going to not make a good change to a property
because of prefixed versions
plinss: If it doesn't matter much, sure, but in general don't want to
consider prefixed versions
Florian: Since there's no consensus to change, let's leave as-is
smfr: Mark as an issue?
smfr: Do we need direction keywords that are writing-mode-aware?
Florian: And bidi-aware, too
Florian: Should we add that to writing-modes?
fantasai: No, belongs in the appropriate module. writing-modes only
deals with CSS2.1 issues directly
TabAtkins: Could add them. Although the keywords are a bit weird, e.g.
'to start before'.
TabAtkins: Would like to see some examples of this
bradk: Gradient from black to white from top to bottom, and reversed-color
headline at the top
fantasai: Example of sidebar menu items with horizontal gradient that
fades out towards the end edge. Would want that logical as well
Florian: [something about writing modes dependency]
TabAtkins: Don't believe I need any keywords from writing modes
TabAtkins: Could maybe refer to 2.1
<florian> Yes
fantasai: Nothing in 2.1, but if it becomes an issue we could pull out
a glossary from writing-modes and publish it as a WG Note or
something
RESOLVED: Add logical keywords to gradients
RESOLVED: Publish next WD with 'to <keyword>' syntax
TabAtkins: back to repeating gradient issue
bradk: Already made my case. Not keep arguing it
bradk: Someday we'll have background-rotate, and it will just be redundant
some muttering about issue wording
RESOLVED: No change to how repeating gradients are handled
(use repeat-* functions)
RESOLVED: Publish updated WD of css3-images with these changes
CSS Speech LCWD
---------------
<danielweck> I am on a high-latency and generally slow wifi connection
(scrambled VoIP audio),
<danielweck> so I will be dumping IRC text while I speak.
<plinss> voice-family: fantasai
<danielweck> All of the issues that were raised for CSS-SPEECH on the
public mailing list
<danielweck> have now been addressed in the specification.
<danielweck> I would like to renew my thanks to Fantasai for finding problems,
<danielweck> and in helping to design solutions too ;)
<danielweck> The editors' working draft is ready for Last Call publication,
<danielweck> and contains the full list of changes since the last public
Working Draft (April 2011).
<danielweck> http://www.w3.org/TR/css3-speech/
<danielweck> http://dev.w3.org/csswg/css3-speech/
<danielweck> any objections?
TabAtkins: I haven't given it a thorough review, but I know fantasai has,
so I trust that.
smfr: I have no objection, but I'm concerned about making a test suite
TabAtkins: I know someone suggested audio reftests shoudl be possible.
<danielweck> I saw the discussion about tests, but wanted to focus on
fixing the spec first
fantasai: And we can always use human-verifiable tests. Not automatable,
but still testable.
plinss: Any reasons not to publish?
RESOLVED: Publish LCWD of css3-speech
fantasai: How long is the LC period, and which other WGs to contact?
TabAtkins: Accessibility TF
<danielweck> HTML-Speech
<danielweck> Voice Browser (SSML )
fantasai: yes, definitely SSML :)
<danielweck> my previous email
<danielweck> - The "Voice Browser" Working Group [1] published SSML1.1 [2],
so we should definitely ask them to review CSS3-Speech.
<danielweck> - The "HTML Speech" Incubator Group [3] maintains a W3C Note [4]
that explicitly refers to CSS3-Speech effort, so we should
contact them too.
<danielweck> - Given the likelihood of CSS3-Speech being used with/by
assistive technologies, I suggest involving the WAI [5]
folks as well.
<danielweck> [1] http://www.w3.org/Voice/
<danielweck> [2] http://www.w3.org/TR/speech-synthesis11/
<danielweck> [3] http://www.w3.org/2005/Incubator/htmlspeech/
<danielweck> [4] http://www.w3.org/2005/Incubator/htmlspeech/live/NOTE-htmlspeech.html
<danielweck> [5] http://www.w3.org/WAI/
Bert: Can't think of any other groups, but because it's summer maybe we
should add a few weeks since it's August [and many people are on
vacation]
<danielweck> end of september sounds good.
<danielweck> (summer holidays)
<danielweck> (now)
<florian> +1 for end of september
Bert: Yes, end of September is good
RESOLVED: End comment period at end of September
<danielweck> thanks.
CSS3 Values
-----------
plinss: Request to add some editors [specifically, Tab and fantasai]
howcome: What does it need?
fantasai: Organizational overhaul, fix issues that have outstanding edits
not done for past two years, sync with 2.1
TabAtkins: This isn't theoretical, fantasai and I went ahead and did th
majority of the work we'd like to see done
TabAtkins: We created a patch queue that could be applied to show what
we'd like to see out of the draft
fantaai: We didn't change any of the features, just fixed up the definitions
howcome: I believe dbaron and clilley are co-editors as well
howcome: It also affects SVG, not sure it's up to us to just take it
howcome: Very important spec for other modules, don't necessarily think
we can bring it to closure
howcome: Is dbaron on the call?
howcome: You've gone through this?
dbaron: I thought I had an action to do one thing at some point, but I
have no record of it
howcome: You did the definitions that's in there for calc(), right?
dbaron: I might've written some of it
howcome: I'm not trying to block progress here. Trying to avoid that we
see a lot of changes come out that are not ...
howcome: we saw for example the hyphenation things that we had a lot of
unnecessary conflicts as a result of that change
TabAtkins: We're not trying to change any features.
TabAtkins: Any conflicts would be about more basic definitions that should
be nailed down in any case
howcome: You plan to take it to CR?
fantasai: yes
howcome: What if a spec needs other values?
TabAtkins: Can define it themself. And if it's a common value type, push
it to Values Level 4
plinss: Sounds like a reasonable path forward.
plinss: Would like to not keep this in ED forever
howcome: I'm just concerned about making lots of substantial changes
TabAtkins: We think the features are fine, just reorganized a bit and
updated definitions
howcome: I think there's issues with calc()
howcome: Not sure about implementations
TabAtkins: We're in the middle of implementing
dbaron: And IE's implemented it too
howcome: Great. Should check with SVGWG if they're ok with this
TabAtkins: Again, since we're not actually changing any features, shouldn't
be an issue. Although if SVGWG wants to add stuff to the draft,
then good to get that feedback
<dbaron> there are a bunch of calc()-related resolutions in
http://lists.w3.org/Archives/Public/www-style/2010Jan/0468.html
ACTION TabAtkins : Discuss editor change on css3-values at FXTF
<fantasai> Here's the result of applying our patch queue:
http://lists.w3.org/Archives/Public/www-archive/2011Aug/att-0010/Overview.html
fantasai: The only feature change we did was to add dbaron's cycle()
proposal to the draft; there was an open action on that since
Jan 2009
plinss: Not hearing any objections to adding you-guys as co-editors
plinss: Ready to publish WD?
fantasai: dbaron just pointed to some resolutions on calc(), need to make
sure they're folded in
dbaron: I think they have been folded in, but prose could use some work
TabAtkins: So let's look at publishing next week
<fantasai> full patch queue:
http://lists.w3.org/Archives/Public/www-archive/2011Aug/0010.html
<dbaron> http://lists.w3.org/Archives/Public/www-style/2010Sep/0003.html
has resolutions on marking things in values at risk
Anonymous-box Pseudo-element Selector
-------------------------------------
Topic: HTML talking about paragraphs pseudo-element selector?
<dbaron> Also, there was a resolution somewhere on making certain things
at-risk.
TabAtkins: Bug was on HTML for allowing styling of anonymous blocks created
by block-in-inline split
<hober> <div>para1<ul><li>foo</li></ul>para2</div>
TabAtkins: So you could give it padding, margin, etc.
TabAtkins: Guessing what it means is that ::paragraph would match all
anonymous block children of an element
<hober> div ::paragraph matches para1 and para2 above
plinss: Is this something we want to accept? Where would ot go?
TabAtkins: The pseudo-element section of Selectors?
fantasai: There isn't one anymore. Could add it to CSS3 Box.
fantasai: That's what defines where boxes are generated
RESOLVED: Assign this as an issue to the box module
<plinss> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12778
HTMLWG/CSSWG Coordination
-------------------------
TabAtkins: Is this the best way for HTMLWG to send comments to CSSWG?
fantasai: Did they email www-style?
fantasai: They should post a message to www-style, just like everyone else.
plinss: If they want to make sure we get to it, they can CC the internal
list or put it on the agenda so we discuss it on the call
CSS Regions: flow-from
----------------------
plinss: Alex sent an email about content: flow-from() vs flow-from: property
Alex: We discussed what the right property for making something a region
Alex: We decided that we like content: flow-from() more than property
flow-from:
Alex: At the moment it sounded totally syntactical
Alex: Looks like difference is even more
Alex: The 'content' property is part of generated content
Alex: Includes ::before and ::after
Alex: That property is what is supposed to put content in the box, not
change the nature of the box
Alex: It's not whatever layout it was anymore, it's a viewport into
something else
Alex: It's still possible to parse the property and if the only thing it
has is flow-from() then that particular value overrides ::before
and ::after
Alex: and changes layout model
Alex: I feel pity for content property that it gets such a weird definition
<vhardy> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0164.html
<vhardy> response from Elika: http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0165.html
<vhardy> response from Vincent: http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0171.html
plinss: I think having ::before and ::after work in regions is valuables
<stearns> +1 to using before and after in regions
vhardy: We had a long discussion about ::before and ::after, because
we had talked about having these continue-before / continue-after
markers
vhardy: Our proposals are to have different pseudos that have a different
processing model, that are exclusions
vhardy: It's different from ::before and ::after
...
Alex: Generic ::before and ::after is not really helpful
bradk: What about ::marker?
bradk: Isn't that equivalently a problem?
Alex: vhardy said his preference is still content: flow-from(). My
preference is flow-from:
Alex: content property can have fallbacks. If one of those is a flow-from(),
then first we have to visit all the URLs first.
Alex: Unless flow-from() has to be its only value
TabAtkins: You said that a region is not a normal element, like it becomes
a viewport onto this embedded document
TabAtkins: Wouldn't that indicate that the 'display' property is appropriate?
Alex: It would make sense for display-inside to have a region value
TabAtkins: Then that seems like an appropriate way to do this
vhardy: So your suggestion is display-inside: flow-from(..) ?
Alex: ...
Alex: Region has to say that it ignores ::before and ::after
<smfr> am I hearing "display: region"?
TabAtkins: Having a value for display makes more sense to me, clearer that
it has all these other side-effects
Alex: Should we make css3-regions be the pioneer for display-inside?
bradk: What does a new display type gain you?
TabAtkins: The significant switch is that 'display' is very clear that
this is doing something very different
TabAtkins: ... [something about conflict resolution] ...
TabAtkins: If 'display' is the switch, then you won't ever have conflicts,
it's only one type of display or another
bradk: Is it just because of ::marker?
TabAtkins: yes, but also it's changing how you display what's inside of you
Alex: Display property says what it is, and content property says what it has
smfr: If you have display: region; how do you say what model you're using?
TabAtkins: You'd need display-inside
fantasai suggests moving this discussion to www-style
Meeting closed.
Received on Wednesday, 10 August 2011 23:29:35 UTC