- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Mar 2015 17:48:43 -0400
- To: www-style@w3.org
CSS UI
------
- RESOLVED: Spec resize property to inject 'width/height' style
attr values in pixels, because we have interop and
nobody wants to make it better.
- RESOLVED: Auto cursor switches between default/text whether
you're over text. No other magic.
- RESOLVED: Don't specify anything for how outlines actually work
other than what's there already. More details in next
level.
- RESOLVED: Resize doesn't apply to pseudos. Note that this may
change in the future.
- RESOLVED: Leave spec as-is, don't apply text-overflow when
overflow: visible.
- RESOLVED: Drop wording allowing word-drops, add as a new feature
in L4 e.g. as a new keyword or something.
===== FULL MINUTES BELOW ======
CSS UI
======
Scribe: fantasai
<tantek> https://wiki.csswg.org/spec/css3-ui#steps-to-pr
tantek: In pretty good shape with CSS UI.
tantek: The links is a set of steps to get to PR.
tantek: We're down to about 7 semi-substantial or substantial
issues, resolutions on most of them.
tantek: Steps to PR, we've got a set of drafts to publish, one
queued up.
tantek: Fixes to issues at this meeting.
tantek: Interest in test cases? Spec is probably stable.
tantek: Features are stable. Ee're cutting things, not adding
things.
ChrisL: Couldn't run the first test,
ChrisL: for directional navigation.
fantasai: I would like to see a WD of what you think should be
going to CR, i.e. after you've fixed the outstanding
issues, and then request a review of that. You haven't
demonstrated wide review of the thing you're proposing
for CR.
<tantek> Current issues: https://wiki.csswg.org/spec/css3-ui#current-issues
Resize Property (Issue 47)
--------------------------
<tantek> https://wiki.csswg.org/spec/css3-ui#issue-47
tantek: Issue 47
tantek: Objection from TabAtkins to resolution, +1 from smfr
[tantek summarizes the issue: original spec talked about a "resize
factor" that was maintained implementations instead modify
'width/height' inline styles directly]
tantek: The downside of speccing that is that it limits how you
handle e.g. resizing of the window by the user.
tantek: You rob the author and user of having interfaces that
dynamically resize in a sensible manner.
tantek: Resolution at last telecon was to change "factor" to
"function"
tantek: and allows for more intelligent resizing.
tantek: The point here is to not restrict the web platform in ways
that prevent it from being competitive with native
platforms.
tantek: That's the goal of sticking with the function wording,
rather than artificially restricting to style attrs.
Florian: Current behavior with browsers does fall short where we
could do better.
Florian: I disagree that the function is a good way to solve this,
because it's so generic, better ones and worse ones,
could be conformant.
Florian: Also, I think it's reasonable to spec in a detailed way
what is currently implemented, but also to extend it.
Florian: e.g. say "resize me, but do so in percent, rather than in
pixels" or "resize me in ems rather than in pixels".
Florian: The function that you allow is undefined, which is good
because it allows good behavior, but is also bad because
it also allows bad behaviors.
Florian: Would rather spec what browsers are actually doing, and
allow extending.
<SimonSapin> +1 Florian
<glazou> dino also said +1
<AndreyR> +1
<dbaron> I think the underlying problem with 'resize' is that the
feature was specified at the wrong layer of the platform (
too low).
fantasai: What would would be worse than the current behavior?
Florian: ... not interoperable.
fantasai: So your issue is that non-interoperable is bad. I'm
asking, what is a specific behavior that is worse than
the current behavior? Because I think the current
behavior is the worst that I can think of that isn't
pathological (e.g. semi-random output on resize).
dbaron: I think the underlying problem with this feature is that
it was designed at the wrong layer of the platform.
dbaron: Was trying to hook into low-level CSS width functions what
should have been a higher function.
dbaron: It's a lot of work for something that shows up in
high-level controls
dbaron: Implementations proxy it down to a lower level, using what
authors could use to do it.
dbaron: They reuse their existing code rather than changing
width/height computation for everything else in their
codebase.
dbaron: We have a legacy feature.
dbaron: We should just spec it better,
dbaron: And figure out a better way to have the feature that
doesn't go poking in low-level CSS calculations.
tantek: The intent was to keep it high-level from the start.
tantek: That's how it started, trying to specify purely as a
high-level feature, not imposing at all on how
implementors implemented it.
tantek: The factor was a possible case, generalized to function.
tantek: There seems to be that even that is specifying too much.
TabAktkins: Not specifying enough.
tantek: Goal was to make this a high-level feature for authors.
tantek: Not sure what different approach could be taken.
Florian: What we have now is extensible.
tantek: By specifying new values.
fantasai: The default behavior would still be the stupid behavior,
that doesn't resize well. Even if you add more keywords,
the number of people who use it would be negligible.
fantasai: That makes it not worth adding the new keywords.
tantek: Should do the right thing by default.
Florian: I have wording for the current interop behavior.
Florian: Blink and Webkit differ from Firefox in a couple cases.
Florian: I propose to spec this and see if anyone disagrees,
Florian: built up from tests.
zcorpan: When and if we do come up with a successor of this
feature, that can provide better behavior
zcorpan: I think it is good to not let the different browsers
choose different behaviors for the same request from the
authors.
zcorpan: It's bad if for example one browser uses pixels and other
uses percents.
fantasai: The author doesn't notice any problems or differences in
behavior because they're designing in a single size.
fantasai: The differences in behavior only show up when you resize
the window.
tantek: Resizing the window is pretty common *rotates his phone*
This is resizing the window.
TabAtkins, florian: You just resize it again.
tantek: If the screen gets narrow I can't get to the resize handle.
TabAtkins: scroll and resize again.
[basically user has sucky experience because we have interop, and
we don't give a shit]
tantek: You want to make the poor behavior a must?
fantasai: So I don't understand the suggestions to create a new
feature that does better.
fantasai: Either you are happy with the existing behavior, or you
want a better behavior.
fantasai: If you want a better behavior, you could do it by adding
a new feature, or you can do it by improving the
existing one.
fantasai: The only reason to create a new feature rather than
improving the existing one is if you have a legacy
problem.
fantasai: I don't think we have a legacy problem here.
[...]
TabAtkins: Floating first letter is an example where we had bad
behavior, couldn't improve it, so made new feature.
tantek: Did design methodology change?
ChrisL: 'Must' is what you should say in all cases where you know
what is the right thing to do.
ChrisL: 'Should' allows you to not do that if you have a good
reason, but good reason is not defined.
SteveZ: 'Should' was being used often in cases where there was not
interop, and we didn't expect interop in the timeframe of
getting the spec out, but there was at least one version
that people could match over time to get interop.
SteveZ: So we used 'should' in context of saying, you're not going
to be an invalid implementation just because of the fact
you don't match it now, but this is where we want people
to be going.
tantek: So if there was in implementation of resize of good
behavior, we could put a should.
SteveZ: Yes, and we could spec that particular one as a should.
fantasai: And we used 'may' in cases where we didn't have an
implementation, but we knew which direction we wanted to
go to.
tantek: My memory agrees with what SteveZ was saying.
tantek: I'm okay with speccing style attr in pixels, since nobody
shows any intent to make it better.
RESOLVED: Spec resize property to inject 'width/height' style attr
values in pixels.
<dbaron> I guess my opinion about it being badly designed might
not be as strong as it was 10 minutes ago, after looking
at our code.
<dbaron> though I still don't know how resizing the old way would
interact with something like flexbox
<dbaron> (old way being as a resize factor)
cursor: auto (Issue 48)
-----------------------
<tantek> https://wiki.csswg.org/spec/css3-ui#issue-48
Florian: cursor: auto is vaguely defined.
tantek: We had a group discussion on auto cursor, to try to
restrict auto value as much as possible.
tantek: Define specifics instead.
tantek: Issue is about resize areas and scollbars.
tantek: The proposal handles this, but may need additional wording.
Florian: dbaron's original proposal of switching between switching
between text vs. default
Florian: Either out of scope for CSS, or expressible in a UA style
sheet.
Florian: We decided that resize cursor for the resize handler is
an override over whatever cursor value that author chose,
not specific to auto.
Florian: You can do magic over links for auto, but don't have to.
Florian: The only thing that needs to be magic inside auto is text
vs. empty space.
ChrisL: Should we have some way to know whether you're empty space
or text?
tantek: Don't have a way to detect scrollbars or resize handlers
either.
Florian: We don't have a ::cursor pseudo.
ChrisL: So proposal is to have auto switch between 'default' and
'text' based on whether you're over text?
tantek: And 'text' already handles horizontal vs vertical text
cursors.
ChrisL: What about links?
Florian: You have a UA style rule for that.
zcorpan: If you specify auto on a link, then you get a text cursor
zcorpan: html style sheet requires UA to specify pointer on links.
tantek: Possible regression if people have written * { cursor:
auto; }
Florian: Matches what firefox does, webkit does more magic.
RESOLVED: auto cursor switches between default/text whether you're
over text. No other magic.
Outline (Issue 55)
------------------
<tantek> Issue 55: https://wiki.csswg.org/spec/css3-ui#issue-55
Florian: Simple cases, everyone understands outline, but aside
from that there's no interop,
Florian: Not possible to spec it all in Level 3 timeframe.
tantek: In some cases we can't spec.
Florian: Would like group to sanction having a very loose spec for
outline in L3.
<AndreyR> agree
Florian: And clarify in L4.
Florian: For example, what do you do if element is transformed? Do
you transform the outline or not?
Florian: If children overflow, do you extend outline to include
them? Is the outline a rectangle or weird shape in that
case?
tantek: Contrary to resize, this is a feature where we've seen a
lot of innovation in browsers.
tantek: It is an area that is so diverse that we don't want to
pick any favorites right now, because we don't know how to
specify those.
tantek: We've seen some nice stuff, and want to see what the
market comes up with.
tantek: I suggest issue 55 and 51 close as no change.
fantasai: I agree with closing 55.
Florian: 51 is transforming outline.
fantasai: If you have interop on something you don't want, then
need to speak up about it.
<AndreyR> no obj
[...]
Florian: Need to answer question of whether outline is supposed to
be a focus indicator or a border that doesn't take up
layout.
fantasai: Whether it rounds on radius, what is its z-index.
fantasai: I'm concerned that if you don't deal with this now,
you'll end up not having a choice.
fantasai: You need to address the transform issue,
fantasai: must do it now or it's too late.
fantasai: Do we want to transform the outline or not?
fantasai: I would like to know what other people think, because my
opinion is completely worthless here.
dbaron: If you're in a 3d scheme, there isn't necessarily a decent
definition of what area is covered by your children.
Florian: If you want outline to be a focus indicator, you put
outline around the projected result.
Florian: We haven't specified this.
dbaron: I Think we can't specify now.
tantek: Objections?
RESOLVED: Don't specify anything for how outlines actually work
other than what's there already.
Resize on Pseudo Elements (Issue 52)
------------------------------------
<tantek> 52: https://wiki.csswg.org/spec/css3-ui#issue-52
tantek: No interop on pseudo-elements.
tantek: Suggest to say that they don't apply to pseudo-elements.
Florian: I don't think you can say that it does not apply and then
make it apply later.
dbaron: What we do is say the applies to line, and then have a
note saying that in the future we might extend things.
tantek: The proposal is resize doesn't apply to pseudos, and add a
note that it may apply in the future.
fantasai: Wouldn't say where it's going to be solved, just say it
may be solved in the future.
RESOLVED: Resize doesn't apply to pseudos. Note that this may
change in the future.
Applying text-overflow when overflow: visible
----------------------------------------------
<tantek> https://wiki.csswg.org/spec/css3-ui#issue-68
Florian: Initial version of text overflow required overflow
~= visible and line would overflow its containing block.
Florian: This is unfortunate if you have a float in the way. You'd
overlap the float.
Florian: The spec is changed to elide before the float.
Florian: Which is what Webkit does.
tantek: Suggestion to request that text-overflow apply even when
overflow is visible.
<tantek> I think generalizing to regardless of overflow value is
too big of a change.
rossen: That's problematic.
rossen: What would a block with text-overflow: ellipsis report for
its main content size, if all lines are ellipsized?
fantasai: text-overflow does not affect sizing.
[...]
Florian: What was specced was Firefox's behavior. now specced
webkit's behavior.
Florian: Firefox also asked for not requiring the overflow rule.
tantek: We don't have an implementation yet, though.
<AndreyR> agree with Tantek
fantasai: The main concern I have with the overflow issue is web
compat.
RESOLVED: Leave spec as-is, don't apply text-overflow when
overflow: visible.
Reverting text-overflow ellipsing at a line break
-------------------------------------------------
<tantek> https://wiki.csswg.org/spec/css3-ui#issue-76
tantek: Request made over twitter to allow implementations to
ellipse for text-overflow not at a character break
boundary but at a line break opportunity.
tantek: Seems like a reasonable request, not sure if anyone would
ever do it, so I put it in as a may.
tantek: One request to revert it.
tantek: Text-overflow, when you get to point where it overflows,
instead of clipping you back off the number of characters
to have ellipsis and not partial characters.
tantek: Proposal is to ellipse at a word boundary, line-wrapping
opportunity.
dino: We would do that, ellipse at a line-wrap opportunity
Florian: I have a few problems with these problems.
Florian: What looks better depends a lot on the context.
Florian: If you're in a mixed directionality context, starting
English, Hebrew going the other way around. Now what
exactly are you doing? You don't want ellipsis in the
middle of the line.
TabAtkins: Ellipsis is visual.
Florian: Another issue is do you know enough about wrapping
opportunities to do it at the visual layer when you're
doing the ellipsis.
Florian: Another issue is scrolling. If you scroll, it's supposed
to reveal more content as you go.
Florian: The really weird to drop in words as you scroll.
tantek: Behavior for scrolling is already looser than wording for
not scrolling.
fantasai: I disagree with this change, if you want this change it
should be a separate property and/or keyword
fantasai: to allow ellipsing at a word / line-wrap opportunity.
RESOLVED: Drop wording allowing word-drops, add as a new feature
in L4 e.g. as a new keyword or something
Received on Wednesday, 18 March 2015 21:49:14 UTC