- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 20 Mar 2013 10:56:41 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: css3-values to say: viewport units in continuous media are
based on the ICB, in paged media undefined (expected to be
defined in css3-page)
- Discussed renaming :matches() to :any()
- Plan to update CSS3 Values; if any issues missed, let us know.
- Reviewed status of Text Decoration CR: waiting on 2 issues
- Discussed Shadow DOM CSS/Selectors features and coordination with WebApps
http://lists.w3.org/Archives/Public/www-style/2013Mar/0283.html
- RESOLVED: grid line numbers always count from the before/start edge,
negative numbers count from the end/after edge.
- RESOLVED: Have 'order' property affect auto-placement and z-index
in grid, just as it does in flexbox
- Call for review of Grid Layout changes; plan to publish updated WD
next week
- Reviewed edits for Flexbox issue #12
http://lists.w3.org/Archives/Public/www-style/2013Mar/0260.html
====== Full minutes below =====
Present:
Glenn Adams
Rossen Atanassov
Bert Bos
Tantek Çelik
Jim Dovey
Arron Eicholz (via IRC)
Elika Etemad
Simon Fraser
Daniel Glazman
Rebecca Hauck
Koji Ishii
Dael Jackson
Brad Kemper (late)
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Anton Prowse
Simon Sapin
Dirk Schulze
Alan Stearns
Nick Van den Bleeken
Lea Verou
Steve Zilles (late)
<RRSAgent> logging to http://www.w3.org/2013/03/20-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Mar/0336.html
Scribe: Anton
Administrative
--------------
plinss: no additions to agenda
Topic: Update form PLH on IETF liaison
plh: no update yet
Viewport units in paged media
-----------------------------
X
SimonSapin: complicated, no solution yet
SimonSapin: Suggest to make undefined in css3-values, noting that it's
expected to be defined in css3-page
TabAtkins: ok
fantasai: are we making both viewport units used in the document and
viewport units used on @page undefined?
SimonSapin: both
fantasai: if we'll figure it out in the next couple of weeks, shouldn't
we wait?
plinss: How about: instead of saying they're undefined in values,
say explicitly that they /will/ be defined in css3-page?
fantasai: how about: it's defined one way if you support css21 page
stuff, otherwise ??
SimonSapin: uncomfortable with values saying it's based on the first
page; not sure that will be true
TabAtkins: I agree
plinss: <wants to avoid confusion>
Rossen: By undefined, remove definition or explicitly state it as
undefined?
TabAtkins: both
SimonSapin: new values module will state that viewport units are based
on ICB in continuous media, and undefined in css3-page
RESOLVED: css3-values to say: viewport units in continuous media are
based on the ICB, in paged media undefined (expected to be
defined in css3-page)
* fantasai thinks it's still based on ICB or else we're failing
something here, it's just a question of which ICB since
Paged Media has several ;)
Renaming :matches()
-------------------
<smfr> http://lists.w3.org/Archives/Public/www-style/2013Mar/0275.html
<tantek> sounds reasonable
<smfr> url?
TabAtkins: original name was 'any()'; we changed it for various reasons
TabAtkins: Brian K pointed out that if we want to extend :matches() and
:not() to express logical combinators, the name doesn't fit
in well with that
TabAtkins: I agree with his argument, and I liked 'any'
* tantek likes :any
* stearns prefers any-of
SimonSapin: I like 'any'
<tantek> or any-of
<Bert> (I don't understand :any(), it's whether an element has a certain
descendant, isnt it? so :matches() is fine, or :has() )
?: but what were the reasons for changing?
<fantasai> It doesn't make much sense if there is only one argument.
fantasai: originally the opposite of :not() which only takes one argument
fantasai gives examples
fantasai: I think :any() doesn't make sense when there's only one argument
inside it, whereas :matches() does.
TabAtkins: I'm comfortable with that argument
SimonSapin: I agree with that argument too
TabAtkins: common case will be multi-argument, so not sure of relevance tho
glazou: lots of docs on the web already describes 'matches'
glazou: I don't think 'any' is best choice, even though 'matches' isn't
perfect
TabAtkins: doc exists for 'any' as well though
* fantasai is ok with either name, as long as we've considered this and
agree its better in all cases, or at least on balance
<tantek> but aren't there more documents that actually use :any(-of) ?
<tantek> documents trump documentation right?
<tantek> seems like an easy opportunity to agree with web authors
<tantek> if we can go either way (can live with), then why not go with what web developers are asking for?
<tantek> (which seems to be :any)
glazou: matches with a group of selectors means you match against any of
the selectors
glazou: so don't think that 'any' gains us something semantic that was missing
<glazou> tantek, speak up!
Tantek: people don't have strong opinions. Web Devs lean towards 'any' or
'any-of'(?). Let's listen to that feedback since we are on the fence
fantasai: if we present it to the webdev community, we should use the single-argument case as an example
tantek: we should indicate the two leading options: any, and any-of
fantasai: I'll send an e-mail
tantek: and we can reassess next week
<Bert> So selector1:matches(selector2) is an element that matches both
selector1 and selector2? Then it is maybe an :and()...
<leaverou> the most common case is when you have multiple arguments
and it works as OR
<Bert> A:matches(B, C) = an element that matches (A and B) or (A and C).
Hmm, that is not an easy logical primitive...
<leaverou> more like A && (B || C)
<SimonSapin> Bert, the comma is OR, joining simple selectors without
whitespace or separator is AND, :matches is just grouping
<fantasai> It's A:matches(S) where S is a selector
<fantasai> Similarly a:not(S)
<fantasai> The comma is part of the selector
<fantasai> it means whatever it usually means
<Bert> A:matches(B, C) == A:matches(B), A:matches(C)
CSS3 Values Update
------------------
Reissue css3-values CR?
TabAtkins: Editors are not aware of any new issues beyond the one that
someone brought up today; let us know very soon if there are any!
CSS3 Text Decoration
--------------------
Go to CR?
fantasai: i18n had things they wanted to discuss; wait to see if they're ok.
fantasai: They had no call last week
TabAtkins: So wait for their approval?
fantasai: yeah, or resolve to go to CR and tweak it based on their feedback:
given that the call takes a month to schedule it seems, we have
plenty of time before it ;-)
<glazou> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013
<confusion about URLs>
fantasai: dbaron has an issue he wanted to talk about
glazou: Issue 6?
TabAtkins: wait for i18n and dbaron
Shadow DOM
----------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0283.html
glazou: spec starts being used by lots of other specs in and out of our WG,
as a way to specify widgets etc
<glazou> @host + CSS bits
glazou: we need to evaluate that stuff
glazou: TabAtkins, what is ETA, implementation report, rec track etc
TabAtkins: I'm directly involved but not necessarily the right person
TabAtkins: I e-mailed the WG last Nov about shadow dom
[TabAtkins summarizes CSS-related stuff in Shadow DOM]
<glazou> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#host-at-rule
TabAtkins: first: the @host rule. Stylesheets inside a web component
inside shadow dom are scoped to that shadow dom; can think
about it as a separate context
TabAtkins: Stylesheets inside and outside cannot cross the boundary
TabAtkins: Common to want to style the shadow dom differently in certain
situations
TabAtkins: @host allows to relax constraint
Tabatkins: we were considering @global which takes a scoped stylesheet
and relaxes it
ACTION Sapin: ask about @host grammar: ruleset vs. declarations
<trackbot> Created ACTION-550
TabAtkins: shadow dom allows you take elements from the DOM and distribute
them ??
< TabAtkins__ gives example >
TabAtkins: we introduced a ::distributed() pseudo-element to select elements
distributed to a distribution point ...
Tabatkins: we added ::shadow() which works in the opposite way from
::distributed
glazou: your pseudo-element makes sense, similar to -moz-bound-element in Mozilla
glazou: @host selects element in shadow host, but you cannot write a rule
whose selectors are matching elements in the shadow host and
shadow dom?
TabAtkins: yes you can
glazou: ok, that's more powerful than the Mozilla pseudo
glazou: the whole thing makes sense now! Much better
glazou: Should these bits remain in that doc, or should that shadow-dom
be joint work between webapps and us?
TabAtkins: it's unofficially joint already
TabAtkins: I don't mind either way
glazou: Members: is it ok to invest time in this in the group, if it's not
in the charter?
plh: The good thing about one single spec is that it's easier to assimilate
plh: will be a joint effort between webapps, us and HTML
TabAtkins: doing it joint won't be a big effort
TabAtkins: I'm not currently acting as an informal co-editor
glenn: maybe we could propose a co-editor from CSSWG to contribute
(eyeballs, etc)
glazou: Would dimitri be prepared to join our WG for purposes of formally
making the spec joint?
plh: Best to use TabAtkins ?
glazou: OK
glazou: @host with new pseudo relies on the fact that in the new grammar
the pseudo doesn't need to be in last position
TabAtkins: actually, no. Not relevant
?: do you have an example?
stearns: boundary of light and dark CSS; if the light css defines a
counter style, can the dark css refer to it?
TabAtkins: yes
SimonSapin: scope is only about selectors?
TabAtkins: yes
plh: link to that draft from css4-selectors draft? Should all selectors
be listed in one doc?
TabAtkins: I think it's reasonable to have a link. c.f. values and units
TabAtkins: plh, glazou : all agree
<SimonSapin> so, should Selectors 4 also link to css4-pseudos, css3-ui,
and anything that adds selectors?
<fantasai> SimonSapin, informatively, probably would be a good idea
<SimonSapin> fantasai, yes, informatively
<glazou> fantasai, SimonSapin : agreed
ACTION: TabAtkins to ping the WG whenever Dimitri finishes the edits
related to CSS
stearns: select a custom component based on a media query?
TabAtkins: we don't have anything for that. Can do it right now using
JS version of the API. There's nothing declarative right now
Alan: in the component itself, the dark css could have a MQ ...
<Alan and TabAtkins__ discuss>
glazou: @host - contains only style rules right now. Why not nested
@-rules?
TabAtkins: spec currently has old version of @host. Only allows
compound selectors
TabAtkins: grammar production will be similar to stuff defined in
conditionals, will allow arbitrary nesting
Grid Layout
-----------
plinss: publish WD?
TabAtkins: we've switched over grid positioning properties into
line-based properties. We think it's complete enough
to be a WD, and changed enough that we really need a
new WD.
<stearns> +1 to publish
fantasai: to avoid confusion, let's go through a couple of the issues
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Mar/0266.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Mar/0182.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Mar/0184.html
<fantasai> (this is issues 1 / 2 in that list)
<TabAtkins explains the issue - see pasted URL>
<TabAtkins describes potentially confusing syntax>
glazou: I like the proposal
<SteveZ> +1
TabAtkins: matches programming languages such as Python
plinss: -1 means last line?
TabAtkins: correct.
RESOLVED: line numbers always count from the before/start edge, negative
numbers count from the end/after edge.
Bert: what happened to grid-area property?
TabAtkins: it's still there
plinss: still some discrepancy about conflating line names and area names,
but I see that's flagged as an issue
fantasai: Can we deal with ordering issue?
plinss: [...]
TabAtkins: it may still affect z-index, but otherwise yes.
RESOLVED: Have 'order' property affect auto-placement and z-index in grid,
just as it does in flexbox
TabAtkins: I wanted to point people to the abspos section of the spec;
it looked like it was easy to get abspos to be useful
http://dev.w3.org/csswg/css3-grid-layout/#abspos-items
TabAtkins: please review
plinss: what about left/right/top/bottom?
TabAtkins: they respond to the containing block; the grid-placement
properties just change the containing block
rossen: Can we have a week to go through issues and give feedback?
TabAtkins, plinss : that's fine
Flexbox
-------
<glazou> FWIW, I have now a basic layout editor based on the most
recent flexbox spec
<glazou> http://lockerz.com/s/287452841
TabAtkins: Are Rossen et al happy with the changes we made to address
Rossen's issue?
TabAtkins: about stretching elements
<fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-12
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0251.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Mar/0260.html
TabAtkins: orthogonal flow issue: resolve it in a similar way to multicol,
to get good behaviour. Current spec is terrible
fantasai: Defining intrinsic sizing on flexbox made a lot of issues fall
out correctly
fantasai: Just need review.
plinss: Bye everyone
Meeting closed.
Received on Wednesday, 20 March 2013 17:57:10 UTC