- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 30 Sep 2013 19:55:23 -0400
- To: www-style@w3.org
- Message-ID: <CADhPm3sVKok9zDd-7S3E6bmJpJDMaf0H_2B1YBsYG7VB4D3rgw@mail.gmail.com>
CSS Masking - Review Request
----------------------------
- RESOLVED: The WG will review Masking LC transition on 10/9 telcon
Any interest in working out selection/editing based on display tree rather
than DOM?
-----------------------------------------------------------------------
- Though some interest was expressed, it was deemed currently not
enough to proceed to an ED
Flexbox
-------
- RESOLVED: Use 2-pass algorithm to resolve % height children of flex
stretched items pending dholbert's feedback.
- RESOLVED: Proposed issue-1 edits are approved.
======FULL MINUTES BELOW==========
Present:
Glenn Adams (Cox)
Rossen Atanassov (Microsoft)
Tab Atkins (Google)
Mihai Balan (Adobe)
David Baron (Mozilla)
Bert Bos (W3C)
Tantek Çelik (Mozilla)
John Daggett (Mozilla, via phone+IRC)
fantasai (Mozilla)
Sylvain Galineau (Adobe)
Daniel Glazman (Disruptive Innovations)
Israel Hilerio (Microsoft)
Koji Ishii (Rakuten)
Kawabata (NTT)
Ian Kirkpatrick (Google)
Håkon Lie (Opera)
Peter Linss (HP)
Ted O'Connor (Apple)
Simon Pieters (Opera)
Rivoal, Florian (Invited Expert)
Simon Sapin (Mozilla)
Dirk Schultze (Adobe)
Alan Stearns (Adobe)
Shane Stevens (Google)
Leif Arne Storset (Opera)
Jet Villegas (Mozilla)
Yamamoto (NTT)
Steve Zilles (Adobe)
[agenda/schedule wrangling]
http://wiki.csswg.org/planning/paris-2013#agenda
* krit plinss: glazou In case we have 5min. Can I ask the WG for a
review of CSS Masking? I incorporated the feedback of the CSS
WG from yesterday and don't have any issues on the spec
anymore.
* krit plinss glazou I would like to get to LC after a review time of
2-3 weeks (probably the later because of the other two specs
need reviews)
<glazou> krit, ok
<glazou> that's just a review request right ? 5mins ?
<krit> yes, nothing more
<glazou> cool, np
CSS Masking - Review Request
----------------------------
Scribe: sgalineau
<krit> http://dev.w3.org/fxtf/masking/
krit: I incorporated yesterday's feedback in the spec
krit: We will only support one layer of masking.
krit: Also, I updated the initial values we discussed.
krit: I have no issues in the spec at the moment and would like to ask
for review.
krit: Child selector for the mask image would be at-risk.
glazou: How much time do you need for review?
krit: 3 weeks?
glazou: Ok, so 2nd telcon from now
fantasai: I'd prefer 4 weeks
<dbaron> so that's October 9
RESOLVED: The WG will review Masking LC transition on 10/9 telcon
Any interest in working out selection/editing based on display tree rather
than DOM?
-----------------------------------------------------------------------
astearns: Selection/editing only works on the DOM tree
astearns: When certain positioning modes/layouts get used, selection
start looking funny
astearns: How much interest is there in making selection/editing work
on table columns, or select what is inside an absolute
position and what is next to it vs selecting DOM ranges?
glazou: The problem is selecting visually contiguous areas regardless
of whether there are floats or whatever.
astearns: Yes. You start selecting inside a float and drag outside, a
lot of stuff comes in.
michou: This gets fun with flex box and grids as well, especially when
the content has been reordered.
fantasai: My understanding was that the DOM APIs for selection allowed
for discontinuous ranges and it was up to the UAs to do the
right thing.
astearns: Is this WG interested in coming up with an intelligent way
to deal with this?
glazou: I think there are two questions
glazou: 1) Is the problem interesting? Yes.
glazou: 2) Is it a CSS problem? I'm not sure it belongs to this WG
glazou: This seems more a description of visual selection behavior in
the UA
astearns: Right. As michou pointed out this is left to UAs.
fantasai: What is the interop we're looking for?
glazou: I've gotten blue griffon bug reports due to surprises related
to caret management.
glazou: WYSIWYG editors behave one way, browser-based editing
surprises users.
krit: It's not only selection, it's also accessibility, isn't it?
fantasai: This can be intentional though.
glazou: I'm really interested in the topic but I do not think this is
a CSSWG work item.
plinss: Maybe we need APIs that produce ranges based on a geometry.
astearns: The Region spec has APIs to get DOM ranges for a named flow
so we're kind of going in that direction.
glazou: Would you like to move this to a new ED?
astearns: Not at this time; there doesn't seem to be enough interest
in this area at the moment
Flexbox
-------
http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-3
tabatkins: A handful of clarifications and tweaks to the layout
algorithm are needed.
<projector> http://dev.w3.org/csswg/css-flexbox/#issue-dd911971
tabatkins: There is a request to make percentages work well even if
the flex item is auto height.
tabatkins: If a flex item is stretched, the fixed container is a fixed
height and a child of the flex item uses % the % is
resolved against the stretched height of the flex item.
dbaron: Is this horizontal only?
fantasai: Apparently IE already implements this; if there is a flex
row container and it's auto height, and an item inside it
has a % height child.
tabatkins: We used to not resolve this. We'll do layout as if it was
auto and then resolve those percentage children
dbaron: What is it that the height applies to?
dbaron: Then I have to relayout
tabatkins: You relayout the flex item but not the flexbox
dbaron: Small incremental updates may require another pass
[tabatkins draws a picture]
dbaron: Does the flex box have a fixed height?
tabatkins: No.
tabatkins: This works well if the item in question is not the tallest.
tabatkins: It's not ideal when the flex item in question is the
tallest but it's still better.
dbaron: It sounds a bit like table row sizing
dbaron: In tables, % sizing of table cell children appears to be
random...
tabatkins: In this case, it's not hard to depend on.
tabatkins: If you have a fixed height, it just works. Otherwise, it
does its best attempt and it's workable in most cases.
dbaron: I'd guess I'd be OK. What does dholbert and other implementors
think?
rossen: We're OK with it.
rossen: I thought we had agreed to this at TPAC
[short exchange ending with tabatkins: oh yeah, I'm making stuff up]
RESOLVED: Use 2-pass algorithm to resolve % height children of flex
stretched items pending dholbert's feedback.
tabatkins: Issue-3 is the proposed text for issue-2
tabatkins: Next is issue-1 about respecting the intrinsic aspect ratio
of flex items.
tabatkins: You don't want to abandon this ratio unless absolutely
necessary.
tabatkins: We never resolved the proposed edits.
tabatkins: During the initial sizing, if it is stretched and auto in
both dimensions, and the container has a definite
cross-size and is single line; then we go ahead and
pre-stretch the item and use its ratio to figure what is
its main size
[tabatkins clarifies the steps for dbaron]
tabatkins: I don't recall any objections; IE already does something
close to this.
RESOLVED: Proposed issue-1 edits are approved.
tabatkins: that's it for now; one issue left we need to discuss later.
fantasai: and then we'll make diffs and move to LC
* zcorpan_ Unrelated question: are css variables scoped to the
stylesheet they're declared in?
* fantasai no, they're effectively properties
* fantasai that cascade and inherit just like regular properties, and
are therefore scoped to a particular element
* zcorpan_ fantasai: you mean the scope is all stylesheets that apply
to a particular document?
* fantasai Yes, the scope is all stylesheets that apply to a
particular document, but it's also scoped by element.
* zcorpan_ Ok.
Received on Monday, 30 September 2013 23:55:51 UTC