- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 21 Aug 2013 16:22:02 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Status updates:
- Counter Styles LC just received many comments, which will
need to be processed before CR
- Fonts CR transition discussions deferred to next week
- Transitions and Animations waiting on edits
- RESOLVED: Drag-and-drop pseudo-classes as :drop(active|valid|invalid)
- Discussed whether to allow syntax like [rel=next,prev,up] in attribute
selectors. No conclusions yet.
- RESOLVED: Accept work on scroll-snapping properties, initially as a
separate module, potentially folded into another one later.
- RESOLVED: Shift CSS4 Color proposal to ED
- Discussed behavior of 'outline' properties. Two use cases conflict:
focus outlines (original intended use case), and "fake borders".
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
Tantek Çelik (via IRC)
David Baron
Bert Bos
Jason Erenkrantz
Elika Etemad
Simon Fraser
Sylvain Galineau
Rebecca Hauck
Dael Jackson
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Chris Palmer
Anton Prowse
Matt Rakow
Florian Rivoal
Simon Sapin
Dirk Schulze
Leif Arne Storset
Nick Van den Bleeken
<RRSAgent> logging to http://www.w3.org/2013/08/21-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Aug/0388.html
Scribe: antonp
Status Updates
--------------
TabAtkins: Counter Styles to CR: lots of issues have come up this week,
so let's not discuss this yet.
TabAtkins: Loop back next week
plinss: Fonts CR transition will wait for John next week
dbaron: Transitions and Animations are waiting on me to do a bunch of
edits that I haven't had time to do.
smfr: I haven't had time to look through test cases, next step will be
to put together issues based on behaviour in those tests
krit: I'm still working on tests
plinss: Will they be ready for F2F?
krit: unlikely.
dbaron: 50/50 chance of getting my edits done for f2f
plinss: Let's try to get this spec advancing
Selectors 4
-----------
Topic: Drag and Drop
<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2013Aug/0076.html
TabAtkins: Great response to the survey; let's do this kind of thing again!
<krit> TabAtkins++
Results: http://lists.w3.org/Archives/Public/www-style/2013Aug/0265.html
<plinss> https://docs.google.com/spreadsheet/ccc?key=0AmRB4Bq4bNRBdEw4TlU5cGNTNGQ1VHF4ZFFORTFoTkE&usp=sharing
[...] One of the consistent themes: People like the repeated part of
the name come first.
florian: The functional notation is interesting if you plan to extend.
Do you?
TabAtkins: Useful part: combine multiple keywords inside of the functional
notation, gains readability
florian: All the suggestions look reasonable, err towards third.
Bert: I prefer to avoid parenthesis, which makes things look like a
formula / maths
fantasai: we also have the option of doing pseudo-classes with parts
reversed, which gets repeated part of the name to come first
TabAtkins: if you put 'drop' first, it looks like a verb rather than
a noun. This makes it awkward to put it first if you
just dash-separate the words
fantasai: fair enough
plinss: Any strong opinions, or we go to straw poll?
[Discussion of valid and invalid]
plinss: Need to define :drop() by itself, no arguments
fantasai: Yeah, would mean all possible drops
plinss: Do you want invalid + valid?
fantasai: Most people won't care wrt valid/invalid, so simple case would
be using active-drop and drop.
fantasai: Distinguishing valid/invalid is more advanced.
Poll: using the numbering in the e-mail
<florian> everything acceptable, 3rd preferred
<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2013Aug/0265.html
1. :current-drop / :valid-drop / :invalid-drop
2. :active-drop / :valid-drop / :invalid-drop
3. :drop(active) / :drop(valid) / :drop(invalid)
[above is a list of the options]
<TabAtkins> 3
<sgalineau> 3
<fantasai> 2 or 3
<smfr> 2
<florian> 3,(no objection to the rest)
<plinss> 3
<Bert> 1 or 2
<SimonSapin> 2 or 3
<leif> 3 or 2
antonp: 2
<plh> 2
<jerenkrantz> 3
<hober> 2, 1
<dbaron> 2 (or maybe just abstain)
<dbaron> though we should also note that (1) won the poll
<florian> to dbaron, yes but 2 wasn't in the poll, and is more similar
to 1 than to any other option actually in the poll
<leif> oops! I meant to vote for the poll winner as second choice,
so my preference would be 3, with 1 as backup
<SimonSapin> if picking one, s/2 or 3/3/
<TabAtkins> #1 = 2 votes, #2 = 8 votes, #3 = 8 votes
plinss: Is there anyone who can't live with 2 or 3?
<Rossen> 3
plinss: Let's call it 3 then, and move on
RESOLVED: :drop(active|valid|invalid)
<tantek> Happy to give into consensus here on bike shedding those UI
pseudos.
Topic: Comma separated attribute value selectors
http://lists.w3.org/Archives/Public/www-style/2013Aug/0331.html
<SimonSapin> do it
TabAtkins: It's about adding comma-separated values to the attribute
selectors, as syntactic sugar
florian: Is there an issue with the comma as part of an attribute value?
TabAtkins: comma is not part of an ident, if you want it you can use a string
dbaron: I'm concerned about readability
<TabAtkins> [foo=a,b,c] === [foo=a], [foo=b], [foo=c]
Bert: Is it an AND or an OR?
plinss: It's an OR. Couldn't possibly be an AND.
Bert: I think it adds complexity without adding functionality
Bert: Use a preprocessor
* sgalineau what I heard was 'if it's just usability we shouldn't do it'
TabAtkins: Just because you can use a preprocessor, it doesn't mean that
we should. Puts a lot of overhead on
Bert: e.g. Perl is easy to write, but hard to read. It's about readability.
<TabAtkins> https://dvcs.w3.org/hg/csswg/file/bb3efb2a3181/default.css#l171
<TabAtkins> [data-link-type=property, propdesc, descriptor, value, function,
at-rule, selector, maybe]::before { ... }
TabAtkins: In the link is an example
Bert: commas are small, and are easy to miss
Bert: I already have a problem with commas so I put clauses on separate lines
TabAtkins: That's good practice anyway.
Bert: The next thing you'll want to add is regular expressions! Bad direction
TabAtkins: I don't like slippery slope arguments. I'm not planning to add
those.
SimonSapin: Implementation-wise, it doesn't add much complexity if we
already have 'matches'
TabAtkins: It can sort of be the inverse of matches if you need to internally
plinss: How will it serialize?
TabAtkins: <replies>
<sgalineau> straw poll?
(+1 is for commas, -1 is against)
<fantasai> +1
<florian> +1
<Bert> -1
<SimonSapin> +1
<TabAtkins> +1
<smfr> +1
<sgalineau> +1
<jerenkrantz> +1
<dbaron> -1
<hober> +0.75
antonp: abstain
<dbaron> p[class, id]
<sgalineau> dbaron, do you mean [foo=1,bar=2]?
dbaron: why does comma have lower precedence than equals sign?
Attribute selectors can take 'attribute' or can take
'attribute = value'.
<dbaron> p[class=foo, id]
<dbaron> p[class=foo, class=id]
dbaron: the second example I typed is conceptually the same as the third
fantasai: I don't see this as being a problem. Commas are lower precedence
than = in HTML (eg class=foo,bar - the value of class becomes
"foo,bar")
fantasai: Having the same pattern in CSS makes sense to me
plinss: I do see dbaron's point.
plinss: Shouldn't we do this for all the other types of attribute
selectors not just = ?
TabAtkins: Yeah, it's not just for =
plinss: p[class, id] is invalid?
TabAtkins: yes
* antonp likes this even less now, in the light of dbaron's comment
* smfr likes this less now too
<SimonSapin> I see the precedence argument as well
TabAtkins: We could take this back and think about it some more
<sgalineau> in favor of thinking about syntax more
TabAtkins: Let's do that.
plinss: OK, so not accepted for now, but you can raise it again later
if you want.
fantasai: Nothing else to discuss today, will bring more stuff later.
<dbaron> I think I gave a list of things in selectors4 I'm still iffy
on at the end (?) of last week's telecon.
Scroll Snapping
---------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html
plinss: interesting comment from roc
plinss: anyone interested?
TabAtkins: I'm in favor and could be an editor on this
smfr: I like it and would like to see it advanced
Rossen: We're also interested I think
plinss: OK, hearing strong support
Rossen: have Matt Rakow with me, who's a member of the WG and our lead
on this
TabAtkins: Separate spec I'd prefer
fantasai: It might fit in to UI
fantasai: but let's start it as a separate spec
TabAtkins: I think it's likely that this spec could grow
plinss: sticky positioning?
fantasai: No, that's positioning, not scrolling
Bert: It's related to overflow isn't it?
TabAtkins: This is about scrolling behaviour, not about all the other
stuff surrounding overflow, so it makes sense to me to keep
it separate
Bert: It doesn't relate to marquee but all other modes are affected
TabAtkins: Paged overflow isn't affected
Bert: sure it is, in interactive paged media
TabAtkins: No, I don't think so
plinss: OK, let's start as a separate doc and fold it in to something
else later
RESOLVED: accept work on scroll-snapping
CSS Colors Level 4
------------------
<SimonSapin> https://rawgithub.com/tabatkins/specs/master/css-color/Overview.html
TabAtkins: It's "which of these proposed things do we want to pursue"
<TabAtkins> http://tabatkins.github.io/specs/css-color/Overview.html#changes-from-3
1. rgb() and rgba() functions now accept <number> rather than <integer>.
2. hsl() and hsla() functions now accept <angle> as well as <number> for hues.
3. All uses of <alpha-value> now accept <percentage> as well as <number>.
4. 4 and 8-digit hex colors have been added, to specify transparency.
5. The color-correction property has been pulled in from the unpublished Color Correction proposal.
TabAtkins: Adding 4- and 8-digit hex colours has been a long-standing
author request
TabAtkins: #1 is something we should fix because it's a common authoring
error.
TabAtkins: Problem when doing something in JavaScript, have to round,
floor etc
TabAtkins: #4 is also for author convenience
TabAtkins: #2 and #3 are less so, but are nice
Tabatkins: This spec also pulls in dbaron's color correction proposal
TabAtkins: I'm fine with taking over editing that, if he's able to consult.
Tabatkins: There are also some other nice things
[plinss and TabAtkins discuss #1]
plinss: Concern about interpreting number as 0-1
TabAtkins: No, use % for that. Number would be 0-255
dbaron: I'm not crazy about adding syntactic sugar in general, because
it adds more compatibility hurdles
dbaron: It might be worth doing for color stuff, given the demand, but
I'm not sure it's high priority
TabAtkins: sure
<sgalineau> may not be high priority, but is it expensive?
<smfr> i like them
glenn: TTML specifies use of a #rrggbbaa syntax since 2010
TabAtkins: The compat issue applies reasonably to #2 and #3.
Tabatkins: but #1 and #4 are fixing stuff
<krit> some SVG authoring tools use #rrggbbaa internally as well like
Inkscape
plinss: How many people use HWB notation?
TabAtkins: Used in SASS, tint and shade is used quite a lot
SimonSapin: what is HWB?
TabAtkins: Hue, Whiteness, Blackness. Transform easily from eg RGB
TabAtkins: It's just an alternative that's intuitive
plinss: opinions?
[silence]
plinss: ok, let's move forward
RESOLVED: Shift these into a CSS4 Color ED
TabAtkins: I'm fine with pushing features out if we don't like them yet
Outline Properties
------------------
<dbaron> http://lists.w3.org/Archives/Public/www-style/2013May/0668.html
dbaron: I sent a message about a bunch of cases in which there's no
interop on outlines, and I'd like to hear what people think we
should be doing
dbaron: I guess there are 2 common differences: I think the spec is clear
that when an inline is broken across multiple lines then you want
the outline to surround the whole thing and not around the
individual lines
dbaron: Other thing was drawing the outline around the overflow, useful
when eg image inside link. Gecko is probably only browser which
does this.
smfr: webkit does that if outline thing is an inline, but doesn't if
it's a block, IIRC
florian: interop problem if you apply a rotation, IIRC
TabAtkins: smfr, no we don't do anything special in the inline case
dbaron: One question that's fundamental is that "we should optimize for
focus outlines"
dbaron: But authors like to use outlines for other things, like "border
which doesn't affect layout". Hence they demand better interop...
but we should ask how much we care about that and similar use
cases.
dbaron: With Gecko, it's becoming harder to maintain in the presence of
3d transforms
dbaron: I've been inclined to just drop the behavior of overflow
dbaron: despite the entire demand coming from authors using it for
non-focus use cases
Rossen: How are authors using this reliably if you guys are the only
ones doing this
dbaron: They was interop on other implementations, and they are complaining
to us
krit: There is strange behavior on outline in WebKit,Blink on things
that create a stacking context from time to time.
plinss: OK, two issues: Does the outline contain overflow content?
What's it's behaviour on wrapped inline elements?
dbaron: The overflow one is the main one I think
plinss: on the overflow topic, what do people think?
dbaron: I have mixed feelings about supporting this case
plinss: maybe we should introduce a property to control this behaviour?
dbaron: Seems like overkill to me...
krit: Regarding outline on svg, most browsers don't even support it.
So the spec is a bit weak.
smfr: In webkit we use different behaviour for focus ring(?) than with
outlines.
smfr: if outline style is auto, we fall into focus ring behaviour which
does go around overflow content
plinss: suggestions for path forward on these issues? We have test cases,
but do we need more discussion etc?
dbaron: I may want to look into webkit behaviour some more, given what
smfr said
Meeting closed.
<florian> dbaron: the outline on this TC behaves differently between
gecko/webkit vs presto
<florian> http://files.florian.rivoal.net/outline.html
<florian> I don't have IE here to test what it does
<Bert> I like Opera's outline best.
<florian> I think the problem with firefox's and webkit's approach is when
you start to have 3d transforms. I don't think transforming the
outline in 3d is a good idea.
<florian> it works ok when people use it as a second border, but not when
it is supposed to related to focusing
<Bert> Yes, imagine tabbing through a document, e.g., with the remote of
your TV. When the outline changes too much from one element to
another, you'll have a hard time finding where it went.
<florian> Let's move this conversation to the mailing list, I have to go
Received on Wednesday, 21 August 2013 23:22:34 UTC