- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 May 2015 13:27:04 -0400
- To: www-style@w3.org
CSSOM View document.scrollingElement review
-------------------------------------------
- RESOLVED: Accept the behavior but add more definition
Publish/Review of CSS3 UI
-------------------------
- RESOLVED: Publish an updated WD with the additional section from
tantek
justify-content: stretch on flex items
--------------------------------------
- RESOLVED: justify-content: stretch computes to stretch but
behaves like start
- Note: This resolution might not have been recorded correctly.
Please see member only discussion regarding potential
clarification, available here:
https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0090.html
Position 'center' and 'page' values
------------------------------------
- RESOLVED: remove position: center from Position
- RESOLVED: Republish CSS positioning without position: page. Also
update the short name.
- Conversation will continue on the mailing list to put together a
case for re-introducing position: page and it will likely
become a F2F topic in NYC.
Proposal to *not* standardize user-modify
-----------------------------------------
- RESOLVED: no user-modify in CSS UI 4
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bo Campbell
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Anton Prowse
Florian Rivoal
Andrey Rybka
Simon Sapin
Alan Stearns
Regrets:
Sanja Bonic
Adenilson Cavalcanti
Hyojin Song
Steve Zilles
scribe: dael
plinss: Let's get started.
plinss: Any last minute additions to the agenda?
plinss: andrey you wanted to do a F2F reminder?
<andrey-bloomberg> sorry phone died
plinss: He sent a note to anyone going the the NYC F2F to update
the wiki so we can get a count.
Florian: I'm about to get air bnb so if anyone wants to join
please let me know today.
<SimonSapin> Florian, did you get my email response?
<Florian> simonSapin: yes, thanks
CSSOM View document.scrollingElement review
-------------------------------------------
<plinss> http://dev.w3.org/csswg/cssom-view/#dom-document-scrollingelement
plinss: TAG was asked for input and there was discussion there,
but I don't think we discussed this in the group. I wanted
to make sure we took a look at this and gave comments or
feedback.
plinss: It's not widely implemented, but has different behaviors.
I'm not sure if this section has been reviewed by many
people and I want to make sure it's implementing what we
want it to implement.
plinss: So does anyone have feedback?
[silence]
<dbaron> Why is this being added? It seems like an odd definition.
smfr: It's not clear if this is a stopgap until browsers have
correct behavior or if it's a long term API that will stick
around.
plinss: Not to me either.
Rossen: Which are you referring to?
smfr: In standards mode it's always scrollingElement. I think this
is a stopgap until webkit and blink use the documentElement
in standards mode. With the intent this is used by polyfills
to get correct behavior.
smfr: It doesn't feel like a stopgap, it seems like it will stick
around until the end of time. If it is a stopgap, I'd prefer
it was designed more like one.
Rossen: I don't think this is a stopgap. I think it has wide
adoption. Backing out, I'm not sure if it would be easy
even if you want to change.
<dbaron> It would be nice if the spec actually contained the
motivation.
<smfr> dbaron: lots of motivation at
https://github.com/w3ctag/spec-reviews/issues/51
<dbaron> Gecko doesn't implement it
plinss: It's not clear how useful this API is. What does it do in
iFrames? There's holes here.
smfr: It's not intended to be scrolling. It's only for this issue
with a historical behavior where in standards mode it
scrolls the body, not the document. It sounds more general,
but it's really specific.
Rossen: We have implemented the same way as webkit and Chrome for
mobile interop. This is a fairly used API at this point
and I don't think we can back out unless we do it together.
smfr: I don't think you impl this. I think you impl the body as a
scrolling element.
dbaron: If this is to be a transitional thing for until the quirky
behavior can go away, shouldn't the definition be tied to
if the behavior is there?
<dbaron> (e.g., if Gecko were to implement it, and doesn't have
the quirky behavior, should we be implementing something
different from what the spec says?)
smfr: That's a good suggestion for ric.
TabAtkins: The major reason for this is the weird behavior of
webkit and blink, but the same quirks mode effects it.
So even if you impl properly you still need to detect
if you're in quirks mode.
plinss: I'm hearing from Microsoft they're not sure if it can be
changed, hearing from others I'm not sure if that's the
way we want it.
TabAtkins: That's not what I said. It sounds like this is needed
for quirks mode vs. standard mode documents as well as
the webkit behaviors.
Rossen: It sounds like this is something we ought to be working on.
smfr: I don't object to this. I think the bug report was webkit
would like it to be more clear on intent.
plinss: Are we comfortable with the behavior as spec'ed?
Rossen: Are you saying a little stronger and clearer definition
would make you willing to put in efforts?
smfr: If what TabAtkins says is correct and this will be longterm
behavior it seems like it has legs and will stick around.
<dbaron> I think (a) we should have a plan to have implementations
doing the same thing and (b) if this is part of a plan to
migrate to some end state, that migration sequence should
be described in the spec
Rossen: Okay. So who would want to work on that, spec wise?
TabAtkins: The spec part seems trivial. You put it in CSSOM View
and it's a paragraph of definition. That's all.
plinss: dbaron made some comments in IRC.
plinss: Anyone willing to take this work?
TabAtkins: I can work with ric to get a definition and do a PR.
plinss: Everyone happy with that?
Rossen: Yep.
RESOLVED: Accept the behavior but add more definition
Publish/Review of CSS3 UI
-------------------------
<Florian> https://www.w3.org/wiki/CSS3-UI
Florian: For the first time in a while we have 0 issues. This wiki
(above) has the resolved issues. Some are by fixing, some
postponing, but it's all documented.
Florian: This looks like a good time to review and perhaps ask
other WG to look at it at the end of which we go to CR.
Florian: tantek mentioned he wanted to add an implementor's
appendix.
tantek: I've gone ahead and added it on my local copy. That should
be done soon. This is a security and privacy questionnaire
that the TAG is looking at and I believe is taking up.
It's meant for self review by editors of their specs. I
think it's good to include as an informative appendix.
tantek: It's informative, not normative and pretty short.
Florian: I suggest we put a WD out and get comments from others.
Florian: After we decide if we're going to CR
<Florian> I want to put a WD out, ask the group to review, maybe
ping other WG
<Florian> Effectively a LC
tantek: I'd like this to go with the WD. Give me a few minutes to
post and we're good.
<tantek> I'm in favor of WD with these informative edits
plinss: Here's the link to what tantek's document is based off of.
<plinss> https://w3ctag.github.io/security-questionnaire/
plinss: So publish an updated WD with this section. Do people want
to review or are we good to publish?
<andrey-bloomberg> +1 for working draft
<fantasai> +1
<fantasai> for resolution to publish
Florian: Do we want to ping any other WG about this being
effectively done?
fantasai: Probably ping HTML and maybe webapps and a11y.
Florian: Yes. Probably also SVG because they were interested in
nav property.
RESOLVED: Publish an updated WD with the additional section from
tantek
plinss: If you could work on the additional comments in DoC form
we can get queued up for CR.
Florian: And everyone should review this.
<tantek> FYI: CSS3-UI security & privacy questionnaire answers
appendix committed
justify-content: stretch on flex items
--------------------------------------
plinss: fantasai I think you raised this?
fantasai: We wanted to know what the right way to change auto and
stretch values of alignment. On flex they behave as
start. Do we compute them through or do we say it stays
the way it is. The reason to compute through is auto is
a new value. If the initial value can make it disappear,
for backwards compat we need to compute through.
fantasai: So a) is compute to flex start or b) is the compute to
themselves and behave as flex start.
<dbaron> "stays the way it is and behaves the other way" ?
* dbaron didn't follow that sentence
Rossen: I'm inclined to go with the first option because there's
less magic. I'm not convinced it would be the optimal
behavior we can have. I haven't had too much chance to
work on the issue and think about it so if anything I will
update on the ML.
dbaron: My one thought is we've been introducing a lot of
computation dependencies and they all have cost an may
prevent more in the future so we should be careful of
those.
<dbaron> fantasai, is "compute through" (a) or (b)?
fantasai: Okay. Based on the feedback so far I'm inclined to have
it compute through. If people disagree we can come back
to it. We're not changing flexbox.
fantasai: Compute through is (a). Compute to flex start
<fantasai> (This is a Box Alignment issue; Flexbox doesn't have
auto or stretch values)
plinss: Option a was compute to stretch and behave as flex start.
So you're saying it computes to flex start?
fantasai: Yeah. It computes to flex start.
<fantasai> A) compute to flex-start
<fantasai> B) compute to self, behave as flex-start
plinss: Objections?
dbaron: What's the exact dependency here, in terms of properties?
fantasai: It depends on value of position and the value of the
parent's display
* fantasai thinks dbaron has a good point, we should make a
dependency graph on the wiki
* dbaron fantasai, we have one on the wiki, I think
* fantasai ok
* fantasai goes looking
* dbaron fantasai, but it's pretty out-of-date
* Florian thinks the computed value dependency graph sound like a
job for bikeshed
* tantek indeed Florian
<dbaron> fantasai, https://wiki.csswg.org/spec/property-dependencies
is our wiki list of dependencies
Rossen: Like fantasai pointed out I don't currently have an
objection, but I'll try to get together with my flexbox
dev and give it some additional thinking so if anything
comes to mind as a better solution, we'll discuss it then.
plinss: Okay.
RESOLVED: justify-content: stretch computes to stretch but behaves
like start
Position 'center' and 'page' values
------------------------------------
fantasai: We had a resolution to publish without the page value
and the center value it it had those. Unless someone can
make an compelling argument to keep page we should
republish without it.
fantasai: We should also remove the position: center because we
have more powerful tools in Box Alignment. We should
remove these two and have the position draft be the
CSS2.1 positioning schemes plus sticky.
Rossen: In term of position: center, I don't remember a resolution
to not have it. We discussed as a part of the positioning
spec. There was some excitement on that, I think, but
that's just memory. I'm impartial. I don't think anyone
has implemented currently or efforts toward it.
Rossen: If that's what everybody wants.
fantasai: We don't have a resolution one way or the other on
center.
<tantek> I would like to keep position: center
<tantek> and if there are issues, note the issues inline
<fantasai> tantek, we have centering in css-align
<tantek> ok fantasai - I defer
<tantek> if you're convinced it's just as easy for authors
<tantek> since I'm not as up to date on it
<tantek> I remember the excitement about position:center also
<fantasai> tantek: Think so. If not, file issues against css-align
:)
<tantek> ok fantasai I'm trusting you :)
Rossen: So does anyone care if we keep position: center? The
proposed resolution is to remove position: center
Rossen: So that's nobody. plinss can we record a resolution?
plinss: tantek said in IRC he'd like to keep, but is willing to
defer.
plinss: Anyone else want to keep it?
RESOLVED: remove position: center from Position
Rossen: For position: page I was going off a resolution we
recorded in...[tries to find it]
Rossen: The resolution from Aug 2011, that was the Seattle F2F
Rossen: The last resolution was publish CSS3 Positioning. There's
nothing about removing it.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2011Nov/0709.html
fantasai: Here's the resolution to remove it.
Florian: But page is meant to address same issues as floats,
right?
fantasai: It's related. There was concerns about the way position:
page works.
Rossen: The way I remember that discussion was...A bit of content
is a better name for position: page is position: fragment,
but back then we hadn't worked on the fragment spec yet so
the term was obscure. Essentially the features allow any
fragmentation context on the way to become a positioning
container. So if you have an element that needs to be
positioned, that fragment will be positions.
<fantasai> (fragmentation contexts = pages, columns, regions, etc.)
Rossen: So if that's a page box, the positioning occurs on that
level. That's what the feature was spec'ing. When the
fragmentation, such as the top level scroller, everything
is positioned off of that. That's the same as saying if I
have no other positioning containers on the way to the
root scroller the root scroller is the positioner.
Rossen: We've seen a lot of usage in applications that use regions
and the only way to target the current page for something
like an annotation is to have a way to define the fragment
as the current container. If there's another way to do
that I'd be happy to explore that, but currently I don't
believe we have any.
<BradK> Sounds like a pretty great feature
Rossen: I'm not married to the name, I believe position: fragment
is a more accurate name. We have missing functionality
there that we need to address.
<fantasai> Arron presented a draft for CSS3 Positioning, which
includes CSS2.1
<fantasai> absolute, fixed, and relative positioning, containing
blocks, and
<fantasai> z-index; and that adds:
<fantasai> - 'position: center', in which 'auto' offsets compute
to center the element
<fantasai> - 'position: page', in which the current page box is
the containing block
<fantasai> There were concerns raised that the page positioning
scheme would result in
<fantasai> layouts that broke very badly if the document were
either rendered onto a
<fantasai> continuous (scrolling) canvas, or if it were paginated
differently than the
<fantasai> author's original intent (due to differently-sized
fonts, differently-sized
<fantasai> pages, etc.). Thus:
<fantasai> RESOLVED: Publish CSS3 Positioning as FPWD, without
position: page
<fantasai> (That was the resolution)
Florian: I'm not an expert on this, but it seems like they're all
addressing the same thing. Am I right about this? I know
they don't work the same, but what you apply them to
seems to be the same.
Rossen: Page floats is a, basically 2 separate features combining
to one. They're defining exclusion areas to some element
and we have aspect that does that. The second feature is
how do you position something on the page. This is beyond
page floats, this is a feature that's meant for several
types of fragments.
Florian: But page floats uses page in the name, but it's really
about fragmentainers and positioning.
Rossen: As far as I remember last time I read page floats, it was
all about pages, not about fragments.
Florian: But it's also about deferring to the next column. So if
you have columns and pages it's not a stretch to add
regions.
Rossen: So what if I don't want something to be a float, but I
want to position it. I don't want an element that creates
an exclusion area. Page floats is combining two features,
creating an exclusion area based on the shape you're
defining. It has nothing to do with how you got to the
area.
Florian: I agree it's a difference, but I'm not sure it counts
against page floats. It's agreed that one of the
weaknesses of abspos is it doesn't deal with things
colliding.
Rossen: Which is what you'd want with annotations that are in the
same area.
* BradK thinks Rossen has a good point. Exclusions is already good
as a separate thing. Fragmentainer positioning negates the
need for page floats.
fantasai: Back to the original issue. When the WG agreed to
publish, it explicitly said it shouldn't include this
feature. It was in the minutes and I pasted it above.
There was no resolution later to include this. It should
be removed and the draft republished.
fantasai: If you want to add it, Rossen, you can make a case. The
resolution as it stands and as it should have been
executed is that it doesn't include the feature and it
should not have that feature since that's the consensus.
I want the draft to reflect where the WG stands on these
features.
Florian: I'm cool with that and continuing the discussion on if we
have the use cases covered. fantasai's point seems valid
to me.
plinss: I agree with fantasai but I also agree it's a useful
feature. It does seem like there's some overlap. The float
reference property does seem similar. Let's have a common
underlying approach, but that's more. Proposal is
republish without this property. Objections?
<Florian> +1 to plinss
Rossen: I don't, no.
RESOLVED: Republish CSS positioning without position: page. Also
update the short name.
<BradK> Editors draft will still have it for reference?
<fantasai> old drafts will still have it for reference
<fantasai> that's why W3C has dated drafts :)
<dbaron> (presumably center should also be removed per previous
resolution)
plinss: Anyone will take an action to create a better definition
of position: page?
Rossen: I'll put this on the NYC F2F topics.
Florian: That sounds like something worth talking about. If you
could bring use cases it would be nice.
Rossen: Yeah. I'll have use cases.
Rossen: It would be good to have page float use cases as well.
Florian: Yes.
plinss: I'd like to see proposal to unify them.
Proposal to *not* standardize user-modify
-----------------------------------------
Florian: I've been looking at things that were in very early
versions or things that were implemented a bit but
currently missing. user-modify existed a long time ago,
but webkit and blink implemented it. They currently only
use it to invoke contentEditable and you can just use
contentEditable
Florian: If we have it in CSS it start applying to non-HTML
languages and we don't know how it applies.
contentEditable is useful, but not on this.
<tantek> agree that user-modify is now out of date per current
thinking
<tantek> let contentEditable and Editing discussions handle this
<tantek> we're agreed on this.
plinss: Anyone with other opinions?
Florian: It's not even removing it. It's deciding not to work on
it.
<tantek> like anything else - if the concept is interesting/useful
in the future, people can make a proposal
RESOLVED: no user-modify in CSS UI 4
Weaken upright rendering of horizontal-only scripts
---------------------------------------------------
plinss: koji are you on the call?
plinss: It doesn't seem so.
plinss: Anyone else able to speak to this or should we defer until
we have koji?
plinss: We'll defer.
plinss: I'm out of topics. I think we're done for the week.
fantasai: Does anyone know where chrisL is?
dbaron: I think I saw him at the AC meeting.
<tantek> ChrisL is in Paris
<tantek> yes he was around the AC meeting
<tantek> dbaron is in the conference room, glazou and I are in the
bar
fantasai: okay. I was just wondering.
plinss: Okay. We'll talk next week.
Rossen: One quick question. The one behavior and proposal I was
going to put on the F2F agenda was the zoom property we've
been working on better interop for. I wanted to give a
heads up that this is something we wanted to talk about.
I'll have a spec describing the current behavior, but it
would be great to decide if we want to keep that property
or get rid of it.
Florian: Is it the zoom that's a bit like transforms but effects
layout things?
Rossen: Yeah.
plinss: Also a good reminder that it's a good time to add topics
to the wiki.
plinss: Now we're really done.
Received on Thursday, 7 May 2015 17:27:32 UTC