- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 27 Mar 2013 18:15:30 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- New ED of CSS3 Overflow, needs review for WD publication next week
http://lists.w3.org/Archives/Public/www-style/2013Mar/0600.html
- RESOLVED: Publish grid layout WD
- Recently-posted issues against CSS3 Text Decoration; need to file
and address in DoC:
http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013
- RESOLVED: We copy the behaviour of % margins/paddings from grid to
flexbox: they are relative to their respective dimension,
not always the inline dimension (as in block layout)
- Discussed problem of always loading style sheets even when qualifying
MQ does not match:
http://lists.w3.org/Archives/Public/www-style/2013Jan/0434.html
http://lists.w3.org/Archives/Public/www-style/2013Jan/0522.html
- RESOLVED: Wrt propagating events up through regions parent chain
(rather than DOM parent chain), propose solution based
on using a property to switch behaviors.
- Discussed offsetParent and region parenting
- RESOLVED: publish new CR for css3-values with above edits
- Checked in on :matches() naming discussion
- Discussed 72-hour resolution-by-email proposal.
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
David Baron
Bert Bos
Jim Dovey
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Israel Hilerio (Microsoft)
Dael Jackson
John Jansen
Brad Kemper
Chris Lilley
Peter Linss
Alexis Menard
Anton Prowse
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Nick Van den Bleeken
Lea Verou
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2013/03/27-css-irc
Regrets: hober, molly, TabAtkins, SimonPieters, plh
Scribe: AntonP
No extra items for agenda.
CSS3 Overflow
-------------
<dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/0600.html
glazou: Request from dbaron to publish FPWD of css3-overflow
dbaron: I added Section 2
dbaron: Would be great if others could read that
florian: I like the draft but have issues with overflow-x/y and so I'd
like to review that section to flag possible problems
?: has there been any implementation activity on this?
Alan: Where does this sit in the group's priority list, charter etc?
florian: I wonder how much interest in Opera there is
glazou: Old charter expires in Sept, and this isn't currently charter
glazou: We occasionally enforce the deliverables in the charter
dbaron: This is mostly moving things from other docs into this one
dbaron: which is not generally a charter problem
ChrisL: That's correct
dbaron: The new thing [fragment overflow?] is new but is an alternative
to something that already exists in another doc
glazou: Are you OK with a week for the WG to review?
dbaron: yes
glazou: What is the priority of this spec, to you?
dbaron: I've heard implementers say that they are interested
florian: I'd like this to make progress, though I'm not implementing
anything
<stearns> whether overflow:fragments is an alternative is debatable -
I consider it an addition
Rossen: Is this targetting various layout models, not just block?
Rossen: A lot of text is copied from css21 but it should be generalized
dbaron: It applies to block and flex containers. It's intentional that
it doesn't apply to eg inline
Rossen: Grid is a valid target spec
fantasai: "Grid containers" are defined in the grid spec right now
dbaron: OK
florian: You specified overflow-x/y but don't carry over the definition
of overflow-style - yet there is overlap. Although I don't
like overflow-style we should avoid overlap.
dbaron: overflow-style is pretty much dead as far as I can tell
florian: overflow-paged?
dbaron: yes
florian: <something about Opera>. Probably nobody
Bert: overflow-style came from Marquee spec
ChrisL: sounds fairly dead
<sgalineau> iirc IE10 uses overflow-style to trigger auto-hide scrollbars
Bert: We introduced it to allow various different ways of overflowing,
not just Opera's but things like marquees and thumbnails
glazou: I don't think this discussion is relevant to the current topic
florian: (It's a good discussion)
florian: we should have it at some point.
<fantasai> I think fragments should not be an overflow-style, but paged
vs. scroll should be
glazou: 1 week for WG to review, then decision next week?
dbaron: OK
ACTION on everyone: review doc
Grid Layout
-----------
(followup from last week)
glazou: Rossen wanted a week to review the doc
Rossen: We're OK overall with going forward with a publishing a new WD
Rossen: I have feedback, but can use mailing list for that
Rossen: No blockers for now
glazou: Any objections to advancing the doc?
RESOLVED: Publish grid layout spec
CSS3 Text Decoration
--------------------
Topic: issue 6 for css3 text decoration
dbaron: I have a better URL for Issue 6 other than the one in the
Disposition of Comments from yesterday
<dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/0529.html
<dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/index.html#msg534
dbaron: I also sent a bunch of other messages <see second URL>
dbaron: I don't quite know how to proceed, given the other issues
dbaron: I'd rather discuss on the mailing list; I haven't seen responses
to them. Don't know if fantasai agrees
fantasai: I haven't seen all of these yet
glazou: OK, let's move on
Flexbox
-------
Topic: vertical % margins and padding on flexbox
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0143.html
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/thread.html#msg143
dbaron: Not necessarily /from/ me, but I wanted to poke the issue
dbaron: People are shipping implementations of flexbox and this is a
change proposal.
dbaron: I'm curious about the status
fantasai: When you have margins on a block element, the vert margins
(block direction margins), they resolve against the size of
the container in the inline dimension
fantasai: Flexbox doesn't say anything about this being different for
flex items, whereas grid does specify that % margins are
relative to the same dimension
fantasai: so there's an inconsistency
fantasai: For blocks, height of containing block typically isn't defined,
so % margins relative to that would fall to zero.
fantasai: Resolving against the containing block width gives better
behavior in the common cases there.
fantasai: However for flexbox that reasoning doesn't apply so much
(nor for grid). These layout models are frequently used
with a defined height.
<fantasai describes flexbox behaviour>
fantasai: Another issue is that the inconsistency in dimensions is
particularly confusing for Flexbox: e.g. for row flexboxes
percentage margins would work in the main axis, but for
column flex boxes they wouldn't.
glazou: Implementors?
dbaron: I'm fine with switching, but it seems odd for different display
types to behave differently. I'd prefer to do it sooner rather
than later though.
Rossen: Matching flexbox behaviour to grid makes sense, will help app
developers
Rossen: The inconsistency will be overcome by authors soon enough.
RESOLVED: We copy the behaviour of % margins/paddings from grid to flexbox
Media Queries
-------------
Topic: media queries and data transfer
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jan/0434.html
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Jan/0522.html
dbaron: Henri raised this is an issue initially. I don't want to solve
it today, but again I wanted to poke it.
dbaron: Lack of a CSS solution is pushing other groups to push HTTP
solutions, which I and others don't think is ideal
<dbaron explains the issue>
dbaron: The proposal is a proposal to add something to HTML, to the LINK
element which links to the stylesheet, saying that the stylesheet
shouldn't be retrieved [....]
fantasai: Can't we do that by default, that UI shouldn't fetch stylesheets
if it thinks it's not used (matched)?
fantasai: and not loaded into object model unless explicitly requested
dbaron: Implementations would be unhappy about doing it for print
fantasai: The browser wouldn't download SSs that it knows it's not going
to use, e.g. device-width doesn't match. But if it thinks it
might use the SS then it could load it, at lower priority,
just not load into the object model until it matched.
dbaron: device width/height can change when you rotate a mobile device
dbaron: Original design was to make it harder for authors to mess up
accidentally
dbaron: Consider the mail as authoritative about the summary/description
of the topic
dbaron: This is probably and HTML group topic; but people here should
be aware of it.
florian: Thought/Question: a stylesheet included from within a CSS
conditional (supports) should also be deferred?
<fantasai> I'm worried we're going to get "async all the things!" from
some authors and "what's an async? i don't know that feature,
so my sites don't use it" from others
<fantasai> would be best if the default behavior was more optimal
<fantasai> then add syntax to force loading or not loading if needed
* Rossen agrees with fantasai
florian: If we allow 'defer' or whatever on the style element so that
it applies to inline style, I'd like it to be compatible for
@import inside @supports
florian: Can we put suggestions to the HTML group
dbaron: I'll ask Henri to
<Bert> (I wonder what this does to phishing and privacy. One reason
to favor MQ over CC/PP was that MQ can hide the UA's
characteristics and user preferences.)
CSSOM View
----------
Topic: CaretPosition.getClientRect() (new API)
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Feb/thread.html#msg323
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Feb/0323.html
dbaron: I wanted to seek comments from non-Mozilla people
dbaron: CaretPosition is interesting; it usually corresponds to a
collapsed range, but allows to get caret position from inside
input or text area
glazou: makes sense
smfr: Fine for me
Rossen: I'm still catching up on the topic, sorry
Rossen: if this isn't urgent I'd like to involve someone else and get
back to you
dbaron: That's fine, but I wanted to poke it
glazou: let's revisit later when we have Rossen's input
Regions and Reparenting Side-effects (pointer-events / offsetParent)
--------------------------------------------------------------------
Topic: click events and ::hover styling in styleable fragment containers
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0573.html
<stearns> http://lists.w3.org/Archives/Public/www-style/2013Mar/0414.html
stearns: I have a long message on the list, with only one response
stearns: main issue: DOM tree, visual box tree; click events and :hover
styling propagate only from DOM tree, which leaves out fragment
containers
stearns: would be good to apply these to fragment containers
stearns: 4 options
1. Interleave frag container into event propagation somehow
2. Fork the propagation to have two different propagation chains
3. (Only works for events)
4. Have a switch: either use the current DOM tree behaviour
or with a switch allow you to move up the visual container
hierarchy.
glazou: I responded, saying I like the 4th solution, especially thinking
about pointer events
glazou: solves an old issue about hovering positioned elements too,
which exists as a note in the selectors spec
stearns: The solution that I put out would only deal with the frag
containers, but I suppose it could be extended to this
situation too
glazou: It's a similar situation.
Rossen: Talking about containing block chain, instead of DOM structure,
glazou?
glazou: yes
Rossen: I can see this potentially being extended to cover both
glazou: yes, there's a possibility to extend it.
glazou: overall, pointer-events strategy seems good
BradK: I don't like switch
dbaron: I'm concerned about CSS properties changing event propagation
dbaron: Generally CSS doesn't affect DOM behavior
<stearns refers to example in his mail, about pages>
<fantasai> I'm sympathetic to dbaron's concern about layering, but
I'll also note that propagating through the region parenting
is entirely controlled by CSS
<sgalineau> dbaron, doesn't pointer-event do that to some extent already?
<fantasai> not really. It changes the geometry of the target only, atm
<sgalineau> you can use it to prevent an element from capturing events
<fantasai> That's equivalent to making its geometry match the empty set
of points
stearns: I'm happy to try out option 4, unless there's anyone who prefers
any of the three previous options
fantasai: I'm not DOM or events person, but second one also looks like
it could be OK
stearns: 2nd one is about duplicate event which goes up the visual hierarchy
fantasai: concern with 4th one: pointer events changes the geometry with
respect to pointer clicks, but doesn't change how the events
are propagated
fantasai: Do we need a separate property?
sgalineau: You're changing which way it's routing
fantasai: It's like making it hidden
sgalineau: if a different node gets the event, you get a different route
fantasai: no
sgalineau: yes
<fantasai> You're just changing what got hit, not what the routing is
after the hit
<sgalineau> disagree; another node behind you gets the event and may
not be your parent afaik.
<fantasai> right, but you didn't hit that because it wasn't "visible".
You didn't change the routing of the event bubble chain,
you changed its target
<sgalineau> if a CSS property causes a different element from
capture/bubbling then we already are doing this
glazou: there are use cases for web designers
glazou: we need a solution.
glazou: Is it OK if stearns starts proposing a solution of some kind,
e.g. based on 4th option?
* fantasai thinks that's fine
stearns: I'll post to list saying we're going with option 4.
Some of the discussion we've just had should be replicated
on the list please
RESOLVED: stearns to post to list with a solution based on option 4
* BradK wonders if the switch is needed for DOM event propagation,
but not for writing selectors
Topic: Changes to offsetParent in styleable fragment containers
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0573.html
stearns: Question for named flows and a bit for shadow DOM and its
insertion points
stearns: What are the offset attributes for?
stearns: Are they for getting some relative position to a box on the
page, or is it meant to provide the offsets to the closest
visual ancestor which has something to do with the box's position?
stearns: DOM structure vs Visual box
stearns: I wanted to poke this issue because I didn't get any response
on the list
smfr: Why do authors use the offset attrs?
smfr: we've talked about adding API allowing point conversion between
elements
smfr: if we have that, we don't need offsetTop stuff
smfr: Maybe we should push for that API
smfr: We'd have to do something sensible for offsetParent, but doesn't
matter too much if implementations differ a bit
stearns: I'm ok with the idea that if it's not interoperable anyway
then let's not fix it
* scribe is not sure he captured stearns' opinion correctly
glenn: suggest discussing with roc and bzbarsky
CSS3 Values
-----------
TOPIC: Reissue css3-values CR?, followup from last week
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0349.html
Tab and I think it's time to reissue CR on css3-values, since
we've made a few clarifications. They're listed here:
http://dev.w3.org/csswg/css3-values/#changes
Let us know if we missed any; I remember Alan mentioned something
and I can't remember if it was one of these or something else. :/
<stearns> I don't remember what my issue might have been
<SimonSapin> http://www.w3.org/mid/514AD389.8060008@exyr.org
ACTION fantasai clarify interaction of viewport units and scroll
<trackbot> Created ACTION-551
fantasai: Any other issues to be handled before CR?
dbaron: I wonder if viewport units should say that it counts the
scrollbars when overflow is scroll, rather than the current
cumbersome description
<fantasai> ACTION fantasai Edit in Simon's issue
<trackbot> Created ACTION-552
Publishing...
SimonSapin: I'm fine with resolving with last weeks resolution
glazou: any objections?
RESOLVED: publish new CR for css3-values with above edits
fantasai: I'll prepare it for Tuesday (doing edits today) and I'll inform
the mailing list
fantasai: there'll be time to tweak it between now and next week
Selectors 4
-----------
Topic: Renaming :matches(), followup from last week
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0275.html
fantasai: SimonSapin sent the e-mail that we said someone would send
last week
fantasai: Doesn't seem to be a conclusion on the ML.
glazou: so no resolution right now?
SimonSapin: feedback: currently does not allow combinators inside matches,
so matches with only one argument isn't very useful
fantasai: Selectors 4 is concerned with performance, but we can remove
that restriction
fantasai: Tab and I discussed the idea of different levels of selector
support for this feature.
fantasai: E.g. batch processors wouldn't have a problem with supporting
complex selectors in :matches() / :not().
glazou: let's defer to mailing list
Administrative
--------------
glazou: 72 hours e-mail: in case of a decision which has to be made
technically on the mailing list, there's a tag in the summary
indicating 72 hours for providing objections
glazou: it's a clean way of making a decision to avoid topics dying off
fantasai: Pretty good idea, but don't pull it up with no warning
ChrisL: if it's kicked off by a telecon, then we should be ok
<general agreement>
antonp: if we do this, please mention it in the summary of the minutes
of the telecon so that it's easy to see that it's happened
<general agreement from various speakers>
Meeting closed.
<fantasai> ok, so publish grid-layout and css3-values...
Received on Thursday, 28 March 2013 01:15:59 UTC