- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 31 Aug 2016 20:38:34 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
TPAC
----
- A reminder that the registration closes and registration fees go
up soon.
- gregwhitworth will likely be the one to speak at the dev meet-up
and he'll cover topics around Grid.
Synthesized baselines seems like a breaking change
--------------------------------------------------
- The behavior of what we do when there isn't a natural baseline
is inconsistent both between specs and between implementations.
- The proposals of what to standardize around were:
A. Make boxes without a natural baseline and boxes
establishing an orthogonal flow synthesize a baseline.
A.1 Base this synthesized baseline on the margin box edges
A.2 Base this synthesized baseline on some other box edge
B. Make boxes without a natural baseline and boxes
establishing an orthogonal flow use start alignment
instead of trying to synthesize a baseline.
C. Something else.
- RESOLVED: Accept option A2 with the modification that we're
talking about the border box.
Add <number-optional-number> type
---------------------------------
- Several people had reservations on adding a new syntax (+#) to
make it easier to read a legacy behavior that could still be
written as [ <foo>+ ]#
- RESOLVED: Don't add any new syntax, just add a note explaining it.
Algorithm of `Element.offsetParent`
-----------------------------------
- RESOLVED: Adopt the Gecko/Edge behavior and specify that
.offsetParent is based on the nearest abspos
containing block or table cell
Media Queries
-------------
- RESOLVED: Accept the proposal (Proposal: Make the
device-width/etc MQs use the same concepts as CSSOM is
using for returning device dimensions.)
- The group began discussing adding device-pixel-ratio but didn't
have time to reach a decision
- One opinion was that it shouldn't be added in order to
encourage people to use 'resolution'
- The other opinion was because '-webkit-device-pixel-ratio'
didn't obviously translate to 'resolution' 'device-pixel-
ratio' should be added to aid authors.
- Right as conversation was wrapping up, smfr asked a question
about 'window.devicePixelRatio' which he was asked to post
on github to allow further conversation.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Aug/0086.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Simon Fraser
Daniel Glazman
Dael Jackson
Brian Kardell
Brad Kemper
Peter Linss
Myles Maxfield
Thierry Michel
Michael Miller
Edward O'Connor
Simon Pieters
Anton Prowse
Matt Rakow
François Remy
Florian Rivoal
Andrey Rybka
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Rachel Andrew
Jen Simmons
scribe: dael
TPAC
====
Rossen: Let's get started.
Rossen: Hello everyone.
Rossen: Any additional agenda items to bring forward?
fantasai: Is the grid baseline issue on there?
Rossen: It is.
Rossen: It's the first one on the agenda.
glazou: A reminder about TPAC. Registration fee is about to
increase and registration will soon close.
glazou: If you haven't it's good to do ASAP.
Rossen: Good point. Also please continue to add agenda topics.
Bert: Is the dev meetup on?
Rossen: I might have missed it. Let's start there.
Bert: Can we propose someone to speak at the dev meeting on the
Monday evening of TPAC?
Rossen: Does it need to be 1 person?
Bert: It's 15-20 minutes. It could be more. We can all go, it's
just the talk is short.
Bert: Do we have an interesting topic and someone to deliver?
Rossen: There were proposals on the private list. One from
astearns about the talk on the CSSWG and call for help. I
proposed grid and volunteered gregwhitworth who can do a
shortened version of the Sydney talk.
Rossen: One is more process/PR and the other more technical.
Rossen: I'm happy with either.
Bert: I think grid would be interesting if gregwhitworth is
available.
gregwhitworth: Sure.
gregwhitworth: I'll need to update it, but I can try to shrink it
down.
Bert: I'll connect you with Gerome who is in charge of the talks.
Rossen: Anything else on this?
Bert: Nope. Reminder charter review ends soon and we need more AC
reps and companies to review. If yours hasn't, please do so.
We have 2 days.
Rossen: Great reminder. Please update your AC rep and have them
respond.
Synthesized baselines seems like a breaking change
==================================================
fantasai: I'm having connectivity issues, but the summary is in
the link.
fantasai: The basic issue was that for writing modes...right now
the behavior of what we do when there isn't a natural
baseline is inconsistent. Implementations don't agree,
specs don't agree. There were several options presented.
I'd like a resolution.
Rossen: One comment...I've edited your comment to say Edge matches
Chrome so there's a bit of interop between Edge and Blink.
fantasai: Okay
fantasai: Just want comments. Does anyone need more explanation?
What's helpful here?
<Rossen> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4416
Rossen: I think a good way to move forward, I'll paste the example
and people can look.
Rossen: I think it's concise and to the point.
Rossen: Are people reviewing? Or are we waiting for someone to
talk?
Rossen: I think fantasai could elaborate on concerns and proposals.
fantasai: Is jensimmons, rachelandrew, or leaverou on the call for
an opinion?
[they aren't]
fantasai: We have a couple of options. 1 is make boxes without a
natural baseline synthesize one. 2) If there's no
natural we use a fallback. If you use a fallback the
author could have gotten that from defining it on the
item instead of synthesize.
fantasai: If we synthesize we have to decide if we do it on margin
box edge or another box edge.
Rossen: Reading your comments and looking through this I agree we
want consistency. If we synthesize it better be the same.
fantasai: I agree.
Rossen: If we make the...align with the inline model so based on
the margin box...that is the more interesting topic we
should decide on. I'm not sure margin makes the most sense
for grid. Border may make more sense as it gives you visual.
fantasai: I have no opinion on this.
Florian: Sounds reasonable on the face of it.
Rossen: What do people think? Other opinions?
Rossen: Do we pick one of fantasai options?
Rossen: I prefer A2 which is they're synthesized based on the
border box edge.
frremy: I agree.
Rossen: So we have some votes for A2.
<tantek> I have been trying to read and understand this issue.
<tantek> A2 with border-box seems reasonable.
Florian: Weak agreement.
<Florian> (as in: I agree, but I haven't thought about it for very
long)
<SteveZ> I agree that visually border box makes more sense, but in
inline the alignment is on margin edge so the result
would differ inline and across grid areas
Rossen: What I'll do because I want to move the conversation
forward and it's holding Grid spec up I'll list the options.
Rossen: I'm hoping we can get resolution on one.
<Rossen> A. Make boxes without a natural baseline and boxes
establishing an orthogonal flow synthesize a baseline.
<Rossen> A.1 Base this synthesized baseline on the margin box edges
<Rossen> A.2 Base this synthesized baseline on some other box edge
<Rossen> B. Make boxes without a natural baseline and boxes
establishing an orthogonal flow use start alignment
instead of trying to synthesize a baseline.
<Rossen> C. Something else.
fantasai: bradk just joined. Do you have an opinion?
bradk: I just joined.
Rossen: We're talking about if we should synthesize baseline for
grid or flex with orthogonal flow and ones with no inline
content. If we do synthesize do we use margin box, border
box or something else
Rossen: I posted the options and we're trying to narrow down.
Currently there's synergy around A2.
<fantasai> bradk:
https://github.com/w3c/csswg-drafts/issues/373#issuecomment-242863486
SteveZ: Two comments. 1) inlines align on margin box and so you
get some interesting things from alignment inline vs row
or flexbox. I'm not sure that's important. 2) if you use
margin edge you can use big margins to adjust alignment
and get centering with a bit of playing
Rossen: That's a great point. I would argue the opposite. I
wouldn't try and align grid and flex with inline in that
respect since alignment and role distribution and sizing
are all dependent on the sizing of the items and it
doesn't matter for inline.
Rossen: So for both complexity and interdependences I would argue
the opposite.
<tantek> steve makes a good point about potential utility of
negative margins
<fantasai> tantek: yes, it was mentioned in my writeup. Along with
some problems with it
<fantasai> tantek, One problem is that negative margins will cause
overlapping with subsequent content -- this is less of
a problem with inline layout because of the struts
<tantek> fantasai, ok. I don't have strong feelings about it.
<fantasai> tantek, Another consideration is that the
'alignment-baseline' property can give control over the
alignment point of synthesized baselines
<fantasai> tantek, and a future property is on the radar for even
more control
bradk: Would you want to align with table cells? How they align?
Rossen: I think they use border box or content box.
Rossen: I think gregwhitworth and frremy were looking into table
cells
bradk: I don't have a strong opinion.
Rossen: So bradk if you don't have strong opinions
fantasai: table cells align content box
Rossen: They're wierd.
<tantek> fantasai - does A2 with border-box seem reasonable to you?
<fantasai> tantek, yeah. Assuming the baseline controls, it's
likely the best solution.
<tantek> ok
<fantasai> without those controls, it's less clear...
dbaron: A bunch depends on what there are use cases for and what
can happen in another way. There's a bunch that can be
accomplished by using a non-baseline alignment. There's a
bunch that can happen from making it a inline block inside
a grid cell. Part of what's not clear to me is what are
the use cases that you can't do in another way and what
are people trying to do
Rossen: There's already a bunch of alignment options to center.
People use - margins in the inline is because they don't
have other ways to center align. I'm with dbaron to allow
all the other alignment options work itself and the
baseline is a baseline.
Rossen: The other comment on the table cell alignment model,
that's weird because usually borders are on the table grid
level and shared between table cells. That's why there it
makes sense to align on content box
fantasai: Table cells do content alignment instead of here we do
self alignment. Conceptually it's do you move the
contents or the box. So they will necessarily be
different cases.
fantasai: I'll throw in my hat for align on the border box. There
are cases you might want items to align to each other.
Border box is the visible part of the box and the margin
doesn't provide that visible piece. Reason for margin is
you can adjust the alignment point, but we have controls
like alignment-baseline that let you determine that
alignment point.
fantasai: Those controls effect how the baseline is synthesized.
Also SteveZ pointed out for inline we'd need more fine
controls and that's something that we could apply here
as well.
<Rossen> +1 to everything fantasai said
<gregwhitworth> sounds like it's border box then
fantasai: So I'm leaning toward border box option because that's
more in the spirit.
fantasai: Also in flex and grid using a negative margin to adjust
the alignment point can cause overlapping content.
fantasai: Anyways, that's what I'm thinking.
Rossen: I agree with fantasai.
frremy: Are we sure we do content box on table rows?
frremy: I'm not sure what's what we do.
fantasai: We're sure
<fantasai> *of course* they align on the content box; if they
didn't the borders wouldn't align across the row!
<fantasai> if you put inline-level content *inside* the table
cell, then that will align on its margin box
Rossen: Are you asking what implementors do now?
frremy: Yeah.
Rossen: Currently there is Edge and Chrome align on synthesize
baseline based on margin box. Firefox seems to align on
border box.
Rossen: Or maybe margin box.
Rossen: There's no interop at the moment. Given there's no perfect
interop and we have a model that makes sense and is easy
to explain and seems obvious we should try and resolve and
clean up the spec and allow implementors to follow up.
Rossen: To move forward, proposal is: resolve on option A2 with
the modification that we're talking about the border box.
Rossen: Objections to specifying that [reads option a2]
RESOLVED: Accept option A2 with the modification that we're
talking about the border box.
Add <number-optional-number> type
=================================
Rossen: Who wants this one?
Rossen: TabAtkins?
TabAtkins: We skipped this last week, right?
TabAtkins: Basic option is to make the grammar clearer on how to
handle weird SVG behavior, particularly where there are
optional commas. For single we're fine, but for
arbitrary lists you can't quite mark it. You could use
+# as a stacked combinator, but that's not technically
possible. Proposal is to add it to the grammar and link
to SVG but mark it as shouldn't be used and it's legacy
Florian: Any drawback to that?
TabAtkins: Not that I know of.
dbaron: Draw back is another symbol for people to learn and read
about.
TabAtkins: Yeah. A combo of two symbols. Hopefully with the
linking to a definition no one is using it.
Bert: I'd prefer not to add a new symbol, but I'm not strongly
against.
TabAtkins: It's combining two existing combinators in a way that's
technically not possible right now.
<TabAtkins> <foo>+#
Rossen: So any other opinions?
* fantasai doesn't have a strong opinion on this
myles: I weakly prefer that if we can do this with existing
grammar something new doesn't need to happen.
<TabAtkins> <foo> [ ,? <foo> ]*
TabAtkins: I just put in how to write it without this.
TabAtkins: It's that odd doubled grammar thing that we tried to do
away with by introducing #. It looks pretty hefty.
<fantasai> [ <foo>+ ]#
* Bert prefers with the [] as fantasai did
myles: Looks fine to me. I don't think we need something new.
Florian: It parses right but implies a different tree?
TabAtkins: No. Only difference is collapsing it so + and # are
next to. It's only because we say combinators are only
for non-terminals.
fantasai: I think you mean we can't stack multipliers.
TabAtkins: Yes.
TabAtkins: Or rather we can't do it directly. We can do it with
the indirection of a square bracket.
fantasai: I don't care either way.
<bradk> [ <foo>+ ]# seems clear enough to me
<astearns> I think [ <foo>+ ]# is fine
<frremy> should we vote, then? yay, nay, don't care?
Rossen: There were at least a couple of people preferring not to
have it and a couple of people who don't quite care but
wouldn't mind adding it.
Florian: And since it's legacy only thing maybe adding new isn't
that important.
TabAtkins: Then I'll probably still want to add a non-normative
bit about the [] pattern thing. I'll want some
indicator that this pattern has a particular meaning
that's slightly different than what it seems to indicate.
<astearns> +1 to clarifying note
fantasai: I have no problem with a note. I might have comments on
the wording, but a note is a good idea.
<Florian> +1
<zcorpan> [ 1+ ]#
<TabAtkins> (The specific meaning is that [ <foo>+ ]# seems to
mean "a comma-separated list of space-separated
things", but in SVG it just means "a list that can be
separated by spaces or commas".
fantasai: Proposal is add a note explaining the syntax, but don't
add anything.
Rossen: Sounds fine. Can we resolve on this? TabAtkins do you have
a problem with that?
TabAtkins: Not enough to object.
Rossen: Any objections?
RESOLVED: Don't add any new syntax, just add a note explaining it.
<Rossen> https://github.com/w3c/csswg-drafts/issues/332
Rossen: We covered #3 as a part of #1
fantasai: I don't think there's anything else there
Algorithm of `Element.offsetParent`
===================================
<Rossen> https://github.com/w3c/csswg-drafts/issues/409
Rossen: Anything new on this we need to talk about?
Rossen: I think that was Florian?
Rossen: Or maybe smfr.
zcorpan: It was me.
zcorpan: There were interop problems and it would be good to
decide what we want the API to do. Most people prefer
Gecko from the comments: matching containing block for
abspos descendents. That's not what the spec says. If you
have a non-none transform that has a containing block it
doesn't affect .offsetParent
dbaron: In some or all implementations?
zcorpan: Some. It does affect in Gecko. Not in Blink or Webkit.
frremy: It does in Edge. We're like Firefox.
zcorpan: I suggest we align with Edge and Gecko.
smfr: My comment is I agree it's good to standardize, but the
guarantee for authors is you can walk up the chain, pop an .
offsetLeft and compute. I think it's essential that you can
compute a position.
zcorpan: .offsetParent also picks up things like table cells which
is a quirk in the API.
dbaron: Presumably what smfr said will hold if .offsetTop and
.offsetLeft are relative to the .offsetParent.
zcorpan: They are in the spec.
smfr: I don't think they take transforms into account.
zcorpan: Spec says transforms are ignored for .offsetTop and
.offsetLeft
<bkardell> that is my recollection as well from some recent use
smfr: Do any implementor have feedback on compat issues?
Rossen: We haven't made changes since IE8. I would expect that
those are used a lot.
Rossen: So changing them will potentially have compat risks.
smfr: Right. And I think Blink has changed since webkit fork. So
I'd like feedback from blink if they saw compat issues.
TabAtkins: I'm not sure. We'll have to investigate.
smfr: Actually I'm not sure they've changed.
Rossen: So TabAtkins can you verify if you've changed?
TabAtkins: Yeah.
<smfr> looks like blink added checks for tables and table cells
Rossen: So I think there will be some compat risk for whomever
changes. So we'll have to evaluate that and minimize the
damage by spec whatever we need to spec.
Rossen: At the same time if there are differences, especially
between Blink and Webkit, that would be a good indicator
people don't rely on this.
<smfr> oh, no, they just moved code around
Rossen: I don't believe we're ready to resolve.
zcorpan: What do we need to resolve. Do we need to talk to a
browser shipping something else? More opinions?
Rossen: We'll have to have a clear spec as to what is expected, as
to what the exact rules are for .offsetParent so everyone
can compute the same. And then ID the compat issues.
Rossen: There will have to be changes for someone. Last week I
started writing a quick list of rules that we use for Edge.
Once I'm done I'll add it to the issue and we can go from
there. And it would be great if you can outline something
similar from other impl. zcorpan posted a link to source
code which not everyone can look at.
smfr: Webkit would be willing to change behavior if we have a good
spec soon. It's early in our release cycle.
Rossen: So zcorpan do you have currently proposed text or a
different proposal than the spec?
zcorpan: Proposal is to change the spec to make .offsetParent
return the ancestor that's the containing block of the
abspos parent.
Rossen: Did you say the nearest ancestor for abspos element or
simply the containing block of the element and if it has
to be abspos.
<bkardell> just absolutely positioned, or relatively too?
<zcorpan> "return the first ancestor which is a containing block
of absolutely-positioned descendants"
zcorpan: Doesn't matter what the element itself is. Nearest
ancestor that's a container for an abspos element, even
if there isn't one.
Rossen: And there's the quirk with table cells?
zcorpan: Yeah, that's still there.
Rossen: And smfr you said you'd be willing to try this out?
smfr: Yes.
Rossen: Does anyone object? Chrome people?
Rossen: TabAtkins?
TabAtkins: I'm fine.
zcorpan: I spoke to rune and mårten from Opera and they preferred
Gecko. They're likely not aware if it breaks the web.
Rossen: Let's move to a resolution and we'll find out from webkit
impl experience and see what compat looks like. Sound
okay? Objections?
RESOLVED: Adopt the Gecko/Edge behavior and specify that
.offsetParent is based on the nearest abspos containing
block or table cell
Media Queries
=============
device-width media feature and privacy
--------------------------------------
Rossen: I believe most remaining topics are Florian's. Order
preference?
Florian: First is quick.
<Rossen> https://github.com/w3c/csswg-drafts/issues/426
Florian: Maybe zcorpan can say more, but there's a change in OM
View where various places that refer to the size of the
screen are a problem. There's no great use cases, but it
leaks private info. In order to allow browsers to hide
that anywhere that you're supposed to give a screen
measurement you can do the exact measurement or another
measure.
<zcorpan> the other thing is indeed the viewport
Florian: In the MQ spec where we have ones that refer to screen
size we propose we allow either the screen or the new
area. It doesn't force a change, but it allows browsers
to provide more privacy.
<zcorpan> https://drafts.csswg.org/cssom-view/#web-exposed-screen-information
Florian: They're deprecated, but we have to support them.
TabAtkins: I strongly agree with this.
Rossen: How does this align with screen object?
Rossen: zcorpan?
Rossen: The screen available width and height may return different
values?
zcorpan: Other way around. CSSOM View spec says now that
screen-available-width or screen-width you can do what
browsers do today or return size of the viewport.
zcorpan: For not device-width leaks screen size.
Florian: By using the same term browsers switch both or neither.
Rossen: That's fine. For browsers in full screen it'll evaluate to
the same. I don't have a disagreement.
TabAtkins: We're not looking for the OM change, we're looking to
make these things do the same thing.
Rossen: So do we have a summarized proposal for resolution?
Rossen: Any objections to the proposal?
RESOLVED: Accept the proposal (Proposal: Make the device-width/etc
MQs use the same concepts as CSSOM is using for
returning device dimensions.)
Consider making device-pixel-ratio a standard alias
---------------------------------------------------
Rossen: Anything in 2 minutes?
<Rossen> https://github.com/w3c/csswg-drafts/issues/417
Florian: We have resolution MQ that use to be under a prefix.
Gecko has/will implement both resolution and
-webkit-device-pixel-ratio, but they find it distasteful
to have -webkit only, so they're considering
device-pixel-ratio. This is just so that we have
unprefixed as well as prefixed. I say don't because
unprefixed is resolution.
MaRakow: I agree with Florian. We haven't seen this in the wild
and if we're trying to push authors we should move to
resolution. Pressure is in one direction and fragmenting
to two is detrimental.
dbaron: I tend to think there's a lot of mind-share to
device-pixel-ratio and so resolution doesn't make sense
for what people want to use.
<zcorpan> there's also window.devicePixelRatio,
https://drafts.csswg.org/cssom-view/#dom-window-devicepixelratio
<tantek> so basically, "resolution" lost the bike-shedding battle
in the market
hober: There's no disagreement from me that the name 'resolution'
is bad
Florian: It's out there so I don't think dropping resolution is an
option.
<bkardell> it seems like an alias is easier for authors
Rossen: Do we believe we can resolve? We're top of the hour
Rossen: One proposal is to drop -device-pixel-ratio.
Florian: Reject proposal to add it.
Rossen: Would people object to that? Especially people from Gecko?
<tantek> flip the proposal around since the intent is to implement
device-pixel-ratio
<tantek> that's the question for which it should be asked if there
are any objections
dbaron: I'm pretty uncomfortable not simultaneously implementing
the same thing unprefixed.
Rossen: We have a bunch of those.
Florian: Isn't that the same as doing -webkit gradient where we
have old webkit syntax or the new syntax and they're not
the same
dbaron: From the names people can figure out what the new one is.
Florian: Yeah, true.
<tantek> the problem is that "resolution" is a crappy name, and
has no easy discover-ability from -webkit-device-pixel-ratio
smfr: Question on resolution. Does it change under page zoom, or
is it capabilities of hardware?
Florian: I don't remember, but it's the same as prefix.
smfr: We've got this difference with window.devicePixelRatio. It
seems to me that window.devicePixelRatio and the resolution
MQ should be the same.
dbaron: I think a bunch is not interoperable.
myles: I think it's time.
Rossen: We are at top of hour. I propose we leave this for next
week and we can continue on github if people have opinions.
Florian: smfr can you bring your question to github?
smfr: Sure.
Rossen: Remember to register for TPAC if you haven't. Talk to you
next week.
Received on Thursday, 1 September 2016 00:39:35 UTC