- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 1 Mar 2017 21:31:17 -0500
- 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.
=========================================
Percentage [max-]width|height and intrinsic sizes
-------------------------------------------------
- dbaron will review and comment on the issue.
What are "form controls"? / Define interaction of display:contents
and replaced elements
------------------------------------------------------------------
- The topic of "what are form controls?" was deemed too large and
undefined to take up telecon time right now, but the smaller
issue around display:contents could be addressed.
- There were three proposed solutions:
1) Treat all the types as stripping off the one box.
2) Treat all of the types as doing display:none when you do
display:contents.
3) Do display:none on form elements and box stripping on
others.
- RESOLVED: Have display:contents treated as display:none for
replaced elements and form controls.
Use flex-order first or document-order first item's baseline?
-------------------------------------------------------------
- RESOLVED: Take the visually first line when considering baseline
alignment in flexboxes.
Percentage [max-]width|height and intrinsic sizes
-------------------------------------------------
- gregwhitworth was actioned to check web compat on fantasai's
proposal (captured here: https://github.com/w3c/csswg-drafts/issues/765)
abspos flex/grid item "align-self: auto behaves as start" spec-text
is too vague
-------------------------------------------------------------------
- RESOLVED: align-self:auto and justify-self:auto still look at
parent's align and justify items for abspos when
calculating static position only.
Renaming stroke-* in paint
--------------------------
- smfr indicated Apple's intent to implement fill and stroke, so
TabAtkins and fantasai will put a high priority on making the
Paint spec ready for a FPWD.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Mar/0000.html
Present:
Rachel Andrew
David Baron
Bert Bos
Bogdan Brinza
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Ian Kilpatrick
Chris Lilley
Peter Linss
Myles Maxfield
Michael Miller
Anton Prowse
Liam Quin
Melanie Richards
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
Vladamir Levantovsky
Simon Pieters
Scribe: dael
Use flex-order first or document-order first item's baseline?
-------------------------------------------------------------
astearns: Tab you were looking for interop?
TabAtkins: I didn't do that yet.
astearns: Then let's table.
<fantasai> I think more than interop, need to consider logic
<fantasai> commented in bug
<fantasai> Proposal is in the last comment
<fantasai> need WG approval to try something that's not interop
but more sane
<fantasai> astearns, ask if there's any objection to last comment
in first issue?
<fantasai> astearns, in which case we can resolve it
Percentage [max-]width|height and intrinsic sizes
-------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/765
astearns: dbaron, you were volunteered to talk on this.
dbaron: I'm not sure how ready this is for telecon. I missed the
proposal on the issue.
astearns: Can I action you?
ACTION dbaron comment on the percentage [max-]width|height and
intrinsic sizes thread
<trackbot> Created ACTION-833
What are "form controls"? / Define interaction of display:contents
and replaced elements
------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/1024
TabAtkins: Still the question on if this is the definition or the
max-width...which issue?
dbaron: The display:contents bit I think was a different github
TabAtkins: 540, yes (https://github.com/w3c/csswg-drafts/issues/540)
dbaron: Right.
dbaron: We have this historic problem that CSS meant to treat form
controls as replaced elements but then we applied a bunch
of css to form controls so we now have this world where
each one is half way between replaced and controlled by
css and each is different.
* tantek agrees with dbaron's summary
dbaron: We need to go through list of form controls and say which
one counts as replaced and which doesn't. There might be a
good general definition for 80% but I'm skeptical on 100%
having a good general definition.
TabAtkins: In general I agree with the outline of the problem.
Which topic do we want to try and discuss. Sizing in
certain circumstances? display:contents? other stuff?
dbaron: I think this is complicated enough it should be offline
for a bit.
dbaron: Unless there's a particular topic.
<fantasai> I don't think defining what a "form control" is is
something we can resolve atm, but 'display: contents'
issue is important
<fantasai> max-width issue is the 2nd issue on the agenda, that
astearns skipped over. I think it is prepared enough
for wg discussion right now
TabAtkins: Percentage max-height|width is more relevant. We should
be consistent on display:contents soon as browsers are
intending to ship.
TabAtkins: display:contents might be easier since you posted a
detailed comment. You had the 3rd option of run
display:contents literally for form controls. Remove
the box and treat children as normal boxes.
* fantasai I think the 3rd option is totally sensible here
dbaron: That avoids the problem and seems like a reasonable
behavior.
TabAtkins: I don't agree it will be useful as only some form
controls have children. Having options as you strip
away doesn't seem all that useful, but I guess it's
fine. There's a lot of form control behavior that
becomes unclear.
astearns: Would you get different boxes for same form control in
different browsers?
TabAtkins: No. You would pretend the form control element wasn't
there and it's children as just present.
<gregwhitworth> that's not actually true - for example our input
will have a clear box - where as Chrome/FF/Safari
will not
<gregwhitworth> select should be pretty uniform
dbaron: Proposal was that display:contents on a form control is
that the form control loses it's replaced magic and you
display children on normal css rules.
TabAtkins: So stripping a select would be a bunch of option inline
children.
<tantek> kind of like how alt text is displayed as normal inline
when an img fails to load.
dbaron: However options display not in a select. From CSS it's
straight forward. It's not well spec what aspects of form
controls are associated with DOM and which with box.
<gregwhitworth> 100% what David said
TabAtkins: Do the options in select...are they still selectable?
TabAtkins: Is there a behavior distinction between select multiple
and single? That's the hard part.
tantek: As soon as it's replaced by plain text or content it loses
it's special behavior. This happens with images when the
alt text is rendered. You can't drag and drop, but you can
select the alt text. It's a simple answer, if not ideal.
TabAtkins: But then you can't walk the DOM and submit a form. You
can't walk the DOM and find the select, you have to
look at the presentation layer.
<gregwhitworth> this sounds messy IMO
tantek: Technically that's not the same. We could draw a
distinction between user interaction behavior and submit
behavior. It's not ideal.
TabAtkins: If we strip the select you couldn't click on an option
to change select index.
tantek: Yeah. It loses it's UI behavior.
TabAtkins: Seems not crazy.
* fantasai just wants a spec that's 100% defined and not a
side-effect of Gecko's nsCSSFrameConstructor
tantek: For DOM and form submission it would behave as-is in the
DOM.
tantek: It's not ideal, but technically you can separate those two.
TabAtkins: Okay. I like it better then what I thought you were
saying. I think we can define that generically in a
reasonable fashion.
astearns: Does that mean we define as replaced elements when using
display:contents lose their replaced behavior?
<fantasai> "Replaced elements no longer replace their content, but
instead that content is displayed according to the
usual CSS rules"
TabAtkins: If we wanted generic over all replaced we have to
accept this has consequences with object. Or we can
acknowledge that the children are css-y and that's why
it works normally.
astearns: We'd have to display what form elements are to have an
order of this.
TabAtkins: Sure, but CSS wouldn't care directly. It would have an
extra category that the host link would define. When
you display:contents if they have a special rendering
normally their children become normal boxes.
TabAtkins: We can define that category. THere's still more to
answer like how they work in layout, but for this
situation we can do it generically without a lot of
effort
<fantasai> Alternate proposal: replaced elements do what was just
suggested, but form controls (defined as anything that
could potentially submit in HTML), behave as display:
none
fantasai: I'm a little skeptical about how we'd define event
handling and interaction for form controls. Possibly
it's straight forward, but I'm not certain. And what
aspects of styling and interaction are inherent to the
form element.
<gregwhitworth> I'm fine with them behaving as display none
fantasai: I think this makes sense for actual replaced elements.
Taking away the box and showing contents is fairly
straight forward. But for form controls I think we can
say they display as display:none. Saying they all
disappear entirely is simpler to understand and define.
And form control is anything capable of submitting html.
TabAtkins: This seems backwards. The elements more similar should
be treated odd, but the things further from normal
would act normally.
fantasai: I see replaced objects like videos as more normal than
form controls since the idea was control would define
how replaced elements work.
fantasai: They don't have elements that are children that
themselves have special behavior that only make sense as
being part of the outer element.
<rachelandrew> the solution fantasai is suggesting makes sense to
me, doesn't seem weird.
<smfr> what about <input type=“text” style=“display:contents”><div>
children</div></input>
smfr: Do we expect orphans will want their own children in form
controls? Or only content the UA creates will show up?
TabAtkins: HTML parser doesn't let you put stuff in form controls,
though DOM APIs do. It's not expected people put things
there on purpose. It's defining how this error case
occurs.
dbaron: You're thinking people might use the dom to do things like
that.
dbaron: I think that might be okay too.
* glazou notes editors like CodeMirror are based on that
rachelandrew: What fantasai is saying makes sense to me. Authors
see form controls as weird anyway so saying they
have the display:none behavior makes sense.
TabAtkins: They're weird, but they act like they have children.
Replaced elements have 0 children and are a black box.
That's why it's weird to me that this thing with no
children can display children.
<dbaron> there might be an advantage to making them less weird,
though...
fantasai: That's not true. When the image fails to load you
display the contents of the container.
rachelandrew: It maps to how authors using this stuff think about
it.
tantek: I disagree with fantasai generalization that replaced
elements act in a consistent way. That's false. Image,
object, and video behave completely differently in regards
to their children.
tantek: Trying to lump those together...they behave differently.
TabAtkins: Her point is the video element where its children are
just info sources vs a select where the options have a
behavior. They interact with user interaction. Her
point is there's more magic in that options are now
normal vs tracks are normal.
<fantasai> thanks, TabAtkins :) That was a clearer explanation
than I would've managed
tantek: Object is between those two. It does do special things
based on if browser supports etc.
TabAtkins: It does fallback. There's no interaction on the normal
behavior. You treat it like it's doing fallback. I
think we should be consistent with replaced where they
all strip one box or all display:none.
tantek: I'd like image and object to be treated the same and strip
away one box.
<gregwhitworth> And what happens when the children boxes vary
browser to browser? That sounds like a testing
nightmare.
<gregwhitworth> should not be - doesn't mean they won't
TabAtkins: I don't think there's use cases for any of these. We're
defining least intrusive option. dbaron suggests doing
it literally is the least intrusive.
TabAtkins: I'm support it on that frame, not on terms of
usefulness. People shouldn't display:contents these.
tantek: For object the use case is to force the fallback to show.
<fantasai> tantek, that is the effect, yes
TabAtkins: There is no use case. We're defining based on it needs
some behavior and we need the easiest. What sounds easy
isn't easy architecturally. Stripping a level is a
little easier.
TabAtkins: If you bring up use case you're arguing wrong. It's a
corner case.
fantasai: It has the effect and if it's useful, do that. But we're
not going from a use case here.
<tantek> I'm ok with treating things simply (architecturally) as a
first cut and see what unexpected things happen, and then
address those as needed
plinss: Every single time in the past where we define a corner
case by whatever is easiest it's come back and bitten us
years later.
astearns: We have 2 proposals. 1 is treat all these as stripping
out one box which will cause a bit more spec pain as
we'll have to define what that means for all of these
things. Other proposal is treat all of these as doing
display:none when you do display:contents. It seems
simpler to spec and communicate.
<gregwhitworth> It also makes it much more obvious to the author
that there's a problem
astearns: Because it's a corner case we're not looking for utility
so the display:none might be easier because we don't
know side effects.
<dbaron> I think I'm OK with the display:none thing; at the very
least it (so far) has a lot fewer problems than the
original display:inline solution.
fantasai: 3rd was display:none on form and box stripping on others
TabAtkins: I believe that's the worse
astearns: I'd rather a consistent story on the edge cases of
display:contents
<tantek> I thought I heard that "stripping off the one box" was
the simpler architectural option?
<fantasai> tantek, it's tricky to define for form controls I think
astearns: And tantek mentions that stripping one box was simpler
architecturally.
dbaron: It's much simpler then display:inline thing. This started
as we wanted to make it display like and then compute to
display:inline
astearns: And that's off the table.
<tantek> ok it sounds like convergence is happening, will wait it
out and see what people say
<gregwhitworth> We can reference HTML5 for "form controls" right?
If you have a new one that is proprietary we don't
need to spec that.
<fantasai> gregwhitworth, technically "form control" isn't dfn'd
but I think we can define it relatively simply or ask
HTML to do so
<gregwhitworth> fantasai: 👍
astearns: Does anyone disagree we're down to display:none or strip
one box?
[silence]
astearns: Does anyone have a marked preference between them?
<tantek> I know we're not arguing usefulness/use-cases, BUT I have
a slight preference for strip one box for that reason
(e.g. object)
TabAtkins: I believe FF dev expressed a preference for stripping a
box because display:none is still not trivial.
dbaron: Emilio's second comment?
TabAtkins: Yeah.
dbaron: I'm not entirely sure what he was thinking about but I'm
not sure it implies it's easier.
TabAtkins: Okay.
<dbaron> (emilio's comment being
https://github.com/w3c/csswg-drafts/issues/540#issuecomment-281875695
)
astearns: So there's slight preference for strip one box. We could
try spec this and go through repercussions of that.
astearns: I have a feeling we will run into similar problems as we
did for inline.
dbaron: I'm fine with going with none. I should ping Emilio.
<tantek> I think fantasai provided the two key examples that help
make strip one box doable. e.g. img does not display alt,
but object does display its contents
<tantek> seems like all form controls fall into one of those two
categories
<tantek> empty or not?
<gregwhitworth> I would prefer none - stated it before but I'll
say it again :)
TabAtkins: Do we tentatively resolve and if there's evidence to
the contrary we can re-open?
astearns: Objections to display:none for items with
display:contents?
<dbaron> And I'm fine with "treated as display:none" -- "computes
to display:none" would be problematic.
fantasai: I'd like to gear from rachelandrew
<tantek> do we have objections to strip one box?
rachelandrew: It seems okay. It's a corner case and we need
something to explain.
astearns: Proposal: have display:contents treated as display:none
for replaced elements and form controls.
astearns: Objections?
<tantek> no objection, but seems like we're throwing away an
opportunity oh well
RESOLVED: Have display:contents treated as display:none for
replaced elements and form controls.
ACTION dbaron to ping Emilio about the have display:contents
treated as display:none for replaced elements and form
controls resolution
<trackbot> Created ACTION-834
Use flex-order first or document-order first item's baseline?
-------------------------------------------------------------
fantasai: I have data that's not compat data, which is about what
is the point of the feature. I think we need to choose
visually first.
fantasai: If you're reverse ordering a column flexbox then you're
choosing first baseline on an element that's potentially
in the middle. If the goal is visual alignment of text
then you need visually first baseline. Regardless of the
interop I think we need to go with first visual box for
first-baseline and last for last-baseline.
astearns: I'm confused about the element in the middle.
<gregwhitworth> an int is used on ~1.3% of sites crawled:
https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/order/
<gregwhitworth> granted this doesn't determine if they care about
baseline alignment in these cases
fantasai: Suppose each box has 10 lines of text. We'd be taking
the 21st line of text as the "first line" to align to.
This makes no sense.
TabAtkins: If you do it with order and move things you'd take
visually the first line. It's taking flex direction
into account as well.
astearns: I'm happy going with visually first line.
astearns: Proposal: take the visually first line when considering
baseline alignment in flexboxes
astearns: Objections?
RESOLVED: Take the visually first line when considering baseline
alignment in flexboxes
Percentage [max-]width|height and intrinsic sizes
-------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/765
fantasai: There's an interop case where if you have a replaced
element with a width or max width in percentage we take
the intrinsic size contribution to be 0 or as close to 0
as you can get on form controls.
dbaron: Not all form controls, just text area and input-type is
text and only the width thing, not max-width.
fantasai: To get interop into spec we'd have to say all replaced
elements get max-squished if the width is % unless it's
a form control where we only look at width. Max-squashed
you take whatever the percentage resolves to.
fantasai: Issue I find is doing this special case for width, but
not max-width for input when doing both for images seems
inconsistent.
dbaron: This is a thing where we imitated this quirk for web
compat.
fantasai: I understand we want to be close to what's there, but do
we have to not do this for max-width on input and
text-area? If that's not a web compat requirement we can
do these things but have rules for images and inputs the
same. I want to put it to the WG, but I don't expect
answers right now.
fantasai: Was that clear?
astearns: I'm not following, but I wouldn't have the data you're
looking for.
fantasai: It's summarized with a test case in the last comment.
astearns: What do we do next?
fantasai: Impl need to review and see if they find it acceptable
or if it will result in web compat.
astearns: Can I get impl besides dbaron to volunteer?
astearns: gregwhitworth? I'd like you to look from Edge.
ACTION gregwhitworth to review #765 in github
<trackbot> Created ACTION-835
abspos flex/grid item "align-self: auto behaves as start" spec-text
is too vague
-------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/440
<astearns> https://github.com/w3c/csswg-drafts/issues/440#issuecomment-280459999
fantasai: There was a comment here.
fantasai: from TabAtkins.
fantasai: Issue was Christian raised a concern about the change in
behavior from when we worked on align. We realized we
don't have align self to take the align item value of
the parent because it may have nothing to do with layout.
TabAtkins: One step back: the behavior before alignment spec when
you have abspos when you set top right bottom left it
fills the box. We've now tied that to the stretch
behavior of align & justify self. If you don't want
that and want to center the abspos you can set top
right bottom left to 0. So auto looks at the parent for
align or justify items.
TabAtkins: If parent is a flexbox, but the abspos containing block
is further up the tree and is entirely manually
positioned you'll get a weird effect where flexbox's
align items changes how the abspos is rendered. It's
mysterious and shouldn't have this effect.
TabAtkins: We tried to break that but we probably go too
aggressive and made it no longer look at parent for
static pos.
TabAtkins: We can probably make this more subtle so abspos with
align-self:auto doesn't pay attention to parent for
normal alignment, but will for static pos.
fantasai: Did anyone follow?
gregwhitworth: You wont be changing static position again?
TabAtkins: It wasn't intended to change static position.
TabAtkins: Goal of the edit was to remove the weird parent. The
change was more aggressive then intended. I can do a
carve out that does this properly.
gregwhitworth: Sounds good.
fantasai: 3 behaviors: align-self had no effect on abspos unless
effects static position of an abspos that happened to be
a child. So it would have a side effect of setting the
static position of the abspos if it happened to be a
child. Then we had this super weird thing where it ended
up doing unexpected alignment. So then we said abspos
don't look at parents, they're always normal. Then
Christian said it changes the behavior of the static pos.
fantasai: So we can say when it's abspos it's just normal, but we
can fix it so that static isn't changed.
fantasai: Proposal: Static position of a child abspos of a flex
container is calculated with align-self looking at align
items even though the abspos normal alignment
calculations don't do that.
TabAtkins: Align-self:auto & justify-self:auto still look at
parent's align and justify items for abspos when
calculating static position only.
astearns: Objections?
RESOLVED: align-self:auto & justify-self:auto still look at
parent's align and justify items for abspos when
calculating static position only.
Renaming stroke-* in paint
--------------------------
<smfr> https://drafts.fxtf.org/paint/
<smfr> https://drafts.fxtf.org/paint/#perfect-world
smfr: I want to note apple has interest in fill and stroke.
smfr: We need Japanese captions which use stroke on a text and
we'd like to use these standard properties. We'd like this
draft to move forward. We want to talk about if we should
accept the rename in 3.7 which is perfect world syntax. We
don't want to lock into old names and we want to impl soon.
TabAtkins: fantasai and I plan to spend our work week in March
finishing this and making it publication ready, now
that you have interest
smfr: We have implemented paint-order so we need to put it here.
There's a stroke-align property where the request is it goes
on the outside of the glyph. It's hard in the graphics
engine. Easier to pop the fill on top of the stroke. So
we've impl paint order.
TabAtkins: Only works for opaque text, but that's the common case
smfr: Absolutely.
smfr: One other things, I'm not sure it specified if you have
fill-color and color.
TabAtkins: Color becomes like svg where it just sends the current
color. It becomes an information channel.
smfr: So color: red fill-color: blue
TabAtkins: You get blue text.
smfr: So fill-color is more specific and wins?
TabAtkins: Color...we're filling in a previously unspecified
property. It was previous un-specifiable so it was
currentColor. Now we can spec.
astearns: We're at the hour. Great that we'll get more work on the
draft. Let's continue these discussion as topics come
up. Thanks all.
<fantasai> yeah, finish off this FPWD has been on our to-do list
for awhile, just finally getting around to it now that
Grid is mostly stabilized :)<div
id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Thursday, 2 March 2017 02:38:42 UTC