- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 19 Nov 2015 05:39:46 -0500
- To: www-style@w3.org
max-width and intrinsic sizes in a table scenario
-------------------------------------------------
- This issue is on dbaron's queue to address.
system-ui change
----------------
- RESOLVED: Change 'system' to 'system-ui' in Fonts 4
pre-wrap/pre-wrap-auto
----------------------
- Florian re-introduced his view on the topic, but the right
people weren't available, so the conversation will continue on
the mailing list.
Resolve intrinsic track sizes: min-content vs auto minimums
-----------------------------------------------------------
- fantasai, TabAtkins, and dholbert were deemed the right people
to solve this problem. They'll respond to the mailing list
saying they're working on the problem.
Specifying solutions for the generated content issues
-----------------------------------------------------
- There was a proposal from glazou to take advantage user-select
to create controls as to if generated content should be
copy/paste-able.
- This solution seemed like it would only work for browsers
implementing multi-range (currently only Gecko)
- Florian will write a note suggesting to browsers that if
they do implement multi-range, they should also use
user-select to create these controls and glazou will
review it.
- It was reaffirmed that not all generated content needs to be or
should be copy/paste-able and therefore the solution needs to
be a switch. Likely that switch should default to turned off
for backwards compat.
===== FULL MINUTES BELOW =======
agenda: https://lists.w3.org/Archives/Public/www-style/2015Nov/0256.html
Present:
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Greg Davis
Elika Etemad
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper (IRC Only)
Peter Linss
Myles Maxfield
Simon Pieters
Anton Prowse
Liam Quin
Florian Rivoal
Alan Stearns
Lea Verou
Jeff Xu
Regrets:
Rossen Atanassov
Adenilson Cavalcanti
John Daggett
Simon Fraser
Michael Miller
Simon Sapin
Ian Vollick
Greg Whitworth
Johannes Wilm
Steve Zilles
scribe: dael
max-width and intrinsic sizes in a table scenario
-------------------------------------------------
astearns: Let's start. Not that many people on the call. Does
anyone have anything additional to bring up?
astearns: I'll take that as a no.
astearns: Since dbaron is only here for a bit, let's do 4.
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0225.html
astearns: I brought this up because it's interesting and doesn't
have any answers.
dbaron: The bug is on my list of things to work on. When I get a
chance to work on it I'll have a proposal for the change,
but I don't know the exact conditions.
Florian: I've looked a bit, but not too much. We're hitting a
CSS 2.1 undefined where everyone has a different answer
than Gecko. We'll have to clarify the spec for what
everyone else does. This is when you have max-width and
you have a loop where the content depends on the
container and the container on the content.
Florian: It seems most people are solving in an intelligent way,
but Gecko is bailing and resolving in terms of the size
of the image, not container. It's okay to do, but leads
to bad results.
Florian: I don't understand this to any more specific of a level.
astearns: You mentioned the other browsers do it different. Did
you test IE or Edge?
Florian: I don't recall specifically, but I think they're in the
same camp. I think it's everyone vs. Gecko, but I'm not
specific on this.
astearns: Anything else to contribute?
astearns: As long as it's on dbaron's queue we're fine.
system-ui change
----------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0228.html
astearns: This is changing the new generic font from 'system' to
'system-ui' to avoid a problem on windows. jdaggett
can't be here, but it was his idea. We've heard from
myles that it's okay.
* fantasai in favor, too, makes sense
<glazou> +1
leaverou: I think it's a bit unwieldy. Maybe 'native' or simply
something simpler.
astearns: Given that this is what the system uses for it's ui, it
seems the shortest that says what it does.
leaverou: If it's fine by everyone else, I'm fine with it.
<dbaron> The trick is that it needs to be a single word that
nobody has ever used as a font name. :-)
<fantasai> dbaron++
astearns: Other comments?
<Bert> +1 to system-ui (unless somebody has a better name...)
<myles> 👍
glazou: Totally support this.
dbaron: One comment for leaverou. The trick is it needs to be a
single word no one has used as a font name before.
<fantasai> And having a hyphenated name is actually good for this
leaverou: And there's no font called system-ui?
glazou: System-dash-ui, probably not
astearns: It's not ever, but we have to have one not used by a
font installed by default. I'm not that concerned that
there's a font somewhere you'd have to install.
leaverou: What about 'platform' or 'native'. They're single words
and I don't think there's a font with those.
astearns: But going back to have a name that describes what you're
trying to target. There are tons of native fonts.
leaverou: yeah...okay.
<fantasai> I think system-ui is very clear, and because of the
hyphen, unlikely to cause a conflict
astearns: Okay, so, I think we're okay to resolve
RESOLVED: Change 'system' to 'system-ui' in Fonts 4
astearns: And jdaggett said he'd edit that into Fonts 4 if we
resolved on it.
pre-wrap/pre-wrap-auto
----------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0239.html
Florian: I'm not sure this is mine or fantasai or koji. fantasai
do you want to start?
myles: fantasai is muted for the call.
<fantasai> I think the current thread is heading in the direction
of having pre-wrap only
<fantasai> and not pre-wrap-auto
<fantasai> using 'word-break' to get the additional behavior that
Florian is requesting
<fantasai> Koji is requesting clarification on use cases on the
thread, is the last I saw.
Florian: So in NY after multiple discussions, we resolved to
clarify the meaning of white-space:pre-wrap into one
behavior and introduced white-space:pre-wrap-auto to let
browsers provide what they want which allows nicer
editing. The specific issue is when there are several
white spaces. Do we wrap them, let the go long, cut them?
Florian: This was brought up for two reasons. Every browser is
inconsistent. None of the solutions solve some of
Bloomberg's use cases. We made the new pre-wrap preserve
every space and wrap them.
Florian: koji doesn't like this, fantasai was re-opening the
option to drop pre-wrap-auto and allow all the variants
including what I asked for as the behavior of pre-wrap.
Florian: I'm not really in favor because I think what I asked for
is specific and authors want to opt-in. In NY we decided
that could cover all cases, but I'm okay with going back
and making it something you opt into. I'm not okay with
you having no choice what the browser does.
Florian: If it's an opt-in, what's the trigger and the default?
One is to say it triggers everything, one is to pick a
default.
Florian: I'm not sure we have to repeat the entire conversation
since we've spoken on this for over an hour already.
<fantasai> Given my current understanding of the situation, I
think the best idea is:
<fantasai> 1. For L3, allow pretty much everything as pre-wrap
<fantasai> 2. For L4, restrict pre-wrap to not wrap within spaces
<fantasai> 3. For L4, add a 'word-break: spaces' value to allow
wrapping at spaces.
<fantasai> and I agree with the idea of converging on the IE
behavior for L4, it makes the most sense
Florian: My proposal is to recommend the IE behavior as the
default - if you have a series of spaces that goes off,
you preserve the spaces and they overflow the line.
Everything else would still wrap. That's D in fantasai's
e-mail.
Florian: I would also allow the Blink/Webkit where if you have
spaces going off the line you elide them. We could also
allow the legacy spec/Gecko behavior.
Florian: I don't think that's a great behavior, it's treat the
entire set of spaces as non-breaking.
Florian: So, use overflow-wrap: break-word as the default. That's
what IE is doing in text area elements.
<fantasai> Florian, you want 'break-word', not 'overflow-wrap'.
<fantasai> It doesn't fit within the model of 'overflow-wrap'
Florian: So I'm asking for IE/Edge on text areas with an allowance
where if you don't opt-in do the Chrome.
Florian: koji doesn't seem to like that, but I'm not sure why.
Florian: Does anyone else have an opinion?
Florian: [reads fantasai comment]
<fantasai> which only triggers wrapping if the entire line has no
other line breaking opportunities
<fantasai> which isn't what you want
<fantasai> you want to break within the trailing spaces even if
there's a space earlier in the line
astearns: Instead of overflow-wrap you want to add the option to break-word
Florian: The reason I picked overflow-wrap, if you're in IE you
have spaces overflowing. You could be wrapping in
different places, but you have spaces overflowing. So
having the overflow wrap say do break makes sense.
<fantasai> break-word is the property that alters the
line-breaking rules
<fantasai> which is what you're proposing to do
Florian: If you're falling back on non-IE it still sort of makes
sense if you think the underlying model is the IE one.
astearns: It sounds to me like both you and fantasai are looking
to take the current level and specify here's what
browsers do, allowing some variation, and locking things
down in a later level with some options. Does koji agree
with that start?
Florian: That's not entirely what I'm saying. The opt-in I'm
proposing already exists. The overflow-wrap doesn't say
what you do with a series of spaces. IE and Edge in text
areas interpret a sequence of whitespace that overflows
is a place where you can break. I'd rather have that
wording now instead of introduced later.
astearns: It sounds like there needs to be a bit more ML
conversation since koji isn't here and fantasai can't
speak. I'd encourage you to break this into steps. What
can you resolve on for the current level and what can
you put off for the next level that might allow you guys
to come to a better understanding of each other's
positions.
Florian: I'd like to understand why fantasai thinks what I'm
proposing doesn't make sense, but then maybe what you're
describing...Yeah. Mailing list time.
<fantasai> I'm fine to clarify that sequences of spaces may be
broken for overflow-wrap: break-word
<fantasai> However *that is not the behavior Florian wants*
<fantasai> Florian wants to allow breaks within trailing spaces
*even if there is a line-breaking opportunity earlier
in the line*
<fantasai> overflow-wrap does not do that.
<fantasai> It only has an effect if there are *no* line breaking
opportunities in the line *at all*
<Florian> fantasai: "break-word: An otherwise unbreakable sequence
of characters may be broken at an arbitrary point if
there are no otherwise-acceptable break points in the
line." Since we are overflowing the spaces, to me it
means that there is no otherwise acceptable break points
for this situation. Making this property appropriate.
<fantasai> Florian: Nope, you're wrong.
<Florian> fantasai: :)
<fantasai> Florian: |xx_xx_|_ has a breakpoint earlier in the line
<fantasai> Florian: but you want that to wrap
Resolve Intrinsic Track Sizes: min-content vs auto minimums
-----------------------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0086.html
* fantasai has no idea
astearns: I'm not sure what we can do without fantasai able to
speak.
astearns: This is from a few weeks back from someone looking for
implementor advice. I think we need to do something
about this.
astearns: Does anyone have an opinion?
[silence]
<fantasai> I think the people that need to discuss this are me,
Tab, and probably dholbert has a good idea of the
correct answer :)
<fantasai> but I don't know at the moment
<fantasai> Grid algo things really don't work on the telecon until
at least one person understands the issue.
<fantasai> and Tab and I tend to batch them up to work on
together, since we get pretty confused ourselves
astearns: fantasai says it's her, TabAtkins and dholbert.
astearns: So one or more of those three should respond on the ML
to get movement.
astearns: If that doesn't work, we'll add this to the agenda next
week.
Specifying solutions for the generated content issues
-----------------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0229.html
astearns: There's been a lot of conversation and one final message
where someone linked a bunch of bugs that people have
filed on browsers.
astearns: We've talked about specifying some of this or not. But I
think we should have selection, copy, paste for list
markers. In our specs you have issues and examples that
you can't search for.
astearns: Some people think there should be alt-text, some not.
But we haven't assigned anyone to put something in our
spec for this.
glazou: I think this is very controversial despite the simplicity
of the technical solution. A long time ago we decided we
didn't want to copy/paste and slowly we started to allow
it because people wanted some items. But switching from
selectables not being able to copy/paste to yes you can
copy/paste isn't great.
glazou: User-select lets someone specify how an element is
selectable. It's implemented by Gecko, Edge, and Webkit at
least. We could extend this set of properties and apply
them to pseudo elements to have a thinner control of what
we can do instead pseudo element. Then we can extend the
UI stylesheet to specify what is the default for a marker.
glazou: I'm thinking out loud, but it's a workable solution.
Florian: First, it kind of makes sense, but will have a problem.
On the positive side we won't need to work on the UA
style sheet. It could default to before and after and
people can switch it on.
Florian: It'll be a problem because it would work in Gecko, but
not elsewhere. Gecko has multiple range selections.
Florian: Other browsers have single range. If you start ::before
with a user-select it won't work. Unless we say everyone
has to switch to the multi-range.
Florian: If we don't have multi-range, it won't work.
<dbaron> what about selection being built around the range apis
which are built around the dom which doesn't have the
generated content in it?
tantek: The last time this came up, I remember we discussed this.
I agree with glazou it's controversial.
tantek: The weak consensus is it's okay to not select copy/paste
generated content so we can move forward with 2.1
* glazou 's recollection matches tantek's
tantek: However I remember we left the door open for browsers to
think of and try to do a better job because we couldn't
come up with a better job ourselves.
tantek: I don't know of any browsers that have done better to date.
I think glazou's proposal is interesting. I'd encourage
him to file a bug in bugzilla and say "hey Gecko, please
consider this enhancement".
tantek: I do believe that it's within what the standards allow.
It's not required. If it works we would have a data point
which we can reason from.
tantek: There's so much history, I think we need concrete data to
come to a better decision.
Florian: It may be a way forward. If the experiment in Gecko is
successful, how do you think we go from there to apply it
into other browsers?
tantek: Dunno. We can cross that bridge if/when we get to it.
tantek: If we have a next step, we can respond to the list so
people don't think they're ignored. We can say hey we need
to try these things to find a way forward. We can also ask
this person if they filed bugs on other browsers, such as
Gecko, and let this continue.
<tantek> note also that the Editing Task Force is working on the
subject of discontiguous selection
<tantek> (no I don't have a specific citation, but it was
discussed in the f2f in Paris)
glazou: To answer Florian, selection is something that's not out
of the blue, it's part of the open web platform. There's
specs in the W3C world that says what it is. Even if
there's differences between browsers now, we can expect
interop in the future. The goal of interop is to ensure
the user experience is the same no matter what.
Florian: But specs don't exist as a word of god. It's not clear to
me people will agree to a spec that requires multi-range.
glazou: I don't care if people won't follow the spec as soon as we
have two implementations.
Florian: We have all but one implementation agreeing on something
else.
glazou: I know that applying a set of properties to determine what
we can or can't do with generated content and pseudo
elements is doable.
Florian: In the abstract, yes. On user-select, maybe not.
tantek: I'm leaning more toward what glazou expresses. This has
been a topic for a long time and we can expect
implementors to move forward. We can spec that IF you
support multi-range, here if how you do it, or please
support this feature if you're doing multi-range. As a
former implementor, that guidance is really valuable.
tantek: That's another excellent way forward and a good way to
test the waters for how appealing that is for implementors.
If we see people moving toward it, we can start to spec.
This isn't all or nothing, we can move in glazou direction
without having to split hairs.
tantek: There's one argument from Florian I wanted to warn against.
If everyone but one browser agrees, we can't just decide
on that. If they're passively agreeing, we can't spec on
that. That's just specing the status quo, not moving
things forward. When everyone but one agrees, if the
agreement is not doing something, that doesn't justify
specing that.
Florian: If it works, I like glazou's behavior. I just worry about
the way forward.
Florian: In this case, people have said what they want, but maybe
they'll change.
Florian: The user-select spec already talks about multi-range.
Should I experiment at the spec level for text to cover
this and see if Gecko likes it, or ask Gecko to come with
language?
<tantek> sure, make a guideline in the spec!
<tantek> totally fine to start with informative suggestions like
that - implementers do read them and use their own
judgment
<tantek> it's a good way to test the waters
<tantek> Note is good
Florian: So an issue? Note?
ACTION Florian write a note on user-select for multi-range
<trackbot> Created ACTION-745
astearns: Aside from the problems of multi-select, I had a
question about glazou approach about adding switches to
change behavior.
astearns: Is that to avoid problems where people have relied on
generated content not being selectable, or is there a
use case for generated content not being selectable? I'm
wondering about the danger of changing without a switch.
glazou: We had examples when we discussed it long, long ago.
People using generated content to do decorations on a
website and they weren't meant to be selected. It's really
visual decoration.
glazou: It's the things that become extremely annoying if you copy
from a page and paste into a text editor.
astearns: It seems to be we're trading annoyances. Right now you
have annoyance where you don't get the list markers you
want. If we switch you get decorative that needs to
strip.
glazou: An example: you have a bulleted list in HTML and the
bullets can be selected/copied. You copy and paste into
word and word will paste the bullets. You don't want the
bullets, you want to hit the bullet button in word. So
adding the selectable can be good, but it can be bad. It's
excellent if you want to paste into plain text, but if you
want to paste into WYSIWYG type editor it doesn't work
unless you recognize the content.
glazou: Smart copy/paste is extremely painful.
tantek: To answer astearns...besides compat danger...the original
reasoning for why we made that decision was around that a
lot of us are very afraid that if we treated generated
content like content it would fail to discourage people
from putting relevant content there instead of HTML.
Documents are supposed to be renderable without the
stylesheet. We wanted to structure to avoid people
creating problems.
tantek: In this day and age we're in a very different climate
where we have all the popular webdevs building websites
that don't render content without JS. The situation is
much worse than 10 years ago when we made this decision.
tantek: At this point, how much harm does it do compared to the
harm being done with the JS dependency, I don't know. The
web is worse, I don't know how to fix it.
<tantek> js;dr reference:
http://tantek.com/2015/069/t1/js-dr-javascript-required-dead
liam: These days, I don't know why a program like word can't do a
smart copy/paste. At one timet hat was reasonable, not today.
glazou: I mentioned word, but it's all word processors.
liam: And some don't need much fixing. I hear you, but I've also
been there and talked to impl for things like open office.
They have shared APIs that help. It's not completely solved.
We shouldn't rule it out completely. It's much more
frustrating to have them vanish instead of have to edit them.
<tantek> also with copy/paste to word (or even google docs) they
usually use the "HTML" on the clipboard, not the "plain
text" (with or without bullets)
<fantasai> tantek++
<tantek> I tend to agree with the list-marker copy/paste use-case
leaverou: I think there are use cases for decorative content and
for real content you want copied or read by a screen
reader. In printing we use generated content a lot. The
ship for decorative content has sailed.
leaverou: Since there are valid use cases for both, why not have a
property which lets you control if it's decorative?
Florian: That's glazou's point.
leaverou: Well, +1 to glazou
Florian: There are some things not in either camp, but should be
treated as decorative. Like if you have clearfix
injecting periods everywhere. So we need a switch with
off by default.
<leaverou> it *has* to be off by default, for backwards compat
glazou: One example. wikipedia. It has unfortunate generated
content. It has real content in generated content, such as
geotags. But it also uses it for decorations.
glazou: Such as images that aren't clickable. So they're using
both fashions of generated content. The best we can do is
a switch.
astearns: As I understand it, Florian will add a note about what
can be done for browsers that support multi-select.
glazou do you need an action to propose this switch?
glazou: I could. The switch is just extending user-select and
probably one or two more properties to pseudo-elements. [
audio breaking up] Which I'm not sure if we're doing now.
If we have that and we explain, we're done.
Florian: I'd like to write the note first and have you review it.
glazou: Fine by me.
astearns: Florian please also respond on the list so people know
we're listening.
astearns: Anything else on this topic?
<tantek> (aside: this topic is a tough one, and the time on it is
well spent)
astearns: That's the end of the agenda for the week. So we'll end
a few minutes early. Thanks everyone.
Received on Thursday, 19 November 2015 10:40:53 UTC