- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Aug 2018 17:46:01 -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.
=========================================
CSS Overflow 3
--------------
- Though the group resolved on issue #2988 ('overflow' 2-value
syntax is in wrong order) last week, the resolution is raising
concerns and questions on github. Anyone interested should
comment there.
CSS Grid 2
----------
- Interested members were requested to review the proposed changes
to resolving line names in subgrids.
Github: https://github.com/w3c/csswg-drafts/issues/2564
CSS Cascade
-----------
- The security and privacy index edits (Issue #620) are completed so
CSS Cascade will be published based on the resolution made
during the Sydney F2F:
https://lists.w3.org/Archives/Public/www-style/2018Jul/0018.html
CSS Color
---------
- RESOLVED: Cross-fade blends images in premultiplied space
(Issue #2722)
CSS Ruby & CSS Text Decor
-------------------------
- Instead of adding new properties to Ruby and Text Decor to handle
TTML's use case in issue #2998
(https://github.com/w3c/csswg-drafts/issues/2998 )
the group thought it might be possible to handle using a special
case for ::first-line. This proposal will be added to the github
issue to see if this covers the entirety of the use case or if
there's more nuance that would still require additional
properties.
CSS Display
-----------
- RESOLVED: Close this issue (#2947: Reconsider if 'inline-block' and
'inline flow-root' should be syntactically equivalent)
no change.
- RESOLVED: Request CR transition for CSS Display
CSS Align
---------
- Issue #3006 (Mixing baseline self-alignment with random content
alignments) needs a better example before it can be discussed.
Anyone with examples is invited to add them to the github issue.
- TabAtkins completed the proposal for issue #1425: Fully specify
the "Overflow and Scroll Positions" section
(https://github.com/w3c/csswg-drafts/issues/1425#issuecomment-411930443 )
and those interested will review so a resolution can be reached.
Selectors
---------
- The proposal in issue #3012 is to change :visited to remove all
special casing and limit the use cases such that it stops being
able to leak private information. This proposal would remove
some current use cases for :visited so several working group
members needed to discuss with their teams. Additionally, there
were concerns about it violating the GDPR regulations so before
resolving members will also consult with their legal teams.
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Aug/0015.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Garrett Berg
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Theresa O'Connor
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Sean Voisen
Greg Whitworth
Jeff Xu
Fuqiao Xue
Regrets:
Chris Lilley
Thierry Michel
Lea Verou
Scribe: dael
CSS Overflow 3
==============
'overflow' 2-value syntax is in wrong order
-------------------------------------------
astearns: Does anyone have any extra items to add to the agenda?
florian: Not fully adding, but we discussed last week and there was
confusion on a resolution. I'd invite people to look at
#2988.
<florian> https://github.com/w3c/csswg-drafts/issues/2988
fantasai: It's block then inline.
florian: Yes, but that's not was implemented
emilio: We're changing the shorthands the property expands to?
emilio: Like, the longhands. It's way more risky then a tweak to
shorthand. If you access via CSSOM it may break.
florian: Not sure, but not sure we should hijack agenda.
fantasai: I see the problem. For a one value value of overflow
shorthand it has to be assigned to physical longhand. For
two value it has to be assigned to logical. That would not
break anything other then the last 4 months of work.
emilio: Right, but that is not how any other shorthand works
fantasai: We're intending the syntax change to happen, but haven't
decided on it. For margin/border/padding there is intent
to have a switch for if assigning to physical or logical.
background-position is aligned to do this.
fantasai: There are 2 types of values for background position. One
set will assign to physical and the other to logical
<fantasai> https://drafts.csswg.org/css-backgrounds-4/#the-background-position
florian: Why does it make a difference to physical or logical in
case where assigning to long hand?
emilio: Because you can read longhand in CSSOM
emilio: If you read element/style you don't resolve the properties
there
TabAtkins: You don't resolve any...oh, you do shorthands. never mind
florian: I suggest we hash that out on github.
astearns: I'm not sure there's anything we can resolve on. florian
can you take this bit of IRC and put it in github?
florian: Yes. I will do that.
astearns: fantasai and TabAtkins do we do #1 or wait for Oriol?
TabAtkins: Wait.
CSS Grid 2
==========
Resolving line names in subgrids
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2564
fantasai: Just a request for...
TabAtkins: For review from WG
fantasai: The way we resolved these questions there was
clarifications. Line names are passed down and the rest of
the behavior falls out from that. We could add additional
logic to change behavior a little but we felt this was
straightforward.
fantasai: Asking for a look, don't need to discuss unless anyone has
a comment or question.
astearns: Are the possible additions documented?
fantasai: I think in the comments
astearns: Sounds good.
astearns: Take this as a call to look at these changes.
rachelandrew: Read through it and it seemed to make sense to me and
be explainable.
astearns: Thanks
astearns: Anything else?
CSS Cascade
===========
Add Security & Privacy appendix
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/620
TabAtkins: Request for review. Finally wrote one. We're happy with
it.
astearns: Looks like chris looked and thought it was good.
Rossen: We haven't been able to review, but will happily do it.
astearns: Are we at point of publishing?
TabAtkins: I think we are.
fantasai: Yeah, were going to but realized we needed one thing. We
wanted to ask WG to review this one thing before publish.
astearns: Rossen would you rather we wait on publish for you to
review?
fantasai: It's CR for both.
fantasai: CR update.
Rossen: I wouldn't block. We should publish. If we need to make
changes we can republish
<fantasai> resolution to publish from Sydney F2F:
<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jul/0018.html
astearns: Have previous resolution. Would you want an updated?
fantasai: No, I think previous is fine.
CSS Color
=========
"transparent" keyword being a special color value, which resolves to
rgba(0,0,0,0) by default?
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2722
TabAtkins: dbaron thought their libraries did blending already. I
checked, same is true for us.
<TabAtkins> https://drafts.csswg.org/css-images-4/#cross-fade-painting
TabAtkins: Given that, I edited the spec ^
TabAtkins: Spec blending of cross-fade is done premultiplied space
so transparent parts of images work as expected
TabAtkins: Any further opinions let me know else this is what I'm
going with.
<smfr> seems fine
TabAtkins: And I'm most of the way through cross-fade edits from
last F2F
astearns: smfr says seems fine. Other opinions?
astearns: TabAtkins want a resolution? Or publish and get feedback?
TabAtkins: Get resolution to end thread. Cross-fade blends images in
premultiplied space
astearns: Objections?
RESOLVED: Cross-fade blends images in premultiplied space
FXTF
====
Filter should be defined to establish a containing block for fixed
and absolutely positioned elements
------------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/11
astearns: chrishtr added this to agenda. Is chrishtr on?
[silence]
TabAtkins: I'll make sure he's on next week
CSS Ruby & CSS Text Decor
=========================
Add over-most-under-last value to ruby-position &
text-emphasis-position for captioning
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2998
astearns: fantasai added to agenda, updates by Nigel
fantasai: The overall question was to add new value to ruby position
property to handle ttml behavior. First line has ruby on
top, second on bottom. 3+ lines they're all on bottom.
Question from WG is do we add it. There's details on how
to segment text, block, line breaks, etc?
astearns: Is there a use case for changing behavior based on forced
line break?
fantasai: Use case is for captions, don't know what markup looks
like. Guessing not on forced line breaks.
dbaron: I can see why it's useful for captions, but feels hard to
implement for general case. What's previously local now
needs bigger area.
florian: Solve by special case first line and having first line be
over and rest under?
florian: Since use case is for 2 line what we do for not 2 lines is
error driven by use case so might as well do simple thing
florian: Then again why can't use first-line pseudo
astearns: First-line pseudo is interesting idea. Gets functionality
for block. Do first lines deal with blocks?
fantasai: Only with first line of not anonymous block
astearns: Then first line gives us what ttml looking for
fantasai: I think so. Don't know nuances of what they're looking for
astearns: Leave it as a question in the issue? Ask if we can let
them do this using first line
fantasai: Alright.
florian: Need to make it explicit that this applies in first-line
pseudo.
fantasai: Have to check pseudo spec. And we can add example in ruby
module to show this behavior.
fantasai: I think we need to call it out, not really clear. Have to
add it explicitly.
astearns: Possibly ttml people considered this and rejected so good
to get their feedback on idea
fantasai: Proposed resolution: add ruby position to properties
applying to first line, respond to ttml suggesting we use
first line for this behavior and check if it's a problem
astearns: It just came up, could get shot down as soon as it's on
the github issue. Not looking for resolution at this point.
fantasai: We have a proposed resolution and asking for feedback.
astearns: We can come back next week.
CSS Display
===========
Reconsider if 'inline-block' and 'inline flow-root' should be
syntactically equivalent
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2947
<dbaron> is Oriol on the call or just on IRC?
<Oriol> Just IRC
astearns: Thanks Oriol
astearns: Hopefully he can follow along in IRC and we can resolve
this
fantasai: The question was...this was raised by Oriol. We had
discussed in the past that we should have inlineblock and
inline-block have same behavior
fantasai: I don't remember subtleties. TabAtkins? If you blockify an
inline-block it turns into display:block it's an inline
flow-root.
<AmeliaBR> From issue: However, in #2673 it was resolved that
blockifications and establishing FC are independent. This
means that a future feature which only blockifies would
make inline flow-root and run-in flow-root end up
generating a block container with no BFC.
fantasai: If you remove inline and swap with block you get bfc. When
you blockify inline-block it's not a bfc due to compat.
fantasai: We made inline flow-root blockify same as inline-block
because we wanted them to compute to same. But when you
blockify either you lose block flow-root ness. Oriol
suggested revert and make them distinct where they're same
but when blockfiy inline flow-root it's different
<Oriol> Exactly
florian: Clarify. When we invoke blockification we'd also invoke
flow-root so it's not observable except in terms of OM?
fantasai: If you blockify...
TabAtkins: Only exception is subgrid so far. That's not relevant
here. When we blockify something that can be inline we
flow-root it as well.
TabAtkins: Not that inline flow-root is implemented yet so that's
not observable.
<Oriol> But can become observable in the future, and then it will be
too late to change CSS Display
florian: I was initially tempted by Oriol's proposal because cleaner
theoretical architecture. Seems to me now it's adding more
complexity then needed.
florian: To clarify a bit more, request is to have the behavior we
want on inline flow-root and therefore force undesirable on
inline-block. We can't have both due to compat.
Theoretical nice design is overshadowed by the creation of
2 distinct behavior despite no use case for the difference.
<TabAtkins> Florian's statement is a concise statement of my own
position
<dbaron> There was another reason this came up, but I've forgotten
what it was...
astearns: Other opinions?
dbaron: This came up in another discussion. Trying to remember what
that was.
astearns: subgrid?
dbaron: Don't think so. I'm okay with it
dbaron: Something else where I wanted it the other way.
<fantasai> dbaron, were you thinking of the earlier discussion
triggered by
https://github.com/w3c/csswg-drafts/issues/1246#issuecomment-313211986
?
astearns: fantasai has a possibility
dbaron: Don't remember if that was it
astearns: As I understand trade off is keeping simple for now vs not
being able to use flow-root nature distinct from
inline-block for some future thing not yet known
astearns: So may be painting into a corner
florian: Goal is not to have distinction, goal is to not have
inline-block constraint. We'd rather have the other
behavior but we can't have just that so the proposal is to
have both.
astearns: Proposed resolution: close no change
astearns: We've done that before.
florian: Used to side with Oriol but no longer. Prefer no change.
astearns: Oriol are you okay with the proposed resolution?
<fantasai> or have anything to add?
<Oriol> I guess it's OK for now, but once multivalue display is
added it will be too late to change in case later in the
future a feature that blockifies without BC is added
astearns: Does anyone have reservations based on Oriol's comment?
florian: Inline-block is odd in that it's a flow-root that doesn't
show in OM. We can do it later in terms of layout even if
not in OM. Will not have perfect correspondence. Given that
is lost and we do want 2 FC we can later since it's not
observable right now. We could revert it later.
astearns: Other comments?
astearns: Objections to close this issue no change?
RESOLVED: Close this issue no change.
Publication
-----------
<fantasai> https://drafts.csswg.org/css-display-3/issues-wd-2017
fantasai: That's last issue in DoC.
fantasai: Do we want to take to CR?
<florian> YES! CR CR CR :)
<fantasai> lol
astearns: Objections to requesting CR transition for CSS Display?
<tantek> +1
<TabAtkins> Nice 👌
RESOLVED: Request CR transition for CSS Display
fantasai: I'll work with chris for publish
CSS Align
=========
Mixing baseline self-alignment with random content alignments
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3006
TabAtkins: I just commented in issue. I think maybe just confused.
How can you mix baseline self alignment with any other.
Baseline cares about your height. Seems odd how it
interacted. Now that I thought about it you have to do
layout before self align so it's not a problem to do
content alignment first and if you do center baseline is
in center of element.
TabAtkins: So I think this is close invalid.
florian: Is there no risk of a dependency between sizing and placing
things? When you align on baseline can that cause things to
grow? Or does that problem not exist?
TabAtkins: Good question. I should consider that further.
florian: If that's okay, we're okay. If not we have a problem
fantasai: What you say makes sense if item itself has a size. You
can align and then baseline align. Trickier thing what if
it's sized as auto and that auto size is not purely shrink
wrapping around content.
fantasai: Where that box is positioned can change size of alignment
container and then change alignment of content.
TabAtkins: Can we table for a full example? Example in issue isn't
complex enough to show problem.
astearns: Okay, we'll come back with a more complex example
fantasai: And anyone with examples, let us know.
Fully specify the "Overflow and Scroll Positions" section
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1425#issuecomment-411930443
astearns: Edits have been made.
fantasai: Wanted to call attention to things trying to fix
<fantasai> https://drafts.csswg.org/css-align/#overflow-scroll-position
fantasai: This section is about when you have a scroll container and
it has align content so you center all the content in the
box in the box. When you have a scroll container we
decided that rather than ignore alignment or align content
to the end and overflow to the top we wanted to make it so
you could read the content and be able to scroll to it.
That meant moving content down and show as if end aligned
TabAtkins: Almost same as aligning scroll thumb in scroll track. Not
quite same. Some content alignments because way some
browsers discard padding means it would normally be
impossible to achieve same layout wither if
overflow:scroll or not.
TabAtkins: Have a bit about mandating you provide enough padding to
match. Also helps solve issue that people want block-end
and inline padding. We say if you use content alignment
you get the padding. That makes all padding work as
expected.
florian: Does that solve the legacy or do we have too many legacy
behaviors?
TabAtkins: Still not sure what legacy should be. Lets us have the
good behavior so we can solve legacy separately.
florian: Fair enough.
astearns: dbaron, you've been in this issue, have you looked at
latest edits?
dbaron: I don't think so
astearns: Leave this as please everyone take a look and we come back
next week to resolve?
TabAtkins: Yeah.
Selectors
=========
Solve :visited once and for all
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3012
TabAtkins: Over weekend there was a new attack on :visited using
houdini api for timing channel attacks. Apparently
chromium is mitigating by disallowing paint on links.
This isn't great. dbaron had proposals to reduce
bandwidth of channels. I think we should solve this.
TabAtkins: This is leaking history information. I suggest we limit
what is exposed to the page to things it can have
observed and then we can make :visited an ordinary pseudo
class
TabAtkins: Same origin pages visited are visible. Links that have
navigated into your origin so that could be exposed.
Finally any links that are visited from your origin are
observable through a number of channels. That's the basis
of the entire ad industry. That's reasonable to expose
TabAtkins: I think that gives you all the usefulness of :visited but
limits privacy to things where we've already lost the
battle. Only thing we're losing is things like "cool
links of the week" pages won't be able to tell you've
visited it before. Most cases are links you've visited in
the same origin or in search. That's preserved
TabAtkins: Concerns by Mats that the sort of tracking from the 3rd
case with outbound links may violate GDPR. I can't
comment on legal issues. I've reached out to our lawyers.
In the meantimes, does this seem reasonable? It this
promising area to push, turning :visited back into a
normal pseudo class?
<AmeliaBR> One addition to Tab's comment: All of this
origin-specific history data would need to be tied into
the ability of users to clear their cookies etc.
dbaron: I think Mats wants both sets of restrictions. Adding what
you propose without removing existing restrictions.
TabAtkins: That would add a lot of complexity and not give people
anything useful. Reduces information leakage, but I'd
like to get all the way over the finish line
<smfr> I think we’ll need to talk about this internally at Apple
before we can give an OK to breaking link coloring for “links
of the week” pages; that seems like a serious usability
regression
<fantasai> What are the new restrictions?
<fantasai> I can't tell from the minutes
astearns: New restrictions. I think it's that :visited only applies
to a certain subset of links that follow the restrictions
TabAtkins said
TabAtkins: Any same origin is visible. Page navigate into origin or
pages navigate from origin and out to. That's all
observable already
fantasai: So when a browser records if something is in history it
also needs to see where you clock...you visited w3c and
you have to record everywhere that I came in from as well.
All the ways I clicked to it from would all be recorded
together.
dbaron: Simpler way to think about it. What you're doing is you're
keeping separate history for each origin.
TabAtkins: It's per origin not per page. Yes. Separate history
database, basically
astearns: smfr responded on IRC [reads]
TabAtkins: It would eliminate that use case, yes. That's the major
casualty.
astearns: He says they'd have to talk internally before giving an
opinion.
TabAtkins: Okay.
astearns: Other objections or reservations?
astearns: I'm not convinced, personally, but don't have an objection
to investigating.
TabAtkins: Anyone reviewing with teams, when weighing please do so
against the current status quo where you can basically
just do link coloring. And there will always be timing
channel hacks in the current but this would stop that
entirely. Benefits of killing status quo are reasonable.
Make sure you weigh that against losing particular use
cases
dbaron: I think always going to be timing channel attacks is a bit
strong. I think there are fixes
TabAtkins: So we can make repaint always observable?
dbaron: No, you always repaint no matter if you visited
TabAtkins: Doesn't stop user interaction based
dbaron: Other trade off is some browsers double key the cache. They
may have different trade offs
astearns: We're at the hour. Sounds like people are interested in
discussing so let's continue in the issue.
astearns: We still have a bunch of agenda F2F issue. Some have been
around for a while. I'm planning on going through that
list and pinging for update before put on weekly agenda.
astearns: Thanks everyone for calling in, we'll talk next week.
Received on Wednesday, 15 August 2018 21:46:59 UTC